|
|
|
|
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: 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.
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
Report Text:
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.
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.
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: 784
Status: Reported
Type: Technical
Reported By: Ian D. Allen
Date Reported: 2006-09-22
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
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: 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: Reported
Type: Editorial
Reported By: Pei-chun Cheng
Date Reported: 2008-01-14
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: 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 "@".
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.
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: 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.
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| | | | |
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: 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: 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: Legacy
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: Legacy
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: Legacy
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: Legacy
Errata ID: 1434
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-06-07
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: 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: Legacy
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: 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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: Legacy
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: 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: Legacy
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: 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: Legacy
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: Legacy
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")
Source of RFC: Legacy
Errata ID: 521
Status: Reported
Type: Editorial
Reported By: Pete Resnick
Date Reported: 2006-03-21
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 [BCP 10].
Notes:
from pending
Errata ID: 764
Status: Reported
Type: Editorial
Reported By: Pete Resnick
Date Reported: 2006-03-21
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: Legacy
Errata ID: 512
Status: Reported
Type: Editorial
Reported By: Ned Freed
Date Reported: 2005-02-24
Section 5.1 says:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
It should say:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <"> /
"/" / "[" / "]" / "?" / "="
Source of RFC: Legacy
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 1