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 7530 records.

Status: Verified (3481)

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 761, "DoD standard Transmission Control Protocol", January 1980

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

Source of RFC: Legacy

Errata ID: 8226
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mattia Marchese
Date Reported: 2025-01-01
Verifier Name: RFC Editor
Date Verified: 2025-01-06

Section 3.1 says:

Control Bits:  8 bits (from left to right):

    URG:  Urgent Pointer field significant
    ACK:  Acknowledgment field significant
    EOL:  End of Letter
    RST:  Reset the connection
    SYN:  Synchronize sequence numbers
    FIN:  No more data from sender

It should say:

Control Bits:  6 bits (from left to right):

    URG:  Urgent Pointer field significant
    ACK:  Acknowledgment field significant
    EOL:  End of Letter
    RST:  Reset the connection
    SYN:  Synchronize sequence numbers
    FIN:  No more data from sender

Notes:

The "control bits" field includes 6 bits as listed, while the line says they are 8 bits.
I might be mistaken, if so please tell me, but I assume it is a typing error due to distraction.

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:

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

It should say:

The 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 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: 7909
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Bondarenko
Date Reported: 2024-04-26
Verifier Name: Eric Vyncke
Date Verified: 2024-04-26

The "Packet format" section says:

        16.bit: (ar$pro) Protocol address space.  For Ethernet
                         hardware, this is from the set of type
                         fields ether_typ$<protocol>.

It should say:

        16.bit: (ar$pro) Protocol address space.  For Ethernet
                         hardware, this is from the set of type
                         fields ether_type$<protocol>.

Notes:

In original text last letter "e" is missing in "ether_type$<protocol>".

--- Verifier note (Eric Vyncke, INT AD) ---
After reclassification into "editorial", this erratum is approved.

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: 7430
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gordon Steemson
Date Reported: 2023-04-02
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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.

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 1025, "TCP and IP bake off", September 1987

Source of RFC: Legacy

Errata ID: 8378
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2025-04-08
Verifier Name: RFC Editor
Date Verified: 2025-04-08

Throughout the document, when it says:

1.  The John Nagel Procedures (RFC-896).

It should say:

1.  The John Nagle Procedures (RFC-896).

Notes:

Spelling correction of John Nagle's name.

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, RFC 9619

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.

Errata ID: 8148
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hirotaka Yamamoto
Date Reported: 2024-10-17
Verifier Name: RFC Editor
Date Verified: 2024-10-24

Section 2.1 says:

           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric
           (see Section 6.1.2.4).

It should say:

           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric.

Notes:

The text says "see Section 6.1.2.4", but section 6.1.2.4 is about compression and is not related to section 2.1 at all.

--VERIFIER NOTES--
Perhaps Section 6.1.3.5 was intended.

Errata ID: 8194
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantinos Psomadakis
Date Reported: 2024-12-01
Verifier Name: RFC Editor
Date Verified: 2024-12-04

Section 6.1.5 says:

Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |

It should say:

Use QCLASS=* unnecessarily                     |6.1.2.2    | | | |x| |

Notes:

In the summary for Section 6.1.2.2, the directive for "Use QCLASS=* unnecessarily" is marked as "SHOULD". This contradicts the guidance in Section 6.1.2.2 which states that QCLASS=* "SHOULD NOT be used unless the requestor is seeking data from more than one class."

The table entry should be updated to "SHOULD NOT" for consistency with the main text

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: 7167
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2022-10-15
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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

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 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: 8142
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gorka Zamorano Oró
Date Reported: 2024-10-16
Verifier Name: RFC Editor
Date Verified: 2024-10-24

Section 6.2 says:

The encapuslated (inner) datagram includes an IP Authentication header.

It should say:

The encapsulated (inner) datagram includes an IP Authentication header.

Notes:

Typo: “encapuslated” should be “encapsulated”.

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: 6800
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Shahaf
Date Reported: 2021-12-27
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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.

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 2080, "RIPng for IPv6", January 1997

Source of RFC: rip (rtg)

Errata ID: 8169
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ze-en Xiong
Date Reported: 2024-11-05
Verifier Name: RFC Editor
Date Verified: 2024-11-05

Section 1.2 says:

- This protocol uses fixed "metrics" to compare alternative routes.
     It is not appropriate for situations where routes need to be chosen
     based on real-time parameters such a measured delay, reliability,
     or load.  The obvious extensions to allow metrics of this type are
     likely to introduce instabilities of a sort that the protocol is
     not designed to handle.

It should say:

- This protocol uses fixed "metrics" to compare alternative routes.
     It is not appropriate for situations where routes need to be chosen
     based on real-time parameters such as measured delay, reliability,
     or load.  The obvious extensions to allow metrics of this type are
     likely to introduce instabilities of a sort that the protocol is
     not designed to handle.

Notes:

It should be 'such as' instead of 'such a'.

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 2157, "Mapping between X.400 and RFC-822/MIME Message Bodies", January 1998

Source of RFC: mixer (app)

Errata ID: 8163
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wes Hardaker
Date Reported: 2024-10-31
Verifier Name: RFC Editor

Section 4.2 says:

           encoding [1] IA5String OPTIONAl -- e.g. quoted-printable

It should say:

           encoding [1] IA5String OPTIONAL -- e.g. quoted-printable

Notes:

The word OPTIONAL has a lower case l at the end instead of an upper case L

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 2223, "Instructions to RFC Authors", October 1997

Note: This RFC has been obsoleted by RFC 7322

Note: This RFC has been updated by RFC 5741, RFC 6949

Source of RFC: Legacy

Errata ID: 8054
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: José-Nicolas Binette
Date Reported: 2024-07-29
Verifier Name: RFC Editor
Date Verified: 2024-07-29

Section 3b says:

These PostScript rules are likely to changed and expanded as
experience is gained.

It should say:

These PostScript rules are likely to be changed and expanded as
experience is gained.

Notes:

Missing word: "be"

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, RFC 9776

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.

Errata ID: 8188
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ari Cooper-Davis
Date Reported: 2024-11-26
Verifier Name: RFC Editor
Date Verified: 2024-12-04

Section 1 - Terminology says:

   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
   the given class, but are no records of the given type.  A NODATA
   response has to be inferred from the answer.

It should say:

   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
   the given class, but there are no records of the given type.  A NODATA
   response has to be inferred from the answer.

Notes:

Added missing "there" which impacts readability.

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.

Errata ID: 8324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Spishak-Thomas
Date Reported: 2025-03-10
Verifier Name: RFC Editor
Date Verified: 2025-03-11

Section 2.3.1 says:

   This return code is normally interpreted as "The resource identified
   by the request is only capable of generating response entities which
   have content characteristics not acceptable according to the accept
   headers sent in the request. In HTCPCP, this response code MAY be
   returned if the operator of the coffee pot cannot comply with the
   Accept-Addition request. Unless the request was a HEAD request, the
   response SHOULD include an entity containing a list of available
   coffee additions.

It should say:

   This return code is normally interpreted as "The resource identified
   by the request is only capable of generating response entities which
   have content characteristics not acceptable according to the accept
   headers sent in the request." In HTCPCP, this response code MAY be
   returned if the operator of the coffee pot cannot comply with the
   Accept-Addition request. Unless the request was a HEAD request, the
   response SHOULD include an entity containing a list of available
   coffee additions.

Notes:

The quoted portion was missing a closing quotation mark.

Errata ID: 8244
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Sayre
Date Reported: 2025-01-07
Verifier Name: RFC Editor
Date Verified: 2025-01-07

Section 2 says:

All HTCPCP servers should be referred to with the "coffee:" URI scheme 
(Section 4).

It should say:

All HTCPCP servers should be referred to with the "coffee:" URI scheme 
(Section 3).

Notes:

The coffee: URI scheme is described in Section 3, not Section 4.

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 2342, "IMAP4 Namespace", May 1998

Note: This RFC has been updated by RFC 4466

Source of RFC: Legacy

Errata ID: 8033
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David Harris
Date Reported: 2024-07-16
Verifier Name: RFC Editor
Date Verified: 2024-07-18

Section 5 says:

< The client is designed so that it keeps two ’Deleted Items’
mailboxes, one for each namespace. >

C: A003 CREATE "Delete Items"
S: A003 OK CREATE command completed
C: A004 CREATE "#mh/Deleted Items"
S: A004 OK CREATE command completed

It should say:

< The client is designed so that it keeps two ’Deleted Items’
mailboxes, one for each namespace. >

C: A003 CREATE "Deleted Items"
S: A003 OK CREATE command completed
C: A004 CREATE "#mh/Deleted Items"
S: A004 OK CREATE command completed

Notes:

Simple typographic error in mailbox name - "Delete" should be "Deleted".

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: 5122
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Russo
Date Reported: 2017-09-24
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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.

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 2425, "A MIME Content-Type for Directory Information", September 1998

Note: This RFC has been obsoleted by RFC 6350

Source of RFC: asid (app)

Errata ID: 7912
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Sydney Kerckhove
Date Reported: 2024-04-29
Verifier Name: Orie Steele
Date Verified: 2024-04-29

Section 8.2 says:

begin:VCARD
source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US
name:Bjorn Jensen

It should say:

begin:VCARD
source:ldap://cn=bjorn%20Jensen,o=university%20of%20Michigan,c=US
name:Bjorn Jensen

Notes:

Section 6.1 says "It contains a URI as defined in [RFC-1738]" and RFC 1738 says in section 2.2:
"Octets must be encoded [...] if the use of the corresponding character is unsafe [...]" and
"The space character is unsafe [...]".
This means that the space character in this source uri must be percent-encoded or, in this case, removed.

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)

Errata ID: 8243
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Lambert
Date Reported: 2025-01-06
Verifier Name: RFC Editor
Date Verified: 2025-01-07

Section 5.3 says:

5.3 Predefined Set Objects

   In a context that expects a route set (e.g.  members attribute of the
   route-set class), an AS number ASx defines the set of routes that are
   originated by ASx; and an as-set AS-X defines the set of routes that
   are originated by the ASes in AS-X. A route p is said to be
   originated by ASx if there is a route object for p with ASx as the
   value of the origin attribute.  For example, in Figure 15, the route
   set rs-special contains 128.9.0.0/16, routes of AS1 and AS2, and
   routes of the ASes in AS set AS-FOO.

   route-set: rs-special
   members: 128.9.0.0/16, AS1, AS2, AS-FOO


          Figure 15:  Use of AS numbers and AS sets in route sets.

   The set rs-any contains all routes registered in IRR. The set as-any
   contains all ASes registered in IRR.

It should say:

   In a context that expects a route set (e.g.  members attribute of the
   route-set class), an AS number ASx defines the set of routes that are
   originated by ASx; and an as-set AS-X defines the set of routes that
   are originated by the ASes in AS-X. A route p is said to be
   originated by ASx if there is a route object for p with ASx as the
   value of the origin attribute.  For example, in Figure 15, the route
   set rs-special contains 128.9.0.0/16, routes of AS1 and AS2, and
   routes of the ASes in AS set AS-FOO.

   route-set: rs-special
   members: 128.9.0.0/16, AS1, AS2, AS-FOO


          Figure 15:  Use of AS numbers and AS sets in route sets.

5.3 Predefined Set Objects

   The set rs-any contains all routes registered in IRR. The set as-any
   contains all ASes registered in IRR.

Notes:

The section header for 5.3 is misplaced. It breaks 5.2 (definition and examples of route-set) at a place that does not make sense in context. The section break should be after the caption for Figure 15. The last two sentences (beginning with "The set rs-any") are the only text referring to predefined set objects.

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: 6302
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Abdullah Talayhan
Date Reported: 2020-10-07
Verifier Name: Paul Wouters
Date Verified: 2025-03-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.

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

Note: This RFC has been updated by RFC 9601

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

Errata ID: 7914
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Sydney Kerckhove
Date Reported: 2024-04-29
Verifier Name: Orie Steele
Date Verified: 2024-04-29

Section 2.3 says:

BEGIN:VCARD
VERSION:3.0
N:Dun;Alec
FN:Alec Dun
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
 Redmond;WA;98052-6399;USA
TEL;WORK;MSG:+1-206-936-4544
TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:user@host1.com
CALADRURI;PREF:mailto:user@host1.com
CALURI;PREF:http://cal.host1.com/user/cal.ics
FBURL;PREF:http://cal.host1.com/user/fb.ifb
CALURI:http://cal.company.com/projectA/pjtA.ics
FBURL:http://cal.company.com/projectA/pjtAfb.ifb
END:VCARD

It should say:

BEGIN:VCARD
VERSION:3.0
N:Dun;Alec
FN:Alec Dun
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
 Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-206-936-4544
TEL;TYPE=WORK,FAX:+1-206-936-7329
EMAIL;TYPE=INTERNET:user@host1.com
CALADRURI;TYPE=PREF:mailto:user@host1.com
CALURI;TYPE=PREF:http://cal.host1.com/user/cal.ics
FBURL;TYPE=PREF:http://cal.host1.com/user/fb.ifb
CALURI:http://cal.company.com/projectA/pjtA.ics
FBURL:http://cal.company.com/projectA/pjtAfb.ifb
END:VCARD

Notes:

The TYPE parameter parameter name was missing. parameter names are not optional, as specified in RFC 2426:

param = param-name "=" param-value *("," param-value)

param-name = iana-token / x-name

param-value = ptext / quoted-string

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: rsvp (tsv)

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, RFC 9601

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, RFC 9765

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, RFC 9765

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 2869, "RADIUS Extensions", June 2000

Note: This RFC has been updated by RFC 3579, RFC 5080

Source of RFC: radius (ops)

Errata ID: 7906
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jan-Frederik Rieckers
Date Reported: 2024-04-24
Verifier Name: RFC Editor
Date Verified: 2024-04-26

Section 5.14 says:

When the checksum is calculated the signature string should be
considered to be sixteen octets of zero.  The shared secret is
used as the key for the HMAC-MD5 hash.  The is calculated and
inserted in the packet before the Response Authenticator is
calculated.

It should say:

When the checksum is calculated the signature string should be
considered to be sixteen octets of zero.  The shared secret is
used as the key for the HMAC-MD5 hash.  The checksum is calculated and
inserted in the packet before the Response Authenticator is
calculated.

Notes:

The last sentence was missing a "checksum"

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 2986, "PKCS #10: Certification Request Syntax Specification Version 1.7", November 2000

Note: This RFC has been updated by RFC 5967

Source of RFC: Legacy

Errata ID: 8336
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angelica Semenec
Date Reported: 2025-03-17
Verifier Name: RFC Editor
Date Verified: 2025-03-18

Section 4.2 says:

certificateRequestInfo is the "certification request information."

It should say:

certificationRequestInfo is the "certification request information."

Notes:

There is no other reference to "certificateRequestInfo" and the ASN.1 definition specifies "certificationRequestInfo".

Errata ID: 8328
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angelica Semenec
Date Reported: 2025-03-14
Verifier Name: RFC Editor
Date Verified: 2025-03-17

Section 4.1 says:

subjectPublicKeyInfo contains information about the public key being certified.

It should say:

subjectPKInfo contains information about the public key being certified.

Notes:

This section describes top-level components of CertificationRequestInfo. "subjectPublicKeyInfo" should be labeled as "subjectPKInfo".

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.

Errata ID: 4899
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2017-01-09
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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 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: 6645
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Hertogs
Date Reported: 2021-07-20
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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: 7529
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2023-05-29
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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.

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 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", November 2002

Source of RFC: sip (rai)

Errata ID: 5184
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: DONG O YI
Date Reported: 2017-11-16
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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

Note: This RFC has been updated by RFC 9557

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 3365, "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", August 2002

Source of RFC: Legacy

Errata ID: 8295
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Sayre
Date Reported: 2025-02-12
Verifier Name: RFC Editor
Date Verified: 2025-02-14

Section 7 says:

We often say that Security is a MUST implement.  It is worth noting that 
there is a significant different between MUST implement and MUST use.

It should say:

We often say that Security is a MUST implement.  It is worth noting that 
there is a significant difference between MUST implement and MUST use.

Notes:

Grammar mistake: "different" should be "difference"

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 obsoleted by RFC 9776

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

Errata ID: 8282
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pablo Navarro
Date Reported: 2025-02-05
Verifier Name: RFC Editor
Date Verified: 2025-02-06

Section 2.4. says:

T1 is the wire-time at which Scr sent the first bit of the first packet, 
and T2 is the wire-time at which Src sent the first bit of the second packet.

It should say:

T1 is the wire-time at which Src sent the first bit of the first packet, 
and T2 is the wire-time at which Src sent the first bit of the second packet.

Notes:

The first mention of Scr is misspelled. It should be Src.

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 3402, "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", October 2002

Source of RFC: urn (app)

Errata ID: 7049
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timothy McSweeney
Date Reported: 2022-07-25
Verifier Name: Orie Steele
Date Verified: 2024-05-04

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 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 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", December 2002

Note: This RFC has been updated by RFC 5343, RFC 5590

Source of RFC: snmpv3 (ops)

Errata ID: 7959
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean-Francois Dube
Date Reported: 2024-05-28
Verifier Name: RFC Editor
Date Verified: 2024-05-28

Section 3.3 says:

   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, for example:          |
   |  '800002b804616263'H (enterpise 696, string "abc")              |

It should say:

   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, for example:          |
   |  '800002b804616263'H (enterprise 696, string "abc")             |

Notes:

Word "enterprise" is written as "enterpise"

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: 7836
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Lemon
Date Reported: 2024-03-04
Verifier Name: Eric Vyncke
Date Verified: 2024-04-23

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.

-- Verifier (Eric Vyncke) note --
See also https://mailarchive.ietf.org/arch/msg/dnsext/bSBYA97VQItwQS26fpVdQocrvnA/

I will request the IETF secretariat to update the datatracker.

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.

Errata ID: 8224
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alan Haggai Alavi
Date Reported: 2024-12-30
Verifier Name: RFC Editor
Date Verified: 2025-01-06

Section 4.2 says:

If an addr-type is
   defined for addresses which use characters outside of this
   repertoire, the specification for that addr-type MUST define the
   means of encoding those addresses in printable US-ASCII characters
   when are then encoded as xtext.

It should say:

If an addr-type is 
   defined for addresses which use characters outside of this 
   repertoire, the specification for that addr-type MUST define the 
   means of encoding those addresses in printable US-ASCII characters 
   which are then encoded as xtext.

Notes:

"characters when are then" should be "characters which are then".

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.

Errata ID: 8285
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mason K
Date Reported: 2025-02-07
Verifier Name: RFC Editor
Date Verified: 2025-03-07

Section Appendix D says:

A registration for a DSN address-type MUST include the following information:

It should say:

A registration for a DSN diagnostic-type MUST include the following information:

Notes:

Section for "IANA registration form for diagnostic-type" accidentally uses 'address-type' instead of 'diagnostic-type', incorrectly indicating that diagnostic-type information should be used for address-type registrations.

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: smime (sec)

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 3565, "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", July 2003

Source of RFC: smime (sec)

Errata ID: 8088
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Grundmann
Date Reported: 2024-08-23
Verifier Name: Deb Cooley
Date Verified: 2024-08-23

Section Appendix A says:

-- AES information object identifiers --

aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
               organization(1) gov(101) csor(3)_ nistAlgorithms(4)  1 }

It should say:

-- AES information object identifiers --

aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
               organization(1) gov(101) csor(3) nistAlgorithms(4)  1 }

Notes:

underscore in aes OID is an ANS.1 syntax error.

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

Errata ID: 7926
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Philip Porada
Date Reported: 2024-05-07
Verifier Name: RFC Editor
Date Verified: 2024-05-09

Section 6 says:

   1.4.1.  Appropriate certificate uses

It should say:

   1.4.1  Appropriate certificate uses

Notes:

There was an extra period trailing the subsection header number.

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 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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francisco Arias
Date Reported: 2018-03-06
Verifier Name: Eliot Lear
Date Verified: 2024-12-01

Section 5.1 says:

CodePoint = 4*8DIGIT  [ "(" Reflist ")" ]

It should say:

CodePoint = 4*8HEXDIG  [ "(" Reflist ")" ]

Notes:

Per RFC 2234, 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 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 3810, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", June 2004

Note: This RFC has been obsoleted by RFC 9777

Note: This RFC has been updated by RFC 4604

Source of RFC: magma (int)

Errata ID: 8029
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Seravalli
Date Reported: 2024-07-12
Verifier Name: RFC Editor
Date Verified: 2024-07-12

Section 2.2 says:

   Both Multicast Address Specific Queries and Multicast Address and
   Source Specific Queries are only sent in response to State Change
   Reports, never in response to Current State Reports.  This
   distinction between the two types of reports is needed to avoid the
   router treating all Multicast Listener Reports as potential changes
   in state.  By doing so, the fast leave mechanism of MLDv2, described
   in more detail in section 2.2, might not be effective if a State
   Change Report is lost, and only the following Current State Report is
   received by the router.  Nevertheless, it avoids an increased
   processing at the router and it reduces the MLD traffic on the link.
   More details on the necessity of distinguishing between the two
   report types can be found in Appendix A1.

It should say:

   Both Multicast Address Specific Queries and Multicast Address and
   Source Specific Queries are only sent in response to State Change
   Reports, never in response to Current State Reports.  This
   distinction between the two types of reports is needed to avoid the
   router treating all Multicast Listener Reports as potential changes
   in state.  By doing so, the fast leave mechanism of MLDv2, described
   in more detail in section 2.3, might not be effective if a State
   Change Report is lost, and only the following Current State Report is
   received by the router.  Nevertheless, it avoids an increased
   processing at the router and it reduces the MLD traffic on the link.
   More details on the necessity of distinguishing between the two
   report types can be found in Appendix A1.

Notes:

IIUC the fast leave mechanism is not explain in section 2.2 but in 2.3

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: smime (sec)

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 3915, "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", September 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 8305
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gavin Brown
Date Reported: 2025-02-21
Verifier Name: Orie Steele
Date Verified: 2025-03-28

Section 4.1.2 says:

When an <info> command has been processed successfully, the EPP
<resData> element MUST contain child elements as described in [2]. In
addition, the EPP <extension> element MUST contain a child
<rgp:infData> element that identifies the registry grace period
namespace and the location of the registry grace period schema.  The
<rgp:infData> element contains a single <rgp:rgpStatus> element that
contains a single attribute "s" whose value describes the current
grace period status of the domain.  Possible status values are
described in section Section 3.1.

It should say:

When an <info> command has been processed successfully, the EPP
<resData> element MUST contain child elements as described in [2]. In
addition, the EPP <extension> element MUST contain a child
<rgp:infData> element that identifies the registry grace period
namespace and the location of the registry grace period schema.  The
<rgp:infData> element contains one or more <rgp:rgpStatus> elements that
each contain a single attribute "s" whose value describes one of the the
current grace period status of the domain.  Possible status values are
described in section Section 3.1.

Notes:

The XML schema in Section 5 sets the maximum number of occurrences of the <rgpStatus> element to be unbounded, meaning that any number of elements may be present.

This correction updates the text to reflect the XML schema.

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, RFC 9601

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 3934, "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", October 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 8311
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean Mahoney
Date Reported: 2025-02-24
Verifier Name: RFC Editor
Date Verified: 2025-02-24

Throughout the document, when it says:

BCP: 94

It should say:

BCP: 25

Notes:

The IESG decided in December 2011 that RFC 3934 should have been added to BCP 25, instead of being added to a new BCP (BCP 94). At the IESG's request, the RFC Editor moved RFC 3934 to BCP 25 (see https://www.rfc-editor.org/info/bcp25 for the list of RFCs in BCP 25). This leaves BCP 94 empty.

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, RFC 9705

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

Note: This RFC has been obsoleted by RFC 9562

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: 4975
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Boon
Date Reported: 2017-03-22
Verifier Name: Orie Steele
Date Verified: 2024-04-24

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: GLOBAL UUID DATABASE
Date Reported: 2018-11-25
Verifier Name: Orie Steele
Date Verified: 2024-04-24

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: 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 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687

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 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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2014-02-12
Verifier Name: Paul Wouters
Date Verified: 2025-03-07

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.

Paul Wouters(Sec AD): This was fixed in RFC 7802 which also obsoletes this RFC

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

Errata ID: 7917
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jesse Coretta
Date Reported: 2024-04-30
Verifier Name: Orie Steele
Date Verified: 2024-05-01

Section 3.3.10 says:

      subset        = "baseobject" / "oneLevel" / "wholeSubtree"

It should say:

      subset        = "baseObject" / "oneLevel" / "wholeSubtree"

Notes:

The Enhanced Guide "subset" token SHOULD honor the case folding scheme for a search scope, as this refers to actual ASN.1 ENUMERATED / INTEGER components; see RFC 4511 Section 4.5.1 and ITU-T Rec. X.511 Clause 11.2.1 respectively.

Therefore, "baseobject" SHOULD be "baseObject".

Additionally, outreach to author failed due to unknown recipient at specified address/domain.

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 4724, "Graceful Restart Mechanism for BGP", January 2007

Note: This RFC has been updated by RFC 8538

Source of RFC: idr (rtg)

Errata ID: 7915
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Haas
Date Reported: 2024-04-29
Verifier Name: John Scudder
Date Verified: 2024-10-09

Throughout the document, when it says:

(See corrected text.)

It should say:

Please add the "Updates: 4271" metadata.

RFC 4724 updates the BGP Finite State Machine (FSM) for RFC 4271, the base BGP-4 specification.  This RFC should UPDATE RFC 4271.

Notes:

Nick Hilliard points out that we are missing this "updates" for the RFC.

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, RFC 9685

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 obsoleted by RFC 9580

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: 7889
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2024-04-10
Verifier Name: Paul Wouters
Date Verified: 2024-04-21

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 ☹

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.

Errata ID: 8139
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolaos Chatzikonstantinou
Date Reported: 2024-10-13
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-10-14

Section 1 says:

         *  Ensuring that neighbors remain reachable using the same IP
            and link layer addresses after initial discovery (Neighbor
            Unreachability Discovery - NUD) and notifying neighbors of
            changes to link layer addresses.  Uses NS and NA [RFC2461].

It should say:

         *  Ensuring that neighbors remain reachable using the same IP
            and link layer addresses after initial discovery (Neighbor
            Unreachability Detection - NUD) and notifying neighbors of
            changes to link layer addresses.  Uses NS and NA [RFC2461].

Notes:

"Discovery" should be "Detection" as defined in RFC2461 § 7.3.

WK: Doh! Thank you for the clear errata report.

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 5083, "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", November 2007

Source of RFC: smime (sec)

Errata ID: 8356
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roman Donchenko
Date Reported: 2025-03-30
Verifier Name: RFC Editor
Date Verified: 2025-04-02

Section 3 says:

generation of public/private key pairs relies on a random numbers.

It should say:

generation of public/private key pairs relies on random numbers.

Notes:

A simple typo.

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, RFC 9765

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
Area Assignment: art

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: 7628
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04
Verifier Name: Deb Cooley
Date Verified: 2025-01-19

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: 8027
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2024-07-11
Verifier Name: Deb Cooley
Date Verified: 2025-01-19

Section Appendix B says:

recipientInfos.riid.issuerSerialNumber = <NULL, 201>

It should say:

recipientInfos.riid.issuerSerialNumber = <NULL-DN, 201>

Notes:

In ASN.1, NULL is a type that is encoded as 0x0500. NULL is not appropriate in this context because the corresponding field is defined as a Name. NULL-DN is defined in RFC4210 as "a zero-length SEQUENCE OF RelativeDistinguishedNames". A NULL-DN is encoded as 0x3000. This is almost certainly what was intended here. Note, RFC4210 is not referenced by RFC5272 currently, so that would need to be changed as well to reference NULL-DN.

Errata ID: 4775
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kees-Jan Hermans
Date Reported: 2016-08-11
Verifier Name: Deb Cooley
Date Verified: 2025-01-19

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.

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, RFC 9598, RFC 9608, RFC 9618

Source of RFC: pkix (sec)

Errata ID: 5802
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikos Mavrogiannopoulos
Date Reported: 2019-08-06
Verifier Name: Deb Cooley
Date Verified: 2024-10-29

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yuting Chen
Date Reported: 2019-12-15
Verifier Name: Deb Cooley
Date Verified: 2024-10-29

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Stradling
Date Reported: 2021-01-28
Verifier Name: Deb Cooley
Date Verified: 2024-10-29

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: 7661
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Strauss
Date Reported: 2023-09-28
Verifier Name: Deb Cooley
Date Verified: 2024-10-29

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

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: 6639
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brennan Vincent
Date Reported: 2021-07-12
Verifier Name: Francesca Palombini
Date Verified: 2024-05-15

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: 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, RFC 9756

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

Errata ID: 8344
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mrinmoy Das
Date Reported: 2025-03-24
Verifier Name: RFC Editor
Date Verified: 2025-03-26

Section 9.15 says:

   IANA created a registry for the PCEP TLVs.

    Value         Meaning                    Reference

      1          NO-PATH-VECTOR TLV         This document
      2          OVERLOAD-DURATION TLV      This document
      3          REQ-MISSING TLV            This document

It should say:

   IANA created a registry for the PCEP TLVs.

    Value         Meaning                    Reference

      1          NO-PATH-VECTOR TLV         This document
      2          OVERLOADED-DURATION TLV    This document
      3          REQ-MISSING TLV            This document

Notes:

As per RFC 5440, the name of PCEP TLV type 2 will be OVERLOADED-DURATION TLV. So, the TLV name needs to be corrected in Section 9.15 of RFC 5440. Also, the IANA registry page needs to be reflected with the same.

Errata ID: 8349
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mrinmoy Das
Date Reported: 2025-03-27
Verifier Name: Ketan Talaulikar
Date Verified: 2025-04-01

Section 7.14 says:

         The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
         format defined in Section 7.1 and is comprised of 2 bytes for
         the type, 2 bytes specifying the TLV length (length of the
         value portion in bytes), followed by a fixed-length value field
         of a 32-bit flags field.

         Type:   2
         Length: 4 bytes
         Value:  32-bit flags field indicates the estimated PCE
                 congestion duration in seconds.

It should say:

         The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
         format defined in Section 7.1 and is comprised of 2 bytes for
         the type, 2 bytes specifying the TLV length (length of the
         value portion in bytes), followed by a fixed-length value field
         of 4 bytes.

         Type:   2
         Length: 4 bytes
         Value:  4 bytes field indicates the estimated PCE
                 congestion duration in seconds.

Notes:

TLV value field marked as 32-bit flags field which needs to be corrected to 4 bytes field.

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.

Errata ID: 8026
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Loïc Etienne
Date Reported: 2024-07-10
Verifier Name: RFC Editor
Date Verified: 2024-07-10

Section 4 says:

---------+----------+------------+-----------
80       | 160-223  | SHA-1      | sect163k1
         |          | SHA-224    | secp163r2
         |          | SHA-256    | secp192r1
         |          | SHA-384    |
         |          | SHA-512    |
---------+----------+------------+-----------

It should say:

---------+----------+------------+-----------
80       | 160-223  | SHA-1      | sect163k1
         |          | SHA-224    | sect163r2
         |          | SHA-256    | secp192r1
         |          | SHA-384    |
         |          | SHA-512    |
---------+----------+------------+-----------

Notes:

Misspelling: secp163r2 is not defined, whereas sect163r2 is.

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: 7945
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Maximilian Bauer
Date Reported: 2024-05-19
Verifier Name: Orie Steele
Date Verified: 2024-05-29

Section 3.8.8.3 says:

rstatus    = "REQUEST-STATUS" rstatparam ":"
             statcode ";" statdesc [";" extdata]

It should say:

rstatus    = "REQUEST-STATUS" rstatparam ":"
             statcode ";" statdesc [";" extdata] CRLF

Notes:

All other properties are specified to end with a CRLF. There seems to be no reason for this property to be an exception.

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 5636, "Traceable Anonymous Certificate", August 2009

Source of RFC: pkix (sec)

Errata ID: 5935
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-12
Verifier Name: Deb Cooley
Date Verified: 2025-01-24

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-12-12
Verifier Name: Deb Cooley
Date Verified: 2025-01-24

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 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, RFC 9629

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 5753, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

Errata ID: 8087
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Grundmann
Date Reported: 2024-08-23
Verifier Name: Deb Cooley
Date Verified: 2024-08-23

Section A.1 says:

   -- From [CMS-AESCG]

   id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters
   id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
     FROM CMS-AES-CCM-and-AES-GCM
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-cms-aes(32) }

   ;

It should say:

   -- From [CMS-AESCG]

   id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters,
   id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
     FROM CMS-AES-CCM-and-AES-GCM
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-cms-aes(32) }

   ;

Notes:

the missing comma after CCMParameters in the import statement is an ASN.1 syntax error

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: 6567
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-05-01
Verifier Name: Deb Cooley
Date Verified: 2025-01-24

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.

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, RFC 9747

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, RFC 9748

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

Note: This RFC has been updated by RFC 9748

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

Errata ID: 8204
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2024-12-06
Verifier Name: RFC Editor
Date Verified: 2024-12-06

Table of Contents

   13. IANA Considerations ...........................................42
   13. References ....................................................42
      13.1. Normative References .....................................42
      13.2. Informative References ...................................43

It should say:

   13. IANA Considerations ...........................................42
   14. References ....................................................42
      14.1. Normative References .....................................42
      14.2. Informative References ...................................43

Notes:

Repeated Section 13 in the Table of Contents. (14 is correctly numbered in the body of the document.)

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
Area Assignment: art

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: 4244
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Nicholas
Date Reported: 2015-01-27
Verifier Name: Deb Cooley
Date Verified: 2025-01-24

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.

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

Errata ID: 7899
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Michel COMBES
Date Reported: 2024-04-17
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-05-15

Section 5.2 says:

   o  Receive_SYN_traffic_key - the traffic key used to authenticate
      incoming SYNs.  The source ISN is known (the TCP connection's
      remote ISN), and the destination (remote) ISN is unknown (and so
      the value 0 is used).

It should say:

   o  Receive_SYN_traffic_key - the traffic key used to authenticate
      incoming SYNs.  The source ISN is known (the TCP connection's
      remote ISN), and the destination (local) ISN is unknown (and so
      the value 0 is used).

Notes:

"remote side" is referenced twice: potential cut-and-paste error from the previous paragraph. Errata verified based on the discussion in tcpm mailing list : https://mailarchive.ietf.org/arch/msg/tcpm/wauBdtHFEqtltJUxTo7kdF8msIU/

RFC 5927, "ICMP Attacks against TCP", July 2010

Source of RFC: tcpm (wit)

Errata ID: 8323
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2025-03-10
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19

Section 2 says:

Appendix D of [RFC4301] provides information about which ICMPv4 error
messages are produced by hosts, intermediate routers, or both.
...
Appendix D of [RFC4301] provides information about which ICMPv6 error
messages are produced by hosts, intermediate routers, or both.

It should say:

[Text sections are removed - see the notes]

Notes:

Text deleted as they are not necessary, since the
correct references to ICMPv4 (RFC792) and ICMPv6 (RFC2460) are already
present.

See the discussions here (https://mailarchive.ietf.org/arch/msg/tcpm/OkmxfectGJJ92thymY-CS375fzQ/).

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

Errata ID: 8191
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2024-11-29
Verifier Name: RFC Editor
Date Verified: 2024-12-04

Section 1 says:

TAMP messages may be exchanged in real time over a network, such as
   via HTTP as described in Appendix A, or may be stored and transferred
   using other means.

It should say:

TAMP messages may be exchanged in real time over a network, such as
   via HTTP as described in Appendix C, or may be stored and transferred
   using other means.

Notes:

The appendix reference is incorrect. Appendix A defines the ASN.1 module whereas Appendix C defines the protocol over HTTP.

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.

Errata ID: 7873
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Štěpán Němec
Date Reported: 2024-03-27
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

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: 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: 7919
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Slater
Date Reported: 2024-05-01
Verifier Name: Orie Steele
Date Verified: 2024-07-17

Section 2 says:

   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.

It should say:

   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 "]").  Care has to be taken
       both when encoding as well as when decoding to make sure these
       operations are applied only once.

Notes:

RFC 3986 does not require that sub-delimiters used in one component are encoded in other components. Specifically, RFC 3986 Section 2.1 (https://www.rfc-editor.org/rfc/rfc3986#section-2.1) states that a character requires encoding when it "is being used as a delimiter of, or within, the component."

According to RFC 3986, the mailto URI <mailto:Mike&family@example.org> is unambiguously the single addr-spec "Mike&family@example.org" because the path component of the mailto scheme does not use "&" as a sub-delimiter.

More comprehensively, the mailto URI <mailto:Mike&family@example.org?subject=Use%20of%20%26&body=Should%20be%20fine%20in%20addr-spec> must substitute "%26" for "&" in the value of the body header field because "&" is a query component sub-delimiter in the mailto scheme, but the query is the only component where this is required.

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

Errata ID: 6093
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Attila Gulyas
Date Reported: 2020-04-12
Verifier Name: Francesca Palombini
Date Verified: 2025-02-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!

Errata ID: 7604
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ted Zhu
Date Reported: 2023-08-15
Verifier Name: Francesca Palombini
Date Verified: 2025-02-12

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: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Wu
Date Reported: 2018-10-09
Verifier Name: RFC Editor
Date Verified: 2025-01-29

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

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, RFC 9554, RFC 9555

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: 7316
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Charles Burkitt
Date Reported: 2023-01-23
Verifier Name: Orie Steele
Date Verified: 2024-05-10

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: 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 6356, "Coupled Congestion Control for Multipath Transport Protocols", October 2011

Source of RFC: mptcp (tsv)

Errata ID: 8345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christian Huitema
Date Reported: 2025-03-24
Verifier Name: RFC Editor
Date Verified: 2025-03-26

The first-page header says:

M. Handly

It should say:

M. Handley

Notes:

This is an error in the front page of RFC 6356. The list of authors is presented as:

Internet Engineering Task Force (IETF) C. Raiciu
Request for Comments: 6356 Univ. Politehnica of Bucharest
Category: Experimental M. Handly
ISSN: 2070-1721 D. Wischik
Univ. College London
October 2011

Notice the misspelled author name "M. Handly". The author name is listed correctly in the Authors' Addresses section as:

Mark Handley
University College London
Gower Street
London WC1E 6BT
UK

EMail: m.handley@cs.ucl.ac.uk

-- VERIFIER NOTES --
Note that this hasn’t affected the XML citation library entry (https://www.rfc-editor.org/refs/bibxml/reference.RFC.6356.xml) or the text reference entry listed at https://www.rfc-editor.org/rfc-index.txt.

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: 7903
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Pahl
Date Reported: 2024-04-21
Verifier Name: Eliot Lear
Date Verified: 2024-12-02

Section 13.2 says:

 -dct_cat1, -dct_cat2, /* cat1 =  "111100",
                                  cat2 = "111101" */
        18, 20,
         -dct_cat3, -dct_cat4, /* cat3 = "1111100",
                                  cat4 = "1111101" */
         -dct_cat5, -dct_cat6  /* cat4 = "1111110",
                                  cat4 = "1111111" */

It should say:

 -dct_cat1, -dct_cat2, /* cat1 =  "111100",
                                  cat2 = "111101" */
        18, 20,
         -dct_cat3, -dct_cat4, /* cat3 = "1111100",
                                  cat4 = "1111101" */
         -dct_cat5, -dct_cat6  /* cat5 = "1111110",
                                  cat6 = "1111111" */

Notes:

The last two bit strings are for categories 5 and 6; only the preceding one is for category 4.

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

Note: This RFC has been obsoleted by RFC 9582

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 6488, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", February 2012

Note: This RFC has been updated by RFC 9589

Source of RFC: sidr (rtg)

Errata ID: 8307
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Theo Buehler
Date Reported: 2025-02-21
Verifier Name: John Scudder
Date Verified: 2025-02-22

Section 2 says:

The content-type is the signed-data type of id-data, namely the id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.

It should say:

The content-type is the id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.

Notes:

id-data (OID 1.2.840.113549.1.7.1) and id-signedData are siblings in the pkcs7 arc, so the latter is not a type of the former.

See also https://mailarchive.ietf.org/arch/msg/sidrops/_FuWIR0d5V53VGGGSh-6MKlqLxI/

Verifier note:

See also also, https://mailarchive.ietf.org/arch/msg/sidr/wIwQ1bsGCKC6V9sPNtRoJ3gntxo/

Verifier note:

See also also, https://mailarchive.ietf.org/arch/msg/sidr/wIwQ1bsGCKC6V9sPNtRoJ3gntxo/

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 6492, "A Protocol for Provisioning Resource Certificates", February 2012

Source of RFC: sidr (rtg)

Errata ID: 8308
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Theo Buehler
Date Reported: 2025-02-21
Verifier Name: John Scudder
Date Verified: 2025-02-22

Section 3.1 says:

The content-type is the signed-data type of id-data, namely id-signedData, OID = 1.2.840.113549.1.7.2.  [RFC5652]

It should say:

The content-type is the id-signedData OID 1.2.840.113549.1.7.2.  [RFC5652]

Notes:

id-data (OID 1.2.840.113549.1.7.1) and id-signedData are siblings in the pkcs7 arc, so the latter is not a type of the former.

See also https://mailarchive.ietf.org/arch/msg/sidrops/_FuWIR0d5V53VGGGSh-6MKlqLxI/

Verifier note:

See also also, https://mailarchive.ietf.org/arch/msg/sidr/wIwQ1bsGCKC6V9sPNtRoJ3gntxo/

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 6531, "SMTP Extension for Internationalized Email", February 2012

Source of RFC: eai (app)

Errata ID: 7580
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2023-07-31
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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: 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, RFC 9685

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

Errata ID: 8275
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olivier Paul
Date Reported: 2025-02-01
Verifier Name: Erik Kline
Date Verified: 2025-02-10

Section 3.2.3 says:

The DAD_NS messages are not
sent through any of the ports configured as Validating Ports.  The
DAD_NSOL messages are sent through Trusted Ports (but, of course,
subject to usual switch behavior and possible MLD snooping
optimizations).

It should say:

The DAD_NS messages are not
sent through any of the ports configured as Validating Ports.  The
DAD_NS messages are sent through Trusted Ports (but, of course,
subject to usual switch behavior and possible MLD snooping
optimizations).

Notes:

DAD_NSOL is the term used in SEND-SAVI but is not used anywhere else in FCFS-SAVI. The current phrasing might lead to believe that DAD_NSOL is different from DAD_NS.

--- Verifier note ---

This indeed appears to be typo, borrowing a different shorthand for the same thing from a related document.

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: 6971
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-05-10
Verifier Name: Erik Kline
Date Verified: 2025-03-12

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

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: 6171
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Valentin Micic
Date Reported: 2020-05-13
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-28

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"?

== Verifier note

This section is about relays/proxy agents checks to detect loops. See also Rob's comment at https://mailarchive.ietf.org/arch/msg/dime/4GVvCGAcMOtfRLuPe3amF2xX2E8/

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, RFC 9700

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 6775, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", November 2012

Note: This RFC has been updated by RFC 8505, RFC 8929, RFC 9010

Source of RFC: 6lowpan (int)

Errata ID: 8338
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adnan Rashid
Date Reported: 2025-03-18
Verifier Name: RFC Editor
Date Verified: 2025-03-21

Section 4.3 says:

   Reserved:                   This field is unused.  It MUST be
                               initialized to zero by the sender and
                               MUST be ignored by the receiver.

It should say:

This text must be removed because there are no Reserved bits exist in ABRO.

Notes:

This text must be removed because there are no Reserved bits exist in ABRO.

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.

Errata ID: 6692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jarle Fredrik Greipsland
Date Reported: 2021-09-22
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-07-09

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.


[Warren Kumari, Ops AD]: Marking as Verified, please see the thread at https://mailarchive.ietf.org/arch/msg/dnsop/voplw-sLcS-6u458reknBGQR2T0/ for additional information / justification.

RFC 6819, "OAuth 2.0 Threat Model and Security Considerations", January 2013

Note: This RFC has been updated by RFC 9700

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

Note: This RFC has been obsoleted by RFC 9755

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
Area Assignment: art

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, RFC 9654

Source of RFC: pkix (sec)

Errata ID: 6165
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Verifier Name: Deb Cooley
Date Verified: 2024-06-04

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Verifier Name: Deb Cooley
Date Verified: 2024-06-04

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Verifier Name: Deb Cooley
Date Verified: 2024-06-04

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

Errata ID: 7961
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: himanshu sharma
Date Reported: 2024-05-29
Verifier Name: Deb Cooley
Date Verified: 2024-06-01

Section Appendix B says:

This module replaces the modules in Section 12 of [RFC5912]
and Appendix A.1 of [RFC6277].

It should say:

This module replaces the modules in Section 4 of [RFC5912]
and Appendix A.1 of [RFC6277]

Notes:

The section "Appendix B" actually updates Section-4 of RFC-5912

Errata ID: 7962
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: himanshu sharma
Date Reported: 2024-05-29
Verifier Name: Deb Cooley
Date Verified: 2024-06-04

Section B.2 says:

IMPORTS

Extensions{}, EXTENSION, ATTRIBUTE

It should say:

IMPORTS

Extensions{}, EXTENSION

Notes:

It should not include "ATTRIBUTE" as it is not being used anywhere.

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.

Errata ID: 5926
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Justin Cranford
Date Reported: 2019-12-03
Verifier Name: Deb Cooley
Date Verified: 2025-04-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.

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: 7977
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Igor Malyushkin
Date Reported: 2024-06-09
Verifier Name: Gunter Van de Velde
Date Verified: 2025-02-10

Section 4.2 says:

Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending
(multicast) traffic, originated by VPLS sites connected to the PE, to
the sites attached to other PEs, then the local PE MUST use the
Originating Router’s IP Address information carried in the Intra-AS
A-D route to add the PE, that originated the route, as a leaf node to
the LSP. This MUST be done irrespective of whether or not the
received Intra-AS A-D route carries the PMSI Tunnel attribute.

It should say:

Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending
(multicast) traffic, originated by VPLS sites connected to the PE, to
the sites attached to other PEs, then the local PE MUST use the
BGP Next-Hop IP Address carried in the Intra-AS
A-D route to add the PE, that originated the route, as a leaf node to
the LSP. This MUST be done irrespective of whether or not the
received Intra-AS A-D route carries the PMSI Tunnel attribute.

Notes:

There is no such field as the Origination Router's IP Address in any VPLS A-D routes (RFC4761, RFC6074). For Intra-AS cases the BGP NH IP address can be used for the leaf tracking.

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
Area Assignment: ops

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

Note: This RFC has been updated by RFC 9579

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: 8327
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Goutham Jain
Date Reported: 2025-03-01
Verifier Name: John Scudder
Date Verified: 2025-03-18

Section 5 says:

bfdSessUp NOTIFICATION-TYPE
     OBJECTS {
         bfdSessDiag, -- low range value
         bfdSessDiag  -- high range value
     }
     STATUS     current
     DESCRIPTION
         "This notification is generated when the
          bfdSessState object for one or more contiguous
          entries in bfdSessTable are about to enter the up(4)
          state from some other state.  The included values of
          bfdSessDiag MUST both be set equal to this
          new state (i.e., up(4)).  The two instances of
          bfdSessDiag in this notification indicate the range
          of indexes that are affected.  Note that all the indexes
          of the two ends of the range can be derived from the
          instance identifiers of these two objects.  For the
          cases where a contiguous range of sessions
          have transitioned into the up(4) state at roughly
          the same time, the device SHOULD issue a single
          notification for each range of contiguous indexes in
          an effort to minimize the emission of a large number
          of notifications.  If a notification has to be
          issued for just a single bfdSessEntry, then
          the instance identifier (and values) of the two
          bfdSessDiag objects MUST be identical."
     ::= { bfdNotifications 1 }

 bfdSessDown NOTIFICATION-TYPE
     OBJECTS {
         bfdSessDiag, -- low range value
         bfdSessDiag  -- high range value
     }
     STATUS     current
     DESCRIPTION
         "This notification is generated when the
          bfdSessState object for one or more contiguous
          entries in bfdSessTable are about to enter the down(2)
          or adminDown(1) states from some other state.  The included
          values of bfdSessDiag MUST both be set equal to this new
          state (i.e., down(2) or adminDown(1)).  The two instances
          of bfdSessDiag in this notification indicate the range
          of indexes that are affected.  Note that all the indexes
          of the two ends of the range can be derived from the
          instance identifiers of these two objects.  For
          cases where a contiguous range of sessions
          have transitioned into the down(2) or adminDown(1) states
          at roughly the same time, the device SHOULD issue a single
          notification for each range of contiguous indexes in
          an effort to minimize the emission of a large number
          of notifications.  If a notification has to be
          issued for just a single bfdSessEntry, then
          the instance identifier (and values) of the two
          bfdSessDiag objects MUST be identical."

It should say:

bfdSessUp NOTIFICATION-TYPE
     OBJECTS {
         bfdSessDiag, -- low range value
         bfdSessDiag  -- high range value
     }
     STATUS     current
     DESCRIPTION
         "This notification is generated when the
          bfdSessState object for one or more contiguous
          entries in bfdSessTable are about to enter the up(4)
          state from some other state.  The current values of
          bfdSessDiag MUST be included. The two instances of
          bfdSessDiag in this notification indicate the range
          of indexes that are affected.  Note that all the indexes
          of the two ends of the range can be derived from the
          instance identifiers of these two objects.  For the
          state from some other state.  The current values of
          bfdSessDiag MUST be included. The two instances of
          the same time, the device SHOULD issue a single
          notification for each range of contiguous indexes in
          an effort to minimize the emission of a large number
          of notifications.  If a notification has to be
          issued for just a single bfdSessEntry, then
          the instance identifier (and values) of the two
          bfdSessDiag objects MUST be identical."
     ::= { bfdNotifications 1 }

 bfdSessDown NOTIFICATION-TYPE
     OBJECTS {
         bfdSessDiag, -- low range value
         bfdSessDiag  -- high range value
     }
     STATUS     current
     DESCRIPTION
         "This notification is generated when the
          bfdSessState object for one or more contiguous
          entries in bfdSessTable are about to enter the down(2)
          or adminDown(1) states from some other state.  The current
          values of bfdSessDiag MUST be included.  The two instances
          of bfdSessDiag in this notification indicate the range
          of indexes that are affected.  Note that all the indexes
          of the two ends of the range can be derived from the
          instance identifiers of these two objects.  For
          cases where a contiguous range of sessions
          have transitioned into the down(2) or adminDown(1) states
          at roughly the same time, the device SHOULD issue a single
          notification for each range of contiguous indexes in
          an effort to minimize the emission of a large number
          of notifications.  If a notification has to be
          issued for just a single bfdSessEntry, then
          the instance identifier (and values) of the two
          bfdSessDiag objects MUST be identical."

Notes:

See discussion at https://mailarchive.ietf.org/arch/msg/rtg-bfd/TGQZeib-j2NAZL2PFPrTykfSLoE/

The changes are

OLD:
state from some other state. The included values of
bfdSessDiag MUST both be set equal to this
new state (i.e., up(4)). The two instances of

NEW:
state from some other state. The current values of
bfdSessDiag MUST be included. The two instances of

and

OLD:
or adminDown(1) states from some other state. The included
values of bfdSessDiag MUST both be set equal to this new
state (i.e., down(2) or adminDown(1)). The two instances

NEW:
or adminDown(1) states from some other state. The current
values of bfdSessDiag MUST be included. The two instances

(The up(4), down(2), and adminDown(1) states are not defined for bfdSessDiag.)

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 7344, "Automating DNSSEC Delegation Trust Maintenance", September 2014

Note: This RFC has been updated by RFC 8078, RFC 9615

Source of RFC: dnsop (ops)

Errata ID: 7997
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Casey Deccio
Date Reported: 2024-06-21
Verifier Name: Paul Wouters
Date Verified: 2024-06-25

Section 6.2.1 says:

When a Parent operates in "calculate DS" mode, it can operate in one
   of two sub-modes:

   full:  The Parent only publishes DS records it calculates from DNSKEY
      records.

It should say:

When a Parent operates in "calculate DS" mode, it can operate in one
   of two sub-modes:

   full:  The Parent only publishes DS records it calculates from CDNSKEY
      records.

Notes:

In the last sentence, "DNSKEY" should be "CDNSKEY". That is, the Parent calculates DS records from the CDNSKEY records, not from the DNSKEY records.

Paul Wouters (AD): Verifying as the regular AD is an author on the doc :)

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 7377, "IMAP4 Multimailbox SEARCH Extension", October 2014

Source of RFC: appsawg (app)

Errata ID: 8364
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2025-03-31
Verifier Name: Orie Steele
Date Verified: 2025-04-07

Section 2 says:

   C: tag1 UID ESEARCH FROM "frobozz" 1:100

   ... followed later by this:

   C: tag1 UID ESEARCH FROM "frobozz" 101:200

It should say:

   C: tag1 ESEARCH FROM "frobozz" 1:100

   ... followed later by this:

   C: tag1 ESEARCH FROM "frobozz" 101:200

Notes:

There is no "UID ESEARCH" command. The document defines the "ESEARCH" command. It is unlike the other commands with a UID and non-UID version, such as fetch, store, search, etc. Understandable, because message sequence numbers aren't returned for multimailbox search results. Just above it says: "it is worth pointing out that with ESEARCH, as with any SEARCH or UID SEARCH command", so there is no confusion about uid vs non-uid commands. The ABNF also only adds an "ESEARCH" command, not a "UID ESEARCH".

The example seems to imply message sequence numbers can be used in the search program with ESEARCH, for pagination. This can work if you know the number of messages in each mailbox you're searching. Presumably also for mailboxes that aren't selected which is what this document is about. But it doesn't make it explicit, there is no "IN (...)" in the example.

The same example is present in RFC 6237.

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.

Errata ID: 8013
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Verifier Name: RFC Editor
Date Verified: 2024-08-16

Section 4.2 says:

   PendingFastOpenRequests: tracks the number of TFO connections in SYN-
      RCVD state.  If this variable goes over a preset system limit, the
      server MUST disable TFO for all new connection requests until
      PendingFastOpenRequests drops below the system limit.  This
      variable is used for defending some vulnerabilities discussed in
      the "Security Considerations" section (Section 5).

It should say:

   PendingFastOpenRequests: tracks the number of TFO connections in SYN-
      RCVD state.  If this variable goes over a preset system limit, the
      server MUST disable TFO for all new connection requests until
      PendingFastOpenRequests drops below the system limit.  This
      variable is used for defending against some vulnerabilities 
      discussed in the "Security Considerations" section (Section 5).

Notes:

The original text seems to suggest defending (the existence of) some vulnerabilities

Errata ID: 8016
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

Section 6.3.3 says:

    <...> In fact, power has become such a prominent issue in
   modern Long Term Evolution (LTE) devices that mobile browsers close
   HTTP connections within seconds or even immediately [SOUDERS11].

It should say:

    <...> In fact, power has become such a prominent issue in
   3G mobile devices that mobile browsers close HTTP connections
   within seconds or even immediately [SOUDERS11].

Notes:

Reading the reference: It mentions 3G exclusively.
3G data networks are circuit-switched so energy consumption on idle connections is an issue.
4G/5G (LTE) networks are packet-switched, and radio energy consumption (active carrier?) might not be an issue. 4G and 5G are not mentioned in the reference.

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, RFC 9572, RFC 9573, RFC 9746

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.

Errata ID: 4980
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2017-03-24
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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: 6158
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2020-05-06
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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.

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 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: 8060
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pieter Kasselman
Date Reported: 2024-07-31
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

Section 7.2 says:

   5.   Verify that the resulting JOSE Header includes only parameters
        and values whose syntax and semantics are both understood and
        supported or that are specified as being ignored when not
        understood.

It should say:

   5.   Verify that the resulting JOSE Header according to RFC7515 or RFC7516.

Notes:

Validation step 5 in section 7.2 of RFC 7519 states that header parameters should only be ignored if they are explicitly specified as needing to be ignored.

This is contrary to step 7 in section 7.2 which requires that the processing rules of RFC 1515 be used if the JWT is a JWS (defined in RFC 1515). RFC 7515 does not include any special provisions for only ignoring header parameters if they are specified as being ignored, but instead requires all header parameters to be ignored if they are not understood (repeated below for convenience).

"Unless listed as a critical Header Parameter, per
Section 4.1.11, all Header Parameters not defined by this
specification MUST be ignored when not understood."

A discussion with the authors at IETF 120 confirmed that all header parameters that are not understood must be ignored.

The proposed errata aims to clarify that if the JWT is a JWS, the processing rules of RFC 7151 should apply (including ignoring header parameters that are not understood). This is consistent with point 7.2, which requires that RFC 7515 [JWS] rules applies and avoids the impression that a new requirement on when parameters are ignored is being introduced in (i.e. the need to be explicitly defined as needing to be ignored).

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.

Errata ID: 8105
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Ogilvie
Date Reported: 2024-09-16
Verifier Name: Deb Cooley
Date Verified: 2025-01-24

Section 3.4 says:

Examples of valid Network Access Identifiers include the following:
[...]
        \(user\)@example.net

It should say:

Examples of invalid Network Access Identifiers include the following:
[...]
        \(user\)@example.net

Notes:

\(user\)@example.net is listed as a valid example, but neither backslashes nor parentheses are allowed in the ABNF rules (sections 2.1 and 2.2). Obsoleted RFC 4282 had ABNF rules to allow for backslash escapes, but RFC 7542 does not. These are the only backslashes in the entire document.

Perhaps this example should be moved to the invalid examples list?

Or perhaps the ABNF rules should be extended to allow some forms of backslash escapes, although probably not to the same wide-open extent as RFC 4282?

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 7589, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", June 2015

Source of RFC: netconf (ops)

Errata ID: 8193
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan
Date Reported: 2024-12-01
Verifier Name: Mahesh Jethanandani
Date Verified: 2025-01-04

Section 2 says:

The well-known TCP port number 6513 is used by NETCONF servers to listen for TCP connections established by NETCONF over TLS clients.

It should say:

The registered TCP port number 6513 is used by NETCONF servers to listen for TCP connections established by NETCONF over TLS clients.

Notes:

Section 10 of that same RFC correctly states: "Per RFC 5539, IANA assigned TCP port number (6513) in the 'Registered Port Numbers' range with the service name 'netconf-tls'. This port is the default port for NETCONF over TLS, as defined in Section 2." With that said, wouldn't the sentence concerned be more correct in the suggested form? Thanks!

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: 7916
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francois LASNE
Date Reported: 2024-04-29
Verifier Name: Deb Cooley
Date Verified: 2024-05-11

Section 3.7.3 says:

 containing a human-readable explanation of the error.

   "status": "201"

   The following is an example of a status in a failed operation.

  "status": "400",
  "response":{
       "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
       "scimType":"invalidSyntax"
       "detail":
  "Request is unparsable, syntactically incorrect, or violates schema.",
       "status":"400"
   }

It should say:

 containing a human-readable explanation of the error.

 The following is an example of a status in a failed operation.

  {
     "status": "400",
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
     "scimType":"invalidSyntax",
     "detail":"Request is unparsable, syntactically incorrect, or violates schema.",
   }

Notes:

it misses a { at the beginning of the 400 sample
it missies a , after invalidSyntax

the overall response looks wrong

Notice that even putting a there can be questionnable as well , and an alternative would be to just drop the content mentionned

SecAD Summary of the changes (per the authors):
* Remove line: “status”: “201”
* Add leading brace ‘{‘
* Add missing comma after “invalidSyntax”

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.

Errata ID: 7898
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Osman Merghani Osman Elsayed
Date Reported: 2024-04-17
Verifier Name: RFC Editor
Date Verified: 2024-04-17

Section 3.12 says:

   Example of an error in response to a PUT request:

   HTTP/1.1 400 Bad Request

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
     "scimType":"mutability"
     "detail":"Attribute 'id' is readOnly",
     "status": "400"
   }

It should say:

   Example of an error in response to a PUT request:

   HTTP/1.1 400 Bad Request

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
     "scimType":"mutability",
     "detail":"Attribute 'id' is readOnly",
     "status": "400"
   }

Notes:

The response body is invalid JSON due to the missing comma after "mutability".

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 7680, "A One-Way Loss Metric for IP Performance Metrics (IPPM)", January 2016

Source of RFC: ippm (ops)

Errata ID: 8290
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pablo Navarro
Date Reported: 2025-02-09
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-28

Section 3.4. says:

At each of the selected times in this process, we obtain one value of Type-P-One-way-Delay.

It should say:

At each of the selected times in this process, we obtain one value of Type-P-One-way-Packet-Loss.

Notes:

It is not generally incorrect that a value of Type-P-One-way-Delay can be obtained at each of the selected times. However, in that case it should also be mentioned in the following sentence ("The value of the sample is the sequence made up of the resulting <time, loss> pairs"), that the loss is 0 exactly when Type-P-One-way-Delay is a finite value, and it is 1 exactly when Type-P-One-way-Delay is undefined. But, as this observation is already made for the singleton metric Type-P-One-way-Packet-Loss in section 2.5., it would be easier to directly refer to this singleton metric in section 3.4. (as suggested in this errata).

== Verifier note

Per https://mailarchive.ietf.org/arch/msg/ippm/Jh_XqG4eruyNkY3zgG8TOeVxI7E/

Errata ID: 8291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pablo Navarro
Date Reported: 2025-02-09
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-28

Section 2.8.1 says:

The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), 
port number, size, or arrangement for special treatment (e.g., IP DS Field 
[RFC2780], Explicit Congestion Notification (ECN) [RFC3168], or RSVP) changes.

It should say:

The value of Type-P-One-way-Packet-Loss could change if the protocol (UDP or 
TCP), port number, size, or arrangement for special treatment (e.g., IP DS Field 
[RFC2780], Explicit Congestion Notification (ECN) [RFC3168], or RSVP) changes.

Notes:

The original text is not incorrect and a change in Type-P-One-way-Delay could also imply a change in Type-P-One-way-Packet-Loss. Therefore, and as this section refers to the Type-P-One-way-Packet-Loss, it would be more accurate to refer to Type-P-One-way-Packet-Loss directly.

== Verifier note

Per https://mailarchive.ietf.org/arch/msg/ippm/Jh_XqG4eruyNkY3zgG8TOeVxI7E/

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 7684, "OSPFv2 Prefix/Link Attribute Advertisement", November 2015

Source of RFC: ospf (rtg)

Errata ID: 8104
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kris Michielsen
Date Reported: 2024-09-16
Verifier Name: Gunter Van de Velde
Date Verified: 2024-09-16

Section 2.1 says:

   Route Type
      The type of the OSPFv2 route.  If the route type is 0
      (Unspecified), the information inside the OSPFv2 External Prefix
      TLV applies to the prefix regardless of prefix's route type.  This
      is useful when prefix-specific attributes are advertised by an
      external entity that is not aware of the route type associated
      with the prefix.  Supported types are:

It should say:

   Route Type
      The type of the OSPFv2 route.  If the route type is 0
      (Unspecified), the information inside the OSPFv2 Extended Prefix
      TLV applies to the prefix regardless of prefix's route type.  This
      is useful when prefix-specific attributes are advertised by an
      external entity that is not aware of the route type associated
      with the prefix.  Supported types are:

Notes:

s/External Prefix/Extended Prefix/

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.

Errata ID: 7858
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Doug Gibbons
Date Reported: 2024-03-20
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

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 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 7842, "Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool", April 2016

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7938
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jean Mahoney
Date Reported: 2024-05-15
Verifier Name: RFC Editor
Date Verified: 2024-05-15

Section 1 says:

   The IETF email archive search tool, as specified in [RFC6778]) and
   available at [mailarch], has been in use for nearly two years.

It should say:

   The IETF email archive search tool, as specified in [RFC6778] and
   available at [mailarch], has been in use for nearly two years.

Notes:

There is a stray parenthesis after the cite tag.

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, RFC 9736

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: 5242
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Innokentiy Solntsev
Date Reported: 2018-01-24
Verifier Name: Eliot Lear
Date Verified: 2025-04-01

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: 6088
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Verifier Name: Eliot Lear
Date Verified: 2025-04-01

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: 8355
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Harding
Date Reported: 2025-03-28
Verifier Name: Eliot Lear
Date Verified: 2025-04-01

Section 5.6.2.4 says:

   Transmission times derived from physical interfaces MUST be n units
   of picoseconds, converted to picoseconds prior to being exchanged
   between neighbors, or used in the composite metric determination.

   This includes delay values present in configuration-based commands
   (i.e., interface delay, redistribute, default-metric, route-map,
   etc.).

   The delay value is then converted to a "latency" using the formula:

                          Delay * EIGRP_WIDE_SCALE
        Latency = K3 *   --------------------------
                             EIGRP_DELAY_PICO

It should say:

   Transmission times derived from physical interfaces MUST be n units
   of picoseconds, converted to picoseconds prior to being exchanged
   between neighbors, or used in the composite metric determination.

   This includes delay values present in configuration-based commands
   (i.e., interface delay, redistribute, default-metric, route-map,
   etc.).

   The sum of the delay values are then converted to a "latency" using the formula:

                          Delay * EIGRP_WIDE_SCALE
        Latency = K3 *   --------------------------
                             EIGRP_DELAY_PICO

Notes:

It is perhaps useful to reference the point at which the delay values should be summed.

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 7901, "CHAIN Query Requests in DNS", June 2016

Source of RFC: dnsop (ops)

Errata ID: 8053
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2024-07-27
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-07-29

Section 8.3 says:

8.3.  Nonexistent Data

   A recursive resolver receives a query for the A record for
   "ipv6.toronto.redhat.ca".  It includes the CHAIN option with the
   following parameters:

   o  Option-code, set to 13

   o  Option-length, set to 0x00 0x03

   o  The closest trust point set to "ca."

It should say:

8.3.  Nonexistent Data

   A recursive resolver receives a query for the A record for
   "ipv6.toronto.redhat.ca".  It includes the CHAIN option with the
   following parameters:

   o  Option-code, set to 13

   o  Option-length, set to 0x00 0x04

   o  The closest trust point set to "ca."

Notes:

The value of the option is 0x02 0x63 0x61 0x00 which has length 4 not 3.

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
Area Assignment: int

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

Note: This RFC has been obsoleted by RFC 9718

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 7998, ""xml2rfc" Version 3 Preparation Tool Description", December 2016

Source of RFC: IAB

Errata ID: 7169
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2022-10-16
Verifier Name: Alexis Rossi (RFC Series Approval Board Chair)
Date Verified: 2025-01-10

Section 5.5.1 says:

Note: since this feature can't be used for RFCs at the moment, this
entire feature might be

It should say:

Note: since this feature can't be used for RFCs at the moment, this
entire feature might be de-prioritized.

Notes:

RFCs do not currently use binary-art as an artwork type. An Internet
Draft may be created with binary-art as an artwork type, but that
artwork will not be published in any resulting RFC.

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
Area Assignment: art

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

Note: This RFC has been updated by RFC 9579

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.

Errata ID: 8318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roman Donchenko
Date Reported: 2025-02-28
Verifier Name: RFC Editor
Date Verified: 2025-03-07

Section A.5 says:

Examples of underlying encryption schemes are given in 
Appendix B.3.

It should say:

Examples of underlying message authentication schemes are 
given in Appendix B.3.

Notes:

The paragraph this sentence is in describes the messageAuthScheme field, and the referenced appendix covers message authentication schemes.

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 8028, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", November 2016

Source of RFC: 6man (int)

Errata ID: 7009
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-06-30
Verifier Name: Erik Kline
Date Verified: 2025-03-21

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Carpenter
Date Reported: 2022-06-30
Verifier Name: Erik Kline
Date Verified: 2025-03-21

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 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017

Note: This RFC has been updated by RFC 8611, RFC 9041, RFC 9570

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

Note: This RFC has been updated by RFC 9615

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

Note: This RFC has been updated by RFC 9672

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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 13 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”.

Errata ID: 8129
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2024-10-02
Verifier Name: RFC Editor
Date Verified: 2024-10-07

Section 1 says:

m. "Reasonably and personally known": something an individual knows

It should say:

n. "Reasonably and personally known": something an individual knows

Notes:

The list has items a through m, then m repeats, then skips directly to the final item, o. From context it’s clear the quoted item should have been n, continuing the sequence in the usual way.

RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", July 2017

Note: This RFC has been updated by RFC 9674, RFC 9697

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

Note: This RFC has been updated by RFC 9673

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: 6517
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2021-04-05
Verifier Name: Gunter Van de Velde
Date Verified: 2024-10-30

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: 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 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: 5715
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Lee
Date Reported: 2019-05-01
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Petit-Huguenin
Date Reported: 2021-03-27
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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.

See also:
- https://datatracker.ietf.org/doc/html/rfc8224#section-4.1.1
- https://datatracker.ietf.org/doc/html/rfc7515#appendix-F
- https://datatracker.ietf.org/doc/html/rfc7515#appendix-C
- https://datatracker.ietf.org/doc/html/rfc4648#section-5

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-01-21
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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 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, RFC 9753, RFC 9756

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

Note: This RFC has been updated by RFC 9756

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 8364, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", March 2018

Note: This RFC has been updated by RFC 8736, RFC 9436

Source of RFC: pim (rtg)

Errata ID: 8052
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David 'equinox' Lamparter
Date Reported: 2024-07-27
Verifier Name: Gunter Van de Velde
Date Verified: 2024-10-30

Section 4.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|         Type = 1              |          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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|         Type = 1            |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The field boundary is off by one bit in the first row of the diagram for Group Source Holdtime TLV. The bar between the Type and Length fields is supposed to be 1 bit further left, matching the 3rd row in the diagram in section 3.1.

The fact that this 1-bit-off boundary makes the type field very oddly bit-aligned will likely cause implementers to double check the two diagrams against each other and also conclude the one in 3.1 is correct. The IANA table in section 7 also has Type as a 15-bit field going up to 32767; the shift in boundary would make it a 16-bit field.

The reporting was originally done as technical errata since the text does not specify the actual encoding, the diagram is the "source" of actual encoding definition, however the errata reported is the result of a editorial table alignment glitch

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: 6821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gordon
Date Reported: 2022-01-24
Verifier Name: Nick Sullivan
Date Verified: 2025-01-18

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


Verified on CFRG list by Bas Westerbaan.

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.

Errata ID: 7900
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Çağdaş Çalık
Date Reported: 2024-04-18
Verifier Name: Colin Perkins
Date Verified: 2024-04-22

Section 4.1. says:

An XMSS private key SK contains 2^h WOTS+ private keys, the leaf
index idx of the next WOTS+ private key that has not yet been used,
SK_PRF (an n-byte key to generate pseudorandom values for randomized
message hashing), the n-byte value root (which is the root node of
the tree and SEED), and the n-byte public seed used to pseudorandomly
generate bitmasks and hash function keys.

It should say:

An XMSS private key SK contains 2^h WOTS+ private keys, the leaf
index idx of the next WOTS+ private key that has not yet been used,
SK_PRF (an n-byte key to generate pseudorandom values for randomized
message hashing), the n-byte value root (which is the root node of
the tree), and SEED (the n-byte public seed used to pseudorandomly
generate bitmasks and hash function keys).

Notes:

SEED appearing in the parenthesis explaining the root value is confusing. It has to be paired with the explanation of it that follows.

Errata verified by Andreas Hülsing, 2024-04-22

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 8409, "The Entity Category Security Assertion Markup Language (SAML) Attribute Types", August 2018

Source of RFC: INDEPENDENT

Errata ID: 8196
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean Mahoney
Date Reported: 2024-12-02
Verifier Name: Eliot Lear
Date Verified: 2024-12-06

Section 3.1 says:

It is RECOMMENDED that http:-scheme or https:-scheme URIs are used;
it is further RECOMMENDED that a category URI resolves to a human-
readable document defining the category.

It should say:

The category URI might also be a URL that resolves to a human-
readable document defining the category.  Because domain ownership
may change hands over time, implementations MUST NOT resolve the
URI for any purpose. Resolution is purely for human documentation
considerations. Even then, caution is advised when readers
click on URIs shown in this specification, just as one domain
has changed hands since its original publication.

Notes:

(Reported on behalf of Alfonso Alongi <alfonso.alongi.it@gmail.com>.
Readers are advised to not make use of macedir.org, as the domain has changed hands.

Errata ID: 8201
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean Mahoney
Date Reported: 2024-12-02
Verifier Name: Eliot Lear
Date Verified: 2024-12-06

Section 4.1 says:

It is RECOMMENDED that http:-scheme or https:-scheme URLs are used;
it is further RECOMMENDED that each such value resolves to a human-
readable document defining the value's semantics.

It should say:

Each such value might resolve to a human-readable document.  The same
precautions and restrictions about URIs discussed in the erratum to
Section 3.1 apply here as well.

Notes:

(Reported on behalf of Alfonso Alongi <alfonso.alongi.it@gmail.com>.

Errata ID: 8202
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean Mahoney
Date Reported: 2024-12-02
Verifier Name: Eliot Lear
Date Verified: 2024-12-06

Section 6 says:

(Top of Section)

It should say:

Add to top of Section 6:

Please note that the macedir.org domain used in the names of
the two SAML Attributes defined in this specification has been
taken over by a third party that is not affiliated with the
original owner of the domain at the time this specification
was authored.  As discussed in the erratum to Section 3.1, 
implementations MUST NOT attempt to resolve
those names as URLs, and readers are advised that doing so
will yield no information related to this work.

Notes:

Reported on behalf of Alfonso Alongi <alfonso.alongi.it@gmail.com>.

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: 6263
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Ireland
Date Reported: 2020-08-24
Verifier Name: Deb Cooley
Date Verified: 2024-10-30

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

Errata ID: 8297
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roman Donchenko
Date Reported: 2025-02-16
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

Section 7 says:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY------

It should say:

(re-encoded with correct attribute OID, see notes)

Notes:

This encoded private key contains an attribute with OID "1 2 840 113549 1 9 9 20", which is not assigned to anything. Likely, the intent was to use "1 2 840 113549 1 9 20" (one fewer 9), which is pkcs-9-at-friendlyName from RFC 2985.

The same private key also appears in section 10.3.

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 8460, "SMTP TLS Reporting", September 2018

Source of RFC: uta (sec)

Errata ID: 8070
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2024-08-09
Verifier Name: RFC Editor
Date Verified: 2024-08-12

Section 3 says:

A receiver MAY opt to only attempt delivery to one of the endpoints;

It should say:

The reporter MAY opt to only attempt delivery to one of the endpoints;

Notes:

The reporter is the entity that delivers the report, not the receiver.

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 8492, "Secure Password Ciphersuites for Transport Layer Security (TLS)", February 2019

Source of RFC: INDEPENDENT

Errata ID: 5727
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Freiherr von Buddenbrock
Date Reported: 2019-05-21
Verifier Name: Eliot Lear
Date Verified: 2025-03-05

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:

There is 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

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 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, RFC 9685

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 8521, "Registration Data Access Protocol (RDAP) Object Tagging", November 2018

Source of RFC: regext (art)

Errata ID: 5896
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2019-11-07
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2020-10-19
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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 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 8532, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", April 2019

Source of RFC: lime (ops)

Errata ID: 7927
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mahesh Jethanandani
Date Reported: 2024-05-07
Verifier Name: Mahesh Jethanandani
Date Verified: 2024-11-03

Section 5 says:

            reference
              "RFC 8029: Detecting Multiprotocol Label
               Switched (MPLS) Data-Plane Failures";

It should say:

            reference
              "RFC 8029: Detecting Multiprotocol Label
               Switching (MPLS) Data-Plane Failures";

Notes:

Errata 7892 is updating the title of RFC 8029. Reflecting that change here. Note, there are 10 occurrences of the string.

RFC 8536, "The Time Zone Information Format (TZif)", February 2019

Note: This RFC has been obsoleted by RFC 9636

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

Note: This RFC has been updated by RFC 9646

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 8574, "cite-as: A Link Relation to Convey a Preferred URI for Referencing", April 2019

Source of RFC: INDEPENDENT

Errata ID: 5697
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2019-04-18
Verifier Name: Eliot Lear
Date Verified: 2025-01-04

Section 6.3 says:

 type="text/ttl"/>

It should say:

>

Notes:

Media type text/ttl is not registered. The example does not require a type.

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 8584, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", April 2019

Source of RFC: bess (rtg)

Errata ID: 5900
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Lu
Date Reported: 2019-11-12
Verifier Name: Gunter Van de Velde
Date Verified: 2025-02-10

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

Errata ID: 7811
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Luc André Burdet
Date Reported: 2024-02-15
Verifier Name: Gunter Van de Velde
Date Verified: 2025-02-10

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

An observation was made while reviewing EVPN Port-Active draft pointing 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 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 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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rob Thomas
Date Reported: 2021-08-10
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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 8590, "Change Poll Extension for the Extensible Provisioning Protocol (EPP)", May 2019

Source of RFC: regext (art)

Errata ID: 8079
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben van Hartingsveldt
Date Reported: 2024-08-16
Verifier Name: RFC Editor
Date Verified: 2024-08-19

Section 5.1 says:

Registration for the changePoll XML schema:

   URI: urn:ietf:params:xml:ns:changePoll-1.0

   Registrant Contact: IESG

   XML: See the "Formal Syntax" section of this document.

It should say:

Registration for the changePoll XML schema:

   URI: urn:ietf:params:xml:schema:changePoll-1.0

   Registrant Contact: IESG

   XML: See the "Formal Syntax" section of this document.

Notes:

The wrong URN for the XML schema is written in the RFC. However, despite that, the IANA registered it correctly: https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema

RFC 8599, "Push Notification with the Session Initiation Protocol (SIP)", May 2019

Source of RFC: sipcore (art)

Errata ID: 8136
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Babar
Date Reported: 2024-10-12
Verifier Name: RFC Editor
Date Verified: 2024-10-24

Section 4.1.4 says:

Example of a SIP REGISTER response including a 'sip.pnsreg'
     media feature tag and a 'sip.pnsreq' feature-capability indicator:

If the UA receives a 2xx response to the REGISTER request that
   contains a Feature-Caps header field with a 'sip.pnsreq' feature-
   capability indicator,

If the UA receives a 2xx response to the REGISTER request that does
   not contain a Feature-Caps header field with a 'sip.pnsreq' feature-
   capability indicator,

It should say:

Example of a SIP REGISTER response including a 'sip.pnsreg'
     media feature tag and a 'sip.pnsreg' feature-capability indicator:

If the UA receives a 2xx response to the REGISTER request that
   contains a Feature-Caps header field with a 'sip.pnsreg' feature-
   capability indicator,

If the UA receives a 2xx response to the REGISTER request that does
   not contain a Feature-Caps header field with a 'sip.pnsreg' feature-
   capability indicator,

Notes:

“sip.pnsreq” should be “sip.pnsreg” in the three sentences in this report.

RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019

Note: This RFC has been updated by RFC 9682

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 8613, "Object Security for Constrained RESTful Environments (OSCORE)", July 2019

Source of RFC: core (wit)

Errata ID: 8229
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Tiloca
Date Reported: 2025-01-03
Verifier Name: RFC Editor
Date Verified: 2025-01-03

Section 7.3 says:

Note that the message binding does not guarantee that a misbehaving
server created the response before receiving the request, i.e., it
does not verify server aliveness.

It should say:

Note that the message binding does not prevent a misbehaving
server from creating the response before receiving the request, i.e.,
OSCORE does not verify server aliveness.

Notes:

The original text should have said "does not guarantee that a misbehaving server did not create", so a negation was missing. The new text addresses that, using "prevent" instead of "guarantee" in order to avoid a double negation.

RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019

Note: This RFC has been updated by RFC 9404, RFC 9670

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 8659, "DNS Certification Authority Authorization (CAA) Resource Record", November 2019

Source of RFC: lamps (sec)

Errata ID: 5934
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: IIDA Yosiaki
Date Reported: 2019-12-12
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

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 8664, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", December 2019

Note: This RFC has been updated by RFC 9756

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 8666, "OSPFv3 Extensions for Segment Routing", December 2019

Source of RFC: lsr (rtg)

Errata ID: 8319
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mohamed BOUCADAIR
Date Reported: 2025-03-02
Verifier Name: Jim Guichard
Date Verified: 2025-03-07

Section 6 says:

   Example 1: If the following router addresses (loopback addresses)
   need to be mapped into the corresponding Prefix-SID indexes:

             Router-A: 2001:DB8::1/128, Prefix-SID: Index 1
             Router-B: 2001:DB8::2/128, Prefix-SID: Index 2
             Router-C: 2001:DB8::3/128, Prefix-SID: Index 3
             Router-D: 2001:DB8::4/128, Prefix-SID: Index 4

   then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV
   would be set to 2001:DB8::1, the Prefix Length would be set to 128,
   the Range Size would be set to 4, and the Index value in the Prefix-
   SID sub-TLV would be set to 1.

   Example 2: If the following prefixes need to be mapped into the
   corresponding Prefix-SID indexes:

             2001:DB8:1::0/120,   Prefix-SID: Index 51
             2001:DB8:1::100/120, Prefix-SID: Index 52
             2001:DB8:1::200/120, Prefix-SID: Index 53
             2001:DB8:1::300/120, Prefix-SID: Index 54
             2001:DB8:1::400/120, Prefix-SID: Index 55
             2001:DB8:1::500/120, Prefix-SID: Index 56
             2001:DB8:1::600/120, Prefix-SID: Index 57

   then the Prefix field in the OSPFv3 Extended Prefix Range TLV would
   be set to 2001:DB8:1::0, the Prefix Length would be set to 120, the
   Range Size would be set to 7, and the Index value in the Prefix-SID
   sub-TLV would be set to 51.

It should say:

   Example 1: If the following router addresses (loopback addresses)
   need to be mapped into the corresponding Prefix-SID indexes:

             Router-A: 2001:db8::1/128, Prefix-SID: Index 1
             Router-B: 2001:db8::2/128, Prefix-SID: Index 2
             Router-C: 2001:db8::3/128, Prefix-SID: Index 3
             Router-D: 2001:db8::4/128, Prefix-SID: Index 4

   then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV
   would be set to 2001:db8::1, the Prefix Length would be set to 128,
   the Range Size would be set to 4, and the Index value in the Prefix-
   SID sub-TLV would be set to 1.

   Example 2: If the following prefixes need to be mapped into the
   corresponding Prefix-SID indexes:

             2001:db8:1::0/120,   Prefix-SID: Index 51
             2001:db8:1::100/120, Prefix-SID: Index 52
             2001:db8:1::200/120, Prefix-SID: Index 53
             2001:db8:1::300/120, Prefix-SID: Index 54
             2001:db8:1::400/120, Prefix-SID: Index 55
             2001:db8:1::500/120, Prefix-SID: Index 56
             2001:db8:1::600/120, Prefix-SID: Index 57

   then the Prefix field in the OSPFv3 Extended Prefix Range TLV would
   be set to 2001:DB8:1::0, the Prefix Length would be set to 120, the
   Range Size would be set to 7, and the Index value in the Prefix-SID
   sub-TLV would be set to 51.

Notes:

The OLD does not follow this recommendation from rfc5952#section-4.3

The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
MUST be represented in lowercase.

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 8678, "Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions", December 2019

Source of RFC: rtgwg (rtg)

Errata ID: 8124
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Scott Shambarger
Date Reported: 2024-09-28
Verifier Name: Jim Guichard
Date Verified: 2024-10-09

Section 6.3.2 says:

Let's consider a scenario in which all uplinks are operational, and
H41 receives two different RAs from R3: one from LLA_A with a PIO for
2001:db8:0:a020::/64 and the default router preference set to 11
(low), and another one from LLA_B with a PIO for
2001:db8:0:a020::/64, the default router preference set to 01 (high),
and a RIO for 2001:db8:0:6666::/64.  As a result, H41 uses

It should say:

Let's consider a scenario in which all uplinks are operational, and
H41 receives two different RAs from R3: one from LLA_A with a PIO for
2001:db8:0:a020::/64 and the default router preference set to 11
(low), and another one from LLA_B with a PIO for
2001:db8:0:b020::/64, the default router preference set to 01 (high),
and a RIO for 2001:db8:0:6666::/64.  As a result, H41 uses

Notes:

Minor technical fix to paragraph 2, 1st sentence: PIO of 2001:db8:0:a020::/64 is used for both LLA_A and LLA_B. Based on the remaining contents of the paragraph, the PIO of LLA_B should be 2001:db8:0:b020::/64.

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 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: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Panos Kampanakis
Date Reported: 2020-05-26
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

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: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2022-12-15
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

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: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Ireland
Date Reported: 2022-12-26
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

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 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 8708, "Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)", February 2020

Note: This RFC has been obsoleted by RFC 9708

Source of RFC: lamps (sec)

Errata ID: 7960
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2024-05-28
Verifier Name: Deb Cooley
Date Verified: 2024-05-28

Section Appendix A says:

   pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
       IDENTIFIER id-alg-hss-lms-hashsig
       KEY HSS-LMS-HashSig-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
           { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

It should say:

   pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
       IDENTIFIER id-alg-hss-lms-hashsig
       -- KEY no ASN.1 wrapping --
       PARAMS ARE absent
       CERT-KEY-USAGE
           { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

Notes:

At the time RFC 8708 was published, we did not think anyone would put an HSS/LMS public key in a certificate. We thought the public key would always be distributed by some other means. We now know that some people plan to put an HSS/LMS public key in a certificate. This part of the ASN.1 module does not come into play when using HSS/LMS in the CMS, but we want it to be consistent with the yet-to-be-published document that describes the conventions for an HSS/LMS public key in a certificate. IETF Hackathon experience shows that no ASN.1 wrapping for the public key is the way forward.

Errata ID: 7963
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2024-05-29
Verifier Name: Deb Cooley
Date Verified: 2024-05-30

Section 4 says:

      pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
          IDENTIFIER id-alg-hss-lms-hashsig
          KEY HSS-LMS-HashSig-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

      HSS-LMS-HashSig-PublicKey ::= OCTET STRING

   Note that the id-alg-hss-lms-hashsig algorithm identifier is also
   referred to as id-alg-mts-hashsig.  This synonym is based on the
   terminology used in an early draft version of the document that
   became [HASHSIG].

   The public key value is an OCTET STRING.  Like the signature format,
   it is designed for easy parsing.  The value is the number of levels
   in the public key, L, followed by the LMS public key.

It should say:

      pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
          IDENTIFIER id-alg-hss-lms-hashsig
          -- KEY no ASN.1 wrapping --
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

      HSS-LMS-HashSig-PublicKey ::= OCTET STRING

   Note that the id-alg-hss-lms-hashsig algorithm identifier is also
   referred to as id-alg-mts-hashsig.  This synonym is based on the
   terminology used in an early draft version of the document that
   became [HASHSIG].

   When the public key appears outside a certificate, it is an 
   OCTET STRING.  Like the signature format, it is designed for easy
   parsing.  The value is the number of levels in the public key, L,
   followed by the LMS public key.

Notes:

At the time RFC 8708 was published, we did not think anyone would put an HSS/LMS public key in a certificate. We thought the public key would always be distributed by some other means. We now know that some people plan to put an HSS/LMS public key in a certificate. This part of the ASN.1 module does not come into play when using HSS/LMS in the CMS, but we want it to be consistent with the yet-to-be-published document that describes the conventions for an HSS/LMS public key in a certificate. IETF Hackathon experience shows that no ASN.1 wrapping for the public key is the way forward.

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 8718, "IETF Plenary Meeting Venue Selection Process", February 2020

Note: This RFC has been updated by RFC 9712

Source of RFC: mtgvenue (gen)

Errata ID: 8372
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Scudder
Date Reported: 2025-04-03
Verifier Name: RFC Editor
Date Verified: 2025-04-08

Section 2.2 says:

   Tourism:
      Variety in site-seeing experiences.

It should say:

   Tourism:
      Variety in sightseeing experiences.

Notes:

There must be a more authoritative citation available for why it's "sightseeing" and not "site-seeing" but this was the first I came upon, and it explains it well enough. https://writingexplained.org/site-seeing-or-sightseeing

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: 7920
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Peter Patel-Schneider
Date Reported: 2024-05-02
Verifier Name: Eliot Lear
Date Verified: 2024-05-15

Section 5 says:

<end of section>

It should say:

Since -0 is a valid JSON Number but is serialized as 0, a JSON
parser following this specification SHOULD generate an error
condition (which in turn SHOULD stop processing) when it
encounters -0, in order to thwart potential attacks on not yet
parsed data. 

Notes:

IEEE 754 includes as distinct values both positive and negative
zero. Section 7.1.12.1 of ECMA-262 says: If m is +0 or -0, return
the String "0". This may lend itself to erroneous input to
supporting functions.

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

Note: This RFC has been updated by RFC 9559

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 allocated in the range 0x80 - 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 - 0x7F are not valid for use
   as Element IDs.

   Two-octet Element IDs MUST be allocated in the range 0x407F - 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 0x0100 - 0x407E and 
   0x8000 - 0xFFFF are not valid for use as Element IDs.

   Three-octet Element IDs MUST be allocated in the range 0x203FFF - 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 0x010000 - 0x203FFE and 
   0x400000 - 0xFFFFFF are not valid for use as Element IDs.

   Four-octet Element IDs MUST be allocated in the range 0x101FFFFF - 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 0x01000000 - 0x101FFFFE and 
   0x20000000 - 0xFFFFFFFF are not valid for use as Element IDs.

Notes:

This erratum corrects values in this text.

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

Note: This RFC has been updated by RFC 9659

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

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

Errata ID: 7297
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Felix Handte
Date Reported: 2023-01-03
Verifier Name: Murray Kucherawy
Date Verified: 2024-08-22

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.

[Verifier note: Confirmed with zstd developers.]

RFC 8881, "Network File System (NFS) Version 4 Minor Version 1 Protocol", August 2020

Source of RFC: nfsv4 (wit)

Errata ID: 7386
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Pali Rohár
Date Reported: 2023-03-13
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-10-30

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: 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 8888, "RTP Control Protocol (RTCP) Feedback for Congestion Control", January 2021

Source of RFC: avtcore (wit)

Errata ID: 7894
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Harald Tveit Alvestrand
Date Reported: 2024-04-16
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-05-21

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.

Errata ID: 8166
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Harald Alvestrand
Date Reported: 2024-11-04
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-12-25

Section 3.1 says:

         Following this, the report block contains a
   16-bit packet metric block for each RTP packet that has a sequence
   number in the range begin_seq to begin_seq+num_reports inclusive
   (calculated using arithmetic modulo 65536 to account for possible
   sequence number wrap-around).

It should say:

         Following this, the report block contains a
   16-bit packet metric block for each RTP packet that has a sequence
   number in the range begin_seq up to, but not including,
   begin_seq+num_reports
   (calculated using arithmetic modulo 65536 to account for possible
   sequence number wrap-around).

Notes:

The text can be read as the range being [begin_seq, begin_seq+num_reports].

If "begin_seq" is taken as the first sequence number you are reporting on, the original text means that you would have to have num_reports be 0 when you are reporting on a single packet. This seems very strange.

Alternatively, if "begin_seq" is taken as the sequence number before the one you are reporting on, the num_reports is consistent, but you are then reporting on the range <begin_seq, begin_seq+num_reports], which also seems strange.

The suggested clarification would report on the sequence [begin_seq, begin_seq + num_reports>, which seems like the most natural interpretation.

This is also consistent with the format of an empty report, which is explicit that begin_seq is the sequence number of the last RTP packet received.

RFC 8894, "Simple Certificate Enrolment Protocol", September 2020

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 8247
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Daniel Van Geest
Date Reported: 2025-01-10
Verifier Name: Deb Cooley
Date Verified: 2025-01-17

Throughout the document, when it says:

authenticated attributes

and

authenticatedAttributes

It should say:

signed attributes

and

signedAttrs

Notes:

Throughout the document it refers to "authenticated attributes" and the "authenticatedAttributes" set. However, SCEP uses the SignedData content type which doesn't have an authenticatedAttributes field (other content types do have this field, e.g. the RFC 2630 version of AuthenticatedData). It should refer to signed attributes instead. This aligns with Figure 6 which includes the signerInfo.signedAttrs field.

Note, if this errata is correct then errata 8245 is incorrect.

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.

Errata ID: 8210
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Angelica Semenec
Date Reported: 2024-12-10
Verifier Name: RFC Editor
Date Verified: 2024-12-11

Section 2.3 says:

If the key being certified allows encryption, then the CA's
CertResp will use the same certificate's public key when
encrypting the response.

It should say:

If the key being certified allows encryption, then the CA's
CertRep will use the same certificate's public key when
encrypting the response.

Notes:

There is no "CertResp" defined in the document. I believe this is supposed to be "CertRep".

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 8928, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", November 2020

Source of RFC: 6lo (int)

Errata ID: 8337
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adnan Rashid
Date Reported: 2025-03-18
Verifier Name: RFC Editor
Date Verified: 2025-03-19

Section 4.2 says:

Figure 1: Enhanced Address Registration Option

It should say:

Figure 1: Extended Address Registration Option

Notes:

E stands for Extended instead of Enhanced, as per the initial standard RFC 8505. The name should remain the same as shown in RFCs 8505, 9685, and other related RFCs.

RFC 8945, "Secret Key Transaction Authentication for DNS (TSIG)", November 2020

Source of RFC: dnsop (ops)

Errata ID: 7983
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Terts Diepraam
Date Reported: 2024-06-11
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-06-11

Section 5.2 says:

If the TSIG RR cannot be interpreted, the server MUST regard the
message as corrupt and return a FORMERR to the server.

It should say:

If the TSIG RR cannot be interpreted, the server MUST regard the
message as corrupt and return a FORMERR to the client.

Notes:

Server send an error to the client, not to itself.

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: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Scudder
Date Reported: 2023-09-22
Verifier Name: Jim Guichard
Date Verified: 2024-10-09

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 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 8972, "Simple Two-Way Active Measurement Protocol Optional Extensions", January 2021

Source of RFC: ippm (ops)

Errata ID: 8339
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2025-03-18
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-25

Section 4.7 says:

The Session-Reflector MUST validate the Length value of the STAMP test
packet.

It should say:

The Session-Reflector MUST validate the Length value of the
Follow-Up Telemetry TLV in that STAMP test packet.

Notes:

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

There is no length field discussed for the test packet. The behavior is about checking the length of a Follow-Up Telemetry TLV included in a test packet.

Errata ID: 8199
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: William Hawkins
Date Reported: 2024-12-04
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-12-04

Section 4.4 says:

Also, the Session-Reflector MUST copy the value of the DSCP and ECN
fields of the IP header of the received STAMP test packet into the
DSCP2 field in the reflected test packet.

It should say:

Also, the Session-Reflector MUST copy the value of the DSCP and ECN
fields of the IP header of the received STAMP test packet into the
DSCP2 and ECN fields, respectively, in the reflected test packet.

Notes:

First, thank you to all the IETF contributors who do such amazing work to keep the Internet going (seriously!). I noticed this minor omission while implementing the specification. I spoke with Mr. Mirsky (one of the authors) who suggested I file this report. Of course, the authors' intent is not in doubt, but he suggested that I submit this report nonetheless. Besides this very minor misstatement, as someone writing an implementation who was completely uninvolved in drafting the RFC, I have found this document to be incredibly readable and easy to follow -- thank you!

[Edit: WK (Ops AD): Thanks for the Errata (and the kind note) ].

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

Errata ID: 8269
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Martin Thomson
Date Reported: 2025-01-28
Verifier Name: Mahesh Jethanandani
Date Verified: 2025-02-01

Section 1 says:

"BRSKI", pronounced like "brewski", is a colloquial term for beer
in Canada and parts of the Midwestern United States [brewski].

It should say:

"BRSKI" is pronounced "brewski", a colloquial term for beer
in Canada and parts of the Midwestern United States [brewski].

Notes:

The original sentence structure here implies the "BRSKI" is the colloquial term.

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.

Errata ID: 7861
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mike Bishop
Date Reported: 2024-03-20
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

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 that contains a token that is
   identifiable as a Retry token, but the token is invalid or does
   not otherwise validate the client's 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.)

Also see the discusion here (https://mailarchive.ietf.org/arch/msg/quic/-NcqDysNsU7mSXhKdCdM63MLYOc/)

Errata ID: 8240
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jaikiran Pai
Date Reported: 2025-01-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

Section 12.4 says:

0x1c-0x1d   CONNECTION_CLOSE  Section 19.19  ih01  N

It should say:

0x1c-0x1d   CONNECTION_CLOSE  Section 19.19  ih01  NC

Notes:

QUIC congestion control RFC 9002 (https://www.rfc-editor.org/rfc/rfc9002) section 3 states:

"The types of frames contained in a packet affect recovery and congestion control logic:
...
Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward congestion control limits and are considered to be in flight."

So as per RFC-9002, it means that ACK and CONNECTION_CLOSE frames do not contribute to congestion control limits.

On the other hand, RFC-9000, section 12.4 has a Table 3 (https://www.rfc-editor.org/rfc/rfc9000#frame-types) which states:

"The "Spec" column in Table 3 summarizes any special rules governing the processing or generation of the frame type, as indicated by the following characters:
...
C: Packets containing only frames with this marking do not count toward bytes in flight for congestion control purposes; see [QUIC-RECOVERY]."

However, in that table, the CONNECTION_CLOSE frame isn't marked with the "C" character and only the ACK frame is. This appears to be an oversight in that table in RFC-9000.


See related discussions here ( https://mailarchive.ietf.org/arch/msg/quic/M3j4UsFxXPS6A8EX1d2zW_ZQrMQ/ )

Errata ID: 7365
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: yongboy
Date Reported: 2023-02-23
Verifier Name: Francesca Palombini
Date Verified: 2024-10-30

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

Note: This RFC has been updated by RFC 9685

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.

Errata ID: 8030
Status: Verified
Type: Editorial
Publication Format(s) : PDF
Reported By: David Harris
Date Reported: 2024-07-14
Verifier Name: RFC Editor
Date Verified: 2024-07-15

Section 6.3.10 says:

The client is designed so that it keeps two 'Deleted Items' mailboxes,
one for each namespace

C: A005 CREATE "Delete Items"
S: A005 OK CREATE command completed
C: A006 CREATE "#mh/Deleted Items"
S: A006 OK CREATE command completed

It should say:

The client is designed so that it keeps two 'Deleted Items' mailboxes,
one for each namespace

C: A005 CREATE "Deleted Items"
S: A005 OK CREATE command completed
C: A006 CREATE "#mh/Deleted Items"
S: A006 OK CREATE command completed

Notes:

Simple typographic error in mailbox name. "Delete Items" should be "Deleted Items".

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: 7093
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Scott Hollenbeck
Date Reported: 2022-08-17
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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

Errata ID: 7986
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gavin Brown
Date Reported: 2024-06-12
Verifier Name: Orie Steele
Date Verified: 2024-06-13

Section 9 says:

The following is an elided example of an entity truncated data.

{
  "objectClassName" : "entity",
  "handle" : "ANENTITY",
  "roles" : [ "registrant" ],
  ...
  "entities" :
  [
    {
      "objectClassName" : "entity",
      "handle": "ANEMBEDDEDENTITY",
      "roles" : [ "technical" ],
      ...
    },
    ...
  ],
  "networks" :
  [
    ...
  ],
  ...
  "remarks" :
  [
    {
      "title" : "Data Policy",
      "type" : "object truncated due to unexplainable reason",
      "description" :
      [
        "Some of the data in this object has been removed."
      ],
      "links" :
      [
        {
          "value" : "https://example.net/help",
          "rel" : "alternate",
          "type" : "text/html",
          "href" : "https://www.example.com/data_policy.html"
        }
      ]
    }
  ]
}

It should say:

The following is an elided example of an entity truncated data.

{
  "rdapConformance" :
  [
    "rdap_level_0"
  ],
  "objectClassName" : "entity",
  "handle" : "ANENTITY",
  "roles" : [ "registrant" ],
  ...
  "entities" :
  [
    {
      "objectClassName" : "entity",
      "handle": "ANEMBEDDEDENTITY",
      "roles" : [ "technical" ],
      ...
    },
    ...
  ],
  "networks" :
  [
    ...
  ],
  ...
  "remarks" :
  [
    {
      "title" : "Data Policy",
      "type" : "object truncated due to unexplainable reason",
      "description" :
      [
        "Some of the data in this object has been removed."
      ],
      "links" :
      [
        {
          "value" : "https://example.net/help",
          "rel" : "alternate",
          "type" : "text/html",
          "href" : "https://www.example.com/data_policy.html"
        }
      ]
    }
  ]
}

Notes:

RFC 9083 4.1 states that the rdapConformance data structure MUST appear in the topmost JSON object of RDAP responses. The example error response provided in Figure 33 should include the rdapConformance property but does not.

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.

Errata ID: 8268
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Sergey Kandaurov
Date Reported: 2025-01-28
Verifier Name: RFC Editor
Date Verified: 2025-02-06

Section B.2 says:

The priority of the absolute form of the request URI over the Host
header field by origin servers has been made explicit to align with
proxy handling. (Section 7.2)

It should say:

Notes:

This text should be in RFC 9112, Appendix C.3 instead.

After the referred text was moved between RFC-to-be 9110 and 9112 [1], this item from "Changes from 7230" was not caught up.

[1] https://github.com/httpwg/http-core/commit/e47483b5

See also https://www.rfc-editor.org/errata/eid8268.

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

Errata ID: 8284
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Julian Reschke
Date Reported: 2025-02-06
Verifier Name: RFC Editor
Date Verified: 2025-02-06

Section C.3 says:

It should say:

   The priority of the absolute form of the request URI over the Host
   header field by origin servers has been made explicit to align with
   proxy handling. (Section 3.2.2)

Notes:

This text should be added after the second paragraph.

After the referred text was moved between RFC-to-be 9110 and 9112 [1], this item from "Changes from 7230" was not caught up.

[1] https://github.com/httpwg/http-core/commit/e47483b5

See also https://www.rfc-editor.org/errata/eid8268 for the erratum in RFC 9110 (ack Sergey Kandaurov)

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: 7702
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Lucas Pardue
Date Reported: 2023-11-15
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19

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 types of frame
   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

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
Area Assignment: sec

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 9132, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", September 2021

Source of RFC: dots (sec)

Errata ID: 7058
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jan Lindblad
Date Reported: 2022-07-29
Verifier Name: Deb Cooley
Date Verified: 2024-05-02

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 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 9141, "Updating References to the IETF FTP Service", November 2021

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 8036
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Kesara Rathnayake
Date Reported: 2024-07-17
Verifier Name: RFC Editor
Date Verified: 2024-07-25

Section 3.2 says:

NEW:

Those archives are located
 at https://www.ietf.org/ietf-ftp/ietf-⁠mail-archive/.

It should say:

NEW:

Those archives are located
 at https://www.ietf.org/ietf-ftp/ietf-mail-archive/.

Notes:

There's a word joiner (WJ) (U+2060) between "ietf-" and "mail-archive/" in the URL which translates to https://www.ietf.org/ietf-ftp/ietf-%E2%81%A0mail-archive/

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 9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", April 2022

Source of RFC: tls (sec)

Errata ID: 8100
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Benjamin
Date Reported: 2024-09-12
Verifier Name: RFC Editor
Date Verified: 2024-09-13

Section 4.1 says:

   *  If the first byte is alert(21), handshake(22), or ack(proposed,
      26), the record MUST be interpreted as a DTLSPlaintext record.

It should say:

   *  If the first byte is alert(21), handshake(22), or ack(26), the
      record MUST be interpreted as a DTLSPlaintext record.

Notes:

This appears to be a remnant from before the codepoint was officially allocated.

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 9167, "Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)", December 2021

Source of RFC: regext (art)

Errata ID: 7176
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stéphane Bortzmeyer
Date Reported: 2022-10-21
Verifier Name: Orie Steele
Date Verified: 2024-11-15

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

Errata ID: 7790
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Neil Madden
Date Reported: 2024-01-30
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2024-04-27

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.

Errata ID: 7934
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Raul Siles
Date Reported: 2024-05-12
Verifier Name: Nick Sullivan
Date Verified: 2025-01-18

Sections 5.1 and 7.2.1 say:

- Section 5.1:

The psk and psk_id fields MUST appear together or not at all.

The psk, psk_id, and info fields have maximum lengths that depend
on the KDF itself,...

- Section 7.2.1:

The following table lists the maximum allowed lengths of these
fields for the KDFs defined in this document,...

It should say:

- Section 5.1:

[Add a new note]

The info parameter used by HPKE is not related to the optional
string info used by the LabeledExpand or Expand functions detailed
in section 4.

The psk and psk_id parameters MUST appear together or not at all.

The psk, psk_id, and info parameters have maximum lengths that depend
on the KDF itself,...

- Section 7.2.1:

The following table lists the maximum allowed lengths of these
parameters for the KDFs defined in this document,...

Notes:

The reference to the "info" parameter in sections 5.1 and 7.2.1 might be confusing. Thus, I suggest to clearly differentiate between the optional string "info" for the LabeledExpand or Expand functions, whose value is clearly defined by the RFC for each LabeledExpand function used in DHKEM or KeySchedule, and the "info" parameter used by HPKE.

Verified by co-author on CFRG list with additional note: Moreover, I would change all instances of "field" to "parameter", except for those referring to a mathematical field (e.g., "field element").

It seems section 7.2.1 refers to the "info" parameter used by HPKE, as it is referenced from section 5.1. This is the "info" parameter that is used specifically as the key for the "info_hash" LabeledExtract function in KeySchedule.

In section 5.1 the third bullet refer to the HPKE "info" parameter, but the 3rd paragraph after the bullets, as it uses the term "fields", might be confused with the "info" string (or field) used by the LabeledExpand and Expand functions.

Perhaps it would be useful to always use two separate terms along RFC 9180:
- the "info" parameter used by HPKE.
- the "info" string used by the LabeledExpand and Expand functions.

As a result, I would remove the term "field(s)" from sections 5.1 and 7.2.1, and replace it by parameter(s).

Additionally, I suggest to add a note in section 5.1 to differentiate both, and clarify that section 5.1 and 7.2.1, with the input length restrictions, refer to the "info" parameter, and not to the "info" string.


Verified on CFRG list by co-author with additional note: Moreover, I would change all instances of "field" to "parameter", except for those referring to a mathematical field (e.g., "field element").

Errata ID: 7937
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-13
Verifier Name: Nick Sullivan
Date Verified: 2025-01-18

Section 7.1.3 says:

For X25519 and X448, the DeriveKeyPair() function applies 
a KDF to the input:

<function()>

It should say:

For X25519 and X448, the DeriveKeyPair() function applies 
a KDF to the input:

<function()>

The suite_id used implicitly in LabeledExtract() and LabeledExpand()
for DeriveKeyPair(ikm) is derived from the KEM identifier of the 
DHKEM in use (see Section 7.1), that is, based on the type of key 
pair been generated for that DHKEM type.

Notes:

RFC 9180 dos not specify all the internal values for LabeledExtract(…) and LabeledExpand(…) for DeriveKeyPair(ikm), specifically the suite_id value. These values are required to standardise the DeriveKeyPair(ikm) function, as it is reference in other IETF drafts, such as https://www.ietf.org/archive/id/draft-westerbaan-cfrg-hpke-xyber768d00-02.html#name-derivekeypair-2, and because it is also used in the RFC 9180 KATs: see Appendix A.


Verified on CFRG list by co-author with notes: I looked at MLSpp and mls-rs, and both of those implementations compute `suite_id`, and they both do it in the way this erratum suggests. And since they interoperate with a bunch of other MLS stacks (including on HPKE), I assume this is how people are reading what's there now. But it would be good to be explicit.

Errata ID: 7932
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Raul Siles
Date Reported: 2024-05-10
Verifier Name: RFC Editor
Date Verified: 2024-05-14

Section 5.2 says:

(In the pseudocode below,

It should say:

(In the pseudocode above,

Notes:

The Context<ROLE>.IncrementSeq() pseudocode has already been provided before the last paragraph of section 5.2.

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 9239, "Updates to ECMAScript Media Types", May 2022

Source of RFC: dispatch (art)

Errata ID: 8041
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Thomas Broyer
Date Reported: 2024-07-22
Verifier Name: RFC Editor
Date Verified: 2024-07-25

Section 4 says:

Source goal sources SHOULD be encoded as UTF-8

It should say:

Script goal sources SHOULD be encoded as UTF-8

Notes:

Section 3 says there are only two goals: Module and Script. That "Source goal" is a typo and should read "Script goal".

RFC 9242, "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", May 2022

Source of RFC: ipsecme (sec)

Errata ID: 8213
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Valery Smyslov
Date Reported: 2024-12-18
Verifier Name: RFC Editor
Date Verified: 2024-12-18

Section 3.3.2 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
   |                       IKE SA Initiator's SPI                  | | |
   |                                                               | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
   |                       IKE SA Responder's SPI                  | K |
   |                                                               | E |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     | H |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
   |                          Message ID                           | r A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                       Adjusted Length                         | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
   |                                                               |   |
   ~                 Unencrypted payloads (if any)                 ~   |
   |                                                               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
   | Next Payload  |C|  RESERVED   |    Adjusted Payload Length    | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
   |                                                               | |
   ~                     Initialization Vector                     ~ E
   |                                                               | E
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
   |                                                               | r |
   ~             Inner payloads (not yet encrypted)                ~   P
   |                                                               | P |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
   |              Padding (0-255 octets)           |  Pad Length   | d
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                               | |
   ~                    Integrity Checksum Data                    ~ |
   |                                                               | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
   |                       IKE SA Initiator's SPI                  | | |
   |                                                               | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
   |                       IKE SA Responder's SPI                  | K |
   |                                                               | E |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     | H |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
   |                          Message ID                           | r A
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                       Adjusted Length                         | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
   |                                                               |   |
   ~                 Unencrypted payloads (if any)                 ~   |
   |                                                               |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
   | Next Payload  |C|  RESERVED   |    Adjusted Payload Length    | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
   |                                                               | |
   ~                     Initialization Vector                     ~ E
   |                                                               | n
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
   |                                                               | r |
   ~             Inner payloads (not yet encrypted)                ~   P
   |                                                               | P |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
   |              Padding (0-255 octets)           |  Pad Length   | d
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                               | |
   ~                    Integrity Checksum Data                    ~ |
   |                                                               | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v

Notes:

Typo in the figure: the vertical sidebar right to the Encrypted Payload should be marked as "Encr pld", currently it is marked "EEcr pld".

RFC 9250, "DNS over Dedicated QUIC Connections", May 2022

Source of RFC: dprive (int)

Errata ID: 7883
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Lyra Naeseth
Date Reported: 2024-04-05
Verifier Name: Eric Vyncke
Date Verified: 2024-04-23

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.

-- Verifier (Eric Vyncke) note --

The short discussion on the DPRIVE WG list has indicated that 2 authors are in favour of verifying this errata.

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.

Errata ID: 7652
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2023-09-22
Verifier Name: Gunter Van de Velde
Date Verified: 2024-05-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: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ketan Talaulikar
Date Reported: 2024-02-20
Verifier Name: Gunter Van de Velde
Date Verified: 2024-05-22

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

Errata ID: 7852
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Tüxen
Date Reported: 2024-03-15
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

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 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: 7143
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2022-10-03
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-27

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

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 9293, "Transmission Control Protocol (TCP)", August 2022

Source of RFC: tcpm (wit)

Errata ID: 8167
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2024-11-04
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19

Section 3.10.7.3 says:

o  A potential blind reset attack is described in RFC 5961 [9].
            The mitigation described in that document has specific
            applicability explained therein, and is not a substitute for
            cryptographic protection (e.g., IPsec or TCP-AO).  A TCP
            implementation that supports the mitigation described in RFC
            5961 SHOULD first check that the sequence number exactly
            matches RCV.NXT prior to executing the action in the next
            paragraph.

It should say:

[ The text is removed - see notes]

Notes:

This entire bullet is removed as RFC 5961 adds no rules to the handling
of RST segments in the SYN-SENT state.

See the discussion here (https://mailarchive.ietf.org/arch/msg/tcpm/Y5feX5f1YA00gCUyb4yP4iNfdXs/)

Errata ID: 8171
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2024-11-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

Section Appendix B says:

    +-----------------+---------+------+--------+-----+--------+------+
    | *  Dest Unreach | SHLD-25 |  X   |        |     |        |      |
    |    (0,1,5) =>   |         |      |        |     |        |      |
    |    inform ALP   |         |      |        |     |        |      |
    +-----------------+---------+------+--------+-----+--------+------+

It should say:

    +-----------------+---------+------+--------+-----+--------+------+
    | *  Dest Unreach | SHLD-25 |      |   X    |     |        |      |
    |    (0,1,5) =>   |         |      |        |     |        |      |
    |    inform ALP   |         |      |        |     |        |      |
    +-----------------+---------+------+--------+-----+--------+------+

Notes:

This requirement has an X in the "MUST" column, but the X should be in the "SHOULD" column.

The relevant text for this requirement is "a TCP implementation ... SHOULD make the information available to the application (SHLD-25)."

Errata ID: 8126
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: zhihua.li
Date Reported: 2024-10-01
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

Section 3.3.1 says:

the sequence space labeled 3 in Figure 3

It should say:

the sequence space labeled 2 and 3 in Figure 3

Notes:

In Figure 3, the send window shoud be 2(sequence numbers of unacknowledged data) and 3(sequence numbers allowed for new data transmission).

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 9312, "Manageability of the QUIC Transport Protocol", September 2022

Source of RFC: quic (wit)

Errata ID: 7996
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: No No
Date Reported: 2024-06-20
Verifier Name: RFC Editor
Date Verified: 2024-06-21

Section 2.1 and 8 says:

Operators should expect to observe packets with other version numbers 
as a result of various Internet experiments, future standards, and 
greasing [RFC7801].

...

[RFC7801]
Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", 
RFC 7801, DOI 10.17487/RFC7801, March 2016, 
<https://www.rfc-editor.org/info/rfc7801>

It should say:

Operators should expect to observe packets with other version numbers 
as a result of various Internet experiments, future standards, and 
greasing [RFC8701].

...

[RFC 8701]
Benjamin, D.,"Applying Generate Random Extensions And Sustain 
Extensibility (GREASE) to TLS Extensibility", RFC 8701, 
DOI 10.17487/RFC8701, January 2020, 
<https://www.rfc-editor.org/info/rfc8701>.

Notes:

Typo, should be RFC8701 instead of RFC7801

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 9321, "Signature Validation Token", October 2022

Source of RFC: INDEPENDENT

Errata ID: 7299
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stefan Santesson
Date Reported: 2023-01-04
Verifier Name: Eliot Lear
Date Verified: 2024-11-01

Section Various 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 9328, "RTP Payload Format for Versatile Video Coding (VVC)", December 2022

Source of RFC: avtcore (wit)

Errata ID: 8111
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Magnus Westerlund
Date Reported: 2024-09-20
Verifier Name: RFC Editor
Date Verified: 2024-09-23

Section 4.3.3 says:

The FU header consists of an S bit, an E bit, an R bit, and a 5-bit
   FuType field, as shown in Figure 10.

It should say:

The FU header consists of an S bit, an E bit, an P bit, and a 5-bit
   FuType field, as shown in Figure 10.

Notes:

The figure 10 and the explanation to Figure 10 calls it the P bit:


+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|P| FuType |
+---------------+

Figure 10: The Structure of the FU Header

The semantics of the FU header fields are as follows:

S: 1 bit
When set to 1, the S bit indicates the start of a fragmented NAL
unit, i.e., the first byte of the FU payload is also the first
byte of the payload of the fragmented NAL unit. When the FU
payload is not the start of the fragmented NAL unit payload, the S
bit MUST be set to 0.

E: 1 bit
When set to 1, the E bit indicates the end of a fragmented NAL
unit, i.e., the last byte of the payload is also the last byte of
the fragmented NAL unit. When the FU payload is not the last
fragment of a fragmented NAL unit, the E bit MUST be set to 0.

P: 1 bit
When set to 1, the P bit indicates the last FU of the last VCL NAL
unit of a coded picture, i.e., the last byte of the FU payload is
also the last byte of the last VCL NAL unit of the coded picture.
When the FU payload is not the last fragment of the last VCL NAL
unit of a coded picture, the P bit MUST be set to 0.

Errata ID: 8162
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Carlos Falgueras García
Date Reported: 2024-10-31
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19

Section 4.3.1 says:

   A single NAL unit packet contains exactly one NAL unit and consists
   of a payload header, as defined in Table 5 of [VVC]

It should say:

   A single NAL unit packet contains exactly one NAL unit and consists
   of a payload header, as defined in Section 7.3.1.2 of [VVC]

Notes:

Table 5 of T-REC-H.266-202309 lists NAL unit type codes, but the text here discusses the NAL unit header format, which is defined in Section 7.3.1.2.

The same happens in sections 4.3.2 and 4.3.3.

RFC 9347, "Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)", January 2023

Source of RFC: ipsecme (sec)

Errata ID: 8042
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Antony Antony
Date Reported: 2024-07-22
Verifier Name: Paul Wouters
Date Verified: 2024-07-23

Section 7.2 says:

3-255 	Reserved

It should say:

2-255 	Unassigned

Notes:

The same section, in the previous line, states "1 Congestion Control Format RFC 9347" so 2 is not covered in the registry. It's likely meant to be "Unassigned"?

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 9359, "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", April 2023

Source of RFC: ippm (ops)

Errata ID: 7901
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Loa Andersson
Date Reported: 2024-04-19
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-28

Throughout the document, when it says:

Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities

It should say:

Echo Request/Reply for Enabled In Situ Operation, Administration,
and Maintenance (IOAM) Capabilities

Notes:

Neither OAM nor IOAM are well-known and need to be expanded at first use, this is the title so this is the first occurrence.

== Verifier note

The change is also consistent with the use in RFC 9486, RFC 9378, RFC 9322, RFC 9326, RFC 9197, etc.

Errata ID: 7902
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Loa Andersson
Date Reported: 2024-04-19
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-27

Throughout the document, when it says:

   Abstract
   
   This document describes a generic format for use in echo request/
   reply mechanisms, which can be used within an IOAM-Domain, allowing
   the IOAM encapsulating node to discover the enabled IOAM capabilities
   of each IOAM transit and IOAM decapsulating node.  The generic format
   is intended to be used with a variety of data planes such as IPv6,
   MPLS, Service Function Chain (SFC), and Bit Index Explicit
   Replication (BIER).

It should say:

   Abstract

   This document describes a generic format for use in echo request/
   reply mechanisms, which can be used within an In Situ Operations, 
   Administration, and Maintenance (IOAM) domain (called, IOAM-Domain), 
   allowing the IOAM encapsulating node to discover the enabled IOAM 
   capabilities of each IOAM transit and IOAM decapsulating node. 
   The generic format is intended to be used with a variety of data
   planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit
   Index Explicit Replication (BIER).

Notes:

The Abstract is considered stand-alone, and any not well-known abbreviations need to be
expanded.
Note: I'm uncertain about the placement of the "hyphen" and the parenthesis in
"In Situ Operations, Administration, and Maintenance (IOAM)-Domain"

== Verifier note

Went with "(called, IOAM-Domain)" hack to maintain the OLD intent.

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"

Errata ID: 8140
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Schinazi
Date Reported: 2024-10-14
Verifier Name: RFC Editor
Date Verified: 2024-10-24

Section 10 says:

In addition, the use of an encrypted DNS mechanism, such as DNS over
TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC9230], hides the name
resolution traffic, which is usually a first step in fetching remote
logotype objects.

It should say:

In addition, the use of an encrypted DNS mechanism, such as DNS over
TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC8484], hides the name
resolution traffic, which is usually a first step in fetching remote
logotype objects.

Notes:

RFC 9399 mentions DNS over HTTPS (DoH) in an example. For this purpose it
includes an informative reference for DoH. Except the reference is wrong.
RFC 9399 incorrectly references RFC 9230 (ODoH) instead of RFC 8484 (DoH).

RFC 9413, "Maintaining Robust Protocols", June 2023

Source of RFC: IAB

Errata ID: 8379
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ben Kallus
Date Reported: 2025-04-12
Verifier Name: RFC Editor
Date Verified: 2025-04-16

Section 2 says:

This scenario excludes those cases where a the specification explicitly
defines how a faulty message is handled.

It should say:

This scenario excludes those cases where the specification explicitly
defines how a faulty message is handled.

Notes:

Typo fix.

RFC 9420, "The Messaging Layer Security (MLS) Protocol", July 2023

Source of RFC: mls (sec)

Errata ID: 8031
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Stefan Schaubeck
Date Reported: 2024-07-15
Verifier Name: RFC Editor
Date Verified: 2024-07-15

Section 7.9 says:

   The parent_hash field in ParentHashInput captures
   information about the nodes above P. the original_sibling_tree_hash
   captures ...

It should say:

   The parent_hash field in ParentHashInput captures
   information about the nodes above P. The original_sibling_tree_hash
   captures ...

Notes:

capital letter needed for first word of second sentence (i.e., "The" not "the").

RFC 9421, "HTTP Message Signatures", February 2024

Source of RFC: httpbis (wit)

Errata ID: 8103
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Takahiko Kawasaki
Date Reported: 2024-09-15
Verifier Name: Francesca Palombini
Date Verified: 2024-10-29

Section 7.5.3 says:

Several parts of this specification rely on the parsing of Structured
Field values [STRUCTURED-FIELDS] -- in particular, strict
serialization of HTTP Structured Field values (Section 2.1.1),
referencing members of a Dictionary Structured Field (Section 2.1.2),
and processing the @signature-input value when verifying a signature
(Section 3.2).  While Structured Field values are designed to be
relatively simple to parse, a naive or broken implementation of such
a parser could lead to subtle attack surfaces being exposed in the
implementation.

For example, if a buggy parser of the @signature-input value does not
enforce proper closing of quotes around string values within the list
of component identifiers, an attacker could take advantage of this
and inject additional content into the signature base through
manipulating the Signature-Input field value on a message.

It should say:

Several parts of this specification rely on the parsing of Structured
Field values [STRUCTURED-FIELDS] -- in particular, strict
serialization of HTTP Structured Field values (Section 2.1.1),
referencing members of a Dictionary Structured Field (Section 2.1.2),
and processing the @signature-params value when verifying a signature
(Section 3.2).  While Structured Field values are designed to be
relatively simple to parse, a naive or broken implementation of such
a parser could lead to subtle attack surfaces being exposed in the
implementation.

For example, if a buggy parser of the @signature-params value does not
enforce proper closing of quotes around string values within the list
of component identifiers, an attacker could take advantage of this
and inject additional content into the signature base through
manipulating the Signature-Input field value on a message.

Notes:

"@signature-input" should be changed to "@signature-params". There is one such error in both the first and second paragraphs of Section 7.5.3.

Errata ID: 8102
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Takahiko Kawasaki
Date Reported: 2024-09-15
Verifier Name: Francesca Palombini
Date Verified: 2024-10-29

Section 7.2.8 says:

"@status": 200
"content-digest": \
  sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-input": ("@status" "content-digest")

It should say:

"@status": 200
"content-digest": \
  sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-params": ("@status" "content-digest")

Notes:

"@signature-input" should be changed to "@signature-params".

RFC 9424, "Indicators of Compromise (IoCs) and Their Role in Attack Defence", August 2023

Source of RFC: opsec (ops)

Errata ID: 7964
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Andrew Shaw
Date Reported: 2024-05-30
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-06-05

Section 3.2.3 says:

At its simplest, this indicates that
   the receiver may share with anyone (TLP:CLEAR), share within the
   defined sharing community (TLP:GREEN), share within their
   organisation and their clients (TLP:AMBER+STRICT), share just within
   their organisation (TLP:AMBER), or not share with anyone outside the
   original specific IoC exchange (TLP:RED).

It should say:

At its simplest, this indicates that
   the receiver may share with anyone (TLP:CLEAR), share within the
   defined sharing community (TLP:GREEN), share within their
   organisation and their clients (TLP:AMBER), share just within
   their organisation (TLP:AMBER+STRICT), or not share with anyone 
   outside the original specific IoC exchange (TLP:RED).

Notes:

The definitions of TLP:AMBER and TLP:AMBER+STRICT are the wrong way round in the original text.

RFC 9435, "Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP)", July 2023

Source of RFC: tsvwg (wit)

Errata ID: 8081
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Angelos Vassiliou
Date Reported: 2024-08-17
Verifier Name: RFC Editor
Date Verified: 2024-08-20

Section 1 says:

A common set of DSCPs are defined for both IPv4 and IPv6

It should say:

A common set of DSCPs is defined for both IPv4 and IPv6

Notes:

The subject of the sentence ("A common set") is singular, but the verb is plural.

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 9483, "Lightweight Certificate Management Protocol (CMP) Profile", November 2023

Source of RFC: lamps (sec)

Errata ID: 7833
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David von Oheimb
Date Reported: 2024-03-01
Verifier Name: Deb Cooley
Date Verified: 2024-11-26

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.

Errata ID: 8183
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rajeev Ranjan
Date Reported: 2024-11-20
Verifier Name: Deb Cooley
Date Verified: 2024-11-21

Section 4.1.6.1 says:

              rid             REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the rKeyId choice, and the
    --   subjectKeyIdentifier MUST equal the senderKID in the
    --   PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used.

It should say:

              rid             REQUIRED	
-- MUST contain the subjectKeyIdentifier of the CMP protection
--   certificate of the request message, if available. The
--   subjectKeyIdentifier is equal the senderKID in the
--   PKIHeader of that message.
-- If the CMP protection certificate of the request message does
--   not contain a subjectKeyIdentifier, the issuerAndSerialNumber
--   choice MUST be used.

Notes:

1. rKeyId choice is wrongly used here as Section 6.2.1 of RFC 5652 does not have rKeyId choice.
2. rid value must be taken from CMP protection certificate of request message as it is used to specify the recipient.

Errata ID: 8184
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rajeev Ranjan
Date Reported: 2024-11-20
Verifier Name: Deb Cooley
Date Verified: 2024-11-21

Section 4.1.6.2 says:

          rid           REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
--   certificate, if available, in the rKeyId choice, and the
--   subjectKeyIdentifier MUST equal the senderKID in the
--   PKIHeader.
-- If the CMP protection certificate does not contain a
--   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
--   be used

It should say:

          rid           REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
--   certificate of the request message, if available, in the
--   rKeyId choice. The subjectKeyIdentifier is equal
--   the senderKID in the PKIHeader of that message.
-- If the CMP protection certificate of the request message does
--   not contain a subjectKeyIdentifier, the issuerAndSerialNumber
--   choice MUST be used.

Notes:

1. rid value must be taken from CMP protection certificate of request message as it is used to identify the recipient using key agreement.
2. senderKID refer to value in request message, and here we are preparing the response message. So MUST is removed.

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

Errata ID: 8020
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Thomas Graf
Date Reported: 2024-07-06
Verifier Name: Mahesh Jethanandani
Date Verified: 2024-07-11

Section A.2 says:

Figure 7:

   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 = 24          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 259         |        Field Count = 3        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |0| srhActiveSegmentIPv6 = 495  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Scope 1 Field Length = 4    |0|srhSegmentIPv6End.Behav = 502|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 1        |0|srhSegmentIPv6Lo.Length = 501|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |           Padding             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8:

 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 = 259          |           Length = 28         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               srhActiveSegmentIPv6 = 2001:db8::1              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End [1]                      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               srhActiveSegmentIPv6 = 2001:db8::4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End with NEXT-CSID [43]      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               srhActiveSegmentIPv6 = 2001:db8::6              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End.DX6 [16]                 |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

Figure 7:

 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 = 24          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 259         |        Field Count = 3        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |0|     srhSegmentIPv6 = 494    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Scope 1 Field Length = 4    |0|srhSegmentIPv6End.Behav = 502|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 1        |0|srhSegmentIPv6Lo.Length = 501|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |           Padding             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 8:

 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 = 259          |           Length = 28         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  srhSegmentIPv6 = 2001:db8::1                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End [1]                      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  srhSegmentIPv6 = 2001:db8::4                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End with NEXT-CSID [43]      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  srhSegmentIPv6 = 2001:db8::6                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|srhSegmentIPv6EndpointBehavior |srhSegmentIPv6LocatorLength= 48|
|= End.DX6 [16]                 |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Example in Appendix A.2 should state IE494 srhSegmentIPv6 instead of IE495 srhActiveSegmentIPv6 for mapping the IE510 srhSegmentIPv6LocatorLength and IE502 srhSegmentIPv6EndpointBehavior in IPFIX option-template as described in Section 6.2.

Errata has been reported to me by a software developer of a major vendor working on implementation.

Also, the first two lines of Figure 7 are two characters to the right from the correct place. This was reported by Carsten Bormann.

RFC 9493, "Subject Identifiers for Security Event Tokens", December 2023

Source of RFC: secevent (sec)

Errata ID: 7727
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Atul Tulshibagwale
Date Reported: 2023-12-11
Verifier Name: Paul Wouters
Date Verified: 2024-04-29

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/

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 9520, "Negative Caching of DNS Resolution Failures", December 2023

Source of RFC: dnsop (ops)

Errata ID: 7838
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Xiang Li
Date Reported: 2024-03-06
Verifier Name: Mohamed Boucadair
Date Verified: 2025-03-27

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

====Verifier Note=====

The link was valid at the time of publication. However, given that this document provides useful information about an attack discussed in the Security Considerations of RFC9520, the report is marked as Verified.

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 9530, "Digest Fields", February 2024

Source of RFC: httpbis (wit)

Errata ID: 8158
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Hugo Gonzalez Labrador
Date Reported: 2024-10-24
Verifier Name: Francesca Palombini
Date Verified: 2024-10-29

Section B.2 says:

Figure 14: Response with Both Content-Digest
 and Digest (Empty Content)

It should say:

Figure 14: Response with Both Content-Digest 
 and Repr-Digest (Empty Content)

Notes:

Minor Editorial correction

Errata ID: 8273
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, HTML
Reported By: Lucas Pardue
Date Reported: 2025-01-30
Verifier Name: RFC Editor
Date Verified: 2025-02-06

Section Appendix A says:

These examples a not exhaustive.

It should say:

These examples are not exhaustive.

Notes:

This is a simple grammatical editorial issue.

RFC 9535, "JSONPath: Query Expressions for JSON", February 2024

Source of RFC: jsonpath (art)

Errata ID: 8343
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Vladimír Gorej
Date Reported: 2025-03-24
Verifier Name: Andy Newton
Date Verified: 2025-03-27

Section 2.4 says:

function-argument   = literal /
                      filter-query / ; (includes singular-query)
                      logical-expr /
                      function-expr

It should say:

function-argument   = logical-expr /
                      filter-query / ; (includes singular-query)
                      function-expr /
                      literal

Notes:

The ABNF grammars in RFC 9535 were designed to be directly usable with PEG (Parsing Expression Grammar) parsers.

However, PEG parsers will fail to parse $[?blt(1==1)] or $[?true(1)==0] with the grammar as given, as they employ prioritized choice, where the order matters.

In the order given, they will try to match the `literal` rule in `function-argument` with the input `1==1`, and find that the `1` indeed matches a `number`, completing the match for `function-argument` and preempting the other choices. The intended rest of the `function-argument`, `==1` does not match anything, and the rule fails.
By putting the more complex `logical-expr` first, the whole `1==1` matches, and the rule succeeds as intended.

Similary, the function name `true` matches as the literal `true` instead, and preempts parsing `true(1)` as the more complex `function-expr`. Putting the `literal` choice last prevents the preemptive match.

Errata ID: 8352
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Vladimír Gorej
Date Reported: 2025-03-24
Verifier Name: Andy Newton
Date Verified: 2025-03-27

Section 2.3.5.1 says:

comparable          = literal /
                      singular-query / ; singular query value
                      function-expr    ; ValueType

It should say:

comparable          = singular-query / ; singular query value
                      function-expr /  ; ValueType
                      literal

Notes:

The ABNF grammars in RFC 9535 were designed to be directly usable with PEG (Parsing Expression Grammar) parsers.

However, PEG parsers will fail to parse $[?blt(1==1)] or $[?true(1)==0] with the grammar as given, as they employ prioritized choice, where the order matters.

In the order given, they will try to match the `literal` rule in `function-argument` with the input `1==1`, and find that the `1` indeed matches a `number`, completing the match for `function-argument` and preempting the other choices. The intended rest of the `function-argument`, `==1` does not match anything, and the rule fails.
By putting the more complex `logical-expr` first, the whole `1==1` matches, and the rule succeeds as intended.

Similary, the function name `true` matches as the literal `true` instead, and preempts parsing `true(1)` as the more complex `function-expr`. Putting the `literal` choice last prevents the preemptive match.

Errata ID: 8353
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Vladimír Gorej
Date Reported: 2025-03-24
Verifier Name: Andy Newton
Date Verified: 2025-03-27

Appendix A says:

comparable          = literal /
                      singular-query / ; singular query value
                      function-expr    ; ValueType

It should say:

comparable          = singular-query / ; singular query value
                      function-expr /  ; ValueType
                      literal

Notes:

The ABNF grammars in RFC 9535 were designed to be directly usable with PEG (Parsing Expression Grammar) parsers.

However, PEG parsers will fail to parse $[?blt(1==1)] or $[?true(1)==0] with the grammar as given, as they employ prioritized choice, where the order matters.

In the order given, they will try to match the `literal` rule in `function-argument` with the input `1==1`, and find that the `1` indeed matches a `number`, completing the match for `function-argument` and preempting the other choices. The intended rest of the `function-argument`, `==1` does not match anything, and the rule fails.
By putting the more complex `logical-expr` first, the whole `1==1` matches, and the rule succeeds as intended.

Similary, the function name `true` matches as the literal `true` instead, and preempts parsing `true(1)` as the more complex `function-expr`. Putting the `literal` choice last prevents the preemptive match.

Errata ID: 8354
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Vladimír Gorej
Date Reported: 2025-03-24
Verifier Name: Andy Newton
Date Verified: 2025-03-27

Appendix A says:

function-argument   = literal /
                      filter-query / ; (includes singular-query)
                      logical-expr /
                      function-expr

It should say:

function-argument   = logical-expr /
                      filter-query / ; (includes singular-query)
                      function-expr /
                      literal

Notes:

The ABNF grammars in RFC 9535 were designed to be directly usable with PEG (Parsing Expression Grammar) parsers.

However, PEG parsers will fail to parse $[?blt(1==1)] or $[?true(1)==0] with the grammar as given, as they employ prioritized choice, where the order matters.

In the order given, they will try to match the `literal` rule in `function-argument` with the input `1==1`, and find that the `1` indeed matches a `number`, completing the match for `function-argument` and preempting the other choices. The intended rest of the `function-argument`, `==1` does not match anything, and the rule fails.
By putting the more complex `logical-expr` first, the whole `1==1` matches, and the rule succeeds as intended.

Similary, the function name `true` matches as the literal `true` instead, and preempts parsing `true(1)` as the more complex `function-expr`. Putting the `literal` choice last prevents the preemptive match.

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

RFC 9562, "Universally Unique IDentifiers (UUIDs)", May 2024

Source of RFC: uuidrev (art)

Errata ID: 7929
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: KIM Jaesuck a.k.a. gim tcaesvk
Date Reported: 2024-05-09
Verifier Name: Orie Steele
Date Verified: 2024-05-10

Section B.2 says:

custom_c  62   0b00, 0x38a375d0df1fbf6

It should say:

custom_c  62   0b01, 0x38a375d0df1fbf6

Notes:

As shown as -938a- in Figure 30.

B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6

See also: https://mailarchive.ietf.org/arch/msg/uuidrev/2wJLek182NMv4xQZf8TIos6XrD0/

Errata ID: 7958
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Roman Donchenko
Date Reported: 2024-05-25
Verifier Name: Orie Steele
Date Verified: 2024-05-29

Section 4.1 says:

     | 0    | x    | x    | x    | 1-7     | Reserved.  Network      |
     |      |      |      |      |         | Computing System (NCS)  |
     |      |      |      |      |         | backward compatibility, |
     |      |      |      |      |         | and includes Nil UUID   |
     |      |      |      |      |         | as per Section 5.9.     |

It should say:

     | 0    | x    | x    | x    | 0-7     | Reserved.  Network      |
     |      |      |      |      |         | Computing System (NCS)  |
     |      |      |      |      |         | backward compatibility, |
     |      |      |      |      |         | and includes Nil UUID   |
     |      |      |      |      |         | as per Section 5.9.     |

Notes:

This row matches the case where MSB0, MSB1, MSB2, MSB3 are all 0, which would make the variant number 0.

Errata ID: 7955
Status: Verified
Type: Technical
Publication Format(s) : PDF, HTML
Reported By: Gordon Garmaise
Date Reported: 2024-05-24
Verifier Name: Orie Steele
Date Verified: 2024-05-29

Section 5.1 says:

time_high:
    The least significant 12 bits from the 60-bit starting timestamp.
    Occupies bits 52 through 63 (octets 6-7).

It should say:

time_high:
    The most significant 12 bits from the 60-bit starting timestamp.
    Occupies bits 52 through 63 (octets 6-7).

Notes:

The original text has the least significant 12 bits from the 60-bit starting timestamp duplicated in the UUID. Once as the least significant 12 bits of time_low and again as time_high. The most significant 12 bits of the starting timestamp are omitted from the UUID.

The corrected text gives the self-evident intention of the committee.

Errata ID: 8288
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nathan McGarvey
Date Reported: 2025-02-08
Verifier Name: Orie Steele
Date Verified: 2025-02-24

Section 6.1 says:

   Length:
      The length of a given timestamp directly impacts how many
      timestamp ticks can be contained in a UUID before the maximum
      value for the timestamp field is reached.  Take care to ensure
      that the proper length is selected for a given timestamp.  UUIDv1
      and UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7
      features a 48-bit timestamp valid until the year 10889 AD.

It should say:

   Length:
      The length of a given timestamp directly impacts how many
      timestamp ticks can be contained in a UUID before the maximum
      value for the timestamp field is reached.  Take care to ensure
      that the proper length is selected for a given timestamp.  UUIDv1
      and UUIDv6 utilize a 60-bit timestamp valid until 5236 AD; UUIDv7
      features a 48-bit timestamp valid until the year 10889 AD.

Notes:

I believe the error is the result of a bad calculation that used the Unix epoch as the zero-date instead of the Gregorian calendar's 1582 zero-date. I've seen online references to the following [incorrect] calculation for determining the UUIDv1 maximum date: (2^60 / 10^7 / 60 / 60 / 24 / 365.25 + 1970) = 5623.38778807. Source: https://github.com/uuid6/uuid6-ietf-draft/issues/23#issuecomment-898866487

That is: (bitsOfTimeData / 100 nanoseconds / secondsPerMin / minutesPerHour / hoursPerDay / daysPerYear + unixEpochYear). However, the max date for v1 and v6 is based, not on the Unix epoch year, but on the year 1582 (Ref: section 5.1).


The same calculation, but using 1582 as the trailing year added, is 5235.38778807.




Doing manual math approximation:

60 bits = 2^60 = 1152921504606846976 one-hundred-nano-second-intervals
1152921504606846976 * 100 = 115292150460684697600 nanoseconds

115292150460684697600 nanoseconds / 31557600000000000 nanosecondPerYear (365.25 daysPerYear assumed) =~ 3653.3878 years.

Date math: 1582.7890 + 3653.3878 years = 5236.1768 =~ March of 5236




Exact date math spot checking using a couple of programming languages calculators:

Go:

package main

import (
"fmt"
"time"
)

func main() {
t := time.Date(1582, 10, 15, 0, 0, 0, 0, time.UTC)
for _ = range 100 {
t = t.Add(1152921504606846976)
}
fmt.Println(t)
}


Output: 5236-03-31 21:21:00.6846976 +0000 UTC



Python:

from datetime import datetime, timedelta, timezone

start_date = datetime(1582, 10, 15, tzinfo=timezone.utc)

nanoseconds = 115292150460684697600
seconds = nanoseconds // 1_000_000_000 # Convert to seconds
remaining_nanoseconds = nanoseconds % 1_000_000_000
microseconds = remaining_nanoseconds // 1000 # Convert remaining to microseconds

delta = timedelta(seconds=seconds, microseconds=microseconds)

result_date = start_date + delta

print(result_date)


Output: 5236-03-31 21:21:00.684697+00:00



Javascript:

const startDate = new Date(Date.UTC(1582, 9, 15)); // Month is 0-based in JS
const nanoseconds = BigInt('115292150460684697600');

const milliseconds = Number(nanoseconds / BigInt(1_000_000));

const resultDate = new Date(startDate.getTime() + milliseconds);

console.log(resultDate.toUTCString());


Output: Mon, 31 Mar 5236 21:21:00 GMT

RFC 9564, "Faster Than Light Speed Protocol (FLIP)", April 2024

Source of RFC: INDEPENDENT

Errata ID: 7877
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Carpenter
Date Reported: 2024-04-01
Verifier Name: Eliot Lear
Date Verified: 2024-11-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

RFC 9568, "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", April 2024

Source of RFC: rtgwg (rtg)

Errata ID: 7947
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2024-05-21
Verifier Name: James Guichard
Date Verified: 2024-06-27

Section 6.4.1 says:

         o  For each IPv4 address associated with the Virtual Router,
            broadcast a gratuitous ARP message containing the Virtual
            Router MAC address and with the target link-layer address
            set to the Virtual Router MAC address.

It should say:

         o  For each IPv4 address associated with the Virtual Router,
            broadcast a gratuitous ARP message containing the Virtual
            Router IPv4 address and with the target link-layer address
            set to the Virtual Router MAC address.

Notes:

The MAC address is specified instead of the IPv4 address.

Errata ID: 7949
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nikolai Malykh
Date Reported: 2024-05-21
Verifier Name: James Guichard
Date Verified: 2024-06-27

Section 6.4.2 says:

         o  For each IPv4 address associated with the Virtual Router,
            broadcast a gratuitous ARP message containing the Virtual
            Router MAC address and with the target link-layer address
            set to the Virtual Router MAC address.

It should say:

         o  For each IPv4 address associated with the Virtual Router,
            broadcast a gratuitous ARP message containing the Virtual
            Router IPv4 address and with the target link-layer address
            set to the Virtual Router MAC address.

Notes:

The MAC address is specified instead of the IPv4 address.

Errata ID: 8298
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06

Section 7.1 says:

    It MUST verify that the VRID is configured on the receiving
    interface and the local router is not the IPvX address owner
    (Priority = 255 (decimal)).

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

It should say:

    It MUST verify that the VRID is configured on the receiving
    interface.

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

It SHOULD verify that the local router is not the IPvX address owner
(Priority = 255 (decimal)) and log the event (subject to
rate-limiting) and MAY indicate via network management that a
misconfiguration was detected.

Notes:

Although it is clearly a configuration error, if two (or more) VRRP routers are configured as the address owner for the same VRID, if received VRRP packets are just dropped (as specified in section 7.1), all such routers will remain in Active state, will continue sending VRRP adverts, and will respond to ARP/ND requests. This will make communication with any VIP unachievable, or at best unreliable.

If the VRRP packets are not dropped, but processed in the normal way, in section 6.4.3 - "Active", following "If an ADVERTISEMENT is received", then:
. If the Priority in the ADVERTISEMENT is greater than the
local Priority or 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 (based
on an unsigned integer comparison of the IPvX addresses in
network byte order), then:
...
Transition to the {Backup} state

will cause all except one of the VRRP routers to revert to Backup state, and the VRRP instance will be stable.

Errata ID: 8299
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06

Section 7.1 says:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

It should say:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

 * It MUST verify that IPvX Addr Count is non zero.

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

Notes:

The only change above is adding:
* It MUST verify that IPvX Addr Count is non zero.

This is due to section 5.2.5 requiring it:

5.2.5. IPvX Addr Count

The IPvX Addr Count field is the number of either IPv4 addresses or IPv6 addresses contained in this VRRP advertisement. The minimum value is 1. If the received count is 0, the VRRP advertisement MUST be ignored.

Errata ID: 8300
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06

Section 7.1 says:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

It should say:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

 * If the received packet is an IPv6 packet, then:
    - It MUST verify that the first address in the IPvX Address(es)
      field is an IPv6 link-local address.

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

Notes:

The change only adds checking that the first IPv6 address is link-local.

Section 5.2.9 states:
For IPv6, the first address MUST be the IPv6 link-local address associated with the Virtual Router.

Section 6.1 also states (although this may relate to the configuration rather than the VRRP packet contents):
IPv6_Addresses One or more IPv6 addresses associated with this Virtual Router. Configured list of addresses with no default. The first address MUST be the Link-Local address associated with the Virtual Router.

Errata ID: 8301
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quentin Armitage
Date Reported: 2025-02-17
Verifier Name: Jim Guichard
Date Verified: 2025-03-06

Section 6.1 says:

Advertisement_Interval  Time interval between VRRP Advertisements
   (centiseconds) sent by this Virtual Router. Default is 100
   centiseconds (1 second).


 and section 7.1 says:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

It should say:

Advertisement_Interval  Time interval between VRRP Advertisements
   (centiseconds) sent by this Virtual Router. Configurable value
   in the range 1-4095 (centiseconds). Default is 100 centiseconds
   (1 second).

 and section 7.1 should say:

 * It MUST verify that the VRID is configured on the receiving
   interface and the local router is not the IPvX address owner
   (Priority = 255 (decimal)).

 *  It MUST verify that the Max Advertise Interval is non zero.

If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event (subject to rate-limiting), and MAY
indicate via network management that an error occurred.

Notes:

The Skew_Time and Active_Down_Time are calculated by multiplying by Active_Adver_Interval which is the Advertisement_Interval of the current active virtual router. A value of 0 for the Active_Adver_Interval will result in Skew_Time and Active_Down_Interval being 0 (centiseconds). The consequence of this is that all backup routers will immediately time out the Active_Down_Interval and transition to Active state. All but the lowest priority virtual router will send an advert, all virtual routes will keep timing out and sending VRRP adverts and the LAN will be flooded with VRRP packets.

It causes mayhem (I have tried it)!

RFC 9579, "Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax", May 2024

Source of RFC: lamps (sec)

Errata ID: 7974
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Hubert Kario
Date Reported: 2024-06-07
Verifier Name: Deb Cooley
Date Verified: 2025-04-03

Section 6 says:

   As documented in Appendix B.1 of [RFC7292], the handling of password
   encoding in the underlying standards is underspecified.  However,
   just as with PBES1 and PBES2 when used in the context of PKCS #12
   objects, all passwords used with PBMAC1 MUST be created from
   BMPStrings with a NULL terminator.

It should say:

   As documented in Appendix B.1 of [RFC7292], the handling of password
   encoding in the underlying standards is underspecified.  However,
   unlike with PBES1 and PBES2 when used in the context of PKCS #12
   objects, all passwords used with PBMAC1 MUST be created from
   UTF-8 encoding without a NULL terminator or Byte Order Mark (BOM).

Notes:

Turns out that in the implementation we used for creating the test vectors, the conversion between the user-provided password and the BMPStrings used for encryption happened in a different place in the call stack than we expected, and the way we generated them, the passwords stayed in UTF-8 format instead of being converted to big-endian UTF-16.

Given that we already have the UTF-8 code implemented in GnuTLS (https://gitlab.com/gnutls/gnutls/-/merge_requests/1833), NSS (https://phabricator.services.mozilla.com/D201833), and that the test-vectors are self-consistent otherwise, I think it will be easier to just redefine how the passwords are passed in to the KDF in the PBMAC1 than to change all the implementations and test vectors.

Thanks space88man on github for noticing this: https://github.com/openssl/openssl/issues/24546#issuecomment-2154729339

RFC 9605, "Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media", August 2024

Source of RFC: sframe (art)

Errata ID: 8321
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rich Logan
Date Reported: 2025-03-03
Verifier Name: Orie Steele
Date Verified: 2025-03-25

Section 4.4.3 says:

def encrypt(CTR, KID, metadata, plaintext):
sframe_key, sframe_salt = key_store[KID]
# encode_big_endian(x, n) produces an n-byte string encoding the
# integer x in big-endian byte order.
ctr = encode_big_endian(CTR, AEAD.Nn)
nonce = xor(sframe_salt, CTR)
# encode_sframe_header produces a byte string encoding the
# provided KID and CTR values into an SFrame header.
header = encode_sframe_header(CTR, KID)
aad = header + metadata
ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
return header + ciphertext

It should say:

def encrypt(CTR, KID, metadata, plaintext):
sframe_key, sframe_salt = key_store[KID]
# encode_big_endian(x, n) produces an n-byte string encoding the
# integer x in big-endian byte order.
ctr = encode_big_endian(CTR, AEAD.Nn)
nonce = xor(sframe_salt, ctr)
# encode_sframe_header produces a byte string encoding the
# provided KID and CTR values into an SFrame header.
header = encode_sframe_header(CTR, KID)
aad = header + metadata
ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
return header + ciphertext

Notes:

The formation of the nonce states to xor the sframe_salt with CTR, which is the original counter value, not the encoded big endian representation created on the line above, which I believe is the intention.

RFC 9615, "Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator", July 2024

Source of RFC: dnsop (ops)

Errata ID: 8034
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Alexander Robohm
Date Reported: 2024-07-17
Verifier Name: RFC Editor
Date Verified: 2024-07-18

Section 4.4 says:

Fully qualified signaling names must by valid DNS names.

It should say:

Fully qualified signaling names must be valid DNS names.

Notes:

Minor typo - "by" should say "be".

RFC 9639, "Free Lossless Audio Codec (FLAC)", December 2024

Source of RFC: cellar (art)

Errata ID: 8256
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Casey
Date Reported: 2025-01-20
Verifier Name: Orie Steele
Date Verified: 2025-01-23

Section 8.2 says:

   SSAAAAAASSBBBBBBSSCCCCCC
   ^   ^   ^   ^   ^   ^
   |   |   |   |   |  Bits of 2nd sample of 1st channel
   |   |   |   |  Sign extension bits of 2nd sample of 2nd channel
   |   |   |  Bits of 1st sample of 2nd channel
   |   |  Sign extension bits of 1st sample of 2nd channel
   |  Bits of 1st sample of 1st channel
   Sign extension bits of 1st sample of 1st channel

It should say:

   SSAAAAAASSBBBBBBSSCCCCCC
   ^   ^   ^   ^   ^   ^
   |   |   |   |   |  Bits of 2nd sample of 1st channel
   |   |   |   |  Sign extension bits of 2nd sample of 1st channel
   |   |   |  Bits of 1st sample of 2nd channel
   |   |  Sign extension bits of 1st sample of 2nd channel
   |  Bits of 1st sample of 1st channel
   Sign extension bits of 1st sample of 1st channel

Notes:

One of the diagram labels appears to contradict the sign-extension + interleaving method described in the preceding paragraph.

RFC 9644, "YANG Groupings for SSH Clients and SSH Servers", October 2024

Source of RFC: netconf (ops)

Errata ID: 8293
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kent Watsen
Date Reported: 2025-02-12
Verifier Name: Mahesh Jethanandani
Date Verified: 2025-02-13

Section 5.5 says:

return the private clear in cleartext form.

It should say:

return the private key in cleartext form.

Notes:

typo

RFC 9645, "YANG Groupings for TLS Clients and TLS Servers", October 2024

Source of RFC: netconf (ops)

Errata ID: 8294
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Kent Watsen
Date Reported: 2025-02-12
Verifier Name: Mahesh Jethanandani
Date Verified: 2025-02-13

Section 5.2 says:

return the private clear in cleartext form.

It should say:

return the private key in cleartext form.

Notes:

typo

RFC 9656, "A YANG Data Model for Microwave Topology", September 2024

Source of RFC: ccamp (rtg)

Errata ID: 8131
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Scott Mansfield
Date Reported: 2024-10-08
Verifier Name: John Scudder
Date Verified: 2024-10-09

Section A.1 says:

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-id": "L2-network",
           "network-types": {
             "ietf-te-topology:te-topology": {}
           },
           "supporting-network": [
             {
               "network-ref": "mw-network"
             }
           ],
           "node": [
             {
               "node-id": "L2-N1",
               "supporting-node": [
                 {
                   "network-ref": "mw-network",
                   "node-ref": "mw-N1"
                 }
               ],
               "ietf-network-topology:termination-point": [
                 {
                   "tp-id": "L2-N1-TP1",
                   "supporting-termination-point": [
                     {
                       "network-ref": "mw-network",
                       "node-ref": "mw-N1",
                       "tp-ref": "mw-N1-RLTP1"
                     }
                   ]
                 }
               ]
             },
             {
               "node-id": "L2-N2",
               "supporting-node": [
                 {
                   "network-ref": "mw-network",
                   "node-ref": "mw-N2"
                 }
               ],
               "ietf-network-topology:termination-point": [
                 {
                   "tp-id": "L2-N2-TP2",
                   "supporting-termination-point": [
                     {
                       "network-ref": "mw-network",
                       "node-ref": "mw-N2",
                       "tp-ref": "mw-N2-RLTP2"
                     }
                   ]
                 }
               ]
             }
           ],
           "ietf-network-topology:link": [
             {
               "link-id": "L2-N1-N2",
               "source": {
                 "source-node": "L2-N1",
                 "source-tp": "L2-N1-TP1"
               },
               "destination": {
                 "dest-node": "L2-N2",
                 "dest-tp": "L2-N2-TP2"
               },
               "supporting-link": [
                 {
                   "network-ref": "mw-network",
                   "link-ref": "mwrl-N1-N2"
                 }
               ]
             }
           ]
         },
         {
           "network-id": "mw-network",
           "network-types": {
             "ietf-te-topology:te-topology": {
               "ietf-microwave-topology:mw-topology": {}