|
|
|
|
Published RFCs never change. Although every published RFC has been submitted to careful proofreading by the RFC Editor and the author(s), errors do sometimes go undetected.
Note that this list of errata may include both verified and unverified errata. Those marked "Verified" have been approved by the authors or the relevant party (e.g., the IESG for IETF documents). Those marked "Reported" have not yet been verified.
To report errata, please use the Errata Query Form.
Source of RFC: Legacy
Errata ID: 2061
Status: Reported
Type: Editorial
Reported By: Hsu Yun-Che
Date Reported: 2010-03-03
Section Title says:
[unknown title] [page 1 missing]
It should say:
HOST SOFTWARE [page 1 missing]
Notes:
RFC0002 was actually titled "HOST SOFTWARE".
This missing historical information is provided by RFC0003.
Source: http://tools.ietf.org/html/rfc3
---------------------------------
RFC-3 "DOCUMENTATION CONVENTIONS"
Section: "OTHER NOTES"
Quote:
"Two notes (1 & 2) have been written so far. These are both titled HOST Software and are by Steve Crocker and Bill Duvall, separately."
Source of RFC: Legacy
Errata ID: 582
Status: Verified
Type: Editorial
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.
Source of RFC: Legacy
Errata ID: 581
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1053
Status: Reported
Type: Technical
Reported By: Noel Chiappa
Date Reported: 2007-08-13
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: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Throughout the document, when it says:
RFMN
It should say:
RFNM
Notes:
This typo occurs twice on page 4.
Source of RFC: Legacy
Errata ID: 1781
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Section I says:
singify
It should say:
signify
Errata ID: 1782
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Section II says:
wre
It should say:
were
Source of RFC: Legacy
Errata ID: 1784
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-15
Throughout the document, when it says:
"cease on link" flow control scheme proposed in RFC 35 by UCLA
It should say:
"cease on link" flow control scheme proposed in RFC 36 by UCLA
Source of RFC: Legacy
Errata ID: 1772
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-04
Throughout the document, when it says:
On 12 August 70, I met a BBN with representatives from BBN and MIT and we discussed third llevel protocol.
It should say:
On 12 August 70, I met a BBN with representatives from BBN and MIT and we discussed third level protocol.
Source of RFC: Legacy
Errata ID: 1814
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-07-20
Section header says:
Metcalff
It should say:
Metcalfe
Source of RFC: Legacy
Errata ID: 580
Status: Verified
Type: Editorial
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
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
Source of RFC: Legacy
Errata ID: 716
Status: Reported
Type: Technical
Reported By: Damien Mattei
Date Reported: 2007-01-03
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: 579
Status: Verified
Type: Editorial
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
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: 578
Status: Reported
Type: Editorial
Reported By: Yin Shuming
Date Reported: 2006-02-18
Section 3.2 says:
Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).
It should say:
Note that this is consistent with the datagram total length field (of course, the header is counted in the total length and not in the fragments).
Source of RFC: Legacy
Errata ID: 577
Status: Verified
Type: Technical
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
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: 1231
Status: Reported
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-01-04
Section Introduction says:
no ICMP messages are sent about ICMP messages
It should say:
no ICMP messages are sent about ICMP error messages
Notes:
For instance, echo replies are sent about echo messages. The context of the original sentence indicates that the author only referred to error messages but the sentence itself is not clear and I've seen the editorial error reproduced in some places.
Errata ID: 1703
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-02
Section p.14 says:
IP Fields:
Type
8 for echo message;
It should say:
ICMP Fields:
Type
8 for echo message;
Source of RFC: Legacy
Errata ID: 573
Status: Verified
Type: Technical
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 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: 1496
Status: Reported
Type: Technical
Reported By: Yin Shuming
Date Reported: 2008-08-27
Section 3.9 says:
CLOSE CALL
CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter CLOSING state.
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
Respond with "error: connection closing".
It should say:
CLOSE CALL
CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter LAST-ACK state.
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
Respond with "error: connection closing".
Notes:
In Page 23,Figure 6."TCP Connection State Diagram",illustrates the state change from "CLOSE-WAIT" TO "LAST-ACK",together with the causing event "CLOSE".
Errata ID: 1561
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.2 says:
LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP
(which includes an acknowledgment of its connection termination
request).
It should say:
LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP
(The connection termination request sent to the remote TCP included
an acknowledgment of the connection termination request sent from
the remote TCP).
Notes:
It is unclear what 'which' and 'its' refers to.
Errata ID: 1562
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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 implicitly included control 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 implicitly included control flags of the last emitted segment,
Errata ID: 1563
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.4 says:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
It should say:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptable acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection, a reset is sent and
the connection goes to the CLOSED state.
If the incoming segment has the ACK bit set, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
A SYN with a sequence number inside the receive window yields a
reset, too.
Notes:
Four errors, two editorial and two technical
1. Typo unacceptibla -> unacceptable
2. wrong spacing and missing 'the'
3. The ACK bit should be set. But this check comes later. See page 71.
4. According to page 71 a SYN can cause a reset, too.
Errata ID: 1564
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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 imlicitly included control 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: 1565
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.8 says:
TCP/Lower-Level Interface
Type of Service = Precedence: routine, Delay: normal, Throughput:
normal, Reliability: normal; or 00000000.
It should say:
TCP/Lower-Level Interface
Type of Service = Precedence, Delay: normal, Throughput:
normal, Reliability: normal; or XXX00000.
where XXX are the three bits determining precedence, e.g. 000
means routine.
Notes:
The precedence is given by the user.
Errata ID: 1566
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.9 says:
OPEN Call
LISTEN STATE
Data associated with SEND may be sent with SYN segment or
queued for transmission after entering ESTABLISHED state. The
urgent bit if requested in the command must be sent with the data
segments sent as a result of this command.
It should say:
OPEN Call
LISTEN STATE
--delete this--
Notes:
This is an OPEN call. There is no data associated with a SEND.
BTW, What WND to set in the SYN segment? Set RCV.WND=1?
Errata ID: 1567
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.9 says:
SEND Call
LISTEN STATE
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment, set
SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. The urgent bit if
requested in the command must be sent with the data segments sent
as a result of this command. If there is no room to queue the
request, respond with "error: insufficient resources". If
Foreign socket was not specified, then return "error: foreign
socket unspecified".
It should say:
SEND Call
LISTEN STATE
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment, set
SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. If data is sent with
the SYN segment, SND.NXT is advanced. The urgent bit if
requested in the command must be sent with the data segments sent
as a result of this command. If there is no room to queue the
request, respond with "error: insufficient resources". If
Foreign socket was not specified, then return "error: foreign
socket unspecified".
Notes:
If data is sent, SND.NXT has to be advanced.
But there are more problems.
What WND to set in the SYN segment? Set RCV.WND=1?
How much data may be put into the segment? There is no SND.WND yet.
What about PUSH? May the data be queued if a PUSH is given?
Errata ID: 1568
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.9 says:
SEGMENT ARRIVES
If the state is LISTEN then
third check for a SYN
The connection
state should be changed to SYN-RECEIVED. Note that any other
incoming control or data (combined with SYN) will be processed
in the SYN-RECEIVED state, but processing of SYN and ACK should
not be repeated.
fourth other text or control
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. An incoming RST segment could not be valid, since
it could not have been sent in response to anything sent by this
incarnation of the connection. So you are unlikely to get here,
If the state is SYN-SENT then
first check the ACK bit
If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and it the segment did not contain a RST.
If the SYN bit is on and the security/compartment and precedence
are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ.
...
Data or controls which were queued for
transmission may be included.
fifth, if neither of the SYN or RST bits is set then drop the
segment and return.
Otherwise,
third check security and precedence
fifth check the ACK field,
SYN-RECEIVED STATE
If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
and continue processing.
If the segment acknowledgment is not acceptable, form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
ESTABLISHED STATE
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response). If the ACK is a duplicate
(SEG.ACK < SND.UNA), it can be ignored. If the ACK acks
something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
drop the segment, and return.
If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
eighth, check the FIN bit,
Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
since the SEG.SEQ cannot be validated; drop the segment and
return.
It should say:
SEGMENT ARRIVES
If the state is LISTEN then
third check for a SYN
??? No idea. But the original does not work.
If there is data in the SYN, we have a problem. We have to be
ESTABLISHED to get a buffer. And in ESTABLISHED the segment will be
dropped, because it has the ACK bit off.
We need to allocate a buffer. It's just for one segment. And we have
to adapt the event handling for the user's RECEIVE call. ???
fourth other text or control
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. So you are unlikely to get here,
If the state is SYN-SENT then
first check the ACK bit
If SND.UNA < SEG.ACK =< SND.NXT then the ACK is acceptable.
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and if the segment did not contain a RST.
If the SYN bit is on, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ.
...
Data or controls which were queued for
transmission may be included and SND.NXT advanced accordingly.
fifth, because neither of the SYN or RST bits is set, drop the
segment and return.
Otherwise,
third check security and precedence
Construct the RST in this way:
If there is an ACK
<SEQ=SEG.ACK><CTL=RST>
Otherwise
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
fifth check the ACK field,
SYN-RECEIVED STATE
If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED state, set
SND.WND <- SEG.WND, SND.WL1 <- SEG.SEQ, SND.WL2 <- SEG.ACK,
and continue processing.
If the segment acknowledgment is not acceptable
(SEG.ACK =< ISS or SEG.ACK > SND.NXT), form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
Drop the segment. Return.
ESTABLISHED STATE
If the ACK is a duplicate (SEG.ACK =< SND.UNA), it can be
ignored. If the ACK acks something not yet sent
(SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
return.
If SND.UNA =< SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
If SND.UNA < SEG.ACK =< SND.NXT, then set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response).
eighth, check the FIN bit,
--delete this--
Notes:
If the state is LISTEN then
fourth other text or control
Incoming RST are already thrown out. Don't diskuss about it here.
If the state is SYN-SENT then
first check the ACK bit
nearly the same as the correction in RFC-1122 4.2.2.20(g)
fourth check the SYN bit
typo it -> if
security/compartment and precedence are already checked. It is no mistake,
but it is superfluous and confusing.
don't forget to advance SND.NXT
fifth
No more testing is necessary. Superfluous testing is confusing.
Otherwise,
third check security and precedence
The ACK bit is not yet checked.
fifth check the ACK field
SYN-RECEIVED STATE
SND.UNA == ISS. SEG.ACK == ISS does not ack our SYN.
SND.WND <- SEG.WND etc is corrected by RFC-1122.
explanation of not acceptable acknowledgment is helpful
'Drop the segment. Return.' is missing, too.
ESTABLISHED STATE
Corrections of RFC-1122 are included.
What about SEG.ACK =< ISS? I reccomend to send an ACK, drop the segment
and return. When SND.NXT overpaces ISS, ISS has to be adjusted somehow,
e.g. ISS <- ISS xor 0x80000000.
The updating of SND.UNA must be in the end, because the comparisations
need the old value of SND.UNA.
eighth, check the FIN bit,
If you are here, you are not in those states.
Errata ID: 1569
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 2.4 says:
The TCP/internet interface provides calls to send and receive datagrams addressed to TCP modules in hosts anywhere in the internet system.
It should say:
The TCP/internet interface provides calls to send datagrams addressed to and receive datagrams addressed from TCP modules in hosts anywhere in the internet system.
Notes:
scnr
Errata ID: 1570
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 2.7 says:
There are two principal cases for matching the sockets in the local passive OPENs and an foreign active OPENs. In the first case, the local passive OPENs has fully specified the foreign socket. In this case, the match must be exact. In the second case, the local passive OPENs has left the foreign socket unspecified. In this case, any foreign socket is acceptable as long as the local sockets match.
It should say:
There are two principal cases for matching the sockets in the local passive OPENs and a foreign active OPEN. In the first case, there is exactly one local passive OPEN with matching local socket that has fully specified the foreign socket. In this case, the match must be exact. In the second case, there is exactly one local passive OPEN with matching local socket that has left the foreign socket unspecified. In this case, any foreign socket is acceptable.
Notes:
In this passage singular or plural make a big difference.
Errata ID: 1571
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Section 3.1 says:
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
It should say:
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field may be sent in the initial connection request
(i.e., in segments with the SYN control bit set) and must not
be sent in other segments. If this option is not used, any
segment size is allowed.
Notes:
'must only' is ambiguous or even senseless.
Errata ID: 1572
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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: 784
Status: Rejected
Type: Technical
Reported By: Ian D. Allen
Date Reported: 2006-09-22
Rejected by: Lars Eggert
Date Rejected: 2008-12-06
Section 3.2 says:
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
It should say:
[not supplied]
Notes:
Compare with RFC 1122:
" 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2,
page 23
There are several problems with this diagram:
(a) The arrow from SYN-SENT to SYN-RCVD should be labeled
with "snd SYN,ACK", to agree with the text on page 68
and with Figure 8."
Either RFC1122 is wrong (in which case *it* needs an Errata entry), or
RFC793 is wrong, in which case *it* needs an Errata entry. They can't
both be right!
Because of the above protocol diagram change given in RFC1122 (and others
in the same section), RFC1122 should also be mentioned as "updating"
RFC793, and RFC793 should be documented as being "updated by" RFC1122.
from pending
--VERIFIER NOTES--
The RFC Editor has been instructed to indicate in their database and web pages that RFC1122 updates RFC0793. This errata has hence been addressed.
Errata ID: 575
Status: Verified
Type: Editorial
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: 574
Status: Verified
Type: Editorial
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: 572
Status: Verified
Type: Editorial
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: 700
Status: Verified
Type: Editorial
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
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
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"
Source of RFC: Legacy
Errata ID: 1769
Status: Reported
Type: Editorial
Reported By: John Klensin
Date Reported: 2009-04-29
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.
Source of RFC: Legacy
Errata ID: 1083
Status: Reported
Type: Technical
Reported By: Peter Backes
Date Reported: 2007-11-21
Section 3.1.4. says:
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
It should say:
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ special
(the) comment
Vegas atom
. special
WBA atom
Notes:
Apparently an artifact introduced by copying and incompletely adapting the example in RFC733, section III.B.e, which uses the atom "at" instead of the special "@".
Errata ID: 1899
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-02
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
Notes:
consistence issue: according to 3.4.4, neither parentheses nor quotation marks are part of the embraced token, so either drop them or include them here, but do not treat them differently.
Source of RFC: Legacy
Errata ID: 571
Status: Reported
Type: Technical
Reported By: SungWoon Lee
Date Reported: 2006-08-18
Section 3 says:
Neither can unilaterally seize control from the other; rather the controlling end must relinguish its control explicitly.
It should say:
Neither can unilaterally seize control from the other; rather the controlling end must relinquish its control explicitly.
Source of RFC: Legacy
Errata ID: 570
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 569
Status: Reported
Type: Technical
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 4 says:
How can the server send an IP datagram to the client, if the client doesnt know its own IP address (yet)?
It should say:
How can the server send an IP datagram to the client, if the client doesn't know its own IP address (yet)?
Source of RFC: Legacy
Errata ID: 568
Status: Verified
Type: Technical
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: 2024
Status: Verified
Type: Editorial
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: 1941
Status: Reported
Type: Editorial
Reported By: Tomasz Kluza
Date Reported: 2009-11-09
Section 3.1.1.5. says:
(...)Therefore, these types have a second parameter
specifying one of the following three formats:
3.1.1.5.1. NON PRINT
(...)
3.1.1.5.2. TELNET FORMAT CONTROLS
(...)
3.1.1.5.2. CARRIAGE CONTROL (ASA)
It should say:
(...)Therefore, these types have a second parameter
specifying one of the following three formats:
3.1.1.5.1. NON PRINT
(...)
3.1.1.5.2. TELNET FORMAT CONTROLS
(...)
3.1.1.5.3. CARRIAGE CONTROL (ASA)
Notes:
Two Sections in the RFC have the same number in the document whereas the The Carriage Control (ASA) should have 3.1.1.5.3. in the structure of the RFC document since its a third format of the possible value for the parameter mention in the statement "Therefore, these types have a second parameter specifying one of the following three formats" ATM it has the same 3.1.1.5.2. as the Telnet Format Controls.
Source of RFC: Legacy
Errata ID: 679
Status: Reported
Type: Technical
Reported By: Anvish
Date Reported: 2002-02-25
I found something strange in rfc1001 Maybe my code is wrong, but it returns "Tge NetBIOS tame" instead of "The NetBIOS name" when I try to encode FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF "For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope "SCOPE.ID.COM" would be represented at level one by the ASCII character string: FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM"
It should say:
[not submitted]
Notes:
from pending
Source of RFC: Legacy
Errata ID: 567
Status: Reported
Type: Editorial
Reported By: Sir Dystic
Date Reported: 2001-04-26
Section 4.2.16 says:
WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NULL (0x0020) | IN (0x0001) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
The values for the first field (the resource record type) are defined above
in section 4.2.1.3. RESOURCE RECORD:
NULL 0x000A NULL Resource Record (See WAIT FOR
ACKNOWLEDGEMENT RESPONSE)
NB 0x0020 NetBIOS general Name Service Resource Record
(See NB_FLAGS and NB_ADDRESS, below)
Notes:
The value for type NULL is defined as 0x000A and the
comment specifically mentions WACK responses. The value shown in the packet
layout is 0x0020, the value for NB resource records, the most common value
for this field. In truth, I can't get Windows boxes to respond to this
packet as documented with either value in that field.
Source of RFC: Legacy
Errata ID: 566
Status: Reported
Type: Editorial
Reported By: "CFeng"
Date Reported: 2002-05-05
Section 7 says:
SRI.COM. NS
*Here-->> KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
It should say:
SRI.COM. NS KL.SRI.COM.
*Here-->> KL.SRI.COM. A 10.1.0.2.
Notes:
You can refer to RR "NS (Name Server)" on Page 6 in the same RFC for the reason.
Source of RFC: Legacy
Errata ID: 564
Status: Verified
Type: Technical
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: 755
Status: Reported
Type: Technical
Reported By: John Kristoff
Date Reported: 2006-03-13
Section 6.1. ends this way: Relative and absolute domain names may be freely intermixed in a master which is incomplete. It's unclear exactly how that sentence may have been intended to end, but minimally I would suggeste it at least terminated with 'file.'. Section 6.2.8. in the diagram shows 'QTYPE=A', but should be of type 'CNAME' based on the context of the example.
It should say:
[see above]
Notes:
from pending
Errata ID: 565
Status: Verified
Type: Editorial
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
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
Source of RFC: vgmib (int)
Errata ID: 562
Status: Verified
Type: Technical
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: 1813
Status: Reported
Type: Technical
Reported By: moritzh
Date Reported: 2009-07-19
Section 5.3 says:
The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:
@ IN SOA VENERA Action\.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA
A A 26.3.0.103
VENERA A 10.1.0.52
A 128.9.0.32
VAXA A 10.2.0.27
A 128.9.0.33
[...]
Note the use of the \ character in the SOA RR to specify the responsible
person mailbox "Action.domains@E.ISI.EDU".
It should say:
The following is an example file which might be used to define the
ISI.EDU zone.and is loaded with an origin of ISI.EDU:
@ IN SOA VENERA Action\.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA
A A 26.3.0.103
VENERA A 10.1.0.52
A 128.9.0.32
VAXA A 10.2.0.27
A 128.9.0.33
[...]
Note the use of the \ character in the SOA RR to specify the responsible
person mailbox "Action.domains@ISI.EDU".
Notes:
The introductory sentence and the following zone definition both correctly refer to the zone ISI.EDU. But the closing sentence noting the usage of "\." in the mailbox name erroneously expands the example to "Action.domains@E.ISI.EDU" instead of "Action.domains@ISI.EDU".
Errata ID: 563
Status: Reported
Type: Editorial
Reported By: Allan Edward Prentice
Date Reported: 2006-03-04
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.
Source of RFC: Legacy
Errata ID: 561
Status: Verified
Type: Technical
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: Reported
Type: Technical
Reported By: Hans Bot
Date Reported: 2009-04-09
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)
Source of RFC: Legacy
Errata ID: 1329
Status: Reported
Type: Technical
Reported By: Mark Taunton
Date Reported: 2008-02-25
Section Frame Format says:
The minimum packet size used with ARP is 24 octets, which is 20
(ARP with 2 octet hardware addresses and 4 octet protocol
addresses) + 8 (LLC+SNAP header) = 24 octets (not including the
MAC header).
It should say:
The minimum packet size used with ARP is 28 octets, which is 20
(ARP with 2 octet hardware addresses and 4 octet protocol
addresses) + 8 (LLC+SNAP header) = 28 octets (not including the
MAC header).
Errata ID: 1330
Status: Reported
Type: Technical
Reported By: Mark Taunton
Date Reported: 2008-02-25
Section Frame Format says:
In typical situations, the packet size used with ARP is 32 octets,
which is 28 (ARP with 6 octet hardware addresses and 4 octet
protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not
including the MAC header).
It should say:
In typical situations, the packet size used with ARP is 36 octets,
which is 28 (ARP with 6 octet hardware addresses and 4 octet
protocol addresses) + 8 (LLC+SNAP header) = 36 octets (not
including the MAC header).
Notes:
Further instance of arithmetic error, previously reported in the preceding paragraph.
Source of RFC: Legacy
Errata ID: 560
Status: Verified
Type: Editorial
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;
Source of RFC: Legacy
Errata ID: 559
Status: Verified
Type: Editorial
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
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: 1740
Status: Reported
Type: Editorial
Reported By: Hannes Hennig
Date Reported: 2009-03-24
Section 2.5 says:
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--
It should say:
| | | | |S| |
| | | | |H| |
| | | | |O|M|F
| | |S| |U|U|o
| | |H| |L|S|o
| |M|O| |D|T|t
| |U|U|M| | |n
| |S|L|A|N|N|o
| |T|D|Y|O|O|t
FEATURE |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--
Same on section 3.5 and 4.2.5.
Notes:
Footnote instead of "Footnotte" in eighth column.
Errata ID: 1936
Status: Reported
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-30
Section 4.2.3.5 says:
(d) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
It should say:
(e) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
Notes:
The paragraph numbering got out of sequence. Letter (d) was used twice.
Source of RFC: Legacy
Errata ID: 558
Status: Verified
Type: Technical
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: 1081
Status: Rejected
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14
Section 2.1 says:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
It should say:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.
Notes:
RFC 3696 section 2 states: "There is an additional rule that essentially requires that top-level domain names not be all-numeric." The eleven IDN test TLDs created in September 2007 contain hyphen-minus as specified in the IDNA RFCs.
--VERIFIER NOTES--
This errata is in conflict with errata 1353. A new I-D and community consensus are probably needed.
Errata ID: 1353
Status: Rejected
Type: Technical
Reported By: John Klensin
Date Reported: 2008-03-08
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14
Section 2.1, ID 1081 says:
Errata ID 1081, reported 2007-11-20, identifies a problem with the
evolution of naming of top-level domains and the text of RFC 1123.
It reads:
Section 2.1 says:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
It should say:
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.
Notes:
RFC 3696 section 2 states: "There is an additional rule that
essentially requires that top-level domain names not be
all-numeric." The eleven IDN test TLDs created in
September 2007 contain hyphen-minus as specified in the
IDNA RFCs.
It should say:
However, a valid host name can never have the dotted-decimal form #.#.#.#, since this change does not permit the highest-level component label to start with a digit even if it is not all-numeric.
Notes:
This is a correct identification of the problem, but the wrong fix. RFC 3696, which ID 1081 cites, is an informational document that is deliberately relaxed about the fine details and says so. It is not relevant to determination of the text that should have been (with perfect knowledge of the future) in 1123.
Based on discussions when we were doing RFC 1591 and subsequently, the expectation then (and presumably when 1123 was written) was that the name of any new TLD would follow the rules for the existing ones, i.e., that they would be exactly two or three characters long and be all-alphabetic (which is exactly what 1123 says). The slightly-odd "will be" language in 1123 was, I believe, because that restriction was expected to be enforced by IANA, rather than being a protocol issue. ICANN, with a different set of assignment policies, effectively eliminated the length rule with the TLDs allocated in 2000. IDNA (RFC 3490) uses a syntax for IDNs that requires embedded hyphens in TLDs if there were ever to be an actual IDN TLD (hence the comment in ID 1081 about the IANA IDN testbed).
While the proposed correction in Errata ID 1081 would fix the problem by imposing the narrowest possible restriction ("not all-numeric"), the original host name rule and the original statement in 1123 both assume the possibility of a minimal check to differentiate between domain names and IP addresses, i.e., checking the first digit only. Because I believe that there are probably implementations that depend on such minimal parsing --some probably ancient and embedded-- it would appear to be wise to relax the rule as little as possible and, in particular, to restrict the "leading digit" exception to domains below the top-level, as 1123 effectively does.
The suggested text above reflects that reasoning. Because of the possible consequences of this issue, I would hope that it would be discussed with the relevant DNS-related WGs, the Root Server Advisory Committee (RSAC), and with IANA for comment and as a heads-up. This issue is substantive enough that it should probably be dealt with by a document that explicitly updates 1123 and that is processed on the Standards Track, but an accurate statement in the errata is the next-best option until that can be done. In the interim and while this suggestion is being discussed, Errata ID 1081 should probably be taken out of "validated" status.
--VERIFIER NOTES--
This errata is in conflict with errata 1081. A new I-D and community consensus are probably needed.
Errata ID: 584
Status: Verified
Type: Editorial
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
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.
Source of RFC: Legacy
Errata ID: 1817
Status: Reported
Type: Editorial
Reported By: Steve Conner
Date Reported: 2009-07-23
Section all says:
Notes:
The PDF file was generated with the pages in reverse order.
Source of RFC: Legacy
Errata ID: 557
Status: Verified
Type: Technical
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)
Source of RFC: Legacy
Errata ID: 556
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1478
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2008-07-23
Section 2 says:
you can discover it's Internet address
It should say:
you can discover its Internet address
Notes:
should be possessive not contractive.
Source of RFC: Legacy
Errata ID: 683
Status: Reported
Type: Technical
Reported By: Joerg Ammon
Date Reported: 2003-03-04
Section 3.3 says:
In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a standard procedure for deriving NSAP-addresses for IS in IP-only environments. However, the DFI as well as the AA are defined to be 'xx' and 'xx xx xx' respectively, which represents neither a valid decimal nor hexadecimal value.
It should say:
[not submitted]
Notes:
from pending
Source of RFC: Legacy
Errata ID: 1843
Status: Reported
Type: Technical
Reported By: Magnus Fromreide
Date Reported: 2009-08-29
Section 4 says:
IMPORTS
enterprises
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC1212;
It should say:
IMPORTS
enterprises
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC1212
DisplayString
FROM RFC1213-MIB;
Notes:
The object smuxPdescription is declared as a DisplayString but that name isn't imported.
I choose to take DisplayString from RFC1213-MIB since that is where it existed at the time.
Source of RFC: osids (app)
Errata ID: 1398
Status: Reported
Type: Editorial
Reported By: Christopher Witkowski
Date Reported: 2008-03-30
Section all says:
see Notes below
It should say:
see Notes below
Notes:
In the PDF version (from RFC-all.zip downloaded on 2008.03.20 15:15 EDT)
the letter spacing is screwed up. Some letters overlap each other while
others have too much space between them. This is in Adobe Reader 6.0.1 in
Windows 98 SE. The PDF starts with %PDF-1.1 so my software can't be too
old. The PostScript version displays OK and I can convert it to a PDF that
also displays OK so I think you just need to retry the conversion.
I've put a screen capture of what I see at:
http://web.ncf.ca/ab234/Capture-03-31-0001.png
Source of RFC: osids (app)
Errata ID: 1397
Status: Reported
Type: Editorial
Reported By: Christopher Witkowski
Date Reported: 2008-03-30
Section all says:
I get an error if I don't fill in this field
It should say:
or this field. So just ignore this and read the Notes.
Notes:
In the PDF version (from RFC-all.zip downloaded on 2008.03.20 15:15 EDT)
the letter spacing is screwed up. Some letters overlap each other while
others have too much space between them. This is in Adobe Reader 6.0.1 in
Windows 98 SE. The PDF starts with %PDF-1.1 so my software can't be too
old. The PostScript version displays OK and I can convert it to a PDF that
also displays OK so I think you just need to retry the conversion.
I've put a screen capture of what I see at:
http://web.ncf.ca/ab234/Capture-03-30-0001.png
Source of RFC: pem (sec)
Errata ID: 554
Status: Verified
Type: Technical
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
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.
Source of RFC: pem (sec)
Errata ID: 552
Status: Verified
Type: Technical
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: 550
Status: Verified
Type: Technical
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
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: 585
Status: Verified
Type: Technical
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). */
Errata ID: 553
Status: Reported
Type: Technical
Reported By: Gennaro Prota
Date Reported: 2006-11-15
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);
Source of RFC: bgp (rtg)
Errata ID: 1434
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-06-07
Held for Document Update by: Ross Callon
Section 3.3.1 says:
[Footnote: Although a domain's selection policies are not explicitly distributed, they have an impact on the routes available to other domains. A route that may be preferred by a particular domain, and not prohibited by transit restrictions, may still be unavailable due to the selection policies of some intermediate domain. The ability to compute and install alternative routes that may be lost using hop-by-hop routing (either LS of PV) is the critical functionality provided by SDR.].
It should say:
[Footnote: Although a domain's selection policies are not explicitly distributed, they have an impact on the routes available to other domains. A route that may be preferred by a particular domain, and not prohibited by transit restrictions, may still be unavailable due to the selection policies of some intermediate domain. The ability to compute and install alternative routes that may be lost using hop-by-hop routing (either LS or PV) is the critical functionality provided by SDR.].
Source of RFC: Legacy
Errata ID: 549
Status: Reported
Type: Editorial
Reported By: Jean Delvare
Date Reported: 2002-07-08
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.
Source of RFC: Legacy
Errata ID: 1712
Status: Reported
Type: Editorial
Reported By: Andy
Date Reported: 2009-03-11
Section 3 says:
Acknowlegements
It should say:
Acknowledgements
Source of RFC: ident (sec)
Errata ID: 548
Status: Verified
Type: Editorial
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
Source of RFC: IESG ()
Errata ID: 547
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1823
Status: Reported
Type: Editorial
Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
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.
Source of RFC: Legacy
Errata ID: 1755
Status: Reported
Type: Editorial
Reported By: Samuel Bronson
Date Reported: 2009-04-03
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.
Source of RFC: dhc (int)
Errata ID: 546
Status: Verified
Type: Technical
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.
Source of RFC: dhc (int)
Errata ID: 545
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1084
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Section Public vs... says:
it it is possible to "intercept" the search by matching against an
It should say:
it is possible to "intercept" the search by matching against an
Errata ID: 1085
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Section Solution(s) says:
starburst,astro.DESERTU.EDU,
It should say:
starburst.astro.DESERTU.EDU, (only 90% sure about this change)
Source of RFC: Legacy
Errata ID: 544
Status: Verified
Type: Technical
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".)
Source of RFC: pppext (int)
Errata ID: 543
Status: Reported
Type: Editorial
Reported By: Stuart Cheshire
Date Reported: 2006-09-27
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.
Source of RFC: pppext (int)
Errata ID: 542
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1404
Status: Reported
Type: Editorial
Reported By: Harald Tveit Alvestrand
Date Reported: 2008-04-03
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.
Source of RFC: Legacy
Errata ID: 541
Status: Reported
Type: Technical
Reported By: "Coleman, Arthur"
Date Reported: 2006-03-09
Section 3 says:
the definitions for Latitude and Longitude are swapped.
I believe this can be considered a typo as the actual values in the
resource record can (and should) be kept in their current order.=20
The correct descriptions are (in general terms):=20
Latitude is the degrees North or South of the Equator and can be
referenced with a range of -90 to +90.=20
Longitude is the degrees East or West of the prime meridian and can
be referenced with a range of -180 to +180.
Below is my attempt to write the errata. If someone wants to make
suggestion about how the errata should be written, please tell me and I
will make a go at doing it as requested.
Art Coleman acoleman@verisign.com
In RFC 1712 the terms Latitude and Longitude are swapped in that each
was given the other's definition. =20
Also the preferred order of the terms is Latitude then Longitude. In
addition to matching the terms with their correct definitions, this
ordering is also addressed.
In Section 3, page 3 is a table, it says:
MSB LSB=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LONGITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LATITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ ALTITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
It should say:
MSB LSB=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LATITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LONGITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ ALTITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.
In Section 3, page 3 under 'where:', it says:
LONGITUDE The real number describing the longitude encoded as a=20
printable string. The precision is limited by 256 charcters
within the range -90..90 degrees. Positive numbers=20
indicate locations north of the equator.
LATITUDE The real number describing the latitude encoded as a=20
printable string. The precision is limited by 256 charcters=20
within the range -180..180 degrees. Positive numbers=20
indicate locations east of the prime meridian.
Is should say:
LATITUDE The real number describing the latitude encoded as a=20
printable string. The precision is limited by 256 characters
within the range -90..90 degrees. Positive numbers=20
indicate locations north of the equator.
LONGITUDE The real number describing the longitude encoded as a=20
printable string. The precision is limited by 256
characters=20
within the range -180..180 degrees. Positive numbers=20
indicate locations east of the prime meridian.
Rational: to match the terms with their correct definitions, and fix the
spelling of the word 'characters'.
In Section 4, page 3, it says:
GPOS has the following format:=20
<owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
It should say:
GPOS has the following format:=20
<owner> <ttl> <class> GPOS <latitude> <longitude> <altitude>
Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.
In Section 4, page 4, it says:
The owner, ttl, and class fields are optional and default to the last
defined value if omitted. The longitude is a floating point number=20
ranging from -90 to 90 with positive values indicating locations=20
north of the equator. For example Perth, Western Australia is=20
located at 32^ 7` 19" south of the equator which would be specified=20
as -32.68820. The latitude is a number ranging from -180.0 to 180.0.
For example Perth, Western Australia is located at 116^ 2' 25" east=20
of the prime meridian which would be specified as 116.86520. Curtin=20
University, Perth is also 10 meters above sea-level.
It should say:
The owner, ttl, and class fields are optional and default to the last
defined value if omitted. The latitude is a floating point number=20
ranging from -90 to 90 with positive values indicating locations=20
north of the equator. For example Perth, Western Australia is=20
located at 32^ 7` 19" south of the equator which would be specified=20
as -32.68820. The longitude is a number ranging from -180.0 to
180.0.=20
For example Perth, Western Australia is located at 116^ 2' 25" east=20
of the prime meridian which would be specified as 116.86520. Curtin=20
University, Perth is also 10 meters above sea-level.
Rational: to match the terms with their correct definitions.
Notes:
from pending
Source of RFC: ripv2 (rtg)
Errata ID: 540
Status: Verified
Type: Editorial
Reported By: Orly Nicklass
Date Reported: 2004-05-27
Section 9 says:
rip2IfConfAuthKey
OCTET STRING (SIZE(0..16)),
It should say:
rip2IfConfAuthKey
OCTET STRING,
Source of RFC: Legacy
Errata ID: 1086
Status: Reported
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
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.
Source of RFC: Legacy
Errata ID: 539
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1059
Status: Verified
Type: Editorial
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)
Source of RFC: rreq (rtg)
Errata ID: 537
Status: Verified
Type: Editorial
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
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.
Source of RFC: html (app)
Errata ID: 536
Status: Verified
Type: Technical
Reported By: Dirk Nimmich
Date Reported: 2002-03-09
Every occurance of the string:
, boundary=
It should say:
; boundary=
Source of RFC: notary (app)
Errata ID: 535
Status: Verified
Type: Editorial
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.
Source of RFC: notary (app)
Errata ID: 534
Status: Verified
Type: Technical
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
Source of RFC: Legacy
Errata ID: 533
Status: Verified
Type: Technical
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
Source of RFC: cidrd ()
Errata ID: 1419
Status: Reported
Type: Editorial
Reported By: Jack Parker
Date Reported: 2008-05-07
Section 3 says:
An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry.
It should say:
An enterprise that decides to use IP addresses within the address space defined in this document can do so without any coordination with IANA or an Internet registry.
Notes:
There appears to be a slight difference in interpretation with the existing phrase, "out of the address space." This 'could' be interpreted to mean "outside of the address space," hence changing the meaning of the entire statement, if the section's context is not considered. In the interest of clarification, would it be possible to rephrase this particular section to "within the address space?" I'm aware of one case in particular where attorneys argued over this issue ad nauseum, regardless of the network architects attempting to intervene.
Source of RFC: Legacy
Errata ID: 532
Status: Verified
Type: Technical
Reported By: John Ioannidis
Date Reported: 2003-04-08
Section 2 says:
the word is "agglutinate", not "aglutenate"
Source of RFC: Legacy
Errata ID: 531
Status: Verified
Type: Technical
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
Source of RFC: Legacy
Errata ID: 530
Status: Verified
Type: Editorial
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.
Source of RFC: Legacy
Errata ID: 529
Status: Verified
Type: Technical
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.
Errata ID: 1088
Status: Reported
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
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.
Source of RFC: Legacy
Errata ID: 2068
Status: Reported
Type: Editorial
Reported By: Fernando Gont
Date Reported: 2010-03-05
Section References says:
[6] Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for
High-Speed Paths", RFC 1885, October 1990.
It should say:
[6] Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for
High-Speed Paths", RFC 1185, October 1990.
Notes:
RFC 1185 has been obsoleted by RFC 1323. RFC 1323 is currently being revised.
Source of RFC: asid (app)
Errata ID: 528
Status: Verified
Type: Technical
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
Source of RFC: pppext (int)
Errata ID: 527
Status: Verified
Type: Technical
Reported By: Bartlomiej Molenda
Date Reported: 2003-11-03
Section 3 says:
Length
3
It should say:
Length
4
Source of RFC: mobileip (int)
Errata ID: 1686
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-02-18
Section 4.3 says:
The encapsulator MAY handle the ICMP Redirect messages itself. It MUST NOT not relay the Redirect to the sender of the original unencapsulated datagram.
It should say:
The encapsulator MAY handle the ICMP Redirect messages itself. It MUST NOT relay the Redirect to the sender of the original unencapsulated datagram.
Source of RFC: Legacy
Errata ID: 526
Status: Verified
Type: Editorial
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
Source of RFC: tcplw (tsv)
Errata ID: 1610
Status: Verified
Type: Technical
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.
Source of RFC: rmonmib (ops)
Errata ID: 525
Status: Verified
Type: Technical
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 }
Source of RFC: poised95 (gen)
Errata ID: 522
Status: Verified
Type: Technical
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
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 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 reference to BCP-11 should be to BCP-9 (RFC 2026 itself).
Errata ID: 523
Status: Verified
Type: Editorial
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
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
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
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:
"implementations" is misspelled.
Errata ID: 2044
Status: Held for Document Update
Type: Editorial
Reported By: Lars Eggert
Date Reported: 2010-02-15
Held for Document Update by: Russ Housley
Section 10.4 says:
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
It should say:
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assignees.
Notes:
Assigns vs. assignees in the boilerplate text. xml2rfc generates the latter (which appears to be correct), idnits currently allows both variants.
The same change needs to be applied in Section 10.3.1 bullet item 7.
Source of RFC: poised95 (gen)
Errata ID: 521
Status: Verified
Type: Editorial
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
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
Source of RFC: Legacy
Errata ID: 518
Status: Verified
Type: Technical
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: 517
Status: Verified
Type: Technical
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: 516
Status: Reported
Type: Technical
Reported By: Ben Fountain
Date Reported: 2002-11-12
Section 1 says:
Each SNTP packet is transmitted as tht TS-Userdata parameter of a T-UNITDATA Request primitive.
It should say:
Each SNTP packet is transmitted as the TS-Userdata parameter of a T-UNITDATA Request primitive.
Errata ID: 519
Status: Verified
Type: Editorial
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
Errata ID: 520
Status: Reported
Type: Editorial
Reported By: Ben Fountain
Date Reported: 2002-11-12
Section 1 says:
An important provision in this document is the reinterpretation of certain NTP Versino 4 header fields which provide for IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service.
It should say:
An important provision in this document is the reinterpretation of certain NTP Version 4 header fields which provide for IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service.
Errata ID: 515
Status: Reported
Type: Editorial
Reported By: vijeeshep
Date Reported: 2005-12-16
Section 5 says:
T = ((T2 - T1) + (T3 - T4)) / 2.
It should say:
T = ((T2 - T1) + (T4 - T3)) / 2.
Notes:
Because T4 always will be greater than (or equal to) T3
For example assume
T1 = 1
T2 = 3
T3 = 4
T4 = 6
Case 1: As per the given formula the local clock offset will be
T = ((3 - 1) + (4 - 6)) / 2 = 0 which is wrong
Case 2: As per the corrected formula the local clock offset will be
T = ((3 - 1)+ (6 - 4)) / 2 = 2 which is correct
Source of RFC: Legacy
Errata ID: 587
Status: Verified
Type: Technical
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: 514
Status: Verified
Type: Technical
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: 513
Status: Verified
Type: Editorial
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.
Source of RFC: 822ext (app)
Errata ID: 512
Status: Verified
Type: Editorial
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.
Source of RFC: 822ext (app)
Errata ID: 508
Status: Verified
Type: Technical
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
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
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: 507
Status: Verified
Type: Technical
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: 510
Status: Verified
Type: Editorial
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: 509
Status: Verified
Type: Editorial
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: 511
Status: Verified
Type: Editorial
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.
Source of RFC: 822ext (app)
Errata ID: 504
Status: Verified
Type: Technical
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
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.
Source of RFC: Legacy
Errata ID: 503
Status: Verified
Type: Technical
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
Source of RFC: http (app)
Errata ID: 749
Status: Reported
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2005-02-06
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.
from pending
Source of RFC: rip (rtg)
Errata ID: 502
Status: Verified
Type: Technical
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).
Source of RFC: ipsec (sec)
Errata ID: 501
Status: Verified
Type: Editorial
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:
Source of RFC: Legacy
Errata ID: 496
Status: Verified
Type: Technical
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: 493
Status: Verified
Type: Technical
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
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: 498
Status: Verified
Type: Technical
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
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
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: Reported
Type: Editorial
Reported By: Anders Langmyr
Date Reported: 2006-01-09
The 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 phrase.
Errata ID: 497
Status: Reported
Type: Editorial
Reported By: Kiyoshi Ogawa
Date Reported: 2006-07-10
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
It should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications should be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Notes:
OR should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications is understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
The change request is "must" to "should".
It may be self definition.
For the balance of SHOULD and SHOULD NOT , it should use "should", not
"must".
Source of RFC: Legacy
Errata ID: 492
Status: Rejected
Type: Technical
Reported By: Larry Masinter
Date Reported: 2002-03-21
Rejected by: RFC Editor
Date Rejected: 2009-12-01
Notes:
All errata for these documents can be found at: http://purl.org/net/http-errata
----------------------
This report was mistakenly posted based on a typo (2126 vs. 2616)
in a message from 2002, and thus has been rejected.
Source of RFC: isdnmib (int)
Errata ID: 1952
Status: Reported
Type: Technical
Reported By: Yigal Hachmon
Date Reported: 2009-12-01
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 }
Errata ID: 491
Status: Rejected
Type: Technical
Reported By: Larry Masinter
Date Reported: 2002-03-21
Rejected by: RFC Editor
Date Rejected: 2009-12-01
Notes:
All errata for these documents can be found at: http://purl.org/net/http-errata
----------------------
This report was mistakenly posted based on a typo (2127 vs. 2617)
in a message from 2002, and thus has been rejected.
Source of RFC: dhc (int)
Errata ID: 490
Status: Verified
Type: Editorial
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 uicast delivery.
Notes:
typo (uicast -> unicast)
Errata ID: 489
Status: Verified
Type: Editorial
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: 488
Status: Reported
Type: Editorial
Reported By: Robert Floyd Jr
Date Reported: 2006-03-23
Section 1.2 says:
In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
It should say:
In other related work, the path maximum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
Source of RFC: dhc (int)
Errata ID: 486
Status: Verified
Type: Technical
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: 487
Status: Reported
Type: Technical
Reported By: "Tyler Tidman"
Date Reported: 2002-09-24
Section 3.18 says:
3.18. Swap Server
This specifies the IP address of the client's swap server.
The code for this option is 16 and its length is 4.
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
It should say:
3.18. Swap Server
This specifies the IP address of the client's swap server.
The code for this option is 16 and its length is 4.
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Source of RFC: Legacy
Errata ID: 1082
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Section 5 says:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [RFC977] NEWS NNTP Synonym for USENET
It should say:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [son-of-1036] NEWSMASTER NNTP Synonym for USENET
Notes:
RFC 977 (obsoleted by RFC 3977) as well as RFC 1036 (obsoleted by RFC.ietf-usefor-usefor) don't specify rôle accounts USENET or NEWS.
Section 1 states that "Other protocols have defacto standards for well known mailbox names, such as <USENET@domain> for NNTP (see [RFC977])", however the IETF USEFOR WG didn't add just as little as an informative reference to RFC 2142.
Errata ID: 1763
Status: Reported
Type: Editorial
Reported By: Nick Levinson
Date Reported: 2009-04-15
Section 1 says:
Most organizations do not need to support the full set of mailbox names defined here, since not every organization will implement the all of the associated services.
It should say:
Most organizations do not need to support the full set of mailbox names defined here, since not every organization will implement all of the associated services.
Notes:
This is submitted 2009-04-16.
Errata ID: 1764
Status: Reported
Type: Editorial
Reported By: Nick Levinson
Date Reported: 2009-04-15
Section 1 & 2 says:
top level domain
Notes:
1. The phrase "top level domain" seems to mean 'second-level and top level domains together', and perhaps 'third- to top level domains together' in cases like <example.co.uk>. It is erroneous now that _top level domain_ (_TLD_) is specifically only what comes after the last dot in a domain, and nonreserved TLDs are so registered at IANA.org.
2. I would rather someone else propose replacement phrasing.
3. This is submitted 2009-04-16.
Errata ID: 1765
Status: Reported
Type: Editorial
Reported By: Nick Levinson
Date Reported: 2009-04-15
Section Erratum 1082 says:
. . . the IETF USEFOR WG didn't add just as little as an informative reference to RFC 2142.
Notes:
1. I didn't understand the text. Perhaps something else belongs in place of or near "just as little".
2. This is submitted 2009-04-16.
Source of RFC: Legacy
Errata ID: 862
Status: Verified
Type: Editorial
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
Source of RFC: mixer (app)
Errata ID: 1387
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-03-25
Section 6.2 says:
ESC 21 41
It should say:
ESC 22 43
Notes:
ESC 21 41 invokes ISO-IR 7, an unrelated C0 set.
ESC 22 43 invokes ISO-IR 77, the C1 set of an old ISO 6429.
For details see <http://www.itscj.ipsj.or.jp/ISO-IR/2-5.htm>
(C0 sets) and <http://www.itscj.ipsj.or.jp/ISO-IR/2-6.htm> (C1).
Source of RFC: Legacy
Errata ID: 485
Status: Verified
Type: Technical
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
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".
Source of RFC: Legacy
Errata ID: 841
Status: Reported
Type: Technical
Reported By: Terje Braten
Date Reported: 2001-04-14
I would like to address some inconsistencies in RFC 2184 regarding
parameter values in MIME header. It is two inconsistencies I would like
to point out.
The first one is about at what number should the counting of the
parameter
parts start (0 or 1). A part of page 3 of RFC 2184 reads:
> are being used to encapsulate a single parameter value. The count
> starts at 0 and increments by 1 for each subsequent section of the
> parameter value. Decimal values are used and neither leading zeroes
> nor gaps in the sequence are allowed.
>
> The original parameter value is recovered by concatenating the
> various sections of the parameter, in order. For example, the
> content-type field
>
> Content-Type: message/external-body; access-type=URL;
> URL*0="ftp://";
> URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
>
This clearly states that the numbering of the parameter parts should
start
at 0. But further down in the RFC an example is used where the count
starts
with 1. At page 4 of RFC 2184 you can read:
>4.1. Combining Character Set, Language, and Parameter Continuations
>
> Character set and language information may be combined with the
> parameter continuation mechanism. For example:
>
> 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!"
And in section 7 "Modificatons to MIME ABNF" it clearly states that the
counting
shall begin with 1. Note at the end of page 5, intial-section is defined
as:
> initial-section := "*1"
And on the start of page 6 you have the definition:
> other-sections := "*" (("2" / "3" / "4" / "5" /
> "6" / "7" / "8" / "9") *DIGIT) /
> ("1" 1*DIGIT))
If you follow this ABNF, the counting must start at 1 and not 0.
It should say:
[see above]
Notes:
from pending
Errata ID: 484
Status: Reported
Type: Editorial
Reported By: Terje Braten
Date Reported: 2001-04-14
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 "?="
Source of RFC: Legacy
Errata ID: 483
Status: Verified
Type: Editorial
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
Source of RFC: ssh ()
Errata ID: 482
Status: Verified
Type: Technical
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:
Source of RFC: Legacy
Errata ID: 481
Status: Verified
Type: Technical
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
Errata ID: 480
Status: Verified
Type: Technical
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:
Source of RFC: intserv (tsv)
Errata ID: 479
Status: Reported
Type: Editorial
Reported By: Orly Nicklass
Date Reported: 2005-09-12
Section 3 says:
TimeInterval, TEXTUAL-CONVENTION, RowStatus,
TruthValue FROM SNMPv2-TC
It should say:
TimeInterval, TEXTUAL-CONVENTION, RowStatus,
TruthValue, TestAndIncr FROM SNMPv2-TC
Source of RFC: Legacy
Errata ID: 1753
Status: Reported
Type: Technical
Reported By: Matthew Luckie
Date Reported: 2009-04-02
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.
Source of RFC: Legacy
Errata ID: 477
Status: Verified
Type: Technical
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: 590
Status: Verified
Type: Technical
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: 478
Status: Verified
Type: Technical
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: 476
Status: Verified
Type: Technical
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.
Source of RFC: drums (app)
Errata ID: 472
Status: Verified
Type: Technical
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: 475
Status: Verified
Type: Technical
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: 474
Status: Verified
Type: Technical
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: 473
Status: Verified
Type: Editorial
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.
Errata ID: 765
Status: Reported
Type: Editorial
Reported By: Keith McCloghrie
Date Reported: 2005-05-19
page 5:
LINEAR WHITE SPACE: Concatenation is ...
...
...
...
... ... to be freelyPand
implicitlyPinterspersed around ...
presumably, each "P" character should be a parenthesis and a space ??
It should say:
[see above]
Notes:
from pending
Source of RFC: idmr (rtg)
Errata ID: 470
Status: Verified
Type: Editorial
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: Reported
Type: Editorial
Reported By: Stephen Nadas (RL/TNT)
Date Reported: 2006-11-28
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.
Source of RFC: dhc (int)
Errata ID: 469
Status: Verified
Type: Technical
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
Source of RFC: acap (app)
Errata ID: 468
Status: Verified
Type: Technical
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Source of RFC: avt (rai)
Errata ID: 782
Status: Reported
Type: Editorial
Reported By: Vishal B S
Date Reported: 2005-09-26
Section 3.3 says:
Payload Type: Distinct payload types should be assigned
for video elementary streams and audio elementary streams.
See [4] for payload type assignments.
M bit: For video, set to 1 on packet containing MPEG frame
end code, 0 otherwise. For audio, set to 1 on first packet of
a "talk-spurt," 0 otherwise.
PT: MPEG video or audio stream ID.
It should say:
[see notes]
Notes:
Payload Type and PT mean the same in RTP header
So, there exists a repetition.
from pending
Source of RFC: asid (app)
Errata ID: 467
Status: Verified
Type: Technical
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
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
Source of RFC: asid (app)
Errata ID: 466
Status: Verified
Type: Technical
Reported By: Charles Bates
Date Reported: 2002-10-30
Section 4 says:
greater = ">="
It should say:
greater than or equal = ">="
Source of RFC: Legacy
Errata ID: 1536
Status: Reported
Type: Editorial
Reported By: Shiang-Ming Huang
Date Reported: 2008-10-03
Section 7 says:
Both the issue of address assignment and renumbering could be addressed by the appropriate use of network address translation (NAT). The use of NAT for multi-homed enterprises is the beyond the scope of this document.
It should say:
Both the issue of address assignment and renumbering could be addressed by the appropriate use of network address translation | (NAT). The use of NAT for multi-homed enterprises is beyond the scope of this document.
Source of RFC: Legacy
Errata ID: 465
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 1374
Status: Reported
Type: Editorial
Reported By: Masatoshi Yamamoto
Date Reported: 2008-03-20
Section 4.1 says:
Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4].
It should say:
Many operations, including high quality formatting, text-to-speech
synthesis, searching, hyphenation, spellchecking and so on benefit
greatly from access to information about the language of a piece of
text. [WR 3.1.1.4].
^^
Notes:
"WC" --> "WR"
Source of RFC: Legacy
Errata ID: 464
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 463
Status: Verified
Type: Technical
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
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:
Source of RFC: urn (app)
Errata ID: 775
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Once you have written RFC 2288 that defined three URN namespaces: ISSN, ISBN, and SICI. The IANA "urn-namespaces" registry does not (and probably never did) contain any pointers to RFC 2288. Meanwhile, the 'ISSN' URN namespace definition has been restated in RFC 3044, including an IANA registration -- according to and using the template specified in RFC 2611 (BCP 33) [that in the meantime has been obsoleted itself by RFC 3406 (BCP 66)] --, and 'ISSN' currently appears as formal URN namespace #3 in the IANA URN namespaces registry. Similarly, the 'ISBN' URN namespace definition has been restated in RFC 3187, including an IANA registration -- according to and using the template specified in RFC 2611 --, and 'ISBN' currently appears as formal URN namespace #9 in the IANA registry. Now, RFC 2288 is *NOT* declared "Obsoleted" in the RFC index. Contrary to that, the 'SICI' URN namespace does *NOT* appear in the current IANA URN namespaces registry. Thus the fate of the 'SICI' namespace and the status of RFC 2288 is questionable and unclear. I suspect that RFC 2288 should be considered obsoleted, and 'SICI' should be considered deprecated. So, what's to do in this case ? According to my understanding of the established procedures, the Informational RFC 2288 cannot easily be re-classified as Historic, and a specific footnote about the deprecated 'SICI' namespace would not be easily entered into the IANA registry. Therefore, to make the situation clearly understandable for everyone, it seems easiest to have the RFC-Ed add the note '(Obsoleted by 3044, RFC 3187)' to the RFC index entry for RFC 2288.
It should say:
[see above]
Notes:
from pending
Source of RFC: Legacy
Errata ID: 462
Status: Reported
Type: Editorial
Reported By: Pierre Beyssac
Date Reported: 2004-11-25
Section 4 says:
( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
DESC 'Abstraction of an IP protocol. Maps a protocol number
to one or more names. The distinguished value of the cn
attribute denotes the protocol's canonical name'
MUST ( cn $ ipProtocolNumber $ description )
MAY description )
It should say:
( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
DESC 'Abstraction of an IP protocol. Maps a protocol number
to one or more names. The distinguished value of the cn
attribute denotes the protocol's canonical name'
MUST ( cn $ ipProtocolNumber )
MAY description )
Source of RFC: dnsind (int)
Errata ID: 461
Status: Reported
Type: Editorial
Reported By: Hideshi Enokihara
Date Reported: 2006-02-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".
Source of RFC: dnsind (int)
Errata ID: 1474
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2008-07-17
Section 4 says:
the the first component
It should say:
the first component
Source of RFC: Legacy
Errata ID: 682
Status: Reported
Type: Technical
Reported By: Andrew Cook
Date Reported: 2002-11-20
Section 2.1.1 says:
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". I have not been able to reach the author regarding this.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 460
Status: Reported
Type: Technical
Reported By: Larry Masinter
Date Reported: 2005-02-19
Section 3 says:
| "caf%C3%E8" ; Catalan, French, Galician
It should say:
| "caf%C3%A9" ; Catalan, French, Galician
Errata ID: 681
Status: Reported
Type: Technical
Reported By: Larry Masinter
Date Reported: 2005-02-19
Section 3 says:
| "caf%C3%E8" ; Catalan, French, Galician
It should say:
| "caf%C3%A9" ; Catalan, French, Galician
Source of RFC: mmusic (rai)
Errata ID: 459
Status: Verified
Type: Technical
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.
Errata ID: 458
Status: Reported
Type: Editorial
Reported By: Richard Walters
Date Reported: 2005-08-01
Section 6 says:
An example of a static payload type is u-law PCM coded single
channel audio sampled at 8KHz. This is completely defined in the
RTP Audio/Video profile as payload type 0, so the media field for
such a stream sent to UDP port 49232 is:
m=video 49232 RTP/AVP 0
An example of a dynamic payload type is 16 bit linear encoded
stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP
payload type 98 for such a stream, additional information is
required to decode it:
m=video 49232 RTP/AVP 98
It should say:
An example of a static payload type is u-law PCM coded single
channel audio sampled at 8KHz. This is completely defined in the
RTP Audio/Video profile as payload type 0, so the media field for
such a stream sent to UDP port 49232 is:
m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16 bit linear encoded
stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP
payload type 98 for such a stream, additional information is
required to decode it:
m=audio 49232 RTP/AVP 98
Notes:
The examples refer to audio but show the media type as "video". I believe
the author intended to put "m=audio" but "m=video" was put in by mistake.
Errata ID: 1093
Status: Reported
Type: Editorial
Reported By: Jim Bell
Date Reported: 2007-12-17
Section 6 says:
The following unit specification characters are allowed:
d - days (86400 seconds)
h - minutes (3600 seconds)
m - minutes (60 seconds)
It should say:
The following unit specification characters are allowed:
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
Notes:
I believe the author means "h" for "hours" and "m" for "minutes" unambiguously.
Source of RFC: ospf (rtg)
Errata ID: 1745
Status: Reported
Type: Technical
Reported By: Wenhu Lu
Date Reported: 2009-03-27
Section Appendix E says:
In the paragraph that starts with: "The above algorithm assumes that all"
The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address.
It should say:
The algorithm also assumes that if
one of the conflicting networks is of IP host mask, its LSA
origination is suppressed. The choice of the suppressing algorithm
again is a local decision. However, the suppressed LSA MUST be
originated if the conflicting network becomes withdrawn.
Notes:
The current algorithm will derive an unchanged ID
if one of the conflicting networks is of IP host mask.
This will cause problems that the algorithm try to solve.
On the other hand, the perfect algorithm for
LSID collision resolution does not exist in
that a flat address space cannot accommodate
all of the overlaid supernet/subnet IDs.
For example,
route1 - 10.0.0.0/32
route2 - 10.0.0.1/32
route3 - 10.0.0.0/31
There is no way to originate 3 LSAs with distinct LSIDs.
Thus though in majority cases, LSID collision even
with host route is resolvable, the suppressing
mechanism is still inevitable.
Errata ID: 1420
Status: Reported
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-05-11
Section 11.3 says:
The routing table entries changes that would be caused by the addition of this virtual link are shown in Table 14.
It should say:
N/A
Notes:
But Table 14 is exiled in another section, section 12, where it has nothing to do. I assume some processor tried to avoid splitting the table and displaced it too far.
Errata ID: 1833
Status: Reported
Type: Editorial
Reported By: Dande Rajasekhar
Date Reported: 2009-08-19
Section 2.1.1 says:
Figure 1b illustrates the link-state database representation of a Point-to-MultiPoint network. On the left side of the figure, a Point-to-MultiPoint network is pictured. It is assumed that all routers can communicate directly, except for routers RT4 and RT5. I3 though I6 indicate the routers'
It should say:
Figure 1b illustrates the link-state database representation of a Point-to-MultiPoint network. On the left side of the figure, a Point-to-MultiPoint network is pictured. It is assumed that all routers can communicate directly, except for routers RT4 and RT5. I3 through I6 indicate the routers'
Notes:
Should be I3 *through* I6
Source of RFC: ion (int)
Errata ID: 1922
Status: Reported
Type: Editorial
Reported By: Michelle Cotton
Date Reported: 2009-10-21
Section B.3.1.2 says:
The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC is safer than normal keyed hashes. Other hash algorithms MAY be supported by def. IANA will assign the numbers to identify the algorithm being used as described in Section C.
It should say:
The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC is safer than normal keyed hashes. Other hash algorithms MAY be supported by def.
Notes:
Removed last paragraph in section B.3.1.2. After doing a review of RFC2334 for any incomplete IANA actions, IANA contacted an author to confirm if a registry for the algorithms needed to be set-up. Joel Halpern confirmed that it the actual purpose of the section is only to make sure that there is something eveyrone can use for interoperability. He suggested I submit an errata for the removal of the last paragraph.
Source of RFC: Legacy
Errata ID: 1258
Status: Reported
Type: Technical
Reported By: Edwin Groothuis
Date Reported: 2008-01-13
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.
Source of RFC: Legacy
Errata ID: 1255
Status: Reported
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2008-01-11
In Appendix A, it says:
A.104 DVM
It should say:
A.104 AC3 DVM
Notes:
Change to match the change being made to the IANA registry. This corrects the name so that when people search for the codepoint for the AC3 codec, they find this (which is the commonly used code point for AC3 instead of code point 0x0092)
Source of RFC: idmr (rtg)
Errata ID: 457
Status: Verified
Type: Technical
Reported By:
Date Reported: 2001-01-03
Throughout the document:
[Figures are present only in the postscript version]
Notes:
There is no postscript version available.
Source of RFC: ipngwg (int)
Errata ID: 455
Status: Verified
Type: Technical
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.
Errata ID: 456
Status: Reported
Type: Editorial
Reported By:
Date Reported: 2001-07-26
It appears that the ABNF grammar for textual representations of IPv6 addresses as detailed in Appendix B of RFC 2373 is not correct in its treatment of IPv6 addresses with a trailing IPv4 address. Specifically, section 2.2.3 of the RFC states that:
"::13.1.83.3"
It should say:
IPv6address = dcolon | hexpart
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT
dcolon = "::" | "::" hexseq [ ":" IPv4address ] | "::" [ IPv4address ]
hexpart = hexseq | hexseq ":" IPv4address | hexseq dcolon
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
Notes:
According to the grammar in Appendix B, this is not a valid IPv6
address; there is no provision for a double colon followed by an IPv4
address. However, the grammar does allow for a double colon, followed by
a colon, followed by an IPv4 address. In other words, ":::13.1.83.3" is a
valid address according to the grammar and "::13.1.83.3" is not.
I blame the discrepancy on the grammar simply because I feel that the
intent of the RFC was clearly to prefer two colons over three colons
before a trailing IPv4 address. This seems to match the behavior of
existing applications.
Source of RFC: Legacy
Errata ID: 2011
Status: Reported
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2010-01-21
Section boilerplate says:
Network Working Group L. Masinter Request for Comments: 2388 Xerox Corporation Category: Standards Track August 1998
It should say:
Network Working Group L. Masinter Request for Comments: 2388 Xerox Corporation Updates: 1867 August 1998 Category: Standards Track
Notes:
RFC 2388 updated the definition of multipart/form-data, which was previously defined in RFC 1867. It appears the RFC Index should reflect that.
Source of RFC: Legacy
Errata ID: 1847
Status: Reported
Type: Editorial
Reported By: Yin Gaosong
Date Reported: 2009-09-07
Section Abstract says:
NATs have traditionally been been used to allow private network domains to connect to Global networks using as few as one globally unique IP address.
It should say:
NATs have traditionally been used to allow private network domains to connect to Global networks using as few as one globally unique IP address.
Notes:
repetition of "been"
Source of RFC: mhtml (app)
Errata ID: 454
Status: Verified
Type: Technical
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>
Source of RFC: ippcp (int)
Errata ID: 453
Status: Verified
Type: Editorial
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.
Source of RFC: Legacy
Errata ID: 450
Status: Verified
Type: Technical
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
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: Reported
Type: Technical
Reported By: Henry Zongaro
Date Reported: 2001-11-12
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.
Errata ID: 1933
Status: Reported
Type: Technical
Reported By: Skip Geel
Date Reported: 2009-10-25
Section appendix B says:
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
It should say:
/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/
Notes:
A Regular Expression is delimited by the slash ("/"). Within it a slash should be preceded by a back-slash ("\").
Errata ID: 1069
Status: Verified
Type: Editorial
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
Source of RFC: Legacy
Errata ID: 2009
Status: Verified
Type: Technical
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
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).
Source of RFC: ipsec (sec)
Errata ID: 449
Status: Verified
Type: Technical
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.
Source of RFC: ipsec (sec)
Errata ID: 1925
Status: Held for Document Update
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-22
Held for Document Update by: Pasi Eronen
Section 7 says:
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2408, November 1998.
It should say:
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
Source of RFC: Legacy
Errata ID: 448
Status: Verified
Type: Technical
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
Source of RFC: Legacy
Errata ID: 446
Status: Verified
Type: Technical
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
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: 440
Status: Reported
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
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 and semantics.
Errata ID: 442
Status: Reported
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
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: 443
Status: Reported
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
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: 444
Status: Reported
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
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 and
semantics.
Errata ID: 441
Status: Reported
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2002-01-07
Appendix B says:
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary_
It should say:
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary--
Notes:
RFC 2046 multipart message close delimiter syntax.
Errata ID: 445
Status: Reported
Type: Editorial
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
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).
Source of RFC: asid (app)
Errata ID: 868
Status: Reported
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-18
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)
from pending
Errata ID: 869
Status: Reported
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Section 4 says:
;For name=3D"SOURCE"
param =3D source-param
; No parameters allowed
value =3D uri
source-param =3D ("VALUE" "=3D" "uri")
/ ("CONTEXT" "=3D" "word")
; Parameter value specifies the protocol context
; for the uri value.
/ (x-name "=3D" *SAFE-CHAR)
It should say:
;For name=3D"SOURCE"
param =3D source-param
; Only source parameters allowed
value =3D uri
source-param =3D ("VALUE" "=3D" "uri")
/ ("CONTEXT" "=3D" "word")
; Parameter value specifies the protocol context
; for the uri value.
/ (x-name "=3D" *SAFE-CHAR)
Notes:
(text-param, text-value)
- "Type value: The default is a single vcard value. It can also be
reset to either a single text or uri value." (Section 3.5.4)
- The "single text" part was forgotten in the ABNF.
from pending
Errata ID: 870
Status: Reported
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Section 4 says:
;For name=3D"UID"
param =3D ""
; No parameters allowed
value =3D text-value
It should say:
;For name=3D"UID"
param =3D "TYPE" "=3D" (iana-token / x-name)
; No parameters allowed
value =3D 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.
from pending
Errata ID: 871
Status: Reported
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-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
from pending
Errata ID: 872
Status: Reported
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
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=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
N:Howes; Tim
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
Notes:
- "Profile special notes: The vCard object MUST contain the FN, N and
VERSION types." (Section 1) N was missing in the original information.
from pending
Errata ID: 1546
Status: Reported
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
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: 1547
Status: Reported
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Section 4 says:
text-param = ("VALUE" "=" "ptext")
/ ("LANGUAGE" "=" langval)
/ (x-name "=" param-value)
langval = <a language string as defined in RFC 1766>
img-inline-value = binary-value
;Value MUST be "b" encoded image content
img-inline-param
img-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" param-value
;TYPE value MUST be an IANA registered image type
It should say:
text-param = ("VALUE" "=" "ptext")
/ ("LANGUAGE" "=" langval)
/ (x-name "=" param-value)
langval = <a language string as defined in RFC 1766>
img-inline-value = binary-value
;Value MUST be "b" encoded image content
img-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" param-value
;TYPE value MUST be an IANA registered image type
Notes:
There is a definition of parameter "img-inline-param" without any assignment to it. The correct definition of "img-inline-param" follows in the next line.
Errata ID: 1549
Status: Reported
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Section 4 says:
;For name="KEY"
param = key-txt-param
; Only value and type parameters allowed
param =/ key-bin-param
; Only value and type parameters allowed
value = text-value
value =/ binary-value
key-txt-param = "TYPE" "=" keytype
key-bin-param = ("TYPE" "=" keytype)
/ ("ENCODING" "=" "b")
; Value MUST be a "b" encoded key or certificate
It should say:
;For name="KEY"
param = key-txt-param
; Only value and type parameters allowed
param =/ key-bin-param
; Only value and type parameters allowed
value = text-value
value =/ binary-value
key-txt-param = "TYPE" "=" keytype
key-bin-param = ("VALUE" "=" "binary")
/ ("TYPE" "=" keytype)
/ ("ENCODING" "=" "b")
; Value MUST be a "b" encoded key or certificate
Notes:
According to section 2.4.1 the KEY type value can be specified as "binary".
Errata ID: 1550
Status: Reported
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
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: Reported
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Section 4 says:
;For name="EMAIL"
param = email-param
; Only email parameters allowed
value = text-value
email-param = "TYPE" "=" email-type ["," "PREF"]
; Value is case insensitive
email-type = "INTERNET" / "X400" / iana-token / "X-" word
; Values are case insensitive
It should say:
;For name="EMAIL"
param = email-param
; Only email parameters allowed
value = text-value
email-param = "TYPE" "=" email-type ["," "PREF"]
; Value is case insensitive
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!
Errata ID: 436
Status: Reported
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Page 33 says:
;For name="CATEGORIES"
param = text-param
; Only text parameters allowed
value = text-list
It should say:
;For name="CATEGORIES"
param = text-param
; Only text parameters allowed
value = text-value-list
Errata ID: 437
Status: Reported
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Section 4 says:
;For name="NICKNAME"
param = text-param
; Text parameters allowed
value = text-list
It should say:
;For name="NICKNAME"
param = text-param
; Text parameters allowed
value = text-value-list
Errata ID: 438
Status: Reported
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Section 4 (p. 33) says:
;For name="CATEGORIES"
param = text-param
; Only text parameters allowed
value = text-list
Notes:
It should say:
;For name="CATEGORIES"
param = text-param
; Only text parameters allowed
value = text-value-list
</CORR>
Errata ID: 439
Status: Reported
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Section 4 says:
;For name="NICKNAME"
param = text-param
; Text parameters allowed
value = text-list
It should say:
;For name="NICKNAME"
param = text-param
; Text parameters allowed
value = text-value-list
Errata ID: 1548
Status: Reported
Type: Editorial
Reported By: Markus Lorenz
Date Reported: 2008-10-09
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".
Source of RFC: calsch (app)
Errata ID: 435
Status: Verified
Type: Technical
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
Reported By: Dave Flater
Date Reported: 2004-01-07
Report Text:
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. 11c11 < November 1998 - --- > November 1998 (as amended 2004-01-07, incorporating errata) 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: 640
Status: Verified
Type: Editorial
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
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
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
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
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: 434
Status: Verified
Type: Editorial
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: 1497
Status: Verified
Type: Editorial
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.
Source of RFC: calsch (app)
Errata ID: 1709
Status: Held for Document Update
Type: Editorial
Reported By: David Riggle
Date Reported: 2009-03-07
Held for Document Update by: Lisa Dusseault
Section 4.4.7 says:
Error! Bookmark not defined
It should say:
various
Notes:
The "Error! Bookmark not defined" string appears 5 times near the end of section 4.4.7. It appears in place of actual data in the examples.
http://www.ietf.org/rfc/rfc2446.txt
Source of RFC: ripv2 (rtg)
Errata ID: 1054
Status: Reported
Type: Editorial
Reported By: Nataraja Kumar Kota
Date Reported: 2007-08-27
Section 3.4.4 says:
RIP implementations must also limit the rate which of triggered updates may be trandmitted.
It should say:
RIP implementations must also limit the rate which of triggered updates may be transmitted.
Source of RFC: pkix (sec)
Errata ID: 432
Status: Verified
Type: Technical
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
Source of RFC: vgmib (int)
Errata ID: 431
Status: Verified
Type: Editorial
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.
Source of RFC: ipngwg (int)
Errata ID: 430
Status: Verified
Type: Technical
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
Source of RFC: roamops (ops)
Errata ID: 428
Status: Verified
Type: Technical
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
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
Source of RFC: dhc (int)
Errata ID: 855
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-02-02
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
Source of RFC: ion (int)
Errata ID: 1327
Status: Reported
Type: Editorial
Reported By: Fernando Gont
Date Reported: 2008-02-18
Section 3 says:
This use of PVC links does not mandate, nor does it prohibit the use of extensions to the Neighbor Discovery protocol which may be developed for either general use of for use in PVC connections (for example, Inverse Neighbor Discovery).
It should say:
This use of PVC links does not mandate, nor does it prohibit the use of extensions to the Neighbor Discovery protocol which may be developed for either general use or for use in PVC connections (for example, Inverse Neighbor Discovery).
Source of RFC: Legacy
Errata ID: 427
Status: Reported
Type: Editorial
Reported By: Saravanan Kesavan
Date Reported: 2006-10-06
Section 9 says:
Host MAC address using a key known only to the Access > Concentrator.
It should say:
Host MAC address using a key known only to the Access Concentrator.
Notes:
There is an unnecessary ">" symbol.
Errata ID: 789
Status: Reported
Type: Editorial
Reported By: Saravanan Kesavan
Date Reported: 2006-10-06
Section 9 says:
While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources. While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
It should say:
While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
Notes:
sentence is repeated.
Errata ID: 1333
Status: Reported
Type: Editorial
Reported By: Praveen Bhamidipati
Date Reported: 2008-02-26
Section 4 says:
The SOURCE_ADDR field MUST contains the Ethernet MAC address of the source device.
It should say:
The SOURCE_ADDR field MUST contain the Ethernet MAC address of the source device.
Notes:
The word "contains" should be "contain"
Source of RFC: webdav (app)
Errata ID: 426
Status: Verified
Type: Technical
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
Source of RFC: pkix (sec)
Errata ID: 425
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 423
Status: Verified
Type: Technical
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: 421
Status: Verified
Type: Technical
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: 424
Status: Verified
Type: Technical
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: Reported
Type: Editorial
Reported By: Al Morton
Date Reported: 2006-11-05
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: 1484
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-08
Section C.2.4.1 Lear says:
This request should be
seen as coming from the immediate destination of the test frame
stream. (i.e. the phantom router (Figure 2) or the end node if
adjacent network routing is being used.) It is assumed that the
router will cache the MAC address of the requesting device. The ARP
request should be sent 5 seconds before the test frame stream starts
in each trial. Trial lengths of longer than 50 seconds may require
that the router be configured for an extended ARP timeout.
+--------+ +------------+
| | | phantom |------ P LAN A
IN A------| DUT |------------| |------ P LAN B
| | OUT A | router |------ P LAN C
+--------+ +------------+
Figure 2
It should say:
This request should be
seen as coming from the immediate destination of the test frame
stream. (i.e. the phantom router (Figure 4) or the end node if
adjacent network routing is being used.) It is assumed that the
router will cache the MAC address of the requesting device. The ARP
request should be sent 5 seconds before the test frame stream starts
in each trial. Trial lengths of longer than 50 seconds may require
that the router be configured for an extended ARP timeout.
+--------+ +------------+
| | | phantom |------ P LAN A
IN A------| DUT |------------| |------ P LAN B
| | OUT A | router |------ P LAN C
+--------+ +------------+
Figure 4
Errata ID: 1488
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-15
Section 26.2 says:
The latency is timestamp B minus timestamp A as per the relevant definition frm RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.
It should say:
The latency is timestamp B minus timestamp A as per the relevant definition from RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.
Errata ID: 1490
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-19
Section C.2.4.2 says:
If the test does not involve adjacent net routing the tester must supply proper routing information using a routing update. A single routing update is used before each trial on each "destination" port (see section C.24).
It should say:
If the test does not involve adjacent net routing the tester must supply proper routing information using a routing update. A single routing update is used before each trial on each "destination" port (see section C.2.6.2).
Source of RFC: radius (ops)
Errata ID: 1607
Status: Reported
Type: Technical
Reported By: Alan DeKok
Date Reported: 2008-11-18
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.
Errata ID: 420
Status: Reported
Type: Editorial
Reported By: Hans-Ake Lund
Date Reported: 2005-02-04
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.
Source of RFC: mhtml (app)
Errata ID: 418
Status: Verified
Type: Technical
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
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
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
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
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
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
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
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
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:
Source of RFC: snmpv3 (ops)
Errata ID: 1435
Status: Reported
Type: Technical
Reported By: grant mills
Date Reported: 2008-06-11
Section Status says:
Notes:
RFC3584 indicates that it obsoletes 2576 but there is no forward reference of this within the rfc2576. This differs from convention that I have observed.
Source of RFC: Legacy
Errata ID: 417
Status: Verified
Type: Technical
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: 415
Status: Verified
Type: Technical
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: 416
Status: Verified
Type: Editorial
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:
Source of RFC: tcpimpl (tsv)
Errata ID: 414
Status: Verified
Type: Technical
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:
Source of RFC: pkix (sec)
Errata ID: 1831
Status: Reported
Type: Technical
Reported By: Paul Hoffman
Date Reported: 2009-08-12
Section 4.1 and 4.2 says:
Optional parameters: version (default value is "1")
It should say:
Optional parameters:
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.
Source of RFC: Legacy
Errata ID: 1076
Status: Reported
Type: Technical
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Section 2.4 says:
- A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc. but would not match
example.com.
It should say:
- A "*" wildcard character MAY be used for the left-most name
components in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc. but would not match
example.com or foo.bar.example.com. *.*.example.com would match
foo.bar.example.com but would not match foo.example.com.
Notes:
It seems the original wording unintentionally disallowed certificates with *.* wildcards.
Source of RFC: diffserv (tsv)
Errata ID: 413
Status: Reported
Type: Editorial
Reported By: Bud
Date Reported: 2005-05-24
Section 1 says:
For example, if traffic conditioning actions at the ingress of the provider DS domain make sure that an AF class in the DS nodes is only moderately loaded by packets with the lowest drop precedence value and is not overloaded by packets with the two lowest drop precedence values, then the AF class can offer a high level of forwarding assurance for packets that are within the subscribed profile (i.e., marked with the lowest drop precedence value) and offer up to two lower levels of forwarding assurance for the excess traffic.
It should say:
For example, if traffic conditioning actions at the ingress of the provider DS domain make sure that an AF class in the DS nodes is only moderately loaded by packets with the lowest drop precedence value and is not overloaded by packets with the two higher drop precedence values, then the AF class can offer a high level of forwarding assurance for packets that are within the subscribed profile (i.e., marked with the lowest drop precedence value) and offer up to two lower levels of forwarding assurance for the excess traffic.
Source of RFC: diffserv (tsv)
Errata ID: 1708
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-06
Section A.3.1 says:
We chose these two since they"re the best and worst cases, respectively, for jitter and we wanted to supply rough guidelines for EF implementers choosing to use WRR or similar mechanisms.
It should say:
We chose these two since they"re the worst and best cases, respectively, for jitter and we wanted to supply rough guidelines for EF implementers choosing to use WRR or similar mechanisms.
Source of RFC: http (app)
Errata ID: 412
Status: Verified
Type: Technical
Reported By:
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: 411
Status: Reported
Type: Technical
Reported By: WooJin Chung
Date Reported: 2006-10-31
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:
[not supplied]
Notes:
As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ).
And if you see the definition of '#', you can find out that null element
can't be counted, and this means you can't just leave a blank after
Accept-Encoding: .
But in the given example, there exists a blank space and this is considered
as a correct one.
The second error is at the last line. Right after the semi-colon, there
can't be a space(SP) by definition, but there actually is in the example.
Errata ID: 892
Status: Reported
Type: Editorial
Reported By: WooJin Chung
Date Reported: 2006-10-31
Section 4.4 says:
4. If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length.
It should say:
4. If the message uses the media type "multipart/byteranges", and the
transfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length.
Errata ID: 1483
Status: Reported
Type: Editorial
Reported By: Martin Kong
Date Reported: 2008-08-06
Section 3.6 says:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
It should say:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.5), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
Notes:
The tokens for Content-Codings are defined in section 3.5. These include the identity token.
Errata ID: 1619
Status: Reported
Type: Editorial
Reported By: Heming Hou
Date Reported: 2008-11-25
Section 4.4 says:
4.If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length. This media type
UST NOT be used unless the sender knows that the recipient can arse
it; the presence in a request of a Range header with ultiple byte-
range specifiers from a 1.1 client implies that the lient can parse
multipart/byteranges responses.
It should say:
4.If the message uses the media type "multipart/byteranges", and the
transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media type
MUST NOT be used unless the sender knows that the recipient can parse
it; the presence in a request of a Range header with multiple byte-
range specifiers from a 1.1 client implies that the client can parse
multipart/byteranges responses.
Notes:
> "ransfer-length" should be "transfer-length"
> "self-elimiting" should be "self-delimiting";
> "UST"should be "MUST";
> "arse"should be "parse";
> "ultiple"should be "multiple";
> "lient"should be "client";
Source of RFC: http (app)
Errata ID: 652
Status: Verified
Type: Technical
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.
Errata ID: 653
Status: Verified
Type: Technical
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: 410
Status: Verified
Type: Technical
Reported By:
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: 408
Status: Verified
Type: Technical
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: 1959
Status: Verified
Type: Technical
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: 1649
Status: Reported
Type: Technical
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-08
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: 1914
Status: Reported
Type: Technical
Reported By: Larry Westrick
Date Reported: 2009-10-14
Section 3.2.2.1 says:
3.2.2.1 Request-Digest
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
If the "qop" directive is not present (this construction is for
compatibility with RFC 2069):
request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
<">
It should say:
3.2.2.1 Request-Digest
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1) ":" unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
If the "qop" directive is not present (this construction is for
compatibility with RFC 2069):
request-digest =
<"> < KD ( H(A1) ":" unq(nonce-value) ":" H(A2) ) >
<">
Notes:
Errata 1796 addressing this issue and was rejected, perhaps for editorial or syntax reasons, when the section as it exists does not indicate the need for a ":" between A1 and unq(nonce-value). The ":" is most certainly required between these variables if the result of the hash is to be correct.
Errata ID: 606
Status: Verified
Type: Editorial
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
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)"...
Errata ID: 1796
Status: Rejected
Type: Editorial
Reported By: Jerry Conrad
Date Reported: 2009-06-19
Rejected by: Alexey Melnikov
Date Rejected: 2009-06-19
Section 3.2.2.1 says:
3.2.2.1 Request-Digest
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
If the "qop" directive is not present (this construction is for
compatibility with RFC 2069):
request-digest =
<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) >
<">
It should say:
3.2.2.1 Request-Digest
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1) ":" unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
If the "qop" directive is not present (this construction is for
compatibility with RFC 2069):
request-digest =
<"> < KD ( H(A1) ":" unq(nonce-value) ":" H(A2) ) >
<">
Notes:
The "," after H(A1) should be ":" in two places.
--VERIFIER NOTES--
KD is defined in the document as:
KD(secret, data) = H(concat(secret, ":", data))
So KD takes 2 parameters and the text in the RFC is correct in this respect.
Source of RFC: ipfc (int)
Errata ID: 407
Status: Verified
Type: Technical
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
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
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
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
Source of RFC: smime (sec)
Errata ID: 406
Status: Verified
Type: Editorial
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
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.
Source of RFC: smime (sec)
Errata ID: 1060
Status: Reported
Type: Editorial
Reported By: Javier Ader
Date Reported: 2007-09-13
This reference is cited in Section 1, but does not appear in the
References section. It should be added:
[DH76] W. Diffie and M. E. Hellman, "New Directions in Cryptography",
IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976,
pp: 644-654.
Source of RFC: smime (sec)
Errata ID: 405
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 404
Status: Reported
Type: Technical
Reported By: Tony Finch
Date Reported: 2005-08-30
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.
Source of RFC: find (app)
Errata ID: 403
Status: Verified
Type: Technical
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/>
Source of RFC: find (app)
Errata ID: 402
Status: Verified
Type: Technical
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/>
Source of RFC: pppext (int)
Errata ID: 401
Status: Verified
Type: Technical
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: 2049
Status: Reported
Type: Technical
Reported By: Wang Haojian
Date Reported: 2010-02-22
Section 1.2 says:
DSLAM Digital Subscriber Line (DSL) Access Module
It should say:
DSLAM Digital Subscriber Line (DSL) Access Multiplexer
Notes:
I think 'Multiplexer' is more appropriate
Source of RFC: nat (tsv)
Errata ID: 400
Status: Verified
Type: Technical
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).
Errata ID: 1432
Status: Reported
Type: Technical
Reported By: Harald Hubich
Date Reported: 2008-05-29
Section 4.3. says:
b) After twice-NAT translation, in private network
SA: 200.200.200.1 DA: 172.16.1.100
It should say:
b) After twice-NAT translation, in private network
DA: 200.200.200.1 SA: 172.16.1.100
Notes:
tricky :)
Source of RFC: dnsind (int)
Errata ID: 1679
Status: Reported
Type: Technical
Reported By: John Klensin
Date Reported: 2009-02-09
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.
Finally, the source of this document in the RFC database is listed as "Legacy". Since it was first published as Standards Track, the source must be IETF.
Source of RFC: ospf (rtg)
Errata ID: 399
Status: Verified
Type: Technical
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 |
-----------------
Source of RFC: ippm (tsv)
Errata ID: 398
Status: Held for Document Update
Type: Technical
Reported By: Andrew Main
Date Reported: 2002-11-18
Held for Document Update by: Lars Eggert
Date Held: 2009-04-07
Section 5.1 says:
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger.
It should say:
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. See Section 11.3 of [1] for computing percentiles.
Notes:
See the list of samples immediately preceding that paragraph.
Source of RFC: ippm (tsv)
Errata ID: 1528
Status: Verified
Type: Technical
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.
Source of RFC: ippm (tsv)
Errata ID: 397
Status: Held for Document Update
Type: Technical
Reported By: Andrew Main
Date Reported: 2002-11-18
Held for Document Update by: Lars Eggert
Date Held: 2009-05-14
Section 4.1 says:
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger.
It should say:
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. See Section 11.3 of [1] for computing percentiles.
Notes:
Corrected text suggested by Matt Zekauskas (matt@internet2.edu).
Source of RFC: Legacy
Errata ID: 396
Status: Verified
Type: Technical
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: Reported
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2009-05-09
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/>).
Source of RFC: ipngwg (int)
Errata ID: 1422
Status: Verified
Type: Editorial
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
Source of RFC: entmib (ops)
Errata ID: 395
Status: Verified
Type: Technical
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
Source of RFC: ospf (rtg)
Errata ID: 394
Status: Verified
Type: Technical
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: 392
Status: Verified
Type: Technical
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: 609
Status: Verified
Type: Technical
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
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
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
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
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
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
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
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
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
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
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
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
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 393
Status: Reported
Type: Editorial
Reported By: Acee Lindem
Date Reported: 2003-02-22
Section 2.5 says:
Link-local unicast addresses are assigned from the IPv6 address range FF80/10.
It should say:
Link-local unicast addresses are assigned from the IPv6 address range FE80::/10.
Notes:
The IPv6 link-local address range is incorrect.
Source of RFC: cat (sec)
Errata ID: 1620
Status: Reported
Type: Editorial
Reported By: Ben Harris
Date Reported: 2008-11-25
Section 5.15 says:
Since some application-level protocols may wish to use tokens emitted by gss_wrap() to provide "secure framing", implementations must support derivation of MICs from zero-length messages.
It should say:
Since some application-level protocols may wish to use tokens emitted by gss_get_mic() to provide "secure framing", implementations must support derivation of MICs from zero-length messages.
Source of RFC: pppext (int)
Errata ID: 391
Status: Verified
Type: Technical
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: Reported
Type: Technical
Reported By: Alexey Melnikov
Date Reported: 2009-10-22
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.
Source of RFC: isis (rtg)
Errata ID: 390
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 389
Status: Verified
Type: Technical
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
Source of RFC: Legacy
Errata ID: 1706
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-03
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.
Source of RFC: Legacy
Errata ID: 388
Status: Verified
Type: Technical
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
Source of RFC: IAB
Errata ID: 1874
Status: Reported
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-09-10
Section 4 says:
centered around
It should say:
revolved around
Notes:
I don't mean to split hairs here, but, really, something cannot center around something, only revolve. Feel free to reject this report, however.
Source of RFC: Legacy
Errata ID: 387
Status: Verified
Type: Technical
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".
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 384
Status: Verified
Type: Technical
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: 386
Status: Verified
Type: Technical
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: 385
Status: Verified
Type: Technical
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: 991
Status: Reported
Type: Technical
Reported By: Stefan Hoffmeister
Date Reported: 2007-06-10
Section 2.3.1 says:
shortname =3D ( letter / digit ) *( letter / digit / "-" )
*( letter / digit )
; as specified in RFC 1123 [HNAME]
It should say:
shortname =3D ( letter / digit ) [ *( letter / digit / "-" ) ( letter = / digit ) ]
Notes:
>From RFC 1123:
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
In RFC 952 the definition of a shortname looks like this
<name> ::=3D <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
from pending
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 383
Status: Reported
Type: Editorial
Reported By:
Date Reported: 2006-08-28
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.
Source of RFC: tls (sec)
Errata ID: 1801
Status: Verified
Type: Technical
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>
Source of RFC: tls (sec)
Errata ID: 1077
Status: Reported
Type: Editorial
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Date Edited: 2007-11-14
Section 3.1 says:
Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
It should say:
Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. *.*.a.com matches foo.bar.a.com but not foo.com
Notes:
This updated example makes explicit that more than one wildcard is allowed in a certificate.
Source of RFC: rmonmib (ops)
Errata ID: 1400
Status: Reported
Type: Technical
Reported By: Mehala
Date Reported: 2008-03-31
Section 1 2 &3 says:
1. matrixDSSourceAddress 2. matrixDSDestAddress 3. hostAddress
It should say:
Definition of OBJECT-TYPE 1, 2 & 3
Notes:
Got error while compiling the MIB. Error says the above objects "must have size restriction".
Source of RFC: ldapext (app)
Errata ID: 382
Status: Reported
Type: Editorial
Reported By: Hallvard B Furuseth
Date Reported: 2005-01-06
The abstract says:
This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service.
It should say:
This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Access Protocol (LDAP) directory service.
Notes:
Source of RFC: drums (app)
Errata ID: 380
Status: Verified
Type: Technical
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: 375
Status: Reported
Type: Technical
Reported By: Jochen Topf
Date Reported: 2004-11-23
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:
This change becomes especially clear, when looking at the following two paragraphs.
Errata ID: 760
Status: Reported
Type: Technical
Reported By: Wayne Schlitt
Date Reported: 2005-05-12
Section 2.4.1 says:
In several places, RFC2821 refers to "section 2.4.1.". Unfortunately there *is* no section 2.4.1. To be quite honest, I'm really not sure what the intended section number is. It doesn't appear obvious to me.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 374
Status: Reported
Type: Technical
Reported By: Mathias Koerber
Date Reported: 2006-10-15
Section 4.2.5 says:
When an SMTP server returns a permanent error status (5yz) code after...
It should say:
When an SMTP server returns a transient error status (4xy) code after...
Notes:
I believe this to be a mistake and that it should read 'transient
error status (4xy)' as this paragraph talks about requeuing and the
permanent case is discussed 2 paragraphs down:
The user who originated the message SHOULD be able to interpret the
return of a transient failure status (by mail message or otherwise)
as a non-delivery indication, just as a permanent failure would be
interpreted. I.e., if the client SMTP successfully handles these
conditions, the user will not receive such a reply.
When an SMTP server returns a permanent error status (5yz) code after
the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
any subsequent attempt to deliver the message. As with temporary
error status codes, the SMTP client retains responsibility for the
message, but SHOULD not again attempt delivery to the same server
without user review and intervention of the message.
This came up in a discussion whether it is legal for a server to
send a transient failure after DATA and the subsequent <CRLF>.<CRLF>
Errata ID: 378
Status: Verified
Type: Editorial
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: 377
Status: Verified
Type: Editorial
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: 381
Status: Verified
Type: Editorial
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
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
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".
Errata ID: 376
Status: Verified
Type: Editorial
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: 379
Status: Verified
Type: Editorial
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.
Source of RFC: drums (app)
Errata ID: 373
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2006-01-10
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
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 372
Status: Reported
Type: Editorial
Reported By: "Craig A. Huegen"
Date Reported: 2002-11-20
Reference says:
[9] Thanks to: Craig Huegen; See:
http://www.quadrunner.com/~chuegen/smurf.txt.
It should say:
[9] Thanks to: Craig Huegen; See:
http://www.pentics.net/denial-of-service/white-papers/smurf.html.
Notes:
Tried to preserve the old URL, but could not.
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 680
Status: Reported
Type: Technical
Reported By: Sebastian Kulpa
Date Reported: 2002-03-24
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) <---- THERE IS A FIELD ar$rhl
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 <---- THERE SHOULD BE A FIELD ar$rhl TOO, not as$rln...
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:
from pending
Source of RFC: fax (app)
Errata ID: 371
Status: Verified
Type: Editorial
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 )
Source of RFC: idr (rtg)
Errata ID: 370
Status: Reported
Type: Editorial
Reported By: "Tom Petch"
Date Reported: 2005-02-04
IANA Considerations say:
"... The SAFI name space is defined in Section 9...."
It should say:
"... The SAFI name space is defined in Section 5...."
Errata ID: 369
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-19
Section 8 says:
As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
attributes contain the Subsequence Address Family Identifier (SAFI)
field. The SAFI name space is defined in Section 9. ...
Notes:
There isn't SAFI name space definition in RFC 2858. This name name space
definition presents in obsoleted RFC 2283 but completely removed from
RFC 2858.
Source of RFC: tsvwg (tsv)
Errata ID: 1303
Status: Verified
Type: Editorial
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.
Source of RFC: radius (ops)
Errata ID: 368
Status: Verified
Type: Technical
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: Reported
Type: Technical
Reported By: Isaac NickAein
Date Reported: 2008-07-13
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
Source of RFC: radius (ops)
Errata ID: 367
Status: Verified
Type: Editorial
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:
Source of RFC: Legacy
Errata ID: 366
Status: Verified
Type: Technical
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.
Source of RFC: smime (sec)
Errata ID: 1839
Status: Reported
Type: Technical
Reported By: Sean Turner
Date Reported: 2009-08-25
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.
Source of RFC: tsvwg (tsv)
Errata ID: 365
Status: Verified
Type: Editorial
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
Source of RFC: ipp (app)
Errata ID: 364
Status: Verified
Type: Technical
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
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:
Source of RFC: enum (rai)
Errata ID: 362
Status: Verified
Type: Technical
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
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.
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 361
Status: Reported
Type: Editorial
Reported By: Trish Lynch
Date Reported: 2002-08-08
Section 3 says:
The syntax of the List-Id header follows: list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
It should say:
The syntax of the List-Id header follows: list-id-header = "List-Id:" [phrase] "<" list-id ">" CRLF
Notes:
In order to bring it in line with the examples, and with common usage (by
the RFC, the List-ID is correct) most mail readers use the example and
do not consider the LHS case insensitive, since the RFC says:
The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].
RFC822, while it says that most headers are character insensitive, does
not mandate that, and RFC 2919 only mandates that the List-Id: header is
subject to *encoding* and *character restrictions*, and does not say it
needs to adhere to case insensitivity.
Therefore, the proposed change above will bring things more in line with common
usage.
Source of RFC: disman (ops)
Errata ID: 360
Status: Verified
Type: Technical
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)."
Source of RFC: schema (app)
Errata ID: 359
Status: Verified
Type: Technical
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 ) )
Source of RFC: conneg (app)
Errata ID: 1080
Status: Verified
Type: Technical
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
Source of RFC: dhc (int)
Errata ID: 358
Status: Verified
Type: Technical
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: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-02-02
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
Source of RFC: http (app)
Errata ID: 1491
Status: Reported
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2008-08-20
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.
Source of RFC: Legacy
Errata ID: 357
Status: Verified
Type: Technical
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
Reported By: Ned Freed
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-15
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.
Source of RFC: Legacy
Errata ID: 356
Status: Verified
Type: Technical
Reported By: Robert Moskowitz
Date Reported: 2000-12-13
* 5.6 Attributes defined in S/MIMIE .............................. 18
It should say:
* 5.6 Attributes defined in S/MIME .............................. 18
Source of RFC: tsvwg (tsv)
Errata ID: 1308
Status: Verified
Type: Editorial
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.
Source of RFC: Legacy
Errata ID: 355
Status: Verified
Type: Technical
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.
Source of RFC: nfsv4 (tsv)
Errata ID: 354
Status: Verified
Type: Technical
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.
Source of RFC: megaco (rai)
Errata ID: 353
Status: Verified
Type: Technical
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"
Source of RFC: nat (tsv)
Errata ID: 2047
Status: Reported
Type: Editorial
Reported By: cloengard
Date Reported: 2010-02-21
Section 2.2 says:
... sends the packet to it's primary router. ... =========================>
It should say:
... sends the packet to its primary router. ...
Notes:
it's => its: use possessive form, not contraction
Source of RFC: Legacy
Errata ID: 352
Status: Verified
Type: Technical
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"?>
Source of RFC: mobileip (int)
Errata ID: 351
Status: Verified
Type: Technical
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,
Source of RFC: Legacy
Errata ID: 350
Status: Verified
Type: Technical
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: Reported
Type: Technical
Reported By: Costin Chirvasuta
Date Reported: 2008-08-21
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.
Source of RFC: Legacy
Errata ID: 349
Status: Verified
Type: Technical
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.
Source of RFC: mpls (rtg)
Errata ID: 348
Status: Verified
Type: Editorial
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
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
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.
Source of RFC: mpls (rtg)
Errata ID: 982
Status: Reported
Type: Technical
Reported By: Stephane Bortzmeyer
Date Reported: 2007-05-18
Section 2.3.2 says:
Since an ICMP message is never sent as a result of receiving an ICMP
message,
It should say:
[not submitted]
Notes:
But this is not what RFC 1122 says in section 3.2.2 :
An ICMP error message MUST NOT be sent as the result of
receiving:
* an ICMP error message, or
("error message", not just "message")
Counter-example: when I ping a host, an ICMP echo-reply message is
generated as the result of my echo-request message. I believe RFC 3032
is wrong here, although it does not seem to have practical
consequences.
(RFC 4379 is also an useful reading here)
from pending
Errata ID: 347
Status: Verified
Type: Editorial
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.
Source of RFC: mpls (rtg)
Errata ID: 346
Status: Verified
Type: Technical
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.
Errata ID: 345
Status: Rejected
Type: Editorial
Reported By: Barbara Denny
Date Reported: 2006-04-13
Rejected by: Adrian Farrel
Date Rejected: 2009-08-24
Report Text:
A reference for [Dobb] is missing. Rationale: In section 2.9.1, there is a mention of a problem with MD5. The text refers to [Dobb] but the reference section contains no citation. --VERIFIER NOTES-- RFC3036 has been obsoleted by RFC5036. The text that gives rise to this issue is a direct quote from RFC 2385. That reference should be explored to determine the full implications of the text.
Errata ID: 1837
Status: Rejected
Type: Editorial
Reported By: Barbara Denny
Date Reported: 2006-04-13
Rejected by: Adrian Farrel
Date Rejected: 2009-08-24
Report Text:
A reference for [Dobb] is missing. Rationale: In section 2.9.1, there is a mention of a problem with MD5. The text refers to [Dobb] but the reference section contains no citation. --VERIFIER NOTES-- RFC 3036 has been obsoleted by RFC 5036. The text at issue is a quote from another RFC. That RFC can be inspected to find the full context.
Source of RFC: mpls (rtg)
Errata ID: 344
Status: Verified
Type: Technical
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.
Source of RFC: avt (rai)
Errata ID: 343
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 342
Status: Verified
Type: Technical
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
Source of RFC: ngtrans (ops)
Errata ID: 341
Status: Verified
Type: Technical
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
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:
Errata ID: 2070
Status: Reported
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-03-09
Section Abstract says:
The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity.
It should say:
The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain native IPv6 connectivity.
Notes:
s/natuve/native/
Source of RFC: Legacy
Errata ID: 1751
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 340
Status: Verified
Type: Technical
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.
Source of RFC: idr (rtg)
Errata ID: 338
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-25
Appendix A says:
The most notable change from [1] is that of reversing the values AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in section "AS_CONFED Segment Type Extension". The reasoning for this is that in the initial implementation, which was already widely deployed, they were implemented backwards from [4], and as such, subsequent implementations implemented them backwards as well. In order to foster interoperability and compliance with deployed implementations, they've therefore been changed here as well.
It should say:
The most notable change from [5] is that of reversing the values
AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
section "AS_CONFED Segment Type Extension". The reasoning foridely
deployed, they were implemented backwards from [4], and as such,
subsequent implementations implemented them backwards as well. In
order to foster interoperability and compliance with deployed
implementations, they've therefore been changed here as well.
Notes:
There is an error in line 1 of Appendix A (RFC 3065). reference
to document [1] is wrong and must be changed to [5].
Errata ID: 339
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-25
Appendix A says:
The most notable change from [1] is that of reversing the values
AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
section "AS_CONFED Segment Type Extension". The reasoning for this
is that in the initial implementation, which was already widely
deployed, they were implemented backwards from [4], and as such,
subsequent implementations implemented them backwards as well. In
order to foster interoperability and compliance with deployed
implementations, they've therefore been changed here as well.
It should say:
The most notable change from [4] is that of reversing the values
AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
section "AS_CONFED Segment Type Extension". The reasoning foridely
deployed, they were implemented backwards from [4], and as such,
subsequent implementations implemented them backwards as well. In
order to foster interoperability and compliance with deployed
implementations, they've therefore been changed here as well.
Notes:
Sorry for mistype error in my previous message.
There is a mistype error in line 1 of Appendix A (RFC 3065). reference
to document [1] is wrong and must be changed to [4].
Source of RFC: Legacy
Errata ID: 337
Status: Verified
Type: Technical
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/
Errata ID: 336
Status: Verified
Type: Technical
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.
Source of RFC: Legacy
Errata ID: 335
Status: Verified
Type: Technical
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!
Source of RFC: beep (app)
Errata ID: 992
Status: Verified
Type: Technical
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
Source of RFC: ipcdn (ops)
Errata ID: 334
Status: Verified
Type: Technical
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)
Source of RFC: INDEPENDENT
Errata ID: 1454
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-06-15
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.
Source of RFC: nat (tsv)
Errata ID: 333
Status: Verified
Type: Technical
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:
Source of RFC: mmusic (rai)
Errata ID: 332
Status: Verified
Type: Technical
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
Source of RFC: avt (rai)
Errata ID: 331
Status: Verified
Type: Technical
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"
Source of RFC: smime (sec)
Errata ID: 1067
Status: Verified
Type: Technical
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
Source of RFC: Legacy
Errata ID: 1634
Status: Reported
Type: Technical
Reported By: Julian Reschke
Date Reported: 2008-12-13
Section 2.2.2 says:
2.2.2 Interception proxies prevent introduction of new HTTP methods
Name
Interception proxies prevent introduction of new HTTP methods
Classification
Architecture
Description
A proxy that receives a request with a method unknown to it is
required to generate an HTTP 501 Error as a response. HTTP
methods are designed to be extensible so there may be applications
deployed with initial support just for the user agent and origin
server. An interception proxy that hijacks requests which include
new methods destined for servers that have implemented those
methods creates a de-facto firewall where none may be intended.
Significance
Medium within interception proxy environments.
Implications
Renders new compliant applications useless unless modifications
are made to proxy software. Because new methods are not required
to be globally standardized it is impossible to keep up to date in
the general case.
Solution(s)
Eliminate the need for interception proxies. A client receiving a
501 in a traditional HTTP environment may either choose to repeat
the request to the origin server directly, or perhaps be
configured to use a different proxy.
Workaround
Level 5 switches (sometimes called Level 7 or application layer
switches) can be used to keep HTTP traffic with unknown methods
out of the proxy. However, these devices have heavy buffering
responsibilities, still require TCP sequence number spoofing, and
do not interact well with persistent connections.
The HTTP/1.1 specification allows a proxy to switch over to tunnel
mode when it receives a request with a method or HTTP version it
does not understand how to handle.
Contact
Patrick McManus <mcmanus@AppliedTheory.com>
Henrik Nordstrom <hno@hem.passagen.se> (HTTP/1.1 clarification)
It should say:
- none -
Notes:
The whole subsection needs to be removed. There is no requirement in RFC2616 for proxies to generate a 501 status for unknown methods.
Source of RFC: pkix (sec)
Errata ID: 1879
Status: Reported
Type: Technical
Reported By: Nick Pope
Date Reported: 2009-09-15
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: 844
Status: Held for Document Update
Type: Editorial
Reported By: Stefan Doerpinghaus
Date Reported: 2007-01-31
Held for Document Update by: Tim Polk
Section 2.4.2 says:
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }
It should say:
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17),
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }
Notes:
Missing comma after the descriptor of the OID of PKIFailureInfo,
at the end of line "addInfoNotAvailable (17).
from pending
Source of RFC: Legacy
Errata ID: 1923
Status: Reported
Type: Technical
Reported By: Alan DeKok
Date Reported: 2009-10-22
Section 2.1 says:
Address
The Address field is 16 octets.
It should say:
String The field is 16 octets
Notes:
As Glen notes in:
http://ops.ietf.org/lists/radiusext/2009/msg00540.html
Using "ipv6 address" for a data type in RADIUS is wrong.
RFC 3162 (among others Glen wrote) contradict his current position. Those documents use data types for the "value" field of RADIUS attributes that have not been defined in RFC 2865. As such, they should either:
a) make it clear that they define a new data type, and be marked as "Updates: 2865"
or
b) use the dat