RFC Errata
Found 7030 records.
Status: Verified (3003)
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: 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
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 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 640, "Revised FTP reply codes", June 1974
Source of RFC: Legacy
Errata ID: 3435
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2012-12-25
Verifier Name: Barry Leiba
Date Verified: 2012-12-25
Section 11a says:
There are four values for the first digit of the reply code: 11a
It should say:
There are five values for the first digit of the reply code: 11a
Notes:
Technical type (vs. Editorial) although operation was not affected ("four" cannot reasonably be considered a misspelling of "five")
Reply code first digit values per sections 11b through 11f are 1, 2, 3, 4, and 5
RFC 675, "Specification of Internet Transmission Control Program", December 1974
Note: This RFC has been obsoleted by RFC 7805
Source of RFC: Legacy
Errata ID: 6868
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chuck Craft
Date Reported: 2022-03-05
Verifier Name: RFC Editor
Date Verified: 2022-03-15
Section 7 says:
6. ROWE74
It should say:
6. ROWE70
Notes:
[PSN] [ROWE70,
POUZ73].
AFIPS 1970,
RFC 783, "TFTP Protocol (revision 2)", June 1981
Note: This RFC has been obsoleted by RFC 1350
Source of RFC: Legacy
Errata ID: 580
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 2 says:
Any transsfer begins with a request to read or write a file, which also serves to request a connection.
It should say:
Any transfer begins with a request to read or write a file, which also serves to request a connection.
Notes:
from pending
Errata ID: 703
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 5 says:
The mode field contains the string "netascii", "octec", or "mail" (or any comibnation of upper and lower case, such as "NETASCII", "NetAscii", etc.) in netascii indicating the three modes defined in the protocol.
It should say:
The mode field contains the string "netascii", "octec", or "mail" (or any combination of upper and lower case, such as "NETASCII", "NetAscii", etc.) in netascii indicating the three modes defined in the protocol.
Notes:
spelling error: comibnation/combination
from pending
RFC 791, "Internet Protocol", September 1981
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:
fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information
It should say:
fragmentation strategy is designed so that an unfragmented datagram has all zero fragmentation information
Notes:
typo: so than => so that
Errata ID: 7561
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2023-07-10
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03
Section 3.2 says:
Identification
The choice of the Identifier for a datagram is based on the need to
provide a way to uniquely identify the fragments of a particular
datagram. The protocol module assembling fragments judges fragments
to belong to the same datagram if they have the same source,
destination, protocol, and Identifier. Thus, the sender must choose
the Identifier to be unique for this source, destination pair and
protocol for the time the datagram (or any fragment of it) could be
alive in the internet.
It seems then that a sending protocol module needs to keep a table
of Identifiers, one entry for each destination it has communicated
with in the last maximum packet lifetime for the internet.
However, since the Identifier field allows 65,536 different values,
some host may be able to simply use unique identifiers independent
of destination.
It should say:
Identification
The choice of the Identification for a datagram is based on the need to
provide a way to uniquely identify the fragments of a particular
datagram. The protocol module assembling fragments judges fragments
to belong to the same datagram if they have the same source,
destination, protocol, and Identification. Thus, the sender must choose
the Identification to be unique for this source, destination pair and
protocol for the time the datagram (or any fragment of it) could be
alive in the internet.
It seems then that a sending protocol module needs to keep a table
of Identification values, one entry for each destination it has communicated
with in the last maximum packet lifetime for the internet.
However, since the Identification field allows 65,536 different values,
some host may be able to simply use unique identifiers independent
of destination.
Notes:
The field is called "Identification", and not "Identifier" (please note the capitalization in the text).
Errata ID: 7560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Günther
Date Reported: 2023-07-04
Verifier Name: RFC Editor
Date Verified: 2023-07-06
Section 3.1, Line 904 says:
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
It should say:
Bits 5: 0 = Normal Reliability, 1 = High Reliability.
Notes:
Typo
RFC 792, "Internet Control Message Protocol", September 1981
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
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
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 864, "Character Generator Protocol", May 1983
Source of RFC: Legacy
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 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
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 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.
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
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
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: 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 1034, "Domain names - concepts and facilities", November 1987
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.
RFC 1035, "Domain names - implementation and specification", November 1987
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
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
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
Source of RFC: Legacy
Errata ID: 558
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2003-02-12
Section 2.5 says:
Host names of up to 635 characters |2.1 |x| | | | |
It should say:
Host names of up to 63 characters |2.1 |x| | | | |
Notes:
Section 2.1 says "Host software MUST handle host names of up to 63 characters" and doesn't mention the number 635 at all.
Errata ID: 584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Harris
Date Reported: 2003-02-12
Section 7 says:
[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983.
It should say:
[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-885, December 1983.
Notes:
RFC 855 is "Telnet Option Specifications"; RFC 885 is "Telnet end of record option".
Errata ID: 1354
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2008-03-08
Verifier Name: Lisa Dusseault
Date Verified: 2008-07-14
Section 2.1 says:
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].
It should say:
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4] and reiterated in RFC-1034 Section 3.5 [DNS:1].
Notes:
This essentially trivial editorial change makes it slightly easier for
anyone (or any tool) that tracks changes and updates to host and domain
naming rules to identify the applicability of this section.
Errata ID: 5456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David LAMBERT
Date Reported: 2018-08-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-08-13
Section 4.1.2.5 says:
This is required because of the long delay after a TCP
connection is closed until its socket pair can be
reused, to allow multiple transfers during a single FTP
session. Sending a port command can avoided if a
transfer mode other than stream is used, by leaving the
data transfer connection open between transfers.
It should say:
This is required because of the long delay after a TCP
connection is closed until its socket pair can be
reused, to allow multiple transfers during a single FTP
session. Sending a port command can be avoided if a
transfer mode other than stream is used, by leaving the
data transfer connection open between transfers.
Notes:
The verb is missing in the last sentence.
"Sending a port command can avoided..."
Errata ID: 6474
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16
Section 6.1.3.6 says:
on the the existence of a TXT or WKS RR in most
domains.
It should say:
on the existence of a TXT or WKS RR in most domains.
Notes:
Doubled word.
Errata ID: 6475
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16
Section 3.2.1 says:
option-negotiation loops. A host MUST refuse (i.e, reply
It should say:
option-negotiation loops. A host MUST refuse (i.e., reply
Notes:
Missing full stop.
RFC 1150, "FYI on FYI: Introduction to the FYI Notes", March 1990
Note: This RFC has been obsoleted by RFC 6360
Source of RFC: Legacy
Errata ID: 3829
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marek Perny
Date Reported: 2013-12-09
Verifier Name: RFC Editor
Section 2 says:
The formost reason is that the distribution mechanisms for RFCs are tried and true.
It should say:
The foremost reason is that the distribution mechanisms for RFCs are tried and true.
Notes:
spelling error
RFC 1155, "Structure and identification of management information for TCP/IP-based internets", May 1990
Source of RFC: Legacy
Errata ID: 2601
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vivek Gupta
Date Reported: 2010-11-03
Verifier Name: Dan Romascanu
Date Verified: 2010-11-04
Section 4.2 says:
Each such subject type is uniquely named by its OBJECT IDENTIFIER
It should say:
Each such object type is uniquely named by its OBJECT IDENTIFIER
Notes:
The word "subject" should be replaced by the word "object" in the referred context
RFC 1158, "Management Information Base for network management of TCP/IP-based internets: MIB-II", May 1990
Note: This RFC has been obsoleted by RFC 1213
Source of RFC: Legacy
Errata ID: 557
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vincent Berger
Date Reported: 2002-03-27
Section 5.4.2 says:
egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13) bgp(14)
It should say:
egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14)
RFC 1180, "TCP/IP tutorial", January 1991
Source of RFC: 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.
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
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 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.
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
Source of RFC: LegacyArea Assignment: app
Errata ID: 4971
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ondrej
Date Reported: 2017-03-15
Verifier Name: Barry Leiba
Date Verified: 2019-04-30
Section 6 says:
(i.e., Datagram length < 516)
It should say:
(i.e., Datagram length < 512)
RFC 1361, "Simple Network Time Protocol (SNTP)", August 1992
Note: This RFC has been obsoleted by RFC 1769
Source of RFC: 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 1459, "Internet Relay Chat Protocol", May 1993
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 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: Legacy
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
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
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>
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 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
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
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: Legacy
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: Legacy
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
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
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 2015, "MIME Security with Pretty Good Privacy (PGP)", October 1996
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
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
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
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
Source of RFC: 822ext (app)
Errata ID: 507
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-10-04
Section 5.1.5 says:
Date: Mon, 22 Mar 1994 13:34:51 +0000
It should say:
Date: Tue, 22 Mar 1994 13:34:51 +0000
Errata ID: 508
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Herman Meerlo
Date Reported: 2001-10-04
Appendix A states:
discard-text := *(*text CRLF)
It should say:
discard-text := *(*text CRLF) *text
Errata ID: 588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.2.2.2 says:
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail Message-ID: <anotherid@foo.com>
It should say:
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Message-ID: <anotherid@foo.com> Subject: Audio mail
Errata ID: 589
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.2.3.7 says:
Content-Type: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
It should say:
Content-Type: message/external-body;
access-type=mail-server;
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Notes:
Semicolons were missing.
Errata ID: 509
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Bellovin
Date Reported: 2004-02-03
Section 9 says:
9. Security Considerations
It should say:
8. Security Considerations
Notes:
In the Table of Contents, the Security Considerations is listed to be in Section 8. However, in the text, both the Security Considerations and Authors' Addresses are in Section 9; there is no Section 8.
Errata ID: 510
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.1.5 says:
undesireble seperate
It should say:
undesirable separate
Notes:
Spelling errors.
Errata ID: 511
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lars Kasper
Date Reported: 2005-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29
Section 3 says:
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG. . subtypes are defined for two widely-used image
formats, jpeg and gif.
It should say:
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. Subtypes are defined
for two widely-used image formats, jpeg and gif.
Notes:
The sentence previous to the last should be deleted, as it is covered by the last sentence.
Errata ID: 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
Source of RFC: 822ext (app)
Errata ID: 504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jose M. Cainzos
Date Reported: 2001-11-10
Section 5 says:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
It should say:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "\". In addition, an
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
Errata ID: 506
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruce Lilly
Date Reported: 2003-02-13
Section 2 says:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
It should say:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
<"> / "/" / "[" / "]" / "?" / "." / "="
Notes:
Also reported by Jon Steinhart 2002-01-17, but corrected by Bruce Lilly.
RFC 2049, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", November 1996
Source of RFC: 822ext (app)
Errata ID: 3933
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-03-26
Verifier Name: Barry Leiba
Date Verified: 2014-05-07
Section 2 says:
(10) Conforming user agents must be able to distinguish
encoded-words from "text", "ctext", or "word"s,
according to the rules in section 4, anytime they
appear in appropriate places in message headers.
It should say:
(10) Conforming user agents must be able to distinguish
encoded-words from "text", "ctext", or "word"s (see the
grammar in Section 3.3 of [RFC822]), according to
the recognition rules in Section 6 of [RFC2047],
any time they appear in appropriate places in
message headers.
Notes:
Section 4 of RFC 2049 was not the correct citation.
RFC 2060, "Internet Message Access Protocol - Version 4rev1", December 1996
Note: This RFC has been obsoleted by RFC 3501
Source of RFC: Legacy
Errata ID: 503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mathieu Fenniak
Date Reported: 2002-05-28
Section 6.4.8 says:
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed
It should say:
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
Notes:
A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata
RFC 2069, "An Extension to HTTP : Digest Access Authentication", January 1997
Note: This RFC has been obsoleted by RFC 2617
Source of RFC: http (app)
Errata ID: 749
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2005-02-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-11
Section 2.4 says:
RfC 2069 (digest access authentication) chapter 2.4 is an example,
the userame is "Mufasa", the password is "CircleOfLife":
| username="Mufasa",
| realm="testrealm@host.com",
| nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
| uri="/dir/index.html",
| response="e966c932a9242554e42c8ee200cec7f6",
| opaque="5ccc069c403ebaf9f0171e9517f40e41"
The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 ))
MD5( A1 ) = MD5( username || ':' || realm || ':' || password )
= MD5( "Mufasa:testrealm@host.com:CircleOfLife" )
= "4945ecf42b1bb868634058a845bedde8"
MD5( A2 ) = MD5( Method || ':' || digest-uri-value )
= MD5( "GET:/dir/index.html" )
= "39aff3a2bab6126f332b942af96d3366"
This results in a response = "1949323746fe6a43ef61f9606e7febea"
instead of the shown value = "e966c932a9242554e42c8ee200cec7f6".
Quick reality check, the RFC 2617 example uses the same values
username = "Mufasa"
nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"
realm = "testrealm@host.com"
A2 = "GET:/dir/index.html"
with a slightly different
password = "Circle Of Life"
resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9"
The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 ))
for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth"
and here the response = "6629fae49393a05397450978507c4ef1" works as
expected.
It should say:
[not submitted]
Notes:
I've tried to contact two of the RFC 2069 authors about this issue,
but got no reply.
Alexey: note that this problem was addressed in RFC 2617.
RFC 2092, "Protocol Analysis for Triggered RIP", January 1997
Source of RFC: rip (rtg)
Errata ID: 502
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kwan Jong Yoo
Date Reported: 2004-03-30
Section 3.3. says:
Triggered RIP will NOT fuction properly (and should NOT be used) if a routing information will be retained/advertised for an arbitrarily long period of time (until an update in the opposite direction fails to obtain a response).
It should say:
Triggered RIP will NOT function properly (and should NOT be used) if a routing information will be retained/advertised for an arbitrarily long period of time (until an update in the opposite direction fails to obtain a response).
RFC 2100, "The Naming of Hosts", April 1997
Source of RFC: Legacy
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
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
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
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
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
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 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997
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
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 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
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
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
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
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
Source of RFC: dnsind (int)
Errata ID: 461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-02-01
Verifier Name: Brian Haberman
Date Verified: 2012-05-01
Section 7.2 says:
7.2 Dead / Unreachable Server (OPTIONAL)
Dead / Unreachable servers are servers that fail to respond in any
way to a query or where the transport layer has provided an
indication that the server does not exist or is unreachable. A
server may be deemed to be dead or unreachable if it has not
responded to an outstanding query within 120 seconds.
Examples of transport layer indications are:
ICMP error messages indicating host, net or port unreachable.
TCP resets
IP stack error messages providing similar indications to those above.
A server MAY cache a dead server indication. If it does so it MUST
NOT be deemed dead for longer than five (5) minutes. The indication
MUST be stored against query tuple <query name, type, class, server
IP address> unless there was a transport layer indication that the
server does not exist, in which case it applies to all queries to
that specific IP address.
It should say:
7.2 Dead / Unreachable Server (OPTIONAL)
Dead / Unreachable servers are servers that fail to respond in any
way to a query or where the transport layer has provided an
indication that the server does not exist or is unreachable. A
server may be deemed to be dead or unreachable if it has not
responded to an outstanding query within 120 seconds.
Examples of transport layer indications are:
ICMP error messages indicating host, net or port unreachable.
TCP resets
IP stack error messages providing similar indications to those above.
A resolver MAY cache a dead server indication. If it does so it MUST
NOT be deemed dead for longer than five (5) minutes. The indication
MUST be stored against query tuple <query name, type, class, server
IP address> unless there was a transport layer indication that the
server does not exist, in which case it applies to all queries to
that specific IP address.
Notes:
Last sentence says, "A server MAY cache a dead server indication.".
But, this "server" is typo, I think.
This "server" should be "resolver" because section 7.1's last sentence uses "resolver".
Errata ID: 4489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wes Hardaker
Date Reported: 2015-09-29
Verifier Name: Brian Haberman
Date Verified: 2015-10-14
In the References
It should say:
ADD:
[RFC2136] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
-------
OR: define SERVFAIL inside of the terminology section (section 1):
"SERVFAIL" - a name for the "Server failure" (2) RCODE described in
[RFC1035 Section 4.1.1].
Notes:
Section 2.1.1 uses the term SERVFAIL to reference DNS RCODE 2, but this term isn't defined in the document nor in the referenced documents. It's first defined in 2136 and thus the two options available are to either add a reference to 2136 or to add a definition of SERVFAIL to the document in the terminology section.
RFC 2319, "Ukrainian Character Set KOI8-U", April 1998
Source of RFC: INDEPENDENT
Errata ID: 4641
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Dmitry Kohmanyuk
Date Reported: 2016-03-18
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20
Section Appendix A says:
180 B4 U0403 CYRILLIC CAPITAL LETTER UKRAINIAN IE
It should say:
180 B4 U0404 CYRILLIC CAPITAL LETTER UKRAINIAN IE
Notes:
Typo in Unicode code point number (main text of RFC has proper number 0404, but Appendix A has a typo: 0403).
RFC 2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", April 1998
Source of RFC: Legacy
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
RFC 2325, "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", April 1998
Source of RFC: Legacy
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
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
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 .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/)
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 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
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
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
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 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 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
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
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
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: 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
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
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: Legacy
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
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
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
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
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 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.
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.
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.
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
Source of RFC: urn (app)
Errata ID: 3145
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02
Section A.2 says:
print "Status: 302 Moved temporarily0;
It should say:
print "Status: 302 Moved temporarily";
Notes:
might be both editorial and technical error (typo, causing the Perl code invalid)
Errata ID: 3146
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02
Section A.3 says:
if ($accept =~ /text\/uri-list/) { #look for text/uri-list,
otherwise text/html
It should say:
if ($accept =~ /text\/uri-list/) {
# look for text/uri-list, otherwise text/html
Notes:
Appears 4 times in the same section. Might be both editorial and technical error (forced line break in the middle of the comment, making the Perl code invalid)
RFC 2655, "CIP Index Object Format for SOIF Objects", August 1999
Source of RFC: find (app)
Errata ID: 403
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kang-Jin Lee
Date Reported: 2002-09-04
Section 8 says:
[2] The Harvest Information Discovery and Access System:
<URL:http://harvest.transarc.com/>
It should say:
[2] Harvest: A distributed Search System:
<URL:http://harvest.sourceforge.net/>
RFC 2656, "Registration Procedures for SOIF Template Types", August 1999
Source of RFC: find (app)
Errata ID: 402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kang-Jin Lee
Date Reported: 2002-09-04
Section 5 says:
[2] The Harvest Information Discovery and Access System:
<URL:http://harvest.transarc.com/>
It should say:
[2] Harvest: A distributed Search System:
<URL:http://harvest.sourceforge.net/>
RFC 2661, "Layer Two Tunneling Protocol "L2TP"", August 1999
Source of RFC: pppext (int)
Errata ID: 401
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ming Deng
Date Reported: 2007-03-17
Section 3 says:
SSHTRESH
It should say:
SSTHRESH
Notes:
Occurs 3 times.
from pending
Errata ID: 5632
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2019-02-11
Verifier Name: RFC Editor
Date Verified: 2019-03-19
Section 6.1 says:
It is sent by either the LAC or the LNS to being the tunnel establishment process.
It should say:
It is sent by either the LAC or the LNS to begin the tunnel establishment process.
RFC 2662, "Definitions of Managed Objects for the ADSL Lines", August 1999
Source of RFC: adslmib (ops)
Errata ID: 5508
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Glenn Mansfield Keeni
Date Reported: 2018-09-29
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-07-01
Section 7 says:
OBJECT adslAtucConfMinSnrMgn
MIN-ACCESS read-wr
MIN-ACCESS read-write
DESCRIPTION
"Read-write access is applicable when
static profiles are implemented."
It should say:
OBJECT adslAtucConfMinSnrMgn
MIN-ACCESS read-write
DESCRIPTION
"Read-write access is applicable when
static profiles are implemented."
Notes:
The extra line
MIN-ACCESS read-wr
results in MIB compilation errors.
RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations", August 1999
Source of RFC: nat (tsv)
Errata ID: 400
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Javier Waisbrot
Date Reported: 2002-11-14
Section 2.6 says:
the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session (i.e., there could be retransmissions).
It should say:
the NAT device cannot safely assume that the segments containing FINs or RSTs will be the last packets of the session (i.e., there could be retransmissions).
RFC 2673, "Binary Labels in the Domain Name System", August 1999
Note: This RFC has been obsoleted by RFC 6891
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 (tsv)
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
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 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
Source of RFC: calsch (app)
Errata ID: 6624
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor
Section 2.3.3 says:
2.3.3 CAPURI Property IANA Registration To: ietf-mime-directory@imc.org Subject: Registration of CAPURI type for application/directory MIME type vCard profile. Type name: CAPURI Type purpose: To specify a protocol independent location from which a calendaring and scheduling client (i.e., CUA) can communicate with a user's entire calendar. Type encoding: 8bit Type value: A single URI value. Type special notes: Where multiple CAPURI properties are specified, the default CAPURI property is indicated with the PREF parameter. Intended usage: Refer to section 1.3.
It should say:
2.3.3 CAPURI Property IANA Registration To: ietf-mime-directory@imc.org Subject: Registration of CAPURI type for application/directory MIME type vCard profile. Type name: CAPURI Type purpose: To specify a protocol independent location from which a calendaring and scheduling client (i.e., CUA) can communicate with a user's entire calendar. Type encoding: 8bit Type value: A single URI value. Type special notes: Where multiple CAPURI properties are specified, the default CAPURI property is indicated with the PREF parameter. Intended usage: Refer to section 1.2.
Notes:
Usage Reference Section was incorrect
Errata ID: 6625
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor
Section 2.3.4 says:
2.3.4 CALURI Property IANA Registration
To: ietf-mime-directory@imc.org
Subject: Registration of CALURI type for text/directory MIME type
vCard profile.
Type name: CALURI
Type purpose: To specify the URI for a user's calendar in a vCard
object.
Type encoding: 8bit
Type value type: A single URI value.
Type special notes: Where multiple CALURI properties are specified,
the default CALURI property is indicated with the PREF parameter. The
property should contain a URI pointing to an iCalendar object
associated with a snapshot of the user's calendar store. If the
iCalendar object is represented as a file or document, it's file type
should be "ics".
Intended usage: Refer to section 1.4.
Type examples:
CALURI;PREF:http://cal.host1.com/calA
CALURI:ftp://ftp.host1.com/calA.ics
It should say:
2.3.4 CALURI Property IANA Registration
To: ietf-mime-directory@imc.org
Subject: Registration of CALURI type for text/directory MIME type
vCard profile.
Type name: CALURI
Type purpose: To specify the URI for a user's calendar in a vCard
object.
Type encoding: 8bit
Type value type: A single URI value.
Type special notes: Where multiple CALURI properties are specified,
the default CALURI property is indicated with the PREF parameter. The
property should contain a URI pointing to an iCalendar object
associated with a snapshot of the user's calendar store. If the
iCalendar object is represented as a file or document, it's file type
should be "ics".
Intended usage: Refer to section 1.3.
Type examples:
CALURI;PREF:http://cal.host1.com/calA
CALURI:ftp://ftp.host1.com/calA.ics
Notes:
Usage Reference Section was incorrect
Errata ID: 6626
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Prakhar Makhija
Date Reported: 2021-06-30
Verifier Name: RFC Editor
Section 2.3.2 says:
2.3.2 CALADRURI Property IANA Registration
To: ietf-mime-directory@imc.org
Subject: Registration of CALADRURI type for application/directory
MIME type vCard profile.
Type name: CALADRURI
Type purpose: To specify the location to which an event request
should be sent for the user.
Type encoding: 8bit
Type value: A single URI value.
Type special notes: Where multiple CALADRURI properties are
specified, the default CALADRURI property is indicated with the PREF
parameter.
Intended usage: Refer to section 1.2.
Type examples:
CALADRURI;PREF:mailto:janedoe@host.com
It should say:
2.3.2 CALADRURI Property IANA Registration
To: ietf-mime-directory@imc.org
Subject: Registration of CALADRURI type for application/directory
MIME type vCard profile.
Type name: CALADRURI
Type purpose: To specify the location to which an event request
should be sent for the user.
Type encoding: 8bit
Type value: A single URI value.
Type special notes: Where multiple CALADRURI properties are
specified, the default CALADRURI property is indicated with the PREF
parameter.
Type examples:
CALADRURI;PREF:mailto:janedoe@host.com
Notes:
Usage Reference Section was wrong
Section 1 (Calendaring and Scheduling URIs) does not define CALADRURI
Usage type example is already mentioned in Section 2.3.2
RFC 2740, "OSPF for IPv6", December 1999
Note: This RFC has been obsoleted by RFC 5340
Source of RFC: ospf (rtg)
Errata ID: 392
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.3.2 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 394
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wu Qian
Date Reported: 2001-08-21
Section 3.1.2 says:
The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by router for the attached link, and the router-LSA originated by the router-LSA for the associated area.
It should say:
The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by router for the attached link, and the router-LSA originated by the router for the associated area.
Errata ID: 609
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
In Section A.2 The Options field:
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
| | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
It should say:
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
| | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
Errata ID: 659
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.3.3 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 660
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.3.4 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 661
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.3.5 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
Errata ID: 662
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.3.6 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 663
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.2 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 664
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.3 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |W|V|E|B| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |W|V|E|B| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 665
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.4 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Errata ID: 667
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.5 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 668
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.6 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 669
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.7 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 671
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.8 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 672
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Moy
Date Reported: 2002-01-17
Section A.4.9 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes | Referenced LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes | Referenced LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000
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
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
Source of RFC: vgmib (int)
Errata ID: 4313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2015-03-25
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-21
Section 3.2 says:
In this approach, we could use an NTP based timestamp value as the sequence number. The roll-over period of an NTP timestamp is about 136 years, much longer than any reasonable lifetime of a key. In addition, the granularity of the NTP timestamp is fine enough to allow the generation of an RSVP message every 200 picoseconds for a given key. Many real time clock modules do not have the resolution of an NTP timestamp. In these cases, the least significant bits of the timestamp can be generated using a message counter, which is reset every clock tick. For example, when the real time clock provides a resolution of 1 second, the 32 least significant bits of the sequence number can be generated using a message counter. The remaining 32 bits are filled with the 32 least significant bits of the timestamp. Assuming that the recovery time after failure takes longer than one tick of the real time clock, the message counter for the low order bits can be safely reset to zero after a restart.
It should say:
In this approach, we could use an NTP based timestamp value as the sequence number. The roll-over period of an NTP timestamp is about 136 years, much longer than any reasonable lifetime of a key. In addition, the granularity of the NTP timestamp is fine enough to allow the generation of an RSVP message every 200 picoseconds for a given key. Many real time clock modules do not have the resolution of an NTP timestamp. In these cases, the least significant bits of the sequence number can be generated using a message counter, which is reset every clock tick. For example, when the real time clock provides a resolution of 1 second, the 32 least significant bits of the sequence number can be generated using a message counter. The remaining 32 bits are filled with the 32 most significant bits of the timestamp. Assuming that the recovery time after failure takes longer than one tick of the real time clock, the message counter for the low order bits can be safely reset to zero after a restart.
Notes:
32 least significant bits of the timestamp will in this case be set to zero.
RFC 2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000
Source of RFC: pppext (int)
Errata ID: 391
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Roughan
Date Reported: 2002-08-26
Section 9.3 says:
0-to-256-unicode-char Password: 4D 79 50 77 16-octet PasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
It should say:
0-to-256-char Password: 4D 79 50 77 0-to-256-unicode-char NtPassword: 4D 00 79 00 50 00 77 00 16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
Errata ID: 1924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexey Melnikov
Date Reported: 2009-10-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-09
Section 8.3 says:
NtPasswordHash(
IN 0-to-256-unicode-char Password,
OUT 16-octet PasswordHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash Password
* into PasswordHash. Only the password is hashed without
* including any terminating 0.
*/
}
It should say:
NtPasswordHash(
IN 0-to-256-unicode-char Password,
OUT 16-octet PasswordHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash Password
* encoded in UTF-16-LE into PasswordHash.
* Only the password is hashed without
* including any terminating 0.
*/
}
Notes:
Section 8.3 is silent on Unicode encoding used for passwords.
Section 9.2 seem to imply that the Unicode encoding used in UTF-16-LE.
RFC 2763, "Dynamic Hostname Exchange Mechanism for IS-IS", February 2000
Note: This RFC has been obsoleted by RFC 5301
Source of RFC: isis (rtg)
Errata ID: 390
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Vine
Date Reported: 2002-06-28
Section 4 says:
A router may also optionally insert this TLV in it's pseudo node LSP for the association of a symbolic name to a local LAN.
It should say:
A router may also optionally insert this TLV in its pseudo node LSP for the association of a symbolic name to a local LAN.
RFC 2764, "A Framework for IP Based Virtual Private Networks", February 2000
Source of RFC: Legacy
Errata ID: 389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Elena Taguer
Date Reported: 2001-02-01
There is a case of sections being numbered wrong:
5.3.3.1 Stub Link Connectivity Scenarios ........................ 30 5.3.3.1 Routing Protocol Instance ............................... 31
RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)", February 2000
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
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
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
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
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
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
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 (tsv)
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 2865, "Remote Authentication Dial In User Service (RADIUS)", June 2000
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
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
Source of RFC: radius (ops)
Errata ID: 2714
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-28
Section 3.10 says:
3.10. Tunnel-Server-Auth-ID
Description
This Attribute specifies the name used by the tunnel terminator
during the authentication phase of tunnel establishment. The
Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
^^^^^^^^^^^^^^^^^^^^^
It should say:
3.10. Tunnel-Server-Auth-ID
Description
This Attribute specifies the name used by the tunnel terminator
during the authentication phase of tunnel establishment. The
Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the
Notes:
Maybe here should be the "Tunnel-Server-Auth-ID"
Errata ID: 2716
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13
Section 6 says:
6.1. Tunnel-Type Attribute Values Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16]. 6.2. Tunnel-Medium-Type Attribute Values Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
It should say:
6.1. Tunnel-Type Attribute Values Values 1-12 of the Tunnel-Type Attribute are defined in Section 3.1; the remaining values are available for assignment by the IANA with IETF Consensus [16]. 6.2. Tunnel-Medium-Type Attribute Values Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 3.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
Notes:
Should be "Section 3.1" and "Section 3.2"
RFC 2873, "TCP Processing of the IPv4 Precedence Field", June 2000
Note: This RFC has been obsoleted by RFC 9293
Source of RFC: Legacy
Errata ID: 366
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt D. Zeilenga
Date Reported: 2001-11-06
In the References Section:
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2587, June 1999.
It should say:
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
RFC 2876, "Use of the KEA and SKIPJACK Algorithms in CMS", July 2000
Source of RFC: smime (sec)
Errata ID: 1839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-08-25
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section 7 says:
300b 0609 6086 4801 6502 0101 0400
It should say:
300b 0609 6086 4801 6502 0101 04
Notes:
The SMIMECapability for SKIPJACK should be 300b 0609 6086 4801 6502 0101 04, which is the DER encoding of the id-fortezzaConfidentialityAlgorithm OID. The extra 00 should not be included.
RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", July 2000
Source of RFC: tsvwg (tsv)
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 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000
Note: This RFC has been obsoleted by RFC 8010
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
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 2988, "Computing TCP's Retransmission Timer", November 2000
Note: This RFC has been obsoleted by RFC 6298
Source of RFC: tsvwg (tsv)
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 (tsv)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
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
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")
RFC 3032, "MPLS Label Stack Encoding", January 2001
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.
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
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
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
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 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
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
Source of RFC: tsvwg (tsv)
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
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
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
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.
RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001
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
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
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
Source of RFC: sip (rai)
Errata ID: 316
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2003-10-03
In Section 25.1:
digest-uri-value = rquest-uri ; Equal to request-uri as
specified by HTTP/1.1
It should say:
digest-uri-value = request-uri ; Equal to request-uri as
specified by HTTP/1.1
Errata ID: 1051
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexandre Machado
Date Reported: 2007-08-23
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 25.1 says:
srvr = [ [ userinfo "@" ] hostport ]
It should say:
srvr = [ [ userinfo ] hostport ]
Notes:
The character "@" should not appear in this rule since it already appears at the end of the rule "userinfo":
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
According to the use of rule "userinfo" in other rules such as "SIP-URI" and "SIPS-URI", the correct place of character "@" is really at the end of rule "userinfo" and not in all other rules using it.
Errata ID: 1073
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Ambu
Date Reported: 2005-12-15
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
I would like to show you an error in RFC 3261. I've discussed in SIP-implementors mailing list too. in RFC 3261 page 44 par 8.1.3.4 there is an example of URI (contact URI) with uri headers: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> I've noticed that URI header "Call-Info" has a value with characters not allowed in uri headers. The BNF says that an header value must contain characters in hnv-unreserved or unreserved or escaped but '<' and '>' are not in that set. The right example should be the following: sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1470
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 17.2.2 says:
If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction MUST enter the "Completed" state...
It should say:
If the TU passes a final response (status codes 200-699) to the server while in the "Trying" or "Proceeding" state, the transaction MUST enter the "Completed" state...
Notes:
"17.2.2 Non-INVITE Server Transaction" doesn't consider the case in which the transaction state is "Trying" and the transaction receives from the TU a final response.
It's totally possible that TU sends a final response without sending before a provisional response. Note that this case is perfectly valid in the diagram of page 139.
Errata ID: 3183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno CHATRAS
Date Reported: 2012-04-10
Verifier Name: Robert Sparks
Section 23.4.3 says:
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
It should say:
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Notes:
A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.
This was discussed on both the SIP Implementors and SIP Core mailing lists.
Errata ID: 4567
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2015-12-17
Verifier Name: Ben Campbell
Date Verified: 2015-12-17
Section 20.11 says:
The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19].
It should say:
The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of "optional" and "required". If the handling parameter is missing, or if the Content-Disposition header field is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19].
Errata ID: 2051
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23
Section 26.3.1 says:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
It should say:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to the DNS name other SIP devices will use to reach them.
Notes:
The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.
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
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
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
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
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
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
Source of RFC: dhc (int)
Errata ID: 294
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 20.1.2 says:
The relay agent copies the source address from the IP datagram in which the message was received from the client into the peer-address field in the Relay-forward message and sets the hop-count field to the value of the hop-count field in the received message incremented by 1.
It should say:
The relay agent copies the source address from the IP datagram in which the message was received from the relay agent into the peer-address field in the Relay-forward message and sets the hop-count field to the value of the hop-count field in the received message incremented by 1.
Notes:
Errata ID: 2472
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 17.2.2 says:
If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID.
It should say:
If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes the IA containing a Status Code option with status code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. The server SHOULD include other stateful IA options (like IA_PD) and other configuration options in the Advertise message.
Errata ID: 2471
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 17.1.3 says:
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user.
It should say:
The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user.
Errata ID: 1373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Marks
Date Reported: 2008-03-19
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 22.17 says:
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
option-data An opaque object of option-len octets,
interpreted by vendor-specific code on the
clients and servers
It should say:
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
option-data An opaque object,
interpreted by vendor-specific code on the
clients and servers
Notes:
option-len is defined to be the size of the option-data + 4. Thus the size of option-data cannot option-len, but is actually option-len - 4.
Errata ID: 2928
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2011-08-09
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 17.2.1 says:
For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message.
It should say:
For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see section 22.20) in the Solicit message, the servers discard the Solicit message.
Errata ID: 1815
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michelle Cotton
Date Reported: 2009-07-22
Verifier Name: Brian Haberman
Date Verified: 2012-07-29
Section 26 says:
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers.html.
It should say:
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers
Notes:
The URL for the enterprise numbers registry is incorrect.
Errata ID: 3577
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pablo Armando
Date Reported: 2013-03-31
Verifier Name: Ted Lemon
Date Verified: 2013-04-02
Section 9.3 says:
An example DUID of this type might look like this: +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 0 | 0 | 9| 12|192| +---+---+---+---+---+---+---+---+ |132|221| 3 | 0 | 9 | 18| +---+---+---+---+---+---+ This example includes the two-octet type of 2, the Enterprise Number (9), followed by eight octets of identifier data (0x0CC084D303000912).
It should say:
An example DUID of this type might look like this: +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 0 | 0 | 9| 12|192| +---+---+---+---+---+---+---+---+ |132|211| 3 | 0 | 9 | 18| +---+---+---+---+---+---+ This example includes the two-octet type of 2, the Enterprise Number (9), followed by eight octets of identifier data (0x0CC084D303000912).
Notes:
0xD3 is 211 decimal, not 221.
I am assuming that this number is the correct one: 0x0CC084D303000912
RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002
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.
RFC 3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003
Source of RFC: sip (rai)
Errata ID: 3799
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14
Section Appendix A says:
spivalue = 10DIGIT; 0 to 4294967295
It should say:
spivalue = 1*10DIGIT; 0 to 4294967295
Notes:
The number string does not have to have 10 digit characters if the number is not 10 digits in length.
RFC 3339, "Date and Time on the Internet: Timestamps", July 2002
Source of RFC: impp (app)
Errata ID: 4110
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Derek P. Moore
Date Reported: 2014-09-12
Verifier Name: Barry Leiba
Date Verified: 2014-09-29
Section Appendix A says:
ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 gives examples where the decimal fractions are not preceded by a "0". This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is in error.
It should say:
ISO 8601/Cor1:1991 also requires (in section 5.3.1.3) that a decimal fraction be proceeded by "00" if less than unity.
Notes:
ISO 8601:1988/Cor 1:1991 says:
"Subclause 5.3.1.3
"Last line, delete “shall be preceded by a zero” and insert “shall be preceded by two zeros in accordance with 4.6” "
The RFC3339 grammar never allowed just one zero ("0") preceding the fraction and has always been compliant with ISO 8601/Cor 1:1991.
----- Note from the RFC authors -----
There are interpretations of ISO 8601 under which section 5.3.1.3 and Annex B.2 are entirely consistent, and the implication that they are in conflict can cause confusion.
----- Note from the Area Director -----
There is a newer version of the ISO spec, ISO 8601:2004. That version came after this RFC, so it cannot be a definitive reference with respect to this RFC, but readers should be aware of the newer version.
Errata ID: 293
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2005-05-26
Section 5.1 says:
The presence of optional punctuation would violate this characteristic.
It should say:
If the format allows optional punctuation or white space then this characteristic can be violated.
Notes:
In Appendix A, it says:
Time:
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
It should say:
Time:
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
/ timespec-midnight
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
In the third paragraph of Appendix A, it states "ISO 8601 is not clear on
whether an hour of 24 is permissible only if minutes and seconds are 0.
This assumes that an hour of 24 is permissible in any context."
This is clarified in the 2000 edition which says:
5.3 Time of the day
The representation of the hour by [24] is only allowed to indicate
midnight, see 5.3.2.
That would result in the following ABNF change:
time-hour = 2DIGIT ; 00-23
and additions:
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]
timespec-base =/ timespec-midnight
Errata ID: 1584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2008-11-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section Appendix A says:
Note that due to ambiguities in ISO 8601, some interpretations had to be made. First, ISO 8601 is not clear if mixtures of basic and extended format are permissible. This grammar permits mixtures.
It should say:
This grammar permits mixtures of basic and extended format.
Notes:
ISO 8601:2000 section 5.4.2 reads:
d) the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format, in which case additional separators shall be used in accordance with 5.2 and 5.3.
(There is similar text in section 4.3.3 of ISO 8601:2004)
Errata ID: 3710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas B
Date Reported: 2013-08-26
Verifier Name: Barry Leiba
Date Verified: 2013-08-26
Section 6 says:
[IERS] International Earth Rotation Service Bulletins,
<http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
It should say:
[IERS] International Earth Rotation Service Bulletins,
<http://hpiers.obspm.fr/eop-pc/products/bulletins
/bulletins.html>.
Notes:
Original link is missing a "bulletins/" before the terminal "bulletins.html".
This leads to a 404
RFC 3345, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", August 2002
Source of RFC: idr (rtg)
Errata ID: 3787
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-05
Verifier Name: Stewart Bryant
Date Verified: 2014-01-16
Section 2.1 says:
1) Ra has the following installed in its BGP table, with the path
learned via AS2 marked best:
It should say:
1) Ra has the following installed in its BGP table, with the path
learned via AS10 marked best:
Notes:
The above text is related to a discussion of topology depicted in Figure 1. This figure does not have AS2 at all. The text should refer to AS10 instead.
RFC 3348, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", July 2002
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 2020
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Barry Leiba
Date Reported: 2010-01-26
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10
Section 3 says:
In some instances a server that supports the CHILDREN extension MAY NOT be able to determine whether a mailbox has children.
It should say:
In some instances a server that supports the CHILDREN extension might not be able to determine whether a mailbox has children.
Notes:
The "may not" in this sentence is not normative text, but is just a statement of fact. It should not be rendered as an RFC 2119 term.
RFC 3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", August 2002
Source of RFC: dnsext (int)
Errata ID: 1680
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01
Section "Bitlabels" says:
addresses, it proposes to use a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS.
It should say:
addresses, it proposes to use a new kind of DNS label (a "bit label"), specified in [RFC2673], to represent binary addresses directly in the DNS. *** RFC 2673 should also appear in the References section.***
Notes:
This document is listed as updating RFC 2673. That claim is actually dubious, since it simply explains why one particular application of 2673 may not be appropriate, an application that is not even mentioned in 2673 itself. But, if it does actually update 2673, then it should be possible for the reader to deduce how the two document interact without extensive detective work.
An alternative fix would be to remove the entry indicating updating of 2673 from the header of this document and corresponding indexes and references -- what this actually updates is 2874, which specifies a particular application of 2673.
RFC 3369, "Cryptographic Message Syntax (CMS)", August 2002
Note: This RFC has been obsoleted by RFC 3852
Source of RFC: smime (sec)
Errata ID: 291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2003-03-03
Several object identifiers (OIDs) have been omitted from the ASN.1 module in section 12.1; however, these OIDs are fully discussed in the body of the document. On page 46 of RFC 3369, the following object identifiers need to be inserted before the end o
-- Content Type Object Identifiers
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
Errata ID: 292
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2003-01-23
Section 13 says:
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3269, August 2002.
It should say:
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
Errata ID: 290
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2004-03-12
Section 12.2 says:
AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
Notes:
The tagging should be EXPLICIT instead of IMPLICIT.
RFC 3370, "Cryptographic Message Syntax (CMS) Algorithms", August 2002
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
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 (tsv)
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 (tsv)
Errata ID: 6981
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2022-05-26
Verifier Name: RFC Editor
Date Verified: 2022-06-16
Section 2.7.1 says:
It is the claim here (see remarks in section 1.3) that the effects
of skew are rather small over the time scales that we are
discussing here, since temperature variations in a system tend to
be slow relative to packet inter-transmission times and the range
of drift is so small.
It should say:
It is the claim here (see remarks in section 1.4) that the effects
of skew are rather small over the time scales that we are
discussing here, since temperature variations in a system tend to
be slow relative to packet inter-transmission times and the range
of drift is so small.
Notes:
Incorrect reference - 1.3 instead 1.4
RFC 3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm", September 2002
Source of RFC: smime (sec)
Errata ID: 3671
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Garron
Date Reported: 2013-06-26
Verifier Name: Sean Turner
Date Verified: 2013-08-14
Section 2.2.3.1 says:
If unwrapping produces A[0] any other value,
It should say:
If unwrapping produces A[0] equal to any other value,
Notes:
This resembles a copy-paste typo, where the last portion of "If unwrapping produces A[0]" was not removed in the second of two sentences.
I edited this based on comments from the authors.
Errata ID: 5777
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Timko
Date Reported: 2019-07-10
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20
Section 2.2.1 says:
1) Initialize variables.
Set A0 to an initial value (see 2.2.3)
For i = 1 to n
R[0][i] = P[i]
It should say:
1) Initialize variables.
Set A[0] to an initial value (see 2.2.3)
For i = 1 to n
R[0][i] = P[i]
Notes:
An array subscript notation should be used for A[]
RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002
Source of RFC: urn (app)
Errata ID: 283
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Olaf M. Kolkman
Date Reported: 2005-12-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02
Section 5 says:
Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]
It should say:
Part Three: The Domain Name System (DNS) Database" (RFC 3403) [2]
RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002
Source of RFC: urn (app)
Errata ID: 282
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-10-05
Section 4.5 says:
See the Additional Information Processing section of RFC 3404 for more information on NAPTR records and the Additional Information section of a DNS response packet.
It should say:
See the Additional Information Processing section of RFC 3403 for more information on NAPTR records and the Additional Information section of a DNS response packet.
Notes:
wrong reference to RFC 3404 (must be RFC 3403)
Errata ID: 787
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-10-05
Section 5.1 says:
There is opportunity for significant optimization here. RFC 3404 defines that Additional Information section may be available. In this case the the SRV records may be returned as additional information for terminal NAPTRs lookups (as well as the A records for those SRVs). This is a significant optimization.
It should say:
There is opportunity for significant optimization here. RFC 3403
defines that Additional Information section may be available. In
this case the the SRV records may be returned as additional
information for terminal NAPTRs lookups (as well as the A records for
those SRVs). This is a significant optimization.
Notes:
wrong reference to RFC 3404 (must be RFC 3403)
from pending
RFC 3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002
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 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
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).
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
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: 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 (tsv)
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 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003
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.
RFC 3464, "An Extensible Message Format for Delivery Status Notifications", January 2003
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.
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
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
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
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
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
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: Legacy
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 3516, "IMAP4 Binary Content Extension", April 2003
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 (tsv)
Errata ID: 2613
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
When an OPEN is done and the specified lockowner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same lockowner.
It should say:
When an OPEN is done and the specified owner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same owner.
Notes:
The 'lockowner' should be replaced by 'owner' (twice in the paragraph). The lockowner is not related to the OPEN operation. Instead, the owner (open_owner) is related.
Errata ID: 2614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the OPEN operation from which the open_confirm value was obtained. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
It should say:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the previous OPEN operation. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
Notes:
The OPEN operation does not return the open_confirm value.
Errata ID: 2637
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current lock, open, or delegation state for any files
and have not been used recently.
It should say:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current open state for any files
and have not been used recently.
Notes:
A lock can be held on already opened files only. This means that every lock state can exist only in case the accompanied open state is already there.
So if there is a lock state held by server then there must be an open state for the file too. This means that we do not need to mention the "current lock state" in the RFC's sentence above.
Next, the delegation state is allocated only in case the delegation is granted by server to a client for a file. The delegation state is related to file and client. It is not related/tied to openowner. This means that it is not possible to test whether an openowner have any delegation states. Delegation states are simply not related to the openowner.
It is easily possible to have a client with some delegation granted with no valid openowner held by a server.
Errata ID: 2663
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-12-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 8.11. says:
When an OPEN is done for a file and the lockowner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
It should say:
When an OPEN is done for a file and the open_owner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
Notes:
The file opens are related to open_owners, not lockowners. The lockowner
should be replaced by open_owner in the first sentence of the paragraph above.
Errata ID: 255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Bauman
Date Reported: 2004-02-03
Section 8.1.8. says:
This sequence establishes the use of an lock_owner and associated sequence number. Should be "a lock_owner"
It should say:
If server replica or a server immigrating a filesystem agrees to Should be "If a server replica"
Notes:
In Section 9.3.2. Data Caching and File Locking, Last Paragraph:
by flushing to the server more data upon an LOCKU than is covered by
the locked range.
Should be "a LOCKU"
Errata ID: 2609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.11. says:
SYNOPSIS
(cfh) locktype, offset, length owner -> {void, NFS4ERR_DENIED ->
owner}
It should say:
SYNOPSIS
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner}
Notes:
Missing comma in the LOCKT synopsis.
Errata ID: 2610
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, open_confirm, attrset delegation
It should say:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, attrset, delegation
Notes:
i) The open_confirm should be removed (it is not a part of the OPEN4resok structure).
ii) There is missing command between attrset and delegation.
Errata ID: 2638
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).
It should say:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN).
Notes:
The FH4_NO_EXPIRE_WITH_OPEN should be replaced with FH4_NOEXPIRE_WITH_OPEN.
Errata ID: 2639
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOL_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOL_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOL_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
It should say:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOLATILE_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
Notes:
The FH4_VOL_ANY should be replaced with FH4_VOLATILE_ANY (three times).
RFC 3533, "The Ogg Encapsulation Format Version 0", May 2003
Source of RFC: INDEPENDENT
Errata ID: 6796
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gang Zhao
Date Reported: 2021-12-25
Verifier Name: Adrian Farrel
Date Verified: 2021-12-27
Section 5 says:
Page_1 consists of the first three segments of packet_1, page_2 contains the remaining 2 segments from packet_1, and page_3 contains the first three pages of packet_2.
It should say:
Page_1 consists of the first three segments of packet_1, page_2 contains the remaining 2 segments from packet_1, and page_3 contains the first three segments of packet_2.
Notes:
The last part of this sentence used "three pages" which should be "three segments". As package is divided into segments.
RFC 3537, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", May 2003
Source of RFC: vgmib (int)
Errata ID: 254
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2004-10-14
Section 3.4 says:
PAD : 38be62
It should say:
PAD : be62fe
Notes:
RFC 3542, "Advanced Sockets Application Program Interface (API) for IPv6", May 2003
Source of RFC: ipv6 (int)
Errata ID: 253
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hideaki Yoshifuji
Date Reported: 2005-06-26
Section 11.3 says:
This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may receive an IPV6_MTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node.
It should say:
This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may receive an IPV6_PATHMTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node.
Notes:
Change: IPV6_MTU should be IPV6_PATHMTU.
Errata ID: 252
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tatuya JINMEI
Date Reported: 2004-02-12
In section 10.2 (page 41), the RFC says:
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint_t align,
void **databufp);
It should say:
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint8_t align,
void **databufp);
Notes:
Similarly, the following part of Section 15 (page 55)
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t, uint_t,
void **);
Should actually be:
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t,
uint8_t, void **);
That is, "uint_t" should be replaced with "uint8_t".
RFC 3548, "The Base16, Base32, and Base64 Data Encodings", July 2003
Note: This RFC has been obsoleted by RFC 4648
Source of RFC: INDEPENDENT
Errata ID: 3916
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daira Hopwood
Date Reported: 2014-03-10
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22
Section References says:
[12] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
http://zgp.org/pipermail/p2p-hackers/2001-September/
000315.html, September 2001.
It should say:
[8] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
http://zgp.org/pipermail/p2p-hackers/2001-September/
000313.html, September 2001.
Notes:
Noticed by Zancas Wilcox.
This erratum was submitted as a correct to reference [12], however
RFC 3548 has it as [8].
RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003
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"
RFC 3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003
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
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
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 }