RFC Errata
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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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 GROUPArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyErrata 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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: LegacyArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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: LegacyArea 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 GROUPArea 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 GROUPArea 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: LegacyErrata 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: LegacyArea 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: LegacyArea 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: LegacyErrata 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: LegacyArea 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: LegacyErrata 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: LegacyArea 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 GROUPArea 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: LegacyArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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: INDEPENDENTErrata 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 GROUPArea 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: INDEPENDENTErrata 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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é";
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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPErrata 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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=""Hypertext Transfer Protocol -- HTTP/1.1"">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=""Hypertext Transfer Protocol -- HTTP/1.1"">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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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^161>; } 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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| <πßå> | Non-ASCII letters are OK | | | | (e.g., GREEK SMALL LETTER | | | | PI, U+03C0) | +------------------------------------+------------------------------+ | 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK | | | | DIAMOND SUIT, U+2666) | +------------------------------------+------------------------------+ | 16| <foo 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| <πßå> | Non-ASCII letters are OK | | | | (e.g., GREEK SMALL LETTER | | | | PI, U+03C0) | +------------------------------------+------------------------------+ | 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK | | | | DIAMOND SUIT, U+2666) | +------------------------------------+------------------------------+ | 16| <foo 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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 GROUPArea 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": {}