|
|
|
|
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.
Errata ID: 2061
Status: Held for Document Update
Type: Editorial
Reported By: Hsu Yun-Che
Date Reported: 2010-03-03
Held for Document Update by: ron bonica
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."
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.
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.
Errata ID: 1053
Status: Verified
Type: Technical
Reported By: Noel Chiappa
Date Reported: 2007-08-13
Verifier Name: ron bonica
Date Verified: 2010-05-11
On page 3, it says:
It is important to remember that there are 356 links in each direction and that no relationship among these is imposed by the network.
It should say:
It is important to remember that there are 256 links in each direction and that no relationship among these is imposed by the network.
Errata ID: 1780
Status: Verified
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Verifier Name: ron bonica
Date Verified: 2010-05-11
Throughout the document, when it says:
RFMN
It should say:
RFNM
Notes:
This typo occurs twice on page 4.
Errata ID: 1781
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Held for Document Update by: ron bonica
Section I says:
singify
It should say:
signify
Errata ID: 1782
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-11
Held for Document Update by: ron bonica
Section II says:
wre
It should say:
were
Errata ID: 1784
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-15
Held for Document Update by: ron bonica
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
Errata ID: 2650
Status: Verified
Type: Technical
Reported By: Mykyta Yevstifeyev
Date Reported: 2010-11-30
Verifier Name: ron bonica
Date Verified: 2011-10-12
Throughout the document, when it says:
Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
It should say:
[NONE - see Notes]
Notes:
This section has been added to the original RFC while putting it to machine-readable form. The original RFC did NOT contain this section.
Errata ID: 2678
Status: Verified
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2010-12-21
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Throughout the document, when it says:
Network Working Group R. Kalin Request for Comments: 60 MIT Category: Experimental 13 July 1970
It should say:
Network Working Group R. Kalin
Request for Comments: 60 MIT
13 July 1970
Notes:
The 'Category' subheader has been added to the text of RFC while putting in machine-readable form. Original RFC text did NOT contain this subheader.
Note: This RFC has been obsoleted by RFC0123
Source of RFC: Legacy
Errata ID: 1772
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-05-04
Held for Document Update by: ron bonica
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.
Errata ID: 1814
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-07-20
Held for Document Update by: ron bonica
Section header says:
Metcalff
It should say:
Metcalfe
Note: This RFC has been obsoleted by RFC1350
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
Errata ID: 2795
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-02
Held for Document Update by: ron bonica
Section 1 says:
The Reference Model was developed to serve as a framework for the coordination of existing and future standards designed to facilitate the interconnection of data processing systems. The purpose of OSI is to enable an end-user application activity (called an "application process") located in a system that employs OSI procedures and protocols (an "open" system) to communicate with any other appication process located in any other open system. It is not the intent of OSI to specify either the functions or the implementation details of systems that provide the OSI capabilities. Communication is achieved by mutual adherence to agreed-upon (standardized) services and protocols; the only thing that an OSI entity in a given layer in one system needs to know about an OSI entity in the same layer
It should say:
The Reference Model was developed to serve as a framework for the coordination of existing and future standards designed to facilitate the interconnection of data processing systems. The purpose of OSI is to enable an end-user application activity (called an "application process") located in a system that employs OSI procedures and protocols (an "open" system) to communicate with any other application process located in any other open system. It is not the intent of OSI to specify either the functions or the implementation details of systems that provide the OSI capabilities. Communication is achieved by mutual adherence to agreed-upon (standardized) services and protocols; the only thing that an OSI entity in a given layer in one system needs to know about an OSI entity in the same layer
Notes:
Typo in "application": s/appication/application
Errata ID: 716
Status: Verified
Type: Technical
Reported By: Damien Mattei
Date Reported: 2007-01-03
Verifier Name: Ralph Droms
Date Verified: 2010-12-06
Section 3.1 says:
+--------+--------+--------+--------+
|10001000|00000010| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
It should say:
+--------+--------+--------+--------+
|10001000|00000100| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
Rationale:
This number count the length which is 4 and not 2.
10 in binary is 2 in decimal, 100 in binary is 4 in decimal.
The option-length octet counts the option-type octet and the
option-length octet as well as the option-data octets.(see page 15)
The length is 4 for the Stream identifier option as we have 4 bytes and
it is well written in page 16 of RFC 791:
The following internet options are defined:
CLASS NUMBER LENGTH DESCRIPTION
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 11 Security. Used to carry Security,
Compartmentation, User Group (TCC), and
Handling Restriction Codes compatible with DOD
requirements.
0 3 var. Loose Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 9 var. Strict Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 7 var. Record Route. Used to trace the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
2 4 var. Internet Timestamp.
Notes:
from pending
Errata ID: 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: 3074
Status: Reported
Type: Editorial
Reported By: ChengYan Wang
Date Reported: 2012-01-04
Section 3.1 Page 12 says:
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
It should say:
Bits 5: 0 = Normal Reliability, 1 = High Reliability.
Notes:
Spelling error.
Errata ID: 578
Status: Held for Document Update
Type: Editorial
Reported By: Yin Shuming
Date Reported: 2006-02-18
Held for Document Update by: ron bonica
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).
Errata ID: 2295
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica
Section Page 27 says:
For example, one could implement a fragmentation procedure that repeatly divided large datagrams in half until the resulting fragments were less than the maximum transmission unit size.
It should say:
For example, one could implement a fragmentation procedure that repeatedly divided large datagrams in half until the resulting fragments were less than the maximum transmission unit size.
Notes:
s/ repeatly/repeatedly/
Errata ID: 2294
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: ron bonica
Section Page 21 says:
If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route begining at the octet indicated by the pointer, and increments the pointer by four.
It should say:
If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route beginning at the octet indicated by the pointer, and increments the pointer by four.
Notes:
s/begining/beginning/g
Errata ID: 2519
Status: Held for Document Update
Type: Editorial
Reported By: Yaakov (J) Stein
Date Reported: 2010-09-14
Held for Document Update by: ron bonica
Section 3.1 says:
Total Length is the length of the datagram, measured in octets, including internet header and data.
It should say:
Total Length is the length of the datagram or fragment, measured in octets, including internet header and data.
Notes:
Section 2.3 makes it clear that during fragmentation the total length field is corrected to the length of the fragment. Wording such as "break a datagram into an almost arbitrary number of pieces" implies that "datagram" means the entire original packet. Thus, without the proposed correction, one may be led to believe that the total length contains the length of the original datagram.
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: Held for Document Update
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-01-04
Held for Document Update by: ron bonica
In the Introduction, it 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: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-02
Held for Document Update by: ron bonica
On page 14, it says:
IP Fields:
Type
8 for echo message;
It should say:
ICMP Fields:
Type
8 for echo message;
Errata ID: 2935
Status: Held for Document Update
Type: Editorial
Reported By: Jeffrey Connell
Date Reported: 2011-08-13
Held for Document Update by: ron bonica
On page 17, it says:
The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests.
It should say:
The identifier and sequence number may be used by the timestamp sender to aid in matching the replies with the requests.
Notes:
In the "Description" of the "Timestamp or Timestamp Reply" message. Appears to be a copy-paste error from the "Echo or Echo Reply" message's description.
Errata ID: 2936
Status: Held for Document Update
Type: Editorial
Reported By: Jeffrey Connell
Date Reported: 2011-08-13
Held for Document Update by: ron bonica
On page 19, it says:
The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests.
It should say:
The identifier and sequence number may be used by the information request sender to aid in matching the replies with the requests.
Notes:
In the "Description" of the "Information Request or Information Reply" message. Appears to be a copy-paste error from the "Echo or Echo Reply" message's description.
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 before any implementation of RFC 793 is attempted.
TCP Feature RFC 793 Ref See RFC 1122 Section Received PUSH bit Section 2.8 4.2.2.2 Urgent Pointer Section 3.1 4.2.2.4 TCP state diagram Section 3.2, p.23 4.2.2.8 Simultaneous Open Section 3.4, Fig 8 4.2.2.10 Retransmission Timeout Section 3.7 4.2.2.15, 4.2.3.1 Event Processing Section 3.9 4.2.2.20
Errata ID: 1562
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.3 says:
Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data in the segment. ... the numbers occupied by a segment are "busy" or "in use" until MSL seconds have passed, upon crashing a block of space-time is occupied by the octets of the last emitted segment,
It should say:
Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data and SYN or FIN flags in the segment. ... the numbers occupied by a segment are "busy" or "in use" until MSL seconds have passed, upon crashing a block of space-time is occupied by the octets and SYN or FIN flags of the last emitted segment,
Notes:
I changed this text to specifically include the SYN and FIN bits, rather than the previous errata wording which was unclear since other control flags are not part of the sequence space, based on discussion on the TCPM mailing list which indicated that the prior wording was confusing.
Errata ID: 1564
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.7 says:
When the sender creates a segment and transmits it the sender advances SND.NXT. When the receiver accepts a segment it advances RCV.NXT and sends an acknowledgment. When the data sender receives an acknowledgment it advances SND.UNA. The extent to which the values of these variables differ is a measure of the delay in the communication. The amount by which the variables are advanced is the length of the data in the segment. Note that once in the ESTABLISHED state all segments must carry current acknowledgment information.
It should say:
When the sender creates a segment and transmits it the sender advances SND.NXT. When the receiver accepts a segment it advances RCV.NXT and sends an acknowledgment. When the data sender receives an acknowledgment it advances SND.UNA. The extent to which the values of these variables differ is a measure of the delay in the communication. The amount by which the variables are advanced is the length of the data and SYN or FIN flags in the segment. Note that once in the ESTABLISHED state all segments must carry current acknowledgment information.
Notes:
SYN and FIN are counted, too
Errata ID: 1572
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.4 says:
If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment.
It should say:
If the incoming segment has the ACK bit set, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment.
Notes:
Every segment has an ACK field.
Errata ID: 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: 1561
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
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: 1565
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
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: 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: 1496
Status: Rejected
Type: Technical
Reported By: Yin Shuming
Date Reported: 2008-08-27
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
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".
--VERIFIER NOTES--
RFC 1122 updates RFC 793 and includes the changes noted in this errata already in section 4.2.2.20.
Errata ID: 1563
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
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 unacceptible -> 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.
--VERIFIER NOTES--
I split the editorial corrections into another errata report and accepted them as "hold for document update". The technical corrections are being rejected due to RFC 1122 updating 793 and already including clarification on setting SEQ=0 and ACK=SEG.SEQ+SEG.LEN, as suggested by this errata submission.
Errata ID: 1566
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
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?
--VERIFIER NOTES--
This is "may" and does not produce incorrect protocol behavior, so there is no reason to remove it. This rejection was validated through consulting with the TCPM list.
Errata ID: 2771
Status: Rejected
Type: Technical
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
Throughout the document, when it says:
Notes:
RFC 793 has no regulations whether it should obsolete RFC 761, which, however, is logically obvious. RFC 761 (http://tools.ietf.org/html/rfc761) is the previous version of RFC 793 and, if this errata report is verified, should be marked as obsoleted by RFC 793.
--VERIFIER NOTES--
This is not a technical matter, and should refer to the RFC metadata rather than the document.
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"
Errata ID: 2934
Status: Held for Document Update
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
Date Held: 2011-08-13
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. The reset takes its sequence
number from the ACK field of the incoming segment.
Notes:
Editorial errors:
1. Typo unacceptible -> unacceptable
2. wrong spacing and missing 'the'
Errata ID: 2296
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section 3 says:
The security paramaters may be used even in a non-secure environment (the values would indicate unclassified data), thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them.
It should say:
The security parameters may be used even in a non-secure environment (the values would indicate unclassified data), thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them.
Notes:
s/paramaters/parameters/
Errata ID: 2297
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section 3.8 says:
Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivlent service
of IP and to be used in the TCP checksum.
It should say:
Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivalent service
of IP and to be used in the TCP checksum.
Notes:
s/equivlent/equivalent/
Errata ID: 2298
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section Page 74 says:
Once the TCP takes responsibility for the data it advances RCV.NXT over the data accepted, and adjusts RCV.WND as apporopriate to the current buffer availability
It should say:
Once the TCP takes responsibility for the data it advances RCV.NXT over the data accepted, and adjusts RCV.WND as appropriate to the current buffer availability
Notes:
s/apporopriate/appropriate/
Errata ID: 2748
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy
Section 2.8 says:
2.8. Data Communication The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceeding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.
It should say:
2.8. Data Communication The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.
Notes:
s/preceeding/preceding
Errata ID: 2749
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy
Section 3.2 says:
NOTE BENE: this diagram is only a summary and must not be taken as the total specification.
It should say:
NOTA BENE: this diagram is only a summary and must not be taken as the total specification.
Notes:
The Latin phrase is correctly written 'Nota bene', but not 'Note bene'.
Errata ID: 1769
Status: Verified
Type: Editorial
Reported By: John Klensin
Date Reported: 2009-04-29
Verifier Name: ron bonica
Date Verified: 2010-05-11
Section Index says:
CCITT draft recommendation T.4. International Telegraph and Telephone Consultative Committee of the International Telecommunication Union. January 1981. (Format: TXT=17025 bytes) (Status: UNKNOWN)
It should say:
CCITT draft recommendation T.4. International Telegraph and Telephone Consultative Committee of the International Telecommunication Union. January 1981. (Format: TXT=17025 bytes) (Status: Obsoleted by ITU Recommendation T.4: Standardization of Group 3 facsimile terminals for document transmission. Available from ITU website (http://www.itu.int/) by searching for ITU-T Recommendations, T-series, T.4.)
Notes:
This document is not online. Even if one could find a copy and scan it, doing so would probably violate various ITU copyrights and, because it was a draft version, relevant agreements. The changes above provide the reader with a real title for the document and pointers to current and earlier published versions.
The actual URL for the information on this document (including links to download the various versions) is http://www.itu.int/rec/T-REC-T.4/en, but the above search instructions are long-term stable while the URL may not be.
Note: This RFC has been obsoleted by RFC2822
Source of RFC: Legacy
Errata ID: 1899
Status: Verified
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-02
Verifier Name: Pete Resnick
Date Verified: 2011-05-16
Section 3.1.4 says:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
It should say:
":sysmail" quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ special
(the) comment
Vegas atom
. special
WBA atom
Errata ID: 1083
Status: Held for Document Update
Type: Technical
Reported By: Peter Backes
Date Reported: 2007-11-21
Held for Document Update by: Pete Resnick
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: 571
Status: Held for Document Update
Type: Editorial
Reported By: SungWoon Lee
Date Reported: 2006-08-18
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02
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.
^^^^^^^^^^
Errata ID: 2528
Status: Verified
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2010-09-20
Verifier Name: ron bonica
Date Verified: 2011-10-12
Section No section says:
and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.
It should say:
and -1,297,728,000 (value which would be illegal for this protocol) corresponds to 00:00 17 Nov 1858 GMT.
Notes:
Although it is not explicit in the RFC, the 32-bits value is unsigned (otherwise, it could not end in 2036, as the RFC says). So, a negative value is not possible.
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.
Errata ID: 569
Status: Held for Document Update
Type: Technical
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Held for Document Update by: ron bonica
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)?
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: 3039
Status: Verified
Type: Technical
Reported By: Julien Moutinho
Date Reported: 2011-12-01
Verifier Name: Pete Resnick
Date Verified: 2011-12-29
Section 5.3.2 says:
<number> ::= any decimal integer 1 through 255
It should say:
<number> ::= any decimal integer 0 through 255
Notes:
if 0 is not allowed, one cannot even represent 127.0.0.1 with
<host-number> ::= <number>,<number>,<number>,<number>
[Verifier Note: This does allow syntactically for nonsense values for <byte-size>, <port-number>, and <host-number>, but this was also true in the current syntax.]
Errata ID: 3040
Status: Rejected
Type: Technical
Reported By: mark hays
Date Reported: 2011-12-01
Rejected by: Pete Resnick
Date Rejected: 2011-12-29
Section 5.3.2 says:
<number> ::= any decimal integer 1 through 255
It should say:
<byte-size> ::= any decimal integer 1 through 255 [...] <number> ::= any decimal integer 0 through 255
Notes:
I agree with the author of errata ID 3039 that excluding 0 from <number> is problematic. However, <number> is also used in the definition of <byte-size>. The text in 3.1.1.4 says that"The value of Byte size must be a decimal integer; there is no default value." Strictly speaking, then, 0 is a valid value but I don't see how zero could lead to a sensible result. Indeed the term "decimal integer" is undefined so perhaps negative values are permissible?
--VERIFIER NOTES--
See Erratum 3039. Though the change there does allow for nonsense values for <byte-size>, so does the current syntax in 959. I have accepted 3039 and rejected this as duplicate.
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: 2410
Status: Verified
Type: Editorial
Reported By: Anthony Bryan
Date Reported: 2010-08-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-08-03
Section Appendix III says:
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 776, BBN, December 1980.
It should say:
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 775, BBN, December 1980.
Notes:
Typo.
RFC 775 "Directory Oriented FTP Commands"
RFC 776 "Assigned Numbers"
Errata ID: 1941
Status: Held for Document Update
Type: Editorial
Reported By: Tomasz Kluza
Date Reported: 2009-11-09
Held for Document Update by: Peter Saint-Andre
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.
Errata ID: 2411
Status: Held for Document Update
Type: Editorial
Reported By: Anthony Bryan
Date Reported: 2010-08-03
Held for Document Update by: Peter Saint-Andre
Section 2.2 says:
type
The data representation type used for data transfer and
storage. Type implies certain transformations between the time
of data storage and data transfer. The representation types
defined in FTP are described in the Section on Establishing
Data Connections.
It should say:
type
The data representation type used for data transfer and
storage. Type implies certain transformations between the time
of data storage and data transfer. The representation types
defined in FTP are described in the Section on Data Representation
and Storage.
Notes:
The representation types defined in FTP are described in Section 3.1, Data Representation and Storage, or more specifically Section 3.1.1, Data Types.
Errata ID: 2503
Status: Held for Document Update
Type: Editorial
Reported By: Anthony Bryan
Date Reported: 2010-08-26
Held for Document Update by: Peter Saint-Andre
Section 5.3 says:
5.3. COMMANDS
The commands are Telnet character strings transmitted over the
control connections as described in the Section on FTP Commands.
The command functions and semantics are described in the Section
on Access Control Commands, Transfer Parameter Commands, FTP
Service Commands, and Miscellaneous Commands.
It should say:
5.3. COMMANDS
The commands are Telnet character strings transmitted over the
control connections as described in the Section on FTP Commands.
The command functions and semantics are described in the Section
on Access Control Commands, Transfer Parameter Commands, and FTP
Service Commands.
Notes:
There does not appear to be a section on Miscellaneous Commands, although SITE and NOOP are listed as "Miscellaneous Commands" in Section 5.4, Sequencing of Commands and Replies. SITE and NOOP are described in 4.1.3, FTP Service Commands.
Errata ID: 679
Status: Held for Document Update
Type: Technical
Reported By: Anvish
Date Reported: 2002-02-25
Held for Document Update by: ron bonica
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
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.
Errata ID: 566
Status: Rejected
Type: Editorial
Reported By: "CFeng"
Date Reported: 2002-05-05
Rejected by: ron bonica
Date Rejected: 2010-11-01
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.
--VERIFIER NOTES--
The status of this document is UNKNOWN. This means that it is so old, that it should not be used as a reference. There is really no way to know if the syntax that you point out was valid in 1987, when the document was published.
Maybe we should transition the document to HISTORIC?
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
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: 2130
Status: Reported
Type: Technical
Reported By: Alexei A. Smekalkine
Date Reported: 2010-04-05
Section 3.2.1 says:
TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.
It should say:
TTL a 32 bit unsigned integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.
Notes:
Conflicting descriptions of the type of TTL field.
Section 3.2.1 says "a 32 bit signed integer" while section 4.1.3 says "a 32 bit unsigned integer".
Errata ID: 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.
Errata ID: 2646
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-11-29
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:
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:
Errata ID: 2691
Status: Reported
Type: Editorial
Reported By: Hirochika Asai
Date Reported: 2011-01-22
Section 4.1.4 says:
In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurance of the same name.
It should say:
In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name.
Note: This RFC has been obsoleted by RFC5536 RFC5537
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: Verified
Type: Technical
Reported By: Hans Bot
Date Reported: 2009-04-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02
Section 2.2.5 says:
This command should generate a "Subject" line which is the same as the original message, except that if the original subject does not begin with "Re:" or "re:", the four characters "Re:" are inserted before the subject.
It should say:
This command should generate a "Subject" line which is the same as the original message, except that if the original subject does not begin with "Re: " or "re: ", the four characters "Re: " are inserted before the subject.
Notes:
Space has been omitted three times. Please compare with original text in RFC850 to confirm that the spaces should be there. (http://www.w3.org/Protocols/rfc850/rfc850.html)
Alexey: also see RFC 5322.
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.
Note: This RFC has been obsoleted by RFC1155
Source of RFC: Legacy
Errata ID: 2080
Status: Verified
Type: Editorial
Reported By: Vivek Gupta
Date Reported: 2010-03-19
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02
Section 4.2 says:
Each such subject type is uniquely named by its OBJECT IDENTIFIER and also has a textual name,
It should say:
Each such object type is uniquely named by its OBJECT IDENTIFIER and also has a textual name,
Notes:
The word "subject" should be replaced by the word "object" in the referred context
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;
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.
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.
Errata ID: 2464
Status: Rejected
Type: Editorial
Reported By: Anthony Bryan
Date Reported: 2010-08-15
Rejected by: ron bonica
Date Rejected: 2011-10-12
Section 4.1.2.6 says:
IMPLEMENTATION:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC-959
will be present (and in fact, Figure 3 on page 43 omits
them).
It should say:
IMPLEMENTATION:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC-959
will be present (and in fact, Figure 3 on page 45 omits
them).
Notes:
In RFC 959, Figure 3 is actually on page 45, not page 43.
--VERIFIER NOTES--
I see figure 3 at the top of page 45.
Errata ID: 2102
Status: Reported
Type: Editorial
Reported By: Alexander Zimmermann
Date Reported: 2010-04-01
Section Header says:
Network Working Group Request for Comments: 1141 Obsoletes: RFC 1071
It should say:
Network Working Group Request for Comments: 1141 Updates: RFC 1071
Notes:
The RFC-Editor said RFC 1141 updates and does not obsolete RFC 1071.
Errata ID: 2796
Status: Rejected
Type: Technical
Reported By: Bryan Irvine
Date Reported: 2011-05-04
Rejected by: ron bonica
Date Rejected: 2011-05-05
Throughout the document, when it says:
Notes:
Special Considerations:
A port mirror should not be used with avian carriers as a single collision with a mirror will result in 100% loss of that carrier.
--VERIFIER NOTES--
As will a single collision with windows.
Errata ID: 2601
Status: Verified
Type: Editorial
Reported By: Vivek Gupta
Date Reported: 2010-11-03
Verifier Name: Dan Romascanu
Date Verified: 2010-11-04
Section 4.2 says:
Each such subject type is uniquely named by its OBJECT IDENTIFIER
It should say:
Each such object type is uniquely named by its OBJECT IDENTIFIER
Notes:
The word "subject" should be replaced by the word "object" in the referred context
Note: This RFC has been obsoleted by RFC1213
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)
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.
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.
Errata ID: 683
Status: Held for Document Update
Type: Technical
Reported By: Joerg Ammon
Date Reported: 2003-03-04
Held for Document Update by: Stewart Bryant
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
Errata ID: 1843
Status: Rejected
Type: Technical
Reported By: Magnus Fromreide
Date Reported: 2009-08-29
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02
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.
--VERIFIER NOTES--
Such a change in a MIB module cannot be done by an erratum, but rather by issuing a new version of the MIB module. As this document is Historic and the MIB module is written in SMIv1, I see no need for such a change in the future.
Note: This RFC has been obsoleted by RFC1282
Source of RFC: Legacy
Errata ID: 2772
Status: Verified
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Verifier Name: ron bonica
Date Verified: 2011-10-12
Throughout the document, when it says:
Notes:
RFC 1258 is obsoleted by RFC 1282, that is clearly stated in the last document. However no such entry was added to RFC Editor database. It should be added once this errata report is verified.
Note: This RFC has been obsoleted by RFC6149
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.
Note: This RFC has been obsoleted by RFC6150
Source of RFC: pem (sec)
Errata ID: 2163
Status: Verified
Type: Technical
Reported By: Nikolai Malykh
Date Reported: 2010-04-16
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section A.4 says:
#ifndef MD #define MD MD5 #endif
It should say:
#ifndef MD #define MD 5 #endif
Errata ID: 2164
Status: Verified
Type: Technical
Reported By: Nikolai Malykh
Date Reported: 2010-04-16
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section A.4 says:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_LEN, TEST_BLOCK_COUNT);
It should say:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_COUNT, TEST_BLOCK_LEN);
Errata ID: 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: Verified
Type: Technical
Reported By: Gennaro Prota
Date Reported: 2006-11-15
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Appendix A says:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_LEN, TEST_BLOCK_COUNT);
It should say:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_COUNT, TEST_BLOCK_LEN);
Errata ID: 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.].
Errata ID: 2278
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-05-19
Held for Document Update by: Wes Eddy
Section 1.1 says:
Section 4 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly
every segment, including retransmissions, to be timed at
negligible computational cost. We use the mnemonic RTTM
(Round Trip Time Measurement) for this mechanism, to
distinguish it from other uses of the Timestamps option.
It should say:
Section 3.2 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly
every segment, including retransmissions, to be timed at
negligible computational cost. We use the mnemonic RTTM
(Round Trip Time Measurement) for this mechanism, to
distinguish it from other uses of the Timestamps option.
Notes:
Incorrect reference to Section 4.
Note: This RFC has been obsoleted by RFC1700
Source of RFC: Legacy
Errata ID: 549
Status: Verified
Type: Editorial
Reported By: Jean Delvare
Date Reported: 2002-07-08
Verifier Name: Russ Housley
Date Verified: 2010-08-19
On page 87, it says:
SUN OS 3.5 SUN OS 4.0
It should say:
SUN-OS-3.5 SUN-OS-4.0
Notes:
The white space isn't supposed to be accepted as part of a system name.
Errata ID: 2683
Status: Verified
Type: Technical
Reported By: -
Date Reported: 2011-01-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-03
Section 3 says:
N-> 1e4a LATIN CAPITAL LETTER N WITH CIRCUMFLEX BELOW N-> 1e4b LATIN SMALL LETTER N WITH CIRCUMFLEX BELOW ... S.-. 1e68 LATIN CAPITAL LETTER S WITH DOT BELOW AND DOT ABOVE S.-. 1e69 LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE
It should say:
N-> 1e4a LATIN CAPITAL LETTER N WITH CIRCUMFLEX BELOW n-> 1e4b LATIN SMALL LETTER N WITH CIRCUMFLEX BELOW ... S.-. 1e68 LATIN CAPITAL LETTER S WITH DOT BELOW AND DOT ABOVE s.-. 1e69 LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE
Notes:
Mnemonics should be unique...
Errata ID: 2813
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-22
Held for Document Update by: Pete Resnick
Section 4 says:
The character mnemonics hav been used to table a number of coded character sets.
It should say:
The character mnemonics have been used to table a number of coded character sets.
Notes:
s/hav/have: a typo
Errata ID: 1712
Status: Held for Document Update
Type: Editorial
Reported By: Andy
Date Reported: 2009-03-11
Held for Document Update by: Alexey Melnikov
Section 3 says:
Acknowlegements
It should say:
Acknowledgements
Errata ID: 3041
Status: Reported
Type: Technical
Reported By: Dean Swift
Date Reported: 2011-12-07
Section 2 says:
Class F-8G has the seven higher order bits set to 1111110, a 49 bit network number and a 8 bit host address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|0| net number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | net number | local part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
Class F-8G has the seven higher order bits set to 1111110, a 49 bit network number and a 8 bit host address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|0| net number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | net number | local part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Remaining bit patterns are unspecified but assumed to be reserved for future definition.
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
Note: This RFC has been obsoleted by RFC4120
Source of RFC: cat (sec)
Errata ID: 3084
Status: Rejected
Type: Editorial
Reported By: Jennifer Black
Date Reported: 2012-01-05
Rejected by: Stephen Farrell
Date Rejected: 2012-01-05
Section 1.2 says:
+ "Denial of service" attacks are not solved with Kerberos. There
are places in these protocols where an intruder intruder can
prevent an application from participating in the proper
authentication steps. Detection and solution of such attacks
(some of which can appear to be not-uncommon "normal" failure
modes for the system) is usually best left to the human
administrators and users.
It should say:
+ "Denial of service" attacks are not solved with Kerberos. There
are places in these protocols where an intruder can
prevent an application from participating in the proper
authentication steps. Detection and solution of such attacks
(some of which can appear to be not-uncommon "normal" failure
modes for the system) is usually best left to the human
administrators and users.
Notes:
Intruder appeared twice.
While that certainly can happen in practice, I don't think the author meant to allude to that possibility. :)
--VERIFIER NOTES--
Already fixed in 4120 which obsoletes this.
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.
Note: This RFC has been obsoleted by RFC4632
Source of RFC: Legacy
Errata ID: 1823
Status: Verified
Type: Editorial
Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
Verifier Name: Stewart Bryant
Date Verified: 2010-10-22
Section 1 says:
This plan is primarily directed at the first two problems listed above. We believe that the judicious use of variable-length subnetting techniques should help defer the onset of the last problem problem, the exhaustion of the 32-bit address space. Note also that improved tools for performing address allocation in a "supernetted" and variably-subnetted world would greatly help the user community in accepting these sometimes confusing techniques. Efforts to create some simple tools for this purpose should be encouraged by the Internet community.
It should say:
This plan is primarily directed at the first two problems listed above. We believe that the judicious use of variable-length subnetting techniques should help defer the onset of the last problem, the exhaustion of the 32-bit address space. Note also that improved tools for performing address allocation in a "supernetted" and variably-subnetted world would greatly help the user community in accepting these sometimes confusing techniques. Efforts to create some simple tools for this purpose should be encouraged by the Internet community.
Notes:
In the phrase "the onset of the last problem problem," word problem appears twice.
Errata ID: 1755
Status: Verified
Type: Editorial
Reported By: Samuel Bronson
Date Reported: 2009-04-03
Verifier Name: ron bonica
Date Verified: 2011-10-12
Section B says:
# Mailcap file for Bellcore lab 214.
#
# The next line sends "richtext" to the richtext
program
text/richtext; richtext %s; copiousoutput
#
# Next, basic u-law audio
audio/*; showaudio; test=/usr/local/bin/hasaudio
#
# Next, use the xview program to handle several image
formats
image/*; xview %s; test=/usr/local/bin/RunningX
#
# The ATOMICMAIL interpreter uses curses, so needs a
terminal
application/atomicmail; /usr/local/bin/atomicmail %s; \
needsterminal
#
# The next line handles Andrew format,
# if ez and ezview are installed
x-be2; /usr/andrew/bin/ezview %s; \
print=/usr/andrew/bin/ezprint %s ; \
compose=/usr/andrew/bin/ez -d %s \;
edit=/usr/andrew/bin/ez -d %s; \;
copiousoutput
#
# The next silly example demonstrates the use of
quoting
application/*; echo "This is \"%t\" but \
is 50 \% Greek to me" \; cat %s; copiousoutput
It should say:
# Mailcap file for Bellcore lab 214.
#
# The next line sends "richtext" to the richtext
# program
text/richtext; richtext %s; copiousoutput
#
# Next, basic u-law audio
audio/*; showaudio; test=/usr/local/bin/hasaudio
#
# Next, use the xview program to handle several image
# formats
image/*; xview %s; test=/usr/local/bin/RunningX
#
# The ATOMICMAIL interpreter uses curses, so needs a
# terminal
application/atomicmail; /usr/local/bin/atomicmail %s; \
needsterminal
#
# The next line handles Andrew format,
# if ez and ezview are installed
x-be2; /usr/andrew/bin/ezview %s; \
print=/usr/andrew/bin/ezprint %s ; \
compose=/usr/andrew/bin/ez -d %s \;
edit=/usr/andrew/bin/ez -d %s; \;
copiousoutput
#
# The next silly example demonstrates the use of
# quoting
application/*; echo "This is \"%t\" but \
is 50 \% Greek to me" \; cat %s; copiousoutput
Notes:
Some comment lines in the example termcap file appear to have improperly reformatted to fit the 78-character limit; the needed "# " was ommitted.
Note: This RFC has been obsoleted by RFC1541
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.
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.
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)
Errata ID: 1084
Status: Held for Document Update
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Held for Document Update by: Sean Turner
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: 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".)
Errata ID: 2696
Status: Rejected
Type: Technical
Reported By: Michael Deckers
Date Reported: 2011-01-30
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27
Section 2 says:
The integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970.
It should say:
The integer value is 63 072 000 when UTC was 1972-01-01; it increases by 1 for every second of UTC, excluding positive leap seconds.
Notes:
At the time when UTC was 1970-01-01, TAI was 1970-01-01 + 8.000 082 s,
according to [ftp://maia.usno.navy.mil/ser7/tai-utc.dat]. (The rate of
UTC was slower than the rate of TAI at the time but there have not been any
leap seconds in UTC between 1970 and 1972-01-01.) The original wording could be
taken to imply that the "integer value" was 63 072 001 when UTC was 1972-01-01
and TAI was 1972-01-01 + 10 s, and reached the value 63 072 002 just 82 µs
later. However, UNIX practice is to assign the value 63 072 000 to
the instant when UTC was 1972-01-01. The proposed wording makes it clear
that seconds of UTC are counted, not any seconds.
-- Regarding negative leap seconds (which have not occurred and probably
never will): "excluding" them would be wrong because, when they occur,
the phase of UTC increases by 2 s (and so must the time_t value) while the
phase of TAI only increases by 1 s. The proposed wording simply does not deal with the case, while the original would do it incorrectly.
--VERIFIER NOTES--
The quoted text does not appear in RFC 1609. However, it does appear in
RFC 4049 (!). If the reporter wishes to file an erratum against RFC 4049,
he will need to file a new report with the correct RFC number.
Errata ID: 2272
Status: Held for Document Update
Type: Editorial
Reported By: jonsimchol
Date Reported: 2010-05-18
Held for Document Update by: Wes Eddy
Section 5.1.3 says:
Although receiver-initiated reservation is the natural choice
for multicast sessions, the justification for receiver
initiateion may appear weaker for unicast sessions, where the
sender may be the logical session initiator.
It should say:
Although receiver-initiated reservation is the natural choice
for multicast sessions, the justification for receiver
initiation may appear weaker for unicast sessions, where the
sender may be the logical session initiator.
Notes:
initiateion -> initiation
Errata ID: 2273
Status: Held for Document Update
Type: Editorial
Reported By: jonsimchol
Date Reported: 2010-05-18
Held for Document Update by: Wes Eddy
Section 5.1.3 says:
RSVP uses receiver-initiation of rservations [RSVP93b]. A
receiver is assumed to learn the senders' offered flowspecs by
a higher-level mechanism ("out of band"), it then generates its
own desired flowspec and propagates it towards the senders,
making reservations in each router along the way.
It should say:
RSVP uses receiver-initiation of reservations [RSVP93b]. A
receiver is assumed to learn the senders' offered flowspecs by
a higher-level mechanism ("out of band"), it then generates its
own desired flowspec and propagates it towards the senders,
making reservations in each router along the way.
Notes:
rservations -> reservations
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.
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.
Errata ID: 1404
Status: Verified
Type: Editorial
Reported By: Harald Tveit Alvestrand
Date Reported: 2008-04-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02
Section 6 says:
RFC822: Harald.Alvestrand@uninett.no X.400: C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand; G=harald
It should say:
RFC822: Harald.Alvestrand@uninett.no X.400: G=Harald; S=alvestrand; O=uninett; P=uninett; C=no
Notes:
The RFC is about the format of O/R names. The address as given in the author's address section should be consistent with the format recommended by the RFC.
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
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,
Note: This RFC has been obsoleted by RFC1939
Source of RFC: Legacy
Errata ID: 1086
Status: Verified
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02
Section 7 says:
Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
^^^^
body, then the POP3 server sends the entire message.
It should say:
Note that if the number of lines requested by the POP3 client is greater than the number of lines in the body, then the POP3 server sends the entire message.
Notes:
Extraneous "than" in discussion of TOP command.
Note: This RFC has been obsoleted by RFC4248 RFC4266
Source of RFC: Legacy
Errata ID: 2845
Status: Rejected
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-26
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27
Section 5 says:
scheme = 1*[ lowalpha | digit | "+" | "-" | "." ] [ . . . ] hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit [ . . . ] user = *[ uchar | ";" | "?" | "&" | "=" ] password = *[ uchar | ";" | "?" | "&" | "=" ] [ . . . ] fpath = fsegment *[ "/" fsegment ] fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] [ . . . ] hpath = hsegment *[ "/" hsegment ] hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ] search = *[ uchar | ";" | ":" | "@" | "&" | "=" ] [ . . . ] group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ] article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host [ . . . ] ppath = psegment *[ "/" psegment ] psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] fieldspec = ";" fieldname "=" fieldvalue fieldname = *[ uchar | "?" | ":" | "@" | "&" ] fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]
It should say:
scheme = 1*( lowalpha | digit | "+" | "-" | "." ) [ . . . ] hostname = *( domainlabel "." ) toplabel domainlabel = alphadigit | alphadigit *( alphadigit | "-" ) alphadigit toplabel = alpha | alpha *( alphadigit | "-" ) alphadigit [ . . . ] user = *( uchar | ";" | "?" | "&" | "=" ) password = *( uchar | ";" | "?" | "&" | "=" ) [ . . . ] fpath = fsegment *( "/" fsegment ) fsegment = *( uchar | "?" | ":" | "@" | "&" | "=" ) [ . . . ] hpath = hsegment *( "/" hsegment ) hsegment = *( uchar | ";" | ":" | "@" | "&" | "=" ) search = *( uchar | ";" | ":" | "@" | "&" | "=" ) [ . . . ] group = alpha *( alpha | digit | "-" | "." | "+" | "_" ) article = 1*( uchar | ";" | "/" | "?" | ":" | "&" | "=" ) "@" host [ . . . ] ppath = psegment *( "/" psegment ) psegment = *( uchar | "?" | ":" | "@" | "&" | "=" ) fieldspec = ";" fieldname "=" fieldvalue fieldname = *( uchar | "?" | ":" | "@" | "&" ) fieldvalue = *( uchar | "?" | ":" | "@" | "&" )
Notes:
Given this is BNF of RFC 822 construction <n>*<m>[element] is incorrect, as RFC 822 defines:
> 2.5. [RULE]: OPTIONAL
>
> Square brackets enclose optional elements; "[foo bar]" is
> equivalent to "*1(foo bar)".
and therefore [] construction is illegal in the aforementioned one. My proposal is to replace all occurrences of [] construction where they are used in the meaning of () with the legal-as-per-822 one.
--VERIFIER NOTES--
This specification does not use the BNF syntax from RFC 822. Please refer
to the first paragraph of Section 5:
###
This is a BNF-like description of the Uniform Resource Locator
syntax, using the conventions of RFC822, except that "|" is used to
designate alternatives, and brackets [] are used around optional or
repeated elements. Briefly, literals are quoted with "", optional
elements are enclosed in [brackets], and elements may be preceded
with <n>* to designate n or more repetitions of the following
element; n defaults to 0.
###
The definitions follow the syntax used in this document. Thus
the report is incorrect.
Note: This RFC has been obsoleted by RFC4271
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.
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)
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.
Errata ID: 2704
Status: Held for Document Update
Type: Editorial
Reported By: Jeffrey Smith
Date Reported: 2011-02-03
Held for Document Update by: Stewart Bryant
Section 4.3.3.6 says:
A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request datagram at least as the maximum of 576 and the MTUs of all the connected networks.
It should say:
A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request datagram at least as large as the maximum of 576 and the MTUs of all the connected networks.
Note: This RFC has been obsoleted by RFC2854
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=
Errata ID: 2171
Status: Verified
Type: Editorial
Reported By: Clark Rossdale
Date Reported: 2010-04-23
Section global says:
illistrate
It should say:
illustrate
Note: This RFC has been obsoleted by RFC3461
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.
Note: This RFC has been obsoleted by RFC3464
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
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
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.
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"
Errata ID: 3104
Status: Reported
Type: Technical
Reported By: Mark Nottingham
Date Reported: 2012-02-05
Section 2. (2) says:
(2) No matter how hard you push and no matter what the priority, you can't increase the speed of light.
It should say:
(2) If you try really hard, and have the right equipment (or suitable funding), you might be able to increase the speed of light. Or not, we're not sure yet.
Notes:
Experimental results suggest it may be possible to go faster; see:
http://arxiv.org/abs/1109.4897
It's true that these results have not been independently verified, and it's true that the speed of light was not observed to be increased (only exceeded), but there is now enough doubt involved to justify an errata (with a view to an update in a potential future BIS WG).
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
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.
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: Held for Document Update
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Held for Document Update by: Peter Saint-Andre
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.
Note: This RFC has been obsoleted by RFC6528
Source of RFC: Legacy
Errata ID: 2068
Status: Held for Document Update
Type: Editorial
Reported By: Fernando Gont
Date Reported: 2010-03-05
Held for Document Update by: Sean Turner
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.
Note: This RFC has been obsoleted by RFC2255
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
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
Errata ID: 2174
Status: Reported
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Section 5.4. says:
If Path MTU Discovery is used, however, the segment size may not be a submultiple of the send space,
It should say:
If Path MTU Discovery is used, however, the segment size may not be a factor of the send space,
Notes:
What is a submultiple?
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.
Errata ID: 2840
Status: Reported
Type: Technical
Reported By: Francesco Balzarini
Date Reported: 2011-06-17
Throughout the document, when it 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
given that:
- The ip4 header has variable size ( >20 octets )
- The suggested extra header has variable size ( 8 or 12 octets )
- The S bit to distinguish the suggested header size is located
inside the second octet of the suggested header
- The only size information is about the sum of both headers
The implication is that the S bit cannot be located.
My opinion to correct this problem is just to change
the order of elements inside the suggested header.
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
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.
Note: This RFC has been obsoleted by RFC4502
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 }
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: 3014
Status: Verified
Type: Editorial
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06
Section 6.5.4 says:
[NOTE: These procedures intentionally and explicitly do not establish a fixed maximum time period that shall be considered "reasonable" in all cases. The Internet Standards Process places a premium on consensus and efforts to achieve it, and deliberately foregoes deterministically swift execution of procedures in favor of a latitude within which more genuine technical agreements may be reached.]
It should say:
[NOTE: These procedures intentionally and explicitly do not establish a fixed maximum time period that shall be considered "reasonable" in all cases. The Internet Standards Process places a premium on consensus and efforts to achieve it, and deliberately forgoes deterministically swift execution of procedures in favor of a latitude within which more genuine technical agreements may be reached.]
Notes:
s/foregoes/forgoes/
"foregoes" means "to go before; precede."
"forgoes" means "to abstain or refrain from; do without."
Errata ID: 3015
Status: Verified
Type: Editorial
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06
Section 10.3.1 says:
5. The contribuitor, the organization (if any) he represents and the
owners of any proprietary rights in the contribution, agree that
no information in the contribution is confidential and that the
ISOC and its affiliated organizations may freely disclose any
information in the contribution.
It should say:
5. The contributor, the organization (if any) he represents and the
owners of any proprietary rights in the contribution, agree that
no information in the contribution is confidential and that the
ISOC and its affiliated organizations may freely disclose any
information in the contribution.
Notes:
s/contribuitor/contributor/
Errata ID: 3016
Status: Verified
Type: Editorial
Reported By: Paul Aitken
Date Reported: 2011-11-04
Verifier Name: Russ Housley
Date Verified: 2011-12-06
Section 10.3.1. says:
By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any propriety rights in the contribution.. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named contributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution.
It should say:
By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any propriety rights in the contribution. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named contributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution.
Notes:
s/contribution../contribution./
Errata ID: 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.
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
Errata ID: 2727
Status: Verified
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-22
Verifier Name: Russ Housley
Date Verified: 2011-06-07
Section 5 says:
[H] IRTF Charter, RFC 2014, October 1996.
It should say:
[H] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and
Procedures", BCP 8, RFC 2014, October 1996.
Errata ID: 2742
Status: Rejected
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-05
Rejected by: Russ Housley
Date Rejected: 2011-06-07
Section 5 says:
[F] IANA Charter, Work in Progress. [G] RFC Editor Charter, Work in Progress.
It should say:
[F] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding
Concerning the Technical Work of the Internet Assigned Numbers Authority",
RFC 2860, June 2000.
[G] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and
RFC Editor", RFC 4844, July 2007.
Notes:
--VERIFIER NOTES--
These documents were not yet complete at the time RFC 2028 was written.
Note: This RFC has been obsoleted by RFC4330
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: 2479
Status: Reported
Type: Technical
Reported By: Dave Higton
Date Reported: 2010-08-20
Section 4 says:
MSF Rugby (UK) Radio 60 kHz
It should say:
MSF Anthorn (UK) Radio 60 kHz
Notes:
The MSF transmitter was relocated from Rugby to Anthorn, in Cumbria, on 2007 March 31. See http://www.npl.co.uk/science-+-technology/time-and-frequency/npl-ensures-accurate-uk-time-for-the-next-15-years
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
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.
Errata ID: 2586
Status: Verified
Type: Technical
Reported By: Christopher Yeleighton
Date Reported: 2010-10-28
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section 1. says:
All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all of these header fields except for Content-Disposition can include RFC 822 comments, which have no semantic content and should be ignored during MIME processing.
It should say:
All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all of these header fields can include RFC 822 comments, which have no semantic content and should be ignored during MIME processing.
Notes:
A header field Content-Disposition is not defined in this document. Therefore, the header fields defined in this document do not contain a field Content-Disposition and the exception is not necessary. It is also misleading because it looks as if the exception affected the Content-Disposition field defined in RFC2813 while it does not.
Errata ID: 512
Status: Verified
Type: Editorial
Reported By: Ned Freed
Date Reported: 2005-02-24
Verifier Name: Alexey Melnikov
Date Verified: 2009-08-29
Section 5.1 says:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
It should say:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <"> /
"/" / "[" / "]" / "?" / "="
Notes:
Missing alternative separator on the second line.
Errata ID: 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.
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.
Errata ID: 2823
Status: Held for Document Update
Type: Editorial
Reported By: Spiros Bousbouras
Date Reported: 2011-06-05
Held for Document Update by: Pete Resnick
Date Held: 2011-06-05
Section 8 says:
The following examples illustrate how text containing 'encoded-word's which appear in a structured field body.
It should say:
The following examples illustrate how text containing 'encoded-word's appears in a structured field body.
Note: This RFC has been obsoleted by RFC3501
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
Note: This RFC has been obsoleted by RFC2617
Source of RFC: http (app)
Errata ID: 749
Status: Verified
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2005-02-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-11
Section 2.4 says:
RfC 2069 (digest access authentication) chapter 2.4 is an example,
the userame is "Mufasa", the password is "CircleOfLife":
| username="Mufasa",
| realm="testrealm@host.com",
| nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
| uri="/dir/index.html",
| response="e966c932a9242554e42c8ee200cec7f6",
| opaque="5ccc069c403ebaf9f0171e9517f40e41"
The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 ))
MD5( A1 ) = MD5( username || ':' || realm || ':' || password )
= MD5( "Mufasa:testrealm@host.com:CircleOfLife" )
= "4945ecf42b1bb868634058a845bedde8"
MD5( A2 ) = MD5( Method || ':' || digest-uri-value )
= MD5( "GET:/dir/index.html" )
= "39aff3a2bab6126f332b942af96d3366"
This results in a response = "1949323746fe6a43ef61f9606e7febea"
instead of the shown value = "e966c932a9242554e42c8ee200cec7f6".
Quick reality check, the RFC 2617 example uses the same values
username = "Mufasa"
nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"
realm = "testrealm@host.com"
A2 = "GET:/dir/index.html"
with a slightly different
password = "Circle Of Life"
resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9"
The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 ))
for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth"
and here the response = "6629fae49393a05397450978507c4ef1" works as
expected.
It should say:
[not submitted]
Notes:
I've tried to contact two of the RFC 2069 authors about this issue,
but got no reply.
Alexey: note that this problem was addressed in RFC 2617.
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).
Errata ID: 2794
Status: Held for Document Update
Type: Technical
Reported By: Kasper Dupont
Date Reported: 2011-05-02
Held for Document Update by: Sean Turner
Section Appendix says:
key = "Jefe" data = "what do ya want for nothing?" data_len = 28 bytes digest = 0x750c783e6ab0b503eaa86e310a5db738
It should say:
key = "Jefe" key_len = 4 data = "what do ya want for nothing?" data_len = 28 bytes digest = 0x750c783e6ab0b503eaa86e310a5db738
Notes:
key_len was omitted from this test vector. The other test vectors specify both key_len and data_len.
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:
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: 2969
Status: Held for Document Update
Type: Technical
Reported By: John Klensin
Date Reported: 2011-09-12
Held for Document Update by: Russ Housley
Section 1,3,4 says:
(1) "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" mean (2) 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean (3) 3. SHOULD This word, or the adjective "RECOMMENDED", mean (4) 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
It should say:
(1) "The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "MAY" means (2) 1. MUST This word, or the term "SHALL", means (3) 3. SHOULD This word means (4) 4. SHOULD NOT This phrase means Editorial note: The use of "mean" after a singular subject is simply wrong. Subordinate phrases like ", or the term BLATHER," do nothing to change that.
Notes:
RFC 2026, to which RFC 2119 should be subordinate, carefully distinguishes between Technical Specifications (TS) and Applicability Statements (AS). Its Section 3.3 prescribes specific language to be used in ASs, with categories "Required", "Recommended", "Elective", "Limited Use", and "Not Recommended", while 2119's language, especially in its Section 6, fairly clearly apply to interoperability requirements within TS documents. Use of terms that 2026 requires for AS documents in a TS context (as synonyms for other, unambiguous, terms) is just an invitation to confusion, especially if the IETF continues to have hair-splitting arguments about the nature of requirements in particular contexts. Consequently, while the change proposed in erratum 419 (altering the definition phrase to reflect the language of Section 4) appears reasonable from an editorial standpoint, the correct fix is to remove the 2026 AS terms as acceptable synonyms from 2119 entirely. If people want to say "SHOULD NOT" and give it specific meaning, they should say "SHOULD NOT" rather than trying to use nearly-synonymous terms and hoping that the reader will figure out what was really met.
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: Verified
Type: Editorial
Reported By: Anders Langmyr
Date Reported: 2006-01-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15
Section Abstract says:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
It should say:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC 2119.
Notes:
The phrase "NOT RECOMMENDED" is missing from this sentence.
Errata ID: 497
Status: Rejected
Type: Editorial
Reported By: Kiyoshi Ogawa
Date Reported: 2006-07-10
Rejected by: Russ Housley
Date Rejected: 2010-08-19
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".
--VERIFIER NOTES--
The full implications MUST be understood in order to ignore a "SHOULD" or "SHOULD NOT" statement in a specification.
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.
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.
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].
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 |
+-----+-----+-----+-----+-----+-----+
Errata ID: 2305
Status: Reported
Type: Technical
Reported By: Richard Chen
Date Reported: 2010-06-17
Section 3.10. says:
The code for the log server option is 8.
It should say:
The code for the cookie server option is 8.
Notes:
Copy error.
Errata ID: 2388
Status: Reported
Type: Editorial
Reported By: Muhammad Yousaf
Date Reported: 2010-07-21
Section 1.2 says:
A DHCP server of "server"is an Internet host that returns configuration parameters to DHCP clients.
It should say:
A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
Errata ID: 2805
Status: Reported
Type: Technical
Reported By: Tony Finch
Date Reported: 2011-05-09
Section 1.1.1 says:
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH and RDATA fields are equal. Note that the time-to-live (TTL) field is explicitly excluded from the comparison.
It should say:
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH and RDATA fields are equal. Compressed names in the RDATA must be decompressed before comparison. Note that the time-to-live (TTL) field is explicitly excluded from the comparison.
Notes:
Name compression depends on the context of the RR so RDATA cannot correctly be compared bytewise without taking this into account.
Errata ID: 1082
Status: Held for Document Update
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-09-15
Section 5 says:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [RFC977] NEWS NNTP Synonym for USENET
It should say:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [RFC1849] 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.
IESG NOTE (2010-09-15): The foregoing text is corrupted, however the intent is clearly that [son-of-1036] is the proper reference for the USENET mailbox convention; note that in March 2010 [son-of-1036] was published as RFC 1849. --Peter Saint-Andre
Errata ID: 1763
Status: Held for Document Update
Type: Editorial
Reported By: Nick Levinson
Date Reported: 2009-04-15
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02
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.
Errata ID: 1764
Status: Held for Document Update
Type: Editorial
Reported By: Nick Levinson
Date Reported: 2009-04-15
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-09-15
Section 1 & 2 says:
top level domain
It should say:
organization's principal domain name
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.
EDITOR'S NOTE (2010-09-15): This matter was discussed on the app-discuss and dnsext mailing lists, and consensus emerged on the phrase "organization's principal domain name". --Peter Saint-Andre
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
Errata ID: 2081
Status: Verified
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-03-19
Verifier Name: Ross Callon
Date Verified: 2010-03-19
Section 5 says:
Because of these properties of OSFP routing, an AS can contain signed and unsigned areas, and achieve a predictable level of authentication.
It should say:
Because of these properties of OSPF routing, an AS can contain signed and unsigned areas, and achieve a predictable level of authentication.
Notes:
s/OSFP/OSPF
Errata ID: 1387
Status: Held for Document Update
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-03-25
Held for Document Update by: Alexey Melnikov
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).
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".
Note: This RFC has been obsoleted by RFC2231
Source of RFC: Legacy
Errata ID: 841
Status: Verified
Type: Technical
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Pete Resnick
Date Verified: 2011-05-13
Section 7 says:
initial-section := "*1"
other-sections := "*" (("2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9") *DIGIT) /
("1" 1*DIGIT))
It should say:
initial-section := "*0"
other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9") *DIGIT)
Notes:
Corrected in RFC 2231
Errata ID: 2808
Status: Verified
Type: Editorial
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Pete Resnick
Date Verified: 2011-05-13
Section 4.1 says:
Content-Type: application/x-stuff
title*1*=us-ascii'en'This%20is%20even%20more%20
title*2*=%2A%2A%2Afun%2A%2A%2A%20
title*3="isn't it!"
It should say:
Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
Notes:
Verifier Note: Corrected in RFC 2231
Errata ID: 484
Status: Verified
Type: Editorial
Reported By: Terje Braten
Date Reported: 2001-04-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section 7 says:
This specification changes this ABNF to: encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
It should say:
This specification changes this ABNF to:
encoded-word := "=?" charset ["*" language] "?" encoding "?"
encoded-text "?="
Note: This RFC has been obsoleted by RFC5092
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
Errata ID: 482
Status: Verified
Type: Editorial
Reported By: IETF Secretariat
Date Reported: 2004-10-13
On page 21, it says:
A firewall is any one of several mechanisms used to control and watch access to and from a network for the purpose of protecting it. A firewall acts as a gateway through which all traffic to and from the protected network and/or systems passes. Firewalls help to place limitations on the amount and type of communication that takes place between the protected network and the another network (e.g., the Internet, or another piece of the site's network).
It should say:
A firewall is any one of several mechanisms used to control and watch access to and from a network for the purpose of protecting it. A firewall acts as a gateway through which all traffic to and from the protected network and/or systems passes. Firewalls help to place limitations on the amount and type of communication that takes place between the protected network and another network (e.g., the Internet, or another piece of the site's network).
Notes:
removed extraneous "the".
Errata ID: 2167
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-04-21
Verifier Name: RFC Editor
Date Verified: 2011-12-01
Section 3.2.3.6 says:
Some sites choose to co-locate FTP with a Web server, since the two protocols share common security considerations However, the the practice isn't recommended, especially when the FTP service allows the deposit of files (see section on WWW above).
It should say:
Some sites choose to co-locate FTP with a Web server, since the two protocols share common security considerations. However, this practice isn't recommended, especially when the FTP service allows the deposit of files (see section on WWW above).
Notes:
added a period after "considerations".
Errata ID: 2674
Status: Verified
Type: Editorial
Reported By: Alexandre Dulaunoy
Date Reported: 2010-12-19
Verifier Name: RFC Editor
Date Verified: 2011-12-01
Section 3.1.1 says:
The plan should also address how incident will be handled. Chapter 5 provides an in-depth discussion of this topic, but it is important for each site to define classes of incidents and corresponding responses. For example, sites with firewalls should set a threshold on the number of attempts made to foil the firewall before triggering a response? Escallation levels should be defined for both attacks and responses. Sites without firewalls will have to determine if a single attempt to connect to a host constitutes an incident? What about a systematic scan of systems?
It should say:
The plan should also address how incident will be handled. Chapter 5 provides an in-depth discussion of this topic, but it is important for each site to define classes of incidents and corresponding responses. For example, sites with firewalls should set a threshold on the number of attempts made to foil the firewall before triggering a response? Escalation levels should be defined for both attacks and responses. Sites without firewalls will have to determine if a single attempt to connect to a host constitutes an incident? What about a systematic scan of systems?
Notes:
Escallation -> Escalation
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:
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
Note: This RFC has been obsoleted by RFC4422 RFC4752
Source of RFC: Legacy
Errata ID: 2847
Status: Rejected
Type: Editorial
Reported By: Alex Allain
Date Reported: 2011-06-28
Rejected by: Peter Saint-Andre
Date Rejected: 2011-08-02
Section 6 says:
will perform no review of clams made
It should say:
will perform no review of claims made
Notes:
Minor typo
--VERIFIER NOTES--
This minor typo was fixed in RFC 4422, which obsoleted RFC 2222.
Errata ID: 1753
Status: Verified
Type: Technical
Reported By: Matthew Luckie
Date Reported: 2009-04-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14
Section 2.2 says:
dqstring = <"> *(dqtext/quoted-pair) <"> dqtext = <any CHAR except <">, "\", and CTLs> sqstring = <'> *(dqtext/quoted-pair) <'> sqtext = <any CHAR except <'>, "\", and CTLs> quoted-pair = "\" CHAR
It should say:
dqstring = <"> *(dqtext/quoted-pair) <"> dqtext = <any CHAR except <">, "\", and CTLs> sqstring = <'> *(sqtext/quoted-pair) <'> sqtext = <any CHAR except <'>, "\", and CTLs> quoted-pair = "\" CHAR
Notes:
As it stands, the original specification would allow an sqstring of 'Bob's Garage' to be valid when that is not intended. [Approver Note: this appears to be a copy-and-paste error.]
Errata ID: 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.
Note: This RFC has been obsoleted by RFC4234
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: Held for Document Update
Type: Editorial
Reported By: Keith McCloghrie
Date Reported: 2005-05-19
Held for Document Update by: Peter Saint-Andre
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
Note: This RFC has been obsoleted by RFC3376
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: Verified
Type: Editorial
Reported By: Stephen Nadas (RL/TNT)
Date Reported: 2006-11-28
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20
Section 2.2 says:
Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members), as discussed in section 7.8. It also allows tuning of the burstiness of IGMP traffic on a subnet, as discussed in section 7.3
It should say:
Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members), as discussed in section 8.8. It also allows tuning of the burstiness of IGMP traffic on a subnet, as discussed in section 8.3
Notes:
Section 2.2 2nd para refers to section 7.8 and 7.3 neither of which
exist. It should refer to 8.8 and 8.3.
Errata ID: 3063
Status: Reported
Type: Editorial
Reported By: Jon Hak Song
Date Reported: 2011-12-26
Section 6 says:
- "set timer", setting the timer to its maximum value [Version 1
Router Present Timeout] and (re)starting it.
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1 query
| ________________ | received
| | | | (set timer)
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (set timer) |
---------------------------
It should say:
- "set timer", setting the timer to its maximum value [Version 1
Router Present Timeout] and starting it.
- "reset timer", resetting the timer to its maximum value [Version 1
Router Present Timeout] and restarting it.
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1 query
| ________________ | received
| | | | (set timer)
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (reset timer) |
---------------------------
Notes:
Resetting timer is obviously different than setting timer.
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
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.
Errata ID: 782
Status: Held for Document Update
Type: Editorial
Reported By: Vishal B S
Date Reported: 2005-09-26
Held for Document Update by: Robert Sparks
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
Note: This RFC has been obsoleted by RFC4510 RFC4517 RFC4523 RFC4512
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
Note: This RFC has been obsoleted by RFC4510 RFC4514
Source of RFC: asid (app)
Errata ID: 2664
Status: Held for Document Update
Type: Editorial
Reported By: Ross Shumway
Date Reported: 2010-12-08
Held for Document Update by: Alexey Melnikov
Throughout the document, when it says:
RFC 2253 LADPv3 Distinguished Names December 1997
It should say:
RFC 2253 LDAPv3 Distinguished Names December 1997
Notes:
This is a minor but annoying character transposition in the page headers.
Note: This RFC has been obsoleted by RFC4510 RFC4515
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 = ">="
Errata ID: 1536
Status: Held for Document Update
Type: Editorial
Reported By: Shiang-Ming Huang
Date Reported: 2008-10-03
Held for Document Update by: ron bonica
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.
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.
Errata ID: 1374
Status: Held for Document Update
Type: Editorial
Reported By: Masatoshi Yamamoto
Date Reported: 2008-03-20
Held for Document Update by: Peter Saint-Andre
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"
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.
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:
Errata ID: 775
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Peter Saint-Andre
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
Errata ID: 462
Status: Held for Document Update
Type: Editorial
Reported By: Pierre Beyssac
Date Reported: 2004-11-25
Held for Document Update by: Peter Saint-Andre
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 )
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".
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
Errata ID: 2812
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-05-22
Held for Document Update by: ron bonica
Section Abstract says:
Abstract This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in all Russian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-U Working Group is http://www.net.ua.
It should say:
Abstract This document provides information about character encoding KOI8-U (KOI8 Ukrainian) which is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in all Russian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-U Working Group is http://www.net.ua.
Notes:
A typo in "which": s/wich/which
Errata ID: 682
Status: Verified
Type: Technical
Reported By: Andrew Cook
Date Reported: 2002-11-20
Verifier Name: RFC Editor
Date Verified: 2011-10-28
Section 2.1.1 says:
Content-Type set to "application/coffee-pot-command".
It should say:
Content-Type set to "message/coffeepot".
Notes:
There is a discrepancy in RFC2324 regarding the content type for HTCPCP
requests. In section 2.1.1, the MIME type is
"application/coffee-pot-command", while in section 4 the MIME type is
"message/coffepot".
--VERIFIER NOTE--
This change will make section 2.1.1 consistent with section 4.
Errata ID: 460
Status: Verified
Type: Technical
Reported By: Larry Masinter
Date Reported: 2005-02-19
Verifier Name: RFC Editor
Date Verified: 2011-10-28
Section 3 says:
| "caf%C3%E8" ; Catalan, French, Galician
It should say:
| "caf%C3%A9" ; Catalan, French, Galician
Note: This RFC has been obsoleted by RFC4566
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: Held for Document Update
Type: Editorial
Reported By: Richard Walters
Date Reported: 2005-08-01
Held for Document Update by: Robert Sparks
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: Held for Document Update
Type: Editorial
Reported By: Jim Bell
Date Reported: 2007-12-17
Held for Document Update by: Robert Sparks
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.
Errata ID: 2953
Status: Verified
Type: Technical
Reported By: Joel Gannett
Date Reported: 2011-08-31
Verifier Name: Stewart Bryant
Date Verified: 2011-09-02
Section 3.4 says:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
It should say:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 25
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
Notes:
The distance from RT4 to N8 should be changed from 18 to 25. Unless there is a virtual link between RT7 and RT10, the shortest path from RT4 to N8 is 25, not 18. Although a virtual link from RT7 and RT10 is discussed in the last paragraph of Section 3.4, it is not assume part of the network design. Moreover, this change is needed to make the N9-N11,H1 row consistent with the N8 row, as each entry in the N9-N11,H1 row must be 11 greater than the same-column entry in the N8 row.
Errata ID: 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: 2394
Status: Reported
Type: Technical
Reported By: Andrea Ceschia
Date Reported: 2010-07-29
Section 3.4. says:
Table 5: Backbone distances calculated by Routers RT3 and RT4
dist from dist from
RT3 RT4
to Ia 20 27
to Ib 15 22
It should say:
Table 5: Backbone distances calculated by Routers RT3 and RT4.
dist from dist from
RT3 RT4
to Ia 15 22
to Ib 20 27
Notes:
From RT3 and RT4 perspective the Ia is the nearest interface while Ib is at the remote side of the link connecting RT6 to RT10.
Errata ID: 2951
Status: Rejected
Type: Technical
Reported By: Joel Gannett
Date Reported: 2011-08-31
Rejected by: Stewart Bryant
Date Rejected: 2011-09-02
Section 3.4 says:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
It should say:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 29
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
Notes:
The distance from RT4 to N9-N11,H1 should be changed from 36 to 29 to be consistent with the row above that, which shows the distance from RT3 to N8 and RT4 to N8 as the same value, 18. The length 18 path from RT3 to N8 is RT3-RT6-RT10-N8, while the length 18 path from RT4 to N8 is RT4-RT5-RT7-RT10-N8. The summarized N9-N11,H1 network is a distance 11 beyond that, or 29 in both cases. The length 29 path from RT3 to N9-N11,H1 is RT3-RT6-RT10-RT11-(N9-N11,H1), and the length 29 path from RT4 to N9-N11,H1 is RT4-RT5-RT7-RT10-RT11-(N9-N11,H1).
--VERIFIER NOTES--
Joel made an error in posting this erratum. He posted a corrected erratum (2953) to which the reader is referred.
Errata ID: 2632
Status: Reported
Type: Editorial
Reported By: Dave Cowley
Date Reported: 2010-11-13
Section 11. says:
Cost
The link state cost of the path to the destination. For all
paths except type 2 external paths this describes the entire
path's cost. For Type 2 external paths, this field describes
the cost of the portion of the path internal to the AS.
It should say:
Cost
The link state cost of the path to the destination. For all
paths except type 2 external paths this describes the entire
path's cost. For Type 1 external paths, this field describes
the cost of the portion of the path both internal and external
to the AS.
Notes:
'Type 2 cost' is listed in the subsequent 'field' description for section 11 (The Routing Table Structure).
Errata ID: 2952
Status: Reported
Type: Editorial
Reported By: Joel Gannett
Date Reported: 2011-08-31
Section 14.1 says:
Premature aging is also be used when unexpectedly receiving self-originated LSAs during the flooding procedure (see Section 13.4).
It should say:
Premature aging might also be used when unexpectedly receiving self-originated LSAs during the flooding procedure (see Section 13.4).
Notes:
Change "is also be used" to "might also be used."
Errata ID: 1420
Status: Held for Document Update
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-05-11
Held for Document Update by: Stewart Bryant
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: Held for Document Update
Type: Editorial
Reported By: Dande Rajasekhar
Date Reported: 2009-08-19
Held for Document Update by: Stewart Bryant
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
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.
Errata ID: 1258
Status: Verified
Type: Technical
Reported By: Edwin Groothuis
Date Reported: 2008-01-13
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section Examples says:
Write Request
client server
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| --> RRQ
<-- |6|blksize|0|2048|0| OACK
It should say:
Write Request
client server
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| --> WRQ
<-- |6|blksize|0|2048|0| OACK
Notes:
At the "Write Request", the string RRQ should be replaced with WRQ.
Errata ID: 1255
Status: Held for Document Update
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2008-01-11
Held for Document Update by: Robert Sparks
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)
Note: This RFC has been obsoleted by RFC4601 RFC5059
Source of RFC: idmr (rtg)
Errata ID: 457
Status: Verified
Type: Technical
Reported By: RFC Editor
Date Reported: 2001-01-03
Throughout the document:
[Figures are present only in the postscript version]
Notes:
There is no postscript version available.
Note: This RFC has been obsoleted by RFC3513
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: Mark Meiss
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.
Errata ID: 2943
Status: Verified
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2011-08-18
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14
Section 7 says:
S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
C: APOP rg c4c9334bac560ecc979e58001b3e22fb
It should say:
S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
C: APOP rg 8f5de26536bc248ba202a9ca612e71bd
Notes:
If the password for user "rg" is "secret" as in the plain PASS example before this APOP example, then
MD5("<1896.697170952@mail.eudora.com>secret") should be as shown in the corrected text.
The original text is a modification of the APOP example in RFC 1939, and
MD5("<1896.697170952@dbc.mtview.ca.us>tanstaaf") almost certainly will not match any plausible
MD5("<1896.697170952@mail.eudora.com>"||password).
Errata ID: 2942
Status: Held for Document Update
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2011-08-18
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-11-15
Section 7 says:
The URL:
<pop://baz;AUTH=SCRAM-MD5@foo.bar>
Results in the following client commands:
<connect to foo.bar, port 110>
S: +OK POP3 server ready <1896.697170952@foo.bar>
C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
It should say:
The URL:
<pop://baz;AUTH=CRAM-MD5@foo.bar>
Results in the following client commands:
<connect to foo.bar, port 110>
S: +OK POP3 server ready <1896.697170952@foo.bar>
C: AUTH CRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
Notes:
The name of the SASL mechanism based on RFC 2222 when this RFC was published is CRAM-MD5 specified in RFC 2195. This is unrelated to the SCRAM-family of SASL mechanisms specified in RFC 5802. Section 4 in RFC 2384 explains the intended SASL POP mechanism names; notably no "S" to indicate SASL.
VERIFIER NOTE: We could change "SCRAM-MD5" to "CRAM-MD5", but we would need to modify the Base64 at the same time. This should be done through a document update or a separate erratum.
Errata ID: 2937
Status: Verified
Type: Editorial
Reported By: Anne van Kesteren
Date Reported: 2011-08-14
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 5.6 says:
application/x-url-encoded
It should say:
application/x-www-form-urlencoded
Notes:
This incorrect media type appears twice and should be replaced both times. In the last paragraph of this section "both" and "as well" can be removed.
Errata ID: 2011
Status: Held for Document Update
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2010-01-21
Held for Document Update by: Peter Saint-Andre
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.
Errata ID: 1847
Status: Held for Document Update
Type: Editorial
Reported By: Yin Gaosong
Date Reported: 2009-09-07
Held for Document Update by: Wes Eddy
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"
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>
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.
Note: This RFC has been obsoleted by RFC3986
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: 452
Status: Verified
Type: Technical
Reported By: Henry Zongaro
Date Reported: 2001-11-12
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11
Section Appendix C says:
C.1. Normal Examples
...
?y = http://a/b/c/?y
...
Notes:
Appendix C shows an example of a relative URI Reference of "?y" with
respect to the base URI "http://a/b/c/d;p?q". However, according to the
collected syntax that appears in Appendix A, "?y" doesn't appear to be a
valid relative URI reference. The syntactic category URI-reference must
begin with an absoluteURI, a relativeURI or a pound sign. An absoluteURI
begins with a scheme, which cannot begin with a question mark; a
relativeURI begins with a net_path or abs_path, both of which begin with a
slash, or with a rel_path. A rel_path begins with a non-empty
rel_segment, which again cannot begin with a question mark.
Alexey: this was fixed in RFC 3986 (the example is correct).
Errata ID: 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: 1933
Status: Held for Document Update
Type: Technical
Reported By: Skip Geel
Date Reported: 2009-10-25
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-11-11
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 ("\").
Peter: This also applies to RFC 3986.
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
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).
Note: This RFC has been obsoleted by RFC4306
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.
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.
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
Note: This RFC has been obsoleted by RFC3801
Source of RFC: Legacy
Errata ID: 440
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11
Section Appendix B says:
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
It should say:
Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: <ABCD-123456789@VM2.mycompany.com>
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: <part3@VM2-4321.mycompany.com>
Notes:
Date inconsistency. 4-digit year. Message-ID, Content-ID
syntax (missing <>) and semantics.
Errata ID: 442
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section Appendix B says:
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
It should say:
Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: <123456789@VM2.mycompany.com>
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: <part1@VM2-4321.mycompany.com>
Notes:
Date inconsistency. 4-digit year number.
Message-ID syntax error (angle brackets required); likewise
for Content-ID. In addition, Content-ID requires a fully-qualified
domain name as it must be world-unique, like a Message-ID.
RFC 1911 section 12 has a similar example with similar errors
in the date and message-id fields.
Errata ID: 444
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section Appendix B says:
| Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
| Content-ID: part6@VM2-4321
It should say:
| Date: Thu, 26 Aug 1993 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
| Content-ID: <part6@VM2-4321.mycompany.com>
Notes:
Date inconsistency. 4-digit year. Content-ID syntax (missing <>) and
semantics (need to use fully qualified domain name).
Errata ID: 446
Status: Verified
Type: Technical
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: 443
Status: Verified
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2002-01-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-11
Section 4.2.4 says:
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
It should say:
Date: Sun, 28 Jul 1996 10:08:49 -0800 (PST)
Notes:
RFC 822, section 5.2 prohibits date inconsistency
between day-of-week and date (see also RFC 2822, sect. 3.3).
RFC 1123 section 5.2.14 strongly encourages use of 4-digit
year numbers; RFC 2822 mandates them. These errors also appear
in RFC 1911 section 4.2.
Errata ID: 2523
Status: Verified
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2002-01-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section 15 says:
Content-type: message/disposition-notification
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Original-Recipient: rfc822;22722@vm.company.com
[...]
It should say:
Content-type: message/disposition-notification
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Original-Recipient: rfc822;22722@vm.company.com
[...]
Notes:
RFC 2298 does not permit extra CRLFs between fields
in a MDN. See the BNF in RFC 2298 section 3 (note that the CRLFs
there are the ones that terminate each header field).
Errata ID: 441
Status: Held for Document Update
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2002-01-07
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2002-01-31
Held for Document Update by: Peter Saint-Andre
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).
Note: This RFC has been obsoleted by RFC6350
Source of RFC: asid (app)
Errata ID: 868
Status: Verified
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-18
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26
Section 4 says:
;For name=3D"AGENT"
param =3D agent-inline-param
param =3D/ agent-refer-param
value =3D agent-inline-value
; Value and parameter MUST match
value =3D/ agent-refer-value
; Value and parameter MUST match
agent-inline-param =3D ""
; No parameters allowed
agent-refer-param =3D "VALUE" "=3D" "uri"
; Only value parameter allowed
agent-inline-value =3D text-value
; Value MUST be a valid vCard object
agent-refer-value =3D uri
; URI MUST refer to image content of given type
It should say:
;For name=3D"AGENT"
param =3D agent-inline-param
param =3D/ agent-refer-param
value =3D agent-inline-value
; Value and parameter MUST match
value =3D/ agent-refer-value
; Value and parameter MUST match
agent-inline-param =3D ""
; No parameters allowed
agent-refer-param =3D "VALUE" "=3D" "uri"
; Only value parameter allowed
agent-inline-value =3D text-value
; Value MUST be a valid vCard object
agent-refer-value =3D uri
; URI MUST refer a valid vCard object
Notes:
- Presumably, the comment from img-refer-value was copied, but it was
not modified.
- The correction is consistent with comment for agent-inline-value.
- The purpose of AGENT type is "To specify information about another
person who will act on behalf of the individual or resource associated
with the vCard." (Section 3.5.4)
Errata ID: 869
Status: Verified
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-27
Section 4 says:
;For name="SOURCE"
param = source-param
; No parameters allowed
It should say:
;For name="SOURCE"
param = source-param
; Only source parameters allowed
Notes:
Corrected the comment.
Errata ID: 870
Status: Verified
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26
Section 4 says:
;For name=3D"UID"
param =3D ""
; No parameters allowed
value =3D text-value
It should say:
;For name="UID"
param = "TYPE" "=" (iana-token / x-name)
; Only the TYPE parameter is allowed.
value = text-value
Notes:
Section 3.6.7 (p. 23) "UID Type Definition" says:
The type can include the type parameter "TYPE" to specify the format
of the identifier. The TYPE parameter value should be an IANA
registered identifier format. The value can also be a non-standard
format.
Alexey: edited as per feedback from Simon Perreault.
Errata ID: 871
Status: Verified
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25
Section 4 says:
adr-type =3D "dom" / "intl" / "postal" / "parcel" / "home"
/ "work" / "pref" / iana-type / x-name
^^^^^^^^^
It should say:
adr-type =3D "dom" / "intl" / "postal" / "parcel" / "home"
/ "work" / "pref" / iana-token / x-name
^^^^^^^^^^
Notes:
iana-type is not defined in given ABNF, but iana-token is. This is
the only reference to iana-type in the document, so it is likely to be a
typo.
iana-token =3D 1*(ALPHA / DIGIT / "-")
; vCard type or parameter identifier registered with IANA
Errata ID: 872
Status: Verified
Type: Technical
Reported By: Javier Godoy
Date Reported: 2007-03-25
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26
Section 7 says:
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=3DWORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=3DVOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=3DFAX,WORK:+1-919-676-9564
EMAIL;TYPE=3DINTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=3DINTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard
BEGIN:vCard
VERSION:3.0
FN:Tim Howes
ORG:Netscape Communications Corp.
ADR;TYPE=3DWORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=3DVOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=3DFAX,WORK:+1-415-528-4164
EMAIL;TYPE=3DINTERNET:howes@netscape.com
END:vCard
It should say:
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
| N:Dawson;Frank;;;
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard
BEGIN:vCard
VERSION:3.0
FN:Tim Howes
| N:Howes;Tim;;;
ORG:Netscape Communications Corp.
ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=FAX,WORK:+1-415-528-4164
EMAIL;TYPE=INTERNET:howes@netscape.com
END:vCard
Notes:
- "Profile special notes: The vCard object MUST contain the FN, N and
VERSION types." (Section 1) N was missing in the original information.
Errata ID: 1546
Status: Verified
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21
Section 4 says:
;For name="SOUND"
param = snd-inline-param
; Only sound parameters allowed
param =/ snd-refer-param
; Only sound parameters allowed
value = snd-line-value
; Value MUST match value type
It should say:
;For name="SOUND"
param = snd-inline-param
; Only sound parameters allowed
param =/ snd-refer-param
; Only sound parameters allowed
value = snd-inline-value
; Value MUST match value type
Notes:
There is no "snd-line-value" specified, but a "snd-inline-value" is.
Errata ID: 1548
Status: Verified
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section 4 says:
img-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" param-value
;TYPE value MUST be an IANA registered image type
It should say:
img-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" param-value)
;TYPE value MUST be an IANA registered image type
Notes:
There is a closing parenthesis missing at the end of "TYPE".
Errata ID: 1549
Status: Verified
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25
Section 4 says:
;For name="KEY"
[...]
key-bin-param = ("TYPE" "=" keytype)
/ ("ENCODING" "=" "b")
; Value MUST be a "b" encoded key or certificate
It should say:
;For name="KEY"
[...]
key-bin-param = ("VALUE" "=" "binary")
/ ("TYPE" "=" keytype)
/ ("ENCODING" "=" "b")
; Value MUST be a "b" encoded key or certificate
Notes:
According to sections 2.4.1 and 3.7.2 the KEY type value can be specified as "binary".
Errata ID: 1550
Status: Verified
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-26
Section 4 says:
;For name="SOUND"
param = snd-inline-param
; Only sound parameters allowed
param =/ snd-refer-param
; Only sound parameters allowed
value = snd-line-value
; Value MUST match value type
value =/ snd-refer-value
; Value MUST match value type
snd-inline-value = binary-value CRLF
; Value MUST be "b" encoded audio content
snd-inline-param = ("VALUE" "=" "binary"])
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" *SAFE-CHAR)
; Value MUST be an IANA registered audio type
It should say:
;For name="SOUND"
param = snd-inline-param
; Only sound parameters allowed
param =/ snd-refer-param
; Only sound parameters allowed
value = snd-inline-value
; Value MUST match value type
value =/ snd-refer-value
; Value MUST match value type
snd-inline-value = binary-value
; Value MUST be "b" encoded audio content
snd-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b")
/ ("TYPE" "=" *SAFE-CHAR)
; Value MUST be an IANA registered audio type
Notes:
There is an odd "CRLF" at the end of the "snd-inline-value" definition. No other definition for binary-values contains this.
The value definition was corrected to "snd-inline-value" as reported in Errata ID 1546.
I also removed an unmeant closing squared bracket in the VALUE-part of the "snd-inline-param" definition.
Errata ID: 1551
Status: Verified
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-25
Section 4 says:
;For name="EMAIL"
[...]
email-type = "INTERNET" / "X400" / iana-token / "X-" word
; Values are case insensitive
It should say:
;For name="EMAIL"
[...]
email-type = "INTERNET" / "X400" / iana-token / x-name
; Values are case insensitive
Notes:
The email-type should contain a 'x-name' type instead of '"X-" word' for consistancy with tel-type, key-type and adr-type.
Although "word" appears several times, it is not defined at all!
Errata ID: 1547
Status: Held for Document Update
Type: Technical
Reported By: Markus Lorenz
Date Reported: 2008-10-09
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
Section 4 says:
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:
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.
Alexey: Also added a missing ")" at the end of img-inline-param definition.
Errata ID: 436
Status: Held for Document Update
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Vincent Ricard
Date Reported: 2002-08-01
Held for Document Update by: Peter Saint-Andre
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
Note: This RFC has been obsoleted by RFC5545
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.
Note: This RFC has been obsoleted by RFC5546
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
Errata ID: 2398
Status: Verified
Type: Editorial
Reported By: Zdenek
Date Reported: 2010-07-29
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 3.4 says:
A proof is given in [2] that this algorithm ....
It should say:
A proof is given in [5] that this algorithm....
Notes:
On page 8
Correct the reference.
Errata ID: 1054
Status: Held for Document Update
Type: Editorial
Reported By: Nataraja Kumar Kota
Date Reported: 2007-08-27
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
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 at which triggered updates may be transmitted.
Note: This RFC has been obsoleted by RFC3280
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
Errata ID: 2541
Status: Reported
Type: Technical
Reported By: Brian Carpenter
Date Reported: 2010-10-03
Section 6 says:
(Nothing about this omission.)
It should say:
Compared to RFC 1883, this specification reduces the size of the flow label field to 20 bits. The references to a 24 bit flow label field on pages 87 and 88 of RFC 2205 are updated accordingly.
Notes:
RFC 2460 updates RFC 2205.
Errata ID: 2843
Status: Reported
Type: Technical
Reported By: Florian Weimer
Date Reported: 2011-06-24
Section 5 says:
In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used.
It should say:
(delete paragraph)
Notes:
This requirement makes it impossible to offer services over IPv6 without keeping per-flow state in the server node. There is no reason why IPv4 fragmentation cannot be used after translation to IPv4.
Note: This RFC has been obsoleted by RFC4862
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.
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
Note: This RFC has been obsoleted by RFC4282
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
Note: This RFC has been obsoleted by RFC2939
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
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).
Errata ID: 2546
Status: Reported
Type: Technical
Reported By: Igor Idziejczak
Date Reported: 2010-10-06
Section 4 says:
The DESTINATION_ADDR field contains either a unicast Ethernet destination address, or the Ethernet broadcast address (0xffffffff).
It should say:
The DESTINATION_ADDR field contains either a unicast Ethernet destination address, or the Ethernet broadcast address (0xffffffffffff).
Notes:
the ethernet broadcast address is 48bit so in hex 0xffffffffffff
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"
Note: This RFC has been obsoleted by RFC4918
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
Note: This RFC has been obsoleted by RFC3647
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.
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: Verified
Type: Editorial
Reported By: Al Morton
Date Reported: 2006-11-05
Verifier Name: ron bonica
Date Verified: 2010-11-01
Section 26.1 says:
Procedure: Send a specific number of frames at a specific rate
through the DUT and then count the frames that are transmitted by the
DUT. If the count of offered frames is equal to the count of received
frames, the fewer frames are received than were transmitted, the rate
of the offered stream is reduced and the test is rerun.
It should say:
Procedure:
Send a specific number of frames at a specific rate through the
DUT and then count the frames that are transmitted by the DUT. If
the count of offered frames is equal to the count of received
frames, the rate of the offered stream is raised and the test
rerun. If fewer frames are received than were transmitted, the
rate of the offered stream is reduced and the test is rerun.
Errata ID: 1484
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-08
Held for Document Update by: ron bonica
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: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-15
Held for Document Update by: ron bonica
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: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-08-19
Held for Document Update by: ron bonica
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).
Errata ID: 2711
Status: Held for Document Update
Type: Editorial
Reported By: Wang Haojian
Date Reported: 2011-02-11
Held for Document Update by: ron bonica
Section Appendix C says:
Notes:
Is there something wrong in the sub section title ?
C.2.5 is missing while the C.2.6.1 and C.2.6.2 exists ?
Errata ID: 420
Status: Verified
Type: Technical
Reported By: Hans-Ake Lund
Date Reported: 2005-02-04
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10
Section 2.7.9 says:
Description
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
It should say:
Description
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary NetBIOS Name Server (NBNS) [18] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
Errata ID: 1607
Status: Verified
Type: Technical
Reported By: Alan DeKok
Date Reported: 2008-11-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10
Section 2.4.1 says:
The NT-Key sub-field is sixteen octets in length and contains the first sixteen octets of the hashed Windows NT password. The format of the plaintext Keys field is illustrated in the following diagram:
It should say:
The NT-Key sub-field is sixteen octets in length and contains the first sixteen octets of the hash of the hashed Windows NT password. The format of the plaintext Keys field is illustrated in the following diagram:
Notes:
See comments referring to RFC 2548 around line 1350 of:
http://github.com/alandekok/freeradius-server/tree/master/src%2Fmodules%2Frlm_mschap%2Frlm_mschap.c
This is interoperable with everything, including Windows.
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:
Errata ID: 2253
Status: Verified
Type: Editorial
Reported By: Jim Schaad
Date Reported: 2010-05-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20
Section 4.2.1 says:
UnknownInfo ::= NULL -- this can be replaced with an enumeration
It should say:
UnknownInfo ::= NULL
Notes:
The is no way to change this without making existing decoders fail decoding the answer. The comment should therefore be removed
The same line exists in the ASN.1 module and should be removed there as well.
Errata ID: 2329
Status: Verified
Type: Editorial
Reported By: Shirley Carter
Date Reported: 2010-07-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20
Section 4.2.2.2.1 says:
CAs issuing such a certificate should realized that
It should say:
CAs issuing such a certificate should realize that
Notes:
simple typo "realized" => "realize"
Note: This RFC has been obsoleted by RFC3584
Source of RFC: snmpv3 (ops)
Errata ID: 1435
Status: Rejected
Type: Technical
Reported By: grant mills
Date Reported: 2008-06-11
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
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.
--VERIFIER NOTES--
This comment needs to be made to the RFC Editor as it concerns the RFC Editor Web pages.
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:
Note: This RFC has been obsoleted by RFC5681
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:
Errata ID: 1831
Status: Verified
Type: Technical
Reported By: Paul Hoffman
Date Reported: 2009-08-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20
Section 4.1 and 4.2 says:
Optional parameters: version (default value is "1")
It should say:
Optional parameters: none [Note: legacy implementations MAY include a version parameter, which SHOULD be ignored if present.]
Notes:
The optional parameters is ambiguous because it does not state what the version refers to. It is unlikely to be the version of PKIX, because RFC 2459 preceded this document, and the versions of the PKIX format described in RFC 2459 was 2 and 3. The authors note that we did not have a reference to the PKIX specification. Because of this, we suggest that the "version" parameter be ignored if present, and that no assumption of what the default of "1" means. Further, we suggest that "version" not be used when generating MIME bodies.
Errata ID: 1076
Status: Held for Document Update
Type: Technical
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-03
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.
Alexey: The submitted errata indicated that multiple wildcards were allowed (e.g., *.*.a.com matches foo.bar.a.com but not foo.com). This is too large of a change to make with an errata. The Security and Application ADs feel a consensus call would be required to make that change. Further, the current practice is to allow only one at the leftmost position. This is being documented in draft-saintandre-tls-server-id-check and its intended to be a BCP.
Errata ID: 413
Status: Held for Document Update
Type: Editorial
Reported By: Bud
Date Reported: 2005-05-24
Held for Document Update by: Wes Eddy
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.
Note: This RFC has been obsoleted by RFC3246
Source of RFC: diffserv (tsv)
Errata ID: 1708
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-06
Held for Document Update by: Wes Eddy
Date Held: 2011-08-17
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.
Notes:
Fix double-quotes to apostrophe and note order of "best" and "worst"
Errata ID: 412
Status: Verified
Type: Technical
Reported By: Justin Erenkrantz
Date Reported: 2001-01-05
Report Text:
From Scott Lawrence: All known errata for this HTTP RFC will be found at: http://purl.org/NET/http-errata and http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
Errata ID: 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: 411
Status: Verified
Type: Technical
Reported By: WooJin Chung
Date Reported: 2006-10-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-04
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.
Alexey: This issue was fixed in HTTPBIS WG, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/25>
Errata ID: 2301
Status: Rejected
Type: Technical
Reported By: Conrad Roche
Date Reported: 2010-06-14
Rejected by: Alexey Melnikov
Date Rejected: 2010-07-07
Section 14.36 says:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
It should say:
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from whose message-body the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
Notes:
The text should mention that the referrer is specified when the URI was obtained from the message-body of the Request-URI.
For instance, when the user agent receives a 302 response for a Request-URI, it does not specify the original Request-URI in the referrer header for the subsequent request - even though the (redirect) URI "was obtained" from the (header of the) 302 response for the original Request-URI.
Roy T. Fielding replied:
I think this should be rejected. The referrer is the redirect.
User agents should be sending the redirecting URI in Referer,
or sending nothing in Referer.
In any case, see the Link header field. It is certainly possible
to be referred by something in the header fields, so saying that it
is in the message-body would be incorrect.
--VERIFIER NOTES--
As per the reply from Roy T. Fielding.
Errata ID: 2998
Status: Rejected
Type: Technical
Reported By: Julien Moutinho
Date Reported: 2011-10-15
Rejected by: Peter Saint-Andre
Date Rejected: 2011-10-17
Section 3.2.1 says:
For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]).
It should say:
For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 3986 [<ref>] (which updates RFCs 1738 [4] and replaces RFC 1808 [11] and RFC 2396 [42]).
Notes:
<ref> should be added
--VERIFIER NOTES--
The reader can follow the chain of document updates from RFC 2396 to RFC 3986, which is why we do not modify published RFCs to track document updates for referenced specifications. In any case, the updated HTTP RFCs (being produced by the HTTPBIS WG) will contain the appropriate references.
Errata ID: 3056
Status: Rejected
Type: Technical
Reported By: Julien Moutinho
Date Reported: 2011-12-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-12-21
Section 5.1.2 says:
Request-URI = "*" | absoluteURI | abs_path | authority
It should say:
Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authority
Notes:
so that "/path?query" is a valid Request-URI as it should.
because it is not the case with RFC 3986
(obsoleting RFC 2396 which has the same problem actually):
absoluteURI = absolute-URI
abs_path = path-absolute
absolute-URI = scheme ":" hier-part [ "?" query ]
path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment-nz = 1*pchar
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
--VERIFIER NOTES--
This issue has been fixed in the revisions to RFC 2616, see http://trac.tools.ietf.org/wg/httpbis/trac/changeset/76
Errata ID: 652
Status: Verified
Type: Editorial
Reported By: Justin Erenkrantz
Date Reported: 2000-12-23
Section 4.4 says:
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self- elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte- range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.
It should say:
4.If the message uses the media type "multipart/byteranges", and the Transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
Notes:
Missing the first character of 6 words.
Errata ID: 653
Status: Verified
Type: Editorial
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: 892
Status: Held for Document Update
Type: Editorial
Reported By: WooJin Chung
Date Reported: 2006-10-31
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Martin Kong
Date Reported: 2008-08-06
Held for Document Update by: Peter Saint-Andre
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: Held for Document Update
Type: Editorial
Reported By: Heming Hou
Date Reported: 2008-11-25
Held for Document Update by: Peter Saint-Andre
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";
Errata ID: 2645
Status: Rejected
Type: Editorial
Reported By: Winfred Qin
Date Reported: 2010-11-27
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-03
Section 3.5 says:
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
It should say:
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with future implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
Notes:
"For compatibility with previous implementations of HTTP",
here, 'previous' should be replaced by 'future'.
--VERIFIER NOTES--
Comment by Peter Saint-Andre:
This erratum is incorrect -- the text is clearly about
backward compatibility, not forward compatibility. The
original poster can comment in the HTTPBIS WG about this
matter since draft-ietf-httpbis-p1-messaging has very
similar text.
Errata ID: 2806
Status: Rejected
Type: Editorial
Reported By: Carlos McEvilly
Date Reported: 2011-05-12
Rejected by: RFC Editor
Date Rejected: 2011-05-16
Section 14.13 says:
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#section- ">section</a> <a href="#section- ">4.4</a>.
It should say:
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#section-4.4">section 4.4</a>.
Notes:
This errata refers to the linkified version of the RFC at:
http://tools.ietf.org/html/rfc2616
Note that the original and corrected text above both contain HTML tags. In case the text doesn't survive the form submission, just to describe the problem, the link in the text shown, an internal anchor link that should point to #section-4.4, is broken because the number 4.4 is missing at the end of the anchor inside the href quotes.
--- VERIFIER NOTES ---
This report has been rejected because it is regarding a link in the HTML version of the RFC on tools.ietf.org. The report has been directed to webmaster@tools.ietf.org.
Errata are for the RFCs as available from rfc-editor.org.
Errata ID: 410
Status: Verified
Type: Technical
Reported By: Scott Lawrence
Date Reported: 2001-01-05
Report Text:
All known errata for this HTTP RFC will be found at: http://purl.org/NET/http-errata and http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
Errata ID: 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: 2600
Status: Verified
Type: Technical
Reported By: Victor S. Osipov
Date Reported: 2010-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-07-14
Section 3.2.2 says:
digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1
It should say:
digest-uri = "uri" "=" <"> digest-uri-value <"> digest-uri-value = request-uri ; As specified by HTTP/1.1
Notes:
This is an error here that the digest-uri-value is not enclosed in quotation marks;
see the correct example in Section 3.5:
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
. . .
Errata ID: 1649
Status: Reported
Type: Technical
Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-08
Edited by: Alexey Melnikov
Date Edited: 2010-07-07
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: Rejected
Type: Technical
Reported By: Larry Westrick
Date Reported: 2009-10-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-27
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.
--VERIFIER NOTES--
The verifier notes on the rejected Erratum 1796 were as follows:
###
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.
###
If there is good reason to pursue this issue further, please do so outside
the errata process.
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.
Note: This RFC has been obsoleted by RFC4338
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
Errata ID: 2753
Status: Verified
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Verifier Name: ron
Date Verified: 2011-03-26
Section 3.6 says:
3.6 "Network News" There does exist a problem in both NNTP, RFC 977, and the Usenet News Message Format, RFC 10336. They both specify two-digit year format. A working group has been formed to update the network news protocols in general, and addressing this problem is on their list of work items.
It should say:
3.6 "Network News" There does exist a problem in both NNTP, RFC 977, and the Usenet News Message Format, RFC 1036. They both specify two-digit year format. A working group has been formed to update the network news protocols in general, and addressing this problem is on their list of work items.
Notes:
s/RFC 10336/RFC 1036
Errata ID: 2754
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Held for Document Update by: ron
Section 2; 5.1; 6 says:
{1 - Section 2}
[...] It should also be noted that the research was performd on RFCs 1
through 2128. At that time the IESG was charted with not allowing [...]
{2 - Section 5.1}
5.1 Fixed Solution
A number of organizations and groups have suggested a fixed solution
to the problem of two digit years. Given a two-digit year YY, if YY
is greater than or equal to 50, the year shall be interpreted as
19YY; and where YY is less than 50, the year shall be intrepreted as
20YY.
{3 - Section 6}
6. Methodology
The first task was dividing the types of RFC's into logical groups
rather than the strict numeric publishing order. Sixteen specific
areas were identified. They are: "Autoconfiguration" , "Directory
Services", "Disk Sharing", "Games and Chat" ,"Information Services &
File Transfer", "Network & Transport Layer", "Electronic Mail",
"NTP", Name Serving", "Network Management", "News", "Real Time
Services", "Routing", "Security", "Virtual Terminal", and "Other".
In addition to these categories, many hundreds of RFC's were
immediately eliminated based on content. That is not to say that all
Informational RFC's were not considered, many did contain some
technical content or overview whichdemanded scrutiny.
It should say:
{1 - Section 2}
[...] It should also be noted that the research was performed on RFCs 1
through 2128. At that time the IESG was charted with not allowing [...]
{2 - Section 5.1}
5.1 Fixed Solution
A number of organizations and groups have suggested a fixed solution
to the problem of two digit years. Given a two-digit year YY, if YY
is greater than or equal to 50, the year shall be interpreted as
19YY; and where YY is less than 50, the year shall be interpreted as
20YY.
{3 - Section 6}
6. Methodology
The first task was dividing the types of RFC's into logical groups
rather than the strict numeric publishing order. Sixteen specific
areas were identified. They are: "Autoconfiguration" , "Directory
Services", "Disk Sharing", "Games and Chat" ,"Information Services &
File Transfer", "Network & Transport Layer", "Electronic Mail",
"NTP", Name Serving", "Network Management", "News", "Real Time
Services", "Routing", "Security", "Virtual Terminal", and "Other".
In addition to these categories, many hundreds of RFC's were
immediately eliminated based on content. That is not to say that all
Informational RFC's were not considered, many did contain some
technical content or overview which demanded scrutiny.
Notes:
{1} A typo in "performed".
{2} A typo in "interpreted".
{3} A typo in "which demanded".
Errata ID: 2755
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Held for Document Update by: ron
Section 12.1; 12.2 says:
{1 - Section 12.1}
12.1 Summary
The RFC's which were categorized into this group were the Internet
Protocol (IP) versions four and six, the Transmission Control
Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point
Protocol (PPP) and its extensions, Internet Control Message Protocol
(ICMP), the Address Resolution Protocol (ARP) and Remote Procedure
Call (RPC) protocol. A variety of less known protocols were also
examined.
After careful review of the nearly 400 RFC's in this catagory, no
millennium or year 2000 problems were found.
{2 - Section 12.2}
[...]
RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses several
timer and timeouts in Section 2.1, none of which suffers from a year
2000 problem.
[...]
RFC 791 on the Internet Protocol defines a packet type 68 which is an
Internet Timestamp, which defines a 32-bit field which contains the
number of milliseconds since midnght UT.
It should say:
{1 - Section 12.1}
12.1 Summary
The RFC's which were categorized into this group were the Internet
Protocol (IP) versions four and six, the Transmission Control
Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point
Protocol (PPP) and its extensions, Internet Control Message Protocol
(ICMP), the Address Resolution Protocol (ARP) and Remote Procedure
Call (RPC) protocol. A variety of less known protocols were also
examined.
After careful review of the nearly 400 RFC's in this category, no
millennium or year 2000 problems were found.
{2 - Section 12.2}
[...]
RFC 2097 on the PPP NetBIOS Frame Control Protocol discusses several
timer and timeouts in Section 2.1, none of which suffers from a year
2000 problem.
[...]
RFC 791 on the Internet Protocol defines a packet type 68 which is an
Internet Timestamp, which defines a 32-bit field which contains the
number of milliseconds since midnight UT.
Notes:
{1} A typo in "category".
{2} 1) A typo in "discusses";
2) A typo in "midnight".
Note: This RFC has been obsoleted by RFC3369 RFC3370
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.
Errata ID: 2506
Status: Verified
Type: Technical
Reported By: Yves Legrandgerard
Date Reported: 2010-09-01
Verifier Name: Sean Turner
Date Verified: 2012-01-06
Section 2.2.1.1 says:
6. For i = 0 to m' - 1
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
Note that for m=160, this reduces to the algorithm of [FIPS-186]
U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].
It should say:
6. For i = 0 to m' - 1
U = U + [SHA1(seed + i) Xor SHA1((seed + m' +i ) mod 2^{seedlen})] * 2^{160 * i}
Note that for m=160, this reduces to the algorithm of [FIPS-186]
U = [SHA1(seed) Xor SHA1((seed +1) mod 2^{seedlen})], where seedlen
is the binary length of seed.
Notes:
The line:
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
is syntactically incorrect. Closing bracket of last 'SHA1[' is missing.
Moreover, when m=160 (m'=1), the loop cannot reduce to the line:
U = SHA1[SEED] XOR SHA1[(SEED + 1) mod 2^160]
as it can be easily seen.
Errata ID: 1060
Status: Held for Document Update
Type: Editorial
Reported By: Javier Ader
Date Reported: 2007-09-13
Held for Document Update by: Tim Polk
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.
Note: This RFC has been obsoleted by RFC3851
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.
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.
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/>
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/>
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
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 :)
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.
Errata ID: 2175
Status: Reported
Type: Technical
Reported By: Constantin Hagemeierc
Date Reported: 2010-04-28
Section 4. says:
receiver derive the actual UDP packet length from the IPv6 payload length. (Note that, prior to this modification, zero was not a legal
It should say:
receiver derive the actual UDP packet length from the Jumbo Payload Length. (Note that, prior to this modification, zero was not a legal
Notes:
The IPv6 payload length is 0.
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 |
-----------------
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.
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.
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).
Note: This RFC has been obsoleted by RFC2800
Source of RFC: Legacy
Errata ID: 2781
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Held for Document Update by: ron bonica
Section TOC says:
2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 2
It should say:
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . 2
Note: This RFC has been obsoleted by RFC5791
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: Verified
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2009-05-09
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11
Section - says:
Notes:
It appears that this document has been obsoleted by "Expressing Dublin Core metadata using HTML/XHTML meta and link elements" (<http://dublincore.org/documents/dc-html/>).
Note: This RFC has been obsoleted by RFC3986
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
Note: This RFC has been obsoleted by RFC4133
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
Note: This RFC has been obsoleted by RFC5340
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: Held for Document Update
Type: Editorial
Reported By: Acee Lindem
Date Reported: 2003-02-22
Held for Document Update by: Stewart Bryant
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.
Errata ID: 2758
Status: Held for Document Update
Type: Editorial
Reported By: Martin Rex
Date Reported: 2011-03-29
Held for Document Update by: Stephen Farrell
Section 2.1.4 says:
o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must -- release with GSS_Release_oid_set() o initiator_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE o acceptor_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY o mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms -- supported by resulting credential. Return major_status codes:
It should say:
o actual_mechs SET OF OBJECT IDENTIFIER, -- full set of mechanisms -- supported by resulting credential. If returned, caller must -- release with GSS_Release_oid_set() o initiator_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE o acceptor_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE Return major_status codes:
Notes:
There appears to be accidentally duplicated text trailing the list of output parameters in section 2.1.4: GSS_Add_cred call (top of page 38).
The parameter "cred_usage" is an input-only parameter and also listed under input parameters, and the parameter "mech_set" is a duplicate of the actual_mechs output parameter. Compare GSS-API C-Bindings document rfc2744, section 5.3. gss_add_cred
-Martin
Errata ID: 1620
Status: Held for Document Update
Type: Editorial
Reported By: Ben Harris
Date Reported: 2008-11-25
Held for Document Update by: Sean Turner
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.
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.
Note: This RFC has been obsoleted by RFC5301
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.
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
Errata ID: 2984
Status: Reported
Type: Technical
Reported By: Jordan Brown
Date Reported: 2011-10-04
Section Weight says:
To select a target to be contacted next, arrange all SRV RRs
(that have not been ordered yet) in any order, except that all
those with weight 0 are placed at the beginning of the list.
Compute the sum of the weights of those RRs, and with each RR
associate the running sum in the selected order. Then choose a
uniform random number between 0 and the sum computed
(inclusive), and select the RR whose running sum value is the
first in the selected order which is greater than or equal to
the random number selected. The target host specified in the
selected SRV RR is the next one to be contacted by the client.
Remove this SRV RR from the set of the unordered SRV RRs and
apply the described algorithm to the unordered SRV RRs to select
the next target host. Continue the ordering process until there
are no unordered SRV RRs. This process is repeated for each
Priority.
It should say:
Correcting the text requires agreement on what to do with entries with weight=0, so I don't want to try to craft text until we have agreement there.
Notes:
The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry. Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time.
I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there: for {0, 1, 1}, the three entries are each selected 1/3 of the time.
I suggest:
- Ordering weight=0 entries to the end.
- Generating random numbers 0..(T-1).
- Using a "greater" test rather than "greater or equal".
- Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected.
Errata ID: 1706
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-03
Verifier Name: Stewart Bryant
Date Verified: 2010-10-22
Section 5.2 says:
An RFC 1701 transmitter may set any of the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits set to one, and thus may transmit the RFC 1701 Key, Sequence Number or Routing fields in the GRE header. As stated in Section 5.3, a packet with non-zero bits in any of bits 1-5 MUST be discarded unless the receiver implements RFC 1701.
It should say:
An RFC 1701 transmitter may set any of the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits set to one, and thus may transmit the RFC 1701 Key, Sequence Number or Routing fields in the GRE header. As stated in Section 2.3, a packet with non-zero bits in any of bits 1-5 MUST be discarded unless the receiver implements RFC 1701.
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
Errata ID: 1874
Status: Held for Document Update
Type: Editorial
Reported By: Matthias Bärwolff
Date Reported: 2009-09-10
Held for Document Update by: Danny McPherson
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.
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".
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: 2821
Status: Verified
Type: Technical
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10
Section 5.1 says:
341 RPL_INVITING
"<channel> <nick>"
It should say:
341 RPL_INVITING
"<nick> <channel>"
Notes:
Numeric reply 341 is used by the server to report a sucessful invitation attempt to the original client sending the invitation. The RFC mentions the reply arguments are the channel and the nickname, but every client and server I have tested expect the nickname first, followed by the channel name.
Errata ID: 2822
Status: Verified
Type: Technical
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10
Section 5.1 says:
The original text is missing.
It should say:
416 ERR_TOOMANYMATCHES
"<channel> :Output too long (try locally)"
- Returned by a server in response to a LIST or NAMES
message to indicate the result contains too many
items to be returned to the client.
Errata ID: 2991
Status: Verified
Type: Technical
Reported By: Matthew Campbell
Date Reported: 2011-10-11
Verifier Name: Peter Saint-Andre
Date Verified: 2011-10-17
Section 3.2.3 says:
The original text is missing.
It should say:
ERR_NOSUCHCHANNEL
Notes:
Numeric reply list for Channel Modes should include ERR_NOSUCHCHANNEL.
Errata ID: 3001
Status: Verified
Type: Technical
Reported By: Matthew Campbell
Date Reported: 2011-10-21
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 3.2.4 says:
The original text is missing.
It should say:
ERR_NOSUCHCHANNEL
Notes:
Numeric reply list for Topic should include ERR_NOSUCHCHANNEL.
Errata ID: 991
Status: Held for Document Update
Type: Technical
Reported By: Stefan Hoffmeister
Date Reported: 2007-06-10
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-06-24
Section 2.3.1 says:
shortname = ( letter / digit ) *( letter / digit / "-" )
*( letter / digit )
; as specified in RFC 1123 [HNAME]
It should say:
shortname = ( 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
Errata ID: 2306
Status: Held for Document Update
Type: Editorial
Reported By: Timo Buhrmester
Date Reported: 2010-06-18
Held for Document Update by: Peter Saint-Andre
Section 1.3 says:
Space is used as parameter separator and command is used as a list item separator by the protocol).
It should say:
Space is used as parameter separator and comma is used as a list item separator by the protocol).
Errata ID: 383
Status: Verified
Type: Technical
Reported By: Huang Xiangkui
Date Reported: 2006-08-28
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-24
Section 3.3 says:
The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3b), which MUST be the first character of the
^^^^
message itself.
It should say:
The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3a), which MUST be the first character of the
^^^^
message itself.
Errata ID: 2870
Status: Verified
Type: Editorial
Reported By: Ricardo Garcia
Date Reported: 2011-07-27
Verifier Name: Peter Saint-Andre
Date Verified: 2011-07-27
Section 5.2.1 says:
as per the LUSER reply
It should say:
as per the LUSERS reply
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>
Errata ID: 1077
Status: Held for Document Update
Type: Editorial
Reported By: Joseph Shraibman
Date Reported: 2007-11-14
Held for Document Update by: Sean Turner
Date Held: 2010-08-10
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 and f*.com matches foo.com but not bar.com.
Notes:
The submitted errata indicated that multiple wildcards were allowed (e.g., *.*.a.com matches foo.bar.a.com but not foo.com). This is too large of a change to make with an errata. The Security and Application ADs feel a consensus call would be required to make that change. Further, the current practice is to allow only one at the leftmost position. This is being documented in draft-saintandre-tls-server-id-check-09 and its intended to be a BCP.
The errata does however correct a misplaced parentheses, and uses semi-colons to separate examples.
Errata ID: 1400
Status: Rejected
Type: Technical
Reported By: Mehala
Date Reported: 2008-03-31
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
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".
--VERIFIER NOTES--
MIB documents before RFC 4001 may present this problem. It's a warning not a compilation error that should be ignored.
Errata ID: 382
Status: Held for Document Update
Type: Editorial
Reported By: Hallvard B Furuseth
Date Reported: 2005-01-06
Held for Document Update by: Peter Saint-Andre
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:
Note: This RFC has been obsoleted by RFC5321
Source of RFC: drums (app)
Errata ID: 375
Status: Verified
Type: Technical
Reported By: Jochen Topf
Date Reported: 2004-11-23
Verifier Name: Pete Resnick
Date Verified: 2011-05-16
Section 4.2.5 says:
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver that message.
It should say:
When an SMTP server returns a transient failure status (4yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver that message.
Notes:
Fixed in RFC 5321.
Errata ID: 380
Status: Verified
Type: Technical
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: 760
Status: Held for Document Update
Type: Technical
Reported By: Wayne Schlitt
Date Reported: 2005-05-12
Held for Document Update by: Alexey Melnikov
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: 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.
Note: This RFC has been obsoleted by RFC5322
Source of RFC: drums (app)
Errata ID: 373
Status: Verified
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2006-01-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21
Section 3.2.6 says:
unstructured = *([FWS] utext) [FWS]
It should say:
unstructured = *([FWS] utext) (*WSP / obs-FWS)
Notes:
A prominent example is the <subject> defined in section 3.6.5:
subject = "Subject:" unstructured CRLF
Expanding the [FWS] at the end (ignoring <obs-FWS>) results in:
subject = "Subject:" *([FWS] utext) [[*WSP CRLF] 1*WSP] CRLF
Alexey: note that this was fixed in RFC 5322 (which obsoleted RFC 2821) in a slightly different way.
Errata ID: 2244
Status: Held for Document Update
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 1 says:
By mentioning the method, he was concerned about encouraging it's use.
It should say:
By mentioning the method, he was concerned about encouraging its use.
Notes:
/it's/ s/'//
Errata ID: 372
Status: Rejected
Type: Editorial
Reported By: Craig A. Huegen
Date Reported: 2002-11-20
Rejected by: Sean Turner
Date Rejected: 2011-02-23
Section 9 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.
--VERIFIER NOTES--
According to the RFC editor:
The URL was correct at the time of publication, so we don't consider
this an erratum. That is, we don't believe errata should be used
to update things that were true at the time of publication. I think
using the errata in this way muddies the system.
Additionally, using Google search
on "Craig Huegen" returns a link to "Index of Craig Huegen's
Denial-of-Service papers and presentations", which seems sufficient.
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
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 )
Errata ID: 2258
Status: Held for Document Update
Type: Technical
Reported By: Flavio Poletti
Date Reported: 2010-05-13
Held for Document Update by: Peter Saint-Andre
Throughout the document, when it says:
Example 3: A file containing a base-64-encoded value version: 1 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg b3V0IG1vcmUu
It should say:
Example 3: A file containing a base-64-encoded value version: 1 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg b3V0IG1vcmUu
Notes:
There is no section numbering in this RFC, hence the "GLOBAL".
Note 10 in "Notes on LDIF Syntax" says that base64-encoded values are subject to the same folding rules explained in Note 2. Note 2 requires folded lines to begin with a space character.
This modification was introduced passing from draft-good-ldap-ldif to RFC 2849.
Errata ID: 2300
Status: Held for Document Update
Type: Editorial
Reported By: Alexey Melnikov
Date Reported: 2010-06-04
Held for Document Update by: Peter Saint-Andre
Section 4 says:
by-parameter = "BY="by-value by-value = by-time";"by-mode[by-trace]
It should say:
by-parameter = "BY=" by-value
^
by-value = by-time ";" by-mode [by-trace]
^ ^ ^
Notes:
This is not a valid ABNF. BAP (ABNF parser) complains:
error: Concatenation of adjacent elements is not allowed (missing whitespace?)
So extra spaces need to be inserted.
Note: This RFC has been obsoleted by RFC4760
Source of RFC: idr (rtg)
Errata ID: 370
Status: Held for Document Update
Type: Editorial
Reported By: Tom Petch
Date Reported: 2005-02-04
Held for Document Update by: Stewart Bryant
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: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-19
Held for Document Update by: Stewart Bryant
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.
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.
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: Verified
Type: Technical
Reported By: Isaac NickAein
Date Reported: 2008-07-13
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03
Section 7.3. says:
02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
00 01 0c 06 00 00 05 dc
It should say:
02 01 00 38 E8 6F A2 FE 28 70 33 AD 2F 6D 5C A3
F7 41 5D A2 06 06 00 00 00 02 07 06 00 00 00 01
08 06 FF FF FF FE 0A 06 00 00 00 00 0D 06 00 00
00 01 0C 06 00 00 05 DC
Notes:
in Attributes, "Framed-Routing" came with value "None" (0)
but in Hex dump of packet the value for this attribute is "Listen for routing packets" (2)
Correct Hex Dump, or Attributes.
Corrected Attributes is:
Attributes:
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
6 Framed-IP-Address (8) = 255.255.255.254
6 Framed-Routing (10) = Listen for routing packets (2)
6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
6 Framed-MTU (12) = 1500
----------
VERIFIER NOTE: Referenced section should be 7.2 and not 7.3
Errata ID: 2712
Status: Verified
Type: Editorial
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13
Section 5 says:
Note that none of the types in RADIUS terminate with a NUL (hex
00). In particular, types "text" and "string" in RADIUS do not
terminate with a NUL (hex 00). The Attribute has a length field
and does not use a terminator. Text contains UTF-8 encoded 10646
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
^^^^^^^^^^^^
It should say:
Note that none of the types in RADIUS terminate with a NUL (hex
00). In particular, types "text" and "string" in RADIUS do not
terminate with a NUL (hex 00). The Attribute has a length field
and does not use a terminator. Text contains UTF-8 encoded 10646
[7] characters and String contains 8-bit binary data. Servers and
clients MUST be able to deal with embedded nulls.
Notes:
Unnecessary Words.
Errata ID: 2713
Status: Verified
Type: Editorial
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13
Section 5 says:
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
It should say:
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
^^^^^^^^^^^
Notes:
Same as RFC2865 , extraneous "servers and" can be deleted. ;)
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:
Errata ID: 2714
Status: Verified
Type: Technical
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-28
Section 3.10 says:
3.10. Tunnel-Server-Auth-ID
Description
This Attribute specifies the name used by the tunnel terminator
during the authentication phase of tunnel establishment. The
Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
^^^^^^^^^^^^^^^^^^^^^
It should say:
3.10. Tunnel-Server-Auth-ID
Description
This Attribute specifies the name used by the tunnel terminator
during the authentication phase of tunnel establishment. The
Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the
Notes:
Maybe here should be the "Tunnel-Server-Auth-ID"
Errata ID: 2716
Status: Verified
Type: Editorial
Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13
Section 6 says:
6.1. Tunnel-Type Attribute Values Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16]. 6.2. Tunnel-Medium-Type Attribute Values Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
It should say:
6.1. Tunnel-Type Attribute Values Values 1-12 of the Tunnel-Type Attribute are defined in Section 3.1; the remaining values are available for assignment by the IANA with IETF Consensus [16]. 6.2. Tunnel-Medium-Type Attribute Values Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 3.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
Notes:
Should be "Section 3.1" and "Section 3.2"
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.
Errata ID: 1839
Status: Verified
Type: Technical
Reported By: Sean Turner
Date Reported: 2009-08-25
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section 7 says:
300b 0609 6086 4801 6502 0101 0400
It should say:
300b 0609 6086 4801 6502 0101 04
Notes:
The SMIMECapability for SKIPJACK should be 300b 0609 6086 4801 6502 0101 04, which is the DER encoding of the id-fortezzaConfidentialityAlgorithm OID. The extra 00 should not be included.
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
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:
Errata ID: 3072
Status: Reported
Type: Technical
Reported By: Michael Sweet
Date Reported: 2012-01-04
Section 4.2.4 says:
This attribute is relevant only if a job consists of two or more documents. This attribute MUST be supported with at least one value
It should say:
This attribute is relevant to jobs consisting of one or more documents. This attribute MUST be supported with at least one value
Notes:
Per consensus of the IPP working group in the Printer Working Group, the "multiple-document-handling" attribute *is* applicable to single-document jobs since it is the only common attribute that can be used to request copy collation.
The other collation attribute ("sheet-collate" from RFC3381])interacts with "multiple-document-handling" in some non-obvious ways and requires clients and printers to support two different attributes for simple collation. The "sheet-collate" attribute also does not address how finishing options are applied to copies while "multiple-document-handling" does.
Note: This RFC has been obsoleted by RFC3761
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.
Errata ID: 2499
Status: Held for Document Update
Type: Editorial
Reported By: Tony Hansen
Date Reported: 2010-08-23
Held for Document Update by: Peter Saint-Andre
Section 2 and 3 says:
[DRUMS]
It should say:
[RFC2822]
Notes:
When going from draft-chandhok-listid-04.txt to the RFC, various references were updated. The [DRUMS] reference to 2822 was updated to [RFC2822] within the References section, but was not changed within the text.
Errata ID: 361
Status: Rejected
Type: Editorial
Reported By: Trish Lynch
Date Reported: 2002-08-08
Rejected by: Alexey Melnikov
Date Rejected: 2010-05-11
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.
--VERIFIER NOTES--
Header field names are case insensitive per use of string literals from RFC 2234.
Note: This RFC has been obsoleted by RFC4560
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)."
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 ) )
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
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
Note: This RFC has been obsoleted by RFC6265
Source of RFC: http (app)
Errata ID: 2644
Status: Verified
Type: Technical
Reported By: Loïc Etienne
Date Reported: 2010-11-23
Verifier Name: Peter Saint-Andre
Date Verified: 2011-05-16
Section 3.3.4 says:
port = "$Port" [ "=" <"> value <"> ]
It should say:
port = "$Port" [ "=" <"> portlist <"> ]
Notes:
<value> is too general, possibly being itself a <quoted-string> (resulting in a twofold quoted string).
The suggested change would agree with the definition on page 5, section 3.2.2: "Port" [ "=" <"> portlist <"> ]
Errata ID: 1491
Status: Verified
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2008-08-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02
Section 12 says:
[Netscape] "Persistent Client State -- HTTP Cookies", available at
<http://www.netscape.com/newsref/std/cookie_spec.html>,
undated.
It should say:
[Netscape] "Persistent Client State -- HTTP Cookies", available at
<http://www.netscape.com/newsref/std/cookie_spec.html>,
undated.
Copy avalaible at <http://curl.haxx.se/rfc/cookie_spec.html>
Notes:
The original URL at www.netscape.com, so it would be good to point readers to an available copy of the document.
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.
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
Note: This RFC has been obsoleted by RFC6298
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.
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.
Note: This RFC has been obsoleted by RFC3530
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.
Note: This RFC has been obsoleted by RFC3525
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"
Errata ID: 2047
Status: Held for Document Update
Type: Editorial
Reported By: cloengard
Date Reported: 2010-02-21
Held for Document Update by: Wes Eddy
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
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"?>
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,
Note: This RFC has been obsoleted by RFC5228 RFC5429
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: Verified
Type: Technical
Reported By: Costin Chirvasuta
Date Reported: 2008-08-21
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11
Section 3.1 says:
actually a separate command in terms of the grammar. However, an elsif MUST only follow an if, and an else MUST follow only either an if or an elsif. An error occurs if these conditions are not met.
It should say:
actually a separate command in terms of the grammar. However, an elsif or an else MUST only follow an if or an elsif. An error occurs if these conditions are not met.
Notes:
Peter: Fixed in RFC 5228.
Errata ID: 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.
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.
Errata ID: 2782
Status: Verified
Type: Editorial
Reported By: Valeria Elisabetta Mattavelli
Date Reported: 2011-04-18
Verifier Name: Adrian Farrel
Date Verified: 2011-04-18
Section 2.2 says:
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
It should say:
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
Notes:
Wrong text indentation
Errata ID: 2992
Status: Reported
Type: Editorial
Reported By: Bala Venkata
Date Reported: 2011-10-12
Section 3.12 says:
If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
It should say:
If the FTN maps a particular FEC to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a FEC to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
Notes:
Since FTN is used for packets that arrive unlabeled (as ILM is used for label-NHLFEs), this section should be corrected. It says that "FTN maps a particular label to a set of NHLFEs"
Errata ID: 2803
Status: Held for Document Update
Type: Editorial
Reported By: maligree
Date Reported: 2011-05-08
Held for Document Update by: Adrian Farrel
Section 3.1 says:
Ru will label with packet with label value L
It should say:
Ru will label the packet with label value L
Errata ID: 2967
Status: Held for Document Update
Type: Editorial
Reported By: fl
Date Reported: 2011-09-11
Held for Document Update by: Adrian Farrel
Section 3.20 says:
When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
It should say:
When ordered control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
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.
Errata ID: 982
Status: Verified
Type: Editorial
Reported By: Stephane Bortzmeyer
Date Reported: 2007-05-18
Verifier Name: Adrian Farrel
Date Verified: 2011-01-28
Section 2.3.2 says:
Since an ICMP message is never sent as a result of receiving an ICMP
message,
It should say:
Since an ICMP message is never sent as a result of receiving an ICMP
error message,
Notes:
As explained in RFC 1122 section 3.2.2 :
An ICMP error message MUST NOT be sent as the result of
receiving:
* an ICMP error message, or
Clearly, ICMP messages *are* sent in responce to other ICMP messages. For example, during ping processing an ICMP echo-reply message is generated as
the result of an echo-request message.
Errata ID: 2166
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-04-21
Verifier Name: Adrian Farrel
Date Verified: 2010-08-19
Section 4.2 says:
2. Data Link Layer Protocol Field
Exactly one MPLSCP packet is encapsulated in the PPP
Information field, where the PPP Protocol field indicates type
hex 8281 (MPLS).
It should say:
2. Data Link Layer Protocol Field
Exactly one MPLSCP packet is encapsulated in the PPP
Information field, where the PPP Protocol field indicates type
hex 8281 (MPLSCP).
Errata ID: 2162
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-04-15
Held for Document Update by: Adrian Farrel
Section 3.1 says:
Suppose that an unlabeled IP datagram is received at a
particular LSR, and that the the LSR pushes on a label before
forwarding the datagram. Such a datagram will be called an
Initially Labeled IP Datagram at that LSR.
It should say:
Suppose that an unlabeled IP datagram is received at a
particular LSR, and that the LSR pushes on a label before
forwarding the datagram. Such a datagram will be called an
Initially Labeled IP Datagram at that LSR.
Notes:
Doubled "the"
Note: This RFC has been obsoleted by RFC5036
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.
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.
Note: This RFC has been obsoleted by RFC4941
Source of RFC: vgmib (int)
Errata ID: 2747
Status: Rejected
Type: Editorial
Reported By: Johannes Endres
Date Reported: 2011-03-11
Rejected by: RFC Editor
Date Rejected: 2011-03-27
Section header says:
It should say:
Obsoleted by: 4941
Notes:
The "Obsoleted by" note is missing from the header, so by itself the RFC seems not to be obsolete.
--RATIONALE--
Generally, the text versions of RFCs do not include post-publication metadata (such as "Obsoleted by" or "Updated by") because this data was not available upon publication, and RFCs do not change after publication.
Post-publication metadata is available in these primary locations:
- RFC search results (http://www.rfc-editor.org/rfcsearch.html)
- RFC info pages
- RFC index (http://www.rfc-editor.org/rfc-index.html)
For this specific RFC, this information is available on all of them:
- RFC search result
- RFC info page (http://www.rfc-editor.org/info/rfc3041)
- RFC index
In addition there are HTML versions of RFCs available via tools.ietf.org; they are not maintained by the RFC Editor. They include an added header in a gray box, which shows post-publication metadata. In this case, the HTML version of RFC 3041 includes the data.
Note: This RFC has been obsoleted by RFC5577
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.
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
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: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-03-09
Held for Document Update by: Dan Romascanu
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/
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.
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.
Note: This RFC has been obsoleted by RFC5065
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].
Note: This RFC has been obsoleted by RFC4646 RFC4647
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.
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!
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
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)
Errata ID: 1454
Status: Verified
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-06-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section Appendix says:
| 2818 | X | X | | | 190 | | 2828 | | X | X | | 191 | | 2830 | X | | | | 192 | | 2831 | X | X | X | | 193 | | 2839 | | X | | | 194 | | 2846 | X | X | | | 195 | | 2853 | | X | | | 196 | | 2863 | | X | | | 197 | | 2910 | | X | X | | 198 | | 2912 | | X | X | | 199 | | 2915 | | X | | | 200 | | 2926 | | | X | | 201 | | 2942 | | X | | | 202 | | 2965 | | X | | | 203 | | 2967 | X | X | X | | 204 | | 2970 | | X | | | 205 | | 2993 | X | X | | | 206 | | 3010 | X | X | | | 207 | | 3023 | | X | | | 208 | | 3028 | | X | | | 209 | | 3075 | X | X | | | 210 | | 3080 | | X | | | 211 | | 3092 | X | X | X | X | 212 | +------+-----+-----+---------+-------+-----+ | RFC# | bar | foo | foo.bar | fubar | # |
It should say:
| 2818 | X | X | | | 190 | | 2821 | X | X | | | 191 | | 2828 | | X | X | | 192 | | 2830 | X | | | | 193 | | 2831 | X | X | X | | 194 | | 2839 | | X | | | 195 | | 2846 | X | X | | | 196 | | 2853 | | X | | | 197 | | 2863 | | X | | | 198 | | 2910 | | X | X | | 199 | | 2912 | | X | X | | 200 | | 2915 | | X | | | 201 | | 2926 | | | X | | 202 | | 2942 | | X | | | 203 | | 2965 | | X | | | 204 | | 2967 | X | X | X | | 205 | | 2970 | | X | | | 206 | | 2993 | X | X | | | 207 | | 3010 | X | X | | | 208 | | 3023 | | X | | | 209 | | 3028 | | X | | | 210 | | 3075 | X | X | | | 211 | | 3080 | | X | | | 212 | | 3092 | X | X | X | X | 213 | +------+-----+-----+---------+-------+-----+ | RFC# | bar | foo | foo.bar | fubar | # |
Notes:
RFC 2821 contains foo.com (34 occurences), bar.com (18 occurences),
bar.org (5 occurences), foo.org (4 occurences), and one foo-u.edu.
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:
Errata ID: 2319
Status: Rejected
Type: Technical
Reported By: Bruno Decraene
Date Reported: 2010-07-07
Rejected by: Adrian Farrel
Date Rejected: 2010-08-20
Section 5 says:
"A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers."
It should say:
"An eBGP speaker should not advertise this capability to another eBGP speaker unless there is a Label Switched Path (LSP) or layer two interface between the two speakers." Or just remove completely that sentence.
Notes:
1) :s/BGP/eBGP
An iBGP router should be able to set up an internal BGP session for AFI 1 / SAFI 4 toward a Route Reflector even if the Route Reflector is not capabble of forwarding MPLS packets (This case is even described in the section 2 of the RFC)
2) + layer two interface
If both router are connected by a direct (sub)interface, they should be able to exchange MPLS packets even if there is no LSP between them.
3) Remove the sentence
AFAIK, the point is now better addressed by draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt
--VERIFIER NOTES--
After discussions with the document author on the MPLS mailing list:
- The EBGP/IBGP distinction is not relevant here, as this does not properly
capture the notion of whether a BGP speaker is in the data path.
- The ability to send an MPLS packet from one router to another does not
necessarily depend on there being either a sequence of MPLS routers
between them or on there being an L2 connection between them. There might
be an L3 tunnel, for example.
Furthermore, we feel that no confusion has arisen as the result of the current text so that there is no harm in leaving it as it stands.
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
Errata ID: 2811
Status: Reported
Type: Technical
Reported By: George Barwood
Date Reported: 2011-05-21
Section 3 says:
Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
It should say:
Leading zero bytes MUST be added to the RSA/SHA1 algorithm signature so that the signature size in bytes is equal to the size of n in bytes.
Notes:
The Original Text implies that zero-padding of RSA signaturs is optional, however the underlying standard requires zero padding, http://tools.ietf.org/html/rfc2437#section-8.1.1
"4. Convert the signature representative s to a signature S of length k octets: S = I2OSP (s, k)"
where k is the length of the modulus in bytes. If the extra bytes are not added, standard RSA libraries will fail to verify the signature about 1% of the time when the padding occurs.
Note: This RFC has been obsoleted by RFC5219
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"
Errata ID: 2819
Status: Reported
Type: Editorial
Reported By: Luis MG
Date Reported: 2011-06-02
Section 3.1 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
The length field is 8 bits long, not 7. The diagram is wrong as the field should end in the 16th bit of the word.
Note: This RFC has been obsoleted by RFC5126
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
Errata ID: 1634
Status: Held for Document Update
Type: Technical
Reported By: Julian Reschke
Date Reported: 2008-12-13
Held for Document Update by: Alexey Melnikov
Date Held: 2010-11-06
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.
Mark Nottingham wrote: I don't think that deleting this section is the right answer; some interception proxies *do* prevent the introduction of new methods; it's just the text about 501 that's wrong.
Errata ID: 1879
Status: Verified
Type: Technical
Reported By: Nick Pope
Date Reported: 2009-09-15
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section 3.6 says:
Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-response or with an HTTP error.
It should say:
Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-reply or with an HTTP error.
Notes:
"application/timestamp-reply" are used in the rest parts of RFC 3161 (4 occurencies). Furthermore, known existing implementations are using
"application/timestamp-reply".
Errata ID: 2931
Status: Verified
Type: Technical
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12
Section 2.4.2 says:
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred }
It should say:
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
-- requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
-- with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred -- }
Notes:
In ASN.1 syntax 1988, all comment lines must be prefixed with double-hyphen, and comment lines followed by some content must be terminated with a double-hyphen.
Errata ID: 2932
Status: Verified
Type: Technical
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12
Section 2.4.2 says:
systemFailure (25)
-- the request cannot be handled due to system failure }
It should say:
systemFailure (25)
-- the request cannot be handled due to system failure -- }
Notes:
In ASN.1 syntax 1988, comment lines followed by content must be terminated by a double-hyphen.
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
Errata ID: 1923
Status: Rejected
Type: Technical
Reported By: Alan DeKok
Date Reported: 2009-10-22
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02
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 data types in RFC 2865.
Or even better, maintain an internally consistent set of beliefs, and leave RFC 3162 alone.
--VERIFIER NOTES--
The common terminology is known by RADIUS implementers. Every RADIUS implementor "knows what this means". i.e. "Address" in RFC 2865 means "ipaddr", and "Address" in RFC 3162 means "ipv6addr". A change now would create further confusion.
Errata ID: 330
Status: Verified
Type: Technical
Reported By: Juergen Schoenwaelder
Date Reported: 2001-09-03
Section 6 says:
SYNTAX Integer32 (1..2147483647)
It should say:
SYNTAX Integer32 (0..2147483647)
Errata ID: 2307
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-06-21
Verifier Name: Lars Eggert
Date Verified: 2010-06-29
Section 6.1 says:
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 4 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
It should say:
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 3 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
Notes:
Incorrect reference to Figure 4 of RFC 793
Errata ID: 2660
Status: Verified
Type: Editorial
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Verifier Name: Lars Eggert
Date Verified: 2011-02-03
Section header block says:
Updates: 2474, 2401, 793
It should say:
Updates: 2474, 2401, 2003, 793
Notes:
RFC 3168 updates RFC 2003 but does not indicate this in its header block.
Specifically, Section 9 of RFC 3168 defines processing of the ECN field for Encapsulated Packets. This updates RFC 2003, which specified "IP Encapsulation within IP" at a time before the ECN field was defined.
Errata ID: 2316
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-06-29
Held for Document Update by: Lars Eggert
Section 15 says:
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2409, November 1998.
It should say:
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
Notes:
Incorrect reference to RFC 2409
Note: This RFC has been obsoleted by RFC5771
Source of RFC: mboned (ops)
Errata ID: 1794
Status: Verified
Type: Technical
Reported By: Simon Perreault
Date Reported: 2009-06-17
Verifier Name: Ron Bonica
Date Verified: 2009-10-06
Section 2 says:
224.0.2.0 - 224.0.255.0 AD-HOC Block
It should say:
224.0.2.0 - 224.0.255.255 AD-HOC Block
Notes:
Section 5 mentions the AD-HOC block as being 224.0.2.0/24 - 224.0.255.0/24, which fits with the corrected text.
Furthermore, IANA has already assigned 224.0.255.0 - 224.0.255.255 for an AD-HOC usage.
Errata ID: 328
Status: Verified
Type: Technical
Reported By: Christian Staudenmayer
Date Reported: 2004-03-20
In the Reference Section, it says:
[FIPS 180-1] "Secure Hash Standard", United States of American,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 180-1, April
1993.
It should say:
[FIPS 180-1] "Secure Hash Standard", United States of America,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 180-1, April
1993.
Notes:
"United States of American" changed to "United States of America"
Errata ID: 329
Status: Verified
Type: Technical
Reported By: Ben Davis
Date Reported: 2006-06-01
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 7.2 says:
/*
* Initialize the first 16 words in the array W
*/
for(t = 0; t < 16; t++)
{
W[t] = context->Message_Block[t * 4] << 24;
W[t] |= context->Message_Block[t * 4 + 1] << 16;
W[t] |= context->Message_Block[t * 4 + 2] << 8;
W[t] |= context->Message_Block[t * 4 + 3];
}
It should say:
/*
* Initialize the first 16 words in the array W
*/
for(t = 0; t < 16; t++)
{
W[t] = (uint32_t)(context->Message_Block[t * 4]) << 24;
W[t] |= (uint32_t)(context->Message_Block[t * 4 + 1]) << 16;
W[t] |= context->Message_Block[t * 4 + 2] << 8;
W[t] |= context->Message_Block[t * 4 + 3];
}
Notes:
Note that Message_Block is an array of "integers of >= 16 bits" as described in "sha1.h" but W[] is an array of unsigned 32-bit integers.
While this works fine in many compilers, some compilers (e.g. Dynamic C v9.25) processing the line:
W[t] = context->Message_Block[t * 4] << 24;
will take the 16 bit integer "context->Message_Block[t * 4]" and shift it left 24 bits, and then assign the resulting (still) 16 bit integer to the 32 bit integer W[t].
This will lead to a different (and undesired) result than the intended behavior of first promoting the 16 bit integer "context->Message_Block[t * 4]" to a 32 bit integer, and *then* shifting that 32 bit integer left 24 times, and storing the result in W[t].
The solution is to use an explicit cast. The last two lines of code in the for loop can remain as they are, as they will not suffer from the above problem and do not need the explicit cast.
Errata ID: 327
Status: Verified
Type: Technical
Reported By: Steve Mattson
Date Reported: 2001-10-22
Section 3 says:
The IANA has allocated 223/8 as per RFC 2770 [RFC2770].
It should say:
The IANA has allocated 233/8 as per RFC 2770 [RFC2770].
Errata ID: 2958
Status: Verified
Type: Technical
Reported By: Marco Molteni
Date Reported: 2011-09-07
Verifier Name: ron bonica
Date Verified: 2011-09-09
Section 6.3 says:
6.3 Authentication (Router/PDP)
[..]
2. Verify user credential
[..]
- Kerberos: Send the Kerberos ticket to the KDC to obtain the
session key. Using the session key authenticate the user.
It should say:
Kerberos: Extract the session key from the ticket. Use the session key to authenticate the user.
Notes:
The corrected text is only an example. The most important point is that Kerberos doesn't require the server to contact the KDC, all the information is already in the kerberos authenticator and ticket sent by the client.
See this email exchange from 2001 :-) http://psg.com/lists/rap/rap.2001/msg00269.html where the same issue is raised by Hannes Tschofenig and confirmed by one of the RFC authors, R. Hess.
Note: This RFC has been obsoleted by RFC6469
Source of RFC: avt (rai)
Errata ID: 326
Status: Verified
Type: Editorial
Reported By: Stephen Casner
Date Reported: 2005-03-10
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 3.1 says:
a=fmtp:113 encode=SD-VCR/525-60
a=fmtp:113 audio=none
It should say:
a=fmtp:113 encode=SD-VCR/525-60 audio=none
Errata ID: 756
Status: Verified
Type: Editorial
Reported By: Stephen Casner
Date Reported: 2005-03-10
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 3.2 says:
a=fmtp: 112 encode=SD-VCR/525-60
a=fmtp: 112 audio=bundled
a=fmtp: 113 encode=306M/525-60
a=fmtp: 113 audio=bundled
It should say:
a=fmtp:112 encode=SD-VCR/525-60 audio=bundled
a=fmtp:113 encode=306M/525-60 audio=bundled
Notes:
from pending
Errata ID: 2924
Status: Verified
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-08-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 3.1.3.1.1 says:
The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 13 in [RFC2911] for a more complete description of each status code.
It should say:
The Printer object MUST return one of the following "status-code" values for the indicated reason. The Printer object MUST accept all document data before returning the success or error response. See Section 13 in [RFC2911] for a more complete description of each status code.
Notes:
HTTP (RFC 2616) classifies POST as a non-idempotent method, so a conforming server implementation may only return an error status or 100-continue as described in sections 8.1.2.2 and 8.2.2 of RFC 2616. Essentially, the printer cannot respond to the POST until it has processed all of the request message body, otherwise how would it report chunking or other protocol errors? And how would a client reliably send or a server reliably process multiple IPP requests (as POST messages) when a server provides an early response?
Errata ID: 3009
Status: Verified
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 7.1 says:
Connection must- must must- must "close" only. Both
if if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
It should say:
Connection must- must must- must "close" or "upgrade" only. Both
if if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
with the value "close"
for the last operation
in such a sequence,
if known. The value
"Upgrade" is used for
TLS upgrade [RFC2817].
Notes:
Implementers guide does not include support for HTTP Upgrade [RFC2817].
Errata ID: 3010
Status: Verified
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-02
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 7.1 says:
User-Agent not not
It should say:
User-Agent may not
Notes:
User-Agent identifies the client software to the Printer, which may in fact be useful for implementing workarounds, etc.
Errata ID: 325
Status: Verified
Type: Technical
Reported By: Francois Audet
Date Reported: 2001-12-13
In the Authors Address Section:
Francois Audet Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: mzonoun@nortelnetworks.com Mo Zonoun Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: audet@nortelnetworks.com
It should say:
Francois Audet Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: audet@nortelnetworks.com Mo Zonoun Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: mzonoun@nortelnetworks.com
Errata ID: 324
Status: Verified
Type: Technical
Reported By: Simon Josefsson
Date Reported: 2002-02-13
Report Text:
The document is missing a reference: </ORIG> [MIME-SEC] Galvin, J., Murphy, S., Crocker, S., and Freed, N.,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
</CORR>
Errata ID: 323
Status: Verified
Type: Technical
Reported By: Lorenzo Vicisano
Date Reported: 2002-09-17
Section 8 says:
Options:
This field encodes binary indications of the presence and
significance of any options. It also directly encodes some
options.
bit 0 set => One or more Option Extensions are present
bit 1 set => One or more Options are network-significant
Note that this bit is clear when OPT_FRAGMENT and/or
OPT_JOIN are the only options present.
bit 6 set => Packet is a parity packet for a transmission
group
of variable sized packets (OPT_VAR_PKTLEN). Only present
when
OPT_PARITY is also present.
bit 7 set => Packet is a parity packet (OPT_PARITY)
Bits are numbered here from left (0 = MSB) to right (7 =
LSB).
All the other options (option extensions) are encoded in
extensions to the PGM header.
It should say:
Options:
This field encodes binary indications of the presence and
significance of any options. It also directly encodes some
options.
bit 7 set => One or more Option Extensions are present
bit 6 set => One or more Options are network-significant
Note that this bit is clear when OPT_FRAGMENT and/or
OPT_JOIN are the only options present.
bit 1 set => Packet is a parity packet for a transmission
group
of variable sized packets (OPT_VAR_PKTLEN). Only present
when
OPT_PARITY is also present.
bit 0 set => Packet is a parity packet (OPT_PARITY)
Bits are numbered here from left (0 = MSB) to right (7 =
LSB).
All the other options (option extensions) are encoded in
extensions to the PGM header.
Errata ID: 1945
Status: Held for Document Update
Type: Editorial
Reported By: Alessandro Spinella
Date Reported: 2009-11-23
Held for Document Update by: Wes Eddy
Date Held: 2011-08-17
Section 1.2.5. says:
If receivers are several hops removed from the first PGM network element, the efficacy of NAK suppression may degrade.
It should say:
If receivers are several hops away from the first PGM network element, the efficacy of NAK suppression may degrade.
Notes:
This is simply a stylistic suggestion in the wording choice.
Errata ID: 2669
Status: Verified
Type: Editorial
Reported By: Mahesh
Date Reported: 2010-12-10
Verifier Name: Adrian Farrel
Date Verified: 2011-01-28
Section 4.3.3.1 says:
The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.
It should say:
The path between a loose node and its preceding node MAY include other network nodes that are not part of the loose node or its preceding abstract node.
Notes:
Narration incorrectly refers to "strict" node while describing "loose" node.
Errata ID: 639
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2007-10-28
Section 4.4 says:
This section contains a RC2 Key Wrap example. Intermediate values corresponding to the named items in section 4.1 are given in hexadecimal.
It should say:
This section contains a RC2 Key Wrap example. Intermediate values corresponding to the named items in section 4.1 are given in hexadecimal. In this example, the effective key length parameter for the RC2 algorithm should be 40 bits. ========================================== RC2 Effective Key Bits: 40 CEK is (16 bytes): b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 LENGTH is: 16 LCEK is (17 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 PAD is (7 bytes): 48 45 cc e7 fd 12 50 LCEKPAD is (24 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 48 45 cc e7 fd 12 50 SHA-1 Digest is (20 bytes): 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98 7e ca 48 06 ICV is (8 bytes): 0a 6f f1 9f db 40 49 88 LCEKPADICV is (32 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88 IV is (8 bytes): c7 d9 00 59 b2 9e 97 f7 KEK (16 bytes): fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05 TEMP1 (32 bytes): a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7 TEMP2 (40 bytes): c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7 TEMP3 (40 bytes): a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0 f7 97 9e b2 59 00 d9 c7 FinalIV (8 bytes): 4a dd a2 2c 79 e8 21 05 KEK (16 bytes): fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05 RESULT (40 bytes): 70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4 20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98 6c ba af b4 b2 8d 4f 35 ========================================== RC2 Effective Key Bits: 128 CEK is (16 bytes): b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 LENGTH is: 16 LCEK is (17 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 PAD is (7 bytes): 48 45 cc e7 fd 12 50 LCEKPAD is (24 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 48 45 cc e7 fd 12 50 SHA-1 Digest is (20 bytes): 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98 7e ca 48 06 ICV is (8 bytes): 0a 6f f1 9f db 40 49 88 LCEKPADICV is (32 bytes): 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88 IV is (8 bytes): c7 d9 00 59 b2 9e 97 f7 KEK (16 bytes): fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05 TEMP1 (32 bytes): 03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29 TEMP2 (40 bytes): c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29 TEMP3 (40 bytes): 29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67 66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03 f7 97 9e b2 59 00 d9 c7 FinalIV (8 bytes): 4a dd a2 2c 79 e8 21 05 KEK (16 bytes): fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05 RESULT (40 bytes): f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77 36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b c6 3b 25 de 2b f7 79 93
Notes:
The text is silent about the RC2 parameter that indicates the effective key size. This errata resolves the ambiguity.
To aid implementors, this errata includes two examples. The first one matches section 4.4 and uses a 40-bit effective key size. The second one uses a 128-bit effective key size. Many thanks to Peter Yee for generating the examples and Blake Ramsdell for checking them.
Errata ID: 322
Status: Verified
Type: Technical
Reported By: Jonathan Rosenberg
Date Reported: 2002-09-06
Section 10.3.1.1 says:
- If the LS is configured to use the MultiExitDisc attribute to
break ties, and the candidate routes differ in the value of the
MultiExitDisc attribute, then select the route that has the
lowest value of MultiExitDisc, else
- Select the route that was advertised by the external LS that
has the lowest TRIP Identifier.
It should say:
- If the LS is configured to use the MultiExitDisc attribute to
break ties, and the candidate routes differ in the value of the
MultiExitDisc attribute, then select the route that has the
highest value of MultiExitDisc, else
- Select the route that was advertised by the external LS that
has the lowest ITAD number.
Errata ID: 2634
Status: Held for Document Update
Type: Editorial
Reported By: Dale R. Worley
Date Reported: 2010-11-16
Held for Document Update by: Robert Sparks
Section 5.1.1.3 says:
PentaDecimal-routing-number = *pentadecimal-digit
- pentadecimal-routing-digit = PENTADECIMAL-DIGIT
It should say:
PentaDecimal-routing-number = *pentadecimal-digit
- pentadecimal-digit = PENTADECIMAL-DIGIT
Notes:
BNF variable "pentadecimal-routing-digit" should be "pentadecimal-digit", by analogy with section 5.1.1.2.
Note: This RFC has been obsoleted by RFC3344
Source of RFC: mobileip (int)
Errata ID: 320
Status: Reported
Type: Editorial
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
In Section 3.6.1.2 (after current page 41), insert the following text:
The Lifetime field is chosen as follows:
- If the mobile node is registering with a foreign agent, the
Lifetime SHOULD NOT exceed the value in the Registration Lifetime
field of the Agent Advertisement message received from the
foreign agent. When the method by which the care-of address is
learned does not include a Lifetime, the default ICMP Router
Advertisement Lifetime (1800 seconds) MAY be used.
- The mobile node MAY ask a home agent to delete a particular
mobility binding, by sending a Registration Request with the
care-of address for this binding, with the Lifetime field set to
zero (Section 3.8.2).
- Similarly, a Lifetime of zero is used when the mobile node
deregisters all care-of addresses, such as upon returning home.
The Home Address field MUST be set to the mobile node's home address,
if this information is known. Otherwise, the Home Address MUST be
set to zeroes.
The Home Agent field MUST be set to the address of the mobile node's
home agent, if the mobile node knows this address. Otherwise, the
mobile node MAY use dynamic home agent address resolution to learn
the address of its home agent. In this case, the mobile node MUST
set the Home Agent field to the subnet-directed broadcast address
of the mobile node's home network. Each home agent receiving such
a Registration Request with a broadcast destination address MUST
reject the mobile node's registration and SHOULD return a rejection
Registration Reply indicating its unicast IP address for use by the
mobile node in a future registration attempt.
The Care-of Address field MUST be set to the value of the particular
care-of address that the mobile node wishes to (de)register. In the
special case in which a mobile node wishes to deregister all care-of
addresses, it MUST set this field to its home address.
The mobile node chooses the Identification field in accordance with
the style of replay protection it uses with its home agent. This is
part of the mobility security association the mobile node shares with
its home agent. See Section 5.7 for the method by which the mobile
node computes the Identification field.
3.6.1.3. Extensions
This section describes the ordering of any mandatory and any optional
Extensions that a mobile node appends to a Registration Request.
This following ordering MUST be followed:
Errata ID: 321
Status: Reported
Type: Editorial
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
Section 5.7 says:
Whatever method is used, the low-order 32 bits of the Identification MUST be copied unchanged from the Registration Request to the Reply. The foreign agent uses those bits (and the mobile node's home address) to match Registration Requests with corresponding replies. of any Registration Reply are identical to the bits it sent in the Registration Request.
It should say:
Whatever method is used, the low-order 32 bits of the Identification MUST be copied unchanged from the Registration Request to the Reply. The foreign agent uses those bits (and the mobile node's home address) to match Registration Requests with corresponding replies. The mobile node MUST verify that the low-order 32 bits of any Registration Reply are identical to the bits it sent in the Registration Request.
Errata ID: 842
Status: Reported
Type: Editorial
Reported By: "Charles E. Perkins"
Date Reported: 2002-04-23
Correction 2: to be inserted before the line on page 74
starting "of any Registration..."
========================================================================
The mobile node MUST verify that the low-order 32 bits
========================================================================
It should say:
[see above]
Notes:
from pending
Errata ID: 2810
Status: Reported
Type: Editorial
Reported By: Edward Lewis
Date Reported: 2011-05-18
Section 2.1 says:
DNSSEC OK[OK] specifies how ...
It should say:
DNSSEC OK[RFC3225] specifies how ...
Notes:
Reference "link" is broken.
Errata ID: 319
Status: Verified
Type: Technical
Reported By: Derrick D. Daugherty
Date Reported: 2004-01-02
Section 4.2 says:
4.2. Name server operator requirements RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the requirements for operating DNS root servers."
It should say:
4.2. Name server operator requirements RFC 2870 (http://www.ietf.org/rfc/rfc2870.txt) describes the requirements for operating DNS root servers."
Errata ID: 318
Status: Verified
Type: Editorial
Reported By: "laercio cruvinel"
Date Reported: 2006-02-02
Section 2.1 says:
Finally, there is an additional recommendation in [6] that an EF compliant node SHOULD NOT reorder packets within a micorflow.
It should say:
Finally, there is an additional recommendation in [6] that an EF compliant node SHOULD NOT reorder packets within a microflow.
Notes:
micorflow --> microflow
Errata ID: 317
Status: Verified
Type: Technical
Reported By: Julian Reschke
Date Reported: 2003-10-11
Report Text:
The WebDAV working group maintains an errata list for RFC3253 at: http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm
Errata ID: 316
Status: Verified
Type: Technical
Reported By: RFC Editor
Date Reported: 2003-10-03
In Section 25.1:
digest-uri-value = rquest-uri ; Equal to request-uri as
specified by HTTP/1.1
It should say:
digest-uri-value = request-uri ; Equal to request-uri as
specified by HTTP/1.1
Errata ID: 1073
Status: Verified
Type: Technical
Reported By: Marco Ambu
Date Reported: 2005-12-15
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
I would like to show you an error in RFC 3261. I've discussed in SIP-implementors mailing list too. in RFC 3261 page 44 par 8.1.3.4 there is an example of URI (contact URI) with uri headers: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> I've noticed that URI header "Call-Info" has a value with characters not allowed in uri headers. The BNF says that an header value must contain characters in hnv-unreserved or unreserved or escaped but '<' and '>' are not in that set. The right example should be the following: sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1051
Status: Verified
Type: Technical
Reported By: Alexandre Machado
Date Reported: 2007-08-23
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 25.1 says:
srvr = [ [ userinfo "@" ] hostport ]
It should say:
srvr = [ [ userinfo ] hostport ]
Notes:
The character "@" should not appear in this rule since it already appears at the end of the rule "userinfo":
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
According to the use of rule "userinfo" in other rules such as "SIP-URI" and "SIPS-URI", the correct place of character "@" is really at the end of rule "userinfo" and not in all other rules using it.
Errata ID: 1470
Status: Verified
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 17.2.2 says:
If the TU passes a final response (status codes 200-699) to the server while in the "Proceeding" state, the transaction MUST enter the "Completed" state...
It should say:
If the TU passes a final response (status codes 200-699) to the server while in the "Trying" or "Proceeding" state, the transaction MUST enter the "Completed" state...
Notes:
"17.2.2 Non-INVITE Server Transaction" doesn't consider the case in which the transaction state is "Trying" and the transaction receives from the TU a final response.
It's totally possible that TU sends a final response without sending before a provisional response. Note that this case is perfectly valid in the diagram of page 139.
Errata ID: 832
Status: Held for Document Update
Type: Technical
Reported By: Marco Ambu
Date Reported: 2006-01-11
Held for Document Update by: Robert Sparks
I would like to show you an ambiguity in RFC 3261. The ABNF for SIP in RFC 3261 page 227 defines header Accept as "Accept = "Accept" HCOLON [accept-range *(COMMA accept-range)]. Expanding this form we have: Accept = "Accept" HCOLON [( (...) *(SEMI m-parameter) *(SEMI accept-param) ) *(COMMA accept-range)] For example we can have Accept: application/sdp;m_extension_parameter=value1;accept_extension_param=value2;q=0.5 We know from RFC 3261 that q is an accept-param. We don't know how to consider the first two unknown parameters: how to distinguish from m-parameter and accept-param? While in other cases RFC 3261 shows the rules to solve ambiguities (for example how to consider the parameters in a Contact URI if the URI is not enclosed in angular brackets) I have not found any suggestion for this specific case in RFC 3261.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 678
Status: Held for Document Update
Type: Technical
Reported By: Matthew S. Harris
Date Reported: 2006-08-14
Held for Document Update by: Cullen Jennings
Section 25.1 says:
On page 220, it says "The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful." (And no, I'm not talking about the "n t" typo.) The rule for TEXT-UTF8-TRIM is TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII which pretty clearly says that the final character of TEXT-UTF8-TRIM cannot be whitespace. TEXT-UTF8-TRIM appears only as the value of a header field, and the rule for message-header does not generate trailing whitespace either. So the text talks about trailing whitespace, which seems reasonable because whitespace is allowed in many other places, but the grammar does not allow it. Was trailing whitespace intended?
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1682
Status: Held for Document Update
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2009-02-10
Held for Document Update by: Robert Sparks
Section 20.7 says:
Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5432"
It should say:
Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5"
Notes:
'response' field in original example has 35 hexadecimal characters while they must be 32:
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
Errata ID: 2769
Status: Held for Document Update
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-08
Held for Document Update by: Robert Sparks
Section 17.1.2.2 says:
MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2.
It should say:
MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). Multiplier on T1 doubles with each reset so that retransmissions occur with an exponentially increasing interval that caps at T2.
Notes:
The original text doesn't clarify that the multiplier of T1 is doubled with each timer reset, so it could be understood that the maximum value the timer takes is MIN(4*T1, T2) which is 2s (so the timer would never reach 4s and the resulting intervals would be 500ms, 1s, 2s, 2s, 2s, 2s, etc).
Errata ID: 3098
Status: Held for Document Update
Type: Technical
Reported By: Alec Davis
Date Reported: 2012-01-27
Held for Document Update by: Robert Sparks
Date Held: 2012-01-27
Section 12.2.1.1 says:
A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number.
It should say:
A client could, for example, choose the 31 least significant bits of a 32-bit second clock as an initial sequence number.
Notes:
Choosing the most sig 31 bits would violate 8.1.1.5, where initial CSeq number must be less than 2**31
8.1.1.5: The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31.
REVIEWER NOTE (rjsparks@nostrum.com) : It was explicitly the intent to point to the most significant bits. The confusion in this report is not recognizing that the intent is to treat those as a 31-bit integer (which by definition will be less than 2**31). Rather than reject the errata, I'm putting this in hold for document update so future revisions can clarify the point.
Errata ID: 3102
Status: Held for Document Update
Type: Technical
Reported By: Alec Davis
Date Reported: 2012-02-01
Held for Document Update by: Robert Sparks
Section 12.2.1.1 says:
With a length of 32 bits, a client could generate, within a single
call, one request a second for about 136 years before needing to
wrap around. The initial value of the sequence number is chosen
so that subsequent requests within the same call will not wrap
around.
It should say:
With a length of 32 bits, a client could generate, within a single
call, one request a second for about 136 years before exhausting
available sequence numbers. Sequence numbers must not wrap around to 0.
The initial value of the sequence number (less than 2**31) is chosen
so that subsequent requests within the same call will not exceed 2**32-1.
Notes:
Highlight that within a dialog sequence numbers;
1). can increment to 2**32-1
2). must not wrap around to 0
Errata ID: 1742
Status: Rejected
Type: Technical
Reported By: Pankaj Jain
Date Reported: 2009-03-25
Rejected by: Robert Sparks
Date Rejected: 2010-05-23
Section 17.1.1.2 says:
Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used.
It should say:
Timer D reflects the amount of time that the client transaction can remain in the "Completed" state when unreliable transports are used.
Notes:
server transaction => client transaction
--VERIFIER NOTES--
The original text is correct. The value (and reason) for timer D is to reflect what's happening in the server transaction. See the discussion of Timer H that immediately follows the text quoted above.
Errata ID: 2910
Status: Rejected
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2011-08-02
Rejected by: Robert Sparks
Date Rejected: 2011-11-04
Section Table 2 says:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
It should say:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - m - -
Notes:
RFC 3261 says:
Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."
Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."
So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.
However Table 2 (page 162) says:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
Record-Route 2xx,18x mr - o o o o -
Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).
--VERIFIER NOTES--
1xx also includes 100 Trying, which cannot establish a Dialog. Contact is not mandatory in 100 Trying responses.
Errata ID: 2051
Status: Verified
Type: Editorial
Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23
Section 26.3.1 says:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
It should say:
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to the DNS name other SIP devices will use to reach them.
Notes:
The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.
Errata ID: 1471
Status: Held for Document Update
Type: Editorial
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks
Section 17 says:
Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response.
It should say:
Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response excepting a 2xx response.
Notes:
"accepting a 2xx response" => "excepting a 2xx response"
Errata ID: 1472
Status: Held for Document Update
Type: Editorial
Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks
Section 25.1 says:
The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings,
It should say:
The TEXT-UTF8-TRIM rule is used for descriptive field contents that are not quoted strings,
Notes:
"are n t" => "are not"
Errata ID: 315
Status: Verified
Type: Technical
Reported By: Steve Conner
Date Reported: 2002-07-04
Report Text:
This document obsoletes RFC 2543.
Errata ID: 2098
Status: Held for Document Update
Type: Technical
Reported By: Parveen Verma
Date Reported: 2010-03-30
Held for Document Update by: Robert Sparks
Section 10 says:
10.1 Basic Exchange Assume that the caller, Alice, has included the following description in her offer. It includes a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). The offered SDP is: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
It should say:
10.1 Basic Exchange Assume that the caller, Alice, has included the following description in her offer. It includes a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). The offered SDP is: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s=- c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
Notes:
The s= session name must have some values as per RFC 4566 Sec 5.3.
----------------------------------------------------------------
RFC 4566
5.3. Session Name ("s=")
s=<session name>
The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e., a single space as the session name).
----------------------------------------------------------------
RFC 3264 also states in Section 5
"Unfortunately, SDP does not allow the "s=" line to be empty."
Even if we put "s= " , it becomes a bit difficult to read/understand in soft/printed copy.
The same error applies to all SDP examples given in Section 10
Errata ID: 2099
Status: Held for Document Update
Type: Technical
Reported By: Brett Tate
Date Reported: 2010-03-30
Held for Document Update by: Robert Sparks
Section 9 says:
v=0 o=carol 28908764872 28908764872 IN IP4 100.3.6.6 s=- t=0 0 c=IN IP4 192.0.2.4 m=audio 0 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 0 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 Figure 1: SDP Indicating Capabilities
It should say:
v=0 o=carol 28908764872 28908764872 IN IP4 100.3.6.6 s=- c=IN IP4 192.0.2.4 t=0 0 m=audio 0 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 0 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 Figure 1: SDP Indicating Capabilities
Notes:
Location of "c=" line is invalid per RFC 2327 and RFC 4566. The corrected text reflects the "c=" line within a valid location.
Errata ID: 314
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2002-07-23
In the Header:
Updates: 2543
It should say:
Updates: 3261
Note: This RFC has been obsoleted by RFC4566
Source of RFC: mmusic (rai)
Errata ID: 313
Status: Verified
Type: Editorial
Reported By: Bernie Hoeneisen
Date Reported: 2004-01-15
Section 1 refers to RFC 2328 as follows:
Accordingly, the address type "IP6" indicating an IPv6 address,
should be allowed in the connection field, "c=", of the SDP. The
ABNF already reflects this, though the "Connection Data" text under
section 6 of RFC 2328 currently only defines the "IP4" address type.
^^^^
It should refer to RFC 2327.
Note: This RFC has been obsoleted by RFC4867
Source of RFC: avt (rai)
Errata ID: 312
Status: Verified
Type: Technical
Reported By: Frederic Turgis
Date Reported: 2002-07-29
Section 5.3 says:
The FT field and the Q bit are defined in the same way as in Section 4.1.2. The P bits are padding and MUST be set to 0.
It should say:
The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0.
Errata ID: 1910
Status: Reported
Type: Editorial
Reported By: Francois Le Faucheur
Date Reported: 2009-10-13
Section 5.2.1 says:
MAPnb : 4 bits
Indicates the number of MAP entries included in the DIFFSERV
Object. This can be set to any value from 0 to 8.
It should say:
MAPnb : 4 bits
Indicates the number of MAP entries included in the DIFFSERV
Object. This can be set to any value from 0 to 7.
Notes:
This errata was reported by Colors Springfield <springfieldcolors@gmail.com> on 13 October 2009.
Errata ID: 310
Status: Verified
Type: Technical
Reported By: Robert deMallac
Date Reported: 2002-07-31
Section 1 says:
Internet is for everyone - but it won't be if it cannot keep up with the explosive demand for its services, so we must dedicate ourselves to continuing its technological evolution and development of the technical standards the lie at the heart of the Internet revolution.
It should say:
Internet is for everyone - but it won't be if it cannot keep up with the explosive demand for its services, so we must dedicate ourselves to continuing its technological evolution and development of the technical standards that lie at the heart of the Internet revolution.
Errata ID: 311
Status: Verified
Type: Editorial
Reported By: vinton g. cerf"
Date Reported: 2002-08-01
Verifier Name: Russ Housley
Date Verified: 2010-04-12
Section 3 says:
Internet is for everyone - but it won't be if it cannot keep up with the explosive demand for its services, so we must dedicate ourselves to continuing its technological evolution and development of the technical standards the lie at the heart of the Internet revolution.
It should say:
Internet is for everyone - but it won't be if it cannot keep up with the explosive demand for its services, so we must dedicate ourselves to continuing its technological evolution and development of the technical standards that lie at the heart of the Internet revolution.
Errata ID: 309
Status: Verified
Type: Technical
Reported By: Jean-Michel Grimaldi
Date Reported: 2002-06-18
Section 4.2.2 says:
The Internet evolved from the APARNET and adopted dynamic routing algorithms with distributed control to determine the paths that packets should take en-route to their destinations.
It should say:
The Internet evolved from the ARPANET and adopted dynamic routing algorithms with distributed control to determine the paths that packets should take en-route to their destinations.
Errata ID: 308
Status: Verified
Type: Technical
Reported By: Joseph Reagle
Date Reported: 2002-04-18
Report Text:
A list of errata can be found at: http://www.w3.org/2001/10/xmldsig-errata
Errata ID: 307
Status: Verified
Type: Technical
Reported By: Olivier Dierick
Date Reported: 2005-08-01
Section 1 says:
This document specifies algorithm identifiers and ASN.1 [X.660] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).
It should say:
This document specifies algorithm identifiers and ASN.1 [X.690] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).
Notes:
In Section 4, it says:
[X.660] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
It should say:
[X.690] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
Errata ID: 2048
Status: Verified
Type: Technical
Reported By: Jim Wigginton
Date Reported: 2009-10-12
Verifier Name: Pasi Eronen
Date Verified: 2010-02-22
Section 2.3.5 says:
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(1) }
It should say:
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(3) }
Notes:
Note that this bug is only in Section 2.3.5; the ASN.1 module in Section 3 has the correct OID.
Errata ID: 1909
Status: Held for Document Update
Type: Editorial
Reported By: Jim Wigginton
Date Reported: 2009-10-12
Held for Document Update by: Pasi Eronen
Date Held: 2010-02-22
Throughout the document, when it says:
Notes:
Replace "ansi-X9.62" with "ansi-X9-62" in Section 2.3.5.
Replace "id-public-key-type" with "id-publicKeyType" in Section 2.3.5.
Replace "sha-1WithRSAEncryption" with "sha1WithRSAEncryption" in Section 2.2.2.
Note: This RFC has been obsoleted by RFC5280
Source of RFC: pkix (sec)
Errata ID: 305
Status: Verified
Type: Technical
Reported By: Takashi Ito
Date Reported: 2002-11-11
Section 6.3.3 says:
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
It should say:
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:
(l) Set the reasons_mask state variable to the union of
its previous value and the value of the interim_reasons_mask
state variable.
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
Errata ID: 306
Status: Verified
Type: Technical
Reported By: Olivier Dierick
Date Reported: 2005-08-01
Section 7 says:
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
[X.690] ITU-T Recommendation X.690 Information Technology - Open
Systems Interconnection - Procedures for the operation of
OSI Registration Authorities: General procedures, 1992.
It should say:
[X.660] ITU-T Recommendation X.660 Information Technology - Open
Systems Interconnection - Procedures for the operation of
OSI Registration Authorities: General procedures, 1992.
[X.690] ITU-T Recommendation X.690 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
Errata ID: 2858
Status: Held for Document Update
Type: Editorial
Reported By: Jaime Hablutzel
Date Reported: 2011-07-12
Held for Document Update by: Sean Turner
Section 4.1.2.4 says:
Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows:
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and and the old
name encoding as subject, or vice-versa.
It should say:
Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows:
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and the old
name encoding as subject, or vice-versa.
Notes:
there is a duplicate 'and'
Note: This RFC has been obsoleted by RFC5755
Source of RFC: pkix (sec)
Errata ID: 304
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2002-07-30
Section 7.1 says:
The AC then contains the ciphertext inside its signed data. The
EnvelopedData (id-envelopedData) ContentType is used, and the
content field will contain the EnvelopedData type.
It should say:
Within EnvelopedData, the encapuslatedContentInfo identifies the
content type carried withing the ciphertext. In this case, the
contentType field of encapsulatedContentInfo MUST contain
id-ct-attrCertEncAttrs, which has the following value:
attrCertEncAttrs OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9)
id-smime(16) id-ct(1) 14 }
Notes:
Errata ID: 302
Status: Verified
Type: Technical
Reported By: Stephen Farrell
Date Reported: 2003-03-07
Section 4.4.6 says:
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
It should say:
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Notes:
The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.
Errata ID: 1479
Status: Verified
Type: Technical
Reported By: Kurt Zeilenga
Date Reported: 2008-07-30
Verifier Name: Tim Polk
Date Verified: 2008-11-20
Section 4.4.6 says:
SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
It should say:
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
Notes:
It appears an error in the definition of SecurityCategory was introduced when it was taken from a module with EXPLICIT TAG default into a module with IMPLICIT TAG default. In particular, the tag on the value MUST be EXPLICIT due to the ANY. Otherwise the tag of the any would replace the value's tag.
Note that extra IMPLICIT in the original text is merely extraneous (whereas the missing EXPLICIT is quite problematic).
It is also noted that clearance was NOT defined in X.501(1993), but X.500(1997). However, X.501(2005) may be the best reference for clearance.
Errata ID: 303
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2004-08-26
Section 4.1 says:
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion -- version is v2,
It should say:
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2,
Errata ID: 710
Status: Verified
Type: Editorial
Reported By: Gidon Moont
Date Reported: 2006-12-20
Verifier Name: Stephen Farrell
Date Verified: 2006-12-21
Section 4.3.2 says:
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF Targets". Conforming AC issuer implementations MUST only produce one "Targets" element. Confirming AC users MUST be able to accept a "SEQUENCE OF Targets". If more than one Targets element is found in an AC, the extension MUST be treated as if all Target elements had been found within one Targets element.
It should say:
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF Targets". Conforming AC issuer implementations MUST only produce one "Targets" element. Conforming AC users MUST be able to accept a "SEQUENCE OF Targets". If more than one Targets element is found in an AC, the extension MUST be treated as if all Target elements had been found within one Targets element.
Notes:
Confirming -> Conforming
Errata ID: 2976
Status: Reported
Type: Technical
Reported By: Ina Singh
Date Reported: 2011-09-21
Section 3.4.5. says:
diffServRandomDropInvProbMax represents Pmax (inverse). This MIB does not represent Pmin (assumed to be zero unless otherwise represented). In addition, since message memory is finite, queues generally have some upper bound above which they are incapable of storing additional traffic. Normally this number is equal to Qclip, specified by diffServAlgDropQThreshold.
It should say:
The average queue depth beyond which traffic has a probability
indicated by diffServRandomDropProbMax of being dropped or
marked. Note that this differs from the physical queue limit,
which is stored in diffServAlgDropQThreshold.
Notes:
diffServRandomDropInvProbMax should be removed
Attaching the e-mail confirmation from Fred :
==============================================
From: Fred Baker (fred)
Sent: Tuesday, September 20, 2011 10:54 PM
To: Ina Singh (inasingh)
Subject: Re: RFC3289/DiffesrvMIB SFS
Thanks for pointing this out. Correct me if I'm wrong; it looks to me like diffServRandomDropInvProbMax only shows up in the comment in section 3.4.5, and diffServRandomDropProbMax is used throughout the MIB. Yes, the comment should be fixed, but the MIB is itself correct with diffServRandomDropProbMax. Correct?
The right thing to do is file an erratum against RFC 3289, so that if it is edited in the future the error can be picked up, and implementers can see it.
http://www.ietf.org/iesg/statement/errata-processing.html describes the process.
On Sep 20, 2011, at 6:50 PM, Ina Singh (inasingh) wrote:
> Hey Fred,
>
> While implementing RFC3289/DiffesrvMIB SFS recently on IOS, we noticed the following error :
> It would seem that diffServRandomDropInvProbMax was replaced by
> diffServRandomDropProbMax (?) , but the reference to “diffServRandomDropInvProbMax” was not removed on subsequent versions.
>
> Can you please confirm, if so, what’s the procedure to correct it ..
>
> Thanks in advance for your help in this and appreciate your time..
>
> Ina
>
> Definition of "diffServRandomDropInvProbMax" upto version 7, here is a link for draft version 6.
>
> http://tools.ietf.org/html/draft-ietf-diffserv-mib-06
>
> iffServRandomDropInvProbMax OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed as
> the inverse of the drop probability. With special
> case of the value zero meaning zero probability of
> drop.
>
> For example, if every packet may be dropped in the
> worst case (100%), this has the value of
> 4,294,967,295."
> ::= { diffServRandomDropEntry 6 }
>
>
>
> In contrast to "diffServRandomDropProbMax" starting from version 8.
>
>
> diffServRandomDropProbMax OBJECT-TYPE
>
> SYNTAX Unsigned32 (0..1000)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed in drops per
> thousand packets.
>
> For example, if in the worst case every arriving packet may be
> dropped (100%) for a period, this has the value 1000.
> Alternatively, if in the worst case only one percent (1%) of
> traffic may be dropped, it has the value 10."
> ::= { diffServRandomDropEntry 6 }
Errata ID: 300
Status: Verified
Type: Editorial
Reported By: Tom Irwin
Date Reported: 2002-08-08
Report Text:
In the process of implementing the RFC 3289 DiffServ MIB, the following errors and discrepancies were noted. 1. In the diffServClfrTable description (second paragraph), diffServClfrStatus should be diffServClfrStorage. This is an understandability issue. 2. The diffServClfrElementStatus description indicates that this entry cannot be deleted if there is a RowPointer pointing to it. A RowPointer is not used to select a classifier element, but rather the diffServClfrId and diffServClfrElementId index values. Consequently, the diffServClfrElementTable does not require a UsageCounter or a DestroyFlag. This is an understandability issue. 3. In the diffServActionSpecific description (third paragraph) erroneously references a meter. This is an understandability issue. 4. The diffServMinRateAbsolute description indicates that zero is a valid value. The SYNTAX range indicates (1..4294967295), but should be (0..4294967295). This is an understandability issue and a MIB implementation issue. 5. The diffServMinRateRelative description indicates that zero is a valid value and that the values are in units of 1/1000 of 1. The SYNTAX range indicates (1..4294967295), but should be (0..1000). This is an understandability issue and a MIB implementation issue. 6. The diffServMaxRateAbsolute description indicates that zero is a valid value. The SYNTAX range indicates (1..4294967295), but should be (0..4294967295). This is an understandability issue and a MIB implementation issue. 7. The diffServMaxRateRelative description indicates that zero is a valid value and that the values are in units of 1/1000 of 1. The SYNTAX range indicates (1..4294967295), but should be (0..1000). This is an understandability issue and a MIB implementation issue.
Errata ID: 301
Status: Verified
Type: Editorial
Reported By: Tom Irwin
Date Reported: 2002-08-27
Report Text:
1. During implementation, there has been some confusion on the "reuse
of structural elements" in section 2.2. It is clear from the comments
and the MIB that counters cannot be effectively reused. What appears
confusing is the case when an entire (or partial) DiffServ tree used for
a specific interface ifIndex and direction is reused. Is the DiffServ
tree in this case just a template such that all of the data path
elements are replicated (counters will not work properly) for another
interface? This seems reasonable since other data path elements such as
queues and schedulers are clearly interface dependent. It is important
to remove this ambiguity since the RowPointer usage does not prohibit
this "not generally recommended" application. What is the intent?
2. Minor update in section 3.2.2:
' Differentiated Services Code Point ' to
' Differentiated Services Code Point, including "any" '
3. Figure 9b in section 3.7.2.1 is somewhat difficult at first to follow
due to how the multiplexing is shown in the Yellow "Count Action" (an
action only has a single input).
Errata ID: 299
Status: Verified
Type: Technical
Reported By: Graham Klyne
Date Reported: 2004-05-06
Section 8.1 says:
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
It should say:
Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)
Notes:
OLD:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)
In section 8.2:
OLD:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)
In section 8.3:
OLD:
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
NEW:
Date: Wed, 20 Sep 1995 00:18:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)
In section 8.4:
OLD:
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)
OLD:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
NEW:
Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)
Note: This RFC has been obsoleted by RFC3600
Source of RFC: INDEPENDENT
Errata ID: 298
Status: Verified
Type: Technical
Reported By: Siegfried Schmitt
Date Reported: 2002-11-15
Section 3.2 says:
-------- Internet Official Protocol Standards 3003 1*
It should say:
-------- Internet Official Protocol Standards 3300 1*
Errata ID: 1579
Status: Verified
Type: Editorial
Reported By: Randy Bush
Date Reported: 2008-10-27
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 4 says:
4. Security Coniderations
It should say:
4. Security Considerations
Errata ID: 2780
Status: Reported
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Section TOC says:
2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 2
It should say:
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . 2
Errata ID: 983
Status: Verified
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2007-05-25
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 5 says:
[MCFW] Srisuresh, S., Kuthan, J., Rosenberg, J., Molitor, A. and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, Date.*
It should say:
[MCFW] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
Notes:
from pending
Errata ID: 297
Status: Verified
Type: Editorial
Reported By: Tom Petch
Date Reported: 2005-10-10
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-11
Section 3.2.1 says:
* 'issn' defined by "Using The ISSN as URN within an ISSN-URN
Namespace" (RFC 3043) [4]
It should say:
* 'issn' defined by "Using The ISSN as URN within an ISSN-URN
Namespace" (RFC 3044) [4]
Errata ID: 1375
Status: Held for Document Update
Type: Editorial
Reported By: K. Ohwashi
Date Reported: 2008-03-20
Held for Document Update by: Peter Saint-Andre
Section 5 says:
1. The W3C and IETF should jointly develop and endorse a model for
URIs, URLs, and URNs consistent with the "Contemporary View"
described in section 1, and which considers the additional URI
issues listed or alluded to in section 3.
It should say:
1. The W3C and IETF should jointly develop and endorse a model for
URIs, URLs, and URNs consistent with the "Contemporary View"
described in section 2, and which considers the additional URI
issues listed or alluded to in section 3.
Errata ID: 2787
Status: Held for Document Update
Type: Editorial
Reported By: J. Clelland
Date Reported: 2011-04-20
Held for Document Update by: Pete Resnick
Date Held: 2011-05-16
Section 3.1.1 says:
The official register of URI scheme names is maintained by IANA, at http://www.iana.org/assignments/uri-schemes.
It should say:
The official register of URI scheme names is maintained by IANA, at http://www.iana.org/assignments/uri-schemes.html.
Notes:
The iana.org web site redirects appropriately, so this can be addressed in a future revision.
Errata ID: 3117
Status: Held for Document Update
Type: Editorial
Reported By: Beis Grigorios
Date Reported: 2012-02-08
Held for Document Update by: Robert Sparks
Section 8 says:
The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.
The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown
in the example below:
m=audio 20000 RTP/AVP 0
a=des:qos failure e2e send
It should say:
The port number of every "m=" line MUST be set to zero, but the connection address is arbitrary.
The desired status line corresponding to the precondition that
triggered the failure MUST use the "failure" strength-tag, as shown
in the example below:
m=audio 0 RTP/AVP 0
a=des:qos failure e2e send
Notes:
The G711U codec's payload type 0 that appears in the m-line, probably led to the typo error with the incorrect port number (20000 instead of 0).
Errata ID: 296
Status: Reported
Type: Technical
Reported By: Shiang-Ming Huang
Date Reported: 2005-03-28
Section 1 says:
At that meeting, a decision was made to
form a design team to write a document offering advice
from the IPv6 WG to the 3GPP community, regarding
their use of IPv6.
It should say:
At that meeting, a decision was made
form a design team to write a document offering advice
from the IPv6 WG to the 3GPP community, regarding
their use of IPv6.
Errata ID: 294
Status: Reported
Type: Technical
Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Section 20.1.2 says:
The relay agent copies the source address from the IP datagram in which the message was received from the client into the peer-address field in the Relay-forward message and sets the hop-count field to the value of the hop-count field in the received message incremented by 1.
It should say:
The relay agent copies the source address from the IP datagram in which the message was received from the relay agent into the peer-address field in the Relay-forward message and sets the hop-count field to the value of the hop-count field in the received message incremented by 1.
Notes:
Errata ID: 1373
Status: Reported
Type: Technical
Reported By: Robert Marks
Date Reported: 2008-03-19
Section 22.17 says:
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
option-data An opaque object of option-len octets,
interpreted by vendor-specific code on the
clients and servers
It should say:
option-code OPTION_VENDOR_OPTS (17)
option-len 4 + length of option-data field
enterprise-number The vendor's registered Enterprise Number as
registered with IANA [6].
option-data An opaque object,
interpreted by vendor-specific code on the
clients and servers
Notes:
option-len is defined to be the size of the option-data + 4. Thus the size of option-data cannot option-len, but is actually option-len - 4.
Errata ID: 2472
Status: Reported
Type: Technical
Reported By: Ole Troan
Date Reported: 2010-08-17
Section 17.2.2 says:
If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID.
It should say:
If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes the IA containing a Status Code option with status code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. The server SHOULD include other stateful IA options (like IA_PD) and other configuration options in the Advertise message.
Errata ID: 2471
Status: Reported
Type: Technical
Reported By: Ole Troan
Date Reported: 2010-08-17
Section 17.1.3 says:
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user.
It should say:
The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user.
Errata ID: 2509
Status: Reported
Type: Technical
Reported By: Suresh Krishnan
Date Reported: 2010-09-03
Section 22.7 says:
A server MAY include an Option Request option in a Reconfigure option to indicate which options the client should request from the server.
It should say:
A server MAY include an Option Request option in a Reconfigure message to indicate which options the client should request from the server.
Notes:
There is no such thing as a "Reconfigure option". I believe that the intent was to refer to the Reconfigure message instead.
Errata ID: 2928
Status: Reported
Type: Technical
Reported By: Leaf Yeh
Date Reported: 2011-08-09
Section 17.2.1 says:
For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message, the servers discard the Solicit message.
It should say:
For example, if the administrative policy for the server is that it may only respond to a client that is willing to accept a Reconfigure message, if the client does not include a Reconfigure Accept option (see section 22.20) in the Solicit message, the servers discard the Solicit message.
Errata ID: 295
Status: Reported
Type: Editorial
Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Section 18.2.7 says:
After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with the value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Decline message for which the server has no binding information, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option.
It should say:
After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with the value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Decline message for which the server has no binding information, the server adds an IA option using the IAID from the Decline message and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option.
Errata ID: 1815
Status: Reported
Type: Editorial
Reported By: Michelle Cotton
Date Reported: 2009-07-22
Section 26 says:
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers.html.
It should say:
[6] IANA. Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers
Notes:
The URL for the enterprise numbers registry is incorrect.
Errata ID: 2778
Status: Held for Document Update
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-16
Held for Document Update by: Robert Sparks
Section 5.5.2 says:
Message sequence for INVITE using Path:
F1 Invite UA2 -> REGISTRAR
INVITE UA1@EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
It should say:
Message sequence for INVITE using Path:
F1 Invite UA2 -> REGISTRAR
INVITE sip:UA1@EXAMPLEHOME.COM SIP/2.0
Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
To: UA1 <sip:UA1@EXAMPLEHOME.COM>
From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
Call-ID: 48273181116@71.91.180.10
CSeq: 29 INVITE
Contact: <sip:UA2@71.91.180.10>
. . .
Notes:
In all the example flow the Request URI is wrong as doesn't contain the URI scheme ("sip" / "sips").
Errata ID: 2169
Status: Held for Document Update
Type: Technical
Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks
Section 4.1 says:
The 200 OK response (6) for the INVITE and the ACK (7) are also sent over the TLS connection. The ACK will contain the same Security- Verify header field as the INVITE (3).
It should say:
The 200 OK response (6) for the INVITE and the ACK (7) are also sent over the TLS connection.
Notes:
RFC3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.
RFC 3261 says (section 20) "Not applicable" means that the header
field MUST NOT be present in a request. If one is placed in a
request by mistake, it MUST be ignored by the UAS receiving the
request.
Errata ID: 2170
Status: Held for Document Update
Type: Technical
Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks
Section 4.2 says:
The second INVITE (4) and the ACK (8) contain a Security-Verify header field that mirrors the Security-Server header field received in the 421.
It should say:
The second INVITE (4) contains a Security-Verify header field that mirrors the Security-Server header field received in the 421.
Notes:
RFC 3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.
RFC 3261 says "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request."
Note: This RFC has been obsoleted by RFC5735
Source of RFC: Legacy
Errata ID: 1436
Status: Held for Document Update
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-06-12
Held for Document Update by: ronbonica
Section 3 says:
0.0.0.0/8 "This" Network [RFC1700, page 4]
10.0.0.0/8 Private-Use Networks [RFC1918]
14.0.0.0/8 Public-Data Networks [RFC1700, page 181]
24.0.0.0/8 Cable Television Networks --
39.0.0.0/8 Reserved but subject
to allocation [RFC1797]
127.0.0.0/8 Loopback [RFC1700, page 5]
128.0.0.0/16 Reserved but subject
to allocation --
169.254.0.0/16 Link Local --
172.16.0.0/12 Private-Use Networks [RFC1918]
191.255.0.0/16 Reserved but subject
to allocation --
192.0.0.0/24 Reserved but subject
to allocation --
192.0.2.0/24 Test-Net
192.88.99.0/24 6to4 Relay Anycast [RFC3068]
192.168.0.0/16 Private-Use Networks [RFC1918]
198.18.0.0/15 Network Interconnect
Device Benchmark Testing [RFC2544]
223.255.255.0/24 Reserved but subject
to allocation --
224.0.0.0/4 Multicast [RFC3171]
240.0.0.0/4 Reserved for Future Use [RFC1700, page 4]
It should say:
0.0.0.0/8 "This" Network [RFC1122, page 30]
10.0.0.0/8 Private-Use Networks [RFC1918]
14.0.0.0/8 Public-Data Networks [RFC1700, page 181]
24.0.0.0/8 Cable Television Networks --
39.0.0.0/8 Reserved but subject
to allocation [RFC1797]
127.0.0.0/8 Loopback [RFC1122, page 31]
128.0.0.0/16 Reserved but subject
to allocation --
169.254.0.0/16 Link Local --
172.16.0.0/12 Private-Use Networks [RFC1918]
191.255.0.0/16 Reserved but subject
to allocation --
192.0.0.0/24 Reserved but subject
to allocation --
192.0.2.0/24 Test-Net
192.88.99.0/24 6to4 Relay Anycast [RFC3068]
192.168.0.0/16 Private-Use Networks [RFC1918]
198.18.0.0/15 Network Interconnect
Device Benchmark Testing [RFC2544]
223.255.255.0/24 Reserved but subject
to allocation --
224.0.0.0/4 Multicast [RFC3171]
240.0.0.0/4 Reserved for Future Use [RFC1112, page 3]
Notes:
RFC 1700, page 4, does not mention 240.0.0.0/4.
Errata ID: 1425
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-05-16
Held for Document Update by: Robert Sparks
Section 3.3.4.1,p.53 says:
a)
| The SDT Identifier is a 32-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which is
supported by the MTP Level 3 at the ASP. Insignificant SDT
Identifier bits are coded 0.
b)
| The SDL Identifier is a 32-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which
is supported by the MTP Level 3 at the ASP. Insignificant SDLI
bits are coded 0.
It should say:
a)
| The SDT Identifier is a 16-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which is
supported by the MTP Level 3 at the ASP. Insignificant SDT
Identifier bits are coded 0.
b)
| The SDL Identifier is a 16-bit unsigned value which may only be
significant to 12 or 14 bits depending on the SS7 variant which
is supported by the MTP Level 3 at the ASP. Insignificant SDLI
bits are coded 0.
Notes:
In both cases, the field width "32-bit" in the text does not match
the parameter breakdown in the immediately preceding artwork.
The above corrections are based on the assumption that the figures
are correct and the text is in error.
Errata ID: 1426
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-05-16
Held for Document Update by: Robert Sparks
Section 3.3.2.6,p.35 says:
The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver echoes the content of the Heartbeat Data in a BEAT ACK message.
It should say:
The receiver of a Heartbeat message echoes the content of the Heartbeat Data field contained therein without further processing in the Heartbeat Data field of the Heartbeat Ack message.
Notes:
Apparently, the quoted text has been copied from 3.3.2.5 without
performing the appropriate rewording to accommodate the context
of 3.3.2.6 (BEAT ACK message).
Errata ID: 293
Status: Verified
Type: Editorial
Reported By: Tony Finch
Date Reported: 2005-05-26
Section 5.1 says:
The presence of optional punctuation would violate this characteristic.
It should say:
If the format allows optional punctuation or white space then this characteristic can be violated.
Notes:
In Appendix A, it says:
Time:
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
It should say:
Time:
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
/ timespec-midnight
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
In the third paragraph of Appendix A, it states "ISO 8601 is not clear on
whether an hour of 24 is permissible only if minutes and seconds are 0.
This assumes that an hour of 24 is permissible in any context."
This is clarified in the 2000 edition which says:
5.3 Time of the day
The representation of the hour by [24] is only allowed to indicate
midnight, see 5.3.2.
That would result in the following ABNF change:
time-hour = 2DIGIT ; 00-23
and additions:
timespec-midnight = "24" [[":"] "00" [[":"] "00"]]
timespec-base =/ timespec-midnight
Errata ID: 1584
Status: Verified
Type: Editorial
Reported By: Roberto Javier Godoy
Date Reported: 2008-11-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section Appendix A says:
Note that due to ambiguities in ISO 8601, some interpretations had to be made. First, ISO 8601 is not clear if mixtures of basic and extended format are permissible. This grammar permits mixtures.
It should say:
This grammar permits mixtures of basic and extended format.
Notes:
ISO 8601:2000 section 5.4.2 reads:
d) the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format, in which case additional separators shall be used in accordance with 5.2 and 5.3.
(There is similar text in section 4.3.3 of ISO 8601:2004)
Note: This RFC has been obsoleted by RFC5944
Source of RFC: mobileip (int)
Errata ID: 1482
Status: Rejected
Type: Technical
Reported By: Keshav Chawla
Date Reported: 2008-08-06
Rejected by: Jari Arkko
Date Rejected: 2010-04-15
Section 1.10 says:
1.10. Long Extension Format This format is applicable for non-skippable extensions which carry information more than 256 bytes.
It should say:
1.10. Long Extension Format This format is applicable for any extension (skippable or non-skippable) which carry information more than 256 bytes.
Notes:
As per description in 1.11
" This format is compatible with the skippable extensions defined in
section 1.9. It is not applicable for extensions which require more
than 256 bytes of data; for such extensions, use the format described
in section 1.10."
However 1.10 specifies that it is applicable to only non-skippable extensions, so what would be the format for skippable extensions of size more than 256 bytes?
The correction will specify that any extension (skippable or non-skippable) shall use long format if its length is more than 256 bytes.
--VERIFIER NOTES--
Pete McCann, chair of MIP4 held a discussion about this in the WG and the conclusion was that the errata should be rejected.
Errata ID: 2020
Status: Verified
Type: Editorial
Reported By: Barry Leiba
Date Reported: 2010-01-26
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10
Section 3 says:
In some instances a server that supports the CHILDREN extension MAY NOT be able to determine whether a mailbox has children.
It should say:
In some instances a server that supports the CHILDREN extension might not be able to determine whether a mailbox has children.
Notes:
The "may not" in this sentence is not normative text, but is just a statement of fact. It should not be rendered as an RFC 2119 term.
Errata ID: 1544
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Stewart Bryant
Section Abstract says:
| ... This document summarizes all Table,
Length and Value (TLV) codepoints [...]
^^^^^
It should say:
| ... This document summarizes all Type,
Length and Value (TLV) codepoints [...]
^^^^
Notes:
Rationale: wrong acronym expansion
If accepted, please update the RFC's Abstract in the full RFC index.
Errata ID: 1680
Status: Reported
Type: Technical
Reported By: John Klensin
Date Reported: 2009-02-09
Section "Bitlabels" says:
addresses, it proposes to use a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS.
It should say:
addresses, it proposes to use a new kind of DNS label (a "bit label"), specified in [RFC2673], to represent binary addresses directly in the DNS. *** RFC 2673 should also appear in the References section.***
Notes:
This document is listed as updating RFC 2673. That claim is actually dubious, since it simply explains why one particular application of 2673 may not be appropriate, an application that is not even mentioned in 2673 itself. But, if it does actually update 2673, then it should be possible for the reader to deduce how the two document interact without extensive detective work.
An alternative fix would be to remove the entry indicating updating of 2673 from the header of this document and corresponding indexes and references -- what this actually updates is 2874, which specifies a particular application of 2673.
Note: This RFC has been obsoleted by RFC3852
Source of RFC: smime (sec)
Errata ID: 292
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2003-01-23
Section 13 says:
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3269, August 2002.
It should say:
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
Errata ID: 291
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2003-03-03
Several object identifiers (OIDs) have been omitted from the ASN.1 module in section 12.1; however, these OIDs are fully discussed in the body of the document. On page 46 of RFC 3369, the following object identifiers need to be inserted before the end o
-- Content Type Object Identifiers
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
Errata ID: 290
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2004-03-12
Section 12.2 says:
AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
Notes:
The tagging should be EXPLICIT instead of IMPLICIT.
Errata ID: 289
Status: Verified
Type: Technical
Reported By: Henning Schulzrinne
Date Reported: 2003-05-13
Section 8 says:
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3269,
August 2002.
It should say:
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3369,
August 2002.
Errata ID: 1840
Status: Held for Document Update
Type: Editorial
Reported By: Russ Housley
Date Reported: 2009-08-25
Held for Document Update by: Sean Turner
Section 8 says:
[PKCS#1] Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC
2437, October, 1998.
It should say:
[PKCS#1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
RFC 2313, March 1998.
Errata ID: 288
Status: Verified
Type: Technical
Reported By: Feng Zhang
Date Reported: 2002-09-22
Report Text:
References to Figures 3, 5, and 7 should refer to Figures 2, 3, and 4, respectively.
Errata ID: 770
Status: Rejected
Type: Technical
Reported By: Rajesh Garg
Date Reported: 2006-03-21
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24
Section 5.2 says:
If new query is Group and Source Specific query and there is pending response for this group and recorded source list for the group is empty (i.e. previous query was Group Specific query)
It should say:
[see note]
Notes:
In section 5.2 of RFC 3376, 5 sequential steps are given to handle the
received query from the multicast router.
I feel the following case is not handled properly in these steps (see above)
In this case, source list will be cleared as per step 4 of section 5.2.
But I feel the source list should be recorded to generate the report
accordingly.
from pending
--VERIFIER NOTES--
The RFC is correct in saying that recorded source-list should be cleared if the newly received query is group-specific query.
Errata ID: 1501
Status: Reported
Type: Editorial
Reported By: Dave Thaler
Date Reported: 2008-09-08
Section Boilerplate says:
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Obsoletes: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
It should say:
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Updates: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
Notes:
RFC 3376 does not completely replace RFC 2236, so it should say "updates" instead of "obsoletes". Specifically, to have a compliant implementation of RFC 3376 section 4, one MUST understand and implement the "Version 2 Membership Report" and "Version 2 Leave Group" messages. This is why RFC 2236 is listed as a normative reference of RFC 3376. (In general, it should be the case that one cannot obsolete a normative reference.)
Errata ID: 3092
Status: Reported
Type: Editorial
Reported By: Jon Hak Song
Date Reported: 2012-01-18
Section 6.6.3.1 says:
6.6.3.1. Building and Sending Group Specific Queries When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. When transmitting a group specific query, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
It should say:
6.6.3.1. Building and Sending Group Specific Queries When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. When a group specific query is being transmitted, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
Note: This RFC has been obsoleted by RFC4510
Source of RFC: ldapbis (app)Errata ID: 287
Status: Verified
Type: Technical
Reported By: Jeff Hodges
Date Reported: 2002-09-26
Report Text:
This document updates RFCs 2251-2256, 2829 and 2830.
Errata ID: 2983
Status: Verified
Type: Editorial
Reported By: Michael Sweet
Date Reported: 2011-10-03
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 4.1 says:
4.1 job-collation-type (type2 enum)
Job Collation includes sheet collation and document collation. Sheet
collation is defined to be the ordering of sheets within a document
copy. Document collation is defined to be the ordering of document
copies within a multi-document job. The value of the "job-
collation-type" is affected by the value of the "sheet-collate" Job
Template attribute (see section 3.1), if supplied and supported.
The Standard enum values are:
'1' 'other': not one of the defined values
'2' 'unknown': the collation type is unknown
'3' 'uncollated-sheets': No collation of the sheets within each
document copy, i.e., each sheet of a document that
is to produce multiple copies, is replicated before
the next sheet in the document is processed and
stacked. If the device has an output bin collator,
the 'uncollated-sheets(3)' value may actually
It should say:
4.1 job-collation-type (type2 enum|other|unknown)
Job Collation includes sheet collation and document collation. Sheet
collation is defined to be the ordering of sheets within a document
copy. Document collation is defined to be the ordering of document
copies within a multi-document job. The value of the "job-
collation-type" is affected by the value of the "sheet-collate" Job
Template attribute (see section 3.1), if supplied and supported.
The Standard enum values are:
'3' 'uncollated-sheets': No collation of the sheets within each
document copy, i.e., each sheet of a document that
is to produce multiple copies, is replicated before
the next sheet in the document is processed and
stacked. If the device has an output bin collator,
the 'uncollated-sheets(3)' value may actually
Notes:
"other" and "unknown" are out-of-band values, per RFC 2911 section 4.1:
Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
"out-of-band" value 'unknown'. See the description of the "out-of-
band" values at the beginning of Section 4.1. Therefore, attributes
of type 'enum' start at '3'.
Errata ID: 3019
Status: Held for Document Update
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section 7.4 says:
The overall structure of the two collection values can be pictorially
represented as:
"media-col" =
{ "media-color" = 'blue';
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}
},
The full encoding is in table 5. A simplified view of the encoding
looks like this:
Table 4 - Overview Encoding of "media-col" collection
Tag Value Name Value
begCollection media-col ""
memberAttrName "" media-color
keyword "" blue
memberAttrName "" media-size
begCollection "" ""
memberAttrName "" x-dimension
integer "" 6
memberAttrName "" y-dimension
integer "" 4
endCollection "" ""
endCollection "" ""
Table 5 - Example Encoding of "media-col" collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
col" collection attribute
0x0009 name- length of (collection)
length attribute name
media-col media-col name name of (collection)
attribute
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts a new member
attribute: "media-color"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "media-color"
length keyword
media-color media-color value value is name of 1st
member attribute
0x44 keyword type value-tag keyword type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
Octets Symbolic Value Protocol comments
field
0x0004 value-
length
blue blue value value of 1st member
attribute
0x4A memberAttrName value-tag starts a new member
attribute: "media-size"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000A value- length of "media-size"
length keyword
media-size media-size value Name of 2nd member
attribute
0x34 begCollection value-tag Beginning of the "media-
size" collection attribute
which is a sub-collection
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0000 value- collection attribute names
length have no value
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts a new member
attribute: "x-dimension"
Octets Symbolic Value Protocol comments
field
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st sub-
collection member
attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0006 value value of 1st sub-
collection member
attribute
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
Octets Symbolic Value Protocol comments
field
y-dimension y-dimension value name of 2nd sub-
collection member
attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0004 value value of 2nd sub-
collection member
attribute
0x37 endCollection value-tag end of the sub-collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x37 endCollection value-tag end of the 1st collection
value in 1setOf
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
Octets Symbolic Value Protocol comments
field
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
It should say:
The overall structure of the two collection values can be pictorially
represented as:
"media-col" =
{ "media-color" = 'blue';
"media-size" =
{ "x-dimension" = 15240;
"y-dimension" = 10160
}
},
The full encoding is in table 5. A simplified view of the encoding
looks like this:
Table 4 - Overview Encoding of "media-col" collection
Tag Value Name Value
begCollection media-col ""
memberAttrName "" media-color
keyword "" blue
memberAttrName "" media-size
begCollection "" ""
memberAttrName "" x-dimension
integer "" 15240
memberAttrName "" y-dimension
integer "" 10160
endCollection "" ""
endCollection "" ""
Table 5 - Example Encoding of "media-col" collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
col" collection attribute
0x0009 name- length of (collection)
length attribute name
media-col media-col name name of (collection)
attribute
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts a new member
attribute: "media-color"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "media-color"
length keyword
media-color media-color value value is name of 1st
member attribute
0x44 keyword type value-tag keyword type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
Octets Symbolic Value Protocol comments
field
0x0004 value-
length
blue blue value value of 1st member
attribute
0x4A memberAttrName value-tag starts a new member
attribute: "media-size"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000A value- length of "media-size"
length keyword
media-size media-size value Name of 2nd member
attribute
0x34 begCollection value-tag Beginning of the "media-
size" collection attribute
which is a sub-collection
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0000 value- collection attribute names
length have no value
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts a new member
attribute: "x-dimension"
Octets Symbolic Value Protocol comments
field
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st sub-
collection member
attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x3b88 value value of 1st sub-
collection member
attribute
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
Octets Symbolic Value Protocol comments
field
y-dimension y-dimension value name of 2nd sub-
collection member
attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x27b0 value value of 2nd sub-
collection member
attribute
0x37 endCollection value-tag end of the sub-collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x37 endCollection value-tag end of the 1st collection
value in 1setOf
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
Octets Symbolic Value Protocol comments
field
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
Notes:
The "media-col" attribute was defined in PWG 5100.3 (ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf) with units consistent with RFC 3805 - namely hundredths of millimeters. However, since the example in RFC 3382 was for the same attribute, many implementers have made mistakes by using the RFC 3382 example information instead of the normative definitions in PWG 5100.3.
These changes make the example in RFC 3382 match the normative definition in PWG 5100.3.
Errata ID: 3020
Status: Held for Document Update
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section 5 says:
5 Example definition of a collection attribute In some printing environments, it is desirable to allow the client to select the media by its properties, e.g., weight, color, size, etc., instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3 keyword | name) Job Template attribute allows selection by name. It is tempting to extend the "media" attribute syntax to include "collection", but then existing clients could not understand default or supported media values that use the collection value. To preserve interoperability, a new attribute MUST BE added, e.g., "media-col (collection)". The following subsections contain a sample definition of a simplified "media-col" attribute. The definition follows the rules in section 3.
It should say:
5 Example definition of a collection attribute In some printing environments, it is desirable to allow the client to select the media by its properties, e.g., weight, color, size, etc., instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3 keyword | name) Job Template attribute allows selection by name. It is tempting to extend the "media" attribute syntax to include "collection", but then existing clients could not understand default or supported media values that use the collection value. To preserve interoperability, a new attribute MUST BE added, e.g., "media-col (collection)". The following subsections contain a sample definition of a simplified "media-col" attribute. The definition follows the rules in section 3. Note: The "media-col" attribute is normatively defined in the IPP Production Printing Attributes - Set 1 [PWG5100.3].
Notes:
Add normative reference to PWG 5100.3 which defines "media-col".
Errata ID: 3021
Status: Held for Document Update
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section 5.1.2.1 says:
5.1.2.1 x-dimension (integer(0:MAX)) This attribute identifies the width of the media in inch units along the X axis.
It should say:
5.1.2.1 x-dimension (integer(0:MAX)) This attribute identifies the width of the media in hundredths of millimeters along the X axis.
Notes:
The units for x-dimension are normatively defined as hundredths of millimeters by PWG 5100.3 to be consistent with RFC 3805.
Errata ID: 3022
Status: Held for Document Update
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section 5.1.2.2 says:
5.1.2.2 y-dimension (integer(0:MAX)) This attribute identifies the height of the media in inch units along the Y axis.
It should say:
5.1.2.2 y-dimension (integer(0:MAX)) This attribute identifies the height of the media in hundredths of millimeters along the Y axis.
Notes:
y-dimension is normatively defined as hundredths of millimeters by PWG 5100.3 to match RFC 3805.
Errata ID: 3024
Status: Held for Document Update
Type: Technical
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section Appendix A says:
Appendix A: Encoding Example of a Simple Collection (Informative)
The overall structure of the collection value can be pictorially
represented as:
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}
A simplified view of the encoding would look like this:
Table 6 - Overview Encoding of simple collection
Tag Value Name Value
begCollection media-size ""
memberAttrName "" x-dimension
integer "" 6
memberAttrName "" y-dimension
integer "" 4
endCollection "" ""
Note: "" represents a name or value whose length is 0.
Table 7 - Example Encoding of simple collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
size" collection attribute
0x000A name- length of (collection)
length attribute name
media-size media-size name name of (collection)
attribute
deBry, et. al. Standards Track [Page 22]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0006 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 23]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf for
length media-size
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0004 value value of 2nd collection
member attribute
0x37 endCollection value-tag end of the collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
It should say:
Appendix A: Encoding Example of a Simple Collection (Informative)
The overall structure of the collection value can be pictorially
represented as:
"media-size" =
{ "x-dimension" = 15240;
"y-dimension" = 10160
}
A simplified view of the encoding would look like this:
Table 6 - Overview Encoding of simple collection
Tag Value Name Value
begCollection media-size ""
memberAttrName "" x-dimension
integer "" 15240
memberAttrName "" y-dimension
integer "" 10160
endCollection "" ""
Note: "" represents a name or value whose length is 0.
Table 7 - Example Encoding of simple collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
size" collection attribute
0x000A name- length of (collection)
length attribute name
media-size media-size name name of (collection)
attribute
deBry, et. al. Standards Track [Page 22]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x3b88 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts a new member
attribute: "y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 23]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf for
length media-size
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x27b0 value value of 2nd collection
member attribute
0x37 endCollection value-tag end of the collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
Notes:
Fix examples to use correct units, per PWG 5100.3 definition.
Errata ID: 3023
Status: Held for Document Update
Type: Editorial
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section 12.1 says:
12.1 Normative References
It should say:
12.1 Normative References [PWG5100.3] K. Ocke, T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes - Set 1", ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf, February 2001
Notes:
Adding normative reference to PWG 5100.3 for media-col.
Errata ID: 3025
Status: Held for Document Update
Type: Editorial
Reported By: Michael Sweet
Date Reported: 2011-11-10
Held for Document Update by: Peter Saint-Andre
Section Appendix B says:
Appendix B: Encoding Example of 1setOf Collection (Informative)
The overall structure of the collection value can be pictorially
represented as:
"media-size-supported" =
{ "x-dimension" = 6;
"y-dimension" = 4
},
{ "x-dimension" = 3;
"y-dimension" = 5
};
A simplified view of the encoding would look like this:
Table 8 - Overview Encoding of 1setOf collection
Tag Value Name Value
begCollection media-size- ""
supported
memberAttrName "" x-dimension
integer "" 6
memberAttrName "" y-dimension
integer "" 4
endCollection "" ""
begCollection "" ""
memberAttrName "" x-dimension
integer "" 3
memberAttrName "" y-dimension
integer "" 5
endCollection "" ""
deBry, et. al. Standards Track [Page 25]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Table 9 - Example Encoding of 1setOf collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
size-supported (1setOf
collection" attribute
0x00014 name- length of (collection)
length attribute name
media-size- media-size- name name of (collection)
supported supported attribute
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 26]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0004 value- length of an integer = 4
length
0x0006 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0004 value value of 2nd collection
member attribute
0x37 endCollection value-tag end of the collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 27]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x34 begCollection value-tag beginning of the 2nd
member of the 1setOf
"sizes-avail " collection
attribute
0x0000 name- Zero length name indicates
length this is member of previous
attribute
name no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
deBry, et. al. Standards Track [Page 28]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0003 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x0005 value value of 2nd collection
member attribute
deBry, et. al. Standards Track [Page 29]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x37 endCollection value-tag end of the 1setOf
collection value
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
It should say:
Appendix B: Encoding Example of 1setOf Collection (Informative)
The overall structure of the collection value can be pictorially
represented as:
"media-size-supported" =
{ "x-dimension" = 15240;
"y-dimension" = 10160
},
{ "x-dimension" = 7620;
"y-dimension" = 12700
};
A simplified view of the encoding would look like this:
Table 8 - Overview Encoding of 1setOf collection
Tag Value Name Value
begCollection media-size- ""
supported
memberAttrName "" x-dimension
integer "" 15240
memberAttrName "" y-dimension
integer "" 10160
endCollection "" ""
begCollection "" ""
memberAttrName "" x-dimension
integer "" 7620
memberAttrName "" y-dimension
integer "" 12700
endCollection "" ""
deBry, et. al. Standards Track [Page 25]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Table 9 - Example Encoding of 1setOf collection
Octets Symbolic Value Protocol comments
field
0x34 begCollection value-tag beginning of the "media-
size-supported (1setOf
collection" attribute
0x00014 name- length of (collection)
length attribute name
media-size- media-size- name name of (collection)
supported supported attribute
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 26]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0004 value- length of an integer = 4
length
0x3b88 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x27b0 value value of 2nd collection
member attribute
0x37 endCollection value-tag end of the collection
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
deBry, et. al. Standards Track [Page 27]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x34 begCollection value-tag beginning of the 2nd
member of the 1setOf
"sizes-avail " collection
attribute
0x0000 name- Zero length name indicates
length this is member of previous
attribute
name no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
0x4A memberAttrName value-tag starts member attribute:
"x-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of "x-dimension"
length keyword
x-dimension x-dimension value name of 1st collection
member attribute
0x21 integer type value-tag attribute type
deBry, et. al. Standards Track [Page 28]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x1dc4 value value of 1st collection
member attribute
0x4A memberAttrName value-tag starts member attribute:
"y-dimension"
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x000B value- length of the "y-
length dimension" keyword
y-dimension y-dimension value name of 2nd collection
member attribute
0x21 integer type value-tag attribute type
0x0000 name- 0 indicates 1setOf
length
no name (since name-length
was 0)
0x0004 value- length of an integer = 4
length
0x319c value value of 2nd collection
member attribute
deBry, et. al. Standards Track [Page 29]
RFC 3382 IPP: The 'collection' attribute syntax September 2002
Octets Symbolic Value Protocol comments
field
0x37 endCollection value-tag end of the 1setOf
collection value
0x0000 name- defined to be 0 for this
length type, so part of 1setOf
no name (since name-length
was 0)
0x0000 value- defined to be 0 for this
length type
no value (since value-
length was 0)
Notes:
Update examples to match PWG 5100.3 definition.
Errata ID: 286
Status: Verified
Type: Technical
Reported By: Vicente Cavanna
Date Reported: 2002-11-18
Section 8.1 says:
///////////////////////////////////////////////////////////////////////
// File: CRC32_D1.v
// Date: Mon Nov 18 18:51:31 2002
//
// Copyright (C) 1999 Easics NV.
// This source file may be used and distributed without restriction
// provided that this copyright statement is not removed from the file
// and that any derivative work contains the original copyright notice
// and the associated disclaimer.
//
// THIS SOURCE FILE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS
// OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
// WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
//
// Purpose: Verilog module containing a synthesizable CRC function
// * polynomial: p(0 to 32) := "100000101111011000111011011110001"
// * data width: 1
//
// Info: jand@easics.be (Jan Decaluwe)
// http://www.easics.com
///////////////////////////////////////////////////////////////////////
module CRC32_D1;
// polynomial: p(0 to 32) := "100000101111011000111011011110001"
// data width: 1
function [31:0] nextCRC32_D1;
input Data;
input [31:0] CRC;
reg [0:0] D;
reg [31:0] C;
reg [31:0] NewCRC;
begin
D[0] = Data;
C = CRC;
NewCRC[0] = D[0] ^ C[31];
NewCRC[1] = C[0];
NewCRC[2] = C[1];
NewCRC[3] = C[2];
NewCRC[4] = C[3];
NewCRC[5] = C[4];
NewCRC[6] = D[0] ^ C[5] ^ C[31];
NewCRC[7] = C[6];
NewCRC[8] = D[0] ^ C[7] ^ C[31];
NewCRC[9] = D[0] ^ C[8] ^ C[31];
NewCRC[10] = D[0] ^ C[9] ^ C[31];
NewCRC[11] = D[0] ^ C[10] ^ C[31];
NewCRC[12] = C[11];
NewCRC[13] = D[0] ^ C[12] ^ C[31];
NewCRC[14] = D[0] ^ C[13] ^ C[31];
NewCRC[15] = C[14];
NewCRC[16] = C[15];
NewCRC[17] = C[16];
NewCRC[18] = D[0] ^ C[17] ^ C[31];
NewCRC[19] = D[0] ^ C[18] ^ C[31];
NewCRC[20] = D[0] ^ C[19] ^ C[31];
NewCRC[21] = C[20];
NewCRC[22] = D[0] ^ C[21] ^ C[31];
NewCRC[23] = D[0] ^ C[22] ^ C[31];
NewCRC[24] = C[23];
NewCRC[25] = D[0] ^ C[24] ^ C[31];
NewCRC[26] = D[0] ^ C[25] ^ C[31];
NewCRC[27] = D[0] ^ C[26] ^ C[31];
NewCRC[28] = D[0] ^ C[27] ^ C[31];
NewCRC[29] = C[28];
NewCRC[30] = C[29];
NewCRC[31] = C[30];
nextCRC32_D1 = NewCRC;
end
endfunction
endmodule
Errata ID: 285
Status: Verified
Type: Editorial
Reported By: Magnus Westerlund
Date Reported: 2004-01-22
In section 5.1, it says:
m=audio 49230 RTP/AVP 101 102
a=rtpmap:101 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:102 CN/16000
It should say:
m=audio 49230 RTP/AVP 101 102
a=rtpmap:101 G7221/16000
a=fmtp:101 bitrate=24000
^^^
a=rtpmap:102 CN/16000
Errata ID: 284
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Tim Polk
Section 2.1 says:
P[i] The ith plaintext key data block
C[i] The ith ciphertext data block
A The 64-bit integrity check register
R[i] An array of 64-bit registers where
i = 0, 1, 2, ..., n
A[t], R[i][t] The contents of registers A and R[i] after encryption
step t.
It should say:
P[i] The ith (64-bit) plaintext key data block
where i = 1, 2, ..., n
C[i] The ith (64-bit) ciphertext data block
where i = 0, 1, 2, ..., n
A The 64-bit integrity check register
R[i] An array of 64-bit registers where
i = 1, 2, ..., n
A[t], R[t][i] The contents of registers A and R[i] after encryption
step t.
Errata ID: 2580
Status: Held for Document Update
Type: Technical
Reported By: Stephen James
Date Reported: 2010-10-19
Held for Document Update by: Gonzalo Camarillo
Date Held: 2011-01-27
Section 8.1.3 says:
Item 6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts.
It should say:
Drop this statement. Section 8.1.3 item 6 should be updated to "The gateway also sends a CANCEL message to the SIP node to terminate the initiation attempt if a provisional response has been received." The situation illustrated in section 8.1.3 does not distinguish the "provisional response received" case from the "provisional response not received" case, so the commentary should cover both cases. (The specific example diagrammed shows the "no provisional response received" case.) A similar change should be made to section 8.1.4 item 7, "The REL will trigger a CANCEL request to the SIP node if a provisional response has been received." A similar change should be made to section 8.1.7 item 7, "Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node if a provisional response has been received.
Notes:
No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request."
Errata ID: 2161
Status: Held for Document Update
Type: Editorial
Reported By: Andrew Miller
Date Reported: 2010-04-13
Held for Document Update by: Robert Sparks
Section 8.2.6.1 says:
504 Version Not Supported 127 Interworking (+)
It should say:
505 Version Not Supported 127 Interworking (+)
Notes:
504 appears twice with different text. From the context, it looks like the text in the second entry is correct, and the number is wrong.
Errata ID: 2977
Status: Held for Document Update
Type: Editorial
Reported By: Jeff Dyer
Date Reported: 2011-09-21
Held for Document Update by: Robert Sparks
Section 7.2.4.1 says:
(+) If the cause location is 'user' than the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
It should say:
(+) If the cause location is 'user' then the 6xx code could be given rather than the 4xx code (i.e., 403 becomes 603)
Notes:
Than is used for comparisons. Then is used to denote something follows in sequence.
Errata ID: 2980
Status: Held for Document Update
Type: Editorial
Reported By: Pablo Varela
Date Reported: 2011-09-27
Held for Document Update by: Robert Sparks
Section 7.2 says:
+---------+
+----------------------->| Idle |<---------------------+
| +----+----+ |
| | |
| | INVITE/6.2.1 |
| V |
| T7/6.2.2 +-------------------------+ REL/6.2.4 |
+<----------------+ Trying +------------>+
| +-+--------+------+-------+ |
| CANCEL/6.2.3 | | | | |
+<----------------+ | E.ACM/ | ACM/ | CON/ANM |
| | 6.2.5 |6.2.6 | 6.2.7 |
| V | | |
| T9/6.2.8 +--------------+ | | |
+<----------+ Not alerting | | | |
| +-------+------+ | | |
| CANCEL/6.2.3 | | | | |
|<--------------+ | CPG/ | | |
| | 6.2.9 | | |
| V V | |
| T9/6.2.8 +---------------+ | REL/6.2.4 |
+<----------------+ Alerting |-|-------------------->|
|<----------------+--+-----+------+ | |
| CANCEL/6.2.3 | ^ | | |
| CPG/ | | | ANM/ | |
| 6.2.9 +--+ | 6.2.7 | |
| V V |
| +-------------------------+ REL/9.2 |
| | Waiting for ACK |------------>|
| +-------------+-----------+ |
| | |
| | ACK/6.2.10 |
| V |
| BYE/9.1 +-------------------------+ REL/9.2 |
+<----------------+ Connected +------------>+
+-------------------------+
Notes:
References in figure to 6.2 should point to 7.1.
Errata ID: 283
Status: Verified
Type: Editorial
Reported By: Olaf M. Kolkman
Date Reported: 2005-12-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02
Section 5 says:
Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]
It should say:
Part Three: The Domain Name System (DNS) Database" (RFC 3403) [2]
Errata ID: 2642
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2010-11-22
Held for Document Update by: Peter Saint-Andre
Section 4, pg. 3 says:
[[ last bullet: ]]
o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
This Application uses the DDDS to resolve any URI to a set of
endpoints or 'resolvers' that can give additional information
about the URI independent of its particular URI scheme.
It should say:
o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
This Application uses the DDDS to resolve any URI to a set of
endpoints or 'resolvers' that can give additional information
about the URI independent of its particular URI scheme.
| "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
| Assignment Procedures" (RFC 3405) [4] contains supplementary
| specification for this application and the DNS database that it
| utilizes.
Notes:
Rationale:
Missing citiation for RFC 3405 [4]; since there's no other instance
of that citation in the entire RFC, without it, the presence of
entry [4] in the References would not conform to the RFC Style Guide.
Errata ID: 2641
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2010-11-22
Held for Document Update by: Peter Saint-Andre
Section 2, 2nd para says:
| This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5]. This document will be updated and or obsoleted when changes are made to the DDDS specifications. Thus the reader is strongly encouraged to | check the IETF RFC repository for any documents that obsoletes or | updates this one.
It should say:
| This document along with RFC 3402 [1], RFC 3403 [2], and RFC 3404 [3] obsoletes RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5]. This document will be updated and or obsoleted when changes are made to the DDDS specifications. Thus the reader is strongly encouraged to check the IETF RFC repository for any documents that | update or obsolete this one.
Notes:
Rationale:
a) missing citations,
b) grammar,
c) changed order according to expected temporal order and likelyhood
and thus, to match the preceding sentence.
Errata ID: 2868
Status: Held for Document Update
Type: Editorial
Reported By: Kevin Dean
Date Reported: 2011-07-21
Held for Document Update by: Peter Saint-Andre
Section 4.1 says:
SERVICES A <character-string> that specifies the Service Parameters applicable to this this delegation path. It is up to the Application Specification to specify the values found in this field.
It should say:
SERVICES A <character-string> that specifies the Service Parameters applicable to this delegation path. It is up to the Application Specification to specify the values found in this field.
Notes:
Duplicate "this".
Errata ID: 282
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-10-05
Section 4.5 says:
See the Additional Information Processing section of RFC 3404 for more information on NAPTR records and the Additional Information section of a DNS response packet.
It should say:
See the Additional Information Processing section of RFC 3403 for more information on NAPTR records and the Additional Information section of a DNS response packet.
Notes:
wrong reference to RFC 3404 (must be RFC 3403)
Errata ID: 787
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-10-05
Section 5.1 says:
There is opportunity for significant optimization here. RFC 3404 defines that Additional Information section may be available. In this case the the SRV records may be returned as additional information for terminal NAPTRs lookups (as well as the A records for those SRVs). This is a significant optimization.
It should say:
There is opportunity for significant optimization here. RFC 3403
defines that Additional Information section may be available. In
this case the the SRV records may be returned as additional
information for terminal NAPTRs lookups (as well as the A records for
those SRVs). This is a significant optimization.
Notes:
wrong reference to RFC 3404 (must be RFC 3403)
from pending
Errata ID: 2923
Status: Held for Document Update
Type: Editorial
Reported By: Kevin Dean
Date Reported: 2011-08-05
Held for Document Update by: Peter Saint-Andre
Section 4 says:
This template defines the URI and URN Resolution DDDS Application according to the rules and requirements found in [3]. The DDDS database used by this Application is found in [4] which is the document that defines the Naming Authority Pointer (NAPTR) DNS Resource Record (RR) type.
It should say:
This template defines the URI and URN Resolution DDDS Application according to the rules and requirements found in [2]. The DDDS database used by this Application is found in [3] which is the document that defines the Naming Authority Pointer (NAPTR) DNS Resource Record (RR) type.
Notes:
Reference numbers are incorrect.
Errata ID: 2687
Status: Verified
Type: Technical
Reported By: Joe Abley
Date Reported: 2011-01-20
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20
Section 8 says:
To: register@URI.ARPA
From: The IETF URN Working Group
Key: urn
Authority: RFC2141
Record: urn IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .
It should say:
To: register@URI.ARPA
From: The IETF URN Working Group
Key: urn
Authority: RFC2141
Record: urn IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\1/i" .
Notes:
The uncorrected, original text contains a regular expression which is invalid -- it includes a back-reference \2 with no corresponding second enclosure. The correction is to make the back-reference \1, i.e. a reference to the single enclosure present in the regular expression.
Errata ID: 2688
Status: Verified
Type: Technical
Reported By: Joe Abley
Date Reported: 2011-01-20
Verifier Name: Alexey Melnikov
Date Verified: 2011-01-20
Section 4 says:
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .
It should say:
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\1/i" .
Notes:
The uncorrected, original text contains a regular expression which is invalid -- it includes a back-reference (\2) with no corresponding second enclosure. The correction is to make the back-reference \1, i.e. a reference to the single enclosure present in the regular expression.
Errata ID: 2842
Status: Rejected
Type: Technical
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-23
Rejected by: Peter Saint-Andre
Date Rejected: 2011-06-23
Section 3; 12 says:
3. Registration Policies
The creation of a given URI scheme or URN namespace id (NID) follows
the appropriate registration documents for those spaces. URI schemes
follow "Registration Procedures for URL Scheme Names" (RFC 2717)
[10]. URN namespace ids follow "URN Namespace Definition Mechanisms"
(RFC 2611) (or updates thereto) [9].
3.1 URI.ARPA Registration
3.1.1 Only Schemes in the IETF Tree Allowed
In order to be inserted into the URI.ARPA zone, the subsequent URI
scheme MUST be registered under the IETF URI tree. The requirements
for this tree are specified in [10].
[ . . . ]
[9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN
Namespace Definition Mechanisms", BCP 33, RFC 2611, October
1998.
[10] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, January 1999.
It should say:
3. Registration Policies
The creation of a given URI scheme or URN namespace id (NID) follows
the appropriate registration documents for those spaces. URI schemes
follow "Guidelines and Registration Procedures for New URI Schemes"
(RFC 4395) [10]. URN namespace ids follow "Uniform Resource Names (URN)
Namespace Definition Mechanisms" (RFC 3406) (or updates thereto) [9].
3.1 URI.ARPA Registration
3.1.1 Only Schemes in the IETF Tree Allowed
In order to be inserted into the URI.ARPA zone, the subsequent URI
scheme's specification MUST be first approved by IESG (formerly known
as IETF Tree URI schemes, per [11]).
[ . . . ]
[9] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[10] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC 4395,
February 2006.
[11] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, January 1999.
Notes:
RFC 4395 eliminated URI schemes trees; this erratum is to incorporate this change. Moreover, references are updated.
--VERIFIER NOTES--
This erratum is rejected in accordance with <http://www.ietf.org/iesg/statement/errata-processing.html>. In particular, this erratum "proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC". Therefore, "if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list".
Errata ID: 2971
Status: Rejected
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-09-15
Rejected by: Peter Saint-Andre
Date Rejected: 2011-09-15
Section n/a says:
N/A
It should say:
N/A
Notes:
This erratum report is to let the readers of RFC 3405 know that after register-uri and register-urn lists were restored in September 2011, new list archives may be found at <http://mm.icann.org/pipermail/register-uri/> and <http://mm.icann.org/pipermail/register-urn/> rather than IANA site.
--VERIFIER NOTES--
This report does not consist of an erratum against the specification.
Errata ID: 1444
Status: Verified
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-06-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02
Section 4.3 says:
Registrations may be revised by updating the RFC through standard IETF RFC update processes (see [RFC2606] for a discussion of IETF process).
It should say:
Registrations may be revised by updating the RFC through standard IETF RFC update processes (see [RFC2026] for a discussion of IETF process).
Notes:
The references (section 7) list RFC 2026, not RFC 2606, as expected.
Errata ID: 2915
Status: Rejected
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-08-04
Rejected by: Pete Resnick
Date Rejected: 2011-08-04
Section Header says:
BCP: 66
It should say:
BCP: 33
Notes:
RFC 3406 obsoletes RFC 2611, which was BCP 33. Correspondingly, RFC 3406 should be BCP 33 as well. (See also http://www.rfc-editor.org/errata_search.php?rfc=4395; this is the same situation.)
If this erratum report is approved, BCP number 66 should be retired, as BCP 115 (see link above).
--VERIFIER NOTES--
This is likely correct. However, this is because the "RFC has not been processed in accordance with the rules governing the proposed change to the RFC metadata." (See IESG statement on changes to metadata in errata.) Making the suggested change would potentially invalidate references to BCP 66. The IESG and RFC Editor should decide best course of action.
Errata ID: 3070
Status: Reported
Type: Editorial
Reported By: Marc Petit-Huguenin
Date Reported: 2011-12-28
Section 3 says:
v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 18 96 a=rtpmap:96 telephone-event a=fmtp:96 0-15,32-35 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 18 96 a=cpar: a=fmtp:96 0-16,32-35 a=cdsc: 4 image udptl t38 a=cdsc: 5 image tcp t38
It should say:
v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 18 96 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15,32-35 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 18 96 a=cpar: a=fmtp:96 0-16,32-35 a=cdsc: 4 image udptl t38 a=cdsc: 5 image tcp t38
Notes:
According to RFC 4566 section 6, the clock rate is mandatory:
"a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]"
Errata ID: 281
Status: Verified
Type: Technical
Reported By: C. M. Heard
Date Reported: 2003-01-29
Section 10.2 says:
[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
Standard Network Management Framework", RFC 2576, January 1996.
It should say:
[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
Standard Network Management Framework", RFC 1908, January 1996.
Errata ID: 1559
Status: Held for Document Update
Type: Editorial
Reported By: Carl Marcinik
Date Reported: 2008-10-11
Held for Document Update by: Dan Romascanu
Date Held: 2010-05-10
Section 6.4 says:
STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.
It should say:
STD 62, RFC 3415, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.
Notes:
--VERIFIER NOTES--
s / VCAM / VACM
Errata ID: 1560
Status: Held for Document Update
Type: Editorial
Reported By: Carl Marcinik
Date Reported: 2008-10-11
Held for Document Update by: Dan Romascanu
Section 8.2 says:
Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to insure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization’s security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly equivalent from a security point of view.
It should say:
Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to ensure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization’s security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly equivalent from a security point of view.
Notes:
The sentence used "insure" when it should have used "ensure".
Errata ID: 279
Status: Verified
Type: Technical
Reported By: Guan Hai Bing
Date Reported: 2002-12-27
Section 3.5.1.1 says:
(2) If appropriate outgoing management target information cannot be
found, the proxy forwarder increments the snmpProxyDrops
counter [RFC1907], and then calls the Dispatcher using the
returnResponsePdu abstract service interface.
It should say:
(2) If appropriate outgoing management target information cannot be
found, the proxy forwarder increments the snmpProxyDrops
counter [RFC3418], and then calls the Dispatcher using the
returnResponsePdu abstract service interface.
Notes:
In Sections 3.2 and 4.1.2:
by [RFC1905]
Should be:
by [RFC3416]
Errata ID: 280
Status: Verified
Type: Technical
Reported By: Eduardo Cardona
Date Reported: 2004-02-20
In Section 4.2.1, page 50, in DESCRIPTION clause of snmpNotifyFilterTable:
A more complete discussion of notification filtering
can be found in section 6. of [SNMP-APPL]."
It should say:
A more complete discussion of notification filtering
can be found in section 6. of RFC3413."
Notes:
Additionally, page 52, in DESCRIPTION clause of snmpNotifyFilterType:
filter. A more detailed discussion of the use of this
object can be found in section 6. of [SNMP-APPL]."
It should be:
filter. A more detailed discussion of the use of this
object can be found in section 6. of RFC3413."
Errata ID: 2459
Status: Verified
Type: Technical
Reported By: Mark Ellison
Date Reported: 2010-08-07
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02
Section 4.2.1 says:
OBJECT snmpNotifyType
SYNTAX INTEGER {
trap(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Create/delete/modify access is not required.
Support of the value notify(2) is not required."
It should say:
OBJECT snmpNotifyType
SYNTAX INTEGER {
trap(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Create/delete/modify access is not required.
Support of the value inform(2) is not required."
Notes:
the enumeration value as stated: notify(2)
the enumeration value should be: inform(2)
This appears in section 4.2.1, "Definitions" for the SNMP-NOTIFICATION-MIB spanning the page break between page 54 and 55 and contained within the snmpNotifyBasicCompliance macro.
Errata ID: 278
Status: Verified
Type: Technical
Reported By: Piotr Bandur
Date Reported: 2003-10-28
Section 6.3.1 says:
4) Prepend K2 to the result of the step 4 and calculate MD5 digest
over it according to [RFC1321]. Take the first 12 octets of the
final digest - this is Message Authentication Code (MAC).
It should say:
4) Prepend K2 to the result of the step 3 and calculate MD5 digest
over it according to [RFC1321]. Take the first 12 octets of the
final digest - this is Message Authentication Code (MAC).
Notes:
In Section 7.3.1:
4) Prepend K2 to the result of the step 4 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).
Should be:
4) Prepend K2 to the result of the step 3 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).
Errata ID: 277
Status: Verified
Type: Technical
Reported By: Guan Hai Bing
Date Reported: 2002-12-27
In Section A.1:
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC3918] (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC3918]
It should say:
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC3418] (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC3418]
Errata ID: 2757
Status: Verified
Type: Technical
Reported By: Mikhail Kulinich
Date Reported: 2011-03-27
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03
Section 3 says:
PDU ::= SEQUENCE {
request-id INTEGER (-214783648..214783647),
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
BulkPDU ::= -- must be identical in
SEQUENCE { -- structure to PDU
request-id INTEGER (-214783648..214783647),
non-repeaters INTEGER (0..max-bindings),
max-repetitions INTEGER (0..max-bindings),
variable-bindings -- values are ignored
VarBindList
}
It should say:
PDU ::= SEQUENCE {
request-id INTEGER (-2147483648..2147483647),
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
BulkPDU ::= -- must be identical in
SEQUENCE { -- structure to PDU
request-id INTEGER (-2147483648..2147483647),
non-repeaters INTEGER (0..max-bindings),
max-repetitions INTEGER (0..max-bindings),
variable-bindings -- values are ignored
VarBindList
}
Notes:
Consider the following dump as a Response to a Get Request:
Received 125 bytes from UDP: [127.0.0.1]:161->[0.0.0.0]
0000: 30 7B 02 01 03 30 11 02 04 5B 70 9B 75 02 03 00 0{...0...[p.u...
0016: FF E3 04 01 01 02 01 03 04 2E 30 2C 04 0D 80 00 ..........0,....
0032: 1F 88 80 82 0B 53 2D 67 01 8A 4D 02 01 01 02 03 .....S-g..M.....
0048: 02 7B 92 04 03 77 65 73 04 0C DF 8B 2A FE 4A C5 .{...wes....*.J.
0064: 4C 33 63 A6 2C C8 04 00 30 33 04 0D 80 00 1F 88 L3c.,...03......
0080: 80 82 0B 53 2D 67 01 8A 4D 04 00 A2 20 02 04 67 ...S-g..M... ..g
0096: DB 56 C4 02 01 00 02 01 00 30 12 30 10 06 0A 2B .V.......0.0...+
0112: 06 01 02 01 5C 01 01 01 00 42 02 03 E8 ....\....B...
NOTIFICATION-LOG-MIB::nlmConfigGlobalEntryLimit.0 = Gauge32: 1000
It was produced with the following command:
$ snmpget -v3 -n "" -c public -u wes -a md5 -A setup_passphrase -l authNoPriv -d localhost nlmConfigGlobalEntryLimit.0
While decoding (with my own tool) the message above, I met a constraint error with ASN.1 describing SNMPv3 message.
The actual issue with request-id parameter inside PDU & BulkPDU definitions.
Received value (from dump):
request-id = 1742427844
ASN.1:
request-id INTEGER (-214783648..214783647)
You can see that may be in number = 214783647, 4 is missed. I.e.: should be the following: 2147_4_83647
----------
Verifier Note:
There is indeed an error in the RFC, but the "correction" text is also incorrect.
The two changes needed are:
OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),
OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),
Errata ID: 276
Status: Verified
Type: Technical
Reported By: Glenn M. Keeni
Date Reported: 2003-08-22
In the text, it says:
6.1. Informative References
It should say:
6.2. Informative References
Errata ID: 275
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
The "short title" in the page headings, is missing an 's'. It currently says:
Internet Media Type message/ipfrag
It should say:
Internet Media Type message/sipfrag
Notes:
Errata ID: 274
Status: Verified
Type: Technical
Reported By: Ged Davies
Date Reported: 2005-06-08
In Normative References, it says:
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3265, June 2002.
It should say:
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Errata ID: 273
Status: Verified
Type: Technical
Reported By: Leslie Daigle
Date Reported: 2002-11-19
The center page header:
IAB Considerations for UNSAP Across NAT
It should say:
IAB Considerations for UNSAF Across NAT
Errata ID: 2261
Status: Held for Document Update
Type: Technical
Reported By: Brett Tate
Date Reported: 2010-05-13
Held for Document Update by: Robert Sparks
Section 10 says:
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
The message is received by user2, displayed, and a response is
generated, message F3, and sent to the proxy:
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
Note that most of the header fields are simply reflected in the
response. The proxy receives this response, strips off the top Via,
and forwards to the address in the next Via, user1pc.domain.com, the
result being message F4:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
It should say:
MESSAGE sip:user2@user2pc.domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
The message is received by user2, displayed, and a response is
generated, message F3, and sent to the proxy:
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
Note that most of the header fields are simply reflected in the
response. The proxy receives this response, strips off the top Via,
and forwards to the address in the next Via, user1pc.domain.com, the
result being message F4:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
Notes:
The corrected text changes F2's request-uri to reflect the binding.
The corrected text proxies received From tag instead of changing it.
The corrected text removes various extra semicolons show within example.
Errata ID: 2008
Status: Verified
Type: Editorial
Reported By: Minoru Teraoka
Date Reported: 2010-01-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10
Section 4 says:
exa(14), -- 10^15
peta(15), -- 10^18
It should say:
peta(14), -- 10^15
exa(15), -- 10^18
Errata ID: 2463
Status: Verified
Type: Technical
Reported By: Vishal Grover
Date Reported: 2010-08-13
Verifier Name: Robert Sparks
Date Verified: 2011-03-23
Section Appendix G says:
On Page no 206 at the bottom you will see following :
Step 2 - Delete Connection (dlcx) from ca to rgw2
Requests rgw2 to delete the connection "67890af54c9":
dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 67890af54c9
It should say:
Step 2 - Delete Connection (dlcx) from ca to rgw2
Requests rgw2 to delete the connection "67890af54c9":
dlcx 2055 aaln/1@rgw2.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 67890af54c9
Notes:
1. Need to visit Following link :
http://tools.ietf.org/rfc/rfc3435.txt
2. Go to Appendix G:
Appendix G: Example Call Flows....................................194
G.3 Connection Deletion........................................206
G.3.1 Residential Gateway to Residential Gateway.................206
3. On Page no 206 at the bottom you will see following :
Step 2 - Delete Connection (dlcx) from ca to rgw2
Requests rgw2 to delete the connection "67890af54c9":
dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 67890af54c9
it should be rgw2 i guess.
-- NOTE from reviewing AD: This change affects page 207, not page 206.
Errata ID: 1650
Status: Verified
Type: Editorial
Reported By: Adam Gleave
Date Reported: 2009-01-09
Verifier Name: Russ Housley
Date Verified: 2009-01-11
Section 4 says:
While there have been many implementations of Universal Interworking unction (UIWF), IWF approaches have been problematic at large scale. his concern is codified in the Principle of Minimum Intervention BRYANT]:
It should say:
While there have been many implementations of Universal Interworking Function (UIWF), IWF approaches have been problematic at large scale. This concern is codified in the Principle of Minimum Intervention [BRYANT]:
Notes:
First character of three lines is missing.
Note: This RFC has been obsoleted by RFC4033 RFC4034 RFC4035
Source of RFC: dnsext (int)
Errata ID: 272
Status: Reported
Type: Editorial
Reported By: "Scott Rose"
Date Reported: 2005-02-22
Values for the key protocol octet are incorrect. They should be:
VALUE Protocol
0 -reserved
1 reserved (was TLS)
2 reserved (was email)
3 dnssec
4 reserved (was IPSEC)
5-255 reserved
Notes:
Rationale: Looking at RFC2535, the values are the original assignments. The
numbers in RFC3445 are incorrect and don't match. I guess since the
registry was closed, they are all reserved now and no one double checked.
RFC 2535 has the original correct assignments, and the registry is correct
in stating that they are now all reserved.
Errata ID: 592
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.2 says:
C ciphertext to be decrypted, an octet string of length k,
where k = 2hLen + 2
It should say:
C ciphertext to be decrypted, an octet string of length k,
where k >= 2hLen + 2
Notes:
In the "Input:" section, near the top of the page, the condition
specified for 'k' is too restrictive. {This becomes clear from
the context - see e.g. 'step 1. c.' in mid-page 22.}
Errata ID: 594
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 8.2.2 says:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM' = I2OSP (m, k).
It should say:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM = I2OSP (m, k).
Notes:
In 'step 2. c.', in fact "EM" is computed, not "EM'" -- as stated
in the text; see also 'step 3.' below.
Errata ID: 595
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 9.1 says:
+-----------+
| M |
+-----------+
|
V
Hash
|
V
+--------+----------+----------+
M' = |Padding1| mHash | salt |
+--------+----------+----------+
|
+--------+----------+ V
DB = |Padding2|maskedseed| Hash
+--------+----------+ |
| |
V | +--+
xor <--- MGF <---| |bc|
| | +--+
| | |
V V V
+-------------------+----------+--+
EM = | maskedDB |maskedseed|bc|
+-------------------+----------+--+
It should say:
+-----------+
| M |
+-----------+
|
V
Hash
|
V
+--------+----------+----------+
M' = |Padding1| mHash | salt |
+--------+----------+----------+
|
+--------+----------+ V
DB = |Padding2| salt | Hash
+--------+----------+ |
| |
V | +--+
xor <--- MGF <---| |bc|
| | +--+
| | |
V V V
+-------------------+----------+--+
EM = | maskedDB | H |bc|
+-------------------+----------+--+
Notes:
Figure 2 names two fields "maskedseed" which in fact are _very_
different, and this nomenclature matches neither the figure
caption given nor the subsequent text -- see e.g. 'step 6.' and
'step 8.' on page 39 and 'step 12.' on page 40.
Errata ID: 633
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.1 says:
+----------+---------+-------+
DB = | lHash | PS | M |
+----------+---------+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+----------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+----------------------------+
It should say:
+----------+--------+--+-------+
DB = | lHash | PS |01| M |
+----------+--------+--+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+------------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+------------------------------+
Errata ID: 635
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section A.2.3 says:
* maskGenAlgorithm identifies the mask generation function. It
shall be an algorithm ID with an OID in the set
PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask
generation function is MGF1 with SHA-1. For MGF1 (and more
generally, ...
It should say:
* maskGenAlgorithm identifies the mask generation function. It
shall be an algorithm ID with an OID in the set
PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask
generation function is MGF1 with SHA-1. For MGF1 (and more
generally, ...
Notes:
The bulleted section for 'maskGenAlgorithm' contains an unexpected
blank line within the second sentence.
Errata ID: 636
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section B.1 says:
Six hash functions are given as examples for the encoding methods in this document: MD2 [33], MD5 [41], SHA-1 [38], and the proposed algorithms SHA-256, SHA-384, and SHA-512 [39].
It should say:
Six hash functions are given as examples for the encoding methods in this document: MD2 [33], MD5 [41], and the algorithms SHA-1, SHA-256, SHA-384, and SHA-512 [38'].
Notes:
RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).
The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".
Both events predate the publishing date of RFC 3447.
Therefore, the first sentence of the second paragraph on page 53 should be as noted above.
Errata ID: 638
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section F says:
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-1: Secure Hash Standard. April 1994.
[39] National Institute of Standards and Technology (NIST).
Draft FIPS 180-2: Secure Hash Standard. Draft, May 2001.
Available from http://www.nist.gov/sha/.
It should say:
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-2: Secure Hash Standard. August
2002.
Notes:
RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).
The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".
Both events predate the publishing date of RFC 3447.
The reference should be updated as noted above.
Errata ID: 2176
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2011-06-02
Section 7.1.2 says:
K recipient's RSA private key (k denotes the length in octets
of the RSA modulus n)
C ciphertext to be decrypted, an octet string of length k,
where k = 2hLen + 2
It should say:
K recipient's RSA private key (k denotes the length in octets
of the RSA modulus n), where k >= 2hLen + 2
C ciphertext to be decrypted, an octet string of length k
Notes:
k >= 2hLen + 2 belongs to K, not to C.
The >= is already reported in #592.
Errata ID: 593
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.2 says:
b. Apply the RSADP decryption primitive (Section 5.1.2) to the
RSA private key K and the ciphertext representative c to
produce an integer message representative m:
It should say:
b. Apply the RSADP decryption primitive (Section 5.1.2) to the
RSA private key K and the ciphertext representative c to
produce an integer message representative m:
Notes:
The first line of 'step 2. b.', is indented too much (by 3 chars)
Errata ID: 596
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 9.2 says:
SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
04 40 || H.
It should say:
SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
04 40 || H.
Notes:
The second line of the last example of 'Note 1.' (for SHA-512) is indented too much (by 3 chars).
Errata ID: 2582
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2010-10-20
Held for Document Update by: Sean Turner
Section 8.1.2 says:
4. If Result = "consistent," output "valid signature." Otherwise,
output "invalid signature."
It should say:
4. If Result = "consistent", output "valid signature". Otherwise,
output "invalid signature".
Notes:
This report acually addresses a previous report, EID=2177,
and provides an improved version of the corrected text.
Note to Verifier: Please merge this Errata Note with EID=2177;
i.e. update the Corrected Text there as shown above, and reject
this Errata Note.
Errata ID: 2177
Status: Rejected
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2011-06-02
Section 8.1.2 says:
4. If Result = "consistent," output "valid signature." Otherwise,
output "invalid signature."
It should say:
4. If Result = "consistent", output "valid signature", Otherwise,
output "invalid signature."
Notes:
obvious
--VERIFIER NOTES--
This is addressed in errata #2582.
Note: This RFC has been obsoleted by RFC5348
Source of RFC: tsvwg (tsv)
Errata ID: 270
Status: Verified
Type: Technical
Reported By: Joerg Widmer
Date Reported: 2003-03-04
Section 4 says:
If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half.
It should say:
If the sender does not receive a feedback report for four round trip times, it cuts its sending rate in half.
Notes:
Nofeedback timeout: Correct an inconsistency in the document.
(collected by Sally Floyd, 2004-06-11)
Errata ID: 1458
Status: Verified
Type: Technical
Reported By: Mark Handley, from Wim Heirman
Date Reported: 2003-03-13
Section 4.4, item (2) says:
If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver,
It should say:
If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, or when p == 0,
Notes:
(collected by Sally Floyd, 2004-06-11)
Errata ID: 1459
Status: Verified
Type: Technical
Reported By: Michele R.
Date Reported: 2003-04-29
Section 5.5 says:
for (i = 1 to n) {
DF_i = 1;
}
It should say:
for (i = 0 to n) {
DF_i = 1;
}
Notes:
When initializing DF, initialize from 0 to n, not from 1 to n.
(collected by Sally Floyd, 2004-06-11)
Errata ID: 806
Status: Verified
Type: Technical
Reported By: Sergiusz Wolicki
Date Reported: 2006-04-27
Section Appendix C says:
C. Prohibition tables The tables in this appendix consist of lines with one prohibited code point per line. The format of the lines are the value of the code point, a semicolon, and a comment which is the name of the code point.
It should say:
[see Notes]
Notes:
This is not true as the tables in this appendix consist of lines with
one prohibited code point _range_ per line. The format of the lines
are the value of the starting code point of the range, a hyphen,
the value of the ending code point of the range, a semicolon,
and a comment which is the informal name of the range in square brackets.
If the range contains only one code point, then the hyphen and the ending
code point value are omitted, and the comment contains the name of
the code point without brackets.
from pending
Errata ID: 2686
Status: Held for Document Update
Type: Editorial
Reported By: Jehan Pagès
Date Reported: 2011-01-20
Held for Document Update by: Alexey Melnikov
Section 3.2 says:
The list of characters to add to the mapping table can determined by the following algorithm:
It should say:
The list of characters to add to the mapping table can be determined by the following algorithm:
Notes:
A small omission of a single word: "be" is missing.
Errata ID: 269
Status: Verified
Type: Technical
Reported By: Mieke Van de Kamp
Date Reported: 2003-03-31
Section 5.2 says:
A reference is made to RFC 1123, section 2.3.3, which does not exist. The correct section in RFC 1123 is 5.3.3.
Errata ID: 686
Status: Verified
Type: Technical
Reported By: Valdis Kletniek
Date Reported: 2004-08-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06
Section 4.2 says:
The "addr-type" portion MUST be an IANA-registered electronic mail address-type (as defined in [3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document. The entire ORCPT parameter MAY be up to 500 characters in length.
It should say:
The "addr-type" portion MUST be an IANA-registered electronic mail
address-type (as defined in [3]), while the "xtext" portion contains
an encoded representation of the original recipient address using the
rules in section 4 of this document. The entire ORCPT parameter MAY
^
be up to 500 characters in length.
Notes:
xtext encoding is described in Section 4, not in Section 5
Errata ID: 2965
Status: Verified
Type: Editorial
Reported By: Bill McQuillan
Date Reported: 2011-09-09
Verifier Name: Pete Resnick
Date Verified: 2011-12-29
Section Appendix E says:
Simple DSN
This is a simple DSN issued after repeated attempts to deliver a
message failed. In this case, the DSN is issued by the same MTA from
which the message was originated.
Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
<MAILER-DAEMON@CS.UTK.EDU> Message-Id:
<199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
Version: 1.0 Content-Type: multipart/report; report-type=delivery-
status;
boundary="RAA14128.773615765/CS.UTK.EDU"
--RAA14128.773615765/CS.UTK.EDU
It should say:
Simple DSN
This is a simple DSN issued after repeated attempts to deliver a
message failed. In this case, the DSN is issued by the same MTA from
which the message was originated.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
Subject: Returned mail: Cannot send message for 5 days
To: <owner-info-mime@cs.utk.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/CS.UTK.EDU"
--RAA14128.773615765/CS.UTK.EDU
Notes:
Apparently an unintended "Reformat Paragraph" of the top level message header.
Errata ID: 695
Status: Verified
Type: Technical
Reported By: Alex Zinin
Date Reported: 2004-10-23
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
The header says:
Network Working Group L. Andersson
Request for Comments: 3468 Consultant
Category: Informational G. Swallow
Cisco Systems
February 2003
It should say:
Network Working Group L. Andersson
Request for Comments: 3468 Consultant
Updates: 3212, 3472, 3475, 3476 G. Swallow
Category: Informational Cisco Systems
February 2003
Notes:
RFC3468 documents the MPLS WG's decision to ice CR-LDP.
However, RFC3468 is not marked as updating RFC3212 (CR-LDP base spec) in the registry.
The RFCs updated by 3468 are:
3212, 3472, 3475, 3476
[Note that the RFC Editor index has been updated accordingly, but the document itself remains incorrect.]
Originally sent by Adrian Farrel.
from pending
Errata ID: 268
Status: Verified
Type: Technical
Reported By: Larry Masinter
Date Reported: 2003-04-25
Section 4.13 says:
"numeric entity reference"
It should say:
"numeric character reference"
Notes:
Section 4.16:
"In XML instances all white space is considered significant and
is by default visible to processing applications."
Should be:
"In XML instances, white space is often significant and visible
to processing applications."
Errata ID: 1977
Status: Verified
Type: Editorial
Reported By: Zongpeng Du
Date Reported: 2009-12-24
Verifier Name: Adrian Farrel
Date Verified: 2009-12-27
Section 2 says:
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3.
It should say:
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.2.
Notes:
Fix to point to correct section number.
Errata ID: 267
Status: Verified
Type: Technical
Reported By: Steve Conner
Date Reported: 2003-02-16
OLD:
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload (ESP)", RFC 2401, November 1998.
It should say:
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload (ESP)", RFC 2406, November 1998.
Errata ID: 1518
Status: Verified
Type: Technical
Reported By: Pontus Sköldström
Date Reported: 2008-09-18
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30
Section 4.2.1 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits
The IP address of the node that should be notified when generating
an error message.
o IPv6 Notify Request Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(195)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits
The IP address of the node that should be notified when generating
an error message.
o IPv6 Notify Request Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(195)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
The figures showing the format of the Notify Request objects have the wrong Class-Number (seems to have used the C-Type instead).
Errata ID: 2159
Status: Verified
Type: Editorial
Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11
Section 12 says:
Alternatively, the sending of no-hop-by-hop Notify messages can be disabled.
It should say:
Alternatively, the sending of non-hop-by-hop Notify messages can be disabled.
Notes:
r/no-hop-by-hop/non-hop-by-hop
Errata ID: 2160
Status: Verified
Type: Editorial
Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11
Section 12 says:
Configured keys MAY be used.
It should say:
Manually configured keys MAY be used.
Notes:
Assumed that this sentence is talking about the opposite of an automated key management system, which is manually configured keys.
Errata ID: 2173
Status: Verified
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2010-04-25
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11
Section TOC says:
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
It should say:
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path, PathTear and ResvConf Messages ....... 32
Notes:
The section is called "Addressing Path, PathTear and ResvConf Messages" while the TOC does not talk about ResvConf Message
Note: This RFC has been obsoleted by RFC5890 RFC5891
Source of RFC: idn (int)
Errata ID: 266
Status: Verified
Type: Technical
Reported By: Adam Costello
Date Reported: 2003-04-28
Section 4.2 says:
The ToUnicode output never contains more code points than its input. This is not true; I have constructed a counterexample.
It should say:
The Punycode decoder can never output more code points than it
inputs, but Nameprep can, and therefore ToUnicode can.
Errata ID: 265
Status: Verified
Type: Technical
Reported By: Adam Costello
Date Reported: 2003-04-28
Section 6.4 says:
where maxint is the greatest integer for which maxint + 1 cannot be represented.
It should say:
where maxint is the maximum value of an integer variable.
Errata ID: 3026
Status: Reported
Type: Technical
Reported By: Mathias Bynens
Date Reported: 2011-11-11
Section 7.1 says:
(I) Russian (Cyrillic):
U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
u+0438
Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
It should say:
(I) Russian (Cyrillic):
U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
u+0438
Punycode: b1abfaaepdrnnbgefbadotcwatmq2g4l
Notes:
The uppercase `D` in the encoded string appears to be a typo.
Errata ID: 264
Status: Verified
Type: Technical
Reported By: Marshall Price
Date Reported: 2004-10-15
In the "Dependent Specifications" section, it says:
RFC 1781 is a technical specification for "User Friendly Naming" which replies on particular syntaxes described in RFC 1779.
It should say:
RFC 1781 is a technical specification for "User Friendly Naming" which relies on particular syntaxes described in RFC 1779.
Errata ID: 261
Status: Verified
Type: Technical
Reported By: Mark Crispin
Date Reported: 2007-06-13
Section 2.3.1.1, page 8:
old:
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
[...]
new:
An unsigned 32-bit value assigned to each message, which when used
with the unique identifier validity value (see below) forms a 64-bit
value that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
[...]
-----
Section 2.3.1.1, page 9:
old:
Associated with every mailbox are two values which aid in unique
identifier handling: the next unique identifier value and the unique
identifier validity value.
new:
Associated with every mailbox are two 32-bit unsigned values which
aid in unique identifier handling: the next unique identifier value
(UIDNEXT) and the unique identifier validity value (UIDVALIDITY).
-----
Section 5.1.3, page 19:
old:
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself.
new:
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself. Only characters inside the modified BASE64 alphabet are
permitted in modified BASE64 text.
-----
Section 5.4, page 22:
old:
If a server has an inactivity autologout timer, the duration of that
timer MUST be at least 30 minutes. The receipt of ANY command from
the client during that interval SHOULD suffice to reset the
autologout timer.
new:
If a server has an inactivity autologout timer that applies to
sessions after authentication, the duration of that timer MUST be at
least 30 minutes. The receipt of ANY command from the client during
that interval SHOULD suffice to reset the autologout timer.
Section 5.5, page 22:
old:
Note: UID FETCH, UID STORE, and UID SEARCH are different
commands from FETCH, STORE, and SEARCH. If the client
sends a UID command, it must wait for a completion result
response before sending a command with message sequence
numbers.
new:
Note: EXPUNGE responses are permitted while UID FETCH,
UID STORE, and UID SEARCH are in progress. If the client
sends a UID command, it must wait for a completion result
response before sending a command which uses message
sequence numbers (this may include UID SEARCH). Any
message sequence numbers in an argument to UID SEARCH
are associated with messages prior to the effect of any
untagged EXPUNGE returned by the UID SEARCH.
-----
Section 6.2.1, page 27:
old:
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities after
STARTTLS.
new:
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities, and
in particular SHOULD NOT advertise the STARTTLS capability, after
a successful STARTTLS command.
-----
Section 6.2.2, page 28:
old:
The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
consisting of a single "*". If the server receives such a
response, it MUST reject the AUTHENTICATE command by sending a
tagged BAD response.
new:
The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
consisting of a single "*". If the server receives such a
response, or if it receives an invalid BASE64 string (e.g.
characters outside the BASE64 alphabet, or non-terminal "="), it
MUST reject the AUTHENTICATE command by sending a tagged BAD
response.
Section 6.3.4, page 36:
old:
It is permitted to delete a name that has inferior hierarchical
names and does not have the \Noselect mailbox name attribute. In
this case, all messages in that mailbox are removed, and the name
will acquire the \Noselect mailbox name attribute.
new:
It is permitted to delete a name that has inferior hierarchical
names and does not have the \Noselect mailbox name attribute. If
the server implementation does not permit deleting the name while
inferior hierarchical names exists the \Noselect mailbox name
attribute is set for that name. In any case, all messages in
that mailbox are removed by the DELETE command.
-----
Section 6.3.10, page 44:
old:
Responses: untagged responses: STATUS
new:
Responses: REQUIRED untagged response: STATUS
-----
Section 6.4.3, page 49:
old:
The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is
sent for each message that is removed.
new:
The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is
sent for each message that is removed. Note that if any messages
with the \Recent flag set are expunged, an untagged RECENT response
is sent after the untagged EXPUNGE(s) to update the client's count
of RECENT messages.
-----
Section 6.4.4, page 50:
old:
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
new:
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text. US-ASCII MUST be supported; other [CHARSET]s MAY be supported.
-----
Section 6.4.4, page 50:
old:
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
new:
In all search keys that use strings, a message matches the key if
the string is a substring of the associated text. The matching is
case-insensitive. Note that the empty string is a substring; this
is useful when doing a HEADER search.
-----
Section 6.4.4, page 54:
old:
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
new:
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
S: + Ready for literal text
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
-----
Section 7.2.2, page 70:
old:
If it is not feasible for the server to determine whether or not
the mailbox is "interesting", or if the name is a \Noselect name,
the server SHOULD NOT send either \Marked or \Unmarked.
new:
If it is not feasible for the server to determine whether or not
the mailbox is "interesting", the server SHOULD NOT send either
\Marked or \Unmarked. The server MUST NOT send more than one of
\Marked, \Unmarked, and \Noselect for a single mailbox, and MAY
send none of these.
-----
Section 7.4.2, page 75:
old:
body location
A string list giving the body content URI as defined in
[LOCATION].
new:
body location
A string giving the body content URI as defined in
[LOCATION].
Section 7.4.2, page 77:
old:
body location
A string list giving the body content URI as defined in
[LOCATION].
new:
body location
A string giving the body content URI as defined in
[LOCATION].
Formal Syntax, Page 84:
old:
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
new:
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
charset = atom / quoted
-----
Formal Syntax, Page 89:
old:
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
new:
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
-----
Formal Syntax, Page 89:
old:
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
new:
search = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key)
-----
Formal Syntax, Page 90:
old:
sequence-set = (seq-number / seq-range) *("," sequence-set)
new:
sequence-set = (seq-number / seq-range) ["," sequence-set]
-----
Formal Syntax, Page 90:
old:
status-att-list = status-att SP number *(SP status-att SP number)
new:
status-att-val = ("MESSAGES" SP number) / ("RECENT" SP number) /
("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number)
status-att-list = status-att-val *(SP status-att-val)
-----
IANA Considerations, Page 94:
new:
GSSAPI/Kerberos/SASL service names are registered by publishing a
standards track or IESG approved experimental RFC. The registry
is currently located at:
http://www.iana.org/assignments/gssapi-service-names
As this specification defines the "imap" service name previously
defined in RFC 1731, the registry will be updated accordingly.
-----
Normative References, Page 95:
old:
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
new:
[LANGUAGE-TAGS] Alvestrand, H., "Content Language Headers",
RFC 3282, May 2002.
Appendix B, Page 103:
new:
115) Add support for Content-Location to BODYSTRUCTURE.
It should say:
[see above]
Notes:
from pending
Errata ID: 3032
Status: Verified
Type: Technical
Reported By: Bron Gondwana
Date Reported: 2011-11-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15
Section 6.3.1 says:
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
[...]
OK [UNSEEN <n>]
The message sequence number of the first unseen
message in the mailbox. If this is missing, the
client can not make any assumptions about the first
unseen message in the mailbox, and needs to issue a
SEARCH command if it wants to find it.
It should say:
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY, UNSEEN (if any unseen exist)
[...]
OK [UNSEEN <n>]
The message sequence number of the first unseen
message in the mailbox. If there are any unseen
messages in the mailbox, an UNSEEN response MUST
be sent, if not it MUST be omitted.
If this is missing, the client cannot make any
assumptions about the first unseen message in the
mailbox, and needs to issue a SEARCH command if
it wants to find it.
Notes:
There is a conflict between "REQUIRED" on the UNSEEN response and having no value to send. This change documents the approach taken by existing servers.
Errata ID: 3093
Status: Reported
Type: Editorial
Reported By: Joe Pallas
Date Reported: 2012-01-18
Section 6.3.11 says:
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in
the message literal argument to APPEND. The full
implications of doing so MUST be understood and
carefully weighed.
It should say:
Note: There may be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in
the message literal argument to APPEND. The full
implications of doing so must be understood and
carefully weighed.
Notes:
Possibly the result of a search-and-replace, these occurrences of "must" and "may" are not RFC 2119 usages.
Errata ID: 2947
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-08-26
Held for Document Update by: Peter Saint-Andre
Section metadata says:
n/a
It should say:
The document should be marked as "Updates: 2801" as it makes several normative changes to IOTP spec.
Errata ID: 258
Status: Verified
Type: Editorial
Reported By: Alex Rousskov
Date Reported: 2005-07-18
Report Text:
Errata for this document can be found at: http://www.measurement-factory.com/std/icap/
Errata ID: 1481
Status: Reported
Type: Technical
Reported By: Manish Yadav
Date Reported: 2008-08-06
Section 3.2 says:
3.2 UDP Tunnel Reply Extension
This extension is a non-skippable extension. It is sent in reply to
a UDP Tunnel Request extension, and indicates whether or not the HA
will use MIP UDP tunnelling for the current mobility binding. The
format of this extension is as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reply Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 44
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type 0
Reply Code Indicates whether the HA assents or declines
to use UDP tunnelling for the current mobility
binding. See Section 3.2.1 below.
Notes:
In RFC 3519 paragraph 3.2, the UDP Tunnel Reply Extension is specified as a non-skippable with type = 44. However the extension is specified in the "Short Extension Format", which should be used for skippable extensions according to RFC 3344 paragraph 1.11.
Note: This RFC has been obsoleted by RFC5125
Source of RFC: megaco (rai)Errata ID: 256
Status: Verified
Type: Editorial
Reported By: Tom Taylor
Date Reported: 2005-09-13
Report Text:
Errata can be found in the ITU-T Implementor's Guide at: http://www.itu.int/itudoc/itu-t/com16/implgd/h248.1v1.html
Errata ID: 257
Status: Held for Document Update
Type: Editorial
Reported By: Chen Rui
Date Reported: 2005-04-28
Held for Document Update by: Robert Sparks
Appendix I says:
MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
Context = 5000 {Modify = A4445} }
It should say:
MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
Context = 5000 {Modify = A5555} }
Errata ID: 2613
Status: Verified
Type: Technical
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
When an OPEN is done and the specified lockowner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same lockowner.
It should say:
When an OPEN is done and the specified owner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same owner.
Notes:
The 'lockowner' should be replaced by 'owner' (twice in the paragraph). The lockowner is not related to the OPEN operation. Instead, the owner (open_owner) is related.
Errata ID: 2614
Status: Verified
Type: Technical
Reported By: Marcel Telka
Date Reported: 2010-11-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the OPEN operation from which the open_confirm value was obtained. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
It should say:
This operation is used to confirm the sequence id usage for the first time that a open_owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open_owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the previous OPEN operation. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
Notes:
The OPEN operation does not return the open_confirm value.
Errata ID: 2637
Status: Verified
Type: Technical
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current lock, open, or delegation state for any files
and have not been used recently.
It should say:
Instead, to avoid unbounded memory use, the
server needs to implement a strategy for disposing of open_owner4s
that have no current open state for any files
and have not been used recently.
Notes:
A lock can be held on already opened files only. This means that every lock state can exist only in case the accompanied open state is already there.
So if there is a lock state held by server then there must be an open state for the file too. This means that we do not need to mention the "current lock state" in the RFC's sentence above.
Next, the delegation state is allocated only in case the delegation is granted by server to a client for a file. The delegation state is related to file and client. It is not related/tied to openowner. This means that it is not possible to test whether an openowner have any delegation states. Delegation states are simply not related to the openowner.
It is easily possible to have a client with some delegation granted with no valid openowner held by a server.
Errata ID: 2663
Status: Verified
Type: Technical
Reported By: Marcel Telka
Date Reported: 2010-12-08
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 8.11. says:
When an OPEN is done for a file and the lockowner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
It should say:
When an OPEN is done for a file and the open_owner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
Notes:
The file opens are related to open_owners, not lockowners. The lockowner
should be replaced by open_owner in the first sentence of the paragraph above.
Errata ID: 255
Status: Verified
Type: Editorial
Reported By: Jon Bauman
Date Reported: 2004-02-03
Section 8.1.8. says:
This sequence establishes the use of an lock_owner and associated sequence number. Should be "a lock_owner"
It should say:
If server replica or a server immigrating a filesystem agrees to Should be "If a server replica"
Notes:
In Section 9.3.2. Data Caching and File Locking, Last Paragraph:
by flushing to the server more data upon an LOCKU than is covered by
the locked range.
Should be "a LOCKU"
Errata ID: 2609
Status: Verified
Type: Editorial
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.11. says:
SYNOPSIS
(cfh) locktype, offset, length owner -> {void, NFS4ERR_DENIED ->
owner}
It should say:
SYNOPSIS
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner}
Notes:
Missing comma in the LOCKT synopsis.
Errata ID: 2610
Status: Verified
Type: Editorial
Reported By: Marcel Telka
Date Reported: 2010-11-05
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.16. says:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, open_confirm, attrset delegation
It should say:
SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, attrset, delegation
Notes:
i) The open_confirm should be removed (it is not a part of the OPEN4resok structure).
ii) There is missing command between attrset and delegation.
Errata ID: 2638
Status: Verified
Type: Editorial
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).
It should say:
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN).
Notes:
The FH4_NO_EXPIRE_WITH_OPEN should be replaced with FH4_NOEXPIRE_WITH_OPEN.
Errata ID: 2639
Status: Verified
Type: Editorial
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 4.2.3. says:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOL_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOL_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOL_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
It should say:
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is
redundant.
.....
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from
the server. FH4_VOLATILE_ANY does not provide this form of information.
In situations where the server will expire many, but not all
filehandles upon migration (e.g., all but those that are open),
Notes:
The FH4_VOL_ANY should be replaced with FH4_VOLATILE_ANY (three times).
Errata ID: 254
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2004-10-14
Section 3.4 says:
PAD : 38be62
It should say:
PAD : be62fe
Notes:
Errata ID: 253
Status: Verified
Type: Technical
Reported By: Hideaki Yoshifuji
Date Reported: 2005-06-26
Section 11.3 says:
This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may receive an IPV6_MTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node.
It should say:
This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may receive an IPV6_PATHMTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node.
Notes:
Change: IPV6_MTU should be IPV6_PATHMTU.
Errata ID: 252
Status: Verified
Type: Editorial
Reported By: Tatuya JINMEI
Date Reported: 2004-02-12
In section 10.2 (page 41), the RFC says:
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint_t align,
void **databufp);
It should say:
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint8_t align,
void **databufp);
Notes:
Similarly, the following part of Section 15 (page 55)
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t, uint_t,
void **);
Should actually be:
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t,
uint8_t, void **);
That is, "uint_t" should be replaced with "uint8_t".
Errata ID: 2142
Status: Verified
Type: Editorial
Reported By: Lev Novikov
Date Reported: 2010-04-08
Verifier Name: Danny McPherson
Date Verified: 2010-09-10
Section 4.5.2.2 says:
Note that if the client has a certificate than SSL-based client authentication can be used. To make this easier, SASL provides the EXTERNAL mechanism, whereby the SASL client can tell the server "examine the outer channel for my identity". Obviously, this is not subject to the layering attacks described above.
It should say:
Note that if the client has a certificate then SSL-based client authentication can be used. To make this easier, SASL provides the EXTERNAL mechanism, whereby the SASL client can tell the server "examine the outer channel for my identity". Obviously, this is not subject to the layering attacks described above.
Notes:
Changed "than" to "then".
Errata ID: 2248
Status: Verified
Type: Editorial
Reported By: Glen Zorn
Date Reported: 2010-05-07
Verifier Name: Danny McPherson
Date Verified: 2010-09-10
Section 4.5.1 says:
modifying with the kernel or installing new drivers.
It should say:
modifying the kernel or installing new drivers.
Notes:
Correct poor grammar.
Errata ID: 1503
Status: Verified
Type: Technical
Reported By: Avi Lior
Date Reported: 2008-09-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 3.21 says:
For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
It should say:
For IEEE Std 802.1X-2001 authenticators, this attribute is used to store the Supplicant MAC address, represented as an ASCII character string in Canonical format (see IEEE Std 802). For example, "00-10-A4-23-19-C0".
Notes:
The IETF Informational RFC needed to specify that the representation of the MAC address is in Canonical Format.
This is the case in the IEEE document 802_1x-2001 which is the corrected text provided.
I would be okay if the authors wanted to use Supplicant MAC address instead of "bridge or Access Point" in the proposed corrected text.
Errata ID: 773
Status: Verified
Type: Technical
Reported By: Alan McNamee
Date Reported: 2006-04-13
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09
AVP Format
<Vendor-Specific-Application-Id> ::=3D < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
Notes:
for 1* [ Vendor-Id ], is it required or optional?=20
In my understanding, [ ] represent "optional", which means allowing none =
of=20
this type AVP appear, but 1* means at least one needed, Is it =
inconsistent?
The same problem for 0*1{ Auth-Application-Id } and 0*1{ =
Acct-Application-Id }.
Can it is be issued as RFC bug for RFC errata?
from pending
Errata ID: 1429
Status: Verified
Type: Technical
Reported By: Parveen Verma
Date Reported: 2008-05-25
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09
Section 11.4.1 says:
11.4.1. Result-Code AVP Values As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017. All remaining values are available for assignment via IETF Consensus [IANA].
It should say:
11.4.1. Result-Code AVP Values As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4003 and 5001-5017. All remaining values are available for assignment via IETF Consensus [IANA].
Notes:
7.1.4. Transient Failures
......
DIAMETER_AUTHENTICATION_REJECTED 4001
......
DIAMETER_OUT_OF_SPACE 4002
......
ELECTION_LOST 4003
The peer has determined that it has lost the election process and
has therefore disconnected the transport connection.
For Transient Failures we have error code 4001-4003 defined but the IANA consideration part says only 4001-4002, which can mean the value 4003 is free, but 4003 is assigned to ELECTION_LOST hence error.
Errata ID: 2817
Status: Verified
Type: Technical
Reported By: Vinay parashar
Date Reported: 2011-05-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section 5.5.2 says:
There is no valid avp named[ Original-State-Id ].
in DWA message [ Original-State-Id ] should be replaced by [ Origin-State-Id ]
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]
It should say:
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Origin-State-Id ]
Errata ID: 2101
Status: Held for Document Update
Type: Technical
Reported By: Diego Rosario Brogna
Date Reported: 2010-03-31
Held for Document Update by: Dan Romascanu
Section 3.2 says:
header = "<" Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
It should say:
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
Errata ID: 250
Status: Verified
Type: Editorial
Reported By: Alan McNamee
Date Reported: 2004-10-02
Section 8.3.2 says:
Message Format
<RAA> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Host-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
It should say:
Message Format
<RAA> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
Notes:
Errata ID: 251
Status: Verified
Type: Editorial
Reported By: Alan McNamee
Date Reported: 2004-10-02
Section 5.5.2 says:
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]
It should say:
Message Format
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Origin-State-Id ]
Notes:
Errata ID: 2564
Status: Held for Document Update
Type: Editorial
Reported By: Hans Liu
Date Reported: 2010-10-14
Held for Document Update by: Dan Romascanu
Section 6.1.8 says:
In figure 6, the contents of some AVPs contains domain name mno.net, but the network realm is example.net.
It should say:
Need to fix the inconsistent domain name, change all example.net to mno.net, which is more differentiable from another domain example.com
Errata ID: 1063
Status: Reported
Type: Technical
Reported By: Peter Koch
Date Reported: 2005-09-13
Section 7 says:
As a courtesy to implementors, it is hereby noted that the complete set of such previously published RR types that contain embedded domain names, and whose DNSSEC canonical form therefore involves downcasing according to the DNS rules for character comparisons, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6.
It should say:
[not supplied]
Notes:
Compare with RFC 4034 (section 6.2):
"3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;"
Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.
neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.
Note: This RFC has been obsoleted by RFC3700
Source of RFC: Legacy
Errata ID: 2779
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Held for Document Update by: ronbonica
Section TOC says:
2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
It should say:
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Errata ID: 1050
Status: Verified
Type: Technical
Reported By: Alexandre Machado
Date Reported: 2007-09-13
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 2.1 says:
rtcp-attribute = "a=rtcp:" port [nettype space addrtype space
connection-address] CRLF
It should say:
rtcp-attribute = "a=rtcp:" port [space nettype space addrtype space
connection-address] CRLF
Notes:
There must be a space between "port" and "nettype".
Errata ID: 2292
Status: Held for Document Update
Type: Technical
Reported By: linear
Date Reported: 2010-05-30
Held for Document Update by: Robert Sparks
Section 1 says:
The session invitation protocol (SIP, [RFC3261])
It should say:
The session initiation protocol (SIP, [RFC3261])
Notes:
SIP stand for Session Initiation Protocol, not invitation.
Errata ID: 1759
Status: Verified
Type: Technical
Reported By: Timur Friedman
Date Reported: 2009-04-07
Verifier Name: Cullen Jennings
Date Verified: 2009-04-07
Section 6.3 says:
"recv-rtt"
It should say:
"rcvr-rtt"
Notes:
Sec. 6.3 describes the SDP attribute in Sec. 5.1, but erroneously calls it "recv-rtt" whereas it is in fact "rcvr-rtt". The IANA, following Sec. 6.3, had recorded "recv-rtt" but has corrected this and now records "rcvr-rtt".
Errata ID: 2262
Status: Held for Document Update
Type: Technical
Reported By: Kamil Sarac
Date Reported: 2010-05-14
Held for Document Update by: Robert Sparks
Section 4.6 says:
min_jitter: 32 bits
The minimum relative transit time between two packets in the
above sequence number interval. All jitter values are measured
as the difference between a packet's RTP timestamp and the
reporter's clock at the time of arrival, measured in the same
units.
max_jitter: 32 bits
The maximum relative transit time between two packets in the
above sequence number interval.
mean_jitter: 32 bits
The mean relative transit time between each two packet series
in the above sequence number interval, rounded to the nearest
value expressible as an RTP timestamp.
dev_jitter: 32 bits
The standard deviation of the relative transit time between
each two packet series in the above sequence number interval.
It should say:
min_jitter: 32 bits
The minimum jitter measured for a pair of packets in the above
sequence number interval. The packet jitter is defined in [9,
Section 6.4.1] and measured in timestamp units.
max_jitter: 32 bits
The maximum jitter measured for a pair of packets in the above
sequence number interval.
mean_jitter: 32 bits
The mean jitter measured for a pair of packets in the above
sequence number interval, rounded to the nearest
value expressible as a timestamp.
dev_jitter: 32 bits
The standard deviation of the jitter measured for a pair of packets
in the above sequence number interval.
Notes:
In the original RFC 3611 in Section 4.6 where it defines "min_jitter", the jitter definition is different from the one given in RFC3550. This errata report is to correct this difference by referring to RFC 3550 for the proper definition of jitter and revises the definitions of "min_jitter", "max_jitter", "mean_jitter", and "dev_jitter" fields.
Errata ID: 249
Status: Verified
Type: Editorial
Reported By: Richard Walters
Date Reported: 2005-08-30
Section 3 says:
VRAT = %x76 %x72 %x61 %x74
Notes:
This rule is important because without it, it isn't clear whether the
"vrat" string is capitalized (like "RIFF" and "QLCM") or not (like
"fmt " and "data").
Errata ID: 2465
Status: Reported
Type: Editorial
Reported By: Fernando Gont
Date Reported: 2010-08-15
Section 6.2 says:
[ICMPv3] Conta, A., Deering, S., "Internet Control Message
Protocol (ICMPv6)", Work in Progress.
It should say:
[ICMPv6] Conta, A., Deering, S., "Internet Control Message
Protocol (ICMPv6)", Work in Progress.
Notes:
Pointer to this reference should be fixed accordingly (i.e., s/ICMPv3/ICMPv6/ across the document)
Errata ID: 2468
Status: Reported
Type: Technical
Reported By: Ole Troan
Date Reported: 2010-08-17
Section 12.1 / 12.2 says:
Section 12.1: Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.
It should say:
Section 12.1: Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached. New last paragraph of 12.2: When the DR delegates prefixes to a Requesting Router, the Requesting Router has sole authority for assignment of those prefixes, and the Delegating Router MUST NOT assign any prefixes from that delegated prefix to any of its own links.
Notes:
This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).
2011-08-02: Notes updated per request from Ole Troan and Leaf Yeh.
Errata ID: 2469
Status: Reported
Type: Technical
Reported By: Ole Troan
Date Reported: 2010-08-17
Section 11.1 says:
The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, with the exception that the requesting router MAY display the associated status message to the user.
It should say:
The requesting router MUST ignore any IA_PDs in an Advertise message that includes a Status Code option containing the value NoPrefixAvail, with the exception that the requesting router MAY display the associated status message to the user.
Errata ID: 2470
Status: Reported
Type: Technical
Reported By: Ole Troan
Date Reported: 2010-08-17
Edited by: Ralph Droms
Date Edited: 2010-08-20
Section 11.2 says:
If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail and a status message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID.
It should say:
If the delegating router will not assign any prefixes to an IA_PD in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail and a status message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID. The server SHOULD include other stateful IA options (like IA_NA) and other configuration options in the Advertise message.
Notes:
Edited by Ralph Droms on 2010-08-20 to correct reference to IA_NA (was IA_PD) in last line.
Errata ID: 248
Status: Reported
Type: Editorial
Reported By: Hideshi Enokihara
Date Reported: 2006-06-15
Section 9 says:
If a requesting router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_PD option and processes the remainder of the message as though the delegating router had not included the IA_PD option.
It should say:
If a requesting router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the requesting router discards the IA_PD option and processes the remainder of the message as though the delegating router had not included the IA_PD option.
Notes:
Errata ID: 1880
Status: Reported
Type: Editorial
Reported By: Yukiyo Akisada
Date Reported: 2009-09-15
Section 9 says:
If a delegating router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the delegating router ignores the invalid values of T1 and T2 and processes the IA_PD as though the delegating router had set T1 and T2 to 0.
It should say:
If a delegating router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the delegating router ignores the invalid values of T1 and T2 and processes the IA_PD as though the requesting router had set T1 and T2 to 0.
Errata ID: 247
Status: Verified
Type: Editorial
Reported By: Daniel Montpetit
Date Reported: 2004-04-21
On page 68, it says:
------------------------------------------------------
4.6.6 Archive Collection System
(Internal or External) 5.5.6
------------------------------------------------------
4.6.6 Procedures to Obtain and
Verify Archive Information 5.5.7
------------------------------------------------------
It should say:
------------------------------------------------------
4.6.6 Archive Collection System
(Internal or External) 5.5.6
------------------------------------------------------
4.6.7 Procedures to Obtain and
Verify Archive Information 5.5.7
------------------------------------------------------
Errata ID: 1500
Status: Reported
Type: Technical
Reported By: Maik Reiß (Reiss)
Date Reported: 2008-09-02
Section 7.7.4 says:
7.7.4. A More Complex Example ... C> MLSD test S> 150 BINARY connection open for MLSD test D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test D> Type=pdir;Perm=e;Unique=keVO1+d?3; .. D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
It should say:
7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here
Notes:
The sample sequence in chapter 7.7.4 uses an example which is completely wrong, because it violates the basic BNF rules of its own document.
Please, see the definition, which is violated:
7.2. Format of MLSx Response
The format of a response to an MLSx command is as follows:
...
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
...
Remember, a fact may not contain ";" or SPC (" ")!
Now take a look into the bad example:
7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
the last line uses the fact "Type=OS.unix=slink:/foobar;". While this line in special not violates the rules at the moment, it implies that "Type=OS.unix=slink:" starts printing the original link target of any given symbolic link. Not wrong till here, but in case a link points to an original directory which name contains a ";" or, most worse, a "; " sequence, it will
lead any client side PI into misinterpretation of the line.
Even more worse, some actual public servers already use this bad syntax. Some can be found at least in the Swiss. It looks like they are running proftpd under Linux operating system, but this is unconfirmed for now.
Solution:
The chapter 7 of the same document allows another approach to tell the client about the original destination of a symlink. This solution uses two lines of answer, see my example:
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar points somewhere else
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here
because of the "Unique" fact, a client PI can now collect all lines with the fact "Type=OS.unix=symlink" and file it under an associative array (map, hastable) with "keVO1+4G4" as the access key. Once the client side parser again gets "Unique=keVO1+4G4", it now can record "/foobar; does point to here" as the original point where foobar points to.
This is exactly, what chapter 7.5.1.5 defines about the "Unique" fact. Please read:
Note: Where the underlying system supports a file type that is
essentially an indirect pointer to another file, the NVFS
representation of that type should normally be to represent the file
that the reference indicates. That is, the underlying basic file
will appear more than once in the NVFS, each time with the "unique"
fact (see immediately following section) containing the same value,
indicating that the same file is represented by all such names.
Useful to say, setting the slink into double quotes like suggested by some developers:
D> Type=OS.unix="slink:/foobar";Perm=;Unique=keVO1+4G4; foobar
would violate the same documents BNF rules (see RCHAR), as well it would require escaping of any DQUOTE in the link pathname itself. This, again, would violate RFC959 which not defines escaping of characters.
Finally, FTP does not support 2 pathnames at the same line at all. This convention sould never been broken.
Errata ID: 2850
Status: Held for Document Update
Type: Technical
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-29
Held for Document Update by: Peter Saint-Andre
Section 2.5 says:
and each sequence of lines that begin "D> " was sent from the server-PI to the user-PI over a data connection created just to send those lines and closed immediately after.
It should say:
and each sequence of lines that begin "D> " was sent from the server-DTP to the user-DTP over a data connection created just to send those lines and closed immediately after.
Notes:
In this case the acting parties are DTPs, not PIs.
Errata ID: 901
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Rejected by: Pete Resnick
Date Rejected: 2011-05-16
Section 7.5.4 says:
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact.
It should say:
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server.
Notes:
It is one of the benefits of 'Create' timestamps for directory
entries that there is *no* enforced relationship between that
timestamp and the 'Modify' timestamp related to the file *content*.
We still support legacy systems from Hewlett-Packard that indeed
maintain three timestamps per directory entry: 'Create', 'Modify',
and 'Access'. The very useful behaviour of the File System and
the proprietary Networking Services is as follows: If you move a
file to another directory or copy it (within a system, or across
the network), the 'Modify' timestamp does not change (since the
file content is unchanged from what it was then), only the 'Create'
timestamp of the new directory entry is set to the current time.
(This means the 'Modify' timestamp behaves like a 'last update'
timestamp embedded in the file content, e.g., in a PDF file.)
In this case, the create fact would have to be *later* than the
modify fact, for RFC 3659. Naturally, if a file was being edited,
the 'Modify' timestamp changes and will then be later than the
'Create' timestamp.
The natural behaviour of a hypothetical FTP client implementing
RFC 3659 in such environment, when performing a 'get' operation,
would be to obtain the modify timestamp of the remote file via
MLSx or MDTM and, after performing the RETR (and, perhaps verifying
the 'atomicity' of the transfer via another MDTM that should deliver
the same response again) setting the 'Modify' timestamp of the local
copy of the file to the moment corresponding to the MDTM result
value (or the modify fact value from the MLSx).
--VERIFIER NOTES--
This is a technical change that may be against the consensus of a WG and therefore is not appropriate for an erratum.
Errata ID: 899
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 6.5 says:
That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
It should say:
That those pathnames all exist does not imply that the TVFS server will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
Notes:
typo: sever --> server
from pending
Errata ID: 900
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 7 says:
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that transmission of 8-bit data over the control connection.
It should say:
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow the transmission of 8-bit data over the control connection.
Notes:
typo: that --> the
from pending
Errata ID: 903
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Held for Document Update by: Peter Saint-Andre
Section 9 says:
[...]. Unless the "media-type" fact is
provided in a MLSx response nor is any advice given here that would
allow determining the content type. [...]
It should say:
[...]. Unless the "media-type" fact is
provided in a MLSx response, no advice is given here that would allow
determining the content type. [...]
Notes:
This sentence apparently is garbled a bit.
from pending
Errata ID: 2496
Status: Held for Document Update
Type: Editorial
Reported By: Anthony Bryan
Date Reported: 2010-08-21
Held for Document Update by: Peter Saint-Andre
Throughout the document, when it says:
3.2 ... Various 4xy replies are also possible in appropriate circumstances. 4.2 ... Various 4xy replies are also possible in appropriate circumstances. 7.2.1 Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
It should say:
3.2 ... Various 4yz replies are also possible in appropriate circumstances. 4.2 ... Various 4yz replies are also possible in appropriate circumstances. 7.2.1 Many of the 4yz and 5yz responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4yz replies) are also possible in appropriate circumstances.
Notes:
RFC 959, Section 4.2 refers to these reply codes as 4yz and 5yz, instead of 4xy and 5xy.
Errata ID: 2740
Status: Verified
Type: Technical
Reported By: Niels Widger
Date Reported: 2011-03-02
Verifier Name: Robert Sparks
Date Verified: 2011-03-03
Section 3.8 says:
F11 CANCEL Proxy 1 -> Proxy 2 CANCEL sip:alice@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
It should say:
F11 CANCEL Proxy 1 -> Proxy 2 CANCEL sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0
Notes:
The Request-URI of message F11 is incorrect according to RFC 3261 Section 9.1: "The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags".
Errata ID: 728
Status: Verified
Type: Editorial
Reported By: Mani Devarajan
Date Reported: 2005-01-11
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 3.1 says:
F2 INVITE Alice -> Proxy1
It should say:
F2 INVITE NGW 1 -> Proxy1
Errata ID: 2807
Status: Verified
Type: Editorial
Reported By: Pete Resnick
Date Reported: 2011-05-13
Verifier Name: Olaf Kolkman
Date Verified: 2011-07-24
Throughout the document, when it says:
Category: Standards Track
It should say:
Category: Best Current Practice
Errata ID: 2524
Status: Reported
Type: Technical
Reported By: YOSHIFUJI Hideaki
Date Reported: 2010-09-16
Section 5.2.2 says:
The interface argument holds the local IP address of the interface.
It should say:
The interface argument holds the interface index of the interface.
Notes:
See Section 5.2.1.
Errata ID: 1395
Status: Reported
Type: Editorial
Reported By: Dave Thaler
Date Reported: 2008-03-27
Section 5.1 says:
The rules for generating errors are the same as those given in Section 5.1.3.
It should say:
The rules for generating errors are the same as those given in Section 4.1.3.
Notes:
There is no section 5.1.3.
Errata ID: 246
Status: Verified
Type: Technical
Reported By: John C. Klensin
Date Reported: 2005-07-09
Section 3 says:
The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. For example
Abc\@def@example.com
is a valid form of an email address. Blank spaces may also appear,
as in
Fred\ Bloggs@example.com
The backslash character may also be used to quote itself, e.g.,
Joe.\\Blow@example.com
It should say:
The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. For example
"Abc\@def"@example.com
is a valid form of an email address. Blank spaces may also appear,
as in
"Fred\ Bloggs"@example.com
The backslash character may also be used to quote itself, e.g.,
"Joe.\\Blow"@example.com
Errata ID: 1003
Status: Verified
Type: Technical
Reported By: John C. Klensin
Date Reported: 2005-07-09
Section 3 says:
In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. Systems that handle email should be prepared to process addresses which are that long, even though they are rarely encountered.
It should say:
In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 256 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 256.
Errata ID: 1004
Status: Verified
Type: Technical
Reported By: Charles Curran
Date Reported: 2007-09-09
Verifier Name: John C. Klensin
Date Verified: 2007-09-09
Section 4.3 says:
+-------------------------+-----------------------------+-----------+
| Email address | MAILTO URL | Notes |
+-------------------------+-----------------------------+-----------+
| Joe@example.com | mailto:joe@example.com | 1 |
...
Notes on Table
1. No characters appear in the email address that require escaping,
so the body of the MAILTO URL is identical to the email address.
It should say:
+-------------------------+-----------------------------+-----------+
| Email address | MAILTO URL | Notes |
+-------------------------+-----------------------------+-----------+
| Joe@example.com | mailto:Joe@example.com | 1 |
...
Notes on Table
1. No characters appear in the email address that
require escaping, so the body of the MAILTO URL is
identical to the email address. Because the local part
of email addresses may be treated as case-sensitive by
the system hosting the mailbox (see RFC 2821, Section
4.1.2), "mailto:joe@example.com" would not be a valid
URL for the mailbox Joe@example.com even though, if the
recommendations of RFC 2821 are followed, it would work
as a synonym. See also Section 6.2.3 of RFC 3986.
Errata ID: 1690
Status: Verified
Type: Technical
Reported By: Dominic Sayers
Date Reported: 2009-02-22
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 3 says:
(from erratum 1003) In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 256 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 256.
It should say:
In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 254 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 254.
Notes:
I believe erratum ID 1003 is slightly wrong. RFC 2821 places a 256 character limit on the forward-path. But a path is defined as
Path = "<" [ A-d-l ":" ] Mailbox ">"
So the forward-path will contain at least a pair of angle brackets in addition to the Mailbox. This limits the Mailbox (i.e. the email address) to 254 characters.
Note: This RFC has been obsoleted by RFC5000
Source of RFC: INDEPENDENT
Errata ID: 1350
Status: Verified
Type: Editorial
Reported By: Shestakov Valerij
Date Reported: 2008-03-05
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section In ToC says:
2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
It should say:
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Errata ID: 1626
Status: Held for Document Update
Type: Editorial
Reported By: Joel Faber
Date Reported: 2008-12-03
Held for Document Update by: Pasi Eronen
Section 4.2 says:
The disadvantage of this scheme is the reliance upon the peer to demonstrate liveliness. To this end, peer B might never be interested in peer A's liveliness. Nonetheless, if A is interested B's liveliness, B must be aware of this, and maintain the necessary state information to send periodic HELLOs to A. The disadvantage of
It should say:
The disadvantage of this scheme is the reliance upon the peer to demonstrate liveliness. To this end, peer B might never be interested in peer A's liveliness. Nonetheless, if A is interested in B's liveliness, B must be aware of this, and maintain the necessary state information to send periodic HELLOs to A. The disadvantage of
Notes:
Add "in" to make "interested in B's liveliness".
Errata ID: 2679
Status: Held for Document Update
Type: Technical
Reported By: Alexey Melnikov
Date Reported: 2010-12-22
Held for Document Update by: Sean Turner
Section 4.1 says:
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
Notes:
The mediaType is underspecified, as no specific syntax is given.
E.g. are spaces allowed before parameters? Also, my understanding is that IA5String disallows UTF-8, while media type parameters can possibly include UTF-8 values.
I would recommend referencing ABNF from Section 4.2 of RFC 4288.
Errata ID: 2325
Status: Held for Document Update
Type: Editorial
Reported By: Alexey Melnikov
Date Reported: 2010-07-13
Held for Document Update by: Tim Polk
Section 4.1 says:
When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a binary file containing the DER encoded data with the syntax LogotypeData. The referenced file name SHOULD include a file extension of "LTD".
Notes:
There is no IETF process for only registering a file extension. IETF MIME type registry allows to register MIME types together with the corresponding file extensions. An update to this document should register a new MIME type for "LTD".
Errata ID: 1958
Status: Held for Document Update
Type: Editorial
Reported By: Jaap Keuter
Date Reported: 2009-12-10
Held for Document Update by: Robert Sparks
Section 1 says:
This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, RTCP (the Real-time Transport Control Protocol) [RFC3350].
It should say:
This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, RTCP (the Real-time Transport Control Protocol) [RFC3550].
Notes:
Reference is made to the RFC pertaining RTP, which is 3550, not 3350.
Errata ID: 243
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Report Text:
[RFC2279] has been obsoleted by [RFC3629]. All citations to [RFC2279] should refer to [RFC3629].
[RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO
10646", RFC 3629, STD 63, November 2003.
Errata ID: 244
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Verifier Name: Bob Braden
Date Verified: 2007-11-12
Section 4.2 says:
Note: This attribute is based on 'printer-uri-supported', 'uri-
authentication-supported', and `'uri-security-supported' (called the
'Three Musketeers' because they are parallel ordered attributes)
It should say:
Note: This attribute is based on 'printer-uri-supported', 'uri-
authentication-supported', and 'uri-security-supported' (called the
'Three Musketeers' because they are parallel ordered attributes)
Notes:
Extraneous "`" in 2nd line.
Errata ID: 245
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-09-06
Verifier Name: Bob Braden
Date Verified: 2007-11-12
Section References says:
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", RFC 2717, November 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", BCP 19, RFC 2718,
November 1999.
[RFC2978] Freed, N. and J.Postel, "IANA Charset Registration
Procedures", RFC2978, October 2000.
It should say:
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", RFC 2717, BCP 35, November 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
[RFC2978] Freed, N. and J.Postel, "IANA Charset Registration
Procedures", RFC2978, BCP 19, October 2000.
Errata ID: 242
Status: Verified
Type: Technical
Reported By: Matt Holdrege
Date Reported: 2004-03-13
Section 6.1 says:
[RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
It should say:
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
Errata ID: 241
Status: Verified
Type: Editorial
Reported By: Julian Satran
Date Reported: 2004-09-01
Section 3.2.6.1 says:
The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established.
It should say:
The only exception is if a discovery session (see Section 3.3 iSCSI Session Types) is to be established.
Notes:
Section 2.3 --> Section 3.3
Errata ID: 1791
Status: Verified
Type: Technical
Reported By: Smadar Tauber
Date Reported: 2009-06-03
Verifier Name: Dan Romascanu
Date Verified: 2009-06-10
Section 4 says:
UNITS definition of the following MIB objects, should change from dBm to dB.
That will also fix the conflict with the units appearing in the Description of these MIB objects (dB).
vdslPhysCurrSnrMgn
vdslPhysCurrAtn
vdslLineConfDownMaxSnrMgn
vdslLineConfDownMinSnrMgn
vdslLineConfDownTargetSnrMgn
vdslLineConfUpMaxSnrMgn
vdslLineConfUpMinSnrMgn
vdslLineConfUpTargetSnrMgn
Example of original text:
vdslPhysCurrSnrMgn OBJECT-TYPE
SYNTAX Integer32 (-127..127)
UNITS "0.25dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Noise Margin as seen by this Vtu with respect to its
received signal in 0.25dB. The effective range is
-31.75 to +31.75 dB."
REFERENCE "T1E1.4/2000-009R3, Part 1, common spec"
::= { vdslPhysEntry 5 }
It should say:
Example of corrected text:
vdslPhysCurrSnrMgn OBJECT-TYPE
SYNTAX Integer32 (-127..127)
UNITS "0.25dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Noise Margin as seen by this Vtu with respect to its
received signal in 0.25dB. The effective range is
-31.75 to +31.75 dB."
REFERENCE "T1E1.4/2000-009R3, Part 1, common spec"
::= { vdslPhysEntry 5 }
Notes:
This Errata replaces errata 1788 (rejected because it did not include list of all MIB objects having this problem and could not be edited).
It was decided by the adslmib Forum, that the solution should be as described by this Errata.
Errata ID: 1788
Status: Rejected
Type: Technical
Reported By: Smadar Tauber
Date Reported: 2009-05-24
Rejected by: Dan Romascanu
Date Rejected: 2009-06-03
Section Global says:
Example:
vdslPhysCurrSnrMgn OBJECT-TYPE
SYNTAX Integer32 (-127..127)
UNITS "0.25dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Noise Margin as seen by this Vtu with respect to its
received signal in 0.25dB. The effective range is
-31.75 to +31.75 dB."
REFERENCE "T1E1.4/2000-009R3, Part 1, common spec"
::= { vdslPhysEntry 5 }
vdslPhysCurrAtn OBJECT-TYPE
SYNTAX Gauge32 (0..255)
UNITS "0.25dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Measured difference in the total power transmitted by
the peer Vtu and the total power received by this Vtu.
The effective range is 0 to +63.75 dB."
It should say:
UNITS statement (dBm) does not match units appearing in DESCRIPTION text (dB). I think 'dB' are the right units for the objects above, but one can check that. Anyway, it is clear that there should not be the existing mismatch. Same problem for more MIB objects in the RFC.
Notes:
--VERIFIER NOTES--
According to the discussions on the WG list, a new Errata report will be submitted including the complete list of objects affected by this change request.
Note: This RFC has been obsoleted by RFC4930
Source of RFC: provreg (app)
Errata ID: 240
Status: Verified
Type: Editorial
Reported By: "Scott Hollenbeck"
Date Reported: 2004-11-17
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19
Section 2.9.2.3 says:
A <poll> acknowledgement response notes the number of messages remaining in the queue and the ID of the next message available for retrieval.
It should say:
A <poll> acknowledgement response notes the ID of the message that has been acknowledged and the number of messages remaining in the queue.
Notes:
Errata ID: 239
Status: Verified
Type: Editorial
Reported By: "Scott Hollenbeck"
Date Reported: 2004-11-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19
Section 2.9.2.3 says:
S: <msgQ count="4" id="12346"/>
It should say:
S: <msgQ count="4" id="12345"/>
Notes:
Author knows the best :-).
Note: This RFC has been obsoleted by RFC4933
Source of RFC: provreg (app)
Errata ID: 238
Status: Verified
Type: Editorial
Reported By: Scott Hollenbeck
Date Reported: 2004-05-13
Section 3.2.4 says:
S: <result code="1000"> S: <msg>Command completed successfully</msg>
It should say:
S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg>
Errata ID: 3108
Status: Verified
Type: Technical
Reported By: Loïc Etienne
Date Reported: 2012-02-06
Verifier Name: Sean Turner
Date Verified: 2012-02-08
Section C.1.1.1. says:
GeneralizedTime : "197110141200Z"
It should say:
GeneralizedTime : "19711014120000Z"
Notes:
X.690
11 Restrictions on BER employed by both CER and DER
11.7 GeneralizedTime
11.7.2 The seconds element shall always be present.
In rfc 3739, C.3 DER-encoding, the second-zeroes are present:
... ..313937 31313031 34313230 3030305A ...
They are just missing in the string representation above.
Additionally RFC 5280 requires the second-zeroes be present.
Errata ID: 237
Status: Verified
Type: Editorial
Reported By: Donald Eastlake III
Date Reported: 2004-03-26
Report Text:
Please see the corresponding W3C document: http://www.w3.org/TR/xml-exc-c14n Please see the pointer to the W3C errata: http://www.w3.org/2002/07/xml-exc-c14n-errata
Errata ID: 236
Status: Verified
Type: Editorial
Reported By: Sally Floyd
Date Reported: 2005-06-08
Section 2 says:
the invariant is maintained so that the congestion window is increased during slow-start by at most max_ssthresh/2 MSS per round- trip time.
It should say:
the invariant is maintained that the congestion window is increased during slow-start by at most max_ssthresh MSS per round-trip time (and at least max_ssthresh/2 MSS per round-trip time).
Notes:
Later in Section 2:
it
takes:
log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)
round-trip times to reach a congestion window of cwnd, for a
congestion window greater than max_ssthresh.
Should be:
it
takes at least:
log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh)
and at most:
log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)
round-trip times to reach a congestion window of cwnd, for a
congestion window greater than max_ssthresh.
Later in Section 2:
Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it
would take 836 round-trip times to reach a congestion window of
83,000 packets,
Should be:
Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it
would take at least 836 round-trip times to reach a congestion window of
83,000 packets,
Errata ID: 235
Status: Verified
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2004-05-26
Report Text:
Issues and resolutions regarding this document can be reviewed at: http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-issues.html
Errata ID: 1643
Status: Reported
Type: Editorial
Reported By: Shiang-Ming Huang
Date Reported: 2008-12-23
Section 1.1 says:
Conversely, the term | "trust relationship" denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future.
It should say:
Conversely, the term | "trust relationship" denotes a mutual priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future.
Note: This RFC has been obsoleted by RFC4334
Source of RFC: pkix (sec)
Errata ID: 233
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2005-01-22
Section 8 says:
id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }
It should say:
id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }
Notes:
Errata ID: 234
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2005-01-22
Section 4 says:
The WLAN SSID attribute certificate attribute is identified by
id-aca-wlanSSID.
id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }
id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }
It should say:
The WLAN SSID attribute certificate attribute is identified by
id-aca-wlanSSID.
id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }
id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }
Notes:
This same error is repeated in the ASN.1 Module (Section 8).
Errata ID: 232
Status: Held for Document Update
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2006-08-31
Held for Document Update by: Tim Polk
Section 4 says:
One possible selection method is described in RFC 2777 [1].
It should say:
One possible selection method is described in RFC 3797 [1].
Notes:
References point to RFC 3797, not RFC 2777:
[1] Eastlake, 3rd, D., "Publicly Verifiable Nominations Committee
(Nomcom) Random Selection", RFC 3797, June 2004.
RFC 3797 has obsoleted RFC 2777
Errata ID: 2537
Status: Verified
Type: Technical
Reported By: Jim Schaad
Date Reported: 2010-09-30
Verifier Name: Sean Turner
Date Verified: 2011-02-23
Section 2.2.3.9 says:
To simplify the comparison of IP address blocks when performing certification path validation, a maximum IP address MUST contain at least one bit whose value is 1, i.e., the subsequent octets may not be omitted nor all zero.
It should say:
Text should be deleted.
Notes:
There are a number of different issues relative to this text that need to be addressed.
1. This text implicitly change the rules for encoding a maximum value. As an example the address 0.0.0.255 is encoded as 03 03 00 00 00 00 according to the rule " The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address."
2. The rule in no way simplifies any comparisions of IP address blocks. If one really wishes to simplify the comparison then one needs to change the rule for maximum addresses to remove all but the last least-signficant one-bit from the address. However it is not clear that even this would really simplify the comparison in any significant way.
If you look at the example in 2.2.3.9 - tis is not clear how having the one bit at the top of the encoding helps make the comparisons any easier - but it satisfies the requirment that atleast one bit is a 1. If the maximum value ws encoded as 1000 1 (0x3 0x02 0x03 0x84) - a bitwise comparision routine could make for a simplified a < b comparison (looking at only the top 5 bits of the address to be compared.)
Errata ID: 836
Status: Verified
Type: Editorial
Reported By: Randy Bush
Date Reported: 2006-06-21
Section 3.2.3.1 says:
The ASIdentifiers type is a SEQUENCE containing one or more forms of autonomous system identifiers -- AS numbers (in the asnum element) or routing domain identifiers (in the rdi element). When the ASIdentifiers type contains multiple forms of identifiers, the asnum entry MUST precede the rdi entry. AS numbers are used by BGP, and routing domain identifiers are specified in the IDRP [RFC1142].
It should say:
[see Notes]
Notes:
IDRP was never defined in an RFC, only by ISO 10747.
from pending
Errata ID: 1886
Status: Verified
Type: Editorial
Reported By: Charles Bobo
Date Reported: 2009-09-21
Verifier Name: Sean Turner
Date Verified: 2010-04-19
Section 2.1.1 says:
An IPv6 address is a 128-bit quantity that is written as eight hexadecimal numbers, each in the range 0 through ffff, separated by a semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. IPv6 addresses frequently have adjacent fields whose value is 0. One such group of 0 fields may be abbreviated by two semicolons ("::").
It should say:
An IPv6 address is a 128-bit quantity that is written as eight hexadecimal numbers, each in the range 0 through ffff, separated by a colon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. IPv6 addresses frequently have adjacent fields whose value is 0. One such group of 0 fields may be abbreviated by two colons ("::").
Notes:
"semicolon" should be "colon"
Added reference to RFC4291.
Verifier: Forward reference to RFC4291 is inappropriate.
Errata ID: 1887
Status: Held for Document Update
Type: Editorial
Reported By: Charles Bobo
Date Reported: 2009-09-21
Held for Document Update by: Tim Polk
Section References says:
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
It should say:
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4291] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 4291, February 2006
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
Notes:
Section is "Informational References" but this doesn't fit in the Section field above.
References were out of alphabetical order -- RFC3281 should come before RFC3513.
Added reference RFC4291
Errata ID: 733
Status: Verified
Type: Editorial
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Verifier Name: Bob Braden
Date Verified: 2008-04-21
Section 3.1 says:
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
Float32
[APPLICATION 12]
IMPLICIT OCTET STRING (SIZE (4))
Float64
[APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8))
Float128
[APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16))
It should say:
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 ::=
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
Float32 ::=
[APPLICATION 12]
IMPLICIT OCTET STRING (SIZE (4))
Float64 ::=
[APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8))
Float128 ::=
[APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16))
Errata ID: 231
Status: Verified
Type: Editorial
Reported By: Sally Floyd
Date Reported: 2004-06-07
Section 8 says:
When not in Fast Recovery, the value of the state variable "recover" should be pulled along with the value of the state variable for acknowledgments (typically, "snd_una") so that, when large amounts of data have been sent and acked, the sequence space does not wrap and falsely indicate that Fast Recovery should not be entered (Section 3, step 1, last paragraph).
It should say:
When updating the Cumulative Acknowledgement field outside of Fast Recovery, the "recover" state variable may also need to be updated in order to continue to permit possible entry into Fast Recovery (Section 3, step 1). This issue arises when an update of the Cumulative Acknowledgement field results in a sequence wraparound that affects the ordering between the Cumulative Acknowledgement field and the "recover" state variable. Entry into Fast Recovery is only possible when the Cumulative Acknowledgment field covers more than the "recover" state variable.
Notes:
Errata ID: 230
Status: Verified
Type: Technical
Reported By: Eddy Quicksall
Date Reported: 2004-05-28
Section 3.2 says:
and a Target Session Identifying Handler (TSIH) - each identifying one end of the same session.
It should say:
and a Target Session Identifying Handle (TSIH) - each identifying one end of the same session.
Errata ID: 692
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section Several says:
(2) disposition modifiers
=========================
The disposition modifiers "warning", "superseded", "expired",
"mailbox-terminated" have not seen actual implementation. They have
been deleted from this document.
Accordingly, the syntax production "disposition-type" in section 3.2.6.
(on page 14) and section 7. (on mid-page 22) has been changed to read:
disposition-modifier = "error" / disposition-modifier-extension
Nevertheless, one of these 'removed' modifiers disposition is
mentioned in the text of RFC 3798:
o "warning" :
- section 3.2.7. , 3rd line of text on page 16
It should say:
<Remove any references to "warning">
Notes:
Alexey: The editors have this change in their editorial copy of -bis.
Errata ID: 691
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12
Appendix A
(1) disposition types
=====================
The dispositions "denied" and "failed" were removed from the
document reflecting the lack of implementation or usage ...
Now, the syntax production "disposition-type" in section 3.2.6. (on
page 14) and section 7. (on mid-page 22) has been changed to read:
disposition-type = "displayed" / "deleted"
This means that the RFC 2298 disposition types "dispatched" and
"processed" have been removed from the syntax definitions as well!
Thus, either Appendix A lacks mentioning these removals OR these
items should not have been removed from the syntax definitions.
Nevertheless, all these disposition types removed from the syntax are
mentioned at many places throughout RFC 3798:
o "dispatched" :
- section 3.2.6. , final paragraph of the section on page 16
- section 4. , third-to-last bullet on page 17
- section 4. , first bullet on page 18
o "processed" :
- section 4. , third-to-last bullet on page 17
- section 4. , first bullet on page 18
- section 5. , 4th paragraph on page 18
o "denied" :
- section 2.1. , bottom of page 4
- section 2.1. , end of 3rd paragraph on page 5
- section 4. , third-to-last bullet on page 17
- section 4. , first bullet on page 18
- section 6.2. , end of first paragraph on page 19
o "failed" :
- section 2.2. , middle of second-to-last paragraph on page 6
- section 2.2. , middle of second paragraph on page 7 (twice)
- section 2.2. , third paragraph on page 7 (twice)
- section 3.2.7. , in 2nd text line, on page 16
(mis-spelled "failure" there)
- section 4. , third-to-last bullet on page 17
- section 4. , first bullet on page 18
All these places in the text deal with the issue/sending/generation
of MDNs with the named deprecated disposition types (it would be
acceptable to talk about what to do with *received* such disposition
types for backwards compatibility with RFC 2298) !
It should say:
[not submitted]
Notes:
from pending
--VERIFIER NOTES--
Clearly this document is a mess. The solution is to publish an RFC that cleans up the mess (and verifies that there is indeed consensus to remove the "denied" and "failed" dispositions), not to handle this via the errata process.
Errata ID: 1842
Status: Reported
Type: Technical
Reported By: Vishwas Manral
Date Reported: 2009-08-27
Section 3 says:
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
Constraint-Based LSP Setup using LDP, [RFC3212]."
SYNTAX Unsigned32(0..4294967295)
It should say:
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel for an IPv4 network. For IPv6
this represents an IPv4 address of the ingress or
egress LSR for the tunnel for an IPv6 network.
This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
Constraint-Based LSP Setup using LDP, [RFC3212]."
SYNTAX OCTET STRING(SIZE(16))
Notes:
The Syntax is wrong. This change will require the new TC to be used through out the MPLS MIB modules. A MIB http://potaroo.net/ietf/idref/draft-manral-mpls-rfc3811bis/ was written for the purpose.
Errata ID: 1882
Status: Verified
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2009-09-16
Verifier Name: Adrian Farrel
Date Verified: 2010-08-20
Section MplsLabel says:
* The Generalized-MPLS (GMPLS) label contains a
value greater than 2^24-1 and used in GMPLS
as defined in [RFC3471]."
It should say:
* The Generalized-MPLS (GMPLS) label may contain
a value greater than 2^24-1 and is used in
GMPLS as defined in [RFC3471]."
Notes:
The orriginal text implied that GMPLS labels could only be greater than
(2^24 - 1). In fact all label alues are supported.
Errata ID: 228
Status: Verified
Type: Technical
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section mplsLsrModuleReadOnlyCompliance says:
OBJECT mplsInSegmentNPop
SYNTAX Integer32 (1..1)
MIN-ACCESS read-only
DESCRIPTION "Write access is not required. This object
SHOULD be set to 1 if it is read-only.
It should say:
OBJECT mplsInSegmentNPop
SYNTAX Integer32 (1)
MIN-ACCESS read-only
DESCRIPTION "Write access is not required. This object
SHOULD be set to 1 if it is read-only.
Notes:
Ref: RFC 2578, section 11.1:
- when a pair of values is specified, the first value
must be less than the second value.
Errata ID: 229
Status: Held for Document Update
Type: Editorial
Reported By: Stefan Winter
Date Reported: 2004-11-17
Held for Document Update by: Adrian Farrel
Description says:
"For creating, modifying, and deleting this row.
When a row in this table has a row in the active(1)
state, no objects in this row except this object
and the mplsXCStorageType can be modified. "
It should say:
"For creating, modifying, and deleting this row.
When a row in this table has a row in the active(1)
state, no objects in this row except this object, the
mplsXCStorageType and the mplsXCAdminStatus can be modified."
Errata ID: 227
Status: Rejected
Type: Technical
Reported By: Michael Kirkham
Date Reported: 2005-02-13
Rejected by: Adrian Farrel
Date Rejected: 2010-08-23
MplsFecEntry is defined as:
MplsFecEntry ::= SEQUENCE {
mplsFecIndex IndexInteger,
mplsFecType INTEGER,
mplsFecAddrType InetAddressType,
mplsFecAddr InetAddress,
mplsFecAddrPrefixLength InetAddressPrefixLength,
mplsFecStorageType StorageType,
mplsFecRowStatus RowStatus
}
It should say:
MplsFecEntry ::= SEQUENCE {
mplsFecIndex IndexInteger,
mplsFecType INTEGER,
mplsFecAddrPrefixLength InetAddressPrefixLength,
mplsFecAddrType InetAddressType,
mplsFecAddr InetAddress,
mplsFecStorageType StorageType,
mplsFecRowStatus RowStatus
}
Notes:
Because the OID assignments are:
mplsFecAddrPrefixLength - mplsFecEntry.3
mplsFecAddrType - mplsFecEntry.4
mplsFecAddr - mplsFecEntry.5
--VERIFIER NOTES--
After discussion with an author (Joan Cucchiara), a MIB Doctor (Mike Heard), and an MPLS MIB expert (Tom Nadeau), we conclude that no change is required.
In the words of Mike Heard...
While this may be a poor practice, I don't think it actually
violates RFC 2578. As far as I can see, the only thing it
actually says is this:
7.10. Mapping of the OBJECT-TYPE value
...
(2) If the object corresponds to a conceptual row, then at least one
assignment, one for each column in the conceptual row, is present
beneath that object. The administratively assigned name for each
column is derived by appending a unique, positive sub-identifier to
the administratively assigned name for the conceptual row.
which does not put any ordering constraints on the sub-identifiers.
Unless there is something that I have missed, it seems to me that
this is not actually an erratum.
Errata ID: 737
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-02-23
Held for Document Update by: Lars Eggert
1a)
Section 4.1.2., near the bottom of page 5, says:
"... But when
accessing the rohcInstanceTable (and the rohcContextTable that shares
a part of its index with the rohcInstanceTable) there are many cases
where either a compressor contexts or a decompressor contexts are of
interest. ..."
It should say:
"... But when
accessing the rohcInstanceTable (and the rohcContextTable that shares
a part of its index with the rohcInstanceTable) there are many cases
| where either a compressor context or a decompressor context are of
interest. ..."
1b)
Section 4.3.1., near the bottom of page 8, says:
"... For compressor contexts it optionally contains
managed object containing the numbers of allowed and used packet
sizes. ..."
It should say:
"... For compressor contexts it optionally contains
| managed objects containing the numbers of allowed and used packet
sizes. ..."
2) Textual issues in the ROHC-MIB definition
2a)
The DESCRIPTION clause of the `RohcChannelIdentifierOrZero'
TEXTUAL-CONVENTION (near the bottom of page 10),
"A number identifying a channel.
The value of 0 is indicates that
no channel is identified."
should be:
"A number identifying a channel.
| The value of 0 indicates that
no channel is identified."
2b)
The DESCRIPTION clause for `rohcChannelEntry' (extending from
the last 2 lines on page 11 to page 12) contains inappropriate
text -- obviously borrowed from the Script MIB (RFC 3165,
page 18, last 3 lines) and unintentionally left un-edited:
"An entry describing a particular script. Every script that
is stored in non-volatile memory is required to appear in
this script table.
Note ..."
This should be replaced by appropriate text, e.g.,
| "An entry describing a particular ROHC channel.
Note ..."
[ Please add whatever you consider appropriate here! ]
2c)
The DESCRIPTION clause for `rohcChannelFeedbackFor', on page 13,
seems to me to be not strict enough. Perhaps,
"If no feedback information is transferred on this channel,
then the value of this ID is 0. If the channel type is set
to notInUse(1), then the value of this object must be 0.
If the channel type is rohc(2) and the value of this object
is a valid channel ID, then feedback information is
piggy-backed on the ROHC channel. If the channel type is
should be replaced by:
"If no feedback information is transferred on this channel,
then the value of this ID is 0. If the channel type is set
to notInUse(1), then the value of this object must be 0.
If the channel type is rohc(2) and the value of this object
| is non-zero, then feedback information for this channel is
| piggy-backed and/or interspersed on the same ROHC channel;
| hence the value of this object must be equal to the value
| of the indexing rohcChannelID. If the channel type is
dedicatedFeedback(3), ..."
[or similar].
Rationale:
As far as I understand RFC 3095 (Section 5.2.2 et al.),
it is not possible to intersperse or/and piggyback feedback
information of another channel on a ROHC channel carrying
payload packets.
2d)
The DESCRIPTION clause for `rohcInstanceVendor', on page 15,
contains two issues. Its first sentence contains the word
"description" instead of "compression", and the second sentence
is subject to mis-interpretation due to unfortunate placement of
the words "allocated for the vendor".
I propose to change the text:
"An object identifier that identifies the vendor who
provides the implementation of robust header description.
This object identifier SHALL point to the object identifier
directly below the enterprise object identifier
{1 3 6 1 4 1} allocated for the vendor. ...
to better read:
"An object identifier that identifies the vendor who
| provides the implementation of robust header compression.
This object identifier SHALL point to the object identifier
| allocated for the vendor directly below the `enterprise'
| object identifier {1 3 6 1 4 1}. ...
2e)
The DESCRIPTION clause for `rohcInstanceContextStorageTime',
on page 17, says:
... . The value of this object is used
to initialize rohcContexStorageTime object when a new
context is created.
Changing ...
where it should better say:
... . The value of this object is used
| to initialize the rohcContexStorageTime object when a new
context is created.
Changing ...
2f)
To better distinguish the counters for payload (i. e. IP) packets
from the counters IR packets, I recommend to enhance the sentence:
"Counter of all packets passing this instance."
to read:
| "Counter of all IP packets passing this instance."
in the DESCRIPTION clauses of following two objects:
o `rohcInstancePackets' (page 18),
o `rohcContextPackets' (page 25).
2g)
The DESCRIPTION clause for `rohcProfileVendor', on page 21,
contains the same two issues as the DESCRIPTION clause for
`rohcInstanceVendor'. Hence, the modification given above,
under 2d), should be applied here as well.
2h)
The DESCRIPTION clause for `rohcProfileNegotiated', on page 21,
contains a small typo. It says:
"When retrieved, this boolean object returns true
if the profile has been negotiated to be used at
the instance, i.e., is supported also be the
corresponding compressor/decompressor."
It should say:
"When retrieved, this boolean object returns true
if the profile has been negotiated to be used at
| the instance, i.e., is supported also by the
corresponding compressor/decompressor."
2i)
The DESCRIPTION clause for `rohcContextStorageTime', on page 24,
contains an improper self-reference. Therefore, replace the text:
... . This object returns the remaining time
that the row may exist before it is aged out. The object
is initialized with the value of the associated
rohcContextStorageTime object. After expiration ...
by:
... . This object returns the remaining time
that the row may exist before it is aged out. The object
is initialized with the value of the associated
| rohcInstanceContextStorageTime object. After expiration ...
^^^^^^^^
2j)
The DESCRIPTION clauses for `ContextAllPacketsMeanSize' and
`rohcContextAllHeadersMeanSize', on page 28, are concluded with
the sentence:
The mean value is given in byte rounded to the next
integer value."
This should be:
The mean value is given in bytes rounded to the next
integer value."
[ Note: I wished this RFC (and many other MIB RFCs, too) would
make frequent use of the UNITS clause specified in STD 58 ! ]
3) Textual issues in the ROHC-RTP-MIB definition
3a)
The DESCRIPTION clause for `rohcRtpContextNACKs', on page 42,
says:
"The number of all dynamic negative feedbacks (ACK) sent
or received in this context, respectively.
..."
It should say:
| "The number of all dynamic negative feedbacks (NACK) sent
or received in this context, respectively.
..."
3b)
The DESCRIPTION clause for `rohcRtpContextSNACKs', on page 42,
says:
"The number of all static negative feedbacks (ACK) sent
or received in this context, respectively.
..."
It should say:
| "The number of all static negative feedbacks (STATIC-NACK)
| sent or received in this context, respectively.
..."
It should say:
[see above]
Notes:
from pending
Errata ID: 3051
Status: Held for Document Update
Type: Editorial
Reported By: tom petch
Date Reported: 2011-12-13
Held for Document Update by: Wes Eddy
Section 17 says:
e.g., to the Next-Hop Resolution Protocol [RFC2322
It should say:
e.g., to the Next-Hop Resolution Protocol [RFC2332
Notes:
RFC2322 is van den Hout, K., Koopal, A. and R. van Mook,"Management of IP numbers by peg-dhcp", RFC 2322, 1 April 1998.
RFC2332 is NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D.Piscitello, B. Cole, N. Doraswamy. April 1998
Errata ID: 2954
Status: Held for Document Update
Type: Editorial
Reported By: Frank Cusack
Date Reported: 2011-08-31
Held for Document Update by: Sean Turner
Date Held: 2011-09-01
Section 5.1.2 says:
This implies that Steve must know in advance which other identities may be involved in this distributed application, in order to generate the appropriate ACs which are signed by Steve's ECC.
It should say:
This implies that Steve must know in advance which other identities may be involved in this distributed application, in order to generate the appropriate ACs which are signed by Steve's EEC.
Notes:
s/ECC/EEC/
Errata ID: 225
Status: Verified
Type: Editorial
Reported By: David Peterson
Date Reported: 2004-11-22
Lines 274 and 333 say:
template-version=0.1
It should say:
template-version=1.0
Errata ID: 224
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-09-01
Section 8.1 says:
[IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
It should say:
[IANALDAP] Zeilenga, K., "Internet Assigned Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", RFC 3383, September 2002.
Notes:
Errata ID: 2654
Status: Verified
Type: Technical
Reported By: wu yongming
Date Reported: 2010-12-02
Verifier Name: Tim Polk
Date Verified: 2011-02-23
Section 6.1 says:
* CS ID map info (16 bits): identifies the crypto session(s) for
which the SA should be created. The currently defined map type is
the SRTP-ID (defined in Section 6.1.1).
It should say:
* CS ID map info (variable length): identifies the crypto session(s) for
which the SA should be created. The currently defined map type is
the SRTP-ID (defined in Section 6.1.1).
Notes:
dear editors,
I guess this should be an error. After googling, I found at least one extension draft(MIKEY-TICKET) had also recognized the problem.
If I have mistaken, I would like to hear your clarification.
Errata ID: 223
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2004-09-01
Section 4 says:
A Service Responder MAY deliver the response to the address(es) from the >From field, or to another address from the request payload, provided this behavior is precisely defined in the specification for that service.
It should say:
A Service Responder MAY deliver the response to the address(es) from the From field, or to another address from the request payload, provided this behavior is precisely defined in the specification for that service.
Notes:
Note: This RFC has been obsoleted by RFC5652
Source of RFC: vgmib (int)
Errata ID: 222
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2005-01-22
Section 6.1 says:
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 4
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is absent) OR
(unprotectedAttrs is absent) OR
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2
It should say:
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 4
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is absent) AND
(unprotectedAttrs is absent) AND
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2
Notes:
Errata ID: 1744
Status: Verified
Type: Editorial
Reported By: Jan Vilhuber
Date Reported: 2009-03-26
Verifier Name: Tim Polk
Date Verified: 2009-06-05
Section 5 says:
A recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value. The signer's public key is referenced either by an issuer distinguished name along with an issuer-specific serial number or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer's certificate can be included in the SignedData certificates field.
It should say:
A recipient independently computes the message digest. This message digest and the signer's public key are used to verify the signature value. The signer's public key is referenced in one of two ways. It can be referenced by an issuer distinguished name along with an issuer-specific serial number to uniquely identify the certificate that contains the public key. Alternatively, it can be referenced by a subject key identifier, which accommodates both certified and uncertified public keys. While not required, the signer's certificate can be included in the SignedData certificates field.
Notes:
The original text seems to indicate that a subjectKeyIdentifier also uniquely identifies a certificate, when in fact no certificate may exist at all. This clarification clarifies some possibly conflicting text from the CMC rfc.
Errata ID: 1756
Status: Verified
Type: Editorial
Reported By: Russ Housley
Date Reported: 2009-04-04
Verifier Name: Tim Polk
Date Verified: 2009-06-05
Section 10.1.2 says:
The SignatureAlgorithmIdentifier type identifies a signature algorithm. Examples include RSA, DSA, and ECDSA.
It should say:
The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest alforithm. Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with SHA-256.
Notes:
Some people have taken the original text to mean that compound signature algorithm identifiers should not be used. This is not the case. Section 12.2 of RFC 2630 (the grandfather of RFC 3852) clearly requires the implementation of id-dsa-with-sha1, which is a compound signature algorithm.
Errata ID: 3011
Status: Held for Document Update
Type: Editorial
Reported By: Kaushik N V S
Date Reported: 2011-11-03
Held for Document Update by: Peter Saint-Andre
Section 5.2 says:
An Example Esing MIME multipart/signed
It should say:
An Example Using MIME multipart/signed
Errata ID: 1606
Status: Verified
Type: Technical
Reported By: Kevin Braun
Date Reported: 2008-11-18
Verifier Name: Lisa Dusseault
Date Verified: 2008-11-24
Section 4.4 says:
<xs:pattern value="0(.[0-9]{0,3})?"/>
<xs:pattern value="1(.0{0,3})?"/>
It should say:
<xs:pattern value="0(\.[0-9]{0,3})?"/>
<xs:pattern value="1(\.0{0,3})?"/>
Notes:
As given, the pattern would allow values such as "09", which is not the intention. The metacharacter '.' needs to be escaped.
Errata ID: 221
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-08-31
Section 2.1 says:
An entry may contain multiple attributes with same attribute type but different combinations of language tag (and other) options.
It should say:
An entry may contain multiple attributes with the same attribute type but different combinations of language tag (and other) options.
Errata ID: 220
Status: Verified
Type: Editorial
Reported By: Kurt D. Zeilenga
Date Reported: 2004-08-18
Section 4 says:
A server SHOULD indicate that it supports storing attributes with language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4 as a value of the root DSE.
It should say:
A server SHOULD indicate that it supports storing attributes with language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4 as a value of the "supportedFeatures" [RFC3674] attribute of the root DSE.
Notes:
In section 5, it says:
Implementators of this specification should take care that their use
of language tag options does not impede proper function of
implementations which do not support language tags.
It should say:
Implementors of this specification should take care that their use
of language tag options does not impede proper function of
implementations which do not support language tags.
Errata ID: 1819
Status: Held for Document Update
Type: Technical
Reported By: Enda Murphy
Date Reported: 2009-07-29
Held for Document Update by: Dan Romascanu
Section 5.2 says:
-- The following are used with Processing error alarm.
storageCapacityProblem (151),
memoryMismatch (152),
corruptData (153),
outOfCPUCycles (154),
sfwrEnvironmentProblem (155),
sfwrDownloadFailure (156),
lossOfRealTimel (157),
--A processing error alarm to be issued after the system has
--reinitialised. This will indicate
--to the management systems that the view they have of the managed
--system may no longer
--be valid. Usage example: The managed
--system issues this alarm after a reinitialization with severity
--warning to inform the
--management system about the event. No clearing notification will
--be sent.
applicationSubsystemFailure (158),
configurationOrCustomisationError (159),
databaseInconsistency (160),
fileError (161),
outOfMemory (162),
softwareError (163),
timeoutExpired (164),
underlayingResourceUnavailable (165),
versionMismatch (166),
--Values 168-200 are reserved for processing error alarm related
-- probable causes.
It should say:
-- The following are used with Processing error alarm.
storageCapacityProblem (151),
memoryMismatch (152),
corruptData (153),
outOfCPUCycles (154),
sfwrEnvironmentProblem (155),
sfwrDownloadFailure (156),
lossOfRealTime (157),
-- A processing error alarm to be issued if the system detects that it has lost the time in
-- the real time clock but the clock itself is working. This could happen e.g. during a power
-- cut in a small NE which does not have battery backup for the real time clock.
reinitialized (158),
--A processing error alarm to be issued after the system has
--reinitialised. This will indicate
--to the management systems that the view they have of the managed
--system may no longer
--be valid. Usage example: The managed
--system issues this alarm after a reinitialization with severity
--warning to inform the
--management system about the event. No clearing notification will
--be sent.
applicationSubsystemFailure (159),
configurationOrCustomisationError (160),
databaseInconsistency (161),
fileError (162),
outOfMemory (163),
softwareError (164),
timeoutExpired (165),
underlayingResourceUnavailable (166),
versionMismatch (167),
--Values 168-200 are reserved for processing error alarm related
-- probable causes.
Notes:
It seems to be a copy/paste error from the M.3100 Standard PC text. The comment in the MIB after "lossOfRealTimel" (Note also rogue "l" at the end!) clearly refers to the PC string "reinitialized" instead. It is strange how the integers have continued on from 158 instead of retaining the original values, but anyway, it appears to be a mismatch between the two standards. Ironically I noticed it when I saw that "versionMismatch" had different values (166 and 167).
Errata ID: 1652
Status: Rejected
Type: Technical
Reported By: Brian Bidulock
Date Reported: 2009-01-13
Rejected by: Dan Romascanu
Date Rejected: 2010-05-11
Section 5.4 says:
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> indeterminate (2)
3 -> warning (6)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)
It should say:
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> warning (6)
3 -> indeterminate (2)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)
Notes:
alarmModelState requires that the states be defined from less severe to more severe; however, under ITU-T PerceivedSeverity from ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more severe than "warning". This change corrects the order to match the requirement for order of severity for alarmModelState.
--VERIFIER NOTES--
While the discrepancy between the documents is unfortunate, there is not a technical requirement for the enumeration values to be identical, nor is there a technical requirement for the labels to be identical, even though there is obviously considerable documentation value in avoiding gratuitous differences.
What *is* technically important is that the MIB be able to uniquely represent all the cases from M.3100, and it accomplishes that goal.
In a future version of the document we can add an informative note alerting implementors to the discrepancies in numbering and spelling, so their implementations can include appropriate mapping functions to avoid losing information.
Errata ID: 219
Status: Verified
Type: Editorial
Reported By: Andreas Politze
Date Reported: 2005-08-08
Section 6.3 says:
ituAlarmPerceivedSeverity critical (3)
It should say:
alarmModelState 3
Notes:
However,
ituAlarmPerceivedSeverity critical (3)
should be mapped to
alarmModelState 6
To match the mapping shown in Section 5.4:
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> indeterminate (2)
3 -> warning (6)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)
Errata ID: 218
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01
Section 3 says:
A Message Tracking Status Motification (MTSN) is intended to be
returned as the body of a Message Tracking request [RFC-MTRK-MTQP].
^^^^^^^
It should say:
A Message Tracking Status Motification (MTSN) is intended to be
returned as the body of a Message Tracking response [RFC-MTRK-MTQP].
^^^^^^^^
Errata ID: 216
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01
Section 5 says:
IANA has registered the SMTP extension defined in section 3.
It should say:
IANA has registered the MIME subtype defined in section 3.
Notes:
The text of RFC 3886, Section 5. (on page 8) appears to by copied
unchanged from RFC 3885 and thus does not fit the context of
RFC 3886.
Errata ID: 217
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01
Section 3.1 says:
That body consists of one or more "fields" formatted to
^^
according to...
It should say:
That body consists of one or more "fields" formatted
according to...
Notes:
Extra "to".
Errata ID: 689
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Held for Document Update by: Alexey Melnikov
Section 3.3.5, 3.3.6, 3.3.7 says:
(on page 7):
a) in section 3.3.5 replace:
"The Remote-MTA field is defined as in section Reference 2.3.5 of
[RFC-DSN-STAT]." ...
^^^^^^^^^^
by:
"The Remote-MTA field is defined as in section 2.3.5 of
[RFC-DSN-STAT]." ...
b) in section 3.3.6 replace:
"The Last-Attempt-Date field is defined as in section Reference 2.3.7
of [RFC-DSN-STAT]." ...
^^^^^^^^^^
by:
"The Last-Attempt-Date field is defined as in section 2.3.7 of
[RFC-DSN-STAT]." ...
c) in section 3.3.7 replace:
"The Will-Retry-Until field is defined as in section Reference 2.3.9
of [RFC-DSN-STAT]." ...
^^^^^^^^^^
by:
"The Will-Retry-Until field is defined as in section 2.3.9 of
[RFC-DSN-STAT]." ...
It should say:
[see above]
Notes:
The first line of these sections seem to have inherited some
undue editing history inserting the appropriate references;
the word "Reference" should be removed in every case.
from pending
Errata ID: 214
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Section 5 says:
All optional text provided with the COMMENT command are ignored.
It should say:
All optional text provided with the COMMENT command is ignored.
Errata ID: 215
Status: Verified
Type: Technical
Reported By: Tony Hansen
Date Reported: 2005-11-07
Section 11 says:
...Thus, if an MTQP client/server pair decide to use TLS
confidentially,...
It should say:
... Thus, if an MTQP client/server pair decides to use TLS
confidentially, ...
Errata ID: 213
Status: Held for Document Update
Type: Editorial
Reported By: Rb Srikanth
Date Reported: 2005-07-26
Held for Document Update by: Robert Sparks
Section 1 says:
INVITE sip:bob@bobster.example.org To: <sip:bob@example.org> From: <sip:alice@phone2.example.org>;tag=8983 Call-ID: 09870@phone2.example.org CSeq: 1 INVITE Contact: <sip:alice@phone2.example.org> Require: replaces Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472 <mailto:425928@bobster.example.org;to-tag=7743;from-tag=6472>
It should say:
INVITE sip:bob@bobster.example.org To: <sip:bob@example.org> From: <sip:alice@phone2.example.org>;tag=8983 Call-ID: 09870@phone2.example.org CSeq: 1 INVITE Contact: <sip:alice@phone2.example.org> Require: replaces Replaces: 425928@bobster.example.org;to-tag=8983;from-tag=7743 <mailto:425928@bobster.example.org;to-tag=8983;from-tag=7743>
Errata ID: 1545
Status: Rejected
Type: Editorial
Reported By: Russ Housley
Date Reported: 2008-10-08
Rejected by: RFC Editor
Date Rejected: 2009-02-10
Section 2 says:
Department:
It should say:
Organization:
Notes:
Searching for IPR statements made by a particular organization is more useful than seaching for a department name within an undisclosed organization.
This erratum was rejected because one of the authors (Valerie See) states:
I would (respectfully) disagree with the proposed edit. As I recall, when we authored this (I say "we" in the sense of the co-authors of the RFC), the reason we went with a "department" was to narrow things down within large companies and/or organizations. If you look at a sampling of the IPR disclosures filed with the IETF (admittedly, only from the perspective of my personal opinion), it seems to be generally true that the "patent holder/applicant" field has made the question of "who" (as in "organization") pretty clear.
Particularly since this is only an informational RFC, stating that the use of the template it contains is optional, and given the history, I don't feel that making the fix for the errata is the right thing to do.
Note: This RFC has been obsoleted by RFC6120
Source of RFC: xmpp (app)
Errata ID: 704
Status: Verified
Type: Technical
Reported By: Peter Saint-Andre
Date Reported: 2004-12-08
Section 6.6 says:
It has been brought to my attention that in Section 6.6 of RFC 3920, the
protocol snippet in Step 11 is as follows:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_345'
version='1.0'>
<stream:features/>
Because this is a server-to-server example, the xmlns for that stream
header should instead be 'jabber:server'.
It should say:
[see above]
Notes:
from pending
Errata ID: 212
Status: Verified
Type: Editorial
Reported By: Peter Saint-Andre
Date Reported: 2004-11-05
In Appendix C.1, add the following three lines directly after the opening <xs:schema> tag:
<xs:import namespace='jabber:client'/> <xs:import namespace='jabber:server'/> <xs:import namespace='jabber:server:dialback'/>
Errata ID: 1406
Status: Verified
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-04-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 6.5 says:
The following example shows the data flow for a client authenticating with a server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
It should say:
The following example shows the data flow for a client authenticating with a server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example). The digests (response and rspauth) in steps 6 and 7 of the examples in this and the next section merely show the format, the values don't correspond to the input values for any known password.
Notes:
response=d388dad90d4bbd760a152321f2143af7 and
rspauth=ea40f60335c427b5527b84dbabcdfffd are the digest
values for the first example in RFC 2831 chapter 4.
Errata ID: 2770
Status: Held for Document Update
Type: Editorial
Reported By: Adam Wos
Date Reported: 2011-04-08
Held for Document Update by: Robert Sparks
Section 2 says:
3. The method MUST follow the required procedures (including the
specific algorithms) defined in [CPIM] and [CPP]. In particular,
these documents specify:
* Signing MUST use [SMIME] signatures with [CMS] SignedData.
* Encryption MUST use [SMIME] encryption with [CMS]
EnvelopeData.
^^^^^^^^^^^^
It should say:
3. The method MUST follow the required procedures (including the
specific algorithms) defined in [CPIM] and [CPP]. In particular,
these documents specify:
* Signing MUST use [SMIME] signatures with [CMS] SignedData.
* Encryption MUST use [SMIME] encryption with [CMS]
EnvelopedData.
Errata ID: 698
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2004-11-10
Held for Document Update by: Magnus Westerlund
(1) On page 31, the Informative Reference "[21]" is inconsistent;
author, title, and publication month / year match RFC 2047,
*not* "RFC 1521" as stated there.
(2) The first use of reference "[21]" appears on page 27, in the
10th line of the 2nd paragraph. There, "RFC 2047" _might_ be
what you meant (together with [20] pointing to RFC 2048).
Now, unfortunately, the current basic MIME specifications,
RFC 2045..2049, do not contain a substantial general
discussion of security issues.
The RFC 2045 and RFC 2049 "Security Considerations" just
refer to RFC 2046.
But RFC 2046 for this purpose refers to two specific media
type explanations / 'informal registrations' contained in
the body of that memo, and to RFC 2048, which in turn
does *NOT* contain a "Security Considerations" section.
(NB:
- RFC 2048 just describes the registration PROCEDURES and
states the Security Considerations *requirement* for any
such registrations.
- The formal ['skeleton'] Registrations for the basic MIME
content types / subtypes from RFC 1521 - Appendix F -
unfortunately have been lost on their [expected] way
into RFC 2046. )
RFC 2047, in particular, is an extreme:
"Security issues are not discussed in this memo."
(Section 10 on page 14).
Therefore I suspect that "RFC 2047" might indeed NOT be
what you wanted to refer to in loc. cit. Perhaps the
combination of RFC 2046 and RFC 2048 would have been
the most appropriate selection for this citation.
(3) The second use of reference "[21]" in RFC 3926 appears
2 lines further down in the same paragraph on page 27,
explicitely referring to RFC 1521.
The final statement there on RFC 1521,
"... even though its protocol is obsoleted
by RFC 2048 [20]."
as well does not seem to be very appropriate for me:
It might be disputable whether one should talk about a
"protocol" when talking about message/document format
descriptions, but more substantially, the major part
of RFC 1521 has been superseded by RFC 2046 - see (2)
above - while RFC 2048 only supersedes Appendix E of
RFC 1521, which at the time of its publication already
had been "updated" (i.e. obsoleted) by RFC 1590.
Therefore, it might be appropriate to replace the impacted
bad Informative Reference citation [21] on page 31 of RFC 3926
by two citations (e.g. [21]' and [23]), one for RFC 1521 and
one for RFC 2046, and to modify the above mentioned phrase.
It should say:
[see above]
Notes:
from pending
Errata ID: 210
Status: Verified
Type: Technical
Reported By: Ming Deng
Date Reported: 2007-05-09
Section 3 says:
SSHTRESH
It should say:
SSTHRESH
Notes:
Occurs 3 times.
from pending.
Errata ID: 1433
Status: Reported
Type: Technical
Reported By: Stefan Puiu
Date Reported: 2008-05-30
Section 4.5 says:
The LCCE then checks the Cookie field in the data packet against the Cookie value received in the Assigned Cookie AVP during session establishment.
It should say:
The LCCE then checks the Cookie field in the data packet against the Cookie value sent in the Assigned Cookie AVP during session establishment.
Notes:
Section 5.4.4 contradicts this directly ("All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP"), and seems consistent with the rest of the 'assigned ...' fields.
Errata ID: 211
Status: Verified
Type: Editorial
Reported By: Carlos Pignataro
Date Reported: 2005-10-31
Section 5.4.5 says:
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 32.
It should say:
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 24.
Notes:
Errata ID: 2766
Status: Reported
Type: Editorial
Reported By: Teco Boot
Date Reported: 2011-04-04
Section 4.1.4 says:
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.
It should say:
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet with DF=0 arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.
Notes:
Following RFC 791, IPv4 packets with the DF flag set shall not fragment such packets. RFC 3931 shall not make a precedent for fragmenting IPv4 packets with DF=1.
Errata ID: 209
Status: Verified
Type: Technical
Reported By: John C Klensin
Date Reported: 2006-02-15
Section 2 says:
The I-D must state an explicit "sunset" timeout typically, not to exceed one year after adoption.
It should say:
The I-D must state an explicit "sunset" timeout, typically not to exceed one year after adoption.
Errata ID: 208
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Report Text:
Informative Reference includes [RFC2806]; however, [RFC2806] has been obsoleted by [RFC3966]. All citations and references should reflect this throughout the document.
Errata ID: 708
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Peter Saint-Andre
Section 8 says:
according to BCP 90 (= RFC 3864), the new IMAIL Header Fields, "Caller-ID" and "Caller-Name", as well should get formal IANA registrations listed in the RFC, using the templates from section 4.2. of RFC 3864 !
It should say:
[none submitted]
Notes:
Perhaps, a citation to BCP 90 would also have been appropriate.
from pending
Errata ID: 709
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-24
Minor textual improvements:
a) Change the first line of section 6.1., on page 6, from
"The intent of these headers are to record telephone number that is
sent by the analog phone system with an incoming call without
alteration or interpretation." ...
to:
| "The intent of these headers are to record the telephone number that
^^^
is sent by the analog phone system with an incoming call without
alteration or interpretation." ...
b) In the first line of section '10. Acknowledgments', on page 9,
change:
"The previous authors of versions of this document were Derrick Dunne
and Jason Collins." ...
to:
| "The authors of previous versions of this document were Derrick Dunne
and Jason Collins." ...
It should say:
[see above]
Errata ID: 2251
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11
Section 6 says:
(https//:videnet.unc.edu)
It should say:
| (https://videnet.unc.edu)
Notes:
Corrected a HTTPS URI.
Errata ID: 707
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11
One general inconsistency observed throughout the text, is related
to the use of 'architecture' (singular) vs. 'architectures' (plural).
Since the H.350 series recommendations describe a *single*
[LDAP directory] architecture [extension], I propose to modify the
text to use the singular form in a consistent manner as noted below.
Further, there are a lot of places where I miss expected articles
('the' / 'a' / 'an') -- even in the text that is said to be copied
from the ITU-T Recommendations.
(1)
Change the first 4 (identical) lines of
- 'Abstract' on page 1, and
- '1. Scope' on page 3, from :
"The International Telecommunications Union Standardization Sector
(ITU-T) has created the H.350 series of Recommendations that specify
directory services architectures in support of multimedia
conferencing protocols. The goal of the architecture is to" ...
^^^^^^^^^^^^^^^^!!
to:
"The International Telecommunications Union Standardization Sector
(ITU-T) has created the H.350 series of Recommendations that specify
| a directory services architecture in support of multimedia
conferencing protocols. The goal of the architecture is to" ...
(2)
Change the second paragraph of '1. Scope' on page 3:
"H.350 architectures are not intended to change the operation of
multimedia conferencing protocols in any way. Rather, they are meant
to standardize the way the already defined protocol elements are
stored in a directory, so that they can be accessed in a standardized
manner."
to:
| "The H.350 architecture is not intended to change the operation of
| multimedia conferencing protocols in any way. Rather, it is meant
to standardize the way the already defined protocol elements are
stored in a directory, so that they can be accessed in a standardized
manner."
(3)
In lines 2..4 of '4.1. Scope' on page 4, change:
... "Standardized directory services
can support association of persons with endpoints, searchable white
pages, and clickable dialling." ...
to:
... "Standardized directory services
| can support the association of persons with endpoints, searchable white
pages, and clickable dialling." ...
(4)
In the bottom half of the second paragraph of section 4.1. on
page 5, change:
... "Each of these
disparate systems can access the same underlying data source,
reducing or eliminating the need to coordinate separate management of
each system. A significant benefit to the user is that the
management of this data can be incorporated into existing customer
management tools, allowing for quick and flexible scaling up of
applications. Indeed, many technology providers have already
incorporate LDAP into their products, but have been forced to do so
without benefit of a standardized schema." ...
to:
... "Each of these
disparate systems can access the same underlying data source,
| reducing or eliminating the need to coordinate the separate management
of each system. A significant benefit to the user is that the
management of this data can be incorporated into existing customer
management tools, allowing for quick and flexible scaling up of
applications. Indeed, many technology providers have already
incorporate LDAP into their products, but have been forced to do so
| without the benefit of a standardized schema." ...
(5)
In lines 3..7 of the forth paragraph of section 4.1. on page 5,
change:
... "LDAP provides a
convenient storage location that can be accessed by both call server
and endpoint; thus it is possible to use the directory to support
endpoint configuration, which is important for simplified operation
and supporting user mobility."
to:
... "LDAP provides a
convenient storage location that can be accessed by both call server
| and endpoint; thus it is possible to use the directory to support the
endpoint configuration, which is important for simplified operation
and supporting user mobility."
(6)
In the bottom half of the sixth paragraph of section 4.1. on page 6,
change:
... "Similarly, commObject contains a
pointer, called commOwner, which points to the individual or resource
that is associated with the commObject. In this way, people or
resources can be associated with endpoints. The only change required
in the enterprise directory is the addition of the simple object
class commURI. CommObject data may be instantiated in the same or in
entirely separate directories, thus allowing flexibility in
implementation."
to:
| ... "Similarly, each commObject contains a
pointer, called commOwner, which points to the individual or resource
that is associated with the commObject. In this way, people or
resources can be associated with endpoints. The only change required
| to the enterprise directory is the addition of the simple object
class commURI. CommObject data may be instantiated in the same or in
| an entirely separate directory, thus allowing flexibility in
implementation."
(7)
In the first lines of the final paragraph of section 4.1.2.1,
on page 9, change:
"Note that this example and approach demonstrate extension of the
general commObject object class, and not any individual H.350.x
classes." ...
to:
| "Note that this example and approach demonstrate an extension of the
general commObject object class, and not any individual H.350.x
classes." ...
(8)
In the first line of section 4.2., on page 10, change:
"Auxiliary object class that contains the commURI attribute." ...
to:
| "An Auxiliary object class that contains the commURI attribute." ...
(9)
Change the 'definition' clause of section 5.2.4., on page 20, from:
"Address which specifies the domain location of SIP proxy within
a domain. RFC 3261 defines the role of the SIP proxy."
to:
| "Address which specifies the domain location of a SIP proxy within
a domain. RFC 3261 defines the role of the SIP proxy."
(10)
In the first two lines of the second paragraph of section 7.,
on page 27, change:
"H.350 does not alter the security architectures of any particular
protocol."
to:
| "H.350 does not alter the security architecture of any particular
protocol."
It should say:
[see above]
Errata ID: 2252
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-05-12
Verifier Name: Adrian Farrel
Date Verified: 2010-05-16
Section 11.2 says:
One can classify LSPs into one of a small set of service levels. Among other things, these service levels define the reliability characteristics of the LSP. The service level associated with a given LSP is mapped to one or more P&R schemes during LSP establishment. An advantage that mapping is that an LSP may use different P&E schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection). These details are likely to be service provider specific.
It should say:
One can classify LSPs into one of a small set of service levels. Among other things, these service levels define the reliability characteristics of the LSP. The service level associated with a given LSP is mapped to one or more P&R schemes during LSP establishment. An advantage that mapping is that an LSP may use different P&R schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection). These details are likely to be service provider specific.
Notes:
Mistype error
The change is...
s/P&E/P&R/ in the 6th line
Errata ID: 2096
Status: Verified
Type: Technical
Reported By: Paul Aitken
Date Reported: 2010-03-25
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 5.3 and 6.2. says:
Padding
The Exporter SHOULD insert some padding bytes so that the
subsequent FlowSet starts at a 4-byte aligned boundary. It is
important to note that the Length field includes the padding
bytes. Padding SHOULD be using zeros.
It should say:
Padding
The Exporter SHOULD insert some padding bytes so that the
subsequent FlowSet starts at a 4-byte aligned boundary. It is
important to note that the Length field includes the padding
bytes. The padding length MUST be shorter than any allowable
record in the Set. Padding SHOULD be using zeros.
Notes:
Addition of "The padding length MUST be shorter than any allowable record in the Set."
With small field sizes, such that the record size <= 3, it's not possible to distinguish padding from further data records (s 5.3) or options data records (s 6.2).
eg, with a record length of 3, three records will consume 9 octets. Three octets of padding will be added to this, giving a total length of 12 octets. The 12 octets now look like *four* records. In this case, padding is NOT appropriate.
NB1 the same paragraph in section 6.1 is NOT affected, because the fixed size of the other fields dictates that the only possibility is padding of 2 octets.
NB2 this situation is anticipated in IPFIX (RFC 5101), from which the additional text is taken.
Errata ID: 2168
Status: Verified
Type: Technical
Reported By: Paul Aitken
Date Reported: 2010-04-22
Verifier Name: Nevil Brownlee
Date Verified: 2011-03-14
Section 8 says:
FLOW_SAMPLER_ID 48 1 Identifier shown
in "show flow-sampler"
It should say:
FLOW_SAMPLER_ID 48 N Identifier shown
in "show flow-sampler".
By default N is 4.
Notes:
Change sampler ID field size to N, defaulting to 4. NB smaller sizes may be used. The actual size may be determined from the corresponding NFv9 template.
Errata ID: 2979
Status: Reported
Type: Technical
Reported By: Paul Aitken
Date Reported: 2011-09-26
Section 5.1 says:
Source ID
A 32-bit value that identifies the Exporter Observation Domain.
NetFlow Collectors SHOULD use the combination of the source IP
address and the Source ID field to separate different export
streams originating from the same Exporter.
It should say:
Source ID
A 32-bit value that identifies the Exporter Observation Domain.
NetFlow Collectors SHOULD use the combination of the source IP
address, source port, and the Source ID field to separate different export
streams originating from the same Exporter.
Notes:
Addition of "source port" to separate multiple export streams.
This is already addressed in RFC5101 (IPFIX) as so:
Collecting Processes SHOULD use the Transport Session and the
Observation Domain ID field to separate different export streams
NB transport session = address + ports.
Errata ID: 2106
Status: Verified
Type: Technical
Reported By: Leslie Daigle
Date Reported: 2010-04-02
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-04
Section 6.5 says:
iana-registered-protocol = ALPHA *31ALPHANUM
It should say:
iana-registered-protocol = ALPHA *31ALPHANUMSYM
Notes:
Previous erratum suggested the fix was to add an ALPHANUM production, but the correct fix is to change ALPHANUM to ALPHANUMSYM in this production.
Errata ID: 608
Status: Rejected
Type: Technical
Reported By: Stéphane Bortzmeyer
Date Reported: 2007-10-17
Rejected by: Alexey Melnikov
Date Rejected: 2010-04-05
Section 6.5 says:
iana-registered-protocol = ALPHA *31ALPHANUM
It should say:
Maybe: iana-registered-protocol = ALPHA *31ALPHANUM ALPHANUM = ALPHA / DIGIT
Notes:
The ALPHANUM production is missing from the grammar (and is not in
RFC 4234 either).
Alexey: this was obsoleted by Erratum # 2106.
--VERIFIER NOTES--
Obsoleted by Erratum # 2106, which fixed this properly.
Errata ID: 2050
Status: Held for Document Update
Type: Editorial
Reported By: Daniel Rudolph
Date Reported: 2010-02-24
Held for Document Update by: Robert Sparks
Section 3 says:
UASs using the offer/answer exchange that will carry regular media for sending and receiving early media can cause media clipping, as described in Section 2.1.1 of [8].
It should say:
UASs using the offer/answer exchange that will carry regular media for sending and receiving early media can cause media clipping, as described in Section 2 of [8].
Notes:
There is no section 2.1.1 in RFC 3960 (=reference [8]).
Errata ID: 207
Status: Verified
Type: Editorial
Reported By: Weijun Wang
Date Reported: 2006-04-05
Verifier Name: Tim Polk
Date Verified: 2010-07-20
The Unicode character g-clef used throughout the document says:
"g-clef U+1011E F0 9D 84 9E"
It should say:
"g-clef U+1D11E F0 9D 84 9E"
Errata ID: 873
Status: Verified
Type: Technical
Reported By: Peter Su
Date Reported: 2007-03-26
Verifier Name: Pekka Savola
Date Verified: 2007-03-26
Section 4.1.3 says:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
It should say:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2001:db8::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
Notes:
copy/paste error. Traffic is sent to the native IPv6 node, so the
destination address should be non-2002::/16. When 6to4 is not used,
dst_v4 is not applicable so it could be removed.
from pending
Errata ID: 874
Status: Verified
Type: Technical
Reported By: Peter Su
Date Reported: 2007-03-26
Verifier Name: Pekka Savola
Date Verified: 2007-03-26
Section 4.2.5 says:
The policy control is usually enacted by applying restrictions to
where the routing information for 2002::/16 and/or 192.188.99.0/24
(if the anycast address used [3]) will spread.
It should say:
The policy control is usually enacted by applying restrictions to
where the routing information for 2002::/16 and/or 192.88.99.0/24
(if the anycast address used [3]) will spread.
Notes:
typo in the anycast address.
from pending
Errata ID: 204
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Normative Reference says:
[5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
Rafferty, "File Format for Internet Fax", RFC 3949, November
2004.
It should say:
[5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
Rafferty, "File Format for Internet Fax", RFC 3949, February
2005.
Notes:
[RFC3949] had not yet been published when [RFC3965] was in December, 2004.
Errata ID: 205
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Informative References
[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
It should say:
[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 3851, June 1999.
Notes:
from pending
Errata ID: 206
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Peter Saint-Andre
Report Text:
The Normative Reference [3] should be deleted from section 6.1., on page 10. Rationale: References [1] and [2] from RFC 2305 have been updated, from pointers to RFC 821 and RFC 822, to pointers to RFC 2821 and RFC 2822, respectively. The (normative) updates to RFC 821 and RFC 822 contained in STD 3, RFC 1123 [3], have been incorporated into RFC 2821 and RFC 2822, respectively, which obsolete their predecessors. Hence, the reference to RFC 1123 is no more needed in RFC 3965, and in fact it is not mentioned in the textual body any more.
Errata ID: 711
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-04
Held for Document Update by: Alexey Melnikov
a) Change the first sentence of section 2.1.3, on page 4, from:
"An offramp gateway that operate as an MTA serving multiple users
SHOULD use SMTP;" ...
to:
| "An offramp gateway that operates as an MTA serving multiple users
SHOULD use SMTP;" ...
b) Change the first sentence of section 2.2.4, on page 4, from:
"A single multi-page document SHOULD be sent as a single multi- page
TIFF file, even though recipients MUST process multipart/mixed
containing multiple TIFF files."
to:
| "A single multi-page document SHOULD be sent as a single multi-page
TIFF file, even though recipients MUST process multipart/mixed
containing multiple TIFF files."
c) Change section 5.1. on page 6 from:
"This specification is based on use of existing Internet mail. To
maintain interoperability with Internet mail, any security to be
provided should be part of the of the Internet security
infrastructure, rather than a new mechanism or some other mechanism
outside of the Internet infrastructure."
to:
| "This specification is based on the use of existing Internet mail.
To maintain interoperability with Internet mail, any security to be
| provided should be part of the Internet security infrastructure,
rather than a new mechanism or some other mechanism outside of the
Internet infrastructure."
d) Change the final sentence of section 5.2, on page 6, from:
... "This section reviews relevant concerns about
Internet mail for IFax environments, as well as considering the
potential problems which can result of integrating the existing G3Fax
service with Internet mail."
to:
... "This section reviews relevant concerns about
Internet mail for IFax environments, as well as considering the
| potential problems which can result from integrating the existing
G3Fax service with Internet mail."
e) Change the first paragraph of section 5.2.1, on page 6, from:
"The actual sender of the message might not be the same as that
specified in the Sender or From fields of the message content headers
or the MAIL FROM address from the SMTP envelope."
to:
"The actual sender of the message might not be the same as that
specified in the Sender or From fields of the message content headers
| or the MAIL FROM address in the SMTP envelope."
f) Change the second-to-last paragraph of section 5.2.2, on page 7,
from:
"Originator authentication entails the use of weak or strong
mechanisms, such as cleartext keywords or encryption-based
data-signing, respectively, to determine and validate the identify
of the sender and assess permissions accordingly."
to:
"Originator authentication entails the use of weak or strong
mechanisms, such as cleartext keywords or encryption-based
| data-signing, respectively, to determine and validate the identity
of the sender and assess permissions accordingly."
g) Change the first sentence of the last paragraph of section 5.2.3,
on page 8, from:
"Typically authorization needs to be associated to specific senders
and specific messages, in order to prevent a "replay" attack which
causes and earlier authorization to enable a later dial-out by a
different (and unauthorized) sender." ...
to:
| "Typically authorization needs to be associated with specific senders
and specific messages, in order to prevent a "replay" attack which
| causes an earlier authorization to enable a later dial-out by a
different (and unauthorized) sender." ...
It should say:
[see above]
Notes:
from pending
Errata ID: 202
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-12-04
Verifier Name: Henning Schulzrinne
Date Verified: 2004-12-04
Section 5.1.5 says:
+1-212-555-1 would not be a valid global context, ...
It should say:
+1-212-555-01 would not be a valid global context, ...
Notes:
Although tiny typo, it could possibly be distorting the meaning.
Errata ID: 203
Status: Verified
Type: Editorial
Reported By: Henning Schulzrinne
Date Reported: 2005-03-01
Section 3 says:
isdn-subaddress = ";isub=" 1*uric
It should say:
isdn-subaddress = ";isub=" 1*paramchar
Errata ID: 702
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2004-12-04
Held for Document Update by: Robert Sparks
Section 12 says:
Fate of "fax" and "modem" URI schemes RFC 3966 re-defines the "tel" URI scheme and obsoletes RFC 2806 which defined (and registered) three URI schemes: "tel", "fax", and "modem". Section 12 of RFC 3966 (on page 15) merely states: "references to ... fax and modem URIs ... have been removed." There are *no* IANA considerations included in RFC 3966 regarding the latter URIs. Hence it is not clear whether these URIs are to be regarded as informally "deprecated" or "de-registered" by this RFC, and therefore should be marked accordingly in the IANA 'URI Schemes' reqistry. If however, by existing policy, URI schemes cannot be "deprecated" or "de-registered", the RFC 3966 meta-information should be changed to say "Updates: 2806" instead of "Obsoletes: 2806", and another errata note should be filed to change the RFC 3966 heading accordingly, to avoid the situation of having no more 'valid' documentation for two registered URI schemes.
It should say:
[see above]
Notes:
The fate of the "fax" and "modem" URI schemes should be made clear,
formally, and in an appropriate way.
Henning Schulzrinne:
Requires discussion in the IPTEL working group, where I suggest you
take this discussion. I have my personal opinions as to the deployment
and deployability of the 'fax' URI scheme, but that's not particularly
relevant. I suspect a separate document that performs the appropriate
designation (e.g., historical) would be called for, rather than changing
3996.
from pending
Errata ID: 201
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-03
Held for Document Update by: Russ Housley
Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.
reading the fresh RFC 3967 (== BCP 97), I found that this memo uses
examples which are well known, but not very appropriate, for the
desired purpose:
(1)
HMAC [RFC2104]
This algorithm - since almost three years - is a US Federal
Information Processing Standard!
( FIPS PUB 198, issued '2002 March 6' ;
to download a PDF copy (updated '2002 April 8'), see
<http://crc.nist.gov/publications/fips/index.html> )
This is an active standard published by a recognized standards body.
Therefore, *Normative References* to HMAC in future IETF Standards
Track documents should always refer to FIPS-198 instead of RFC 2104 !
It should say:
[see above]
Notes:
Remark 1:
FIPS-198 in turn refers to RFC 2104 as a readily available
source document for the algorithm, but gives a detailed,
independent description of the algorithm and its application.
Remark 2:
Expect alternative MAC algorithms like UMAC, TTMAC, EMAC,
and RMAC to get formally standardized soon by various Standards
Bodies. For example, the former three Algorithms are already
(since Feb. 2003) recommended for new applications to be used in
the public administration and economy within the European Union.
This has been the result of the NESSIE project - an open contest
similar to the AES contest of NIST's), see
<http://www.cryptonessie.org/> .
from pending
Errata ID: 706
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-01-03
Held for Document Update by: Russ Housley
Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.
(2)
MD5 [RFC1321]
According to the contemporary cryptographic literature, protocols
should now better use SHA-xxx (xxx = [1 / ] 224 / 256 / 384 / 512)
as a cryptographic hashing primitive instead of MD5.
See
- FIPS PUB 180-2, issued '2002 August 1', and amended by
Change Note 1, issued '2004 February 25', for SHA-224,
and
- RFC 3174 (for SHA-1) and RFC 3874 (for SHA-224) -- based on above.
FIPS 180-2 should be used for Normative References in future IETF
Standards Track documents.
It should say:
[see above]
Notes:
Remark 3:
SHA-1 (as well as MD5) already is no more recommended for new
applications to be used in the public administration and economy
within the European Union, see the URL given in Remark 2 above!
from pending
Errata ID: 734
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-02-25
Page 16:
The DESCRIPTION clauses of
- teTunnelOctects and teTunnelLPOctects
- teTunnelPackets and teTunnelLPPackets
are pairwise identical, respectively.
There is no precise description of the precise meaning of
these "teTunnelLPxxx" objects.
Admittedly, one might guess from the SYNTAX clauses of these
objects that "LP" stands for 'lower part' -- meaning that the
value of a "teTunnelLPOctets" object should always equal the
value of the corresponding "teTunnelOctets" object MODULO 2^32
(and similarly for the "...Packets" objects), but this is not
stated in the text.
Furthermore, unfortunately the naming of these objects does
not conform to the conventional naming style used in (almost)
all IETF standards track MIB modules with High Capacity
counters, e. g. "xxxOctets" and "xxxHCOctets" .
The above interpretation would be more manifest if this
standard naming convention would have been followed.
Now, given that the naming of the objects cannot be changed
any more, it would certainly be useful to have a textual
clarification of these DESCRIPTIONs posted on the RFC Editor's
RFC-Errata web page.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 960
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
(1) Section 2 -- wrong reference tags
Near the bottom of page 5, Section 2 of RFC 3971 says:
Neighbor Discovery Protocol (NDP)
| The IPv6 Neighbor Discovery Protocol [7, 8].
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
It should say:
Neighbor Discovery Protocol (NDP)
| The IPv6 Neighbor Discovery Protocol [4, 5].
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
Rationale:
See Section 12.1, on page 50; the proper references are
RFC 2461 [4] and RFC 2462 [5].
Subsequently, on top of page 6, RFC 3971 says:
Non-SEND node
An IPv6 node that does not implement this specification but uses
only the Neighbor Discovery protocol defined in RFCs 2461 and
| 2462, as updated, without security.
^^^^^^^^^^^^
It should say:
Non-SEND node
An IPv6 node that does not implement this specification but uses
only the Neighbor Discovery protocol defined in RFCs 2461 and
| 2462, without security.
Rationale:
Perhaps, there once was a reference to some work in progress,
e.g., what has become RFC 4311, or the 2461bis and 2462bis I-Ds,
and this reference was been removed only partially. Cleanup!
For an alternative text change, see the next item.
(2) Section 3 -- clarification ?
At the bottom of page 6, Section 3 says:
[...] This section is not normative, and if
this section and the original Neighbor Discovery RFCs are in
| conflict, the original RFCs, as updated, take precedence.
^^^^^^^^^^^
It is unclear what has been inteded here. The rationale above
might apply here as well. Or was it intended to say:
[...] This section is not normative, and if
this section and the original Neighbor Discovery RFCs are in
| conflict, the original RFCs, or any updates to these, take
precedence.
^^^^^^^^^^^^^^^^^^^^^^^^
Please comment.
(3) Section 6.4.1 -- spurious word / grammar, and a clarification
(3a)
On page 30, the explanation for 'Source Address' in Section 6.4.1 says:
A link-local unicast address assigned to the sending interface,
| or to the unspecified address if no address is assigned to the
sending interface.
It should say:
A link-local unicast address assigned to the sending interface,
| or the unspecified address if no address is assigned to the
sending interface.
(3b)
The last paragraph of Section 6.4.1, at the bottom of page 31,
(as quoted below) has several issues.
First of all, this sentence apparently does *not* belong to the
discussion of `Valid Options` above it; hence, it should be indented
one step less.
Next, I propose to add an initial article, 'The'.
But most importantly, I suspect that the ICMP lenght specification,
>= 8 , in fact should be: > 8 .
Unfortunately I cannot find a precise statement specifying clearly
that the Trust Anchor option is mandatory in the Certification Path
Solicitation Message, but the explanation 9 lines before the end of
the section,
The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3.
IMHO in fact does imply this.
If that is correct, the final line,
| ICMP length (derived from the IP length) MUST be 8 or more octets.
should say:
| The ICMP length (derived from the IP length) MUST be greater than 8
octets.
(4) Section 6.4.2 -- clarification
Similar to the rationale for item (3b) above, I suspect that
the Certification Path Advertisement Message will always include
at least one Option.
Therefore, the last paragraph of Section 6.4.2, on mid-page 34,
The ICMP length (derived from the IP length) MUST be 8 or more
octets.
should say:
The ICMP length (derived from the IP length) MUST be greater than 8
octets.
(5) Section 6.4.3 -- mis-specification ?
At the bottom of page 34, Section 6.4.3 contains the explanation:
Length
The length of the option (including the Type, Length, Name Type,
| Pad Length, and Name fields), in units of 8 octets.
^^^^^^^^^
It should say:
Length
The length of the option (including the Type, Length, Name Type,
| Pad Length, Name, and Padding fields), in units of 8 octets.
^^^^^^^^^^^^^^^^^^^^
Rationale:
See the explanation for the 'Padding' field, at the bottom of page 35.
(6) Section 6.4.4 -- mis-specification ?
On page 36, Section 6.4.4 contains the explanation:
Length
The length of the option (including the Type, Length, Cert Type,
| Pad Length, and Certificate fields), in units of 8 octets.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It should say:
Length
The length of the option (including the Type, Length, Cert Type,
| Reserved, Certificate, and Padding fields), in units of 8 octets.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Rationale:
Apparently, there's no 'Pad Length' field in the Certificate Option;
the artwork on top of page 36 shows a 'Reserved' field in the same
octet where the Trust Anchor Option carries a 'Pad Length' field,
and the text contains a description of that 'Reserved' field.
According to the explanation for the 'Padding' field at the bottom
of page 36, the length of the 'Padding' field must be derived
implicitely from the ASN.1 encoding of the 'Certificate' field,
and the 'Length' field comprises the length of the 'Padding' field.
Note:
Because the extensible format potentially allows for other Cert Type
values and other Certificate encodings, I am in doubt whether the
decision to include a Reserved octet in place of a Pad Length octet
was very wise.
The current description of the 'Reserved' field will admit a future
revision of that decision.
(7) Section 6.4.5 vs. Section 6.4.6 -- contradiction!
The first paragraph of Section 6.4.5, on page 37, says:
[...]. Future, backward-
| compatible changes to the protocol may specify the contents of the
| Reserved field or add new options; backward-incompatible changes may
use different Code values. [...]
Contrary to that, the first paragraph of Section 6.4.6, on page 38,
says:
[...]. Future, backward-
| compatible changes to the protocol MAY specify the contents of the
| Reserved field or add new options; backward-incompatible changes MUST
use different Code values. [...]
I suspect that the first "may" above should be a "MAY" and the second
"may" should have been a "MUST" as well.
If that's correct, the first paragraph of Section 6.4.5 should say:
[...]. Future, backward-
| compatible changes to the protocol MAY specify the contents of the
| Reserved field or add new options; backward-incompatible changes MUST
use different Code values. [...]
(8) Section 6.4.6 -- missing article
On top of page 39, at the end of the first paragraph there,
Section 6.4.6 says:
[...]. If there are multiple missing certificates, additional CPS
| messages can be sent after getting a response to first one. However,
the complete retrieval process may last at most CPS_RETRY_MAX
seconds.
It should say:
[...]. If there are multiple missing certificates, additional CPS
| messages can be sent after getting a response to the first one.
However, the complete retrieval process may last at most
CPS_RETRY_MAX seconds.
(9) Section 7.4 -- a spurious and a missing article
(9a)
The first paragraph of Section 7.4, on page 41, says:
[...]. This specification also does not apply to addresses
| generated by the IPv6 stateless address autoconfiguration from a
fixed interface identifiers (such as EUI-64).
^ ^^
It should say:
[...]. This specification also does not apply to addresses
| generated by the IPv6 stateless address autoconfiguration from fixed
interface identifiers (such as EUI-64).
(9a)
The last paragraph of Section 7.4, on page 42, says:
v
| The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in proxy Neighbor
Discovery, which is not supported by this specification.
It should say:
vvv
| The Target Address in a Neighbor Advertisement is required to be
equal to the source address of the packet, except in proxy Neighbor
Discovery, which is not supported by this specification.
(10) Section 9.1 -- missing article
The third paragraph of Section 9.1, at the bottom of page 44, says:
v
| There may not be cryptographic binding in SEND between the link layer
frame address and the IPv6 address. An unsecured link layer could
allow nodes to spoof the link layer address of other nodes.
It should say:
vvv
| There may not be a cryptographic binding in SEND between the link
layer frame address and the IPv6 address. An unsecured link layer
could allow nodes to spoof the link layer address of other nodes.
It should say:
[see above]
Notes:
from pending
Errata ID: 2290
Status: Reported
Type: Technical
Reported By: Tony Cheneau
Date Reported: 2010-05-25
Section 5.1 says:
CGA Parameters
A variable-length field containing the CGA Parameters data
structure described in Section 4 of [11].
^^^^^^^^^
It should say:
CGA Parameters
A variable-length field containing the CGA Parameters data
structure described in Section 3 of [11].
^^^^^^^^^
Notes:
The current text points to Section 4 of RFC 3972, which is "CGA Generation". I believe it should point to Section 3 that is "CGA Parameters and Hash Values".
Errata ID: 970
Status: Rejected
Type: Technical
Reported By: Mark Doll
Date Reported: 2007-05-16
Rejected by: Adrian Farrel
Date Rejected: 2011-09-04
Remark: In Section 4.7.10 it says, the 4th value is "The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt."
It should say:
[not submitted]
Notes:
from pending
--VERIFIER NOTES--
This Erratum is complaining that this RFC defines a bit, but then marks it as outside the scope of this document.
While this is bad practice, it does not break any rules and is not grounds for an Erratum. It might be justifiable e use of the bit if anyone is interested.
Furthermore, the Erratum does not make any specific point or propose and resolution.
Errata ID: 967
Status: Verified
Type: Editorial
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,G,I)
} else {
return infinite_assert_metric()
}
}
It should say:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,I)
} else {
return infinite_assert_metric()
}
}
Notes:
In Section 4.6.1, spt_assert_metric(S,I) is defined to have two
parameters, not three.
from pending [error in data transfer corrected 2/15/08.]
Errata ID: 968
Status: Verified
Type: Editorial
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)}
}
It should say:
assert_metric
spt_assert_metric(S,I) {
return {MRIB.pref(S),MRIB.metric(S),my_addr(I)}
}
Notes:
In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.
Errata ID: 969
Status: Verified
Type: Editorial
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}
It should say:
assert_metric
infinite_assert_metric() {
return {infinity,infinity,0}
}
Notes:
In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.
Errata ID: 1524
Status: Verified
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-23
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23
Throughout the document, when it says:
If the argument is a message-id and no such article exists, a 430 response MUST be returned. If the argument is a number or is omitted and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the argument is a number and that article does not exist in the currently selected newsgroup, a 423 response MUST be returned. If the argument is omitted and the current article number is invalid, a 420 response MUST be returned.
It should say:
If the argument is a message-id and no such article exists, a 430 response MUST be returned. If the argument is a number or is omitted, and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the argument is a number and that article does not exist in the currently selected newsgroup, a 423 response MUST be returned. If the argument is omitted and the currently selected newsgroup is valid but the current article number is invalid, a 420 response MUST be returned.
Notes:
A comma should be added after "omitted" in the second sentence. The detail about the validity of the currently selected newsgroup should be added to the last sentence.
Note that this remark applies to sections 6.2.1.2 (ARTICLE), 8.3.2 (OVER) and 8.5.2 (HDR). In the case of OVER and HDR, although the wording is different (ranges are used instead of article numbers), the changes to apply remain the same.
Errata ID: 1525
Status: Verified
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23
Section 3.2.1.1 says:
Example of an attempt to access a facility not available to this connection: [C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 500 Permission denied
It should say:
Example of an attempt to access a facility not available to this connection: [C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 502 Permission denied
Notes:
The response code is 502 in that case because IHAVE is a recognized
command. It is not available to this connection but may be available
from another connection.
Errata ID: 1932
Status: Verified
Type: Technical
Reported By: Julien Élie
Date Reported: 2009-10-25
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03
Section 9.4.3 says:
over-content = 1*6(TAB hdr-content) /
7(TAB hdr-content) *(TAB hdr-n-content)
It should say:
over-content = 7(TAB hdr-content) *(TAB hdr-n-content)
Notes:
Section 8.3.2 describes the OVER command and mentions that there are seven mandatory fields. Though trailing tabs MAY be omitted in OVER responses, it is impossible to have 1*6(TAB hdr-content) owing to the sixth and seventh fields being the metadata :bytes and :lines which are mandatory items (and MUST be computed by the news server).
Less than 7 entries cannot occur for news servers implementing OVER (which should not be confused with XOVER).
Errata ID: 2627
Status: Reported
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-01-14
Throughout the document, when it says:
(a) Section 6.2.1.1 about ARTICLE:
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(b) Section 6.2.1.2, last paragraph about ARTICLE:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a number or is omitted
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a number and that article does not
exist in the currently selected newsgroup, a 423 response MUST be
returned. If the argument is omitted and the current article number
is invalid, a 420 response MUST be returned.
(c) Section 6.2.2.1 about HEAD:
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(d) Section 6.2.3.1 about BODY:
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(e) Section 6.2.4.1 about STAT:
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
(f) Section 8.3.1 about OVER:
Third form (current article number used)
224 Overview information follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(g) Section 8.3.2, last paragraph about OVER:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a range or is omitted
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a range and no articles in that
number range exist in the currently selected newsgroup, including the
case where the second number is less than the first one, a 423
response MUST be returned. If the argument is omitted and the
current article number is invalid, a 420 response MUST be returned.
(h) Section 8.5.1 about HDR:
Third form (current article number used)
225 Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(i) Section 8.5.2, antepenultimate paragraph about HDR:
If the second argument is a message-id and no such article exists, a
430 response MUST be returned. If the second argument is a range or
is omitted and the currently selected newsgroup is invalid, a 412
response MUST be returned. If the second argument is a range and no
articles in that number range exist in the currently selected
newsgroup, including the case where the second number is less than
the first one, a 423 response MUST be returned. If the second
argument is omitted and the current article number is invalid, a 420
response MUST be returned.
It should say:
(a) Section 6.2.1.1 about ARTICLE:
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(b) Section 6.2.1.2, last paragraph about ARTICLE:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a number or is omitted,
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a number or is omitted, and that
article does not exist in the currently selected newsgroup, a 423
response MUST be returned. If the argument is omitted and the currently
selected newsgroup is valid but the current article number is invalid,
a 420 response MUST be returned.
(c) Section 6.2.2.1 about HEAD:
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(d) Section 6.2.3.1 about BODY:
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(e) Section 6.2.4.1 about STAT:
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(f) Section 8.3.1 about OVER:
Third form (current article number used)
224 Overview information follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(g) Section 8.3.2, last paragraph about OVER:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a range or is omitted,
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a range or is omitted, and no articles
in that number range exist in the currently selected newsgroup, including
the case where the second number is less than the first one, a 423
response MUST be returned. If the argument is omitted and the currently
selected newsgroup is valid but the current article number is invalid,
a 420 response MUST be returned.
(h) Section 8.5.1 about HDR:
Third form (current article number used)
225 Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(i) Section 8.5.2, antepenultimate paragraph about HDR:
If the second argument is a message-id and no such article exists, a
430 response MUST be returned. If the second argument is a range or
is omitted, and the currently selected newsgroup is invalid, a 412
response MUST be returned. If the second argument is a range or is
omitted, and no articles in that number range exist in the currently
selected newsgroup, including the case where the second number is less
than the first one, a 423 response MUST be returned. If the second
argument is omitted and the currently selected newsgroup is valid but
the current article number is invalid, a 420 response MUST be returned.
Notes:
RFC 3977 does not define the response code to answer when the third form of ARTICLE, BODY, HDR, HEAD, OVER, and STAT is used while the current article number is valid but does not exist. It is in fact 423: this response code is used by the NNTP reference implementation, as well as major widely used current implementations like INN.
All these commands define that when the argument (or the second argument for HDR) is omitted, the current article number is used.
If 420 is used instead of 423 for that case, RFC 3977 becomes inconsistent regarding the notion of an "invalid current article number", specially for the NEXT and LAST commands. That's why the 423 response code needs to be sent when the current article number is valid but does not exist.
Note that this erratum also takes into account the previously reported erratum 1524.
Errata ID: 2004
Status: Reported
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-01-14
Throughout the document, when it says:
(a) Section 6.2.1.1 about ARTICLE:
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(b) Section 6.2.1.2, last paragraph about ARTICLE:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a number or is omitted
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a number and that article does not
exist in the currently selected newsgroup, a 423 response MUST be
returned. If the argument is omitted and the current article number
is invalid, a 420 response MUST be returned.
(c) Section 6.2.2.1 about HEAD:
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(d) Section 6.2.3.1 about BODY:
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(e) Section 6.2.4.1 about STAT:
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
(f) Section 8.3.1 about OVER:
Third form (current article number used)
224 Overview information follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(g) Section 8.3.2, last paragraph about OVER:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a range or is omitted
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a range and no articles in that
number range exist in the currently selected newsgroup, including the
case where the second number is less than the first one, a 423
response MUST be returned. If the argument is omitted and the
current article number is invalid, a 420 response MUST be returned.
(h) Section 8.5.1 about HDR:
Third form (current article number used)
225 Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
(i) Section 8.5.2, antepenultimate paragraph about HDR:
If the second argument is a message-id and no such article exists, a
430 response MUST be returned. If the second argument is a range or
is omitted and the currently selected newsgroup is invalid, a 412
response MUST be returned. If the second argument is a range and no
articles in that number range exist in the currently selected
newsgroup, including the case where the second number is less than
the first one, a 423 response MUST be returned. If the second
argument is omitted and the current article number is invalid, a 420
response MUST be returned.
It should say:
(a) Section 6.2.1.1 about ARTICLE:
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(b) Section 6.2.1.2, last paragraph about ARTICLE:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a number or is omitted,
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a number or is omitted, and that
article does not exist in the currently selected newsgroup, a 423
response MUST be returned. If the argument is omitted and the currently
selected newsgroup is valid but the current article number is invalid,
a 420 response MUST be returned.
(c) Section 6.2.2.1 about HEAD:
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(d) Section 6.2.3.1 about BODY:
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(e) Section 6.2.4.1 about STAT:
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(f) Section 8.3.1 about OVER:
Third form (current article number used)
224 Overview information follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(g) Section 8.3.2, last paragraph about OVER:
If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a range or is omitted,
and the currently selected newsgroup is invalid, a 412 response MUST
be returned. If the argument is a range or is omitted, and no articles
in that number range exist in the currently selected newsgroup, including
the case where the second number is less than the first one, a 423
response MUST be returned. If the argument is omitted and the currently
selected newsgroup is valid but the current article number is invalid,
a 420 response MUST be returned.
(h) Section 8.5.1 about HDR:
Third form (current article number used)
225 Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
| 423 No article with that number
(i) Section 8.5.2, antepenultimate paragraph about HDR:
If the second argument is a message-id and no such article exists, a
430 response MUST be returned. If the second argument is a range or
is omitted, and the currently selected newsgroup is invalid, a 412
response MUST be returned. If the second argument is a range or is
omitted, and no articles in that number range exist in the currently
selected newsgroup, including the case where the second number is less
than the first one, a 423 response MUST be returned. If the second
argument is omitted and the currently selected newsgroup is valid but
the current article number is invalid, a 420 response MUST be returned.
Notes:
RFC 3977 does not define the response code to answer when the third form of ARTICLE, BODY, HDR, HEAD, OVER, and STAT is used while the current article number is valid but does not exist. It is in fact 423: this response code is used by the NNTP reference implementation, as well as major widely used current implementations like INN.
All these commands define that when the argument (or the second argument for HDR) is omitted, the current article number is used.
If 420 is used instead of 423 for that case, RFC 3977 becomes inconsistent regarding the notion of an "invalid current article number", specially for the NEXT and LAST commands. That's why the 423 response code needs to be sent when the current article number is valid but does not exist.
Note that this erratum also takes into account the previously reported erratum 1524.
Errata ID: 2720
Status: Reported
Type: Technical
Reported By: Julien Élie
Date Reported: 2011-02-15
Section 9.4.3 says:
This syntax defines the content of the various multi-line responses; more precisely, it defines the part of the response in the multi-line data block after any "dot-stuffing" has been undone. The numeric | portion of each non-terminal name indicates the response code that is followed by this data.
It should say:
This syntax defines the content of the various multi-line responses; more precisely, it defines the part of the response in the multi-line data block after any "dot-stuffing" has been undone. The numeric | portion of each non-terminal name indicates the response code of the | initial-reponse-line that is followed by this data.
Notes:
The last sentence in the RFC text is misleading; there may be (and in fact, in several cases — cf. Section 9.4.2, there indeed are) response-arguments between the response code and the data specified by the multi-line-response-content production.
First reported by Alfred Hönes.
Errata ID: 1527
Status: Held for Document Update
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-24
Held for Document Update by: Lisa Dusseault
Section 3.2.1 says:
401: The client must change the state of the connection in some other manner. The first argument of the response MUST be the capability label (see Section 5.2) of the facility that provides the necessary mechanism (usually an extension, which may be a private extension). The server MUST NOT use this response code except as specified by the definition of the capability in question.
Notes:
The 401 code is never dealt with in the whole RFC 3977. Even the definition of the MODE-READER capability does not indicate when the 401 return code should be used.
It should be said that it MUST be used in answers to commands only available after having sent MODE READER. Maybe section 5.3.2 that described the MODE READER command, is the right place to use in order to specify that behaviour.
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] MODE-READER
[S] .
[C] POST
[S] 401 MODE-READER
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] .
[C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: An Example Net
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received OK
Errata ID: 2003
Status: Held for Document Update
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-01-14
Held for Document Update by: Peter Saint-Andre
Throughout the document, when it says:
(a) Section 6.1.3.2, last paragraph about LAST: If the current article number is already the first article of the newsgroup, a 422 response MUST be returned. If the current article number is invalid, a 420 response MUST be returned. If the currently selected newsgroup is invalid, a 412 response MUST be returned. In all three cases, the currently selected newsgroup and current article number MUST NOT be altered. (b) Section 6.1.4.2, last paragraph about NEXT: If the current article number is already the last article of the newsgroup, a 421 response MUST be returned. In all other aspects (apart, of course, from the lack of 422 response), this command is identical to the LAST command (Section 6.1.3).
It should say:
(a) Section 6.1.3.2, last paragraph about LAST: If the currently selected newsgroup is invalid, a 412 response MUST be returned. If the currently selected newsgroup is valid but the current article number is invalid, a 420 response MUST be returned. If the current article number is valid and there is no previous article in the currently selected newsgroup, a 422 response MUST be returned. In all three cases, the currently selected newsgroup and current article number MUST NOT be altered. (b) Section 6.1.4.2, last paragraph about NEXT: If the current article number is valid and there is no next article in the currently selected newsgroup, a 421 response MUST be returned. In all other aspects (apart, of course, from the lack of 422 response), this command is identical to the LAST command (Section 6.1.3).
Notes:
RFC 3977 is unclear about the 421 and 422 response codes: the first article of a newsgroup is defined as its reported low water mark, and the last article as its reported high water mark (see Section 6.1.1.2). However, there MAY be no previous article in the group, although the current article number is not the reported low water mark (see the second paragraph of Section 6.1.3.2). Therefore, a 422 response code MUST also be returned in that case. A similar case for the next article and the 421 response code exists.
The notion of "previous" and "next" article is respectively defined in the first paragraph of Sections 6.1.3.2 and 6.1.4.2.
This erratum also reverses the order of 412, 420, and 421/422 so that it is clearer that an invalid newsgroup or article number takes precedence in determining the return code.
Errata ID: 2037
Status: Held for Document Update
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-02-10
Held for Document Update by: Alexey Melnikov
Section 6.2.1.2 says:
Note that a previously valid article number MAY become invalid if the article has been removed. A previously invalid article number MAY become valid if the article has been reinstated, but this article number MUST be no less than the reported low water mark for that group.
It should say:
Note that a previously valid article number MAY cease to refer to any article if that article has been removed, in which case use of that article number (explicitly or implicitly) will cause a 423 response. A previously removed article may be reinstated (but its number MUST be no less than the reported low water mark for that group), in which case that number will once again refer to that article.
Notes:
The paragraph is misusing the term "invalid article number". The wording should have been something like the corrected text, suggested by Clive Feather.
Errata ID: 2311
Status: Held for Document Update
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-06-24
Held for Document Update by: Alexey Melnikov
Section 8.3.2 says:
For all fields, the value is processed by first removing all CRLF pairs (that is, undoing any folding and removing the terminating CRLF) and then replacing each TAB with a single space. If there is no such header in the article, no such metadata item, or no header or item stored in the database for that article, the corresponding field MUST be empty.
It should say:
For all fields, the value is processed by first removing all CRLF pairs (that is, undoing any folding and removing the terminating CRLF) and then replacing each TAB with a single space. If there is no such header in the article, no such metadata item, or no header or item stored in the database for that article, the corresponding field MUST be empty. If a given header occurs in the article more than once, only the content of the first occurrence is returned by OVER.
Notes:
The precision about using the first occurrence of a given header exists for the HDR command (Section 8.5.2). The same thing should be done for OVER, out of consistency between the two commands.
Note: Maybe future versions of the protocol should consider the notion of concatenation of header fields. (We could transform "Comments: Line 1\r\nComments: Line 2" into "Comments: Line 1 Line 2" in the overview field instead of losing information.)
Errata ID: 2312
Status: Held for Document Update
Type: Technical
Reported By: Julien Élie
Date Reported: 2010-06-24
Held for Document Update by: Alexey Melnikov
Section 8.5.2 says:
If the information is available, it is returned as a multi-line data block following the 225 response code and contains one line for each article in the range that exists.
It should say:
If the information is available, it is returned as a multi-line data block following the 225 response code and contains one line for each article in the range that exists, sorted in numerical order of article number.
Notes:
The precision about using a numerical order exists for the OVER command (Section 8.3.2). The same thing should be done for HDR, out of consistency between the two commands.
Errata ID: 1521
Status: Rejected
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-23
Rejected by: Lisa Dusseault
Date Rejected: 2008-09-29
Section 3.4.1 says:
Except as an effect of the MODE READER command (Section 5.3) on a mode-switching server, once a server advertises either or both of the IHAVE or READER capabilities, it MUST continue to advertise them for the entire session.
It should say:
Except as an effect of the MODE READER command (Section 5.3) on a mode-switching server, once a server advertises either or both of the IHAVE or READER capabilities, it SHOULD continue to advertise them for the entire session.
Notes:
This condition should not be treated as a MUST but as a SHOULD.
Indeed, we can have the following case (amongst others):
* a news server connects to another one in transit mode;
* IHAVE is advertised;
* the news server authenticates via AUTHINFO (an NNTP
extension defined in RFC 4643);
* it is now authorized to only stream articles, thus IHAVE
is no longer available, replaced with STREAMING (an NNTP
extension defined in RFC 4644).
RFC 3977 should not prevent such a case from happening.
Otherwise, it would compel a news server to advertise IHAVE
even though that command is not available to the user.
The same remark also applies to the READER capability.
--VERIFIER NOTES--
This is a request to change the protocol, not an errata. Changes like this need to go through a new RFC.
Errata ID: 1523
Status: Rejected
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-23
Rejected by: Lisa Dusseault
Date Rejected: 2008-09-29
Section 5.3.3 says:
Example of use of the MODE READER command on a mode-switching server:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] MODE-READER
[S] .
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] NEWNEWS
[S] LIST ACTIVE NEWSGROUPS
[S] STARTTLS
[S] .
In this case, the server offers (but does not require) TLS privacy in
its reading mode but not in its transit mode.
It should say:
Example of use of the MODE READER command on a mode-switching server: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] MODE-READER [S] . [C] MODE READER [S] 200 Reader mode, posting permitted [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS [S] STARTTLS [S] . In this case, the server offers (but does not require) TLS privacy in its reading mode but not in its transit mode. Despite the 200 response code, the POST capability is not advertised, indicating that the POST command is not yet available but may become available later (presumably after a TLS negotiation and possibly authentication). This example shows a case where the 200 response code cannot be as accurate or fine-grained as the CAPABILITIES response.
Notes:
This precision should be added because of the comment "Reader mode, posting permitted". It makes it clearer and incidentally provides an interesting example regarding the use of the 200 response code.
--VERIFIER NOTES--
This is a request to change the document, not an erratum.
--RFC EDITOR NOTE--
2009-11-27: The Corrected Text was updated per a request from Julien Élie.
Errata ID: 1526
Status: Rejected
Type: Technical
Reported By: Julien Élie
Date Reported: 2008-09-24
Rejected by: Lisa Dusseault
Date Rejected: 2009-11-23
Section 9.2 says:
mode-reader-command = "MODE" WS "READER"
It should say:
mode-command = "MODE" WS mode-variant mode-variant = keyword
Notes:
Even though the ABNF syntax directly treats MODE READER as a command, MODE is
a base command and READER is a variant of this base command.
Therefore, when the keyword is an invalid mode, the 501 response code is sent:
[C] MODE UNKNOWN
[S] 501 Unknown MODE variant
--VERIFIER NOTES--
the errata contributor asked me to reject it.
Errata ID: 1707
Status: Rejected
Type: Technical
Reported By: Julien Élie
Date Reported: 2009-03-05
Rejected by: Lisa Dusseault
Date Rejected: 2010-01-19
Section 6.1.1.2 says:
o The high water mark will be one less than the low water mark, and the estimated article count will be zero. Servers SHOULD use this method to show an empty group. This is the only time that the high water mark can be less than the low water mark.
It should say:
o The low water mark will be one more than the high water mark, and the estimated article count will be zero. Servers SHOULD use this method to show an empty group. This is the only time that the high water mark can be less than the low water mark.
Notes:
The difference in wording is subtle. The low water mark is one more than
the high water mark (that is to say that the low water mark has increased,
and the high water mark has not decreased). It will permit the following
article arrival to be handled by incrementing the high water mark and
leaving the low water mark unchanged.
To be more precise, if at a given time we have only one article in misc.test
and the following answer to a GROUP command:
[C] GROUP misc.test
[S] 211 1 12 12 misc.test
After cancelling this article, the same GROUP command SHOULD give:
[C] GROUP misc.test
[S] 211 0 13 12 misc.test
Besides, RFC 3977 also mentions in the same section:
The client may make use of the low water mark to
remove all remembered information about articles with lower numbers,
as these will never recur. This includes the situation when the high
water mark is one less than the low water mark.
It should be read as "when the low water mark is one more than the high
water mark". The answer to the previous GROUP command is not
"211 0 12 11 misc.test". Otherwise, a news client may still wrongly
consider that the article whose number is 12 is still present whereas
it could remove it if the low water mark was set to 13.
--VERIFIER NOTES--
Julien asked that this errata be rejected
Errata ID: 1533
Status: Verified
Type: Editorial
Reported By: Julien Élie
Date Reported: 2008-10-01
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-23
Section 5.3.3 says:
Example of use of the MODE READER command on a server that provides reading facilities: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] . [C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.have@example.com> [S] 500 Permission denied [C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test
It should say:
Example of use of the MODE READER command on a server that provides reading facilities: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] . [C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.have@example.com> [S] 500 Unknown command [C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test
Notes:
The response code 500 is sent because this server does not implement the IHAVE command at all. Therefore, IHAVE is not recognized.
Had the server known the command, it would have replied "502 Permission denied" (according to the result of CAPABILITIES, there is no possibility to authenticate or negotiate a TLS layer which could have provided the availability of the command).
Errata ID: 1929
Status: Verified
Type: Editorial
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03
Section 9.2 says:
group-command = "GROUP" [WS newsgroup-name]
It should say:
group-command = "GROUP" WS newsgroup-name
Notes:
The ABNF syntax for the GROUP command makes its argument optional. However, that is not the case. Section 6.1.1 clearly shows that the argument (a newsgroup name) is mandatory.
Errata ID: 1930
Status: Verified
Type: Editorial
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03
Section 7.6.1.2 says:
If the keyword is not recognised, or if an argument is specified and the keyword does not expect one, a 501 response code MUST BE returned. If the keyword is recognised but the server does not maintain the information, a 503 response code MUST BE returned.
It should say:
If the keyword is not recognised, or if an argument is specified and the keyword does not expect one, a 501 response code MUST be returned. If the keyword is recognised but the server does not maintain the information, a 503 response code MUST be returned.
Notes:
So as to be homogeneous with the rest of the document, lower-case letters should be used for the verb after "MUST".
Errata ID: 1931
Status: Verified
Type: Editorial
Reported By: Julien Élie
Date Reported: 2009-10-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-03
Section 6.1.1.3 says:
Example reselecting the currently selected newsgroup: [C] GROUP misc.test [S] 211 1234 234 567 misc.test [C] STAT 444 [S] 223 444 <123456@example.net> retrieved [C] GROUP misc.test [S] 211 1234 234 567 misc.test [C] STAT [S] 223 234 <different@example.net> retrieved
It should say:
Example reselecting the currently selected newsgroup: [C] GROUP misc.test [S] 211 123 234 567 misc.test [C] STAT 444 [S] 223 444 <123456@example.net> retrieved [C] GROUP misc.test [S] 211 123 234 567 misc.test [C] STAT [S] 223 234 <different@example.net> retrieved
Notes:
Section 6.1.1.2 mentions that "if the group is not empty, the estimate MUST be at least the actual number of articles available and MUST be no greater than one more than the difference between the reported low and high water marks".
The count 1234 is not correct because there are less than 567-234+1=334 articles in the newsgroup.
Errata ID: 1522
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2008-09-23
Held for Document Update by: Lisa Dusseault
Section 5.3.3 says:
Example of use of the MODE READER command on a transit-only server (which therefore does not providing reading facilities):
It should say:
Example of use of the MODE READER command on a transit-only server (which therefore does not provide reading facilities):
Errata ID: 1529
Status: Held for Document Update
Type: Editorial
Reported By: Clive Feather
Date Reported: 2008-09-29
Held for Document Update by: Lisa Dusseault
Section 13 says:
Other people who contributed to this document include:
Matthias Andree
Greg Andruk
Daniel Barclay
Maurizio Codogno
Mark Crispin
Andrew Gierth
Juergen Helbing
Scott Hollenbeck
Urs Janssen
Charles Lindsey
Ade Lovett
David Magda
Ken Murchison
Francois Petillon
Peter Robinson
Rob Siemborski
Howard Swinehart
Ruud van Tol
Jeffrey Vinocur
Erik Warmelink
It should say:
Other people who contributed to this document include:
Matthias Andree
Greg Andruk
Daniel Barclay
Maurizio Codogno
Mark Crispin
Julien Elie
Andrew Gierth
Juergen Helbing
Scott Hollenbeck
Urs Janssen
Charles Lindsey
Ade Lovett
David Magda
Ken Murchison
Francois Petillon
Peter Robinson
Rob Siemborski
Howard Swinehart
Ruud van Tol
Jeffrey Vinocur
Erik Warmelink
Notes:
On the basis that at least one of his reported errata is being accepted, insert Julien Elie into this list at the appropriate place.
In those versions that can cope, the first letter of his surname should carry an acute accent (U+00C9).
Errata ID: 2719
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2011-02-15
Held for Document Update by: Peter Saint-Andre
Section 7.2.3 says:
[C] HELP [S] 100 Help text follows [S] This is some help text. There is no specific | [S] formatting requirement for this test, though [S] it is customary for it to list the valid commands [S] and give a brief definition of what they do. [S] .
It should say:
[C] HELP [S] 100 Help text follows [S] This is some help text. There is no specific | [S] formatting requirement for this text, though [S] it is customary for it to list the valid commands [S] and give a brief definition of what they do. [S] .
Notes:
A simple typo "test" -> "text".
First reported by Alfred Hönes.
Errata ID: 2721
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2011-02-15
Held for Document Update by: Peter Saint-Andre
Section 14 says:
Section 14.1 (Normative References):
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
It should say:
Section 14.2 (Informative References):
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
Notes:
This Reference should be moved to the Informative References (Section 14.2) because:
* RFC 3977 is published as Proposed Standard, and it has formally obsoleted RFC 977, thus removing it from the Standards track.
* Normative References in a Standards Track RFC must be at a comparable (or higher) level on the IETF Standards Track (or at similar position in other Standards Bodies' scheme).
* All uses of the Ref. tag [RFC977] are non-normative in nature.
First reported by Alfred Hönes.
Note: This RFC has been obsoleted by RFC5378
Source of RFC: ipr (gen)
Errata ID: 200
Status: Verified
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2005-07-02
Section 4.2 says:
(B) to prepare or allow the preparation of translations of the RFC
into languages other than English.
It should say:
(B) to prepare or allow the preparation of translations of the RFC
into languages other than English,
Notes:
In Section 5.3, it says:
This notice can be used on IETF Contributions that are intended to
provide background information to educate and to facilitate
discussions within IETF working groups but are not intended to be
published as an RFCs.
It should say:
This notice can be used on IETF Contributions that are intended to
provide background information to educate and to facilitate
discussions within IETF working groups but are not intended to be
published as RFCs.
Errata ID: 199
Status: Verified
Type: Editorial
Reported By: Stephane Bortzmeyer
Date Reported: 2005-01-09
Appendix A says:
he whois application protocol label refers to RFC 954 [19].
It should say:
he whois application protocol label refers to RFC 3912 [19].
Notes:
Errata ID: 1305
Status: Verified
Type: Technical
Reported By: Marcos Sanz
Date Reported: 2008-01-29
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01
Section 4 says:
<group
name="partialMatchGroup">
<choice>
<sequence>
<element
name="beginsWith">
<simpleType>
<restriction
base="token">
<minLength
value="1"/>
</restriction>
</simpleType>
</element>
<element
minOccurs="0"
name="endsWith">
<simpleType>
<restriction
base="token">
<minLength
value="1"/>
</restriction>
</simpleType>
</element>
</sequence>
<element
name="endsWith">
<simpleType>
<restriction
base="token">
<minLength
value="1"/>
</restriction>
</simpleType>
</element>
</choice>
</group>
It should say:
<group name="partialMatchGroup"> <choice> <sequence> <element name="beginsWith" type="dreg:partialMatchComponentType"/> <element name="endsWith" type="dreg:partialMatchComponentType" minOccurs="0"/> </sequence> <element name="endsWith" type="dreg:partialMatchComponentType"/> </choice> </group> <simpleType name="partialMatchComponentType"> <restriction base="token"> <minLength value="1"/> </restriction> </simpleType>
Notes:
The original definition of the group "partialMatchGroup" violates the rule of consistent element declaration in XML schema:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-element-consistent
In order to fix the schema without introducing any semantic changes, a type declaration has been created, which makes the schema valid and more compact.
Errata ID: 2525
Status: Verified
Type: Technical
Reported By: Christopher Yeleighton
Date Reported: 2010-09-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section 3.1 says:
Advice for designers of new URI schemes can be found in [RFC2718].
It should say:
Advice for designers of new URI schemes can be found in [RFC4395].
Notes:
The document [RFC2718] is for designers of designers of new URL schemes only. It has been obsoleted by [RFC4395] that covers all URI schemes.
[RFC4395]
T. Hansen, T. Hardie, T. and L. Masinter,
"Guidelines and Registration Procedures for New URI Schemes",
RFC 4395, February 2006.
Errata ID: 2624
Status: Held for Document Update
Type: Technical
Reported By: Peter Saint-Andre
Date Reported: 2010-11-11
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-03-30
Section Appendix B says:
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
It should say:
/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/
Notes:
This is a copy of Erratum #1933, reported against RFC 2396.
Errata ID: 2933
Status: Reported
Type: Editorial
Reported By: Bjoern Hoehrmann
Date Reported: 2011-08-13
Section 5.2.2. says:
T.path = merge(Base.path, R.path);
It should say:
T.path = merge(Base, R);
Notes:
In 5.2.3. the "If the base URI has a defined authority component" condition requires knowing the authority component, so passing just the path component is misleading.
Errata ID: 2033
Status: Held for Document Update
Type: Editorial
Reported By: Tanaka Akira
Date Reported: 2010-02-05
Held for Document Update by: Alexey Melnikov
Section 3.3. says:
path-empty = 0<pchar>
It should say:
path-empty = ""
Notes:
According to ABNF, 0<pchar> is interpreted as
zero repeatation of the prose-val: pchar.
However pchar is an non-terminal.
So I think the production should be follows:
path-empty = 0pchar
However this production means a empty string.
So
path-empty = ""
is more clear.
Appendix A. has also the same production.
Errata ID: 1783
Status: Rejected
Type: Editorial
Reported By: Christopher Yeleighton
Date Reported: 2009-05-15
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15
Section 3.1. says:
Advice for designers of new URI schemes can be found in [RFC2718].
It should say:
Advice for designers of new URL schemes can be found in [RFC2718].
Notes:
[RFC2718] does not contain advice for designers of new URN schemes; it is applies to URL schemes only and it is titled accordingly.
The information as published is misleading.
--VERIFIER NOTES--
Given that RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") obsoletes the referenced RFC 2718 ("Guidelines for new URL Schemes"), this erratum is best considered in error.
Errata ID: 2717
Status: Rejected
Type: Editorial
Reported By: Winfred Qin
Date Reported: 2011-02-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16
Section 3 says:
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
It should say:
hier-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-rootless
/ path-empty
Notes:
There are four ABNF rules for path, but the following words says:
'These restrictions result in five different ABNF rules for a path (Section 3.3)'
And in section 3.3, there are five rules.
--VERIFIER NOTES--
PSA: There is no error here, because the hierarchical part excludes
paths that are not preceded by "//", whereas the path rule includes
paths that are not preceded by "//" (thus five rules for "path" but
only four rules for "hier-part").
Errata ID: 631
Status: Verified
Type: Technical
Reported By: Martin Duerst
Date Reported: 2007-06-26
Throughout the document, when it says:
[semicolon outside] "http://example.org/rosé";
It should say:
[semicolon inside] "http://example.org/rosé"
Notes:
In ALL cases, the final semicolon has to be inside the double quotes, not outside. See the example above.
from pending
Errata ID: 629
Status: Verified
Type: Editorial
Reported By: Martin Duerst
Date Reported: 2007-06-26
Section 3.1 says:
Syntaxical.
It should say:
Syntactical.
Notes:
from pending
Errata ID: 2783
Status: Verified
Type: Technical
Reported By: Peter Zehler
Date Reported: 2011-04-18
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14
Section 8.1 says:
8.1. 'hold-new-jobs' Value
'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
(see section 3.3.1) or other means, but the output-device(s) are
taking an appreciable time to stop. Later, when all output has
stopped, the "printer-state" becomes 'stopped', and the 'paused'
value replaces the 'moving-to-paused' value in the "printer-
state-reasons" attribute. This value MUST be supported if the
Hold-New-Jobs operation is supported and the implementation takes
significant time to pause a device in certain circumstances.
It should say:
8.1. 'hold-new-jobs' Value
'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
(see section 3.3.1) or has initiated the holding of new jobs by
other means. This value indicates that all Jobs subsequently
submitted to the Printer will be placed into the ‘pending-held’
state. Thus all newly accepted jobs will be automatically held
by the Printer. This “printer-state-reasons” value will be removed
when the Operator issues the Release-Held-New-Jobs Operation or
releases the holding of new jobs by other means.
Notes:
This is a cut and paste error.
Note that the definition of the Hold-New-Jobs operation (3.3.1) states:
"When the Printer completes all the 'pending' and 'processing' jobs,
it enters the 'idle' state as usual. An operator monitoring Printer
state changes will know when the Printer has completed all current
jobs because the Printer enters the 'idle' state."
Thus the Printer does not enter the ‘stopped’ state as currently indicated in the text. It is the Pause-Printer
and Pause-Printer-After-Current-Job operations that move the state of the Printer to stopped’ and put the
‘moving-to-paused’ or ‘paused’ values into “printer-state-reasons”.
Errata ID: 1462
Status: Verified
Type: Technical
Reported By: Avi Lior
Date Reported: 2008-07-08
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09
Section 9.6 says:
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
It should say:
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
Errata ID: 1946
Status: Rejected
Type: Technical
Reported By: Avi Lior
Date Reported: 2009-11-25
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02
Section 9.2 says:
If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets, or Accounting-Output-Packets AVPs are present, they must be translated to the corresponding RADIUS attributes. If the value of the Diameter AVPs do not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords must be used.
It should say:
If the Accounting-Input-Octets, Accounting-Output-Octets, AVPs are present, they must be translated to the corresponding RADIUS attributes. If the value of the Diameter AVPs do not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords must be used.
Notes:
The last sentence of the original text causes confusion because according to RFC2869, the Acct-Input/Output-Gigawords are only overflows for the Acct-Input/Output-Octet attributes.
THE ABOVE CORRECTION BASICALLY DOES NOT PROVIDE FOR OVERFLOW FOR THE PACKET COUNTERS.
--VERIFIER NOTES--
The working group discussion on this item led to the following text change being recommended:
If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets, or Accounting-Output-Packets AVPs are present, they SHOULD be translated to the corresponding RADIUS attributes. However, if the value of the Accounting-Input-Octets AVP or Accounting-Output-Octets AVP does not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input-Gigawords and Acct-Output-Gigawords Attributes must be used.
Care must be taken when interworking Diameter with RADIUS due to the fact that there is no attribute available in RADIUS to record overflows in packet counters. One remedy that can be used is to limit the session time such that packet counter do not overflow. Another remedy would be to ignore the packet counters altogether and just rely on the octet counters.
Errata ID: 2563
Status: Held for Document Update
Type: Editorial
Reported By: Hans Liu
Date Reported: 2010-10-14
Held for Document Update by: Dan Romascanu
Section 10.1 says:
The occurrence of route-record AVP in AAA is 0+.
It should say:
The occurrence of route-record AVP in AAA should be 0 according to AAA definition of section 3.2.
Notes:
In 3GPP Rx application TS 29.214, AAA command contains no route-record AVP either. So section 10.1 of RFC4005 needs to be corrected.
Note: This RFC has been obsoleted by RFC4269
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 751
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Russ Housley
(A)
>
> Unfortunately, within a few lines in the RFC text, the variable name 'X'
> gets used for two very distinct purposes and contexts:
>
> o X = X0 || X1 || X2 || X3 (2)
> ... the 32 bit wide input to the function G
>
> o X used as formal argument in the defining equations for
> the 'SS-boxes' SS0 ... SS3
> ... a single octet (8 bit wide entity),
> [application of the formulas - see (3) below - will
> substitute X0, ..., X3 in turn for the arguments]
>
> Perhaps, it would have been better to use another symbol, e.g. 'x', for the
> latter purpose.
>
>
> (B)
>
> As far as I can see, feeding the definition of the SS-boxes given in the
> last 4 text/formule lines on page 3 into the formula on top of page 4,
>
> Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)
>
> does ***NOT*** yield the same result as using the primary defining formulas
> given for Z0 ... Z3 in the first formula block of section 2.2., together
> with
>
> Z = Z0 || Z1 || Z2 || Z3 (1).
>
> I suspect a mis-ordering in the use of m0 ... m3 in the equations defining
> SS0 ... SS3 :
>
> With regard to the formulas (1), (2), and (3) (as numbered above), the
> 'matrix' pattern of the 4x4 terms in braces { ... } , obtained from the
> formula block defining SS0 ... SS3 by substitution of Xi for the argument of
> SSi (i=0,1,2,3) - as required in (3) -, should be the matrix transpose of
> the pattern of the same terms in braces appearing in the formula block
> defining Z0 ... Z3 , e. g. the first 'column' of {...} terms for SSi()
> should contain the {...} terms appearing in the formula for Z0.
> But this is not the case.
>
> Therefore, I suspect that the last 6 text/formula lines on page 3 of RFC
> 4009 should in fact read (including the enhancement from (A)
> above):
>
> "
> To increase the efficiency of the G function, four extended S-boxes
> 'SS-box' (See Appendix A.2) are defined as follows:
>
> SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3}
> SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0}
> SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1}
> SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2}
> "
>
>
> In this case, I also recommend to include a textual enhancement for the
> first sentence of section 2.3., replacing:
>
> "The key schedule generates each round subkeys."
> by:
> "The key schedule generates subkeys for each round."
>
> And finally, for completeness, it would have been useful as well to give
> additional Informational Reference(s) for the seedMAC (and the
> [seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. - e.g. RFC
> 3610 (and RFC 2451 / NIST SP 800-38A) [?].
It should say:
[see above]
Notes:
from pending
Errata ID: 752
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Russ Housley
(C)
First, a formal issue with the ASN.1 given in the RFC text:
In the ASN.1 definitions in section 2.5., it would perhaps be more
natural and consistent with the requirements from the text (and the
ASN.1 comment already present there!) to give an explicit SIZE
restriction in the definition of the syntax of the initialization
vector for SEED in CBC mode (which indeed *MUST* be 16 octets long).
To this end, I recommend to replace the 7th text line of section 2.5.,
"seedCDCParameter ::= OCTET STRING -- 128-bit Initialization Vector"
by:
| "seedCDCParameter ::= OCTET STRING (SIZE(16))
| -- 128-bit Initialization Vector"
(D)
The text in section 2.2. talks about two basic 8x8 S-boxes, named
"S1" and "S2". Contrary to that, Appendix A.1. (on page 7) gives
tables for "S-Box S0" and "S-Box S1".
It would be easier to change the headlines in Appendix A.1.,
but, given the numbering style of all other formula elements,
it is certainly be more appropriate and consistent to modify the
equations in section 2.2., replacing "S1" by "S0", and "S2" by "S1".
I'll give a full replacement text for section 2.2. below, covering
this issue as well.
[ Now, returning to the open issue ... ]
(B)
In short, sorry, I do NOT agree with your definition of the SS-boxes.
It does not conform with the primary definition of the function G.
Below, I'll give you a detailed step-by-step explanation, using a
concrete example, for the reasoning already presented in my first
mail.
Note: For brevity and due to the email line length restriction,
in the subsequent reasoning, I will omit the braces '{ ... }'
around the ANDed terms, making use of the usual precedence rule
for multiplication over addition and the facts that
- the '^' operation is the normal addition in the 8 / 32 dimensional
vector spaces over GF(2) we are working on,
- '&' representing the 8 / 32 fold tensor product of the scalar
multiplication over GF(2) .
I repeat and extend the numeration of the formulas from my first
email, already applying item (D).
X = X0 || X1 || X2 || X3 (2)
... the 32 bit wide input to the function G;
Z = Z0 || Z1 || Z2 || Z3 (1)
... the 32 bit wide output of the function G applied to X;
with the 8-bit wide components computed by the application
of the two S-Boxes S0 and S1 via the equations:
Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0)
Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1)
Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2)
Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3)
with m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F (1.4)
The alternate description of the Function G is to be
Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)
where, below, I'll try "my" version of the SS-Box definition ...
SS0(x) = S0(x) & m0 || S0(x) & m1 || S0(x) & m2 || S0(x) & m3 (4.0)
SS1(x) = S1(x) & m1 || S1(x) & m2 || S1(x) & m3 || S1(x) & m0 (4.1)
SS2(x) = S0(x) & m2 || S0(x) & m3 || S0(x) & m0 || S0(x) & m1 (4.2)
SS3(x) = S1(x) & m3 || S1(x) & m0 || S1(x) & m1 || S1(x) & m2 (4.3)
... and the version from the text (with the formal changes already
discussed properly applied) ...
SS0(x) = S0(x) & m3 || S0(x) & m2 || S0(x) & m1 || S0(x) & m0 (5.0)
SS1(x) = S1(x) & m0 || S1(x) & m3 || S1(x) & m2 || S1(x) & m1 (5.1)
SS2(x) = S0(x) & m1 || S0(x) & m0 || S0(x) & m3 || S0(x) & m2 (5.2)
SS3(x) = S1(x) & m2 || S1(x) & m1 || S1(x) & m0 || S1(x) & m3 (5.3)
With these notations, let's challenge the example octet sequence
X0 = 0x09 , X1 = 0x11 , X2 = 0xE1 , X3 = 0xF9 (6a)
i.e., by (2) : X = (0x) 09 11 E1 F9 (6b)
Applying the tables from Appendix A.1., we obtain (*) :
S0(X0) = 0x43 ,
S1(X1) = 0x62 ,
S0(X2) = 0xB9 ,
S1(X3) = 0x4C .
To first compute Z with the original definition of G, substituting
(*) and (1.4) into (1.0) .. (1.3), we obtain, step by step:
Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0)
= 0x43 & 0xFC ^ 0x62 & 0xF3 ^ 0xB9 & 0xCF ^ 0x4C & 0x3F
= 0x40 ^ 0x62 ^ 0x89 ^ 0x0C
==>
Z0 = 0xA7 (7.0)
Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1)
= 0x43 & 0xF3 ^ 0x62 & 0xCF ^ 0xB9 & 0x3F ^ 0x4C & 0xFC
= 0x43 ^ 0x42 ^ 0x39 ^ 0x4C
==>
Z1 = 0x74 (7.1)
Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2)
= 0x43 & 0xCF ^ 0x62 & 0x3F ^ 0xB9 & 0xFC ^ 0x4C & 0xF3
= 0x43 ^ 0x22 ^ 0xB8 ^ 0x40
==>
Z2 = 0x99 (7.2)
Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3)
= 0x43 & 0x3F ^ 0x62 & 0xFC ^ 0xB9 & 0xF3 ^ 0x4C & 0xCF
= 0x03 ^ 0x60 ^ 0xB1 ^ 0x4C
==>
Z3 = 0x9E (7.3)
Putting (7.0) .. (7.3) together using (1), we get the byte sequence
Z = Z0 || Z1 || Z2 || Z3 (1)
==>
Z = (0x) A7 74 99 9E (7)
Now let's see what happens when we apply "my" definition of the
SS-Boxes, substituting (6a), (*), and (1.4) into (4.0) .. (4.3) :
SS0(X0) = S0(X0) & m0 || S0(X0) & m1 || S0(X0) & m2 || S0(X0) & m3
= 0x43 & 0xFC || 0x43 & 0xF3 || 0x43 & 0xCF || 0x43 & 0x3F
= 0x40 || 0x43 || 0x43 || 0x03
==>
SS0(X0) = (0x) 40 43 43 03 (8.0)
SS1(X1) = S1(X1) & m1 || S1(X1) & m2 || S1(X1) & m3 || S1(X1) & m0
= 0x62 & 0xF3 || 0x62 & 0xCF || 0x62 & 0x3F || 0x62 & 0xFC
= 0x62 || 0x42 || 0x22 || 0x60
==>
SS1(X1) = (0x) 62 42 22 60 (8.1)
SS2(X2) = S0(X2) & m2 || S0(X2) & m3 || S0(X2) & m0 || S0(X2) & m1
= 0xB9 & 0xCF || 0xB9 & 0x3F || 0xB9 & 0xFC || 0xB9 & 0xF3
= 0x89 || 0x39 || 0xB8 || 0xB1
==>
SS2(X2) = (0x) 89 39 B8 B1 (8.2)
SS3(X3) = S1(X3) & m3 || S1(X3) & m0 || S1(X3) & m1 || S1(X3) & m2
= 0x4C & 0x3F || 0x4C & 0xFC || 0x4C & 0xF3 || 0x4C & 0xCF
= 0x0C || 0x4C || 0x40 || 0x4C
==>
SS3(X3) = (0x) 0C 4C 40 4C (8.3)
Note: Please observe that the terms in (8.0) .. (8.3) are indeed
the same terms as in (7.0) .. (7.3), but in 4x4 matrix transposed
order -- as stated abstractly in my first email.
Summing up (8.0) .. (8.3) according to (3), we get what should be
the alternate definition of G(X) :
Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)
= (0x) 40 43 43 03 ^ -- from (8.0)
(0x) 62 42 22 60 ^ -- from (8.1)
(0x) 89 39 B8 B1 ^ -- from (8.2)
(0x) 0C 4C 40 4C -- from (8.3)
==> -----------
Z = (0x) A7 74 99 9E (8)
Obviously, (8) indeed is identical to (7).
Finally, let's look for what we get with your definition of the
SS-Boxes, substituting (6a), (*), and (1.4) into (5.0) .. (5.3) :
SS0(X0) = S0(X0) & m3 || S0(X0) & m2 || S0(X0) & m1 || S0(X0) & m0
= 0x43 & 0x3F || 0x43 & 0xCF || 0x43 & 0xF3 || 0x43 & 0xFC
= 0x03 || 0x43 || 0x43 || 0x40
==>
SS0(X0) = (0x) 03 43 43 40 (9.0)
SS1(X1) = S1(X1) & m0 || S1(X1) & m3 || S1(X1) & m2 || S1(X1) & m1
= 0x62 & 0xFC || 0x62 & 0x3F || 0x62 & 0xCF || 0x62 & 0xF3
= 0x60 || 0x22 || 0x42 || 0x62
==>
SS1(X1) = (0x) 60 22 42 62 (9.1)
SS2(X2) = S0(X2) & m1 || S0(X2) & m0 || S0(X2) & m3 || S0(X2) & m2
= 0xB9 & 0xF3 || 0xB9 & 0xFC || 0xB9 & 0x3F || 0xB9 & 0xCF
= 0xB1 || 0xB8 || 0x39 || 0x89
==>
SS2(X2) = (0x) B1 B8 39 89 (9.2)
SS3(X3) = S1(X3) & m2 || S1(X3) & m1 || S1(X3) & m0 || S1(X3) & m3
= 0x4C & 0xCF || 0x4C & 0xF3 || 0x4C & 0xFC || 0x4C & 0x3F
= 0x4C || 0x40 || 0x4C || 0x0C
==>
SS3(X3) = (0x) 4C 40 4C 0C (8.3)
Summing up (9.0) .. (9.3) according to (3), we get
Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)
= (0x) 03 43 43 40 ^ -- from (9.0)
(0x) 60 22 42 62 ^ -- from (9.1)
(0x) B1 B8 39 89 ^ -- from (9.2)
(0x) 4C 40 4C 0C -- from (9.3)
==> -----------
Z = (0x) 9E 99 74 A7 (9)
This is NOT the same as (7).
In fact, it is the byte-reversed sequence from (7) .
-- Bingo!
Taking a closer look at (5.0) .. (5.3), I now see that indeed the
terms in these equations are in the reverse concatenation sequence
compared to (4.0) .. (4.3) !
After a detailed inspection of the tables given in Appendix A.2.
of RFC 4009, it now becomes clear that -- disregarding the IETF
conventions to represent all binary data in network byte order,
and without any further notice of this fact -- these tables do NOT
represent octect sequences (as expected from the presentation of
above formula using octet concatenation, not arithmetic left-shift
or multiply-by-256 operations), BUT the hexadecimal representation
of the proper 4-octet sequences improperly cast into 32 bit numbers
on a 'little endian' processor, i.e., without using the ntohl()
intrinsic!
I suspect that your definition of the SS-boxes (5.0) .. (5.3) has
been inadvertently retrofitted to match the values given in the
tables in Appendix A.2., again re-formulating the printed byte
order (which is NOT the storage byte order [= octet concatenation
order] in a little endian processor) using the octet concatenation
notation / formalism.
Because definition of the function G according to section 2.2. does
not make use of 32-bit integer arithmetic operations, I recommend
to clarify the situation by
o giving formula (4.0) .. (4.3) for the SS-Boxes, consistent
with the other formulas, and
o stating explicitely in Appendix A.2. that these tables give
byte reversed presentations of the octet sequences to be
used as the output of the SS-boxes.
To catch up, here's my proposed replacement text for the whole
section 2.2. of RFC 4009, covering the issues (A), (B), and (D)
mentioned so far:
---------------- cut here -------------------------------
2.2. The Function G
The function G has two layers: a layer of two 8x8 S-boxes, S0 and
S1, and a layer of block permutation of sixteen 8-bit sub-blocks.
The output octet sequence Z (= Z0 || Z1 || Z2 || Z3) of the
function G with the four-octet input X (= X0 || X1 || X2 || X3)
is as follows:
Z0 = {S0(X0) & m0} ^ {S1(X1) & m1} ^ {S0(X2) & m2} ^ {S1(X3) & m3}
Z1 = {S0(X0) & m1} ^ {S1(X1) & m2} ^ {S0(X2) & m3} ^ {S1(X3) & m0}
Z2 = {S0(X0) & m2} ^ {S1(X1) & m3} ^ {S0(X2) & m0} ^ {S1(X3) & m1}
Z3 = {S0(X0) & m3} ^ {S1(X1) & m0} ^ {S0(X2) & m1} ^ {S1(X3) & m2}
where m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F .
To increase the efficiency of the calculation of the function G, four
extended S-boxes with 4-octet output ('SS-boxes', see Appendix A.2.)
are defined as follows:
SS0(x) = {S0(x) & m0} || {S0(x) & m1} || {S0(x) & m2} || {S0(x) & m3}
SS1(x) = {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0}
SS2(x) = {S0(x) & m2} || {S0(x) & m3} || {S0(x) & m0} || {S0(x) & m1}
SS3(x) = {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2}
Hereby, the function G can be defined as follows:
Z = G(X) = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) .
This alternate definition of the function G is faster than the
original definition but it takes 16 times the memory to store
the four SS-boxes compared to the two original S-boxes.
---------------- cut here -------------------------------
Immediately below the headline of Appendix A.2., on page 8,
I propose to insert the following text (or similar):
"The following tables specify the byte-reversed SS-box values,
i.e., the first octet to be returned from the function G
(named Z0 in section 2.2.), is obtained by XORing together
the rightmost bytes from the appropriate entries looked up
in the following four tables, etc."
(E)
The above discussion, and the observed deviation from the IETF
standard ('network') byte ordering convention, immediately raises
additional byte ordering concerns for
- the definition of the round function F in section 2.1., and
- the Key Schedule definition given in section 2.3.
The function G -- as defined in section 2.2. -- operates on a four-
octet sequence and returns a four-octet sequence, according to the
formulae labelled (1) and (2) above.
The definition of the round function F and the key schedule make use of
several multi-byte INTEGER arithmetic operations, in particular 32-bit
(mod 2^32) addition and subtraction, on input and output values of the
function G, and the key schedule uses circular shift operations on
concatenated (64 bit) intermediate key blocks.
With regard to the observations made above, I now suspect that some
of the implicit 'cast' operations (between octet sequences and multi-
byte integers) involved in the round functions and the key schedule
might also be formulated in a little-endian centric way, omitting the
necessary application of the htonl() and ntohl() intrinsics when
producing the test cases in Appendix B. (I did not have the time
to verify that.)
For the sake of interoperability, it SHOULD be clarified whether the
formulae given for R0' and R1' in section 2.1., and for Ki0 and Ki1
in section 2.3., as well as the constant's values tabulated in the
latter section, are specified according to IEFT standard byte ordering
rules, or with implicit little-endian byte order in mind.
It should say:
[see above]
Notes:
from pending
Errata ID: 197
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-03-06
Held for Document Update by: Russ Housley
Section 2.5 says:
seedCDCParameter ::= OCTET STRING -- 128-bit Initialization Vector
It should say:
seedCDCParameter ::= OCTET STRING (SIZE(16))
-- 128-bit Initialization Vector
Errata ID: 196
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Tim Polk
Section 3.1 says:
P[i] The ith plaintext key data block
C[i] The ith ciphertext data block
A The 64-bit integrity check register
R[i] An array of 64-bit registers where
i = 0, 1, 2, ..., n
A[t], R[i][t] The contents of registers A and R[i] after
encryption step t.
It should say:
P[i] The ith (64-bit) plaintext key data block
where i = 1, 2, ..., n
C[i] The ith (64-bit) ciphertext data block
where i = 0, 1, 2, ..., n
A The 64-bit integrity check register
R[i] An array of 64-bit registers where
i = 1, 2, ..., n
A[t], R[t][i] The contents of registers A and R[i] after
encryption step t.
Errata ID: 1812
Status: Verified
Type: Editorial
Reported By: Alexey Melnikov
Date Reported: 2009-07-18
Verifier Name: Sean Turner
Date Verified: 2010-04-19
Section 2.3 says:
This profile specifies the following characters as prohibited input:
It should say:
This profile specifies the following characters as prohibited output:
Notes:
Per RFC 3454, the check for prohibited characters is done after the "Map" and "Normalize" steps. Characters listed here are actually allowed as inputs if they get removed by the "Map" or "Normalize" steps.
Errata ID: 195
Status: Held for Document Update
Type: Editorial
Reported By:
Date Reported: 2006-08-17
Held for Document Update by: Stewart Bryant
Section 8.10 says:
VPN Forwarding Instance (VFI) is a logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN instance [L3VPN-FRAME].
It should say:
VPN Forwarding Instance (VFI) is a logical entity that resides in a PE that includes the route information base and forwarding information base for a VPN instance [L3VPN-FRAME].
Errata ID: 632
Status: Verified
Type: Technical
Reported By: Ervin Wittner
Date Reported: 2007-06-25
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 9 says:
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one.
It should say:
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAC is indicating support for timers but is not requesting one.
Notes:
I believe that in the first sentence, the reference to "...the UAS is
indicating support...." should read "... the UAC is indicating
support..."
Errata ID: 1681
Status: Verified
Type: Technical
Reported By: Muthu Arul Mozhi
Date Reported: 2009-02-09
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 13 says:
In section 13 (Example Call Flow) the From tag never changes between the initial INVITE message and the subsequent INVITE messages sent after receiving a 422: message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp However, as per RFC 3261, if an initial INVITE generates a non-2xx final response, that terminates all sessions and all dialogs that were created. Hence, these are not re-INVITE messages, rather new INVITE messages and should use a new From tag.
It should say:
message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=2568701785 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=5647301796 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp
Notes:
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, February 09, 2009 10:09 PM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram Mohan R (rmohanr)
Subject: Re: UAS behavior after sending 422 for initial INVITE
yes, I think so.
Paul
Muthu ArulMozhi Perumal (mperumal) wrote:
> In section 13 (Example Call Flow) of RFC 4028 the From tag never changes
> between the initial INVITE message and the subsequent INVITE messages
> sent after receiving a 422:
>
> message 1
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 4
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 10
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> Is this a bug in the RFC?
>
> thanks,
> Muthu
>
> |-----Original Message-----
> |From: Paul Kyzivat (pkyzivat)
> |Sent: Wednesday, February 04, 2009 12:36 AM
> |To: Radha Krishna Saragadam (rsaragad)
> |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal);
> Ram Mohan R (rmohanr)
> |Subject: Re: UAS behavior after sending 422 for initial INVITE
> |
> |Radha,
> |
> |It is not a reinvite, because a dialog was never established - the
> first
> |call failed.
> |
> |So you are starting a new invite. You can use the same callid, but
> |should use a new from-tag.
> |
> | Thanks,
> | Paul
> |
> |Radha Krishna Saragadam (rsaragad) wrote:
> |> Hi Paul
> |>
> |> My question is for initial INVITE. For initial INVITE if UA
> |> receives 422 and UA want to retry INVITE with new value increased
> value
> |> then what should be the To(with tag), From(with tag) and CallID
> values?
> |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for
> |> To,From and CallID
> |>
> |> Regards
> |> S.Radha krishna
Errata ID: 1687
Status: Held for Document Update
Type: Technical
Reported By: Radha krishna Saragadam
Date Reported: 2009-02-19
Held for Document Update by: Robert Sparks
Section 9 says:
The UAS MUST NOT increase the value of the Session-Expires header field.
It should say:
same as session 8.1 If the request doesn't indicate support for the session timer but contains a session interval that is too small, the UAS cannot usefully reject the request, as this would result in a call failure. Rather, the UAS SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the UAS SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The UAS MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field
Notes:
----- Forwarded Message ----
From: Radha krishna <krishna_srk2003@yahoo.com>
To: Brett Tate <brett@broadsoft.com>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Sent: Thursday, February 19, 2009 10:56:31 AM
Subject: Re: [Sip-implementors] Sending 422
Thanks Brett,
So I think same should be added for UAS
<Snip from RFC section 8.1>
If the request doesn't indicate support for the session timer but
contains a session interval that is too small, the proxy cannot
usefully
reject the request, as this would result in a call failure.
Rather, the
proxy SHOULD insert a Min-SE header field containing its
minimum
interval. If a Min-SE header field is already present, the
proxy SHOULD
increase (but MUST NOT decrease) the value to its
minimum interval. The
proxy MUST then increase the Session-Expires
header field value to be equal to the value in the
Min-SE header
field, as described above.
</Snip from RFC>
Regards
S.Radha krishna
________________________________
From: Brett Tate <brett@broadsoft.com>
To: Radha krishna <krishna_srk2003@yahoo.com>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Sent: Wednesday, February 18, 2009 6:42:31 PM
Subject: RE: [Sip-implementors] Sending 422
It looks like Section 9 may have forgotten to indicate the behavior when UAC timer support not indicated. Section 8.1 allows a proxy to increase the Session-Expires; I see no reason why the same cannot be done by the UAS.
> -----Original Message-----
> From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-
> implementors-bounces@lists.cs.columbia.edu] On Behalf Of Radha krishna
> Sent: Tuesday, February 17, 2009 9:48 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] Sending 422
>
> Hi
>
> Consider the following topology
> UA1 ----- Call-stateful-proxy ------ UA2
>
> UA1 does not support session timer, Make a call to UA2. Call-
> stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2
> minimum session expires is 900. But in this case INVITE will not contain
> "support: timer". According section 9, UAS can reject with 422 only if
> there is a timer tag in supported header
>
> <Snip from RFC>
>
> If an incoming request contains a Supported header field with a value
> 'timer' and a Session Expires header field, the UAS MAY reject the
> INVITE request with a 422 (Session Interval Too Small) response if
> the session interval in the Session-Expires header field is smaller
> than the minimum interval defined by the UAS' local policy. When
> sending the 422 response, the UAS MUST include a Min-SE header field
> with the value of its minimum interval. This minimum interval MUST
> NOT be lower than 90 seconds.
> </Snip from RFC>
>
> Also UAS cannot increase the session expires duration
> <Snip from RFC>
> The UAS MUST
> NOT increase the value of the Session-Expires header field.
> </Snip from RFC>
>
> What should be the behavior of UAS here?
> 1) accept the call with 100 seconds?
> 2) Increase the duration to 900 seconds while sending 200 Ok?
> Note: Session timer should not be turned-off
>
> Regards
> S.Radha krishna
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Errata ID: 194
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-06-23
Section 9.1 says:
Offering native service as quickly as possible is important. In the meantime, however, a 6to4 relay may be provided in the meantime for optimized 6to4 connectivity and may also be combined with a tunnel broker for extended functionality.
It should say:
Offering native service as quickly as possible is important. In the meantime, however, a 6to4 relay may be provided for optimized 6to4 connectivity and may also be combined with a tunnel broker for extended functionality.
Notes:
In Section 12, it says:
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,
R., "Evaluation of Transition Mechanisms for Unmanaged
Networks", Work in Progress.
...
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational
guidelines", Work in Progress.
It should say:
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004.
...
[DNSGUIDE] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.
Errata ID: 3043
Status: Reported
Type: Technical
Reported By: Mark Andrews
Date Reported: 2011-12-07
Section Updates says:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
It should say:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3597, 3226 VeriSign
Notes:
RFC 4033, 4034 and 4035 all list 3007 as being updated but none of them update 3007.
Errata ID: 1062
Status: Reported
Type: Technical
Reported By: Peter Koch
Date Reported: 2005-09-13
Section 6.2 says:
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;
It should say:
[not supplied]
Notes:
Compare with RFC 3597 (section 7):
"As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6."
Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.
neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.
Errata ID: 2681
Status: Reported
Type: Technical
Reported By: Guillaume Bailey
Date Reported: 2011-01-05
Section B says:
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits.
It should say:
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together with at least 32-bit precision, retaining any carry bits. The carry bits are then added to the result, and finally, only the lower 16 bits of the result are used as the key tag.
Notes:
This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:
ac += (ac >> 16) & 0xFFFF;
Errata ID: 3045
Status: Reported
Type: Technical
Reported By: Mark Andrews
Date Reported: 2011-12-07
Section Updates says:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
It should say:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3597, 3226 VeriSign
Notes:
4033, 4034 and 4035 all list 3007 as being updated but none do so.
Errata ID: 193
Status: Verified
Type: Editorial
Reported By: Donald E. Eastlake III
Date Reported: 2005-06-21
In Appendix B.1, it says:
For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th to last and 3rd to last octets
of the public key modulus).
It should say:
For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 3rd to last and 2nd to last octets
of the public key modulus).
Errata ID: 2824
Status: Reported
Type: Editorial
Reported By: Edward Lewis
Date Reported: 2011-06-06
Section 3.1.3 says:
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present).
It should say:
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the leftmost label if it is a wildcard.
Notes:
In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.)
The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations.
Errata ID: 3044
Status: Reported
Type: Technical
Reported By: Mark Andrews
Date Reported: 2011-12-07
Section Updates says:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
It should say:
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3597, 3226 VeriSign
Notes:
4033, 4034 and 4035 all list 3007 as being updated but none update 3007
Errata ID: 192
Status: Verified
Type: Editorial
Reported By: Denis Pinkas
Date Reported: 2007-02-07
Appendix A.2. 1993 ASN.1 Module says:
Appendix A.2. 1993 ASN.1 Module
PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-perm-id-93(29) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- from [RFC3280]
ATTRIBUTE
FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
informationFramework(1) 4};
-- from [X.501]
-- Permanent identifier Object Identifiers
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
-- Permanent Identifier
permanentIdentifier ATTRIBUTE ::= {
WITH SYNTAX PermanentIdentifier
ID id-on-permanentIdentifier }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use the serialNumber attribute
-- if there is a single such attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
}
END
It should say:
Appendix A.2. 1993 ASN.1 Module
PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-perm-id-93(29) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
OTHER-NAME
FROM CertificateExtensions {joint-iso-itu-t ds(5) module(1)
certificateExtensions(26) 4} ;
-- from Module CertificateExtensions (X.509:03/2000)
-- Permanent identifier Object Identifiers
id-pkix OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)security(5)
mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
-- Permanent Identifier
permanentIdentifier OTHER-NAME ::=
{ PermanentIdentifier IDENTIFIED BY id-on-permanentIdentifier }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use the serialNumber attribute
-- if there is a single such attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
}
END
Notes:
Errata ID: 772
Status: Verified
Type: Technical
Reported By: Brian E Carpenter
Date Reported: 2005-07-28
Section Section 4 says:
IANA Considerations, of RFC 4048 omitted to request IANA to release IPv6 option type code 11-0-00011 = 195 decimal, C3 hexadecimal.
It should say:
[see above]
Notes:
from pending
Errata ID: 191
Status: Verified
Type: Technical
Reported By: Donald Eastlake III
Date Reported: 2005-11-08
Notes:
In Section 2.3.5, the two URLs should have their right-most slash ("/") replace with a pound sign =
("#").
Errata ID: 190
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-05-17
Section 7.2 says:
[6] Trowbridge, S., Bradner, S., and F. Baker, "Procedure for
Handling Liaison Statements Between Standards Bodies",
June 2004.
It should say:
[6] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF", BCP 103,
RFC 4053, April 2005.
Notes:
Also reported by Loa Andersson <loa@pi.se> on Mon, 25 Jul 2005 14:21:06 +0200.
Errata ID: 1468
Status: Verified
Type: Editorial
Reported By: Sean Turner
Date Reported: 2008-07-09
Verifier Name: Tim Polk
Date Verified: 2008-11-19
Section 3 says:
CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the publicKeyAlgorithms field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the publicKeyAlgorithms field for end-entity certificates.
It should say:
CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the subjectPublicKeyInfo algorithm field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the subjectPublicKeyInfo algorithm field for end-entity certificates.
Notes:
The correct name of the field is "subjectPublicKeyInfo algorithm field" as opposed to "publicKeyAlgorithms field". Note that this change is also included in the draft-ietf-pkix-rfc4055-update ID.
Errata ID: 1676
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Verifier Name: Sean Turner
Date Verified: 2010-04-19
Section 3.1, 4.1 says:
a) Section 3.1, explanation of maskGenAlgorithm, last paragraph
(2nd paragraph on page 9)
b) Section 4.1, explanation of maskGenFunc, last paragraph
(2nd paragraph on page 11)
both say:
Although mfg1SHA1Identifier is defined as the default value for
this field, implementations MUST accept both the default value
encoding (i.e., an absent field) and mfg1SHA1Identifier to be
explicitly present in the encoding.
It should say:
both a) and b) should say:
Although mgf1SHA1Identifier is defined as the default value for
this field, implementations MUST accept both the default value
encoding (i.e., an absent field) and mgf1SHA1Identifier to be
explicitly present in the encoding.
Notes:
Rationale: 4 instances of the same character twister:
mfg1SHA1Identifier
--- ^^
mgf1SHA1Identifier
Note: "MGF" is the abbreviation of "Mask Generation Function".
Errata ID: 1677
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Held for Document Update by: Tim Polk
Section 6, pg. 18 says:
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
| parameters rSSASSA-PSS-SHA512-params }
^^^^
vvvv
| rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
hashAlgorithm sha512Identifier,
maskGenAlgorithm mgf1SHA512Identifier,
saltLength 20,
trailerField 1 }
It should say:
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
| parameters rSASSA-PSS-SHA512-params }
^^^
vvv
| rSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
hashAlgorithm sha512Identifier,
maskGenAlgorithm mgf1SHA512Identifier,
saltLength 20,
trailerField 1 }
Notes:
repeated Typo; s/rSSA/rSA/
Errata ID: 2724
Status: Held for Document Update
Type: Editorial
Reported By: Sean Turner
Date Reported: 2011-02-16
Held for Document Update by: Tim Polk
Section 2.1 says:
id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
It should say:
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
Notes:
There's an extra "{". This is incorrect ASN.1. I marked it as editorial because the ASN.1 module does not contain this error.
Errata ID: 189
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-06-17
Section 4.6 says:
Network
management will not need to support both IPv4 and IPv6 and view nodes
as dual stacks.
It should say:
Network
management will need to support both IPv4 and IPv6 and view nodes
as dual stacks.
Errata ID: 188
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-05-17
Section 2.2 says:
The additional fundamental frequency and voicing class information is compressed for each frame pair. The pitch for the first frame of the FP is quantized to 7 bits and the second frame is differentially quantized to 7 bits.
It should say:
The additional fundamental frequency and voicing class information is compressed for each frame pair. The pitch for the first frame of the FP is quantized to 7 bits and the second frame is differentially quantized to 5 bits.
Errata ID: 1955
Status: Held for Document Update
Type: Editorial
Reported By: Glen Zorn
Date Reported: 2009-12-03
Held for Document Update by: Dan Romascanu
Section 4.1.4 says:
Note that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through mode, it cannot know the Key-Name before receiving it from the AAA server. As a result, a Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter server receiving a Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST silently discard the AVP.
It should say:
Note that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through mode, it cannot know the name of the key before receiving it from the AAA server. As a result, an EAP-Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter server receiving a Diameter-EAP-Request containing an EAP-Key-Name AVP with non-empty data MUST silently ignore the AVP.
Notes:
In the original text, the first occurrence of the string "Key-Name" apparently is meant to refer to the actual name of the key, rather than an AVP identifier, while the next two occurrences are obviously typos, since no Key-Name AVP is defined in the document. Also, the term "silently discard" is typically used in reference to messages; with reference to a single AVP, "silently ignore" seems more appropriate.
Errata ID: 1956
Status: Held for Document Update
Type: Editorial
Reported By: Glen Zorn
Date Reported: 2009-12-03
Held for Document Update by: Dan Romascanu
Section 4.1.4 says:
In addition, the home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request.
It should say:
In addition, the home Diameter server SHOULD include this AVP in the Diameter-EAP-Answer message only if an empty EAP-Key-Name AVP was present in the corresponding Diameter-EAP-Request.
Notes:
There's no such thing as a "Diameter-EAP-Response" message; the rephrasing is for purposes of clarification.
Errata ID: 2317
Status: Rejected
Type: Editorial
Reported By: Souheil Ben Ayed
Date Reported: 2010-06-30
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02
Section 3.2. says:
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
[ Accounting-EAP-Auth-Method ]
[ Service-Type ]
It should say:
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
* [ Accounting-EAP-Auth-Method ]
[ Service-Type ]
Notes:
When one or more EAP methods used for authenticating the user, for each used EAP method an Accounting-EAP-Auth-Method AVP is added in the Diameter-EAP-Answer with a successful result code. In the message format of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can be included.
--VERIFIER NOTES--
This erratum if verified would create an non-backward-compatible change. The submiter is kindly requested to consider the discussions with the author on the WG list and if he still thinks that the change is needed to resubmit the erratum as Technical.
Errata ID: 762
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-05-17
Held for Document Update by: Sean Turner
In the module heading and in the IMPORTS clause of the ASN.1 module of RFC 4073 (Appendix A on page 7), the textual label for the sub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is spelled "pkcs-9(9)". But, ALL other (#=4) appearances of this same sub-identifier in the text of RFC 4073 use the spelling "pkcs9(9)" (without the '-'). I've tried to resolve this inconsistency going "back to the roots", and unfortunately found a big mess! (see detailed list below) Basically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985 should be considered the primary reference because this spec contains the definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 . There, the spelling consistently is "pkcs-9(9)" . This notation style is strictly followed in all PKCS publications from RSA (as far as I could verify), and in most RFCs related to PKCS/CMS/PKIX. I've found 24 RFCs of this kind. But there are two RFCs using the spelling "pkcs9(9)" (without the '-') exclusively. And finally, I found 8 RFCs - including RFC 4073 and your RFC 4049, as well - using both spellings mixed without any recognizable pattern. Here are the detailed results of my RFC scan - with shortened titles, and some content oriented grouping applied: 'pkcs-9(9)' only : ---------------- 2985 - PKCS #9 2311 - S/MIME v.2 Message Specification, 2312 - S/MIME v.2 Certificate Handling, 2633 - S/MIME v.3 Message Specification 3114 - Company Classifying Policy via S/MIME Security Label 3183 - Domain Security Services using S/MIME 3850 - S/MIME v.3.1 Certificate Handling 3855 - Transporting S/MIME Objects in X.400 2459 - PKIX Certificate and CRL Profile [ obsoleted by: 3280 ] 3280 - PKIX Certificate and CRL Profile 2511 - PKIX Certificate Request Messages 3029 - PKIX Data Validation and Certification Server Protocols 2797 - Certificate Mgmt Messages over CMS 3161 - PKIX Time-Stamp Protocol 3125 - Electronic Signature Policies 3211 - Password-based Encryption for CMS [ obsoleted by: 3369+3370 ] 3274 - Compressed Data Content for CMS 2875 - D-H Proof-of-Posession 3185 - Reuse of CMS CEKs 3217 - Triple-DES and RC2 Key Wrapping 3370 - CMS Algorithms 3537 - HMAC Key Wrapping with 3DES or AES 3560 - RSAES-OAEP Key Transport in CMS 3565 - Use of AES Encryption in CMS 'pkcs9(9)' only : --------------- 3657 - Use of Camellia Encryption in CMS 4010 - Use of SEED Encryption in CMS mixed spelling : -------------- 2630 - CMS [ obsoleted by: 3369+3370 ] 3369 - CMS [ obsoleted by: 3852 ] 3852 - CMS 2634 - Enhanced Security Services for S/MIME 3851 - S/MIME v.3.1 Message Specification 3126 - Electronic Signature Formats for lon-term signatures 4049 - BinaryTime 4073 - Multiple Content in CMS Note: I fear that there might exist similar inconsistencies for other ==== object identifiers (verification: t.b.d.) So, what should be done? It certainly would be VERY preferable to follow identifier naming literally, always and strictly, once published in a normatively referable way. At least, we should ensure a consistent use of already defined identifiers to be followed in future IETF publications. Additionally, it might be considered to post Errata Notes for some (or all non-obsoleted) RFCs in the 2nd and 3rd category above (i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073).
It should say:
[see above]
Notes:
from pending
Errata ID: 3105
Status: Reported
Type: Technical
Reported By: Florian Weimer
Date Reported: 2012-02-05
Section 6.2.2 says:
If one uses no more than the:
log ( log ( s ) )
2 2 i
low-order bits, then predicting any additional bits from a sequence
generated in this manner is provably as hard as factoring n.
It should say:
(see below)
Notes:
As noted by Koblitz and Menezes in "Another look at provable security II", <http://eprint.iacr.org/2006/229.pdf>, this recommendation is based on a misinterpretation of the big-O notation. The claim about provable security is therefore misleading.
Errata ID: 3106
Status: Reported
Type: Technical
Reported By: Florian Weimer
Date Reported: 2012-02-05
Section 4.4 says:
(see below)
It should say:
(remove entire section)
Notes:
Compression is not suitable for de-skewing, even if headers are removed. For most compression algorithms, discriminators are known. For instance, in gzip output, the most significant bit of each byte is set with a frequency somewhat above 0.501 (except for small inputs). This means that the output is not uniformly distributed even when looking at isolated bytes.
I recommend removal of the entire section.
Errata ID: 1204
Status: Held for Document Update
Type: Technical
Reported By: Gunnar Hellstrom
Date Reported: 2007-12-27
Held for Document Update by: Robert Sparks
Section 4 says:
m=text 11000 RTP/AVP 98 100
It should say:
m=text 11000 RTP/AVP 100 98
Notes:
According to RFC 3264 Offer-answer model, section 5.1, the payload types in m-lines shall be listed in order of preference. The redundancy method shall be preferred as default as described in section 4 of RFC 4103. The example should show the most common use. Therefore the redundancy payload type 100 shall be given first in the example m-line.
Errata ID: 1203
Status: Held for Document Update
Type: Technical
Reported By: Gunnar Hellstrom
Date Reported: 2007-12-27
Held for Document Update by: Robert Sparks
Section 7.2 says:
m=text 11000 RTP/AVP 98 100
It should say:
m=text 11000 RTP/AVP 100 98
Notes:
According to RFC 3264 Offer-answer model, section 5.1, the payload types in m-lines shall be listed in order of preference. The redundancy method shall be preferred as default as described in section 4 of RFC 4103. The example should show the most common use. Therefore the redundancy payload type 100 shall be given first in the example m-line.
Errata ID: 1793
Status: Held for Document Update
Type: Technical
Reported By: Gunnar Hellstrom
Date Reported: 2009-06-16
Held for Document Update by: Robert Sparks
Section 7.1 says:
The value of the "R2 block length" would be set to zero in order to represent the empty T140block.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| "RED" PT | sequence number of primary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp of primary encoding "P" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R2" | "R2" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R1" | "R1" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140 PT | "R1" T.140 encoded redundant data |
+-+-+-+-+-+-+-+-+ +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| "P" T.140 encoded primary data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
The value of the "R1 block length" would be set to zero in order to represent the empty T140block.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| "RED" PT | sequence number of primary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp of primary encoding "P" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R2" | "R2" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R1" | "R1" block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140 PT | "R2" T.140 encoded redundant data |
+-+-+-+-+-+-+-+-+ +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| "P" T.140 encoded primary data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Errata ID: 1919
Status: Verified
Type: Editorial
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Pasi Eronen
Date Verified: 2010-03-01
Section 14 says:
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST. http://
csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
gcm-spec.pdf, January 2004.
It should say:
[GCM] Dworkin, M. "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007.
Notes:
The previous URL is dead. According to David McGrew, SP 800-38D is an acceptable substitute for the original paper. Note that this is a normative reference for good reason: there are many details in the referred-to document that are needed to implement RFC 4106.
Errata ID: 187
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-06-20
DESCRIPTION clause of 'udpEndpointRemotePort' says:
The remote port number for this UDP endpoint. If
datagrams from any remote system are to be accepted,
this value is zero.
It should say:
The remote port number for this UDP endpoint. If
datagrams from any remote port are to be accepted,
this value is zero.
Errata ID: 767
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-06-20
The DESCRIPTION clause of 'udpEndpointRemoteAddressType',
at the bottom of page 10,
"The address type of udpEndpointRemoteAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all remote IP addresses are
accepted. ..."
It should say:
"The address type of udpEndpointRemoteAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams from all remote IP addresses are
accepted. ..."
^^^^
Notes:
from pending
Errata ID: 186
Status: Verified
Type: Editorial
Reported By: Bernie Hoeneisen
Date Reported: 2005-06-21
Section 3.1.2 says:
Example <info> response: [...] S: <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> [...]
It should say:
Example <info> response: [...] S: <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> [...]
Notes:
There is the <domain:host> that should list the "fully qualified names
of the subordinate host objects that exist under this superordinate domain object."
As the <domain:name> is not "example.com:, those <domain:host> elements should be
removed.
Errata ID: 185
Status: Verified
Type: Editorial
Reported By: Gonzalo Camarillo
Date Reported: 2005-08-22
Section 3 says:
|--------------------(4) INVITE SDP TA------------------->|
| | |
|<--------------------(5) 200 OK SDP B--------------------|
| | |
|-------------------------(6) ACK------------------------>|
| | |
|--------(7) INVITE--------->| |
| | |
|<---(8) 200 OK SDP TA+TB --| |
| | |
|--------------------(9) INVITE SDP TA------------------->|
It should say:
|--------------------(4) INVITE SDP TB------------------->|
| | |
|<--------------------(5) 200 OK SDP B--------------------|
| | |
|-------------------------(6) ACK------------------------>|
| | |
|--------(7) INVITE--------->| |
| | |
|<---(8) 200 OK SDP TA+TB --| |
| | |
|--------------------(9) INVITE SDP TB------------------->|
Errata ID: 1535
Status: Verified
Type: Technical
Reported By: Eduardo Cardona
Date Reported: 2008-10-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23
Section 2.2.2 says:
2.2.2. 'usage-rules' Element
'retransmission-allowed': When the value of this element is 'no', the
Recipient of this Location Object is not permitted to share the
enclosed Location Information, or the object as a whole, with
other parties. When the value of this element is 'yes',
snip..
'retention-expires': This field specifies an absolute date at which
time the Recipient is no longer permitted to possess the location
snip..
'ruleset-reference': This field contains a URI that indicates where a
fuller ruleset of policies, related to this object, can be found.
Notes:
Definitions do not match with the XML schema :
* boolean according to XML Schema Part 2: Datatypes Second Edition is either 'true', 'false', '0', or '1'
<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>
* Element names do not match
<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>
Errata ID: 827
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-12-21
Rejected by: Robert Sparks
Date Rejected: 2010-05-23
On mid-page 8, RFC 4119 specifies:
[...] If the
value in the 'retention-expires' element has already passed when
the Location Recipient receives the Location Object, the Recipient
MUST discard the Location Object immediately.
Now, RFC 4119 contains examples of Location Objects. Thus, the reader
of RFC 4119 (or his workstation) becomes a Location Recipient.
But those examples of Location Objects contained in RFC 4119 specify
a 'retention-expires' date that has passed *long before* the
publication of RFC 4119.
Therefore, every reader of RFC 4119, and every system receiving a
copy of RFC 4119, MUST immediately discard the RFC; moreover,
even the RFC editor SHOULD NOT ever have processed the draft!
But in this case, the above rule would not have become effective,
making these actions, creation and reading of the RFC, legitimate
again ...
It should say:
[see above]
Notes:
from pending
From the RAI reviewer: Strictly speaking, only the Location Objects contained in the RFC4119 MUST be discarded. Since this would only remove the examples from the RFC and not the specifiction, the RFC would remain effective, if somewhat less convenient to use.
--VERIFIER NOTES--
Errata ID: 1771
Status: Verified
Type: Editorial
Reported By: Martin Thomson
Date Reported: 2009-05-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23
Section 2.3 says:
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
...
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
It should say:
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
...
<gp:usage-rules>
<gbp:retransmission-allowed>no</gbp:retransmission-allowed>
<gbp:retention-expiry>2003-06-23T04:57:29Z</gbp:retention-expiry>
</gp:usage-rules>
Notes:
This applies to both examples in Section 2.3. The use of the "urn:ietf:params:xml:ns:pidf:geopriv10" namespace for the retransmission-allowed and retention-expiry elements is incorrect. These elements are defined in the "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" namespace.
This does not manifest in an error in parsers due to the allowance for extensions. The XML schema <any> rule with processContents="lax" permits unknown elements, as these are. A schema-aware processor would not reliably detect these elements, potentially leading to them being ignored.
To reveal this problem, validate these examples against a schema with processContents="strict" on all <any> elements.
Errata ID: 1352
Status: Verified
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2008-03-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
In Appendix B, it says:
uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f
It should say:
uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29
Notes:
The given value e902... etc. is based on a calculation swapping the eight octets 0..3, 4..5, 6..7 twice, for the name space UUID, and for the MD5 output, as foreseen for little endian input, but the example values were already big endian. I can reproduce the example and the proposed fix, see <http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>.
The blog entry contains links to an identical older error report, and two (different) examples from third parties also agreeing with that theory.
Errata ID: 1428
Status: Verified
Type: Technical
Reported By: Russ Housley
Date Reported: 2008-05-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
Section 3 says:
UUIDs, as defined in this document, can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second precedes the first if the most significant field in which the UUIDs differ is greater for the second UUID.
It should say:
UUIDs, as defined in this document, can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second follows the first if the most significant field in which the UUIDs differ is greater for the second UUID.
Notes:
The second and third sentences in the paragraph as originally written are
inconsistent. I have proposed one of the possible fixes. There are others
that will make them consistent.
Errata ID: 1957
Status: Verified
Type: Technical
Reported By: Sergey Shandar
Date Reported: 2009-12-03
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
Section 4.1.3 says:
The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field).
It should say:
The version number is in the most significant 4 bits of the time stamp (bits 12 through 15 of the time_hi_and_version field).
Notes:
time_hi_and_version is defined as 16 bit field.
Errata ID: 184
Status: Verified
Type: Editorial
Reported By: Tim Wilson-Brown
Date Reported: 2006-05-03
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
Section 4.3 says:
The UUIDs generated from the same name in two different namespaces
should be different with (very high probability).
It should say:
The UUIDs generated from the same name in two different namespaces
should be different (with very high probability).
Notes:
The brackets should be set similarly to the other points.
Errata ID: 3028
Status: Verified
Type: Technical
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12
Section 7.4.3 says:
digest-alg-id = "sha1" | "md5"
It should say:
digest-alg-id = "sha-1" | "sha1" | "md5" ; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry ; It should be maintained for backwards compatibility
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Split off erratum 1974
Errata ID: 3029
Status: Verified
Type: Technical
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12
Section 7.3 says:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
It should say:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha-1 or sha1
MD5 md5
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility.
Errata ID: 2973
Status: Rejected
Type: Technical
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Pete Resnick
Date Rejected: 2011-11-12
Section 7.3 says:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha1
MD5 md5
It should say:
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value Used
--------- -------
SHA-1 sha-1 or sha1
MD5 md5
SHA-224 sha-224
SHA-256 sha-256
SHA-384 sha-384
SHA-512 sha-512
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
A separate erratum was issued with the SHA1/SHA-1 fix. The additional algorithms cannot be added in an erratum.
Errata ID: 2974
Status: Rejected
Type: Technical
Reported By: Kyle Meadors
Date Reported: 2011-09-16
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12
Section 7.4.3 says:
digest-alg-id = "sha1" | "md5"
It should say:
digest-alg-id = "sha-1" | "sha-224" | "sha-256" | "sha-384" | "sha-512" | "sha1" | "md5" ; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry ; It should be maintained for backwards compatibility
Notes:
The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Because this erratum really requires publication of a replacement RFC, in accordance with the "IESG Processing of RFC Errata for the IETF Stream" <http://www.ietf.org/iesg/statement/errata-processing.html> the appropriate processing is to reject it.
Errata ID: 3055
Status: Rejected
Type: Technical
Reported By: JP McCrory
Date Reported: 2011-12-20
Rejected by: Pete Resnick
Date Rejected: 2011-12-29
Throughout the document, when it says:
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Warning: An identical message already exists at the
destination server.
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
It should say:
(Remove/replace warning examples from section '7.5.6. Backward Compatibility with Disposition Type, Modifier, and Extension' - see notes) 9.3. Replay Remark Because business data documents normally contain transaction ids, replays (such as resends of not-yet-acknowledged messages) are discarded as part of the normal process of duplicate detection. Detection of duplicates by Message-Id or by business transaction identifiers is recommended. (Add following comment to above section.) If duplicate is detected the disposition should be returned with 'processed' and without an error or warning status unless other errors occurred. Sending an error or warning on a duplicate can result in an endless communication loop between retransmissions and resulting error/warnings.
Notes:
Endless communication loops are a problem with AS2 and this is only supported by the RFC and its multiple examples of 'duplicate-document'. What most commonly happens is a file is sent synchronously to one of our partners but our two minute timeout in holding the connection for an MDN is reached. The recipients AS2 software generated the MDN but doesn't recognize the connection is no longer available for MDN return and as a result non-repudiation of receipt has not occurred. The file is later resent to the partner who then promptly sends an MDN with a processed/warning condition again not meeting our threshold of non-repudiation of receipt.
We have three or four occurrences of this exact scenario occur every week and because the RFC undercuts our ability to get AS2 software clients to address this issue at all many of our supplier are forced to manually mark their files as transmitted manually through a mailbox UI we have online.
We understand the need for duplicate detection and have our own in place but implemented in a way that endless communication loops cannot occur. Balanced duplicate detection is advised because to stringent of duplicate detection especially done within the communication protocol itself if problematic. An example of this would be partner who receive a file but then have issues in processing the data and did not take an archive of their data before processing as many do. These partners have requested our system to resend their data AS2 only to find the data is rejected before the file is received because it has the same 'message-id' as it did the first time it was sent and their AS2 software still have the message-id stored in their software's receiving records.
Again I support duplicate checking but it needs to be better defined for AS2 especially the elimination of the duplicate warning with the understanding of the unending communication loops that it can create through no fault of anyone just a missed MDN on the initial communication is all it takes.
--VERIFIER NOTES--
Aside from this being a poorly formatted report (it does not give proper original/change text and should probably have been split into multiple errata), none of this is at all appropriate for an erratum. This is a change to the examples and to add an additional warning given operational experience. This needs to be done via a document update, not an erratum.
Errata ID: 1575
Status: Verified
Type: Editorial
Reported By: r. deutsch
Date Reported: 2008-10-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section 4.1 says:
Any difference between AS2 implantations and RFCs are
^^^^^^^^^^^^^
mentioned specifically in the sections below.
It should say:
Any difference between AS2 implementations and RFCs are
^^^^^^^^^^^^^^^
mentioned specifically in the sections below.
Notes:
The word "implantations" should be "implementations".
Errata ID: 183
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-22
Verifier Name: Dan Romascanu
Date Verified: 2009-02-18
Section 2.12.1 says:
For example, the entPhysicalUris object may be used to encode a URI
containing a Common Language Equipment Identifier (CLEI) URN for
the managed physical entity. The URN name space for CLEIs is
defined in [RFCYYYY], and the CLEI format is defined in
[T1.213][T1.213a]. For example, an entPhysicalUris instance may
have the value of
URN:CLEI:D4CE18B7AA
[RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name
space. The specific CLEI code, D4CE18B7AA, is based on the example
provided in [T1.213a].
It should say:
For example, the entPhysicalUris object may be used to encode a URI
containing a Common Language Equipment Identifier (CLEI) URN for
the managed physical entity. The URN name space for CLEIs is
defined in [RFC4152], and the CLEI format is defined in
[T1.213][T1.213a]. For example, an entPhysicalUris instance may
have the value of
URN:CLEI:D4CE18B7AA
[RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name
space. The specific CLEI code, D4CE18B7AA, is based on the example
provided in [T1.213a].
Errata ID: 779
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-22
Verifier Name: Ron Bonica
Date Verified: 2009-09-03
Section 8.2 says:
[RFCYYYY] Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
Namespace for the CLEI Code", RFC YYYY, August 2005.
It should say:
[RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
Namespace for the CLEI Code", RFC 4152, August 2005.
Errata ID: 1716
Status: Verified
Type: Technical
Reported By: Maxim Masiutin
Date Reported: 2009-03-15
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 4.8 & 4.9 says:
In 4.8, From: aliceDss@examples.com Subject: Example 4.8 Message-Id: <020906002550300.249@examples.com> In 4.9, From: aliceDss@examples.com Subject: Example 4.9 Message-Id: <021031164540300.304@examples.com>
It should say:
In 4.8, From: AliceDSS@example.com Subject: Example 4.8 Message-Id: <020906002550300.249@example.com> In 4.9, From: AliceDSS@example.com Subject: Example 4.9 Message-Id: <021031164540300.304@example.com>
Notes:
"From" line of the RFC-822 message is aliceDss@examples.com, while the certificate’s SubjectAlternativeName contains Rfc822Name = AliceDSS@example.com
So the two emails are different in the host part:
aliceDss@examples.com
AliceDSS@example.com
The wrong email (aliceDss@examples.com) is given in both cleartext examples and encoded examples.
Additionally, the Message-Id should also be from example.com not from examples.com.
Note: This RFC has been obsoleted by RFC5380
Source of RFC: mipshop (int)
Errata ID: 182
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-14
Appendix A
1.) There are a couple of issues with the citations given
in Appendix A, on pp. 24-27 :
1.1) I suspect that the repeated occurrences of "[5]" should
in fact be "[4]" (the Fast Handover RFC 4068).
1.2) The final phrase at the bottom of page 26 should obviously
refer to RFC 4067 (CXTP) instead of a "work in progress"
(add appropriate ref to section 14.2.!)
1.3) The citations "[6]" on page 27 apparently make no sense --
SEND does not update RFC 4068. I suspect a reference to
some "work in progress" would have been appropriate.
2.) Minor typos and proposed textual improvements
2.1) On p.8, in line 5 (i.e. the end of section 4.1.):
instead of "introduced in future" the text might perhaps
better say: "introduced in the future".
2.2) On p. 14, in the bottom line (at the end of section 7.1.),
the final "." is missing.
2.3) On p. 16, in the 2nd-to-last paragraph of section 7.2.,
The phrase "RCoA is then bound to ..." should perhaps better
say: "The RCoA is then bound to ...".
2.4) On page 19, in the final line of section 9.2., the word
"movement" is mis-spelled "u0movement".
2.5) On page 20, in the enumerated list at the end of section 12.,
I propose to remove the "The" in all 3 items, aligning with
the titles of the subsequent sections 12.1. - 12.3.
It should say:
[see above]
Notes:
from pending
Errata ID: 181
Status: Reported
Type: Editorial
Reported By: Teemu Huovila
Date Reported: 2006-08-23
Section 9.2 says:
This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR u0movement is not frequent.
It should say:
This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR movement is not frequent.
Errata ID: 805
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-11-22
Verifier Name: Dave Crocker
(1)
In Section 1.2, the last paragraph at the bottom of page 4 says:
* three MIME Content header fields (Content-Convert, Content-
Previous and * Content-Features) that specify appropriate
content header fields and record conversions that have been
performed.
It should say:
* three MIME Content header fields (Content-Convert, Content-
| Previous and Content-Features) that specify appropriate
content header fields and record conversions that have been
performed.
(2)
In Section 3, the fourth paragraph on page 6 says:
When CONPERM is used, conversions are performed by the first ESMTP
host that can obtain both the originator's permission and information
about the capabilities supported by the recipient. If a relay or
client is unable to transmit the message to a next-hop that supports
CONPERM or to perform appropriate conversion, then it terminates
message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the
originator, with status code 5.6.3 (Conversion required but not
supported).
It should say:
When CONPERM is used, conversions are performed by the first ESMTP
host that can obtain both the originator's permission and information
about the capabilities supported by the recipient. If a relay or
client is unable to transmit the message to a next-hop that supports
CONPERM or to perform appropriate conversion, then it terminates
| message transmission and returns a Delivery Status Notification (DSN)
[DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3
(Conversion required but not supported).
Rationale: Probably, that triple of RFCs should not be sent :-)
The proposed text change conforms to the current authoring style
guides for I-Ds / RFCs, spelling out the abbreviation 'MDN' at its
first occurrance in the text.
(3)
Similarly, the final NOTE in Section 3, on page 9, says:
NOTE: An originator MAY validate any conversions that are made
by requesting a positive [DSNSMTP]. ...
where it should better say:
NOTE: An originator MAY validate any conversions that are made
| by requesting a positive DSN [DSNSMTP]. ...
(4)
The second item of the first enumerated list in Section 3.3,
on page 12, contains a (visually hidden) word replication.
The text says:
2) MUST return a DSN notification to the originator, with status
code 5.6.3 (Conversion required but not supported). [DSNSMTP,
DSNFMT, SYSCOD]
It should say:
| 2) MUST return a DSN to the originator, with status code 5.6.3
(Conversion required but not supported). [DSNSMTP, DSNFMT,
SYSCOD]
Rationale: The trailing "N" of "DSN" already stands for "notification".
(5)
To make the spelling of [E]SMTP keywords and verbs consistent within
the text, the headline of Section 4.2 (on page 13),
4.2. CONPERM Parameter to Mail-From
should better use uppercaes spelling as well, to read:
4.2. CONPERM Parameter to MAIL-FROM
(6)
The ABNF given in Section 7, on page 16, and Section 8, on page 17,
does not fully conform to the contemporary (RFC 2822) style.
The ABNF in Section 7 omits the explicit specification of white
space usage that presumably has been intended.
The ABNF in Section 8 inserts a paramount of CFWS.
NOTE:
- RFC 2822 has deprecated the use of white space between header
field names and the subsequent ":" and, as far as I can see,
comments have not been allowed at such places by RFC 822,
and aren't by the "obsolete syntax" in RFC 2822.
- RFC 2822 has carefully made [C]FWS an intrinsic part of many
low-level syntactic constructs to improve readability of the
high-level ABNF productions. Thus, CFWS should not be inserted
again where it is (logically) already present.
Furthermore, the spelling of ABNF production names should be
self-consistent within a certain field. RFC 2822 makes use of
lowercase production (rule) names for teh syntactic description
of the Internet Message Format; therefore it seems preferrable
to follow this style when defining IMF extensions.
In the light of these explanations (and detailed inspection of
RFC 2822), the ABNF productions in Section 7 :
Convert = "Content-convert" ":"
permitted
Permitted = "ANY" / "NONE" / permitted-list
should perhaps be re-written as :
convert = "Content-convert:" [CFWS] permitted
permitted = "ANY" / "NONE" / permitted-list
and the ABNF productions in Section 8 :
previous = "Content-Previous" [CFWS] ":"
[CFWS]
date by type
date = "Date " [CFWS] date-time [CFWS] ";"
[CFWS]
by = "By " [CFWS] domain [CFWS] ";"
[CFWS]
should perhaps be re-written as :
previous = "Content-Previous:" date by type
date = "Date " [CFWS] date-time ";" [CFWS]
by = "By " domain ";" [CFWS]
or even (disallowing comments after "Date " - like RFC 2822 does):
previous = "Content-Previous:" date by type
date = "Date " date-time ";" [CFWS]
by = "By " domain ";" [CFWS]
(7)
The examples in Section 9 contain improperly truncated references
to MIME Content-Types.
The following line that appears
- in Section 9.1 in the 3rd text line on page 18,
and
- in Section 9.2 in the 10th text line :
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
should, in both cases, read:
C: <<RFC 2822 message with MIME Content-Type: image/TIFF-FX
(8)
In Appendix C, the headline:
Appendix C. MIME Content-Type Registrations
should say:
Appendix C. MIME Header Field Registrations
(9)
Perhaps, in Appendix C, the IANA should have been directed to
add to the MIME Header Registration for "Content-Features:"
an additional reference to RFC 4141.
E.g., add on page 25, before the "Authors' Addresses":
C.3. Content-Features
This memo substantially amends the specification of the
MIME Header Field "Content-Features:" registered by [[FEAT].
The IANA should include into the 'Specification document(s)'
clause of that registration a pointer to RFC 4141.
It should say:
[see above]
Notes:
From Dave Crocker:
I congratulate you on such an excellent job of proof-reading. I certainly do
recommend that you post your note on the errata page.
All of your points are worth considering. Some entail simple errors and
some entail matters of taste.
I believe that the errors you cite do not change the substance of the
specification, although the question of white space syntax could formally
involve a meaningful technical error. (Normally it would be clear that it
is significant; given the history of RFC733/RFC722/RFC2822 and the slow
adoption of 2822, I'm not too worried that the error in our document will
hurt real-world interoperability.
from pending
Errata ID: 852
Status: Verified
Type: Technical
Reported By: Matthias Wimmer
Date Reported: 2007-01-31
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21
Section 4 says:
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa
IN NAPTR 10 10 "u" "E2U+ifax:mailto"
"!^.*$!mailto:toyo@example.com!"
It should say:
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa
IN NAPTR 10 10 "u" "E2U+ifax:mailto"
"!^.*$!mailto:toyo@example.com!" .
Notes:
This NAPTR record is missing the REPLACEMENT field (see RFC 3403).
(Note the additional point at the end of the example.)
Errata ID: 179
Status: Verified
Type: Editorial
Reported By: Mark Doll
Date Reported: 2005-08-29
Section 2 says:
F800::/6 Reserved by IETF RFC3513
FA00::/7 Reserved by IETF RFC3513
FC00::/7 Reserved by IETF RFC3513
It should say:
F800::/6 Reserved by IETF RFC3513
FC00::/7 Reserved by IETF RFC3513
Notes:
Section 2 states "There are no overlapping address blocks in the first
column", but the address blocks F800::/6 and FA00::/7
overlap. Therefore, the address block FA00::/7 should be removed from the table.
Errata ID: 1485
Status: Verified
Type: Technical
Reported By: Tony Finch
Date Reported: 2008-08-08
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11
Section 2.1 says:
emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname
It should say:
emailAddress = addr-spec
; addr-spec from RFC 2822/5322
Notes:
The syntax as specified does not allow characters such as + which are commonly found in email addresses.
Alexey: this is not quite right either, as addr-spec allows various characters that need %-encoding in URIs.
Errata ID: 178
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11
Section 5 says:
[2] should refer to RFC 5234 [5] should refer to RFC 4122
Notes:
RFC 2234 was obsoleted by RFC 5234.
Errata ID: 177
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Alexey Melnikov
Report Text:
Section 2 should be consistent with the systematic use of the term "URI instead of "URL"
Rationale:
RFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7,
specifies:
... Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].
Admittedly, RFC1630 and RFC 1738 used the term "URL" -- but that
was long before RFC 3986!
Errata ID: 176
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-11
Held for Document Update by: Alexey Melnikov
Report Text:
Section 2 should be consistent with the systematic use of the term "URI instead of "URL" Rationale: RFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7, specifies: ... Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]. Admittedly, RFC1630 and RFC 1738 used the term "URL" -- but that was long before RFC 3986!
Errata ID: 1629
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-12-05
Held for Document Update by: Robert Sparks
Section 1.2, pg.4 says:
vvvvv
| Signal Transfer Point (STP) - A Signal Transfer Point as defined by
MTP standards, e.g., [Q.700].
vvvvv
| Signaling Point (STP) - A Signaling Point as defined by MTP
standards, e.g., [Q.700].
It should say:
Signal Transfer Point (STP) - A Signal Transfer Point as defined by MTP standards, e.g., [Q.700]. | Signaling Point - A Signaling Point as defined by MTP standards, e.g., [Q.700].
Notes:
Overloading the same abbreviation in a single document does not
make sense.
The list of Abbreviations (Section 1.3) is in favor of the first
interpretation of "STP", and the second use would be surprising.
Further, the only other use of "STP" in the whole RFC --
in Section 1.5, at the bottom of page 6 -- also expands the
abbreviation according to the first explanation quoted above.
The whole document (besides the quotation above) does not use
an abbreviation for "Signaling Point"; therefore, the proper
resolution seems to be dropping the second instance of "(STP)".
Errata ID: 175
Status: Verified
Type: Editorial
Reported By: Hannes Reinecke
Date Reported: 2006-06-23
Verifier Name: Lars Eggert
Date Verified: 2008-11-28
Section 4.1.1 says:
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
^^^^^^^^^^^^^^^^^^^^^^
It should say:
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
Notes:
Section 4.1.1 refers to 'iSCSI Node Certificate', which is never defined in the document.
From David Black:
The comment appears to be correct, and the actual Errata should
be to remove the following line from Section 4.1.1 of RFC
4171 (iSNS) because it is not supported by the iSNS protocol:
iSCSI Node Certificate
Errata ID: 174
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-10-17
Rejected by: Lars Eggert
Date Rejected: 2008-11-28
Report Text:
Two normative references have been obsoleted:
RFC 2396 ( Ref. "[Lee98]" )
and
RFC 2732 ( Ref. "[Hinden99]" )
have both been obsoleted by RFC 3986 == STD 66 (published in
January 2005) !
Affected pieces of RFC 4173:
- Both Ref's appear once (and together) near the bottom of
page 4 (in the 6th-to-last line).
- Normative References section, bottom of page 9 + top of page 10
--VERIFIER NOTES--
Independent of the publication date, the work on the draft that
became this RFC significantly predates publication of RFC 3986.
The references to those two RFCs are correct, and the obsoleted
status of the RFCs can be readily determined from the RFC Editor's
database.
Errata ID: 173
Status: Verified
Type: Technical
Reported By: C. M. Heard
Date Reported: 2005-11-01
Section 4.6.1.1 says:
- For integer-valued enumerations:
- INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
NOT be used.
It should say:
- For integer-valued enumerations:
- INTEGER is REQUIRED;
- Integer32, Unsigned32, and Gauge32 MUST NOT be used.
Errata ID: 857
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-10-23
Verifier Name: C. M. Heard
Date Verified: 2005-10-23
Section 4.9 says:
Two point are worth reiterating:
It should say:
Two points are worth reiterating:
Notes:
from pending
Errata ID: 858
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-10-23
Verifier Name: C. M. Heard
Date Verified: 2005-10-23
Appendix A says:
8.) IPR Notice -- if the draft does not contains a verbatim copy of
It should say:
8.) IPR Notice -- if the draft does not contain a verbatim copy of
Notes:
from pending
Errata ID: 172
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-09-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 2 says:
RFC 3032 states on page 4:
It should say:
RFC 3032 states on page 5:
Notes:
Wrong page number in reference.
Errata ID: 171
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
Section 8.1 says:
Length
Indicates the length of this attribute in multiples of four
bytes. The maximum length of an attribute is 1024 bytes. The
length includes the Attribute Type and Length bytes.
It should say:
Length
Indicates the length of this attribute in multiples of four
bytes. The maximum length of an attribute is 1020 bytes. The
length includes the Attribute Type and Length bytes.
Notes:
As there is no offset defined, the maximum encoded Length value
of 255 corresponds to a total of 4*255 = 1020 octets.
Note:
Other protocols incorporate an offset of -1 in similar cases, e.g.,
when a TLV Length field comprises the length of the 'T' and 'L',
also removing the artificially designed-in error case (Length=0),
that otherwise must be checked for by all implementations!
Some people speak of bad protocol design when encountering
Length fields that do not indicate the true length of an object
value proper, which might be zero.
from pending
Errata ID: 956
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
Section 10.14 says:
The value field of the AT_MAC attribute contains two reserved bytes followed by a keyed message authentication code (MAC). The MAC is | calculated over the whole EAP packet and concatenated with optional message-specific data, with the exception that the value field of the MAC attribute is set to zero when calculating the MAC.
It should say:
The value field of the AT_MAC attribute contains two reserved bytes followed by a keyed message authentication code (MAC). The MAC is | calculated over the whole EAP packet, concatenated with optional message-specific data, with the exception that the value field of the MAC attribute is set to zero when calculating the MAC.
Notes:
"The MAC is calculated ... and concatenated ..."
could easily be misunderstood.
From the context it can be concluded that the potential ambiguity
should be resolved and clarified by omitting the word 'and',
and replacing it by a comma.
from pending
Errata ID: 957
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
(1) [[posted separately.]]
(2) [[posted separately.]]
(3) [missing article]
Within Section 1, the 2nd paragraph on page 5 says:
EAP-SIM specifies optional support for protecting the privacy of
subscriber identity using the same concept as the GSM, which uses
pseudonyms/temporary identifiers. [...]
It should say:
| EAP-SIM specifies optional support for protecting the privacy of the
subscriber identity using the same concept as the GSM, which uses
pseudonyms/temporary identifiers. [...]
(4) [missing article]
Section 2, near the bottom of page 6, says:
Fast Re-authentication Username
The username portion of fast re-authentication identity,
i.e., not including any realm portions.
It should say:
Fast Re-authentication Username
| The username portion of the fast re-authentication identity,
i.e., not including any realm portions.
(5) [missing article]
The first paragraph of Section 4.2.3, on page 19, says:
If EAP-SIM peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-SIM identity in the EAP-
Response/Identity packet. [...]
It should say:
| If the EAP-SIM peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-SIM identity in the EAP-
Response/Identity packet. [...]
(6) [missing article]
The Section title (on page 19 and in the ToC),
v
4.2.4. Server Operation in the Beginning of EAP-SIM Exchange
should better say:
vvvv
4.2.4. Server Operation in the Beginning of an EAP-SIM Exchange
(7) [misleading continuation indicator]
In Section 4.3.6, Figure 7 (on page 29) contains for lines that
might erroneously be misunderstod to indicate the omission of
some protocol steps (which is not the case).
I suspect that this is an artifact from a draft version where
Figure 7 was split over two pages; after joining the parts,
these continuation indicators have become ambiguous, and hence
should be deleted.
On mid-page 29, the lines:
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
: :
: :
: :
: :
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
should say:
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
(8) [grammar / articles]
Within Section 5.3, the text on top of page 32,
If the EAP server supports fast re-authentication, it MAY include the
| skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of
EAP-Request/SIM/Challenge message (Section 9.3). This attribute
contains a new fast re-authentication identity for the next fast
re-authentication. The attribute also works as a capability flag
| that, indicating that the server supports fast re-authentication, and
that the server wants to continue using fast re-authentication within
the current context. The peer MAY ignore this attribute, in which
case it MUST use full authentication next time. If the peer wants to
use re-authentication, it uses this fast re-authentication identity
| on next authentication. Even if the peer has a fast
re-authentication identity, [...]
should say:
If the EAP server supports fast re-authentication, it MAY include the
| skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of the
EAP-Request/SIM/Challenge message (Section 9.3). This attribute
contains a new fast re-authentication identity for the next fast
re-authentication. The attribute also works as a capability flag,
| indicating that the server supports fast re-authentication, and
that the server wants to continue using fast re-authentication within
the current context. The peer MAY ignore this attribute, in which
case it MUST use full authentication next time. If the peer wants to
use re-authentication, it uses this fast re-authentication identity
| on the next authentication. Even if the peer has a fast
re-authentication identity, [...]
(9) [misleading continuation indicator, again]
Repetition of the issue described in item (7) above:
In Section 5.4, in Figure 8 (on page 35), the 4 lines:
: :
: :
: :
: :
should be deleted, because these might erroneously be misunderstood
as indicating the omission of some protocol steps.
(10) [missing article]
In Section 7, the paragraph at the bottom of page 43 says:
The notation n*Kc in the formula above denotes the n Kc values
concatenated. The Kc keys are used in the same order as the RAND
| challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value
(not the AT_NONCE_MT attribute, but only the nonce value). The
Version List includes the 2-byte-supported version numbers from
AT_VERSION_LIST, in the same order as in the attribute. [...]
It should say:
The notation n*Kc in the formula above denotes the n Kc values
concatenated. The Kc keys are used in the same order as the RAND
| challenges in the AT_RAND attribute. NONCE_MT denotes the NONCE_MT
value (not the AT_NONCE_MT attribute, but only the nonce value).
The Version List includes the 2-byte-supported version numbers from
AT_VERSION_LIST, in the same order as in the attribute. [...]
Notes:
from pending
Errata ID: 1576
Status: Held for Document Update
Type: Technical
Reported By: Guy Lespade
Date Reported: 2008-10-16
Held for Document Update by: ron bonica
Section 6.1 says:
Within this section, the 3rd paragraph on page 38 says: The receipt of a notification code with the S bit set to one (values | 32768...65536) does not imply failure. Notification code "Success" (32768) has been reserved as a general notification code to indicate successful authentication.
It should say:
The receipt of a notification code with the S bit set to one (values | 32768...65535) does not imply failure. Notification code "Success" (32768) has been reserved as a general notification code to indicate successful authentication.
Notes:
Within this section, 2nd paragraph on page 38, values start from 0, so they end at 65535 (2^16 - 1).
Errata ID: 959
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
(1) [misleading wording]
In Section 3, the RFC text at the bottom of page 13 says:
[...]. In certain circumstances, shown in Figure 4, it is
possible for the sequence numbers to get out of sequence.
This sentence is misleading. Figure 4 only shows the *discovery*
of the de-synchronization; it does not show 'certain circumstances'
that might lead to this problem.
(2) [typo]
On page 18, the second paragraph of Section 4.1.1.7 says:
[...]. It is
recommended that the EAP servers implement some centralized mechanism
to allow all EAP servers of the home operator to map pseudonyms
| generated by other severs to the permanent identity. [...]
^^^^^^
It should say:
[...]. It is
recommended that the EAP servers implement some centralized mechanism
to allow all EAP servers of the home operator to map pseudonyms
| generated by other servers to the permanent identity. [...]
^
(3) [missing article]
The last paragraph of Section 4.1.1.8, on page 20, says:
If the peer does not receive a new pseudonym username in the
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
username instead of the permanent username on next full
authentication. [...]
It should say:
If the peer does not receive a new pseudonym username in the
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
| username instead of the permanent username on the next full
authentication. [...]
^^^^^
(4) [grammar / misleading punctuation]
The last paragraph of Section 4.1.2.1, on page 22, says:
Please note that only the EAP-AKA peer and the EAP-AKA server process
| the AT_IDENTITY attribute and entities that pass through; EAP packets
do not process this attribute. [...]
^ ^^
It should say:
Please note that only the EAP-AKA peer and the EAP-AKA server process
| the AT_IDENTITY attribute, and entities that pass through EAP packets
do not process this attribute. [...]
^^ ^
(5) [missing article]
The first paragraph of Section 4.1.3, on top of page 23, says:
| If EAP-AKA peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-AKA identity in the EAP-
Response/Identity packet. [...]
It should say:
| If an EAP-AKA peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-AKA identity in the EAP-
Response/Identity packet. [...]
(6) [grammar]
The second paragraph of Section 4.1.4, on mid-page 23, says:
If the server chooses to not ignore the contents of
| EAP-Response/Identity, then the server may already receive an EAP-AKA
| identity in this packet. However, if the EAP server has not received
any EAP-AKA peer identity (permanent identity, pseudonym identity, or
fast re-authentication identity) from the peer when sending the first
EAP-AKA request, or if the EAP server has received an
EAP-Response/Identity packet but the contents do not appear to be a
valid permanent identity, pseudonym identity, or a re-authentication
identity, then the server MUST request an identity from the peer
using one of the methods below.
It should say:
If the server chooses to not ignore the contents of
| EAP-Response/Identity, then the server may already have received an
EAP-AKA identity in this packet. However, if the EAP server has not
received any EAP-AKA peer identity (permanent identity, pseudonym
identity, or fast re-authentication identity) from the peer when
sending the first EAP-AKA request, or if the EAP server has received
an EAP-Response/Identity packet but the contents do not appear to be
a valid permanent identity, pseudonym identity, or a
re-authentication identity, then the server MUST request an identity
from the peer using one of the methods below.
(7) [misleading wording]
On page 25, the first paragraph of Section 4.1.6 says:
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
| network. However, an active attacker may transmit an
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
to the peer, in an effort to find out the true identity of the user.
If the peer does not want to reveal its permanent identity, then the
peer sends the EAP-Response/AKA-Client-Error packet with the error
code "unable to process packet", and the authentication exchange
terminates.
It should say:
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
| network. In fact, an active attacker may transmit an
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
to the peer, in an effort to find out the true identity of the user.
If the peer does not want to reveal its permanent identity, then the
peer sends the EAP-Response/AKA-Client-Error packet with the error
code "unable to process packet", and the authentication exchange
terminates.
(8) [[posted separately.]]
(9) [missing article]
The 4th paragraph of Section 5.1, near the bottom of page 32, says:
[...]. For example, on the second
| fast re-authentication, counter value is two or greater, etc. The
AT_COUNTER attribute is encrypted.
It should say:
[...]. For example, on the second
| fast re-authentication, the counter value is two or greater, etc.
The AT_COUNTER attribute is encrypted.
(10) [missing article]
The first paragraph of Section 5.3, near the bottom of page 33, says:
[...]. If the EAP
server supports fast re-authentication, it MAY include the skippable
| AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/-
AKA-Challenge message. This attribute contains a new
re-authentication identity for the next fast re-authentication. [..]
It should say:
[...]. If the EAP
server supports fast re-authentication, it MAY include the skippable
| AT_NEXT_REAUTH_ID attribute in the encrypted data of the EAP-
Request/-AKA-Challenge message. This attribute contains a new
re-authentication identity for the next fast re-authentication. [..]
(The spurious blank after "EAP-" disappears due to the new line break.)
(11) IMPORTANT -- [misleading continuation indicator, again]
Repetition of the issue described in item (8) above:
In Section 5.4, in Figure 10 (on page 36), the 6 lines:
: :
: :
: :
: :
should be deleted, because these might erroneously be misunderstood
as indicating the omission of some protocol steps.
(12) [missing article]
The last paragraph of Section 5.5, on page 38, says:
It should be noted that in this case, peer identity is only
transmitted in the AT_IDENTITY attribute at the beginning of the
whole EAP exchange. The fast re-authentication identity used in this
AT_IDENTITY attribute will be used in key derivation (see Section 7).
It should say:
| It should be noted that in this case, the peer identity is only
transmitted in the AT_IDENTITY attribute at the beginning of the
whole EAP exchange. The fast re-authentication identity used in this
AT_IDENTITY attribute will be used in key derivation (see Section 7).
(13) [missing article]
Within Section 6.1, the 3rd paragraph on page 39 says:
[...]. A re-authentication
round is considered successful only if the peer has successfully
verified AT_MAC and AT_COUNTER attributes, and does not include the
AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
It should say:
[...]. A re-authentication
round is considered successful only if the peer has successfully
| verified the AT_MAC and AT_COUNTER attributes, and does not include
the AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-
Reauthentication.
(14) [grammar / articles]
Within Section 8.1, the text at the bottom page 46,
Attributes numbered within the range 0 through 127 are called
non-skippable attributes. When an EAP-AKA peer encounters a
non-skippable attribute type that the peer does not recognize, the
| peer MUST send the EAP-Response/AKA-Client-Error packet, and the
authentication exchange terminates. If an EAP-AKA server encounters
a non-skippable attribute that the server does not recognize, then
| the server sends EAP-Request/AKA-Notification packet with an
[<page break>]
[...]
should say:
Attributes numbered within the range 0 through 127 are called
non-skippable attributes. When an EAP-AKA peer encounters a
non-skippable attribute type that the peer does not recognize, the
| peer MUST send an EAP-Response/AKA-Client-Error packet, and the
authentication exchange terminates. If an EAP-AKA server encounters
a non-skippable attribute that the server does not recognize, then
| the server sends an EAP-Request/AKA-Notification packet with an
[<page break>]
[...]
(15) [missing article]
Section 9, on page 48 says:
| [...]. Message format is specified in
Section 8.1.
It should say:
| [...]. The message format is specified in
Section 8.1.
(16) IMPORTANT -- misleading specification !
On page 63, the 2nd paragraph of Section 10.15 says:
The value field of the AT_MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
| calculated over the whole EAP packet and concatenated with optional
message-specific data, with the exception that the value field of the
MAC attribute is set to zero when calculating the MAC. [...]
It should say:
The value field of the AT_MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
| calculated over the whole EAP packet, concatenated with optional
message-specific data, with the exception that the value field of the
MAC attribute is set to zero when calculating the MAC. [...]
Rationale:
"The MAC is calculated ... and concatenated ..."
could easily be misunderstood. From the context it can be
concluded that the potential ambiguity should be resolved and
clarified by omitting the word 'and', and replacing it by a comma.
(17) [improper, extraneous wording]
In Section 10.15, the second-to-last paragraph on page 63 says:
| The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The
HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
truncating the output to 16 bytes. Hence, the length of the MAC is
16 bytes.) The derivation of the authentication key (K_aut) used in
the calculation of the MAC is specified in Section 7.
It should say:
| The MAC algorithm is HMAC-SHA1-128 [RFC2104]. (The HMAC-SHA1-128
value is obtained from the 20-byte HMAC-SHA1 value by truncating the
output to 16 bytes. Hence, the length of the MAC is 16 bytes.) The
derivation of the authentication key (K_aut) used in the calculation
of the MAC is specified in Section 7.
Rationale: Beyond grammar, don't mess up 'algorithm' and 'value' !
(17) [missing article]
The second text paragraph of Section 10.18, on page 65, says:
The value field of the AT_NONCE_S attribute contains two reserved
bytes followed by a random number (16 bytes) that is freshly
generated by the server for this EAP-AKA fast re-authentication. The
random number is used as challenge for the peer and also as a seed
value for the new keying material. [...]
It should say:
The value field of the AT_NONCE_S attribute contains two reserved
bytes followed by a random number (16 bytes) that is freshly
generated by the server for this EAP-AKA fast re-authentication. The
| random number is used as a challenge for the peer and also as a seed
value for the new keying material. [...]
(18) [misleading wording]
Within Section 11, the second text paragraph on page 67 says:
[...]. The following attribute types are
specified in this document in [EAP-SIM]:
^
It should say:
[...]. The following attribute types are
| specified in this document and in [EAP-SIM]:
^^^^^
(19) [[posted separately.]]
Notes:
Whereas most items just should be noted for consideration when
preparing future derived work, at least items (8), (11), and (16)
seem to deserve an Errata Note.
from pending
Errata ID: 966
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
Section 12.7 says:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that any extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not included in the MACs later on, and thus some other precautions must be taken to avoid modifications to them.
It should say:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that the AT_CHECKCODE attribute (see Section 10.13) can be used to achieve the protection of extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets.
Notes:
This text is too pessimistic. The reader's attention should be
directed to Section 10.13 of the RFC. The (late) introduction of
the AT_CHECKCODE concept, as explained there, has taken care of
this issue; implementations should make use of this attribute.
from pending
Errata ID: 170
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Held for Document Update by: ron bonica
Date Held: 2006-12-01
Section 4.2.5 says:
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
It should say:
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
Notes:
In Section 4.2.5, Figure 9 (on page 31) contains six lines that
might erroneously be misunderstod to indicate the omission of
some protocol steps (which is not the case).
I suspect that this is an artifact from a draft version where
Figure 9 was split over two pages; after joining the parts,
these continuation indicators have become ambiguous, and hence
should be deleted.
from pending
Errata ID: 793
Status: Verified
Type: Editorial
Reported By: C. M. Heard
Date Reported: 2005-11-01
Verifier Name: C. M. Heard
Date Verified: 2005-11-01
Section 4.9 says:
" ... . Two point are worth reiterating:"
It should say:
" ... . Two points are worth reiterating:"
Notes:
Originally from Alfred Hoenes
from pending
Errata ID: 794
Status: Verified
Type: Editorial
Reported By: C. M. Heard
Date Reported: 2005-11-01
Verifier Name: C. M. Heard
Date Verified: 2005-11-01
Appendix A
"... -- if the draft does not contains a verbatim copy ..."
It should say:
"... -- if the draft does not contain a verbatim copy ..."
Notes:
Originally from Alfred Hoenes
from pending
Errata ID: 786
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-10-17
Held for Document Update by: Dan Romascanu
(1)
There is a significant inconsistency in the newly introduced
conformance information with respect to the new
'dot1dStpPortPathCost32' object:
The bridgeCompliance4188 MODULE-COMPLIANCE macro
(at the bottom of page 37 and the top of page 38) says:
GROUP dot1dStpPortGroup2
DESCRIPTION
"Implementation of this group is mandatory for
bridges that support the Spanning Tree Protocol."
GROUP dot1dStpPortGroup3
DESCRIPTION
"Implementation of this group is mandatory for bridges
that support the Spanning Tree Protocol and 32-bit path
costs. In particular, this includes devices supporting
IEEE 802.1t and IEEE 802.1w."
Now (see upper half of page 34), both dot1dStpPortGroup2 and
dot1dStpPortGroup3 contain the object 'dot1dStpPortPathCost32'.
Thus the net result of the above text is that we have two
overlapping but different requirements for that object, and
that the object 'dot1dStpPortPathCost' is not covered by
the bridgeCompliance4188 statement at all.
But, looking at the description clauses for dot1dStpPortPathCost
(on top of page 22) and dot1dStpPortPathCost32 (on page 23)
I conjecture that the original intent was to ALWAYS have
dot1dStpPortPathCost instantiated in rows of the
dot1dStpPortTable (as before, per RFC 1493), and to take
(the new semantics of) the special (max.) value 65535 for
that object as an indication that dot1dStpPortPathCost32 has
also been instantiated in the respective row; therefore, I
expect that dot1dStpPortPathCost should be included in the
conditionally mandatory groups named in bridgeCompliance4188.
The easiest way to remedy this inconsistency would be to modify
the OBJECTS list of the OBJECT-GROUP dot1dStpPortGroup2 by
replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
But then the definition of dot1dStpPortGroup2 would-be-word
by word identical to the definition of dot1dStpPortGroup (!)
and it might be better to replace 'dot1dStpPortGroup' for
'dot1dStpPortGroup2' on the first line of the text fragment
cited above (bottom of page 37).
Perhaps, an OBJECT clause mentioning the new semantics of the
max. value for dot1dStpPortPathCost in the past-RFC1493
context migth be appropriate as well.
I think that a correction is needed for this issue and would
like to receive your comment before formally submitting an
errata note to the RFC editor.
a) Replace:
dot1dTpPortInFrames OBJECT-TYPE
...
DESCRIPTION
"The number of frames that have been received by this
port from its segment. Note that a frame received on the
interface corresponding to this port is only counted by
this object if and only if it is for a protocol being
processed by the local bridging function, including
bridge management frames."
by:
dot1dTpPortInFrames OBJECT-TYPE
...
DESCRIPTION
"The number of frames that have been received by this
port from its segment. Note that a frame received on
the interface corresponding to this port is counted by
this object if and only if it is consumed by the local
bridging function, including bridge management frames."
b) Replace:
dot1dTpPortOutFrames OBJECT-TYPE
...
DESCRIPTION
"The number of frames that have been transmitted by this
port to its segment. Note that a frame transmitted on
the interface corresponding to this port is only counted
by this object if and only if it is for a protocol being
processed by the local bridging function, including
bridge management frames."
by:
dot1dTpPortOutFrames OBJECT-TYPE
...
DESCRIPTION
"The number of frames that have been transmitted by this
port to its segment. Note that a frame transmitted on
the interface corresponding to this port is counted by
this object if and only if it originates from a local
bridging function, including bridge management frames."
It should say:
[see above]
Notes:
Please correct me if this proposal does not match the original
intent of these DESCRIPTIONs.
(Concern: If the bridge is manageable, the management agent might
reside on the bridge that in this case would have an IP address and
perform the SNMP protocol stack and/or other IP protocols as well.
It might be the case that it was intended to include such locally
destined/originated packets of non-IEEE802.1D functions into the
above counters as well.
Important remark: IEEE802.1D clause 14.6.1.1.3, e.g., includes
"BPDUs, frames addressed to the Bridge as an end station, and
frames that were submitted to the forwarding process" into the
'Frames Received' count! Therefore, the REFERENCE clauses pointing
to that 802.1D clause might be considered inappropriate as well,
for both objects.)
from pending
Errata ID: 1838
Status: Reported
Type: Technical
Reported By: Glen Zorn
Date Reported: 2009-08-24
Section 2.1 says:
Default router preferences and preferences for more-specific routes
are encoded the same way.
Preference values are encoded as a two-bit signed integer, as
follows:
01 High
00 Medium (default)
11 Low
10 Reserved - MUST NOT be sent
Note that implementations can treat the value as a two-bit signed
integer.
It should say:
Default router preferences and preferences for more-specific routes
are encoded the same way.
Preference values are encoded in 2 bits, as
follows:
01 High
00 Medium (default)
11 Low
10 Reserved - MUST NOT be sent
Note that implementations can treat the value as a two-bit signed
integer.
Notes:
The characterization of route preferences as a 2-bit integer is extremely confusing. Fortunately, -(0) is not used, but even so there seems to be little rationale for looking treating the preference as a signed rather than unsigned value.
Errata ID: 1534
Status: Held for Document Update
Type: Technical
Reported By: Immad Mir
Date Reported: 2008-10-02
Held for Document Update by: Stewart Bryant
Section 4.3 says:
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ | | | ^ | ^ ^
| | | |B | |<------+------>| | | | | |
| A | +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
It should say:
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<=|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ | | | ^ | ^ ^
| | | |B | |<------+------>| | | | | |
| A | +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
Notes:
From the figure, the DEC on PE1 has an emulated input AND an emulated output. It appears that the PHY on PE1 converts the Emulated traffic into Attachment Circuit.
However, the DEC should have Emulated traffic at input and Attachment Circuit at the output. Therefore the output of DEC on PE1 should be '<=' not '<:'
Errata ID: 823
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Held for Document Update by: Adrian Farrel
(1)
Section 10 specifies the required behaviour of *aperiodic*
transmission retries with exponential backoff.
(1a)
Nevertheless, at various places the text talks about "periodically"
transmitting certain messages. It should better say "repeated[ly]".
Examples for this issue are:
- Section 11.1.1, page 28 : introduction, and
the paragraphs labelled "ConfSend:" and "Active:" ;
- Section 11.1.2, page 30, text for event '12a)' ;
- Section 11.2.1, page 32 : introduction, and
the paragraphs labelled "Init:" and "Up:" ;
- Section 11.3.1, page 35 : paragraph labelled "Test:" ;
- Section 12.3.1, page 42, last paragraph;
- Section 12.4, page 43, last paragraph;
- Section 12.5.1, page 44, last paragraph;
- Section 12.5.4, first line on page 46;
- Section 12.5.6, final paragraph on page 46 (twice);
- Section 12.6.1, second paragraph on page 48.
(1b)
At the bottom of page 26, Section 10.1 defines the following
parameter:
Rapid retry limit Rl:
Rl is the maximum number of times a message will be transmitted
without being acknowledged.
The naming of this variable is very unfortunate because in similar
contexts in protocol design, the "retry limit" customarily defines the
(maximum) number of *re*-tries -- with 0 meaning no retries at all,
1 meaning a single retry, etc.
The definition given means that the maximum number of retries will
be <Rl> - 1 , thereby restricting the allowed range for <Rl> to 1
or above, excluding the value 0, without mentioning this fact.
Because Section 10.2 codifies the abovementioned definition and this
certainly should not be changed after the fact of publication as an
RFC, it might be advisable to post a warning note pointing to the
specific semantics of 'retry limit' with LMP, the admitted value
range, and in particular the use '1' for <Rl> to inhibit retries.
(2)
Section 12.2, on page 41, codifies an (unfortunately very popular)
design flaw: the 'Length' field in LMP objects is specified as
comprising the cumulative size of the object contents *and* the
object prefix (4 bytes). This unnecessarily creates illegal
values (0..3) for 'Length' which must be checked for in all
implementations. It would have been very muck preferrable to have
'Length' just giving the size of the object contents (in bytes),
whereby Length=0 would be the very mnemonic (and most efficiently
testable) condition for empty object content
[Note: In the case of LMP objects the 16 bit width of length does
not constitute an artificial limitation to the size of the object
contents, because the whole message must be shorter than 2**16
bytes. This *is* a problem, e.g., for RADIUS with its single-octet
'Length' !]
(3)
In Section 13.2, on page 51, the explanatory text after the diagram
for 'C-Type = 1' says:
Node_Id:
This identities the node that originated the LMP packet.
^
where it should say:
Node_Id:
This identifies the node that originated the LMP packet.
^
Similarly, following the diagram for 'C-Type = 2', the same section
says at the top of page 52:
Node_Id:
This identities the remote node.
^
where it should say:
Node_Id:
This identifies the remote node.
^
(4) Section 13.8
a) The explanation for "Flags:" on page 57 contains the improperly
indented and punctuated entry:
vvv
0x0002 Data Link Type
If set, the data links to be verified are ports, otherwise
they are component links
^
It should specify instead:
0x0002 Data Link Type
If set, the data links to be verified are ports, otherwise
they are component links.
^
b) The explanation for "Verify Transport Mechanism:", on top of
page 58, contains:
0x8000 Payload:Test Message transmitted in the payload
^^
It should say:
0x8000 Payload: Test Message transmitted in the payload
^^^
(5) Wavelength encodings
This issue is related to:
- Section 13.8, on page 57/58, and
- Section 13.12.1, on page 64 plus Section 13.12.1.2 on page 65.
Obviously -- and unfortunately --, RFC 4204 avoids specifying the
admissible encoding[s] and the related units for data elements
specifying Wavelengths.
I suspect there could not be reached consensus on a single encoding
style. Nevertheless it would have been very desirable for the sake
of interoperability to specify a (small) set of standard encodings,
e.g.:
- IEEE floating point, units: meters;
- unsigned32, units: nanometers (or picometers?);
- unsigned32 implementation specific wavelength identifiers;
- 0 always meaning: 'implicit / known by out-of-band methods'.
All occurences on 'Wavelength' data elements would have allowed for
the addition of some kind of 'wavelength encoding selector', e.g.
as a 2-/3-/4-bit subfield of the already present 'Flags' field,
or separate values of the already present 'subobject type'.
(6)
Section 13.12.1 says:
This is used to identify the local Interface Switching Type of the TE link as defined in [RFC3471].
It should say:
This is used to identify the local Interface Switching Type of the Data link as defined in [RFC3471].
(7)
Section 16, near the bottom of page 77, contains wording inconsistent
the remainder of this section and with other parts of the document.
The two paragraphs:
The policy for allocating values out of the LMP Object Class name
space is part of the definition of the specific Class instance. When
a Class is defined, its definition must also include a description of
the policy under which the Object Class names are allocated.
The policy for allocating values out of the LMP Sub-object Class name
space is part of the definition of the specific Class instance. When
a Class is defined, its definition must also include a description of
the policy under which sub-objects are allocated.
should better say:
vvvv
The policy for allocating values out of the LMP Object Class type
(C-type) name space is part of the definition of the specific Class
instance. When a Class is defined, its definition must also include
a description of the policy under which the Object Class types are
allocated.
The policy for allocating values out of the LMP Sub-object Class type
(C-type) name space is part of the definition of the specific Class
instance. When a Class is defined, its definition must also include
a description of the policy under which sub-objects are allocated.
[Notes:
The primary name space is the Class type (C-type) name space because
its management is essential for interoperability; the class names are
subordinated additional labels for the human reader and implementor.
Above, I have added "(C-type)" for clarity; this is not absolutely
necessary, if you dislike the repetition here.
]
(8)
There's another small typo in Section 16, at mid-page 82:
The headline:
o CHANNEL_STATUS_REQUESTClass name (14)
should be:
o CHANNEL_STATUS_REQUEST Class name (14)
It should say:
[see above]
Notes:
from pending
Errata ID: 167
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
Section 4.1.1 says:
[...] The format of the TraceMonitor message is as
follows:
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
It should say:
<< THIS CHANGE IS REJECTED >>
<< See the Notes field for the revised editorial change. >>
[...] The format of the TraceMonitor message is as
follows:
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
<TRACE> ...
Notes:
<Original note>
> RFC 4207 defines the syntax of the TraceMonitor message in Section
> 4.1.1, on page 6.
> Similarly, the TraceMonitorAck and TraceMonitorNack Messages are
> specified in Sections 4.1.2 and 4.1.3, respectively, on page 8.
>
> While the former specifies a single <TRACE> object to appear
> in a TraceMonitor message, the latter specs uses wording like
> "all of the TRACE Objects in a TraceMonitor message" or
> "TRACE object value(s)".
>
> IMHO, it makes much sense to indeed allow multiple TRACE Objects
> (with different trace types, but all related to a single Interface)
> in a single TraceMonitor Message.
</Original note>
CCAMP consensus on this issue is that the BNF is correct. That is, only a single instance of the <TRACE> object is permitted on the <TraceMonitor Message> or any of the other messages.
The text in the various sections is factually correct when it says things like "all the Trace Objects..." However, this is misleading and should be changed to be singlular in all cases.
Errata ID: 2615
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-11-08
Held for Document Update by: Sean Turner
Section Appendix C says:
-- ********** -- * For the purposes of this specification, the ASN.1 comment -- * given in [CRMF] pertains not only to certTemplate, but -- * also to the altCertTemplate control. That is, -- **********
It should say:
-- ********** -- * For the purposes of this specification, the ASN.1 comment -- * given in [CRMF] pertains not only to certTemplate, but -- * also to the altCertTemplate control. -- **********
Errata ID: 2616
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-11-09
Held for Document Update by: Sean Turner
Section 5.1.3.1 says:
Note: it is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) in order to reduce the overhead associated with PasswordBasedMac computation).
It should say:
Note: it is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) in order to reduce the overhead associated with PasswordBasedMac computation.
Errata ID: 166
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Section 4.1 says:
algorithmIdentifier identifiers the signature algorithm and an
associated parameters used to produce the POP value.
signature contains the POP value produce.
It should say:
algorithmIdentifier identifies the signature algorithm and
associated parameters used to produce the POP value.
signature contains the POP value produced
Notes:
Errata ID: 2339
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section B says:
Near the middle of page 32, contains the following [commented out] ASN.1, and ASN.1 comment:
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
^^^^
The RFC should say:
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 3629.
It should say:
[see above]
Notes:
RFC 2279 has been obsoleted by RFC 3629 == STD 63 "long" ago.
I am aware of the fact that the UTF-8 definition in RFC 3629
syntactically and semantically by intention is a proper subset
of the definition in RFC 2279 (restriction to possible Unicode
codepoints with up to 24-bit representation).
Thus, it might be true that the reference to RFC 2279 has been
used intentionally in this ASN.1 comment, e.g., because RFC 3280
[PROFILE] (pre-3629!) referred to RFC 2279 in that context.
But, regarding the STD status of RFC 3629, a standards track RFC
like RFC 4211 should, in this case, present explicit arguments
for the deviation from STD 63. (It doesn't.)
Errata ID: 2347
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section 7.1 says:
Subsequently, near the top of page 24, the same section says:
vvvvvvvvv
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
(%25) if they are not being used for their reserved purpose. Names
MUST NOT start with a numeric character.
It should better say:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
The %xx mechanism of Section 2.1 of STD 66 [RFC3986] is used to
encode '?' (%3f) and '%' (%25) if they are not being used for their
reserved purpose. Names MUST NOT start with a numeric character.
It should say:
[see above]
Notes:
Rationale: RFC 1738 has been obsoleted; the %-escaping method is now covered by the above mentioned section of that Internet Standard.
Errata ID: 2349
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section 10.2 says:
On page 27, contains the following Ref. as its final entry:
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
It should say:
[see above]
Notes:
According to Errata 2348, this should be removed, and a new Ref.
[RFC3986] added -- to be taken from rfc-ref.txt .
Given the nature and context of the use of this Ref. in section 7.1
-- see item (11) above -- and the STD Status of RFC 3986, then
perhaps it is advisable to place this new Ref. into Section 10.1,
Normative References, not in section 10.2, Informative References.
Errata ID: 2340
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29
Section 4.2.1 says:
In the last paragraph on page 11 says:
identifier contains a name that the CA/RA can associate with the
requestor. This will generally be either the DN of a certificate
or a text token passed and known to both the requestor and the
CA/RA. ...
It should say:
identifier contains a name that the CA/RA can associate with the requestor. This will generally be either a portion of either a subject name or subject alternative name (either from an existing certificate or from the certificate request) or a text token passed and known to both the requestor and the CA/RA.
Notes:
The location of the DN material will vary based on the question of whether
this is an archive operator or a POP operation.
Errata ID: 2342
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 4.4 says:
In the first text line on page 15, says:
The fields of PEMParameter have the following meaning:
^
It should say:
v
The fields of PBMParameter have the following meaning:
It should say:
[see above]
Notes:
Rationale: an OCR problem???
Changed to editorial.
Errata ID: 2341
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 4.4 says:
The ASN.1 fragment at the bottom of page 14, says:
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
^^^
It should say:
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
It should say:
[see above]
Errata ID: 2343
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.1 says:
In the first paragraph on page 19, refers to a wrong subsection; it says:
The regToken control is used only for initialization of an end entity
into the PKI, whereas the authenticator control (see section 7.2) can
^
be used for the initial as well as subsequent certification requests.
It should say:
The regToken control is used only for initialization of an end entity
into the PKI, whereas the authenticator control (see section 6.2) can
be used for the initial as well as subsequent certification requests.
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2344
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.3 says:
In the upper half of page 20, says:
The fields of PKIPublicationInfo have the following meaning:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their means are:
^^
It should say:
The fields of PKIPublicationInfo have the following meaning:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their meanings are:
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2345
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-29
Section 6.3 says:
At the bottom of page 20, says:
The fields of SinglePubInfo have the following meaning:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubInfos field MUST be omitted.
^^^^^
(To make the full context visible, I have shown more text than
would be necessary for the errata note.)
>From the context, I strongly suspect that the RFC text should say:
The fields of SinglePubInfo have the following meaning:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubLocation field MUST be omitted.
^^^^^^^^
It should say:
[see above]
Notes:
Rationale: pubInfos is a "SEQUENCE SIZE (1..MAX) OF SinglePubInfo".
I cannot imagine how a certain value of a SinglePubInfo instance
subfield can ever imply a MUST to omit the full enclosing structure,
pubInfos -- which would have removed this subfield as well :-) .
Perhaps, the text has been cloned from the explanation of the
'dontPublish' value of the PKIPublicationInfo.action filed given
just below the text excerpt reproduced under item (7) above
without fully applying the proper changes.
Errata ID: 2346
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.4 says:
At the bottom of page 22, says:
The fields of EncryptedKey have the following meaning:
encryptedValue is longer used. This field has been deprecated
along with the EncryptedValue structure.
It should say:
The fields of EncryptedKey have the following meaning:
vvvv
encryptedValue is no longer used. This field has been
deprecated along with the EncryptedValue structure.
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2348
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 9 says:
In the first paragraph on page 26, contains the sentence:
... The user can
claim that an item was signed by the entity that generated the key as
well as any entity that might have seen the key value during transfer
from the generator the to EE. ...
^^^^^^
It should say:
... The user can
claim that an item was signed by the entity that generated the key as
well as any entity that might have seen the key value during transfer
from the generator to the EE. ...
^^^^^^
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2350
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29
Section A.2 says:
In the last ASN.1 fragment on page 31, says:
IP address (identifier "I"):
<iname> ::= <oid>
^^^^^
It should say:
[see above]
Notes:
The text should clarify what is meant by <oid> which is not defined in this
document nor is it a standard BNF item. It should be considered if a BNF
reference should be added. It should be made clearer what the different
terminals mean.
Errata ID: 2595
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-10-29
Held for Document Update by: Sean Turner
Section 2.1 says:
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
7. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
8. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
9. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
10. Add details on how private keys are to be structured when
encrypted.
11. Allow for POP on key agreement algorithms other than DH.
It should say:
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
8. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
9. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
10. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
11. Add details on how private keys are to be structured when
encrypted.
12. Allow for POP on key agreement algorithms other than DH.
Notes:
Item 7 erroneously repeated.
Errata ID: 798
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Rejected by: Sean Turner
Date Rejected: 2010-07-29
Section 4.2 says:
Key Encipherment Keys, in the lower part of page 10, in the two (doubly indented) paragraphs explaining the components of 'agreeMAC', uses improper names for these components -- cf. the ASN.1 syntax for PKMACValue at the top of page 9. The RFC says:
vvvvvv
macAlg contains the algorithm identifying the method used to
compute the MAC value.
macValue contains the computed MAC value.
^^^^^^^^
It should say (I propose to make use of hierarchical subfield
notation):
agreeMAC.algID contains the algorithm identifying the method
used to compute the MAC value.
agreeMAC.value contains the computed MAC value.
It should say:
[see above]
Notes:
--VERIFIER NOTES--
The implication of doing the second level of indentation indicates that
these fields are in the type referenced by the agreeMac field. Note that the same thing occurs just above for subsequentMessage. The type definition occurred in the previous section 4.1.
Errata ID: 2172
Status: Held for Document Update
Type: Editorial
Reported By: Fernando Gont
Date Reported: 2010-04-25
Held for Document Update by: Ron Bonica
Section 4 says:
The issue and the remainder threats are discussed at more length in Security Considerations.
It should say:
This issue and the remainder threats are discussed at more length in Security Considerations.
Errata ID: 800
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Verifier Name: RFC Editor
Date Verified: 2007-11-01
Section 12.5 says:
"... This contrasts the with situation when ..."
It should say:
"... This contrasts with the situation when ..."
Notes:
from pending
Errata ID: 803
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Verifier Name: RFC Editor
Date Verified: 2007-11-01
Section 12.5 says:
"o The various people who have help author this document ..."
It should say:
"o The various people who have helped [to] author this document ..." or: "o The various people who have helped the author of this document ..."
Notes:
from pending
Errata ID: 165
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-09
Held for Document Update by: Alexey Melnikov
Abstract says:
This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
It should say:
This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 3207, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
Notes:
the remainder of the text (including the References section)
correctly refers to RFC 3207 that once had obsoleted RFC 2487
Errata ID: 2404
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section A.3 says:
Still in Appendix A.3, the text on the upper half of page 19 contains
a wrong (undefined) variable name 'O' which should be 'A' instead,
and it should be adapted according to item (3) above.
The text says:
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
Oracle VerO(A)
--------------
i = C
While (i <= C + s - 1 and Win == FALSE) do
If A == ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1
Return Win to B
It should say:
It should say:
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
| Return A to B
Oracle VerO(A)
--------------
| i = C'
| While (i <= C' + s - 1 and Win == FALSE) do
| If A == ALG(K,i) then Win = TRUE; C' = i + 1
Else i = i + 1
Return Win to B
Notes:
another typo, and continuation of 2402 above
Errata ID: 2401
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section A.1 says:
On page 17, Appendix A.1 contains the text: Let IntDiv(a,b) denote the integer division algorithm that takes | input integers a, b where a >= b >= 1 and returns integers (q,r) | the quotient and remainder, respectively, of the division of a by b. (Thus, a = bq + r and 0 <= r < b.)
It should say:
The restriction "a >= b" is not necessary and in fact inappropriate; the additional blank line seems to be an artifact of the editing process. Thus, the above text should better read: Let IntDiv(a,b) denote the integer division algorithm that takes | input integers a, b where b >= 1 and returns integers (q,r), the quotient and remainder, respectively, of the division of a by b. (Thus, a = bq + r and 0 <= r < b.)
Notes:
inappropriate restriction specified + formatting flaw
Errata ID: 834
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section E.4 says:
The enumeration in Appendix E.4, on page 34, contains inconsistent
variable namings (cf. issue (3) above!).
To make it self-consistent, the enumeration:
1) C-client >= C-server
2) C-client - C-server <= s
3) Check that HOTP client is valid HOTP(K,C-Client)
4) If true, the server sets C to C-client + 1 and client is
authenticated ^^^
^^^ ^^^
It should say:
should read:
1) C-client >= C-server
2) C-client - C-server <= s
| 3) Check that HOTP client is valid HOTP(K,C-client)
| 4) If true, the server sets C-server to C-client + 1 and client is
authenticated
Notes:
Lines up with errata 2402
Errata ID: 2405
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section A.4.1 says:
(6) [ typos in mathematical text ]
Lemma 1 and its proof in Appendis A.4.1, on page 20, contains
several typos.
In Lemma 1, the line,
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
^^^
should read:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]
This corrects the use of an undefined variable, n, by using the
variable N as expected from the LHS term.
In the Proof of Lemma 1, the case distinction for z contains an
improper relational operator at two places.
To adjust to the possible range of values (cf. item (2) above!),
the formula parts:
P_{N,m}(z) = [ ... ]
= mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
| 0 if N - mq <= z <= m
^^^^
= q/N +
r/N * 1 / r if 0 <= z < N - mq
| 0 if r <= z <= m
^^^^
should be modified to read:
P_{N,m}(z) = [ ... ]
= mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
| 0 if N - mq <= z < m
= q/N +
r/N * 1 / r if 0 <= z < N - mq
| 0 if r <= z < m
It should say:
see above
Notes:
typos
Errata ID: 2402
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section A.3 says:
In Appendix A.3, unfortunately the necessary distinction between the counter value kept with the user and the counter value kept at the server is not preserved in the variable names introduced. This leads to significant confusion. I hereby propose a 'minimally invasive' text modification as follows (Cf. Appendix E.3 for another notation) : The text of the 2nd and 3rd paragraph of Appendix A.3, on page 18 : The scenario we are considering is that a user and server share a key K for ALG. Both maintain a counter C, initially zero, and the user authenticates itself by sending ALG(K,C) to the server. The latter accepts if this value is correct. In order to protect against accidental increment of the user counter, the server, upon receiving a value z, will accept as long as z equals ALG(K,i) for some i in the range C,...,C + s-1, where s is the resynchronization parameter and C is the server counter. If it accepts with some value of i, it then increments its counter to i+1. If it does not accept, it does not change its counter value.
It should say:
should be modified to say: The scenario we are considering is that a user and server share a key | K for ALG. Both maintain a counter C and C', respectively, initially zero, and the user authenticates itself by sending ALG(K,C) to the server. The latter accepts if this value is correct. In order to protect against accidental increment of the user counter, the server, upon receiving a value z, will accept as long as z equals | ALG(K,i) for some i in the range C',...,C' + s-1, where s is the | resynchronization parameter and C' is the server counter. If it accepts with some value of i, it then increments its counter to i+1. If it does not accept, it does not change its counter value.
Notes:
conflicting naming of variables
Errata ID: 2406
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Tim Polk
Date Held: 2011-03-27
Appendix A.4.3 says:
Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL using v verification oracle queries and a <= 2^c - s authenticator oracle queries. Then [...]
It should say:
Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL using v verification oracle queries and a <= 2^c - s authenticator oracle queries. Then [...]
Errata ID: 2408
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section C says:
In Appendix C, the source text in the upper half of page 28
contains an improperly formatted comment -- obviously intended
to illustrate the subsequent declaration, the comment must be
aligned with that declaration.
Thus, the lines:
// These are used to calculate the check-sum digits.
| // 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
It should say:
should read:
// These are used to calculate the check-sum digits.
| // 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
Notes:
formatting
Errata ID: 163
Status: Verified
Type: Editorial
Reported By: M'Raihi, David
Date Reported: 2005-12-26
Section 9 says:
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
It should say:
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return A to B
^^
Notes:
Section A.4.1, Paragraph 3, Lemma 1 definition, top of page 19
The description of Lemma 1 defines P_ {N,m} (z) using the term Z_ {n}
and it should actually be Z_ {N}.
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Should be:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]
^^^
Section E.2, Paragraph 4, bottom of page 32
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 9-digit HOTP value.
Should be:
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is
significantly better than a 12-digit HOTP value.
^^
In Author's Addresses, Page 35, David Naccache's contact information should be:
David Naccache
ENS, DI
45 rue d'Ulm
75005 Paris, France
and
Information Security Group,
Royal Holloway,
University of London, Egham,
Surrey TW20 0EX, UK
EMail: david.naccache@ens.fr, david.naccache@rhul.ac.uk
Errata ID: 2403
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Edited by: Sean Turner
Date Edited: 2010-07-30
Section A.3 says:
Near the bottom of page 18, the 2nd-to-last paragraph of Appendix A.3
(on that page) says:
... It wins if the
server accepts this accumulator.
^^^^^^^^^^^
It should say:
It should say instead:
... It wins if the
server accepts this authenticator.
Notes:
typo
Errata ID: 2400
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section 5.3 says:
The text of Section 5.3, in the 2nd and 3rd paragraph on page 7,
says:
The reason for masking the most significant bit of P is to avoid
confusion about signed vs. unsigned modulo computations. Different
processors perform these operations differently, and masking out the
| signed bit removes all ambiguity.
^^
Implementations MUST extract a 6-digit code at a minimum and possibly
7 and 8-digit code. Depending on security requirements, Digit = 7 or
more SHOULD be considered in order to extract a longer HOTP value.
It should say:
It should say: The reason for masking the most significant bit of P is to avoid confusion about signed vs. unsigned modulo computations. Different processors perform these operations differently, and masking out the | sign bit removes all ambiguity. Implementations MUST extract a 6-digit code at a minimum and possibly | 7 and 8-digit codes. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value.
Notes:
Editorial fixes.
Errata ID: 2407
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section A.5 says:
Within Appendix A.5, in the lower half of page 23, the text for
"Assumption 1" says:
Let T denotes the time to perform one computation of H. [...]
^
It should say:
It should say: Let T denote the time to perform one computation of H. [...]
Notes:
typo
Errata ID: 2409
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section C says:
In Appendix C, the source code on page 30 (lower half) and
page 31 contains improperly indented lines.
The following three line groups should be indented by 6 more character
positions to make them conformant to RFC style 'nice' format:
- on page 30:
String result = null;
int digits = addChecksum ? (codeDigits + 1) : codeDigits;
- on page 30:
if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) {
offset = truncationOffset;
}
- on page 31:
if (addChecksum) {
otp = (otp * 10) + calcChecksum(otp, codeDigits);
}
result = Integer.toString(otp);
while (result.length() < digits) {
result = "0" + result;
}
return result;
It should say:
[see above]
Notes:
[ further formatting (indentation) issues ]
Errata ID: 162
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-02-08
Verifier Name: Eamon O'Tuathail
Date Verified: 2006-02-14
Section 9 says:
Although service provisioning is a policy matter, at a minimum, all
implementations MUST provide the following tuning profiles:
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side
certificates)
It should say:
Although service provisioning is a policy matter, at a minimum, all
implementations MUST provide the following tuning profiles:
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_128_CBC_SHA cipher)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_128_CBC_SHA cipher supporting client-side
certificates)
Notes:
--VERIFIER NOTES--
It was first reported to us by Alfred Hînes with helpful comments by Philip
Nesser.
Errata ID: 699
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-02-08
Verifier Name: Eamon O'Tuathail
Date Verified: 2006-02-14
Section 6.1.1 says:
If the authority component contains a domain name and a port number,
e.g.,
soap.beep://stockquoteserver.example.com:1026
then the DNS is queried for the A Resource Records corresponding to
the domain name, and the port number is used directly.
If the authority component contains a domain name and no port number,
e.g.,
soap.beep://stockquoteserver.example.com
the Service Record algorithm [11] is used with a service parameter of
"soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP
addressing information. If no appropriate SRV RRs are found (e.g.,
for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is
queried for the A RRs corresponding to the domain name and the port
number used is assigned by the IANA for the registration in Section
8.4.
It should say:
If the authority component contains a domain name and a port number,
e.g.,
soap.beep://stockquoteserver.example.com:1026
then the DNS is queried for the Address Records (i.e. "A" for
IPv4, "AAAA" for IPv6 based on the host resolver specifications)
corresponding to the domain name, and the port number is used directly.
If the authority component contains a domain name and no port number,
e.g.,
soap.beep://stockquoteserver.example.com
the Service Record algorithm [11] is used with a service parameter of
"soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP
addressing information. If no appropriate SRV RRs are found (e.g.,
for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is
queried for the Address RRs corresponding to the domain name
and the port number used is assigned by the IANA for the registration
in Section 8.4.
Notes:
--VERIFIER NOTES--
It was first reported to us by Alfred Hînes with helpful comments by Philip
Nesser.
Errata ID: 837
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16
(2)
RFC 2068 [4] has been obsoleted by RFC 2616 [11], and the latter
purposely has omitted a few elements of HTTP from the former
specification because of "detected problems" and/or "lack of
implementation" -- cf. Section 19.6 of RFC 2616.
Thus, there is no more current specification for these elements.
According to my understanding that means that these elements
effectively have been deprecated by RFC 2616.
Among those (deprecated) elements of HTTP 1.1 are the HTTP Header
Fields:
- Content-Base
- Content-Version
- Derived-From
- Keep-Alive
- Link
- Public
- URI
As expected, the Registrations for these HTTP Header Fields, as
presented in RFC 4229, consistently all refer to RFC 2068 [4] as
the (obsolete) 'Specification document' -- but, very surprisingly,
the registered 'Status' entries for these Header Fields all contain:
"standard" instead of "deprecated".
According to my understanding of IETF procedures, a feature or
protocol element must not be named "standard" if its specification
has been officially obsoleted / deprecated by a Standards Track RFC.
Hence, IMHO the IANA Registrations for the above mentioned HTTP
Header Fields (Subsections 2.1.{21,33,41,59,62,89,108} of RFC 4229
should be immediately corrected to contain 'Status: deprecated".
It should say:
[see above]
Notes:
(Note: A status of "deprecated" still allows standards conformant
implementations to implement any such feature or protocol element
for the sake of backwards compatibility!)
--VERIFIER NOTES--
This is not an appropriate subject for an erratum.
Please take this up with the IANA or, better yet,
write an Internet-Draft. --Peter Saint-Andre
Errata ID: 161
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
Held for Document Update by: Alexey Melnikov
Report Text:
Reference tags for RFC 2109 [5] should be replaced by reference tags for RFC 2965 [15]. Rationale: RFC 2109 [5] has been obsoleted by RFC 2965 [15], and the latter apparently contains the current specification for the Set-Cookie (and the Set-Cookie2) Header Field. Nevertheless, the registration for 'Set-Cookie' in Subsection 2.1.96 of RFC 4229 (on page 36) refers to RFC 2109 [5] as the normative Specification document. I suspect that this particular Registration should be updated immediately to point to RFC 2965 [15] .
Errata ID: 976
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy
Section 3.2 says:
The sending system needs to maintain the following attributes in such
a security association [1]:
[...]
o Latest sequence number (received with this key identifier)
It should say:
The sending system needs to maintain the following attributes in such
a security association [1]:
[...]
o Latest sequence number (sent with this key identifier)
Notes:
received --> sent
from pending
Errata ID: 977
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy
Section 3.4 says:
[...]. The RSVP INTEGRITY object (outer object) covers the
entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
covers objects within the POLICY_DATA element.
It should say:
[not submitted]
Notes:
The subsequent Figure 1 (on top of page 10)
does *not* depict this security relevant object at all.
Has there something been fost from Figure 1 ?
from pending
Errata ID: 975
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 3.1 says:
o Keyed Message Digest:
The Keyed Message Digest is a security mechanism built into RSVP
| that used to provide integrity protection of a signaling message
(including its sequence number).
It should say:
o Keyed Message Digest:
The Keyed Message Digest is a security mechanism built into RSVP
| that is used to provide integrity protection of a signaling
message (including its sequence number).
Section 3.4 -- word omissions
In the first paragraph on page 11, Section 3.4 says:
[...]. If user identity
| confidentiality is provided, then the policy locator has to be
encrypted with the public key of the recipient. How to obtain
this public key is not described in the document. This detail
may be specified in a concrete architecture in which RSVP is
used.
It should say:
vvvvvvv
[...]. If user identity
| confidentiality is to be provided, then the policy locator has
to be encrypted with the public key of the recipient. How to
obtain this public key is not described in the document. This
detail may be specified in a concrete architecture in which
RSVP is used.
Rationale: Better balance the two parts of the tagged sentence!
Section 4.3 -- word omission
Within Section 4.3, near the bottom of page 27, the first paragraph
under the headline (6) Performance says:
v
| [...]. Otherwise, it difficult
to say which identifier is used to index the security
association.
It should say:
vvv
| [...]. Otherwise, it is
difficult to say which identifier is used to index the security
association.
Section 5.4 -- spurious blank line
On top of page 36, the text in the last bullet, (3), of Section 5.4
contains a spurious blank line, perhaps a page reformating artifact.
The RFC says:
(3) It is assumed that SPIs do not change during the lifetime of the
established QoS reservation. If a new IPsec SA is created, then
|
a new SPI is allocated for the security association. [...]
It should say:
(3) It is assumed that SPIs do not change during the lifetime of the
established QoS reservation. If a new IPsec SA is created, then
a new SPI is allocated for the security association. [...]
Section 5.6 -- a typo and a word omission
The second paragraph on page 37 says:
v
| If an RSVP message can taket more than one possible path, then the
IPsec engine will experience difficulties protecting the message.
Even if the RSVP daemon installs a traffic selector with the
destination IP address, still, no distinguishing element allows
selection of the correct security association for one of the possible
| RSVP nodes along the path. Even if it possible to apply IPsec
protection (in tunnel mode) for RSVP signaling messages by
incorporating some additional information, there is still the
possibility that the tunneled messages do not recognize a path change
in a non-RSVP router. [...]
It should say:
| If an RSVP message can take more than one possible path, then the
IPsec engine will experience difficulties protecting the message.
Even if the RSVP daemon installs a traffic selector with the
destination IP address, still, no distinguishing element allows
selection of the correct security association for one of the possible
| RSVP nodes along the path. Even if it is possible to apply IPsec
protection (in tunnel mode) for RSVP signaling messages by
incorporating some additional information, there is still the
possibility that the tunneled messages do not recognize a path change
in a non-RSVP router. [...]
Section 5.7 -- spurious blank line
Similar as noted in item (6) above, there is a spurious blank line
in the first paragraph of Section 5.7.
On top of page 38, the RFC says:
mechanism, but authentication might, in many cases, be insufficient
for authorization. The communication procedures defined for policy
|
objects [42] can be improved to support the more efficient per-
channel financial settlement model by avoiding policy handling
between inter-domain networks at a signaling message granularity.
[...]
It should say:
mechanism, but authentication might, in many cases, be insufficient
for authorization. The communication procedures defined for policy
objects [42] can be improved to support the more efficient per-
channel financial settlement model by avoiding policy handling
between inter-domain networks at a signaling message granularity.
[...]
Section 9.2 -- typo/punctuation
Within Section 9.2, the first entry on top of page 42 says:
[21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
| strengthened version of RIPEMD in Fast Software Encryption",
LNCS vol. 1039, pp. 71-82, 1996.
It should say:
[21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
| strengthened version of RIPEMD", in: Fast Software Encryption,
LNCS vol. 1039, pp. 71-82, 1996.
It should say:
[see above]
Notes:
from pending
Errata ID: 2841
Status: Held for Document Update
Type: Editorial
Reported By: Marco Molteni
Date Reported: 2011-06-17
Held for Document Update by: Wes Eddy
Section 3.4 says:
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [2].
It should say:
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [7].
Notes:
This wrong cross-reference appears at least in the HTML version of RFC4230, at http://tools.ietf.org/html/rfc4230.
Reference [2] is "RSVP Extensions for Policy Control", RFC 2750, while it should be Reference [7] "Identity Representation for RSVP", RFC 3182.
Note: This RFC has been obsoleted by RFC5234
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 160
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-10-13
Section 3.10 says:
Strings, Names formation
Comment
Value range
Repetition
Grouping, Optional
Concatenation
Alternative
It should say:
Strings, Names formation
Comment
Value range
Grouping, Optional
Repetition
Concatenation
Alternative
Notes:
This re-ordering aligns the table with the prose description and the
meta-grammar in section 4.
Errata ID: 783
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-10-13
Rejected by: Peter Saint-Andre
Date Rejected: 2010-11-18
The following clarifications apply to the meta-grammar in section 4.
a) Near the bottom of page 10, the rule:
repetition = [repeat] element
should say:
| repetition = ( [repeat] element ) / option
At the top of page 11, the rule:
element = rulename / group / option /
char-val / num-val / prose-val
should say:
| element = rulename / group /
char-val / num-val / prose-val
These changes have the effect to formally disallow
a <repeat> element in front of an <option>
-- a senseless construct formerly unexpectedly allowed.
b) On page 11, the last rule:
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR
; without angles
; prose description, to be used as
; last resort
should say:
prose-val = "<" *(%x20-3D / %x3F-7E) ">"
| ; bracketed string of:
| ; SP and VCHAR without closing angle
; prose description, to be used as
; last resort
This change aligns the comment with the formal rule.
It should say:
[see above]
Notes:
from pending
--VERIFIER NOTES--
Peter: The authors have consensus that these are stylistic issues and therefore are not errors.
Errata ID: 777
Status: Rejected
Type: Technical
Reported By: Zoltan Ordogh
Date Reported: 2006-09-18
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02
Section 3.4 says:
A range of alternative numeric values can be specified compactly,
using dash ("-") to indicate the range of alternative values. Hence:
DIGIT = %x30-39
is equivalent to:
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
It should say:
[not supplied]
Notes:
The word equivalent is correct only when US-ASCII character set is used, since:
DIGIT = %x30-39 ;
means any hexadecimal value between 0x30 and 0x39,
while
DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ;
means any digit from 0 thru 9.
from pending
--VERIFIER NOTES--
As per Note in Section 2.3:
ABNF strings are case-insensitive and the character set for these
strings is us-ascii.
So these 2 representations *are* equivalent.
Errata ID: 778
Status: Rejected
Type: Technical
Reported By: Zoltan Ordogh
Date Reported: 2006-09-18
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02
In Appendix B.1, it says:
CHAR = %x01-7F
; any 7-bit US-ASCII character,
; excluding NUL
It should say:
[see below]
Notes:
NUL is not defined.
Suggestions:
(1)
Re-write the document in a character-encoding-independent manner.
(2)
Add definition of NUL (or NULL) as terminating null character - watch =
out for character encoding!
(3)
Add definition of NOTNULL as any character but terminating null =
character - watch out for character encoding!
from pending
--VERIFIER NOTES--
NUL is defined in US-ASCII.
Errata ID: 2625
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-10-13
Held for Document Update by: Pete Resnick
Date Held: 2010-11-12
Section Appendix B.2 says:
Externally, data are represented as "network virtual ASCII" (namely, 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to zero.
It should say:
Externally, data are represented as "network virtual ASCII" (namely, 7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to zero).
Notes:
This change should make it clear (as in RFC 2234) that the phrase,
"with the high (8th) bit set to zero" is an intrinsic part of the
full definition of "network virtual ASCII", and not the specification
of an exception -- or an additional manipulation for the purpose of
ABNF -- to "network virtual ASCII".
Errata ID: 159
Status: Rejected
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-31
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15
Section 2.4 says:
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix A (Core) provides definitions for a 7-bit US-ASCII
environment as has been common to much of the Internet.
It should say:
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix B (CORE ABNF OF ABNF) provides definitions for
a 7-bit US-ASCII environment as has been common to much of the
Internet.
Notes:
--VERIFIER NOTES--
Fixed in RFC 5234.
Errata ID: 866
Status: Rejected
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2007-03-02
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15
Appendix A says:
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix A (Core) provides definitions for a 7-bit US-ASCII
environment as has been common to much of the Internet.
It should say:
External representations of terminal value characters will vary
according to constraints in the storage or transmission environment.
Hence, the same ABNF-based grammar may have multiple external
encodings, such as one for a 7-bit US-ASCII environment, another for
a binary octet environment, and still a different one when 16-bit
Unicode is used. Encoding details are beyond the scope of ABNF,
although Appendix B (Core) provides definitions for a 7-bit US-ASCII
environment as has been common to much of the Internet.
Notes:
Appendix A" by "Appendix B" here.
from pending
--VERIFIER NOTES--
Fixed in RFC 5234.
Errata ID: 771
Status: Verified
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28
Section 6.2 says:
direction="receiver">
It should say:
direction="recipient">
Notes:
Occurs on pages 28, 29 (2 times), and 30.
The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.
from pending
Errata ID: 774
Status: Verified
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28
Section 4.4 says:
<xs:attribute name="display-name" type="xs:string"
It should say:
<xs:attribute name="display" type="xs:string"
Notes:
The proposed version of text is consistent with the rest of the document,
especially with all examples and has been implemented by several
manufacturers this way.
from pending
Errata ID: 781
Status: Verified
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28
Section 6.2 says:
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
It should say:
<local>
<target uri="sip:alice@pc33.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
Notes:
The <param> element must be enclosed by the <target> element.
from pending
Errata ID: 788
Status: Verified
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Verifier Name: Cullen Jennings
Date Verified: 2009-01-28
Section 6.2 says:
<state reason="cancelled">terminated</state>
<state reason="replaced">terminated</state>
<state reason="replaced">confirmed</state>
<state reason="remote-bye">terminated</state>
It should say:
<state event="cancelled">terminated</state>
<state event="replaced">terminated</state>
<state event="replaced">confirmed</state>
<state event="remote-bye">terminated</state>
Notes:
The "state" element does not have a "reason" attribute. It is called "event"
by definition in section 4.1.2. and the schema in 4.4.
from pending
Errata ID: 2861
Status: Reported
Type: Technical
Reported By: Martin Thomson
Date Reported: 2011-07-13
Section 4.4 says:
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
It should say:
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="tns:dialog-state">
...
<xs:simpleType name="dialog-state">
<xs:restriction base="xs:string">
<xs:enumeration value="trying"/>
<xs:enumeration value="proceeding"/>
<xs:enumeration value="early"/>
<xs:enumeration value="confirmed"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
Notes:
The RFC is rather coy about defining the exact syntax for the state element. The schema permits any content. It's fairly clear from the description in Section 3.7.1 what the permitted values are, but the case of the values is never explicitly stated. The text and diagram use title case consistently, and all the examples use lower case exclusively.
This is bad for interoperability. In practice, this is probably moot, since most implementations will use the lowercase form. Arguably, it would be valid to produce a value of "Early". An implementation seeking maximum interoperability would have to use case insensitive comparison to avoid a misinterpretation of the value.
Errata ID: 780
Status: Held for Document Update
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-14
Held for Document Update by: Robert Sparks
Section 4.2 says:
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
It should say:
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi=" <http://www.w3.org/2001/XMLSchema-instance>
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full" entity="sip:alice@example.com">
Notes:
According to the schema in section 4.4 the attribute "entity" must appear on
element "dialog-info".
from pending
Errata ID: 785
Status: Held for Document Update
Type: Technical
Reported By: Nicolas-Peter Pohland
Date Reported: 2007-01-15
Held for Document Update by: Robert Sparks
Section 6.1 says:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
It should say:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="1000" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="1001" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
[[or something similar with the id values differing]]
Rationale:
Quote from RFC 4235:
"4.1.1. Dialog Element
...
For a caller, the id is created when an INVITE request is sent. When
a 1xx response with a tag, or a 2xx response is received, the dialog
is formally created. The id remains unchanged. However, if an
additional 1xx or 2xx is received, resulting in the creation of
another dialog (and resulting FSM), that dialog is allocated a new
id.
..."
The id of the dialog is a hash value of the call-id, local-tag and
remote-tag of the dialog. Therefore, the values of the ids in the example MUST not be identical.
Notes:
from pending
Errata ID: 1495
Status: Held for Document Update
Type: Technical
Reported By: Iñaki Baz Castillo
Date Reported: 2008-08-26
Held for Document Update by: Robert Sparks
Section 3.7.1 says:
[...] non-2xx response for any other reason, all FSMs spawned from that INVITE transition to the Terminated state with the event "rejected". -------------- [...] If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can occur in the Proceeding and Early states), the FSM transitions to the Terminated state with the event "cancelled".
It should say:
[...] non-2xx response for any other reason, all FSMs spawned from that INVITE transition to the Terminated state with the event "rejected". During Early state the FSM transitions to the Terminate state if the UAC sends a BYE (corresponding to "local-bye" event). ------------- [...] If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can occur in the Proceeding and Early states), the FSM transitions to the Terminated state with the event "cancelled". If the UAS receives a BYE request during the Early state the FSM transitions to the Terminated state with the event "remote-bye".
Notes:
Section 3.7.1 (The Dialog State Machine) and the Figure 3 forget the case in which a UAC sends a BYE during an early-dialog as RFC3261 allows:
RFC 3261:
----------------
15 Terminating a Session
When a BYE is received on a dialog, any session
associated with that dialog SHOULD terminate. A UA MUST NOT send a
BYE outside of a dialog. The caller's UA MAY send a BYE for either
confirmed or early dialogs, and the callee's UA MAY send a BYE on
confirmed dialogs, but MUST NOT send a BYE on early dialogs.
----------------
So it should be a new row in Figure 3 from "Early" to "Terminate" labeled "local-bye/remote-bye". It would be "local-bye" in case of UAC and "remote-bye" in case of UAS.
Errata ID: 1517
Status: Held for Document Update
Type: Technical
Reported By: Klaus Darilion
Date Reported: 2008-09-17
Held for Document Update by: Robert Sparks
Section 6.1 says:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
It should say:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
Notes:
The dialog which was cancelled was the first dialog and its remote tag is 456887766 instead of hh76a
Errata ID: 2266
Status: Held for Document Update
Type: Technical
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks
Section 4.4 says:
...
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
It should say:
** Remove Element **
Notes:
The route-set element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04
Errata ID: 2267
Status: Held for Document Update
Type: Technical
Reported By: David Grant
Date Reported: 2010-05-18
Held for Document Update by: Robert Sparks
Section 4.4 says:
<xs:element name="cseq" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/>
It should say:
** Remove Element **
Notes:
The participant/cseq element was removed between draft-ietf-sipping-dialog-package-03 and draft-ietf-sipping-dialog-package-04
Errata ID: 2268
Status: Rejected
Type: Technical
Reported By: David Grant
Date Reported: 2010-05-18
Rejected by: Robert Sparks
Date Rejected: 2010-10-07
Section 4.2 says:
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
It should say:
<xs:complexType name="sessd"> <xs:attribute name="type" type="xs:string"/> </xs:complexType>
Notes:
The sessd type is a simple type, which allows text content, yet the RFC does not describe what content it should have, so it should be an empty type instead.
--VERIFIER NOTES--
(From reviewer Dale Worley):
The description of the session-description element in section 4.1.6.3
is not particularly clear, but it is unambiguous:
4.1.6.3. Session Description Element
The session-description element contains the session description used
by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless it was
explicitly requested by the subscriber. It has a single attribute,
"type", which indicates the MIME media type of the session
description. To avoid repeating session description information in
each request, the subscriber can assume that the session description
is the same as in previous notifications if no session description
element is present in the corresponding local or remote element.
Therefore, a typical usage would be:
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
<session-description type="application/sdp">v=0
o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com
s=Session SDP
t=0 0
c=IN IP4 pc33.atlanta.com
m=audio 3456 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
</session-description>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
<session-description type="application/sdp">[SDP sent by remote UA]</se\
ssion-description>
</dialog>
</dialog-info>
That is, <session-description> has a "type" attribute whose value is
the MIME type of the session description, and it has content which is
the session description.
(Note that both the <local> and <remote> elements have their own
<session-description>, as SDP is sent by both UAs. Presumably the
<session-description> of a participant is the SDP that was *sent* by
that participant.)
Within this understanding, the XML schema language in the RFC is
correct. The '<xs:extension base="xs:string">' specifies that the
content of <session-description> is a string, and the '<xs:attribute
name="type" type="xs:string" use="required"/>' specifies that
<session-description> must have an attribute 'type'.
(The situation could have been made much clearer if the RFC included
an example of the use of <session-description>.)
Errata ID: 158
Status: Verified
Type: Editorial
Reported By: Michael Procter
Date Reported: 2006-10-24
Section 4.1 says:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>
It should say:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Notes:
The proposed version of text is consistent with the rest of the document,
including the schema in section 4.4.
Errata ID: 1070
Status: Verified
Type: Technical
Reported By: RFC Editor
Date Reported: 2005-11-02
Section 4.2 says:
vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1 vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2
It should say:
vPIMTelephoneNumber A 1.3.6.1.1.11.2.1 vPIMRfc822Mailbox A 1.3.6.1.1.11.2.2
Errata ID: 156
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Section 4.1 says:
IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template:
It should say:
IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template. This Object Identifier, 1.3.6.1.1.11, is referred to as the "IANA-ASSIGNED-OID" in the body of this memo.
Errata ID: 157
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18
Section 2 says:
(IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
SUP 'top'
... )
It should say:
(IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'
SUP 'top'
... )
Notes:
Note: IANA assigned OID 1.3.6.1.1.11 to IANA-ASSIGNED-OID. See <http://www.iana.org/assignments/ldap-parameters>.
Errata ID: 1071
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Section 2.5 says:
Because ADPCM is a required format, the audio32kadpcm value must be listed if this attribute is present.
It should say:
Because ADPCM is a required format, the audio/32kadpcm value must be listed if this attribute is present.
Errata ID: 810
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Rejected by: Alexey Melnikov
Date Rejected: 2009-07-18
I suspect that the OID value given in Section 2 is not correct.
It does not match the one listed in section 4.2, on page 10,
4th text line.
Therefore I propose the following erratum:
RFC 4237, at the beginning of Section 2, on page 3, says:
(IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
SUP 'top'
... )
it should say:
vv
(IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'
SUP 'top'
... )
It should say:
[see above]
Notes:
from pending
--VERIFIER NOTES--
Duplicate of the erratum # 157.
Errata ID: 155
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-11-30
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18
Section 5 says:
This specification registers the E2U+VPIM and E2U+Voice services according to the specifications and guidelines in RFC 3761 [ENUM] and the definitions in this document.
It should say:
This specification registers the E2U+VPIM:LDAP and E2U+VPIM:Mailto services according to the specifications and guidelines in RFC 3761 [ENUM] and the definitions in this document.
Notes:
[Note: The RFC text uses "<uri_schema_name>" vs. "<uri_schema_name>:"
in a non-systematical manner. I suspect the difference is not meant to
be significant in the text. Systematical usage of only one of these
two styles would be preferrable in derived (and other future) work.
I have intentionally omitted the trailing ":" after "Mailto" above.]
Errata ID: 839
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks
(2) [ minor textual improvement ]
In the final paragraph of section 3.3, on mid-page 11, perhaps
the words "most anything" should be replaced by "almost anything".
(3) [ textual improvement ]
The last paragraph on page 12 (within Section 4.1.) apparently
contains a plural/singular inconsistency.
The text says:
vvv vvv
The media server presents the parameters as environment variables in
the connection object. Specifically, the parameter appears in the
connection.sip tree. ^^^ ^^^
It should better say:
The media server presents the parameters as environment variables in
| the connection object. Specifically, the parameters appear in the
connection.sip tree.
(4) [ inconsistent terminology ]
I suspect that section 5 contains an unintentional inconsistency
in the terminology used:
The syntax element represented by the 'uniqueIdentifier' part
of the example in the 9th line of Section 5 apparently is
referred to as the "conf-id value" in various places (once
on page 13, 11th text line from the bottom of the page, and
4 occurrences on page 14 (text lines 3, 9, 12, and 13).
But in the 'Formal Syntax' Section 5.2., this syntactic
element is named "instance-id" (see bottom of page 16).
It certainly would be preferrable to always use the same
terminology; you should decide which term should be used.
(5) [ editorial artifact ]
The call flow diagram on page 15 unnecessarily 'overflows'
to page 16. The two first text lines on page 16,
| | | | |
| | | | |
do not carry any useful information and might better have been
suppressed.
(6) [ mismatch between diagram and explanation ]
Subsequently, near the top of page 16, the explanation of the
call flow diagram on page 15 says:
Note that the above call flow does not show any 100 TRYING messages
that would typically flow from the Application Server to the UACs;
nor does it show the ACKs from the UACs to the Application Server or
from the Application Server to the Media Server.
The latter is not true; the diagram in fact DOES show these ACKs !
Therefore, this paragraph should be shortened to just say:
Note that the above call flow does not show any 100 TRYING messages
that would typically flow from the Application Server to the UACs.
(7) [ confusion between concrete and abstract parameter names ]
In the 'IANA Considerations' Section 6., on page 17, the
registered lines mix concrete (real) parameter names (like
'play') with the meta-parameter name 'extension' in a way
that might mislead the reader to taking 'extension' as a
concrete parameter name as well.
>From Section 3.3., it can clearly be seen that this is merely
a placeholder for any additional parameter that might be
standardized in the future.
I'm seriously in doubt whether it is a good idea to register
this meta-parameter. Rather, future standards defining
concrete instances for the 'extension-param' should register
those concrete parameter names.
I therefore propose to delete the final line from the list,
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
. . .
. . .
. . .
| extension no RFC 4240
and from the actual IANA registration performed.
(8) [ legacy left in text? ]
The 3rd paragraph of Section 7, on page 17, says:
This document explicitly addresses this issue. The user names
described in the text (namely annc, ivr, dialog, and conf) are
available for whatever local use a given SIP user agent or proxy
wishes for them. [ ... ]
The user name, 'ivr', does not appear in the remainder of the text.
Admittedly omitting any detailed research, I suspect its occurrence
to be an improper left-over from earlier drafts.
Thus, this text should say:
This document explicitly addresses this issue. The user names
| described in the text (namely annc, dialog, and conf) are
available for whatever local use a given SIP user agent or proxy
wishes for them. [ ... ]
It should say:
[see above]
Notes:
from pending
Errata ID: 154
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-01-23
Held for Document Update by: Robert Sparks
Section 3.3 says:
A number of MIME registrations, which could be used here, have
parameters, for instance, video/DV. To accommodate this, and retain
compatibility with the SIP URI structure, the MIME-type parameter
separator (semicolon, %3b) and value separator (equal, %d3) MUST be
escaped. For example: ^^^
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
It should say:
A number of MIME registrations, which could be used here, have
parameters, for instance, video/DV. To accommodate this, and retain
compatibility with the SIP URI structure, the MIME-type parameter
separator (semicolon, %3b) and value separator (equal, %3d) MUST be
escaped. For example:
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%3d314M-25/625-50
Errata ID: 819
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 2.3 says:
[ ....mising text ... ]
IA_PD option and IA_PD Prefix options for the chosen prefix(es)
back to the PE.
It should say:
Notes:
The 3rd paragraph of the indented, bulleted enumeration in
Section 2.3 contains only a fragment of a sentence.
The second bulleted paragraph covers this, the unbulleted third para
seems to be unneccessary, probably a fragment from a former edit;
just delete it.
Errata ID: 1411
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Section 2.3 says:
[ ....mising text ... ]
IA_PD option and IA_PD Prefix options for the chosen prefix(es)
back to the PE.
It should say:
Notes:
The 3rd paragraph of the indented, bulleted enumeration in
Section 2.3 contains only a fragment of a sentence.
That unbulleted fragment seems to be left over from earlier editing,
the bullet before it says it all here. Delete the fragment.
Errata ID: 153
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Bob Braden
Date Verified: 2008-04-21
Section 2.5 says:
The CPE should return ICMPv6 Destination Unreachable message to
a source address or silently discard the packets, when the original
packet is destined for the unassigned prefix in the delegated prefix.
It should say:
The CPE should return an ICMPv6 Destination Unreachable message
to the source address or silently discard the packet when the original
packet is destined for an unassigned prefix in the delegated prefix.
Errata ID: 821
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03
Second paragraph of Section 2.6: Devices connected to user network may learn a recursive DNS server address with the mechanism described in [RFC3736]. And the first sentence in Section 2.8: ICMPv6 Echo Request will be sent to the user network for connectivity monitoring in the service.
It should say:
Second paragraph of Section 2.6: Devices connected to the user network may learn a recursive DNS server address with the mechanism described in [RFC3736]. And the first sentence in Section 2.8: ICMPv6 Echo Requests will be sent to the user network for connectivity monitoring in the service.
Errata ID: 2608
Status: Held for Document Update
Type: Editorial
Reported By: Hadriel Kaplan
Date Reported: 2010-11-04
Held for Document Update by: Robert Sparks
Section 4.5 says:
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
It should say:
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP%3B\
cause%3D408%3Btext%3D%22RequestTimeout%22>;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP%3B\
cause%3D487%3Btext%3D%22Request%20Terminated%22>; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP%3B\
cause%3D603%3Btext%3D%22Decline%22>; index=1.1.3
Notes:
This is one of many incorrect examples in section 4.5, 4.5.1, 4.5.2, etc. The ";", "=", double-quotes, and space are not legal tokens in URI-embedded headers.
Errata ID: 1486
Status: Verified
Type: Editorial
Reported By: Pasi Eronen
Date Reported: 2008-08-08
Verifier Name: Pasi Eronen
Date Verified: 2008-08-11
Section 12 says:
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
It should say:
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
SSH_MSG_KEXDH_INIT 30
SSH_MSG_KEXDH_REPLY 31
Notes:
This errata combines the partial errata reported by Denis Bider (errata ID 152 on 2006-01-23) and Dwayne Litzenberger (errata ID 1408 on 2008-04-11).
Errata ID: 152
Status: Rejected
Type: Editorial
Reported By: denis bider
Date Reported: 2006-01-23
Rejected by: Pasi Eronen
Date Rejected: 2008-08-11
Section 12 says:
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
It should say:
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
SSH_MSG_KEXDH_INIT 30
SSH_MSG_KEXDH_REPLY 3
Notes:
--VERIFIER NOTES--
Errata IDs 152 and 1408 are combined to 1486.
Errata ID: 1408
Status: Rejected
Type: Editorial
Reported By: Dwayne Litzenberger
Date Reported: 2008-04-11
Rejected by: Pasi Eronen
Date Rejected: 2008-08-11
Section 12 says:
SSH_MSG_KEXDH_INIT 30
SSH_MSG_KEXDH_REPLY 3
It should say:
SSH_MSG_KEXDH_INIT 30
SSH_MSG_KEXDH_REPLY 31
Notes:
This is a transcription error in the erratum dated 2006-01-23. Section 12 says "numbers 30-49 are used for kex packets", so using 3 for SSH_MSG_KEXDH_REPLY is clearly wrong. OpenSSH and python-paramiko both use 31, not 3.
--VERIFIER NOTES--
Errata IDs 152 and 1408 are combined into 1486.
Errata ID: 693
Status: Verified
Type: Technical
Reported By: Sam Weiler
Date Reported: 2006-02-10
Section 3.1 says:
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | fp type | /
It should say:
[not submitted]
Notes:
Section 3.1 has a packet format picture, and the upper row of bit
numbers seems to have been shifted to the left.
from pending
Errata ID: 1678
Status: Verified
Type: Technical
Reported By: Frank Cusack
Date Reported: 2009-02-03
Verifier Name: Pasi Eronen
Date Verified: 2009-02-16
Section 3.2 says:
The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
It should say:
The language tag MAY be the empty string. If acceptable/preferable languages were communicated during key exchange [SSH-TRANS], or in the SSH_MSG_USERAUTH_REQUEST message, the language tag SHOULD be the language selected by the server for the SSH_MSG_USERAUTH_INFO_REQUEST message.
Notes:
As originally pointed out by Alfred Hoenes (errata ID 758), this text
was incorrectly copy-pasted from Section 3.1.
The Information Request is sent from the server to the client, and it
already contains strings that make use of the particular
language/locale. The language tag in this message specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request. This parallels the use of the language tag
in, e.g., the Disconnection Message of the SSH Transport Layer
Protocol.
Errata ID: 758
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Pasi Eronen
Date Rejected: 2009-02-16
Section 3.2 says:
"Information Requests", on page 5, RFC 4256 says: The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. Instead, the server SHOULD select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent.
It should say:
[see Notes]
Notes:
[Replace by errata ID 1678]
(These two paragraphs apparently have been copied from Section 3.1
without change.)
This specification makes no sense here:
The Information Request is sent from the *server* to the client,
and it already contains strings that *do* make use of a particular
language/locale.
The one and only useful interpretation of the 'language tag'
in the Information Request message is that it specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request.
This parallels the use of the language tag, e.g., in the
Disconnection Message of the SSH Transport Layer Protocol
(cf. RFC 4253, Sect. 11.1).
NOTE: The client might have announced a locale *list* in the
initial exchange, and the server should choose from that list;
the actual choice [for a particular message with text strings]
needs to be communicated to the client.
NOTE: In multi-stage authentication, the backend authentication
mechanisms will be the source of all these strings, and the SSH
server might have no choice than to just report the locale used
by each backend mechanism to the client; such mechanisms easily
could make use of different locales - hence the locale needs to
be announced per message from the server in this context!
NOTE: RFC 4253 recommends to send empty language tags fields in
the initial exchange; this makes the 'language tag' field in all
SSH protocol messages containing text to be presented to the user
*very* desirable !
Therefore, the 'language tag' should also better *not* be deprecated
in the SSH_MSG_USERAUTH_INFO_REQUEST message!
from pending
--VERIFIER NOTES--
[Replaced by errata ID 1678]
Errata ID: 2611
Status: Verified
Type: Technical
Reported By: Mark Ellison
Date Reported: 2010-11-06
Verifier Name: Dan Romascanu
Date Verified: 2010-11-23
Section 5 says:
entStateOperEnabled NOTIFICATION-TYPE
.
.
.
...to find out whether
there were any known alarms against the entity at that
time that may explain why the physical entity has become
operationally disabled."
::= { entStateNotifications 1 }
entStateOperDisabled NOTIFICATION-TYPE
.
.
.
...to find out whether
there were any known alarms against the entity at that
time that may affect the physical entity's
ability to stay operationally enabled."
::= { entStateNotifications 2 }
It should say:
entStateOperEnabled NOTIFICATION-TYPE
.
.
.
...to find out whether
there were any known alarms against the entity at that
time that may affect the physical entity's
ability to stay operationally enabled."
::= { entStateNotifications 1 }
entStateOperDisabled NOTIFICATION-TYPE
.
.
.
...to find out whether
there were any known alarms against the entity at that
time that may explain why the physical entity has become
operationally disabled."
::= { entStateNotifications 2 }
Notes:
It appears that the text was inadvertently swapped in the DESCRIPTION clauses for the ~Enabled and ~Disabled notification definitions.
Errata ID: 826
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
(1)
In the CONTACT-INFO clauses of both MODULE-IDENTITY instances
(page 6 and page 10), apparently a text line (between the two
HTTP URIs given) has been blanked out inadvertently; usually,
"Working Group Charter:"
appears at similar places in other MIB definitions.
(2) [typo]
The DESCRIPTION clause of the EntityAlarmStatus TEXTUAL-CONVENTION
declaration contains a funny 'byte twist'.
It says (near the middle of page 8):
When the 'value of underRepair' is set, the resource is
currently being repaired, ...
It should say:
When the value of 'underRepair' is set, the resource is
currently being repaired, ...
(3)
In the DESCRIPTION clause of the entStateAdmin OBJECT-TYPE says:
Setting this object to 'notSupported' will result in an 'inconsistentValue' error. [...]
It should say:
Setting this object to 'unknown' will result in an 'inconsistentValue' error. [...]
Notes:
This is inconsistent with the value range for the EntityAdminState
TEXTUAL-CONVENTION describing the syntax of this object.
(Perhaps there's some history behind the scene.)
(4) [typo/grammar]
The fourth paragraph of the DESCRIPTION clause of the entStateOper
OBJECT-TYPE, 10 text lines from the bottom of page 12, says:
A value of 'testing' means that entity currently being
tested and cannot therefore report whether it is
operational or not.
It should perhaps better say:
vvvv
A value of 'testing' means that entity currently is
being tested and cannot therefore report whether it
is operational or not.
(5) [editing omission?]
The DESCRIPTION clause of the entStateStandby OBJECT-TYPE, near
mid-page 14, says:
Some entities will exhibit only a subset of the
remaining standby state values. [...]
^^^^^^^^^^
Perhaps this text has been 'cloned' without full adaptation.
Since, in this case, no possible value of the object has been
excluded by the text, the word "remaining" is inappropriate in
this context. Therefore, this clause should better say:
Some entities will exhibit only a subset of the
standby state values. [...]
(6) + (7) [typo/grammar]
The second paragraph of the DESCRIPTION clause of each of the
two NOTIFICATION-TYPE declarations, near the bottom of page 14
and near the top of page 15, contains the sentence:
The entity this notification refers can be identified by
extracting the entPhysicalIndex from one of the
variable bindings. [...]
Preferrably, this sentence should better say (in both instances):
vvvv
The entity this notification refers to can be identified
by extracting the entPhysicalIndex from one of the
variable bindings. [...]
It should say:
[see above]
Notes:
from pending
Errata ID: 2659
Status: Held for Document Update
Type: Technical
Reported By: Lloyd Wood
Date Reported: 2010-12-04
Held for Document Update by: Stephen Farrell
Section 3 says:
Integrity protection. It is common to compare a hash value that
is received out-of-band for a file with the hash value of the file
after it is received over an unsecured protocol such as FTP.
It should say:
Reliability checking and error detection. It is common to compare a hash value that
is received out-of-band for a file with the hash value of the file
after it is received over an unsecured protocol such as FTP.
Notes:
"integrity protection" is a term with specific meaning to security researchers, and that meaning doesn't gel with how the rest of the world uses terms like 'integrity' or 'protection,' or with the rest of this bullet point. So, we swap the term out for something less contentious.
This came up in discussion with Martin Rex and the IESG. Martin writes:
> Integrity protection is terminology that is used in the
> security&cryptographic area and this defect of rfc-4270 is going
> to create misunderstandings.
So, filing an erratum.
Errata ID: 2658
Status: Rejected
Type: Technical
Reported By: Lloyd Wood
Date Reported: 2010-12-04
Rejected by: Stephen Farrell
Date Rejected: 2011-11-12
Section 1 says:
The Internet protocol community needs to migrate in an orderly manner away from SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms.
It should say:
The Internet community needs to migrate in an orderly manner away from reliance for security purposes on SHA-1 and MD-5 -- especially MD5 -- and toward more secure hash algorithms for all security-related usages of hash functions in all protocols.
Notes:
This came up in discussion with Sean Turner, Martin Rex and the IESG over IESG Last Call: <draft-turner-md5-seccon-update-07.txt>.
RFC4270 lists seven uses for hash algorithms in section 3. MD5 should not be used for two of those [non-repudiable signatures and digital signatures in certificates] as those are are affected by collision attacks -- albeit only in limited circumstances. For the other five uses - particularly reliability checking (misnamed integrity protection in this draft) in a non-security context, MD5 remains fine to use. Martin flagged the original text as bad, and we came up with qualifiers - below.
On 3 Dec 2010, at 21:40, Martin Rex wrote:
> L.Wood@surrey.ac.uk wrote:
>> I also take issue with RFC4270's claim that:
>>
>> >The Internet protocol community needs to
>> > migrate in an orderly manner away from SHA-1 and MD5 -- especially
>> > MD5 -- and toward more secure hash algorithms.
>>
>> which is rather broad, and entirely without the context and qualifiers
>> we're discussing. RFC4270 was not written for a general audience,
>> but for a security audience. The Internet _security protocol_ community
>> may well need to migrate from these for certain uses (despite there not
>> yet being obvious things to move _to_), but RFC4270 and your draft's
>> sum take-away message that MD5BADDONOTUSE overstates the case.
>
> I agree that the above wording of rfc-4270 is BAD.
>
> It should have said:
>
> The Internet community needs to migrate in an orderly manner away from
> SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms
> for all security-related usages of hash functions in all protocols.
That wording is better, though I would also add a qualifier
on the front by saying 'away from reliance for security purposes on SHA-1
and MD-5...'. This should imo be filed as an erratum on RFC4270.
--VERIFIER NOTES--
This is a substantive change that would require "security-related" to be sufficiently well defined. Writing a draft about this would be better.
Errata ID: 1072
Status: Verified
Type: Editorial
Reported By: Henrik Levkowetz
Date Reported: 2005-12-02
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 1 says:
Hash algorithms are used by cryptographers in a variety of security protocols, for a variety of purposes, at all levels of the Internet protocol stack. They are used because they have two security properties: to be one way and collision free.
It should say:
Hash algorithms are used by cryptographers in a variety of security protocols, for a variety of purposes, at all levels of the Internet protocol stack. They are used because they have two security properties: to be one-way and collision-free.
Notes:
Note the " one way and collision free." On the face of it, as plain
English, this is nonsense. In cryptographic terminology, I believe
the correct expression is " one-way and collision-free."
Errata ID: 1633
Status: Verified
Type: Technical
Reported By: John Scudder
Date Reported: 2008-12-12
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02
Section 6.3 says:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
It should say:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
Notes:
This simply removes the clause "the attribute MUST be discarded", which doesn't make sense since the peering is to be terminated anyway.
Errata ID: 2838
Status: Verified
Type: Technical
Reported By: Jamie Taylor
Date Reported: 2011-06-16
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02
Section 8.2.2 says:
on page 72, description of the Established state: If the HoldTimer_Expires event occurs (Event 10), the local system: ...[list of actions to take]...
It should say:
If the HoldTimer_Expires event occurs (Event 10), the local system: - deletes all routes associated with this connection ...[list of actions in original text]...
Notes:
All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well.
Errata ID: 1332
Status: Rejected
Type: Technical
Reported By: Aaron Hughes
Date Reported: 2008-02-26
Rejected by: Stewart Bryant
Date Rejected: 2011-08-02
Section 4.5 says:
OPEN Message Error subcodes:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Optional Parameter.
5 - [Deprecated - see Appendix A].
6 - Unacceptable Hold Time.
It should say:
OPEN Message Error subcodes:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Optional Parameter.
5 - [Deprecated - see Appendix A].
6 - Unacceptable Hold Time.
7 - Unsupported Capability
Notes:
7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.
Thanks!
Aaron
--VERIFIER NOTES--
The working group debated this point and concluded the following:
The functionality (specifically, BGP Capabilities) this error code applies to does not appear anywhere in RFC 4271 (or RFC 1771). As IANA records, this error subcode is defined in RFC5492/RFC3392, along with the related functionality. The IANA registry is the final authority as to code point assignments, and is correct as written. Accordingly, this erratum is rejected.
Errata ID: 3031
Status: Reported
Type: Editorial
Reported By: Kireeti Kompella
Date Reported: 2011-11-14
Section 9.1.2 says:
The Phase 2 decision function is blocked from running while the Phase 3 decision function is in process.
It should say:
The Phase 3 decision function is blocked from running while the Phase 2 decision function is in process.
Notes:
I believe that is what was intended; the text as is confuses me no end.
Errata ID: 150
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2006-01-26
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-02
Section 9.1.1 says:
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
It should say:
The Phase 1 decision function is a separate process, which completes when it has no further work to do.
Errata ID: 148
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
(1) typo (missing word)
The second paragraph of Section 2.2, on page 4 of RFC 4274, says:
BGP uses an incremental update strategy to conserve bandwidth and
| processing power. That is, after initial exchange of complete
routing information, a pair of BGP routers exchanges only the changes
to that information. [...]
It should say:
BGP uses an incremental update strategy to conserve bandwidth and
| processing power. That is, after the initial exchange of complete
routing information, a pair of BGP routers exchanges only the changes
to that information. [...]
(2) typo
Section 2.3 contains (on page 5) the state description:
ACTIVE: State in which BGP peer is trying to acquire a peer
| by listening and accepting TCP connection.
It should say:
ACTIVE: State in which BGP peer is trying to acquire a peer
| by listening and accepting a TCP connection.
^^^
(An alternative correction, replacing 'connection' by 'connections',
does not precisely reflect the desired behaviour.)
(3) typos (multiple missing articles)
Section 4 of RFC 4274, on page 6, says:
Whenever a BGP speaker detects an error in a peer connection, it
shuts down the peer and changes its FSM state to IDLE. BGP speaker
requires a Start event to re-initiate an idle peer connection. If
the error remains persistent and BGP speaker generates a Start event
automatically, then it may result in persistent peer flapping.
Although peer oscillation is found to be wide-spread in BGP
implementations, methods for preventing persistent peer oscillations
are outside the scope of base BGP specification.
It should say:
Whenever a BGP speaker detects an error in a peer connection, it
| shuts down the peer and changes its FSM state to IDLE. A BGP speaker
requires a Start event to re-initiate an idle peer connection. If
| the error remains persistent and the BGP speaker generates a Start
event automatically, then it may result in persistent peer flapping.
Although peer oscillation is found to be wide-spread in BGP
implementations, methods for preventing persistent peer oscillations
| are outside the scope of the base BGP specification.
(4) inconsistency in updated text
The text of section 6.1 has been revised substantially from its
predecessor, RFC 1774. Unfortunately, the modifications have
not been performed incompletely, leading to near-nonsense text.
Section 6.1, on page 7, says:
Immediately after the initial BGP connection setup, BGP peers
exchange complete sets of routing information. If we denote the
total number of routes in the Internet as N, the total path
attributes (for all N routes) received from a peer as A, and assume
that the networks are uniformly distributed among the autonomous
systems, then the worst-case amount of bandwidth consumed during the
| initial exchange between a pair of BGP speakers (P) is
| BW = O((N + A) * P)
^^^^ ^^^^^
This makes no sense -- obviously you can't multiply by a non-numeric
quantity P, "a pair of BGP speakers".
I strongly suspect that it was the intention to say:
Immediately after the initial BGP connection setup, BGP peers
exchange complete sets of routing information. If we denote the
total number of routes in the Internet as N, the total path
attributes (for all N routes) received from a peer as A, and assume
that the networks are uniformly distributed among the autonomous
systems, then the worst-case amount of bandwidth consumed during the
| initial exchange between a pair of BGP speakers is
| BW = O((N + A))
Please verify.
(5) like (4)
Section 6.1.2, on page 8, exhibits similar symptoms as noted above.
The RFC says:
To quantify the worst-case memory requirements for BGP, we denote the
total number of networks in the Internet as N, the mean AS distance
of the Internet as M (distance at the level of an autonomous system,
expressed in terms of the number of autonomous systems), the total
number of unique AS paths as A. Then the worst-case memory
requirements (MR) can be expressed as
MR = O(N + (M * A))
Because a mean AS distance M is a slow moving function of the
interconnectivity ("meshiness") of the Internet, for all practical
purposes the worst-case router memory requirements are on the order
| of the total number of networks in the Internet multiplied by the
| number of peers that the local system is peering with. [...]
Apparently, the first part of that text has been revised eliminating
the role of the peering count. Thus the last sentence should have
been updated accordingly, to make it match the new formula.
The second paragraph thus perhaps should say:
Because a mean AS distance M is a slow moving function of the
interconnectivity ("meshiness") of the Internet, for all practical
purposes the worst-case router memory requirements are on the order
| of the total number of networks in the Internet. [...]
The final paragraph on page 8,
The following table illustrates typical memory requirements of a
router running BGP. We denote the average number of routes
advertised by each peer as N, the total number of unique AS paths as
A, the mean AS distance of the Internet as M (distance at the level
of an autonomous system, expressed in terms of the number of
autonomous systems), the number of octets required to store a network
as R, and the number of bytes required to store one AS in an AS path
| as P. It is assumed that each network is encoded as four bytes, each
AS is encoded as two bytes, and each networks is reachable via some
| fraction of all the peers (# BGP peers/per net). For purposes of the
| estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
^^^^ ^^^^
and the table on page 9,
vvvvvvvvvvvvvvvvvvv
| # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
| (N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000
exhibit additional issues:
- The text defines 'P' as
"the number of bytes required to store one AS in an AS path"
while apparently in the table (P) means
"# BGP peers/per net".
- 'S' in the formula in the last line of page 9 is not defined
anywhere in the text.
- "# BGP peers/per net" IMHO does not even make sense in the
context of BGP, since BGP speakers represent ASes, not networks
(prefixes).
I do not have a proposal for an easy way to get rid of these
inconsistencies.
Please check.
(6) typos / grammar
In Section 10, the second paragraph on page 13 says:
| BGP uses TCP MD5 option for validating data and protecting against
spoofing of TCP segments exchanged between its sessions. The usage
of TCP MD5 option for BGP is described at length in [RFC2385]. The
TCP MD5 Key management is discussed in [RFC3562]. BGP data
| encryption is provided using the IPsec mechanism, which encrypts the
| IP payload data (including TCP and BGP data). The IPsec mechanism
| can be used in both the transport mode and the tunnel mode. The
| IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option
| and the IPsec mechanism are not widely deployed security mechanisms
for BGP in today's Internet. Hence, it is difficult to gauge their
| real performance impact when using with BGP. However, because both
| the mechanisms are TCP- and IP-based security mechanisms, the Link
Bandwidth, CPU utilization and router memory consumed by BGP would be
| the same as any other TCP- and IP-based protocols.
It should say, correcting grammar and unclear semantics:
| BGP uses the TCP MD5 option for validating data and protecting
against spoofing of TCP segments exchanged between its sessions. The
usage of TCP MD5 option for BGP is described at length in [RFC2385].
The TCP MD5 Key management is discussed in [RFC3562]. BGP data
| encryption is provided using the IPsec ESP mechanism, which encrypts
| the IP payload data (including TCP and BGP data). The IPsec ESP
| mechanism can be used in both transport mode and tunnel mode. The
| IPsec ESP mechanism is described in [RFC2406]. Both the TCP MD5
| option and IPsec ESP are not widely deployed security mechanisms
for BGP in today's Internet. Hence, it is difficult to gauge their
| real performance impact when used with BGP. However, because both
| mechanisms are TCP- and IP-based security mechanisms, the Link
Bandwidth, CPU utilization and router memory consumed by BGP would be
the same as any for other TCP- and IP-based protocols.
(I am in doubt whether the last sentence is appropriate;
at least, "the same as" should better be replaced by "similar as".
Preferrably, I would delete that sentence.)
Finally, the 4th paragraph on page 13,
v
| Such flexible TCP- and IP-based security mechanisms, allow BGP to
prevent insertion/deletion/modification of BGP data, any snooping of
the data, session stealing, etc. [...]
should say:
| Such flexible TCP- and IP-based security mechanisms allow BGP to
prevent insertion/deletion/modification of BGP data, any snooping of
the data, session stealing, etc. [...]
(7) some Ref's inappropriately named Normative
The References "[BGP-VULN]" and "[SBGP]" do not fulfill the
criteria for being used as Normative References.
Their inclusion in Section 11.1, on page 14, might formally be
seen as inhibiting the progress of BGP-4 on the Standards Track.
Notes:
from pending
Errata ID: 147
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Section 7 says:
[RFC4274] Haas, J. and S. Hares, Eds., "Definitions of Managed
Objects for the Fourth Version of Border Gateway Protocol
(BGP-4)", RFC 4274, January 2006.
It should say:
[RFC4273] Haas, J. and S. Hares, Eds., "Definitions of Managed
Objects for BGP-4", RFC 4273, January 2006.
Notes:
All references in the text to RFC 4274 ( '[RFC4274]' )
should be changed to RFC 4273 ( '[RFC4273]' ).
Errata ID: 146
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-21
(1) Relationship to RFC 1773
While studying RFC 4277, and re-reading its predecessor, RFC 1773,
it became more and more unclear to me why RFC 1773 has not simply
been declared being obsoleted by RFC 4277 - or perhaps being done
so by RFC 4277 plus RFC 4276.
Almost all material contained in RFC 1773 has been expanded upon
in RFC 4277; only a few historical noted have been dropped -
which arguably are of no more interest from the point of view
of current standardization and implementation efforts.
Hence, RFC 4277 apparently is a perfect replacement for RFC 1773,
and it would have added to clarity about the status of the memos
making this visible in the RFC index by means of a pair of
related OBSOLETED BY and OBSOLETES notes.
(2) Inconsistencies with References
There are a few issues with References in RFC 4277:
(2a)
RFC 1965 had been obsoleted by RFC 3065, as noted in the text,
and consistently, the Ref. [RFC1965] has been placed into the
Informative References (Section 22.2), whereas [RFC3065] has
been recorded as a Normative Reference. That's pretty o.k.
A similar relation exists between RFC 1966 and RFC 2796 (that
had obsoleted the former), and the text contains a similar,
parallel treatment of this RFC pair as the pair noted above.
Nevertheless, the Ref. [RFC1966] has been placed in Section
22.1, Normative References.
That seems to be inappropriate and inconsistent; [RFC1996]
should have been filed as an Informative Reference.
(2b)
The first sentence of Section 3, on page 3, contains a citation to
"[BGP-MIB]" that can be assumed from the context to mean RFC 4273,
but there's no such entry in Section 22 !
Consistently with (2a) above, the Ref. [RFC1657] from Section 22.1
should better have been placed into Section 22.2, and instead of it,
a new entry [BGP-MIB] pointing to RFC 4273 inserted into the
Normative References, Section 22.1.
The following text might be considered for inclusion in an RFC
Errata Note for RFC 4277 to resolve isuues (2a) and (2b):
-----
RFC 4271, in Section 22.1, "Normative References", on page 17,
contains entries labeled '[RFC1966]' and '[RFC1657]' .
These entries should have been placed into Section 22.2,
"Informative References", instead.
Additionally, another entry should be added to Section 22.1 :
[BGP-MIB] Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed
Objects for BGP-4", RFC 4273, January 2006.
-----
(3) further errata (typos)
(3a)
The example network topology diagram in Section 8, on mid-page 8,
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
should say:
/---- transit B ----\
end-customer transit A----
\---- transit C ----/
Rationale: cf. RFC 1773 !
(3b)
Conforming to standard IPsec terminology, the first sentence
in Section 17.2 of RFC 4277 (on page 14),
vvv
BGP can run over IPsec, either in a tunnel or in transport mode,
where the TCP portion of the IP packet is encrypted. [...]
should better say:
vvvvvv
| BGP can run over IPsec, either in tunnel mode or in transport mode,
where the TCP portion of the IP packet is encrypted. [...]
or even, omitting that first 'mode' entirely,
| BGP can run over IPsec, either in tunnel or in transport mode, where
the TCP portion of the IP packet is encrypted. [...]
(3c)
The last sentence in Section 21 of RFC 4277, on page 16,
Finally, we'd like to think the IDR WG for general and specific input
that contributed to this document.
should say:
v
| Finally, we'd like to thank the IDR WG for general and specific input
that contributed to this document.
Notes:
from pending
Errata ID: 145
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Section 4.1 says:
Broadcast and Multicast Service Controller Domain Name List for DHCPv4
It should say:
Broadcast and Multicast Service Controller Domain Name List Option for DHCPv4
Notes:
Note: This RFC has been obsoleted by RFC6381
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 2859
Status: Verified
Type: Editorial
Reported By: Randall Gellens
Date Reported: 2011-07-12
Verifier Name: Wes Eddy
Date Verified: 2011-08-17
Section 3.1 says:
cod-fancy := "codecs*" ":=" encodedv
It should say:
cod-fancy := "codecs*" "=" encodedv
^^^
Notes:
The syntax is supposed to specify "=" not ":="
Errata ID: 757
Status: Verified
Type: Technical
Reported By: Peter Koch
Date Reported: 2005-12-13
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09
Section 2.6 says:
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035]. This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035], Fully Qualified Domain Names (FQDNs) such as 3com.com are commonly used and accepted by current software.
It should say:
[not supplied]
Notes:
section 2.6 missed the update of the hostname syntax in
RFC 1123, section 2.1.
RFC 1123 (STD 3) 2.1 allows labels starting with a <digit>
in fully qualified domain names of a host, RFC 1035 (STD 13)
2.3.1 still wants labels starting with a <letter>.
Errata ID: 816
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Held for Document Update by: Dan Romascanu
Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.
In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.
This is not true!
The pretended deviation in fact reflects the current standards.
The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:
"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."
and continues saying:
"Host software MUST handle host names of up to 63 characters
and SHOULD handle host names of up to 255 characters."
Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!
Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !
Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in
RFC 4282 that is on the IETF Standards Track.
o L2F [RFC2341] has been published for information only
as a Historic RFC 'ab initio'.
o PPTP [RFC2637] has purposely been rejected by the IETF --
because of its well known significant security flaws, among
other issues, and the Informational RFC 2637 has been
published with a very clear IESG Note to this end.
I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet. We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!
It should say:
[see above]
Notes:
from pending
Errata ID: 753
Status: Rejected
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2006-08-14
Rejected by: Dan Romascanu
Date Rejected: 2010-11-03
Section 2.1 says:
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
It should say:
[see below]
Notes:
Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?
--VERIFIER NOTES--
There is no clear suggested change. The chairs are aware about issues with RFC 4282, and believe that a new document is probably required to address them.
Errata ID: 1623
Status: Rejected
Type: Technical
Reported By: Martin Thomson
Date Reported: 2008-12-01
Rejected by: Dan Romascanu
Date Rejected: 2009-02-05
Section 2.1 says:
realm = 1*( label "." ) label
It should say:
realm = *( label "." ) label
Notes:
The ABNF for realm forces the inclusion of two labels, which is not consistent with RFC 1034, which allows just one:
<subdomain> ::= <label> | <subdomain> "." <label>
--VERIFIER NOTES--
Not allowing single-label realms was a deliberate decision (and the examples of invalid NAIs in Section 2.8 also include this case). One of the reasons was that RFC 1034 considers names without dots to be "relative" names of local significance. Such names may be valid DNS names for some other purposes than NAIs, though.
Errata ID: 1848
Status: Rejected
Type: Technical
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Normalization requirements, as specified in Section 2.2 of
[RFC4013], are also designed to assist in comparisons.
It should say:
o Normalization is, in general, a bad idea.
Notes:
Much of RFC 4282 is simply wrong.
Normalization can be done only when both the local and character set information is included with the text. And that information is not included with the username or realm.
In addition, not all systems will treat "User" the same as "user". The decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.
Errata ID: 1849
Status: Rejected
Type: Technical
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Bidirectional characters are handled as specified in Section 2.4
of [RFC4013].
It should say:
o Bidrectional characters are handled in a site-specific fashion
Notes:
The rules in [4013] have shortcomings. Updates are in:
http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.
Errata ID: 1850
Status: Rejected
Type: Technical
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Unassigned code points are specified in Section 2.5 of [RFC4013].
The use of unassigned code points is prohibited.
It should say:
o Unassigned code points MUST be ignored
Notes:
Unassigned code points sometimes go through a process called "assignment". This means that they suddenly become valid.
Implementations that forbid unassigned code points will not be updated when the standards change to assign them. Therefore, they should ignore unassigned code points.
Happily, this is what all implementations do.
--VERIFIER NOTES--
The suggested change should be discussed with the WG as part of a possible revision of the document.
Errata ID: 144
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-19
Section 5 says:
In addition, IANA has created a new namespace for the subtype field of the Mobile Node Identifier option. The currently allocated values are as follows: NAI (defined in [RFC4282]).
It should say:
In addition, IANA has created a new namespace for the subtype field
of the Mobile Node Identifier option. The currently allocated values
are as follows:
1 -- NAI (defined in [RFC4282]).
Errata ID: 143
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Section 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
Errata ID: 142
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Section 3.1.2 says:
3.1.2. AdvertisementJitter
This is the maximum time (in seconds) by which the
AdvertisementInterval is perturbed for each unsolicited
Advertisement. Note that the purpose of this jitter is to avoid
synchronization of multiple routers on a network, hence choosing a
value of zero is discouraged. This value MUST be an integer no less
than 0 seconds and no greater than AdvertisementInterval.
The AdvertisementJitter MUST be 0.025*AdvertisementInterval .
It should say:
3.1.2. AdvertisementJitter
This is the maximum time (in seconds) by which the
AdvertisementInterval is perturbed for each unsolicited
Advertisement. Note that the purpose of this jitter is to avoid
synchronization of multiple routers on a network.
The value of AdvertisementJitter is not independently configurable;
it is a variable derived internally within the implementation
from the configured value for AdvertisementInterval.
The AdvertisementJitter MUST be set to 0.025*AdvertisementInterval.
Errata ID: 141
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Section 4.2.2 says:
A Media type of "image" indicates that the content specifies or more
separate images that require appropriate hardware to display. ...
It should say:
A Media type of "image" indicates that the content specifies one or
more separate images that require appropriate hardware to display.
...
Errata ID: 818
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Two small editorial issues: - Perhaps as an artifact of the conversion of text from an existing RFC to a revised memo in I-D format and finally back to RFC format, along with repeated re-pagination, it can be observed from time to time that there appear unexpected blank lines in RFC text which visually break sentences apart. This recurring arifact has hit RFC 4288 near the top of its pages #8 and #10.
It should say:
[not submitted]
Notes:
I assume you're referring to the break between "linear" and "sequence". I agree
it should not have been there.
from pending
Errata ID: 2702
Status: Reported
Type: Technical
Reported By: Bassam Al-Khaffaf
Date Reported: 2011-02-01
Section 2.3 says:
For example, the following are legal representations of the 60-bit prefix 20010DB80000CD3 (hexadecimal): 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 2001:0DB8::CD30:0:0:0:0/60 2001:0DB8:0000:CD30::/60
It should say:
For example, the following are legal representations of the 60-bit prefix 20010DB80000CD3 (hexadecimal): 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 2001:0DB8:0000:CD30::/60
Notes:
According to the erratum reported on 2010-08-16 by Michael Rushton, the second text representation address of the example will be no more valid and should be taken away and keep the first and third ones.
This is because the use of "::" indicates two or more groups of 16 bits of zeros. Thank you
Errata ID: 2735
Status: Reported
Type: Technical
Reported By: Richard Hartmann
Date Reported: 2011-02-24
Section 2.2 says:
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address.
For example, the following addresses
2001:DB8:0:0:8:800:200C:417A a unicast address
FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified address
may be represented as
2001:DB8::8:800:200C:417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified address
It should say:
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates two or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address. All
compressed groups of 16 bits of zeros MUST be aligned with their
respective leading and trailing ":".
For example, the following addresses
2001:DB8:9300:0:12:0:0:417A a unicast address
FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified address
may be represented as
2001:DB8:9300:0:12::417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified address
and MUST NOT be represented as
2001:DB8:93::12:0:0:417A an incorrect unicast address
Notes:
Errata ID: 2466 would change the text I am changing, as well.
My changed text includes the change from errata 2466 to avoid the likelyhood of human mistakes.
In case http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming becomes a RFC before this errata can be worked in, "group of 16 bits of zeros" should be replaced with "$new_term of zeros" or similar. As it looks today, $new_term will most likely end up being "hextet".
The current wording allows for 2001:DB8:9300:12:0:0:417A to be written as 2001:DB8:93::12:0:0:417A which is clearly wrong and against the intentions behind the relevant RFCs. While RFC 5952 puts additional constraints on compression, it still allows for the incorrect example given above.
Thus, alignment of 16 bit groups of zeros along ":" is enforced specifically.
Errata ID: 2466
Status: Reported
Type: Editorial
Reported By: Michael Rushton
Date Reported: 2010-08-16
Section 2.2.2 says:
In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address.
It should say:
In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates two or more groups of 16 bits of zeros.
The "::" can only appear once in an address.
Errata ID: 1627
Status: Held for Document Update
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Held for Document Update by: RFC Editor
Date Held: 2008-12-03
Section 2.7 says:
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
It should say:
Routers must not forward any multicast packets beyond the scope indicated by the scop field in the destination multicast address.
Notes:
extraneous "of"
Errata ID: 863
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03
Section 2.7 says:
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; ...
It should say:
Nodes must not originate a packet to a multicast address whose scope field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scope field contains the reserved value F; ...
Notes:
Typo: scop --> scope (2 times)
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.
Errata ID: 864
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03
Section 2.7 says:
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
It should say:
Routers must not forward any multicast packets beyond the scope indicated by the scope field in the destination multicast address.
Notes:
Typo: scop --> scope; extraneous "of"
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.
[There is an extraneous "of", which has been listed in a separate report: Errata ID 1627.]
Errata ID: 865
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2007-12-03
Section 2.7 says:
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; ...
It should say:
Nodes must not originate a packet to a multicast address whose scope field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scope field contains the reserved value F; ...
Notes:
Typo: scop --> scope (2 times)
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.
Errata ID: 140
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
(1a)
The second paragraph of Section 3.2.11, on page 10, says:
The circumstances used in the compliance section are implementing
IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
than 20MB, between 20MB and 650MB, or greater than 650MB.
It should say:
The circumstances used in the compliance section are implementing
IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
| than 20Mbps, between 20Mbps and 650Mbps, or greater than 650Mbps.
(1b)
The DESCRIPTION clause of the ipSystemStatsHCOctetGroup, on page 87,
says:
"This group is mandatory for systems that have an aggregate
bandwidth of greater than 20MB. Including this group does
not allow an entity to neglect the 32 bit versions of these
objects."
It should say:
"This group is mandatory for systems that have an aggregate
| bandwidth of greater than 20Mbps. Including this group does
not allow an entity to neglect the 32 bit versions of these
objects."
(1c)
The DESCRIPTION clause of the ipSystemStatsHCPacketGroup,
on page 87/88, says:
"This group is mandatory for systems that have an aggregate
bandwidth of greater than 650MB. Including this group
<< page break >>
does not allow an entity to neglect the 32 bit versions of
these objects."
It should say:
"This group is mandatory for systems that have an aggregate
| bandwidth of greater than 650Mbps. Including this group
<< page break >>
does not allow an entity to neglect the 32 bit versions of
these objects."
(1d)
The DESCRIPTION clause of the ipIfStatsHCOctetGroup, on page 88,
says:
"This group is mandatory for systems that include the
ipIfStatsGroup and include links with bandwidths of greater
than 20MB. Including this group does not allow an entity to
neglect the 32 bit versions of these objects."
It should say:
"This group is mandatory for systems that include the
ipIfStatsGroup and include links with bandwidths of greater
| than 20Mbps. Including this group does not allow an entity
to neglect the 32 bit versions of these objects."
(1e)
The DESCRIPTION clause of the ipIfStatsHCPacketGroup, on page 88,
says:
"This group is mandatory for systems that include the
ipIfStatsGroup and include links with bandwidths of greater
than 650MB. Including this group does not allow an entity
to neglect the 32 bit versions of these objects."
It should say:
"This group is mandatory for systems that include the
ipIfStatsGroup and include links with bandwidths of greater
| than 650Mbps. Including this group does not allow an entity
to neglect the 32 bit versions of these objects."
(1f)
The DESCRIPTION clause of the ipv4SystemStatsHCPacketGroup,
onpage 88, says:
"This group is mandatory for all systems supporting IPv4 and
that have an aggregate bandwidth of greater than 650MB.
Including this group does not allow an entity to neglect the
32 bit versions of these objects."
It should say:
"This group is mandatory for all systems supporting IPv4 and
| that have an aggregate bandwidth of greater than 650Mbps.
Including this group does not allow an entity to neglect the
32 bit versions of these objects."
(2) improperly replicated description text
On page 35, the DESCRIPTION clauses of the ipSystemStatsOutFragReqds
OBJECT-TYPE and the ipSystemStatsOutFragOKs OBJECT-TYPE erroneously
contain identical clauses.
After analysis of the context it becomes apparent that the
DESCRIPTION clause of the ipSystemStatsOutFragReqds OBJECT-TYPE,
"The number of IP datagrams that would require fragmentation
in order to be transmitted.
When tracking interface statistics, the counter of the
outgoing interface is incremented for a successfully
fragmented datagram.
[...]
in fact should say:
"The number of IP datagrams that would require fragmentation
in order to be transmitted.
When tracking interface statistics, the counter of the
| outgoing interface is incremented for a datagram requiring
| fragmentation.
[...]
(Note: The original text is appropriate in the DESCRIPTION clause of
the ipSystemStatsOutFragOKs OBJECT-TYPE, where it appears again.)
(3) improperly replicated description text
On page 36, the DESCRIPTION clause of the ipSystemStatsOutFragCreates
OBJECT-TYPE says:
"The number of output datagram fragments that have been
generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the
| outgoing interface is incremented for a successfully
| fragmented datagram.
[...]
Obviously, the second sentence contradicts the first one.
( Apparently, this is an un-edited copy from the DESCRIPTION clauses
mentioned above, in item (2), that needs editing to be appropriate.)
Therefore, the RFC should say:
"The number of output datagram fragments that have been
generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the
outgoing interface is incremented for a successfully
| created datagram fragment.
[...]
(4) improperly replicated description text
On page 52, a "mirror" of issue (2) recurs, for the Interface
Statistics.
The DESCRIPTION clause of the ipIfStatsOutFragReqds OBJECT-TYPE
says:
"The number of IP datagrams that would require fragmentation
in order to be transmitted.
When tracking interface statistics, the counter of the
| outgoing interface is incremented for a successfully
| fragmented datagram.
[...]
It should say:
"The number of IP datagrams that would require fragmentation
in order to be transmitted.
When tracking interface statistics, the counter of the
| outgoing interface is incremented for a datagram requiring
| fragmentation.
[...]
(5) improperly replicated description text
On page 53, a "mirror" of issue (3) recurs, for the Interface
Statistics.
The DESCRIPTION clause of the ipIfStatsOutFragCreates OBJECT-TYPE
says:
"The number of output datagram fragments that have been
generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the
| outgoing interface is incremented for a successfully
| fragmented datagram.
[...]
It should say:
"The number of output datagram fragments that have been
generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the
outgoing interface is incremented for a successfully
| created datagram fragment.
[...]
(6) wrong object name
On page 60, the DESCRIPTION clause of the ipAddressPrefixType
OBJECT-TYPE,
"The address type of ipAddressPrefix."
mentions an object that does not exist in the MIB module.
That clause in fact should say:
| "The address type of ipAddressPrefixPrefix."
(7) two typos
On page 76, there are two typos in the ipDefaultRouterPreference
OBJECT-TYPE invocation:
The DESCRIPTION clause,
"An indication of preference given to this router as a
default router as described in he Default Router
Preferences document. [...]
should say:
"An indication of preference given to this router as a
| default router as described in the Default Router
Preferences document. [...]
^^
And the clause,
REFERENCE "RFC 4291, section 2.1"
should say:
| REFERENCE "RFC 4191, section 2.1"
^
(Otherwise, Ref. [8] would not have been needed at all!)
Notes:
from pending
Errata ID: 2526
Status: Reported
Type: Editorial
Reported By: Raphael Garti
Date Reported: 2010-09-19
Section 5 (p.76) says:
ipDefaultRouterLifetime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The remaining length of time, in seconds, that this router
will continue to be useful as a default router. A value of
zero indicates that it is no longer useful as a default
router. It is left to the implementer of the MIB as to
whether a router with a lifetime of zero is removed from the
list.
For IPv6, this value should be extracted from the router
advertisement messages."
REFERENCE "For IPv6 RFC 2462 sections 4.2 and 6.3.4"
::= { ipDefaultRouterEntry 4 }
It should say:
ipDefaultRouterLifetime OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The remaining length of time, in seconds, that this router
will continue to be useful as a default router. A value of
zero indicates that it is no longer useful as a default
router. It is left to the implementer of the MIB as to
whether a router with a lifetime of zero is removed from the
list.
For IPv6, this value should be extracted from the router
advertisement messages."
REFERENCE "For IPv6 RFC 2461 sections 4.2 and 6.3.4"
::= { ipDefaultRouterEntry 4 }
Notes:
The REFERENCE clause of ipDefaultRouterLifetime (p.76) refers to an RFC which does not contain the sections referred to. The correct reference should be to RFC 2461.
Note: This RFC has been obsoleted by RFC6434
Source of RFC: ipv6 (int)
Errata ID: 139
Status: Verified
Type: Technical
Reported By: Mark Andrews
Date Reported: 2006-04-11
Section 5.1 says:
Those nodes are NOT RECOMMENDED to support the experimental A6 and DNAME Resource Records [RFC-3363].
It should say:
Those nodes are NOT RECOMMENDED to support the experimental A6 Resource Records [RFC-3363].
Errata ID: 138
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-04-18
(1) Page 7, Section 4.4
The RFC 4294 text says:
4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463
ICMPv6 [RFC-2463] MUST be supported.
It should say:
4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC-4443] MUST be supported.
The title of Section 4.4 in the Table of Contents should be
adapted accordingly.
Rationale: RFC 4443 (replacing and obsoleting RFC 2463) has been
published exactly 3 weeks before RFC 4294, and hence should be
used as the currently valid reference.
(2) Page 7, Section 4.5.1
RFC 4294 says:
4.5.1. IP Version 6 Addressing Architecture - RFC 3513
The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
updated by [RFC-3879].
It should say:
4.5.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC-4291] MUST be supported.
Rationale: RFC 4291 (replacing and obsoleting RFC 3513, and thereby
incorporating RFC 3879) has been published more than 8 weeks before
RFC 4294, and hence should be used as the currently valid reference.
(3) Page 8, Section 5.1
RFC 4294 says:
DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
and [RFC-3596]. [...]
It should say:
DNS is described in [RFC-1034], [RFC-1035], [RFC-3363], and
[RFC-3596]. [...]
And subsequently, where RFC 4294 says,
- reverse addressing in ip6.arpa using PTR records [RFC-3152];
it should say:
- reverse addressing in ip6.arpa using PTR records [RFC-3596];
Rationale: RFC 3152 has been obsoleted and incorporated into RFC 3596.
(4) Page 10, Section 6.1.1
RFC 4294 says:
6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893
It should say:
6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213
Rationale: RFC 4213 (replacing and obsoleting RFC 2893) has been
published more than 6 months before RFC 4294, and hence should be
used consistently as the currently valid reference. (The text body
of the section has been updated accordingly, before publication.)
(5) Page 11, Section 8.2
RFC 4294 says:
8.2. Security Protocols
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported.
It should say:
8.2. Security Protocols
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MAY be supported.
Rationale: The new IPsec RFCs purposely have changed the requirement
level for AH. From RFC 4301, page 9, 1st paragraph of Section 3.2 :
[...] IPsec implementations MUST support ESP and MAY
support AH. (Support for AH has been downgraded to MAY because
experience has shown that there are very few contexts in which ESP
cannot provide the requisite security services. Note that ESP can be
used to provide only integrity, without confidentiality, making it
comparable to AH in most contexts.)
In Section 13, RFC 4301 lists the differences from RFC 2401,
and it states on page 74:
o Support for AH in both IPv4 and IPv6 is no longer required.
RFC 4294 does not give any arguments to override these statements.
(The IPsec references in RFC 4294 apparently have been changed
shortly before publication without due adaptation of the text.)
(6) Section 12.1, Normative References :
- The reference [RFC-2463] should be replaced by a reference to
RFC 4443 according to item (1) above.
- The reference [RFC-3152] (last item on page 14) should be deleted.
That RFC has been obsoleted long time ago, and the material has been
incorporated into RFC 3596 (see the entry [RFC-3596] on page 15)
according to item (3) above.
- The reference [RFC-3513] should be replaced by an entry [RFC-4291],
containing the proper reference to RFC 4291, according to item (2)
above.
- The reference [RFC-3879] is not needed any more according to
item (2) above; the material from RFC 3879 has been incorporated
into RFC 4291, the successor of RFC 3513 -- see item (2) above.
Notes:
from pending
Errata ID: 1915
Status: Reported
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-14
Section 5.2 says:
5.3.3. Use of Router Advertisements in Managed Environments
It should say:
5.2.3. Use of Router Advertisements in Managed Environments
Errata ID: 1939
Status: Reported
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-11-03
Section 12.1 says:
[RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version
3 of the Internet-standard Network Management
Framework", BCP 74, RFC 3584, August 2003.
It should say:
[RFC-3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February
2003.
Notes:
wrong reference
Errata ID: 137
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
(1) MIB object naming scheme broken
It is accepted consensus in the IETF to use a common, mnemonic scheme
for the naming of tables, table rows, and columnar objects within
these rows, namely (variable text to be instantiated shown as <..>):
<tableName>Table
<tableName>Entry
<tableName><Object1>
<tableName><Object2>
...
<tableName><Objectn>
or:
<tableName>Table
<tableName>Entry
<tableNameShort><Object1>
<tableNameShort><Object2>
...
<tableNameShort><Objectn>
where
<tableNameShort> is an abbreviated version of <tableName> .
Unfortunately, the mip6NodeTraffic counter table breaks this scheme.
Page 24 of RFC 4295 specifies:
Mip6NodeTrafficEntry ::=
SEQUENCE {
mip6NodeInOctets Counter32,
| mip6HCNodeInOctets Counter64,
mip6NodeInPkts Counter32,
| mip6HCNodeInPkts Counter64,
mip6NodeOutOctets Counter32,
| mip6HCNodeOutOctets Counter64,
mip6NodeOutPkts Counter32,
| mip6HCNodeOutPkts Counter64,
mip6NodeCtrDiscontinuityTime TimeStamp
}
As can be seen, the irregularity is in the 'HC' (Counter64) names;
"mip6HCNodeXxx" should have been replaced by "mip6NodeHCXxx", i.e.,
Mip6NodeTrafficEntry ::=
SEQUENCE {
mip6NodeInOctets Counter32,
| mip6NodeHCInOctets Counter64,
mip6NodeInPkts Counter32,
| mip6NodeHCInPkts Counter64,
mip6NodeOutOctets Counter32,
| mip6NodeHCOutOctets Counter64,
mip6NodeOutPkts Counter32,
| mip6NodeHCOutPkts Counter64,
mip6NodeCtrDiscontinuityTime TimeStamp
}
As the published irregular object names cannot be changed easily
after the fact, I hereby propose to introduce the regular object
names in a future update to the MIB module as *aliases* to the
irregular ones, bound to the same OIDs.
Of course,
- the OBJECT-TYPE declarations of the four affected MIB objects,
on page 25..28, and
- the definition of the mip6NodeTrafficGroup OBJECT-GROUP,
on page 81
would have to be adjusted accordingly.
( Perhaps, it would be best to change the symbolic object names
in the above SEQUENCE definition, and in the OBJECT-TYPE and
OBJECT-GROUP definitions, and add new OBJECT IDENTIFIER
definitions to introduce the old, irregular names again,
with the same OIDs, for backwards compatibility.)
(2) wrong object name in cloned DESCRIPTION clause
The DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, on page 28 of RFC 4295, apparently has been
cloned from another object without proper editing, and thus
refers to a wrong object, mip6NodeOutOctets, where it should
refer to the object, mip6NodeOutPkts.
Thus, the DESCRIPTION text (in the 12th line on page 28),
[...]
| This object is a 64-bit version of mip6NodeOutOctets.
[...]
should say:
[...]
| This object is a 64-bit version of mip6NodeOutPkts.
[...]
(3) clarification (text too much abbreviated)
The DESCRIPTION clause of the mip6MnHomeAddressState OBJECT-TYPE,
on page 30, suffers from a couple of word omissions.
The text:
home -- mobile node is on the home network.
registered -- mobile node is on a foreign network
and is registered with the home
agent.
pending -- mobile node has sent registration
request to the home agent and is
waiting for the reply.
isolated -- mobile node is isolated from network,
i.e., it is not in its home network,
it is not registered, and no
registration ack is pending.
should perhaps better say:
| home -- the mobile node is on the home
network.
| registered -- the mobile node is on a foreign
network and is registered with the
home agent.
| pending -- the mobile node has sent a
registration request to the home
agent and is waiting for the reply.
| isolated -- the mobile node is isolated from its
| home network, i.e., it is not in its
home network, it is not registered,
and no registration ack is pending.
(4) typo
The DESCRIPTION clause of the mip6MnBLAcceptedTime OBJECT-TYPE,
on page 39, says:
v
| "The time at which the mobile node receives a binding
acknowledgment indicating that Binding Update has
been accepted (status code 0 or 1);
[...]
It should say:
v
| "The time at which the mobile node received a binding
acknowledgment indicating that Binding Update has
been accepted (status code 0 or 1);
[...]
or even better (similar to the mip6MnBLAccepted DESCRIPTION on the
same page):
vvvv v
| "The time at which the mobile node has received a
binding acknowledgment indicating that Binding
Update has been accepted (status code 0 or 1);
[...]
(5) punctuation
The DESCRIPTION clause of the mip6MnCompliance2 MODULE-COMPLIANCE,
on page 93, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
support monitoring of the mobile node
| functionality specifically the Discovery- and
| Registration-related statistics,
There are a number of INDEX objects [...]
It should say:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
support monitoring of the mobile node
| functionality, specifically the Discovery- and
| Registration-related statistics.
There are a number of INDEX objects that cannot be
(6) description too unspecific
The DESCRIPTION clause of the mip6CnCompliance MODULE-COMPLIANCE,
on page 94, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
| support monitoring of the basic correspondent node
| functionality.
This is the same description text as supplied for the
mip6CnCoreCompliance (on the same page), and hence does not
suffice to distinguish these two compliance statements.
The above text perhaps should say:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and support
monitoring of the basic correspondent node
| functionality and per-MN BU traffic.
(7) description too unspecific, and punctuation
The DESCRIPTION clause of the mip6HaCompliance2 MODULE-COMPLIANCE,
on page 95, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
support monitoring of the home agent
| functionality specifically the Home Agent List
| and the home-agent-registration-related statistics,
There are a number of INDEX objects [...]
for reasons as in item (5) and item (6) above,
it should better say:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
| support detailed monitoring of the home agent
| functionality, specifically the Home Agent List
| and the home-agent-registration-related statistics.
There are a number of INDEX objects [...]
(8) punctuation, and extraneous blank line
The DESCRIPTION clause of the mip6HaCompliance3 MODULE-COMPLIANCE,
on page 96, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
support monitoring and control of the home agent
| functionality specifically the Home Agent List
| and the home-agent-registration-related statistics,
|
There are a number of INDEX objects [...]
It should say (see above items for rationale and similarity):
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB and
support monitoring and control of the home agent
| functionality, specifically the Home Agent List
| and the home-agent-registration-related statistics.
There are a number of INDEX objects [...]
(9) punctuation, and extraneous blank line
The DESCRIPTION clause of the mip6HaReadOnlyCompliance2
MODULE-COMPLIANCE, on page 99, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB without support
for read-write (i.e., in read-only mode) and
support monitoring of the home agent
| functionality specifically the Home Agent List
and the home-agent-registration-related statistics.
|
There are a number of INDEX objects [...]
It should say (see above items for rationale and similarity):
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB without support
for read-write (i.e., in read-only mode) and
support monitoring of the home agent
| functionality, specifically the Home Agent List
and the home-agent-registration-related statistics.
There are a number of INDEX objects [...]
(10) punctuation, and extraneous blank line
The DESCRIPTION clause of the mip6HaReadOnlyCompliance3
MODULE-COMPLIANCE, on page 101, says:
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB without support
for read-write (i.e., in read-only mode) and
? support monitoring and control of the home agent
| functionality specifically the Home Agent List
| and the home-agent-registration-related statistics,
|
There are a number of INDEX objects [...]
It should say (see above items for rationale and similarity):
"The compliance statement for SNMP entities
that implement the MOBILEIPV6-MIB without support
for read-write (i.e., in read-only mode) and
support monitoring and control of the home agent
| functionality, specifically the Home Agent List
| and the home-agent-registration-related statistics.
There are a number of INDEX objects [...]
Furthermore, arguably the words "and control" should better be
deleted since write access is not required.
Notes:
The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.
from pending
Errata ID: 136
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-06
Verifier Name: lars.eggert@nokia.com
Date Verified: 2008-12-10
Section 2.2.1 says:
void rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d)
It should say:
rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)
Notes:
This is inconsistent with the detailed description of that primitive
given subsequently on page 15 (2nd-to-last list paragraph), which
specifies four (4) arguments.
The latter, detailed spec is the appropriate version.
Errata ID: 2180
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 4.4.2.2. says:
OPAQUE**** 0 prot. "P" OPAQUE
It should say:
OPAQUE**** 0 prot. "P" discard packet
Notes:
Opaque means protocol must not be available. Therefore this packet does not match and must be discarded.
The same four times more.
Errata ID: 2184
Status: Verified
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section D2 says:
We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields.
It should say:
We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. But we did not. ANY encompasses OPAQUE.
Notes:
misleading
Errata ID: 2178
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 4.1.1. says:
SPD-S, SPD-I, SPD-O Pages 20,21
It should say:
Needs to be formulated differently.
Notes:
This text needs information which comes later in RFC4301. There must be an explanation of decorrelation (hint on Appendix B).
The part of outbound traffic is confusing. If you have no SPD-S entries, you can handle it the same way as explained for inbound traffic.
--VERIFIER NOTES--
There is no section 4.1.1.
Errata ID: 135
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04
Appendix A2 says:
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
It should say:
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE
-- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE
(CHANGES UNPREDICTABLY DURING TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
Notes:
Perhaps it should be formatted as shown above to avoid the overlap of the columns.
Errata ID: 717
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11
(1) [typo]
In section 4.1, on page 14, RFC 4301 says:
DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
as that term in used in this architecture, the sender will need a
mechanism to direct packets with a given (set of) DSCP values to the
appropriate SA. This mechanism might be termed a "classifier".
It should say ( s/in used/is used/ ) :
DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
| as that term is used in this architecture, the sender will need a
mechanism to direct packets with a given (set of) DSCP values to the
appropriate SA. This mechanism might be termed a "classifier".
(2) [textual improvement]
In section 4.4.3.2, the last lines on page 45 say:
[...]. An entry
used with certificate-based authentication MAY include additional
data to facilitate certificate revocation status, e.g., a list of
<< page break >>
appropriate OCSP responders or CRL repositories, [...]
This seems to make not much sense. It should perhaps say:
[...]. An entry
used with certificate-based authentication MAY include additional
data to facilitate certificate revocation status determination, e.g.,
a list of appropriate OCSP responders or CRL repositories, [...]
(3) [typo]
The second paragraph of section 4.4.3.3, on page 46, says:
If the entry indicates that the IKE ID is to be used, then the PAD
entry ID field defines the authorized set of IDs. If the entry
indicates that child SAs traffic selectors are to be used, then an
additional data element is required, in the form of IPv4 and/or IPv6
address ranges. [...]
It should say ( s/SAa/SA/ ) :
If the entry indicates that the IKE ID is to be used, then the PAD
entry ID field defines the authorized set of IDs. If the entry
| indicates that child SA traffic selectors are to be used, then an
additional data element is required, in the form of IPv4 and/or IPv6
address ranges. [...]
(4) [textual consistency]
Below the table on page 59, section 5.1.2.2 says:
Notes:
(1) - (6) See Section 5.1.2.1.
It should say:
Notes:
| (1) - (3), (5), (6) See Section 5.1.2.1.
(5) [typo]
The second paragraph of App. D.2, on page 89, says:
[...]. (If we choose
to allow carriage of fragments on transport mode SAs for IPv6, the
problems arises in that context as well.)
^ ^^
There obviously is a singular/plural mismatch.
The text should say:
[...]. (If we choose
to allow carriage of fragments on transport mode SAs for IPv6, the
| problem arises in that context as well.)
(6) Insufficient IPcomp integration
At the end of section 3.1, on page 10, RFC 4301 says:
IPsec optionally supports negotiation of IP compression [SMPT01],
motivated in part by the observation that when encryption is employed
within IPsec, it prevents effective compression by lower protocol
layers.
It has also been observed that payload compression can help counter
TPA. Thus, there are at least two reasons for a tight integration
of IPComp with IPsec.
But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303
as well) for the concrete support of IPComp in ESP / AH IPsec SAs.
IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall
that be triggered and work, in an interoperable way, if there are no
architectural provisions for the support of IPComp designed in into
the IPsec databases (SPD, SAD) as described in RFC 4301 ????
(7) Insufficient integration with QoS (DS)
The steps taken for the integration with Differentiated Services
are half-hearted. The processing rules specified for the DSCP
field in the IP header[s] remain incomplete as long as there is
no specified interoperable way to use DSCP as an selector as well.
IMHO, the discussion on page 14 of RFC 4301 is misleading because
DS classification and treatment needs to be done independent from
IPsec treatment.
In many scenarios, e.g. on 'hosts' or 'QoS gateways' that must
perform fine-grained traffic classification, DS treatment must
be performed strictly before IPsec treatment in the outbound
case (and after IPsec in the inbound case), to make ULP fields
accessible to the DS classifiers.
IPsec should then be capable of guaranteeing the same security
treatment of all packets of certain traffic class to a given
destination.
I still have problems to imagine how DS integration could be
achieved with the processing model of section 5.1 of RFC 4301.
At the end of section 3.1, on page 10, RFC 4301 says:
(8) Inconsistent DS Field handling specified in Section 5.1.2.x
The IPv6 related table in section 5.1.2.2 contains the line,
DS Field copied from inner hdr (5) no change (9)
and the subsequent Notes give a lengthy explanation under (9).
Contrary to that, the corresponding table line for IPv4, in section
5.1.2.1 on page 57, is *not* linked to such a note.
I cannot see any reason precluding the application of the arguments
given in Note (9) of section 5.1.2.2 to the IPv4 case as well.
Have I missed any significant point there?
(9) SA negotiation -- capability mismatch with IKEv2
See section 4.4.1.2, second paragraph.
It should say:
[see above]
Notes:
from pending
Errata ID: 1684
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-02-17
Held for Document Update by: Pasi Eronen
Section 4.5.3. says:
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass.
It should say:
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which SH1's traffic must pass.
Errata ID: 1713
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-03-12
Held for Document Update by: Pasi Eronen
Section 12 says:
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
It should say:
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
Notes:
See http://www.iana.org/assignments/smi-numbers
Errata ID: 2179
Status: Held for Document Update
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 4.4.2.2 says:
list of prot's
It should say:
list of prots
Notes:
This is not genitive. It's plural.
Errata ID: 2181
Status: Held for Document Update
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk
Section 4.4.3.1. says:
The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type.
It should say:
The Key ID field is defined as an OCTET string in IKE. For this name type, exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type.
Notes:
'only A must be supported' is ambigous.
Does it mean 'A must be supportet and anything else must not be supportet', or does it mean 'A must be supportet and anything else may be supportet'. The next sentence clearifies that it is the second interpretation.
Errata ID: 2182
Status: Held for Document Update
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk
Section 4.4.3.2 says:
This document requires support for two required authentication data types:
It should say:
This document requires support for two authentication data types:
Notes:
pleonasm
Errata ID: 2183
Status: Rejected
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 5.1. says:
There is no requirement that an implementation buffer the packet if there is a cache miss.
It should say:
There is no requirement that an implementation buffers the packet if there is a cache miss.
Notes:
typo
--VERIFIER NOTES--
original text was grammatically correct.
Errata ID: 2661
Status: Rejected
Type: Editorial
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Rejected by: Sean Turner
Date Rejected: 2011-03-10
Section header block says:
Obsoletes: 2401
It should say:
Obsoletes: 2401 Updates: 3168
Notes:
RFC 4301 updates RFC 3168 but does not indicate this in its header block.
Specifically, RFC 4301 updates the processing of the ECN field for IPsec tunnel mode that was specified in RFC 3168.
--VERIFIER NOTES--
This action was taken already. The RFC index is already updated and so is the datatracker.
Errata ID: 134
Status: Verified
Type: Technical
Reported By: Vishwas Manral
Date Reported: 2006-01-12
Section 3.3.4 says:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
It should say:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header, and either the More flag or the Fragment Offset is non-zero. If so that packet needs reassembling prior to IPsec processing.
Errata ID: 744
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
(1)
RFC 4301, in section 13, "Differences from RFC 2401", in the
second bulleted item (near the top of page 73) states:
o There is no longer a requirement to support nested SAs or "SA
bundles". [...]
And later on, on page 74:
o Support for AH in both IPv4 and IPv6 is no longer required.
Therefore, the paragraph on page 10 of RFC 4302,
ESP and AH headers can be combined in a variety of modes. The IPsec
Architecture document describes the combinations of security
associations that must be supported.
^^^^^^^^^^^^^^^^^
entails more or less a "NOPE". If something like the second
sentence is still desired, it might better say, e.g.,
ESP and AH headers can be combined in a variety of modes. The IPsec
Architecture document briefly describes the methods to configure
such combinations of security associations.
(2)
On page 25, Appendix A1 presents a table classifying the IPv4 options.
Within that table, the second column is partially misaligned.
(3)
On page 26, the table within Appendix A2 classifying the IPv6
extension headers,
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
perhaps would have better been formatted like:
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE
-- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE
(CHANGES UNPREDICTABLY DURING TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
to avoid the overlap of the columns.
(4)
In Appendix B2.1, at one place on page 30, the variable
"seqh" is mis-spelled as "seqH" (this is in the 6th-to-last
line of Appendix B2.1).
(5)
Appendix B, as a whole, is a [near] duplicate of Appendix A of
RFC 4303; the latter does not contain the typo from item (4)
above, and it contains extended and improved explanations in
the third subsection -- corresponding to page 32 of RFC 4302.
Readers and potential implementors need to read both Appendices
just to detect that they are in fact essentially the same spec.
IMHO, it would have been better to avoid this re-specification,
and instead have pointers to the (better, and mandatory!) ESP
Appendix placed into the AH RFC.
Having a single specification always avoids disagreement or
inconsistency, and it facilitates the maintenance of the spec.
(6)
Finally:
I would have appreciated the introduction of an explicit version
numbering for AH, e.g. rename:
AH as per RFC 1826 to AHv1,
AH as per RFC 2402 to AHv2 or AHv2.0, and
AH as per RFC 4302 to AHv3 or AHv2.1
(or similar).
This would make it easier to specify / identify versions and/or
version specific behaviour in implementations, without having
to refer to the RFC numbers explicitely. (Similar numbering has
proven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)
It should say:
[see above]
Notes:
from pending
Errata ID: 2188
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-30
Section 3.3.3.2.2. says:
If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
It should say:
The padding bytes MUST be zero. The algorithm MUST NOT specify anything else.
Notes:
This is forced two times in this RFC4302, namely before in this
section 3.3.3.2.2 and in 3.4.4 .
--VERIFIER NOTES--
Section 3.4.4 deals with verification of the ICV, whereas section 3.3.3 deal with generation of an ICV. Thus discussion of padding is needed in both contexts and is not redundant. The text should remain as it is.
Errata ID: 2189
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 3.4.3. says:
received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for
It should say:
received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's left edge's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for
Notes:
--VERIFIER NOTES--
There is no mention of a "left edge sequence number counter" in 4302.
Errata ID: 1644
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-12-25
Held for Document Update by: Pasi Eronen
Section B2 says:
Appendix B2 says:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
It should say:
Must say:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 2)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 3)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 3 -- Case B
Notes:
Wrong numbers for figures in Section B2.
Errata ID: 1645
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-12-26
Held for Document Update by: Pasi Eronen
Section B2.2 says:
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
It should say:
+ Under Case A (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 3):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
Notes:
Wrong numbering for figures
Errata ID: 2157
Status: Held for Document Update
Type: Editorial
Reported By: Carsten Bormann
Date Reported: 2010-04-10
Held for Document Update by: Sean Turner
Section 2.5 says:
anti-reply
It should say:
anti-replay
Notes:
(End of first para.)
Obvious, but maybe confusing to learners.
Errata ID: 2185
Status: Rejected
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 2.4. says:
datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
It should say:
datagrams to SAs. Implementations that support only unicast traffic need not to implement this de-multiplexing algorithm.
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.
Errata ID: 2186
Status: Rejected
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 2.5. says:
Verification". Thus, the sender MUST always transmit this field, but the receiver need not act upon it.
It should say:
Verification". Thus, the sender MUST always transmit this field, but the receiver needs not to act upon it.
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.
Errata ID: 2187
Status: Rejected
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 3.3.3.2.1. says:
(The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation,
It should say:
(The padding is arbitrary, but needs not to be random to achieve security.) These padding bytes are included in the ICV calculation,
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.
Errata ID: 133
Status: Verified
Type: Technical
Reported By: Vishwas Manral
Date Reported: 2006-01-12
Section 3.3.4 says:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
It should say:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header, and either the More flag or the Fragment Offset is non-zero. If so that packet needs reassembling prior to IPsec processing.
Errata ID: 1654
Status: Verified
Type: Technical
Reported By: Nikolai Malykh
Date Reported: 2009-01-16
Verifier Name: Pasi Eronen
Date Verified: 2009-06-18
Section 3.4.4.1 says:
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append zero-filled bytes to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
It should say:
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append padding bytes (according integrity
algorithm specification, see Section 3.3.2.1) to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
Notes:
(confirmed by Stephen Kent)
Errata ID: 721
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11
(1)
Section 2.1 of RFC 4303 re-states a lot of material from the
IPsec Architecture document, RFC 4301, without being able to
present all the details. SPI selection has become a quite
complicated procedure with subtle details, which all can be
found in RFC 4301.
IMHO, it would have been very much preferrable to replace most
of the text in section 2.1 by a short referral to RFC 4301.
Any replication of specification entails the danger of
inconsistencies and raises the question of "truth weight"
for the concurring specifications; it is better to avoid
such "races" from the beginning.
This same issue applies to section 2.4 of RFC 2402. (By accident,
I have forgotten to mention it in my comments on that document.)
More concretely, I would have preferred the replacement of the
second up to the second-to-last paragraph of section 2.1 of RFC 4303,
on pages 10/11,
For a unicast SA, the SPI can be used by itself to specify an SA, or
it may be used in conjunction with the IPsec protocol type (in this
...
...
...
...
...
multicast address, and source address. An Any-Source Multicast group
SA requires only an SPI and a destination multicast address as an
identifier.
by a short note, e.g.
All implementations of ESP MUST support the Security Association
Database (SAD) as specified in the IPsec Archtecture document
[Ken-Arch] and the SA lookup procedures for unicast traffic
specified therein. ESP implementations SHOULD support extensions
to the SAD and the SA lookup procedures specified in documents
amending [Ken-Arch], e.g. for multicast traffic or mobility support,
if they intend to provide ESP support for such scenarios.
A similar change would be applicable to RFC 4302, section 2.4,
pages 6/7.
(2)
In section 3.4.3, on the lower half of page 29, RFC 4303 says:
[...]. In either
case, if the integrity check fails, the receiver MUST discard the
received IP datagram as invalid; this is an auditable event. The
audit log entry for this event SHOULD include the SPI value,
[...]
Because the audit log details are in a separate sentence, the logical
hierarchy implied by using one semicolon and one full stop is brocken.
It would have been better to say:
[...]. In either
case, if the integrity check fails, the receiver MUST discard the
| received IP datagram as invalid. This is an auditable event. The
audit log entry for this event SHOULD include the SPI value,
[...]
Similar punctuation already is used in many places of the RFC.
(3)
As mentioned in section 7, section 3.4 has been reorganized from
RFC 2406.
During that process, the perhaps most important part of ESP inbound
packet processing has disappeared from the section headlines:
decryption !
To cover what's inside, and to make that locatable in the ToC,
perhaps the section headline,
3.4.4. Integrity Check Value Verification
on page 30, and in the ToC, should be modified to read:
3.4.4. Integrity Check Value Verification and Payload Decryption
I would like to recommend that you submit an RFC Errata Note to
catch this issue.
(4)
In section 3.4.4.2, the same issue as (2) above also applies to
the item numbered "2." on page 32.
(5) References
RFC 4306 repeatedly refers to its predecessor, RFC 2406, but it omits
giving a formal (Informative) Reference to that document in Section
10.2 on page 37.
Perhaps it would also have been worth noting that a *full* version
of the research paper [Kra01] can be found on IACR ePrint, document
2001/040.
(6) Appendix A
As mentioned in my comments on RFC 4302, this appendix is the more
complete and hence preferrable text compared to App. B of RFC 4302.
There is one exception:
The formatting of tha last part of A2.1 ia less pleasant.
To enhance readability, it is always preferrable not to break
simple expressions apart by line breaks, whenever possible. In
this case, simple relational expressions are broken into 2 lines.
RFC 4303, on page 40, says:
In checking for replayed packets,
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
The formatting in RFC 4302 of the same text (with the already
mentioned typo there corrected, and the Appendix name adapted),
is better:
In checking for replayed packets,
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix A2.2
below for determination of Seqh).
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix A2.2
below for determination of Seqh).
But I would even have preferred this formatting:
In checking for replayed packets,
+ Under Case A:
If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl,
then check the corresponding bit in the window to see if this
Seql has already been seen. If yes, reject the packet.
If no, perform integrity check (see Appendix A2.2 below for
determination of Seqh).
+ Under Case B:
If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl,
then check the corresponding bit in the window to see if this
Seql has already been seen. If yes, reject the packet.
If no, perform integrity check (see Appendix A2.2 below for
determination of Seqh).
It should say:
[see above]
Notes:
from pending
Errata ID: 859
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
The 'version numbering' issue (as reported as item (6) for RFC 4302)
I would have appreciated the introduction of an explicit version
numbering for ESP, e.g. rename:
ESP as per RFC 1827 to ESPv1,
ESP as per RFC 2406 to ESPv2 or ESPv2.0, and
ESP as per RFC 4303 to ESPv3 or ESPv2.1
(or similar).
This would make it easier to specify / identify versions and/or
version specific behaviour in implementations, without having
to refer to the RFC numbers explicitely. (Similar numbering has
proven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)
Notes:
from pending
Note: This RFC has been obsoleted by RFC4835
Source of RFC: ipsec (sec)
Errata ID: 132
Status: Verified
Type: Technical
Reported By: Donald Eastlake III
Date Reported: 2006-02-20
In the header, it says:
Obsoletes: 2404, 2406
It should say:
Obsoletes: 2402, 2406
Note: This RFC has been obsoleted by RFC5996
Source of RFC: ipsec (sec)
Errata ID: 2190
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 2.5. says:
Similarly, payload types that are not defined are reserved for future use; implementations of version 2.0 MUST skip over those payloads and ignore their contents.
It should say:
Similarly, payload types that are not defined are reserved for future use.
Notes:
The behaviour of an implementation of version 2.0 depends on the critical flag. See next paragraph.
Errata ID: 2191
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.2. says:
whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the Critical bit's value. Skipped payloads are expected to have valid Next
It should say:
?
Notes:
Difficult to understand. More explanation needed:
An implementation of IKE which is older than 2.0 does not know about the
critical bit and will skip an unknown payload. This behaviour fits to
cleared critical bit.
Errata ID: 2192
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.3. says:
If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple Transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or
It should say:
If there are multiple transforms with the same Transform Type, those transforms constitute a group out of which exactly one transform is to be chosen. If there are multiple of those groups, the proposal is an AND of the choices out of the different groups. For example, to propose ESP with (3DES or
Notes:
Logically unclear. OR means AND/OR. But here you talk about XOR.
Furthermore has AND precedence before OR.
Errata ID: 2194
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.12. says:
identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0).
It should say:
- delete it -
Notes:
According to 3.2 the critical bit has to be clear.
And the rest is trivial: To be compliant you have to comply.
Errata ID: 2195
Status: Held for Document Update
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.15. says:
Some attributes MAY be multi-valued, in which case multiple attribute values of the same type are sent and/or returned. Generally, all values of an attribute are returned when the attribute is requested.
It should say:
Some attributes MAY be multi-valued, in which case multiple Configuration Attribute structures of the same type are sent and/or returned. Generally, all values of an attribute are returned when the attribute is requested.
Notes:
The text may suggest that there may be multiple values in one
Configuration Attribute structure.
Errata ID: 2193
Status: Rejected
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-05-07
Section 3.3.5. says:
Attribute Type Value Attribute Format
--------------------------------------------------------------
RESERVED 0-13 Key Length (in bits)
14 TV RESERVED 15-17
RESERVED TO IANA 18-16383 PRIVATE USE
16384-32767
Values 0-13 and 15-17 were used in a similar context in IKEv1 and
should not be assigned except to matching values. Values 18-16383
are reserved to IANA. Values 16384-32767 are for private use among
mutually consenting parties.
- Key Length
When using an Encryption Algorithm that has a variable-length key,
this attribute specifies the key length in bits (MUST use network
byte order). This attribute MUST NOT be used when the specified
Encryption Algorithm uses a fixed-length key.
It should say:
?
Notes:
I do not understand anything.
Therefore I cannot offer a better formulation.
--VERIFIER NOTES--
No alternative text was proposed. Note that I did forward this to the authors of draft-ietf-ipsecme-ikev2bis.
Errata ID: 2279
Status: Verified
Type: Editorial
Reported By: Sergiu Todirascu
Date Reported: 2010-05-19
Verifier Name: Sean Turner
Date Verified: 2010-07-21
Section 3.3.2 says:
Name Number Defined In
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1826)
AUTH_AES_XCBC_96 5 (RFC3566)
It should say:
Name Number Defined In
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1828)
AUTH_AES_XCBC_96 5 (RFC3566)
Notes:
The RFC for AUTH_KPDK_MD5 should be 1828, not 1826 which is the first version of AH.
Errata ID: 1671
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-01-28
Held for Document Update by: Pasi Eronen
Section 3.1 says:
-- V(ersion) (bit 4 of Flags) - This bit indicates that
the transmitter is capable of speaking a higher major
version number of the protocol than the one indicated
in the major version number field. Implementations of
IKEv2 must clear this bit when sending and MUST ignore
it in incoming messages.
It should say:
-- V(ersion) (bit 4 of Flags) - This bit indicates that
the transmitter is capable of speaking a higher major
version number of the protocol than the one indicated
in the major version number field. Implementations of
IKEv2 MUST clear this bit when sending and MUST ignore
it in incoming messages.
Errata ID: 1672
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2009-01-29
Held for Document Update by: Pasi Eronen
Section 3.3.2 says:
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last
Proposal could be identified from the length of the SA.
It should say:
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last
Transform could be identified from the length of the Proposal.
Errata ID: 2196
Status: Held for Document Update
Type: Editorial
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 3.15. says:
For some attributes (in this version of the specification only internal addresses), multiple requests indicates a request that multiple values be assigned. For these attributes, the number of
It should say:
For some attributes (in this version of the specification only internal addresses), multiple requests indicate a request that multiple values be assigned. For these attributes, the number of
Notes:
typo
Errata ID: 1937
Status: Verified
Type: Technical
Reported By: Tero Kivinen
Date Reported: 2009-11-02
Verifier Name: Pasi Eronen
Date Verified: 2010-03-01
Section 3.1.3. says:
ENCR_NULL 11 [RFC2410] MAY
It should say:
ENCR_NULL 11 [RFC2410] MUST NOT
Notes:
ENCR_NULL is MUST NOT for IKEv2, as RFC4306 specifies that ENCR_NULL MUST NOT be used as IKE encryption algorithm (RFC4306 section 5).
Errata ID: 131
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen
Section 3.1.3 says:
IKEv2 defines several possible algorithms for Transfer Type 1 (encryption). These are defined below with their implementation status.
It should say:
IKEv2 defines several possible algorithms for Transform Type 1 (encryption). These are defined below with their implementation status.
Errata ID: 685
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen
Section 3.1.4 says:
Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed.
It should say:
Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed.
Notes:
from pending
Errata ID: 687
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen
Section 3.1.5 says:
Transfer Type 3 Algorithms are Integrity algorithms used to protect data against tampering.
It should say:
Transform Type 3 Algorithms are Integrity algorithms used to protect data against tampering.
Notes:
from pending
Errata ID: 688
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen
Like other contemporary RFCs, RFC 4307 seems to have been infected by a common 'virus'. In the case or RFC 4307, the first sentence of the Introduction has been inadvertantly split by a spurious blank line.
Notes:
from pending
Errata ID: 690
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Pasi Eronen
On pages 3 and 4 of RFC 4307, the text in Section 3.1.3 through Section 3.1.5 contains three instances of the same typo, talking about [algorithms of] "Transfer Type <n>" , where it should refer to [algorithms of] "Transform Type <n>".
Notes:
typo breaking IPsec terminology
from pending
Errata ID: 1090
Status: Verified
Type: Technical
Reported By: Paul Hoffman
Date Reported: 2007-12-08
Verifier Name: Tim Polk
Date Verified: 2008-11-20
Section 2 says:
<none>
It should say:
2.4 Hash Algorithm for IKEv1 This document does not specify a hash algorithm to negotiate for IKEv1. Any hash algorithm can be used; SHA-1 is a common choice. No hash algorithm is needed for IKEv2.
Notes:
This was accidentally omitted during the discussion of this document.
Errata ID: 130
Status: Held for Document Update
Type: Editorial
Reported By: Aaron Cohen
Date Reported: 2006-01-05
Held for Document Update by: Pasi Eronen
Page heading says:
RFC 4309 Using AEC CCM Mode with IPsec ESP December 2005
It should say:
RFC 4309 Using AES CCM Mode with IPsec ESP December 2005
Notes:
In RFC 4309 the page headings have a typo AES is misspelled as AEC.
Errata ID: 129
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Rejected by: Russ Housley
Section 5 says:
On page 6, the second paragraph of Section 5 says: Sequence Numbers are conveyed canonical network byte order. Extended Sequence Numbers are conveyed canonical network byte order, placing the high-order 32 bits first and the low-order 32 bits second. Canonical network byte order is fully described in RFC 791, Appendix B. The text should perhaps better say: Sequence Numbers are conveyed in canonical network byte order. Extended Sequence Numbers are conveyed in canonical network byte order, placing the high-order 32 bits first and the low-order 32 bits second. Canonical network byte order is fully described in RFC 791, Appendix B. The second half-sentence of the second sentence might even be considered redundant, fully comprised by the term 'canonical network byte order', and hence be omitted entirely. Doing that, and following the maxim of "making RFC text as simple as possible", the above text might be abreviated to say: Sequence Numbers and Extended Sequence Numbers are conveyed in canonical network byte order. Canonical network byte order is fully described in RFC 791, Appendix B. Finally, considering that the SPI is a 32-bit number and covered by the same ordering rule as well, the text might - even shorter - say: All fields are conveyed in canonical network byte order. Canonical network byte order is fully described in RFC 791, Appendix B. Please decide whether the initial text correction deserves an Errata Note, possibly including the additional enhancement(s).
Notes:
word omissions - and opportunity to simplify the text
NOTE (2006-02-13)
I do not think that any of these will lead to confusion or
interoperability concerns. Thus, I do not think that they warrant
the time and other resources need to generate Errata.
Russ Housley
from pending
Errata ID: 128
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-03
Held for Document Update by: Russ Housley
Report Text:
Informative References need to be updated Rationale: RFC 4312 apparently has been published a bit later than, but closely coordinated with, the new IPsec document suite (RFC 430x). Accordingly, the Normative Reference [ESP] of RFC 4312 points to the new ESP RFC 4303, as expected. But surprisingly, the Informative References are not updated similarly. I would have expected [ARCH] pointing to RFC 4301 (that has obsoleted RFC 2401), and at least an additional Ref. to IKEv2 (RFC 4306, which substantially amends/updates the old RFC 2409 [IKE]) -- with title and text of Section 4 slightly adapted. The current text and Ref. [IKE] even might lead to the mis- conception that the Camellia cipher would not be suitable for use with IKEv2 (a statement certainly not intended by you).
Errata ID: 828
Status: Verified
Type: Technical
Reported By: Arnaud Taddei
Date Reported: 2005-12-31
Section 2.1.1 says:
Example: C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete
It should say:
Example: C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A003 OK Setacl complete
C: A004 getAcl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
S: A004 OK Getacl complete
Notes:
from pending
Errata ID: 127
Status: Verified
Type: Editorial
Reported By: Arnaud Taddei
Date Reported: 2005-12-31
Section 2.1.1 says:
The client has specified the "d" right in the SETACL command above
and it expands to "et" on the server:
C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete
It should say:
The client has specified the "d" right in the SETACL command above
and it expands to "et" on the server:
C: A002 getacl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete
Errata ID: 831
Status: Verified
Type: Editorial
Reported By: Arnaud Taddei
Date Reported: 2005-12-31
Section 3.5 says:
The MYRIGHTS command returns the set of rights that the user has to mailbox in an untagged MYRIGHTS reply.
It should say:
The MYRIGHTS command returns the set of rights that the user has to the mailbox in an untagged MYRIGHTS reply.
Notes:
from pending
Errata ID: 838
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-01-18
after studying the recently published RFC 4319 authored by you
I'd like to report the textual issues I found in that memo.
I use change bars '|' in column 1 and '^^^' / 'vvv' style tags on
extar lines to emphasize the location of the textual issues and/or
the proposed corrections.
If necessary, I also have adjusted the line folding of proposed
text to keep it conformant with RFC formatting rules.
(1)
Apparently, Figure 2 on page 10 has not been adapted from RFC 3276
to remain aligned with the extensions covered by RFC 4319.
To keep the changes minimal, I propose to just amend the Figure
caption, replacing:
Key: <////> HDSL2/SHDSL span
<~~~~> HDSL2/SHDSL segment
=1= HDSL2/SHDSL wire-pair-1
=2= SHDSL optional wire-pair-2 (Not applicable to HDSL2)
C Customer side segment endpoint (modem)
N Network side segment endpoint (modem)
by:
Key: <////> HDSL2/SHDSL span
<~~~~> HDSL2/SHDSL segment
=1= HDSL2/SHDSL wire-pair-1
| =2= SHDSL optional wire-pair-2 (not applicable to HDSL2)
| and SHDSL.bis optional wire-pair-3 and wire-pair-4
| (not applicable to HDSL2 and 'classic' SHDSL)
C Customer side segment endpoint (modem)
N Network side segment endpoint (modem)
(2)
Section 2.7, on page 11, contains a bulleted list with two entries.
It turns out that the second (indented) paragraph of the 2nd bullet
in fact applies to both entries and hence should
- not be indented so much, and
- be adapted for plural grammar.
Thus, the paragraph saying:
vvv vv
The index value for this profile is a locally-unique
administratively-assigned name for the profile having the textual
convention 'SnmpAdminString' (RFC 3411 [RFC3411]).
should be modified to say:
vvv vv
| The index value for these profiles is a locally-unique
| administratively-assigned name for the profile having the textual
| convention 'SnmpAdminString' (RFC 3411 [RFC3411]).
(3)
The REVISION / DESCRIPTION clause pairs in MODULE-IDENTITY macro
invocations preferrably should be formulated in an 'update-friendly'
manner, i.e. such that the text does not need to be modified when
another revision of the MIB module is published in the future.
Therefore, I propose to change the DESCRIPTION clause for the
RFC 4319 revision of the HDSL2-SHDSL-LINE-MIB, at the bottom of
page 15 to follow this requirement.
The text there contains improper wording as well, the correction
of which justifies a combined Erratum entry.
Hence, the lines:
REVISION "200512070000Z" -- December 7, 2005
DESCRIPTION "This version, published as RFC 4319.
The following changes have been made in this version:
1. Added a 3rd and 4th wire pair.
2. Modified all rates such that their rates are only
constrained by an unsigned 32-bit value and not by
what today's perceived technology limitations are.
should be changed to say:
REVISION "200512070000Z" -- December 7, 2005
| DESCRIPTION "Revised version, published as RFC 4319.
The following changes have been made in this version:
1. Added a 3rd and 4th wire pair.
| 2. Modified all rates such that they are only
constrained by an unsigned 32-bit value and not by
what today's perceived technology limitations are.
(3)
On page 16 (lower half), the 2nd paragraph of the DESCRIPTION clause
of the Hdsl2ShdslPerfCurrDayCount TEXTUAL-CONVENTION contains a mis-
spelled syntax name (of another TEXTUAL-CONVENTION).
The sentence,
[ ... ] At that time, the value of the
gauge is stored in the previous 1-day history interval, as
defined in a companion object of type
Hdsl2Shdsl1DayIntevalCount, and the current interval gauge
is restarted at zero.
should say:
[ ... ] At that time, the value of the
gauge is stored in the previous 1-day history interval, as
defined in a companion object of type
| Hdsl2Shdsl1DayIntervalCount, and the current interval gauge
is restarted at zero.
^
(4)
On page 17 (lower half), the DESCRIPTION clause of the
Hdsl2ShdslPerfIntervalThreshold TEXTUAL-CONVENTION suffers from the
lack of a verb in its 2nd sentence.
The paragraph,
"This convention defines a range of values that may be set in
a fault threshold alarm control. As the number of seconds in
a 15-minute interval numbers at most 900, objects of this type
may have a range of 0...900, where the value of 0 disables the
alarm."
should say:
"This convention defines a range of values that may be set in
a fault threshold alarm control. As the number of seconds in
| a 15-minute interval numbers is at most 900, objects of this
type may have a range of 0...900, where the value of 0 disables
the alarm."
(5)
On page 18, there is a word omission in the DESCRIPTION clause of the
Hdsl2ShdslWirePair TEXTUAL-CONVENTION.
The paragraph,
"This is the referenced pair of wires in an HDSL2/SHDSL segment.
HDSL2 only supports a single pair (wirePair1 or two wire),
SHDSL lines support an optional second pair (wirePair2 or four
wire), and G.shdsl.bis support an optional third pair
(wirePair3 or six wire) and an optional fourth pair
(wirePair4 or eight wire)."
should say:
"This is the referenced pair of wires in an HDSL2/SHDSL segment.
HDSL2 only supports a single pair (wirePair1 or two wire),
SHDSL lines support an optional second pair (wirePair2 or four
| wire), and G.shdsl.bis lines support an optional third pair
(wirePair3 or six wire) and an optional fourth pair
(wirePair4 or eight wire)."
(6)
On pages 45..49 it would be very useful to have REFERENCE clauses
added to the OBJECT-TYPE declarations for the technology specific
objects in the Span Configuration Profile Table (similarly to what
has been done for the OBJECT-TYPE declarations for the objects in
the Unit Inventory Group, on pp. 24..27).
(7)
The DESCRIPTION clause of the hdsl2ShdslSpanConfMinLineRate OBJECT-
TYPE declaration contains a reference to a truncated object name.
That clause says:
"This object configures the minimum transmission rate for
the associated SHDSL Line in bits-per-second (bps) and includes
both payload (user data) and any applicable framing overhead.
If the minimum line rate equals the maximum line rate
(hdsl2ShdslSpanMaxLineRate), the line rate is considered
'fixed'. If the minimum line rate is less than the
maximum line rate, the line rate is considered
'rate-adaptive'."
It should say:
"This object configures the minimum transmission rate for
the associated SHDSL Line in bits-per-second (bps) and includes
both payload (user data) and any applicable framing overhead.
If the minimum line rate equals the maximum line rate
| (hdsl2ShdslSpanConfMaxLineRate), the line rate is considered
'fixed'. If the minimum line rate is less than the
maximum line rate, the line rate is considered
'rate-adaptive'."
(8)
The DESCRIPTION clauses of OBJECT-TYPE declarations preferrably
should be 'self-centric', i.e. describe context as seen from
the respective object. Therefore, text replications from one object
to another object without proper adaptation are sub-optimal, at best.
In particular, referencing an object within its DESCRIPTION clause
by name, while omitting to call another object (referenced there)
by its name does not add much to the clarity of the DESCRIPTION.
Therefore, I propose to slightly modify the DESCRIPTION clause of
the hdsl2ShdslSpanConfMaxLineRate OBJECT-TYPE declaration, on top
of page 46. This clause is affected by issue (7) as well.
The clause says:
"This object configures the maximum transmission rate for
the associated SHDSL Line in bits-per-second (bps) and includes
both payload (user data) and any applicable framing overhead.
If the minimum line rate equals the maximum line rate
(hdsl2ShdslSpanMaxLineRate), the line rate is considered
'fixed'. If the minimum line rate is less than the
maximum line rate, the line rate is considered
'rate-adaptive'."
It better should say:
"This object configures the maximum transmission rate for
the associated SHDSL Line in bits-per-second (bps) and includes
both payload (user data) and any applicable framing overhead.
| If the minimum line rate (hdsl2ShdslSpanConfMinLineRate) equals
| the maximum line rate the line rate is considered 'fixed'.
If the minimum line rate is less than the maximum line rate,
the line rate is considered 'rate-adaptive'."
(9)
On pages 47/48, the DESCRIPTION clauses for the four objects:
hdsl2ShdslSpanConfCurrCondTargetMarginDown,
hdsl2ShdslSpanConfWorstCaseTargetMarginDown,
hdsl2ShdslSpanConfCurrCondTargetMarginUp, and
hdsl2ShdslSpanConfWorstCaseTargetMarginUp
contain mainly identical text. This emphasizes the similarities
between these objects but leaves the reader alone as to the use and
differing purpose of the objects. It would be very desirable to
have additional expanatory text added to these four descriptions
to clarify the intended use (e.g., as an alarm limit).
It should say:
[see above]
Notes:
from pending
Errata ID: 796
Status: Verified
Type: Technical
Reported By: Clay Sikes
Date Reported: 2007-01-07
Section 2.5 says:
=2= SHDSL optional wire-pair-2 (Not applicable to HDSL2)
It should say:
=2= SHDSL optional wire-pair-2 (Not applicable to HDSL2)
and SHDSL.bis optional wire-pair-3 and wire-pair-4
(not applicable to HDSL2 and 'classic' SHDSL)
Notes:
from pending
Errata ID: 813
Status: Verified
Type: Technical
Reported By: Clay Sikes
Date Reported: 2007-01-07
Section 3 says:
[[Page 45, hdsl2ShdslSpanConfMinLineRate, description]]
If the minimum line rate equals the maximum line rate
(hdsl2ShdslSpanMaxLineRate), the line rate is considered
'fixed'.
It should say:
If the minimum line rate equals the maximum line rate
(hdsl2ShdslSpanConfMaxLineRate), the line rate is considered
'fixed'.
Notes:
from pending
Errata ID: 815
Status: Verified
Type: Technical
Reported By: Clay Sikes
Date Reported: 2007-01-07
Section 3 says:
[[Page 46, hdsl2ShdslSpanConfMaxLineRate, description]]
If the minimum line rate equals the maximum line rate
(hdsl2ShdslSpanMaxLineRate), the line rate is considered
'fixed'.
It should say:
If the minimum line rate (hdsl2ShdslSpanConfMinLineRate) equals
the maximum line rate, the line rate is considered
'fixed'.
Notes:
from pending
Errata ID: 2633
Status: Held for Document Update
Type: Technical
Reported By: Stefan Reichmuth
Date Reported: 2010-11-16
Held for Document Update by: Dan Romascanu
Section 3 says:
hdsl2ShdslEndpointCurrAtn OBJECT-TYPE
SYNTAX Integer32(-127..128)
[...]
hdsl2ShdslEndpointCurrSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128)
It should say:
hdsl2ShdslEndpointCurrAtn OBJECT-TYPE
SYNTAX Integer32(-128..127)
[...]
hdsl2ShdslEndpointCurrSnrMgn OBJECT-TYPE
SYNTAX Integer32(-128..127)
Notes:
The data type for SNR margin and loop attenuation defined in ITU-T G.991.2 section 9.5.5.7.14 is signed char (-128..127). In particular for the attenuation value it is important that -128 is part of the allowed range, because this means 'not available'.
Errata ID: 797
Status: Verified
Type: Editorial
Reported By: Clay Sikes
Date Reported: 2007-01-07
Section 2.7 says:
SHDSL segment endpoints. These profiles are defined in the hdsl2ShdslEndpointAlarmConfProfileTable. The index value for this profile is a locally-unique ...
It should say:
SHDSL segment endpoints. These profiles are defined in the hdsl2ShdslEndpointAlarmConfProfileTable. The index value for these profiles is a locally-unique ...
Notes:
from pending
Errata ID: 801
Status: Verified
Type: Editorial
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01
Section 3 says:
2. Modified all rates such that their rates are only
It should say:
2. Modified all rates such that they are only
Notes:
from pending
Errata ID: 807
Status: Verified
Type: Editorial
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01
Section 3 says:
[[Page 16, Hdsl2ShdslPerfCurrDayCount, second paragraph in the description]]
Hdsl2Shdsl1DayIntevalCount, and the current interval gauge
It should say:
Hdsl2Shdsl1DayIntervalCount, and the current interval gauge
Notes:
from pending
Errata ID: 808
Status: Verified
Type: Editorial
Reported By: Clay Sikes
Date Reported: 2007-01-07
Verifier Name: RFC Editor
Date Verified: 2007-11-01
Section 3 says:
[[Page 17, Hdsl2ShdslPerfIntervalThreshold , description]]
a 15-minute interval numbers at most 900, objects of this
It should say:
a 15-minute interval numbers is at most 900, objects of this
Notes:
from pending
Errata ID: 812
Status: Verified
Type: Editorial
Reported By: Clay Sikes
Date Reported: 2007-01-07
Section 3 says:
[[Page 18, Hdsl2ShdslWirePair , description]]
wire), and G.shdsl.bis support an optional third pair
It should say:
wire), and G.shdsl.bis lines support an optional third pair
Notes:
from pending
Errata ID: 2455
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 9.3 says:
The first senrtence of Section 9.3, on page 34, says: Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break. [...] The 'line break' might occor at any place within the network, not just at the 'remote end'. Therefore, the text should better say: Tunnels sometimes go down because the remote end crashes, | disconnects, or a network link break occurs. [...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2456
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 11.2 says:
Within the details of step 5, the text on page 38, lacks of a
sub-step label.
The text,
(5J) DNS replies with public key of initiator.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
[...]
should say:
(5J) DNS replies with public key of initiator.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
| (5K) Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
[...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2458
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 12.3 says:
The second paragraph of Section 12.3 (on page 41) says:
The design of ISAKMP/IKE, and its use of cookies, defend against many
kinds of denial of service. [...]
It should say:
v
| The design of ISAKMP/IKE, and its use of cookies, defends against
many kinds of denial of service. [...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2451
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 1.2 says:
The last paragraph of that section, on page 4, says:
[...]. The
mechanism described here, however, does provides an additional way to
distribute the authentication materials; it is a public key method
that does not require deployment of an X.509 based infrastructure.
It should say:
vvv
[...]. The
| mechanism described here, however, does provide an additional way to
distribute the authentication materials; it is a public key method
that does not require deployment of an X.509 based infrastructure.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2457
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 11.2 says:
The final paragraph of Section 11.2, on page 39, says:
SG-A sends the datagram saved at step (5) through the newly
created tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8). SG-B already has a
| tunnel up with G1 and uses it. [...]
^^
"G1" is undefined; apparently, it should be "SG-A".
Hence, this snippit should say:
SG-A sends the datagram saved at step (5) through the newly
created tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8). SG-B already has a
| tunnel up with SG-A and uses it. [...]
^^^^
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2454
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 4.5 says:
The first paragraph of Section 4.5, on page 25, says: The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, nor uses the NSEC records to provide authentication of the absence of a TXT or KEY record. [...] It should say: The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, | nor does it use the NSEC records to provide authentication of the absence of a TXT or KEY record. [...] (or similar).
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2452
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 3.2.5 says:
Section 3.2.5
a) The second paragraph of Section 3.2.5, on page 16,
Exit from this state occurs with either a successfully created IPsec
SA or a failure of some kind. Successful SA creation results in a
transition to the key connection state.
should correctly name the state (cf. the Figure in Section 3.2, and
Section 3.2.6) by saying:
Exit from this state occurs with either a successfully created IPsec
SA or a failure of some kind. Successful SA creation results in a
| transition to the keyed connection state.
^^
b) The second paragraph on page 17 contains the sentence:
[...]. For an OE-
pessimistic connection, the initiator makes a transition to the deny
connection again with a low lifespan. [...]
Conformant to the terminology used in the remainder of the text
(cf. the definition in the 3rd paragraph of Section 3.2, on page 12),
it should say:
vvvvvvvv
| [...]. For an OE-paranoid
connection, the initiator makes a transition to the deny connection
again with a low lifespan. [...]
c) The final paragraph of the section, still on page 17, says:
The third failure occurs when there is signature failure while
authenticating the remote gateway. This can occur when there has
been a key roll-over, but DNS has not caught up. In this case again,
the initiator makes a transition to the clear-text or the deny
connection based upon the connection class. However, the lifespan
depends upon the remaining time to live in the DNS. [...]
It should say:
vvv
| The third failure occurs when there is a signature failure while
authenticating the remote gateway. This can occur when there has
been a key roll-over, but DNS has not caught up. In this case again,
the initiator makes a transition to the clear-text or the deny
| connection state based upon the connection class. However, the
lifespan depends upon the remaining time to live in the DNS. [...]
^^^^^^^
Rationale for the second change:
Transitions occur between *states* in the FSM. 'clear-text' and
'deny connection' are names given to two of these FSM states.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2450
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 1.2 says:
The 2nd paragraph on page 3 says:
[...]. A future document [IPSECKEY] will describe
a variation that complies with RFC 3445. [...]
The reference [IPSECKEY] has been updated before publication of
RFC 4322 to point to RFC 4025 (cf. the first entry in Section 14.2,
on page 42). Hence this wording in not appropriate and inconsistent.
The text should say:
vvvvvvvv vvv v
| [...]. Another document [IPSECKEY] describes
a variation that complies with RFC 3445. [...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2453
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 3.2.7 says:
The second paragraph of that section refers to [RFC1034]: The DNS query and answer that lead to the expiring connection state are also examined. The DNS query may become stale. (A negative, i.e., no such record, answer is valid for the period of time given by the MINIMUM field in an attached SOA record. See [RFC1034] section 4.3.4.) [...] This reference is not very appropriate, and hence misleading. RFC 1034, and in particular section 4.3.4 of RFC 1034, has been substantially clarified and updated by RFC 2308. The Abstract of RFC 2308 says: "This document ... replaces [RFC1034 Section 4.3.4]." (The precise rule for determining the 'negative caching TTL' is a bit more complicated, taking the minimum of SOA.MINIMUM and SOA.TTL.) Therefore, RFC 4322 should better refer to RFC 2308, in this place, perhaps with a detailed hint pointing to section 5 of RFC 2308.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 125
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Rejected by: Sean Turner
Date Rejected: 2010-08-06
Section General says:
It's a pity that RFC 4322, published a few days *after* the new IPsec RFCs including the IKEv2 specification (RFC 4306), does not give a perspective on Opportunistic Encryption in the context of IKEv2.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
--VERIFIER NOTES--
No action proposed.
Errata ID: 124
Status: Verified
Type: Technical
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02
Section 7.2 says:
When in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and
It should say:
When in the Reassembly State, the Receiver reads the first two bytes from the TS Packet payload. This value forms the first 2 bytes of the SNDU base header, which is a combination of the D-bit and the SNDU-Length. If the combined value is less than or equal to 4, or equal to 0xFFFF (i.e. D=1 and SNDU Length = 32768), the Receiver MUST discard the Current SNDU and
Notes:
- Usage of last byte in a TS-Packet.
Source: Bernhard Collini-Nocker & Gorry Fairhurst, 15th February 2006
Errata ID: 726
Status: Verified
Type: Technical
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02
Section 4.1 says:
The most significant bit of the Length field carries the value of the Destination Address Absent Field, the D-bit
It should say:
The most significant bit of the first byte of the SNDU base header carries the value of the Destination Address Absent Field, the D-bit
Notes:
- Length field description refers to a 16-bit value.
Source: Bernhard Collini-Nocker, 15th February 2006
Errata ID: 727
Status: Verified
Type: Technical
Reported By: Gorry Fairhurst
Date Reported: 2006-08-02
In Example A.2, it says:
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
It should say:
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0xB5 |
Notes:
- Misrepresentation of hex byte in example, Change /0x65/0xB5/
Source: Karsten Siebert, 26th February 2006
Note: This RFC has been obsoleted by RFC4631
Source of RFC: ccamp (rtg)Errata ID: 123
Status: Verified
Type: Technical
Reported By: Adrian Farrel
Date Reported: 2006-01-18
Report Text:
RFC 4327 makes use of the TruthValue textual convention defined in RFC
2579.
Several places in the text identify the enumerations of the textual
convention ("true" and "false") using their names and their numeric values
(1 and 2 respectively).
However, several references to the enumerations of the textual convention
use the incorrect numeric values.
All references to the enumerations of this textual convention in this RFC
should take the names ("true" and "false") as the definitive settings, and
should disregard the numeric values when stated incorrectly.
Errata ID: 705
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30
(1) [plaintext flaw]
In the final paragraph of Section 7, on page 8, RFC 4327 says:
In parallel with the entry created in the lmpTeLinkTable, an entry
may be created in the teLinkTable of TE Link MIB module
[RFC4220].
It should better say:
In parallel with the entry created in the lmpTeLinkTable, an entry
| may be created in the teLinkTable of the TE Link MIB module
[RFC4220].
^^^^^
(2) [plaintext flaw]
In the second paragraph of Section 8, at the bottom of page 8,
RFC 4327 says:
[...]. The interrelation of entries in the
ifTable is defined by Interfaces Stack Group defined in [RFC2863].
It should say:
[...]. The interrelation of entries in the
| ifTable is defined by the Interfaces Stack Group defined in
[RFC2863].
^^^^^
(3) LmpInterval TEXTUAL-CONVENTION (page 12)
The clause,
DESCRIPTION
"The interval delay in milliseconds."
perhaps should better say:
DESCRIPTION
| "The delay interval in milliseconds."
or even:
DESCRIPTION
| "The interval period for a periodically performed LMP operation,
| in milliseconds."
(4) LmpRetransmitInterval TEXTUAL-CONVENTION (page 12)
The clause,
DESCRIPTION
"The retransmission interval delay in milliseconds."
perhaps should better say:
DESCRIPTION
| "The retransmission delay interval in milliseconds."
or even better:
DESCRIPTION
| "The (initial) retransmission interval in milliseconds."
(5) lmpNbrRetransmitInterval OBJECT-TYPE (page 14)
The sentence in the DESCRIPTION clause,
"[...] This object ... is used to implement congestion-handling
mechanism as defined in Section 10 of the Link Management Protocol
specification, which is based on RFC 2914."
should perhaps better say:
vvvvv
| "[...] This object ... is used to implement the congestion-handling
mechanism as defined in Section 10 of the Link Management Protocol
specification, which is based on RFC 2914."
(6) lmpNbrRetryLimit OBJECT-TYPE (page 14)
The correction from item (5) above should be applied here as well.
(7) lmpCcRemoteAddressType OBJECT-TYPE (page 20)
DESCRIPTION
"This value represents the remote control channel IP address
type. In point-to-point configuration, this value can be set
to unknown(0)."
::= { lmpControlChannelEntry 6 }
should better say:
DESCRIPTION
"This value represents the remote control channel IP address
| type. In point-to-point configurations, this value can be set
to unknown(0)."
::= { lmpControlChannelEntry 6 }
^
[ The possible alternative, "In a point-to-point configuration, ..."
is not proposed here, to maintain a style similar to the minimal
change for the next object -- see (8) below.]
(8) lmpCcRemoteIpAddr OBJECT-TYPE (page 20)
DESCRIPTION
"[...]
Control channel must be numbered on non-point-to-point
configuration. For point-to-point configuration, the
remote control channel address can be of type unknown
in which case this object must be a zero-length string. The
lmpCcRemoteId object then identifies the unnumbered
address."
::= { lmpControlChannelEntry 7 }
should better say:
DESCRIPTION
"[...]
| The control channel must be numbered on non-point-to-point
| configurations. For point-to-point configurations, the
remote control channel address can be of type unknown
in which case this object must be a zero-length string. The
lmpCcRemoteId object then identifies the unnumbered
address."
::= { lmpControlChannelEntry 7 }
(11) lmpControlChannelPerfEntry OBJECT-TYPE (page 24)
DESCRIPTION
"An entry in this table is created by a LMP-enabled device for
every control channel. lmpCcCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
in this table."
The latter is not true.
In this MIB module, the discontinuity is monitored per table *entry*
(conceptual row), not for the table as a whole -- see the DESCRIPTIONs
for lmp<*>DiscontinuityTime later in the RFC.
Therefore, the above clause should say:
DESCRIPTION
"An entry in this table is created by a LMP-enabled device for
every control channel. lmpCcCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
| in this entry (conceptual row)."
(12) lmpCcChannelStatusAckSent OBJECT-TYPE (page 34)
The clause,
DESCRIPTION
"This object counts the number of ChannelStatus messages
that have been sent on this control channel."
::= { lmpControlChannelPerfEntry 47 }
refers to the wrong message type; it should say:
DESCRIPTION
| "This object counts the number of ChannelStatusAck messages
that have been sent on this control channel."
::= { lmpControlChannelPerfEntry 47 }
(14) lmpTeLinkPerfEntry OBJECT-TYPE (page 42)
The correction from item (11) above is to be applied here as well:
Replace:
DESCRIPTION
"An entry in this table is created by an LMP-enabled device for
every TE link. lmpTeCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
in this table."
by:
DESCRIPTION
"An entry in this table is created by an LMP-enabled device for
every TE link. lmpTeCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
| in this entry (conceptual row)."
(15) lmpTeEndVerifyRetransmit OBJECT-TYPE (page 45/46)
DESCRIPTION
"This object counts the number of EndVerify messages that
have been retransmitted over this control channel."
::= { lmpTeLinkPerfEntry 12 }
is inappropriate. In accordance with the text supplied for the
other objects in the LMP TE Link Performance Table, it should say:
DESCRIPTION
"This object counts the number of EndVerify messages that
| have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 12 }
(16) lmpTeTestStatusFailureRetransmit OBJECT-TYPE (page 47)
DESCRIPTION
"This object counts the number of TestStatusFailure messages
that have been retransmitted on this TE link."
::= { lmpTeLinkPerfEntry 20 }
should say:
DESCRIPTION
"This object counts the number of TestStatusFailure messages
that have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 20 }
[ According to Section 12.5.8. of the LMP specification [RFC 4204],
LMP TestStatusFailure messages are transmitted over the control
channel; hence, "retransmitted *on* this TE Link" is wrong! ]
(17) lmpTeLinkSummaryRetransmit OBJECT-TYPE (page 48)
The correction from item (15) above is to be applied here as well:
Replace:
DESCRIPTION
"This object counts the number of LinkSummary messages that
have been retransmitted over this control channel."
::= { lmpTeLinkPerfEntry 25 }
by:
DESCRIPTION
"This object counts the number of LinkSummary messages that
| have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 25 }
(18) lmpTeChannelStatusAckSent OBJECT-TYPE (page 50)
The correction from item (12) above is to be applied here as well:
Replace:
DESCRIPTION
"This object counts the number of ChannelStatus messages
that have been sent for this TE link."
::= { lmpTeLinkPerfEntry 34 }
by:
DESCRIPTION
| "This object counts the number of ChannelStatusAck messages
that have been sent for this TE link."
::= { lmpTeLinkPerfEntry 34 }
(20) lmpDataLinkPerfEntry OBJECT-TYPE (page 55)
The correction from item (11) above is to be applied here as well:
Replace:
DESCRIPTION
"An entry in this table contains information about
the LMP performance counters for the data-bearing links.
lmpDataLinkDiscontinuityTime is used to indicate potential
discontinuity for all counter objects in this table."
by:
DESCRIPTION
"An entry in this table contains information about
the LMP performance counters for the data-bearing links.
lmpDataLinkDiscontinuityTime is used to indicate potential
| discontinuity for all counter objects in this entry."
(21) lmpNotificationMaxRate OBJECT-TYPE (page 57/58)
The DESCRIPTION text near the top of page 58 says:
[...]. For instance, a network of 100 nodes
with 5 links of 128 wavelengths each and a link verification
of 1 minute with no more than 10% of the links failed at any
given time would have 1 notification per second sent from
each node, or 100 notifications per second for the whole
network. The rest of the notifications are negligible
compared to this number.
To alleviate the congestion problem, the
lmpNotificationMaxRate object can be used to implement a
throttling mechanism. It is also possible to enable/disable
certain type of notifications.
It should say, correcting two flaws (line breaks adjusted):
[...]. For instance, a network of 100 nodes
with 5 links of 128 wavelengths each and a link verification
| interval of 1 minute with no more than 10% of the links failed
at any given time would have 1 notification per second sent
from each node, or 100 notifications per second for the whole
network. The rest of the notifications are negligible
compared to this number.
To alleviate the congestion problem, the
lmpNotificationMaxRate object can be used to implement a
throttling mechanism. It is also possible to enable/disable
| certain types of notifications.
(23) lmpControlChannelGroup OBJECT-GROUP (page 72)
At the bottom of page 72, the RFC says:
DESCRIPTION
"Objects that can be used to configure LMP interface."
It should say:
DESCRIPTION
| "Objects that can be used to configure LMP interfaces."
It should say:
[see above]
Notes:
Verifier's analysis:
1. Yes. Editorial nit.
2. Yes. Editorial nit.
3. Yes. Editorial nit.
4. Yes. Editorial nit.
5. Yes. Editorial nit.
6. Yes. Editorial nit.
7. Yes. Editorial nit.
8. Yes. Editorial nit.
11. Yes. Editorial change of substance.
12. Yes. Editorial change of substance.
14. Yes. Editorial change of substance.
15. Yes. Editorial change of substance.
16. Yes. Editorial change of substance.
17. Yes. Editorial change of substance.
18. Yes. Editorial change of substance.
20. Yes. Editorial change of substance.
21. Yes. Editorial nit.
23. Yes. Editorial nit.
Rejected items have been moved to Errata ID 1938.
Errata ID: 1938
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Rejected by: Adrian Farrel
Date Rejected: 2009-10-30
(9) lmpCcHelloInterval OBJECT-TYPE (page 21)
An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
Hence,
DESCRIPTION
"This object specifies the value of the HelloInterval
parameter. The default value for this object should be
set to lmpCcHelloIntervalDefault."
::= { lmpControlChannelEntry 10 }
should better say:
DESCRIPTION
"This object specifies the value of the HelloInterval
| parameter. The default value to be used for this object
| is lmpCcHelloIntervalDefault."
::= { lmpControlChannelEntry 10 }
(9') lmpCcHelloIntervalMin OBJECT-TYPE (page 21) ,
(9'') lmpCcHelloIntervalMax OBJECT-TYPE (page 21/22) ,
(10) lmpCcHelloDeadInterval OBJECT-TYPE (page 22) ,
(10') lmpCcHelloDeadIntervalMin OBJECT-TYPE (page 22) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE (page 22)
The change from item (9) above should be applied there similarly:
Replace the phrase,
"[...]. The default value for this object should be
set to lmp<*>Default."
by:
| "[...]. The default value to be used for this object
| is lmp<*>Default."
using, at all instances, the appropriate value for the placeholder <*>.
(13) lmpTeLinkEntry OBJECT-TYPE (page 36)
The DESCRIPTION clause contains the sentence:
[...]. The
administrative status value is controlled from the ifEntry.
[...]
This sentence should say:
[...]. The
| administrative status is controlled from the ifEntry.
[...]
(19) lmpDataLinkEntry OBJECT-TYPE (page 51)
The correction from item (13) above is to be applied here as well:
The sentence in the DESCRIPTION clause,
[...]. The administrative status value is
controlled from the ifEntry. [...]
should say:
| [...]. The administrative value is
controlled from the ifEntry. [...]
(22) lmpNodeGroup OBJECT-GROUP (page 71/72)
Near the top of page 72, the RFC says:
DESCRIPTION
"Collection of objects that represent LMP node
configuration."
::= { lmpGroups 1 }
It should say:
DESCRIPTION
| "Collection of objects that represents the LMP node
configuration."
::= { lmpGroups 1 }
[ In fact, it is *the collection* (singular) that represents
the node configuration! ]
(24) lmpDataLinkGroup OBJECT-GROUP (page 76)
Similar to item (22) above, the clause,
DESCRIPTION
"Collection of objects that represent data-bearing link
configuration."
::= { lmpGroups 9 }
should better say:
DESCRIPTION
"Collection of objects that represents data-bearing link
configurations."
::= { lmpGroups 9 }
It should say:
[see above]
Notes:
Verifier's analysis:
9. No. Editorial change of no substance.
9' No. Editorial change of no substance.
9" No. Editorial change of no substance.
10. No. Editorial change of no substance.
10' No. Editorial change of no substance.
10" No. Editorial change of no substance.
13. No. The value is controlled, not the status.
19. No. The value is controlled, not the status.
22. No. The English is correct.
24. No. The English is correct.
Verified items are in Errata ID 705.
Note: This RFC has been obsoleted by RFC5905
Source of RFC: INDEPENDENT
Errata ID: 2263
Status: Reported
Type: Technical
Reported By: Scott Barnes
Date Reported: 2010-05-15
Section 5 says:
The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields is 0 or the Mode field is not 4 (unicast) or 5 (broadcast).
It should say:
The server reply should be discarded if any of the VN, Stratum, or Transmit Timestamp fields is 0 or the Mode field is not 4 (unicast) or 5 (broadcast).
Notes:
Zero is a legal value for the LI field under normal conditions. Zero is not legal for VN field, however.
Errata ID: 2480
Status: Reported
Type: Technical
Reported By: Dave Higton
Date Reported: 2010-08-20
Section 4 says:
MSF Rugby (UK) Radio 60 kHz
It should say:
MSF Anthorn (UK) Radio 60 kHz
Notes:
The MSF transmitter was relocated from Rugby to Anthorn, in Cumbria, on 2007 March 31. See http://www.npl.co.uk/science-+-technology/time-and-frequency/npl-ensures-accurate-uk-time-for-the-next-15-years
Errata ID: 122
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-03
(1)
In the 3rd paragraph of section 1, on page 2 RFC 4334 says:
For example, the same wireless station might use IEEE 802.1X to
authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11
"hotspot." [...]
^^
The syntax error of that sentence should be corrected to say:
For example, the same wireless station might use IEEE 802.1X to
authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11
| "hotspot". [...]
^^
(2)
At the end of the 2nd paragraph of section 5, on page 6, the RFC says:
[...]. Whenever this SSID disclosure is a
concern, different peer certificates ought to be used for the each
WLAN.
^^^^^^^^^^^^
It should say:
[...]. Whenever this SSID disclosure is a
| concern, different peer certificates ought to be used for each WLAN.
(3)
In Section 7.1, on page 7, the Normative Reference,
vvv
[EAP] Aboba, B., Blunk, L., Vollbrechtand, J., Carlson, J.,
and H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
should say:
| [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
| H. Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
and on page 8, the Normative Reference,
v
[X.690] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
should say:
v
| [X.690] ITU-T Recommendation X.690 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
Notes:
* The minor item (1) is included for completeness.
* Items (1) and (2) are inherited from RFC 3770.
from pending
Errata ID: 1309
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-02-05
Held for Document Update by: Pasi Eronen
Section 3, 1st para says:
The following channel-specific request can be sent over a session channel (as described in [4]) to request that the remote host perform a BREAK operation.
It should say:
The following channel-specific request can be sent over a session | channel (as described in [5]) to request that the remote host perform a BREAK operation.
Notes:
The relevant information is in RFC 4254 [5], "SSH Connection Protocol",
in particular sections 5 and 6.
RFC 4253 [4] does not even mention the concept of session channels
to any notable detail.
Errata ID: 1310
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-02-05
Held for Document Update by: Pasi Eronen
Section 3, last para says:
If the 'want_reply' boolean is set, the server MUST reply using an SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be sent.
It should say:
If the 'want_reply' boolean is set, the server MUST reply using an SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a | BREAK of any kind was performed, SSH_MSG_CHANNEL_SUCCESS MUST be | sent. If no BREAK was performed, SSH_MSG_CHANNEL_FAILURE MUST be sent.
Notes:
s/preformed/performed/g
Errata ID: 121
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-19
Held for Document Update by: Robert Sparks
Section 5 says:
Security considerations: See section 5 of RFC 4337.
It should say:
Security considerations: See section 4 of RFC 4337.
Notes:
The Security Considerations *are* in Section 4 of RFC 4337.
Note: This must have been a last-minute "fix", the draft was o.k.
I recommend to have the IANA update the registrations accordingly.
Errata ID: 120
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
Held for Document Update by: Ron Bonica
Section 5.3.3 says:
4. It is sub-optimal to utilize the radio resources in 3GPP networks
for DHCPv6 messages if there is a simpler alternative is
available.
It should say:
4. It is sub-optimal to utilize the radio resources in 3GPP networks
for DHCPv6 messages if there is a simpler alternative available.
Notes:
from pending
Errata ID: 974
Status: Verified
Type: Technical
Reported By: Eddie Kohler
Date Reported: 2006-07-11
Section 6.6.4 says:
[text below should be added to the end of the section]
It should say:
FGSR and FGSS values always satisfy FGSR <= GSR and FGSS <= GSS,
where GSR and GSS are the Greatest Sequence Numbers Received by and
Sent from this endpoint. These constraints MUST be enforced even
when GSR and GSS wrap, as they might in a long connection.
Implementations SHOULD thus check FGSR and FGSS after every packet
received or sent, as follows. (Wmax is the maximum allowed value for
the Sequence Window feature; see Section 7.5.2.)
If FGSR > GSR, then FGSR := GSR - Wmax.
If FGSS > GSS, then FGSS := GSS - Wmax.
Alternate implementations that correctly handle sequence number
wrapping are also acceptable.
Notes:
One technical omission has been found concerning the FGSR and FGSS
variables used to detect reordering of feature negotiation options. We
suggest adding the above paragraph to the end of Section 6.6.4, on Page
42.
via Alfred Hoenes
from pending
Errata ID: 1049
Status: Verified
Type: Technical
Reported By: Sally Floyd
Date Reported: 2007-09-01
Section 6.6.8 says:
The Ack
Ratio feature takes two-byte, non-zero integer values, so a
"Change L(Ack Ratio, 0)" option is never valid.
It should say:
The Sequence Window feature takes six-byte, non-zero integer
values, with a minimum valid value of 32, so a "Change
L(Sequence Window, 0)" option is never valid.
Notes:
reported by Gerrit Renker
Errata ID: 980
Status: Verified
Type: Editorial
Reported By: Eddie Kohler
Date Reported: 2006-07-11
In Section 6.6.4, Page 41, it says:
(Change and/or Confirm). This value is initialized to
ISR - 1.
It should say:
(Change and/or Confirm). This value is initialized to
ISR - 1, where ISR is the Initial Sequence Number Received
from the other endpoint. (ISR and other sequence number
variables are defined in Section 7.1.)
In Section 6.6.4, Page 41, it says:
reordering. FGSS is initialized to ISS.
It should say:
reordering. FGSS is initialized to ISS, the Initial
Sequence Number Sent by this endpoint.
In Section 7.5.2, Page 49, it says:
getting out sync after bursts of loss,
It should say:
getting out of sync after bursts of loss,
In Section 8.1.2, Page 60, it says:
intepreting the four-character result as a 32-bit big-endian
It should say:
interpreting the four-character result as a 32-bit big-endian
In Appendix A, Page 116, it says:
right to left. The implementation maintains five variables, aside
It should say:
right to left. The implementation maintains four variables, aside
And it says:
acknowledged in the buffer. This corresponds to the "head"
It should say:
acknowledged in the buffer. This corresponds to the "buf_head"
On Page 117, it says:
Ack Vector, it remembers four variables:
It should say:
Ack Vector, it remembers five variables:
In Section A.3, Page 121, it says:
HC-Sender packet 3, so the HC-Sender has now received HC-Receiver's
It should say:
HC-Sender packet 3, so the HC-Sender has now received the HC-Receiver's
In Section A.4, Page 122, it says:
a single acknowledgement number tells HC-Receiver how much ack
It should say:
a single acknowledgement number tells the HC-Receiver how much ack
Notes:
via Alfred Hoenes
from pending
Errata ID: 829
Status: Verified
Type: Technical
Reported By: Eddie Kohler
Date Reported: 2007-02-07
Section 5 says:
Translating this to the packet-based congestion control of CCID 3, the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT.
It should say:
Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT. This might be implemented, for example, by setting the initial sending rate to min(4*s, max(2*s, 4380 bytes)), where "s" as usual is the packet size in bytes.
Notes:
Clarification of initial sending rates.
Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan
from pending
Errata ID: 830
Status: Verified
Type: Technical
Reported By: Eddie Kohler
Date Reported: 2007-02-07
Section 5 says:
The sender's measurement of the round-trip time uses the Elapsed Time and/or Timestamp Echo option contained in feedback packets, as described in Section 8.2. The Elapsed Time option is required, while the Timestamp Echo option is not. The sender maintains an average round-trip time heavily weighted on the most recent measurements.
It should say:
The sender's measurement of the round-trip time uses DCCP's mechanisms for round-trip time measurement. This includes Elapsed Time and/or Timestamp Echo options. As described in Section 8.2, feedback packets must carry an Elapsed Time option; Timestamp Echo is optional. The sender maintains an average round-trip time heavily weighted on the most recent measurements. Senders MAY use any available round-trip time measurements, including from the initial Request-Response packet exchange, to maintain this average. This differs from [RFC 3448], which constrains round-trip time measurements to feedback packets only.
Notes:
Clarification of round-trip time measurement.
Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan
from pending
Errata ID: 610
Status: Verified
Type: Technical
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 6 says:
2. A Receive Rate option, defined in Section 8.3, specifying the
rate at which data was received since the last DCCP-Ack was
sent.
It should say:
2. A Receive Rate option, defined in Section 8.3, specifying the
rate at which data was received over the last round-trip time.
Notes:
Section 8.3 of RFC 4342 (DCCP CCID 3) specifies that the Receive
Rate option reports the receive rate since the last feedback packet
was sent. In contrast, Section 6.2 of RFC 3448 (TFRC) specifies
that the feedback packet reports the receive rate over the last
round-trip time. As a result, the receive rate specified by
RFC 4342 differs from that of TFRC for a feedback packet after an
idle period; the receive rate report specified in RFC 4342 reports
the receive rate over the entire idle period. The receive rate
reported by RFC 4342 also differs from that of TFRC for an early
feedback packet reporting a new loss event. This errata updates
RFC 4342 to use the definition of the receive rate as specified in
RFC 3448.
Errata ID: 611
Status: Verified
Type: Technical
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 8.3 says:
Its four data bytes indicate the rate at which
the receiver has received data since it last sent an
acknowledgement, in bytes per second. To calculate this receive
rate, the receiver sets t to the larger of the estimated round-
trip time and the time since the last Receive Rate option was
sent.
It should say:
Its four data bytes indicate the rate at which
the receiver has received data over the last round-trip time,
in bytes per second. To calculate the time interval t for
calculating this receive rate, the receiver follows Section
6.2 of [RFC3448].
Notes:
This errata updates RFC 4342 to use the definition of the receive rate
as specified in RFC 3448.
Errata ID: 612
Status: Verified
Type: Technical
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 8.3 says:
It should say:
Assume that the sender receives two feedback packets with
Acknowledgement Numbers A1 and A2, respectively. Further assume
that the sender sent no data packets in between Sequence Numbers
A1+1 and A2, inclusive. (All those packets must have been pure
acknowledgements, Sync and SyncAck packets, and so forth.) Then
the sender MAY, at its discretion, ignore the second feedback
packet's Receive Rate option. Note that when the sender decides
to ignore such an option, it MUST NOT reset the nofeedback timer
as it normally would; the nofeedback timer will expire as if the
second feedback packet had not been received.
Notes:
This is a new paragraph to be added to the end of Section 8.3.
It specifies that if the interval covered by a feedback packet doesn't include
any data packets, then the sender doesn't have to use the reported receive rate.
Errata ID: 119
Status: Reported
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2006-02-26
Section 1 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 [RFC2119].
It should say:
The key words "MUST" and "MAY" in this document are to be interpreted as described in [RFC2119].
Notes:
Other than in the above-quoted sentence, there are no
instances of "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD",
"SHOULD NOT", "RECOMMENDED", or "OPTIONAL" in the RFC (and the
instances above surely cannot be interpreted as described in RFC
2119; they are mere labels in the context of that sentence).
Errata ID: 2647
Status: Reported
Type: Editorial
Reported By: Sam Bretheim
Date Reported: 2010-11-29
Section 2.1 says:
("."), which can be expressed as and \046 or \. It is advisable to
It should say:
("."), which can be expressed as \046 or \. It is advisable to
Errata ID: 118
Status: Held for Document Update
Type: Editorial
Reported By: Ben Harris
Date Reported: 2006-02-07
Held for Document Update by: Sean Turner
Section 7.2 says:
[MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances
in Cryptology -- CRYPTO 2002: 22nd Annual International
Cryptology Conference, August 2002,
<http://eprint.iacr.org/2002/067.pdf>.
It should say:
[MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances
in Cryptology -- CRYPTO 2002: 22nd Annual International
Cryptology Conference, August 2002, full version at
<http://crypto.stanford.edu/~mironov/papers/rc4full.pdf>
Note: This RFC has been obsoleted by RFC5246
Source of RFC: tls (sec)
Errata ID: 1075
Status: Verified
Type: Technical
Reported By: Eric Rescorla
Date Reported: 2006-02-26
Section 4.7 says:
PKCS #1 block type 0 or type 1, as described in [PKCS1A].
It should say:
PKCS #1 block type 1, as described in [PKCS1A].
Errata ID: 1896
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Verifier Name: Pasi Eronen
Date Verified: 2009-10-14
Section 7.2.2 says:
decryption_failed
This alert MAY be returned if a TLSCiphertext decrypted in an
invalid way: either it wasn't an even multiple of the block
length, or its padding values, when checked, weren't correct.
This message is always fatal.
Note: Differentiating between bad_record_mac and decryption_failed
alerts may permit certain attacks against CBC mode as used in
TLS [CBCATT]. It is preferable to uniformly use the
bad_record_mac alert to hide the specific type of the error.
It should say:
decryption_failed
This alert was used in TLS version 1.0, and MUST NOT be sent in
TLS 1.1.
Note: Differentiating between bad_record_mac and decryption_failed
alerts may have permitted certain attacks against CBC mode
as used in TLS 1.0 [CBCATT]. It is preferable to uniformly
use the bad_record_mac alert to hide the specific type of
the error.
Notes:
(split off from Errata ID 117 )
The original text contradicted the text for bad_record_mac
("This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way").
Errata ID: 116
Status: Held for Document Update
Type: Editorial
Reported By: David Hopwood
Date Reported: 2006-05-11
Held for Document Update by: Pasi Eronen
Report Text:
Following references should all be to Section 12: Section 6: # See Section 11 for IANA Considerations for ContentType values. Section 7.2.2: # See Section 11 for IANA Considerations for alert values. Section 7.4: # See Section 11 for IANA Considerations for these values. Section 7.4.4: # Additional information describing the role of IANA in the allocation # of ClientCertificateType code points is described in Section 11. from pending
Errata ID: 117
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Pasi Eronen
Date Held: 2009-09-25
(C2) imprecise data description for `ciphersuites`
Section 7.4.1.2, on page 37 defines the syntax:
uint8 CipherSuite[2]; /* Cryptographic suite selector */
According to the specifications given in Section 4.3, vectors
of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.
Hence, the declaration in Section 7.4.1.2, on top of page 38,
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
should better say:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
| CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
This issue recurs in Appendix A.4.1 (2nd line from bottom of p.57)
and at various places in other TLS RFCs, in particular in RFC 4347
and RFC 4366 -- see my errata messages for these RFCs.
Historical Note:
In SSL 2.0, the CipherSuite construct was 3 bytes long.
Because 3 divides 2^16-1, <3..2^16-1> was an appropriate size
range then. The issue has been introduced with SSL 3.0.
(C3) missing Reference
Appendix B, at the bottom of page 66, contains the Glossary item:
RC2
A block cipher developed by Ron Rivest at RSA Data Security, Inc.
[RSADSI] described in [RC2].
There is no such Reference "[RSADSI]" in the Informative References
Section, on pp. 82 ff. -- apparently, it has been prematurely deleted
from RFC 2246. Perhaps, nothing would be lost when replacing the
above Glossary item by:
RC2
A block cipher developed by Ron Rivest described in [RC2].
(C4) Outdated Normative Reference
RFC 4346 has been jointly published with RFC 4366, which has
obsoleted RFC 3546.
Therefore, it would have been much more consistent to replace,
in the Normative References Section, on page 82, the entry:
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
by:
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
| Extensions", RFC 4366, April 2006.
^^^^^^^^^^^^^^^^
(C5) unexpected / inappropriate Reference
Page 83 contains the inappropriate Informative Reference:
[TCP] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
This clearly should be:
| [TCP] Postel, J., "Transmission Control Protocol", STD 7,
| RFC 793, September 1981.
(Cf. the single citation to [TCP], in the first paragraph of Section 1,
on page 4.)
Simple textual issues (errata)
==============================
(E1) typo
The second paragraph of Section 3 of RFC 4346, on page 6, says:
This document is not intended to supply any details of service
definition or of interface definition, although it does cover select
areas of policy as they are required for the maintenance of solid
security.
It should perhaps say:
This document is not intended to supply any details of service
definition or of interface definition, although it does cover
| selected areas of policy as they are required for the maintenance of
solid security.
(E2) copy-and-paste error (?)
At the bottom of page 11, Section 4.7 of RFC 4346 says:
In public key encryption, a public key algorithm is used to encrypt
data in such a way that it can be decrypted only with the matching
private key. A public-key-encrypted element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the signing
algorithm and key.
It should say:
In public key encryption, a public key algorithm is used to encrypt
data in such a way that it can be decrypted only with the matching
private key. A public-key-encrypted element is encoded as an opaque
| vector <0..2^16-1>, where the length is specified by the encrypting
algorithm and key.
^^^^^^^^^^
(E3) typo
The beginning of the first paragraph of Section 6.1, on page 15,
A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a compression algorithm, and encryption
algorithm, and a MAC algorithm. In addition, the parameters for
should say (replacing "and" by "an"):
A TLS connection state is the operating environment of the TLS Record
| Protocol. It specifies a compression algorithm, an encryption
algorithm, and a MAC algorithm. In addition, the parameters for
(E4) word twister
Near the bottom of page 15, Section 6.1 says:
compression algorithm
An algorithm to be used for data compression. This specification
must include all information the algorithm requires compression.
It should perhaps say:
compression algorithm
An algorithm to be used for data compression. This specification
| must include all information the compression algorithm requires.
(E5) improper indentation
In Section 7.4.1.1, on page 36, a headline is indented too much;
the text,
Structure of this message:
struct { } HelloRequest;
Note: This message MUST NOT be included ...
should say:
| Structure of this message:
struct { } HelloRequest;
Note: This message MUST NOT be included ...
(E6) improper line (un)folding and irregular indentation
In Section 7.4.1.2, at the bottom of page 36, the text,
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
gmt_unix_time The current time and date in standard UNIX 32-bit
format (seconds since the midnight starting Jan 1, 1970, GMT,
ignoring leap seconds) according to the sender's internal clock.
Clocks are not required to be set correctly by the basic TLS
Protocol; higher-level or application protocols may define
additional requirements.
random_bytes
28 bytes generated by a secure random number generator.
following the layout style followed in the remainder of the document
should be formatted as:
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
| gmt_unix_time
| The current time and date in standard UNIX 32-bit
format (seconds since the midnight starting Jan 1, 1970, GMT,
ignoring leap seconds) according to the sender's internal clock.
Clocks are not required to be set correctly by the basic TLS
Protocol; higher-level or application protocols may define
additional requirements.
| random_bytes
| 28 bytes generated by a secure random number generator.
(E7) improper line (un)folding
The last paragraph of Section 7.4.1.3, on page 40,
compression_method The single compression algorithm selected by the
server from the list in ClientHello.compression_methods. For
resumed sessions this field is the value from the resumed session
state.
consistently should be formatted as:
| compression_method
| The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions
this field is the value from the resumed session state.
(E8) improper line (un)folding and irregular indentation
In Section 7.4.7.1, on page 48, the clauses,
client_version The latest (newest) version supported by the
client. This is used to detect version roll-back attacks.
Upon receiving the premaster secret, the server SHOULD check
that this value matches the value transmitted by the client in
the client hello message.
random
46 securely-generated random bytes.
consistently should be formatted as:
| client_version
| The latest (newest) version supported by the client. This is
used to detect version roll-back attacks. Upon receiving the
premaster secret, the server SHOULD check that this value
matches the value transmitted by the client in the client hello
message.
random
| 46 securely-generated random bytes.
and subsequently, the clause,
pre_master_secret
This random value is generated by the client and is used to
generate the master secret, as specified in Section 8.1.
should be:
pre_master_secret
| This random value is generated by the client and is used to
| generate the master secret, as specified in Section 8.1.
(E9) spurious text line
During the removal of the "EXPORT" ciper suites from Appendix C,
a text line from RFC 2246 has been left there inadvertently.
The table, at the bottom of page 68,
Key
Exchange
Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None
DH_DSS DH with DSS-based certificates None
DH_RSA DH with RSA-based certificates None
| RSA = none
NULL No key exchange N/A
RSA RSA key exchange None
should say:
Key
Exchange
Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None
DH_DSS DH with DSS-based certificates None
DH_RSA DH with RSA-based certificates None
NULL No key exchange N/A
RSA RSA key exchange None
(E10) improper language
During the addition of the third protocol variant, text in Appendix E
has become improper, stiil talking about "both" versions.
The second paragraph of Appendix E, on page 71,
TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
supporting both is easy. TLS clients who wish [...]
^^^^
should say, e.g.:
TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
| supporting all is easy. TLS clients who wish [...]
^^^
(E11) improper line (un)folding
Appendix E.1, near the bottom on page 73, contains the clause:
challenge The client challenge to the server for the server to
identify itself is a (nearly) arbitrary-length random. The TLS
server will right-justify the challenge data to become the
ClientHello.random data (padded with leading zeroes, if
necessary), as specified in this protocol specification. If the
length of the challenge is greater than 32 bytes, only the last 32
bytes are used. It is legitimate (but not necessary) for a V3
server to reject a V2 ClientHello that has fewer than 16 bytes of
challenge data.
This should be formatted as:
| challenge
| The client challenge to the server for the server to identify
itself is a (nearly) arbitrary-length random. The TLS server will
right-justify the challenge data to become the ClientHello.random
data (padded with leading zeroes, if necessary), as specified in
this protocol specification. If the length of the challenge is
greater than 32 bytes, only the last 32 bytes are used. It is
legitimate (but not necessary) for a V3 server to reject a V2
ClientHello that has fewer than 16 bytes of challenge data.
(E12) punctuation issues in References
The following Normative Reference entries on page 81/82 contain
syntactically inconsistent punctuation.
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001.
should say:
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
| (AES)", FIPS 197. November 26, 2001.
^
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To
DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
should say:
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To
| DES", IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
^^
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards
Institute, 1983.
should say:
[DES] ANSI X3.106, "American National Standard for Information
| Systems-Data Link Encryption", American National Standards
Institute, 1983.
^^
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard,"
National Institute of Standards and Technology, U.S.
Department of Commerce, 2000.
should say: vv
| [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard",
National Institute of Standards and Technology, U.S.
Department of Commerce, 2000.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
should say: vv
| [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard", National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
Similarly, the following Informative Reference entry on page 83,
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems," Communications of the ACM, v. 21, n. 2,
Feb 1978, pp. 120-126.
should say:
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
| Cryptosystems", Communications of the ACM, v. 21, n. 2,
Feb 1978, pp. 120-126.
(E13) mis-spelled author name in Informative Reference
The name of Alan O. Freier has been mis-spelled on page 83, in the
Informative Reference,
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
which should say:
vv
| [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
Notes:
(Item C1 split to separate Errata ID 1896)
All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.
I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.
from pending
Note: This RFC has been obsoleted by RFC6347
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 115
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Russ Housley
(1) typo
At the top of page 3, Section 1 of RFC 4347 says:
[...]. Unfortunately, although application layer
security protocols generally provide superior security properties
(e.g., end-to-end security in the case of S/MIME), they typically
requires a large amount of effort to design -- in contrast to the
relatively small amount of effort required to run the protocol over
TLS.
It should say:
[...]. Unfortunately, although application layer
security protocols generally provide superior security properties
(e.g., end-to-end security in the case of S/MIME), they typically
| require a large amount of effort to design -- in contrast to the
relatively small amount of effort required to run the protocol over
TLS.
(2) imprecise data description for `ciphersuites`
This is an issue inherited from RFC 4346 -- see my errata submission
on that RFC. For convenience, I repeat the details here.
Section 7.4.1.2 of RFC 4346 (on p. 12 of RFC 4346) defines the syntax:
uint8 CipherSuite[2]; /* Cryptographic suite selector */
According to the specifications given in Section 4.3 of RFC 4346,
vectors of type CipherSuite strictly must have byte lengths being a
multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.
Hence, the declaration in Section 4.2.1 of RFC 4347, on page 12,
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
should say:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
| CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
This change should be applied to the syntax summary in section 4.3.2,
on mid-page 21, as well.
(3) missing white space
In Section 4.2.2 of RFC 4347, the lines on top of page 14,
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
should say:
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
| case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
| case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
| case finished: Finished;
This change should be applied to the syntax summary in section 4.3.2,
on top of page 21, as well.
(4) copy-and-paste issue (?)
On page 20, the first declaration in Section 4.3.2,
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
should say, using the appropriate term:
enum {
hello_request(0), client_hello(1), server_hello(2),
| hello_verify_request(3), // New value
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
(5) Outdated Informative References
RFC 4347 has been published several months after the new IPsec RFCs.
It therefore would have been preferrable to have the following
references updated:
[AH] : RFC 2402 --> RFC 4302
[ESP] : RFC 2406 --> RFC 4303
BTW: The Ref. "[AH]" does *not* appear anywhere in the text!
Also, The DCCP RFCs have been published a few weeks before RFC 4347;
therefore, the following Ref. update would have been appropriate:
[DCCP] : "Work in Progress" --> RFC 4340, March 2006.
(6) unexpected / inappropriate Reference
Page 23 contains the inappropriate Informative Reference:
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
Messages", RFC 2521, March 1999.
This clearly should be:
| [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
| Protocol", RFC 2522, March 1999.
(Cf. the citations to [PHOTURIS], in Section 4.2.1, on page 11.)
Notes:
All excerpts from the RFC text are taken keeping their original
formatting, and modified text is formatted in conformance with
RFC guidelines again.
I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.
from pending
Errata ID: 114
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-02-07
(1)
In Section 4.3.2.3 of RFC 4352, the first formula line on page 18,
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 < i < n
should say:
TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 <= i <= n
(2)
The 'Example Algorithm' in Section 4.5.1, on page 27, in the second
half of Step 1, says:
Return recovered timestamps as
x(n) = t0 + n*L1 and associated ISF equal to isf0,
for 0 < n < (t1 - t0)/L0
goto End
This pseudocode fragment should say:
for 0 < n < (t1 - t0)/L0
Return recovered timestamps as
x(n) = t0 + n*L0 and associated ISF equal to isf0
goto End
(3)
In Section 7.2, on page 32, the second item of the unnumbered list
says:
- The media type (payload format name) is used in SDP "a=rtpmap" as
the encoding name. [...]
It should say:
- The media subtype (payload format name) is used in SDP "a=rtpmap"
as the encoding name. [...]
(4)
Within the second paragraph on page 33, Section 7.2.1 of RFC 4352
says:
[...] As any receiver will
be capable of receiving stereo frame type and perform local mixing
within the AMR-WB+ decoder, there is normally only one reason to
restrict to mono only: to avoid spending bit-rate on data that are
not utilized if the front-end is only capable of mono.
It should say:
[...] As any receiver will
be capable of receiving stereo frame types and perform local
mixing within the AMR-WB+ decoder, there is normally only one
reason to restrict to mono only: to avoid spending bit-rate on
data that are not utilized if the front-end is only capable of
mono.
Notes:
from pending
Errata ID: 1473
Status: Verified
Type: Technical
Reported By: Serguei Leontiev
Date Reported: 2008-07-16
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 7 says:
This algorithm creates a GOST 28147-89 key Kd, given GOST R 34.10-94 or GOST R 34.10-2001 secret key K and diversification data D of size 4..40 bytes.
It should say:
This algorithm creates a GOST 28147-89 key Kd, produced from given 256-bit secret key K and diversification data D of size 4..40 bytes.
Notes:
In this place "secret key" means any key, which MUST NOT be used to
protect of raw data. For example, private keys, shared secret keys,
wrap/unwrap keys, etc.
Russian-English terminology translation bug
Errata ID: 1463
Status: Verified
Type: Editorial
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 4.1.1 Key... says:
Using the secret key corresponding to the originatorKey publicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
It should say:
Using the private key corresponding to the originatorKey publicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
Notes:
Russian-English terminology translation bug
Errata ID: 1464
Status: Verified
Type: Editorial
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 4.2.1 Key... says:
Using the secret key corresponding to the GostR3410- TransportParameters ephemeralPublicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
It should say:
Using the private key corresponding to the GostR3410- TransportParameters ephemeralPublicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
Notes:
Russian-English terminology translation bug
Errata ID: 1467
Status: Verified
Type: Editorial
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 13.2 says:
[RFDSL] "Russian Federal Digital Signature Law", 10 Jan 2002 N
1-FZ
It should say:
[RFDSL] "Russian Federal Electronic Digital Signature Law",
10 Jan 2002 N 1-FZ.
Notes:
Russian-English terminology translation bug
Errata ID: 715
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-02-27
Section 3.1. defines the Extended Community extended type classes 0x00ss and 0x40ss, as does Section 3.2. for the type classes 0x01ss and 0x41ss, and Section 3.3. for the type classes 0x03ss and 0x43ss (where 'ss' is the Sub-Type). These classes are also covered by the IANA Considerations section. Section 4. and Section 5. of RFC 4360 both define extended types where "the value of the high-order octet of the Type field ... can be 0x00, 0x01, or 0x02". There is no formal definition for the latter case, Type = 0x02ss, in the whole RFC, and the subtypes 0x0202 and 0x0203 are not covered by the IANA considerations section. >From text in Section 4. and 5., it can be concluded, that perhaps the layout from Section 3.1. should be applicable in this case as well, but that's all I could find! Was type 0x02ss deprecated during the evolution of the draft, or has the definition of that extended type been ommitted accidentially from the RFC ?
It should say:
[see above]
Notes:
from pending
Errata ID: 1917
Status: Verified
Type: Editorial
Reported By: Yakov Rekhter
Date Reported: 2009-10-19
Verifier Name: Ross Callon
Date Verified: 2009-10-19
Section 6 says:
If a route has a non-transitivity extended community,
It should say:
If a route has a non-transitive extended community,
Errata ID: 1632
Status: Reported
Type: Editorial
Reported By: Yakov Rekhter
Date Reported: 2008-12-12
Section 7 says:
This document defines a class of extended communities called IPv4
address specific extended community for which the IANA is to create
and maintain a registry entitled "IPv4 Address Specific Extended
Community". All the communities in this class are of extended Types.
Future assignment are to be made using the "First Come First Served"
policy defined in [RFC2434]. The Type values for the transitive
communities of the two-octet AS specific extended community class
are 0x0100-0x01ff, and for the non-transitive communities of that
class are 0x4100-0x41ff. Assignments consist of a name and the
value.
It should say:
This document defines a class of extended communities called IPv4
address specific extended community for which the IANA is to create
and maintain a registry entitled "IPv4 Address Specific Extended
Community". All the communities in this class are of extended Types.
Future assignment are to be made using the "First Come First Served"
policy defined in [RFC2434]. The Type values for the transitive
communities of the IPv4 Address specific extended community class
are 0x0100-0x01ff, and for the non-transitive communities of that
class are 0x4100-0x41ff. Assignments consist of a name and the
value.
Errata ID: 2680
Status: Rejected
Type: Editorial
Reported By: *Zhong* Qiyao
Date Reported: 2011-01-04
Rejected by: Ron Bonica
Date Rejected: 2011-01-24
Section MIB says:
> Dear IETF Person-in-Charge,
>
> We found that Q-BRIDGE-MIB (RFC 2674) had its content corrected
> using the RFC 4363.
>
> While this kind of update and grammatical correction is a good
> thing,
> we found that:
>
> << old ("which" as correlative pronoun)
> "The number of valid frames received by this port from
> its segment which were classified as belonging to this
> VLAN which were discarded due to VLAN related reasons.
> Specifically, the IEEE 802.1Q counters for Discard
> Inbound and Discard on Ingress Filtering."
> >>
>
> << new ("that" as correlative pronoun)
> "The number of valid frames received by this port from
> its segment that were classified as belonging to this
> VLAN and that were discarded due to VLAN-related reasons.
> Specifically, the IEEE 802.1Q counters for Discard
> Inbound and Discard on Ingress Filtering."
> >>
>
> According to our education, "which" is correct, and "that" is
> only
> colloquial. But Microsoft Word seems to reject the use of "which" in
> such
> situations, and it may have mis-lead IETF into thinking that the Q-
> BRIDGE-MIB
> should remove "which" and use "that", which is a pity.
>
> Thanks.
>
> Qiyao #3165 鍾啟堯　上
> --------------------------------------------------------------------------
> *Zhong* Qiyao, Xinzhu, Tajvano ~{VSFtR"~}
> Greg 2009.12.13-19
> --------------------------------------------------------------------------
Notes:
Many places.
--VERIFIER NOTES--
Please see http://www.chicagomanualofstyle.org/CMS_FAQ/Whichvs.That/Whichvs.That01.html for details
Ron Bonica
Errata ID: 113
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: ron bonica
(1) Section 1 (Introduction)
The 1st paragraph on page 3 contains the sentence:
[...]. The PE routers distribute, to the CE
routers in a particular VPN, the routes from other the CE routers in
that VPN. [...]
It should say:
[...]. The PE routers distribute, to the CE
| routers in a particular VPN, the routes from the other CE routers in
that VPN. [...]
^^^^^^^^^
(2) Section 3.3 (Populating the VRFs)
The last paragraph of Section 3.3, on mid-page 12, says:
If an attachment circuit leads to a site which is in multiple VPNs,
the attachment circuit may still associated with a single VRF, in
which case the VRF will contain routes from the full set of VPNs of
which the site is a member.
It should say:
vvvv
If an attachment circuit leads to a site which is in multiple VPNs,
| the attachment circuit may still be associated with a single VRF, in
which case the VRF will contain routes from the full set of VPNs of
which the site is a member.
(3) Section 6 (Maintaining Proper Isolation of VPNs)
At the bottom of page 26, and extending to page 27, the text says:
The first condition ensure that any labeled packets received from
non-backbone routers have a legitimate and properly assigned label at
<< page break >>
the top of the label stack. [...]
It should say:
vv
| The first condition ensures that any labeled packets received from
non-backbone routers have a legitimate and properly assigned label at
<< page break >>
the top of the label stack. [...]
(4) Section 7 (How PEs Learn Routes from CEs)
The descrition of 'technique #4', on mid-page 28 says:
4. The PE and CE routers may be BGP peers, and the CE router may
use BGP (in particular, EBGP to tell the PE router the set of
address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.)
It should say:
vvv
4. The PE and CE routers may be BGP peers, and the CE router may
| use BGP (in particular, EBGP) to tell the PE router the set of
address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.)
(5) Section 9 (Carriers' Carriers)
The last paragraph at the bottom of page 31 contains the sentence:
[...]. All that
is required is that the external routes be known to whatever routers
are responsible for putting the label stack on a hitherto unlabeled
packet and that there be label switched path that leads from those
routers to their BGP peers at other sites. [...]
It should say:
[...]. All that
is required is that the external routes be known to whatever routers
are responsible for putting the label stack on a hitherto unlabeled
| packet and that there be a label switched path that leads from those
routers to their BGP peers at other sites. [...]
^^^
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
from pending
Errata ID: 112
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: ron bonica
Date Verified: 2011-08-01
If these are desired, they must be provided by mechanisms that
are outside the scope of the VPN mechanisms. For instance, the
users can use secure protocols on an end-to-end basis, e.g.,
IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.
It should say:
If these are desired, they must be provided by mechanisms that
are outside the scope of the VPN mechanisms. For instance, the
users can use secure protocols on an end-to-end basis, e.g.,
| IPsec, Secure Shell (SSH), Transport Layer Security (TLS), etc.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Note: This RFC has been obsoleted by RFC5246 RFC6066
Source of RFC: tls (sec)
Errata ID: 111
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Rejected by: David Hopwood
Date Rejected: 2006-05-29
(1) imprecise syntax description for `ciphersuites`
This is an issue inherited from RFC 2246, RFC 3546, and RFC 4346;
I already have reported this issue against RFC 4346 (and RFC 4347
as well).
Section 7.4.1.2 of RFC 4346, on page 37 of RFC 4346 defines the syntax:
uint8 CipherSuite[2]; /* Cryptographic suite selector */
According to the specifications given in Section 4.3 of RFC 4346,
vectors of type CipherSuite strictly must have byte lengths being
a multiple of 2.
This also means that the upper bound for a varaiable-length array
of type CipherSuite should always be a multiple of 2.
Hence, the declaration in Section 2.1 of RFC 4366 (on page 5),
an extended version of the basic declaration in Section 7.4.1.2
of RFC 4346 (on top of page 38), stating
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
should better say:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
| CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
(2) incomplete semantics specified for "server_name" extension
Section 3.1 of RFC 4366, on page 9, defines the "server_name"
extension as containing a *list* of `ServerName` structures.
On page 10, the same section says:
It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
A server that receives a client hello containing the "server_name"
extension MAY use the information contained in the extension to guide
its selection of an appropriate certificate to return to the client,
and/or other aspects of security policy. In this event, the server
SHALL include an extension of type "server_name" in the (extended)
server hello. The "extension_data" field of this extension SHALL be
empty.
If the server understood the client hello extension but does not
| recognize the server name, it SHOULD send an "unrecognized_name"
^^^
alert (which MAY be fatal).
and on page 19, Section 4 defines the error alert,
- "unrecognized_name": this alert is sent by servers that receive a
| server_name extension request, but do not recognize the server
name. This message MAY be fatal. ^^^
All these clauses apparently state the semantics for the "server_name"
extension solely in the case where the data field of the extension in
the (extended) Client Hello contains a *single* `ServerName` structure.
IMHO, if the client, as allowed by the syntax, indeed specifies
multiple names in the "server_name" extension -- a feature that
seems to be useful in certain scenarios --, it needs to get feedback
from the server as to which of the specified names has been used for
the purpose described in the second paragraph cited above.
Hence, the server should better be instructed by the specification
to include the selected name in the "server_name" extension returned
to the client in the (extended) Server Hello.
For backwards compatibility, the specification should perhaps
prescribe to omit this feedback, reverting to the specification
cited above) in the case that the Client Hello received contained
only a single server name.
In parallel, the semantics of the "unrecognized_name" alerts should
be amended to mean: all received names are unrecognized.
(3) incomplete / outdated referencing text
The paragraph of Section 3.2 spanning from page 11 to page 12, says:
[...]. For example, if the negotiated
<page break>
length is 2^9=512, then for currently defined cipher suites (those
defined in [TLS], [KERB], and [AESSUITES]), and when null compression
is used, the record layer output can be at most 793 bytes: 5 bytes of
headers, 512 bytes of application data, 256 bytes of padding, and 20
bytes of MAC. [...]
This apparently is not up to date. I propose to either substitute
"[TLSbis]," for "[TLS]," in the text above -- thus referring only to
current specifications --, or even to substitute "[TLS] and [TLSbis],"
for "[TLS]," there -- thus honoring to the predecessor.
(4) spurious blank line
Within Section 3.6, the 5th paragraph on page 18 is interrupted
by a blank line in the middle of a sentence.
Perhaps this is a formatting artifact inherited from the page break
that was at this place in the text in RFC 3546.
Thus, the text body:
Servers return a certificate response along with their certificate by
sending a "CertificateStatus" message immediately after the
"Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a
|
"CertificateStatus" message, then the server MUST have included an
extension of type "status_request" with empty "extension_data" in the
extended server hello.
should be joined to say:
Servers return a certificate response along with their certificate by
sending a "CertificateStatus" message immediately after the
"Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a
"CertificateStatus" message, then the server MUST have included an
extension of type "status_request" with empty "extension_data" in the
extended server hello.
(5) punctuation issue in Informative Reference
The following Informative Reference entry on page 28 contains
syntactically inconsistent punctuation:
[MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
ClientHello extension mechanism and virtual hosting,"
ietf-tls mailing list posting, August 14, 2000.
should say:
[MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
| ClientHello extension mechanism and virtual hosting",
ietf-tls mailing list posting, August 14, 2000.
Notes:
All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.
I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.
Issue (2) above certainly needs discussion; perhaps you know what
once was intended. The other issues seem to be straightforward.
from pending
Errata ID: 110
Status: Verified
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2006-02-26
Verifier Name: RFC Editor
Date Verified: 2007-10-10
Section 3 says:
>From this model, it is clear that three entities in the system can potentially make false assumptions about the service provided by the server.
It should say:
From this model, it is clear that three entities in the system can potentially make false assumptions about the service provided by the server.
Errata ID: 675
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-10-31
Section 5 says:
[...]. Note that mplsLcAtmStdUnlabTrafVci and mplsLcAtmStdCtrlVci
MUST not be equal; nor should mplsLcAtmStdCtrlVpi or
mplsLcAtmStdUnlabTrafVpi be equal.
It should say:
Note that the VPI/VCI pair used for unlabeled traffic (mplsLcAtmStdUnlabTrafVpi, mplsLcAtmStdUnlabTrafVci) MUST NOT equal the VPI/VIC pair used for control traffic (mplsLcAtmStdCtrlVpi, mplsLcAtmStdCtrlVci).
Notes:
The (Vpi, Vci) - *pairs* must not be equal for every
mplsLcAtmStdInterfaceConfEntry.
Errata ID: 105
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11
Section 2 says:
C-FR RFC 3034 defines a label-switching-controlled Frame Relay
(LC-FR) interface. Packets traversing such an interface carry
labels in the DLCI field
C-ATM RFC 3035 defines a label-switching-controlled ATM (LC-ATM)
interface as an ATM interface controlled by the label switching
control component.
It should say:
LC-FR
RFC 3034 defines a label-switching-controlled Frame Relay
(LC-FR) interface. Packets traversing such an interface carry
labels in the DLCI field
LC-ATM
RFC 3035 defines a label-switching-controlled ATM (LC-ATM)
interface as an ATM interface controlled by the label switching
control component.
Notes:
The acronyms, "C-FR" and "C-ATM", do not appear elsewhere in the text.
Apparently, the first column has been cut off.
Errata ID: 109
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 2.1 says:
One-hop Delay: The fixed delay experienced by a packet to
reach the next hop resulting from the of
the propagation latency, the transmission
latency, and the processing latency.
It should say:
One-hop Delay: The fixed delay experienced by a packet to
reach the next hop resulting from the sum
of the propagation latency, the
transmission latency, and the processing
latency.
Notes:
Fix word omission. Insert "sum"
Errata ID: 676
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 4.1 says:
Furthermore, the automation of path liveliness is desired in cases where large numbers of LSPs might be tested. [...]
It should say:
| Furthermore, the automation of path liveliness testing is desired in cases where large numbers of LSPs might be tested. [...]
Notes:
Fix word omission. Insert "testing"
Errata ID: 677
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 4.11.1 says:
(1) At an ingress LSR, accounting of traffic through LSPs that
| begin at each egress in question.
^^^^^
(2) At an intermediate LSR, accounting of traffic through LSPs for
| each pair of ingress to egress.
^^
v
| (3) At egress LSR, accounting of traffic through LSPs for each
ingress.
It should say:
(1) At an ingress LSR, accounting of traffic through LSPs that
| end at each egress in question.
(2) At an intermediate LSR, accounting of traffic through LSPs for
| each pair of ingress and egress.
| (3) At an egress LSR, accounting of traffic through LSPs for each
ingress.
Notes:
Fix wrong wording in bullet (1) [s/begin/end/]
Minor typos in bullets (2) and (3).
Errata ID: 108
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
Section 3 says:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 (FEC TLV) | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 (FEC TLV) | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
According to Section 3.3 of the LDP specification, RFC 3036,
the Lenght element of LDP TLVs measures the size of the Value
element in bytes.
Therefore, 'Length = 12' is wrong, it should be 'Length = 32'.
from pending
Errata ID: 1418
Status: Verified
Type: Technical
Reported By: Brian Carpenter
Date Reported: 2008-04-30
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
Section 4.3 says:
An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104.
It should say:
An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:7F00/104.
Notes:
The ":127" is ambiguous (intended to be decimal, but could be hexadecimal).
An alternative fix would be 0:0:0:0:0:FFFF:127.0.0.0/104.
This report was corrected 9/15/08 as requested by Brian Carpenter.
Errata ID: 1714
Status: Verified
Type: Technical
Reported By: Yaakov (J) Stein
Date Reported: 2009-03-12
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02
Section 3 says:
Page 6 figure
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Page 8 para 6
The TimeStamp Sent is the time-of-day (in seconds and microseconds,
according to the sender's clock) in NTP format [NTP] when the MPLS
echo request is sent.
It should say:
Page 6 figure
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Page 8 para 6
The TimeStamp Sent is the time-of-day in NTP format [NTP],
according to the sender's clock, when the MPLS echo request is sent.
Notes:
The text and figure were contradictory since in NTP format the second field
of 32 bits is fractional seconds, not microseconds.
Errata ID: 1786
Status: Verified
Type: Editorial
Reported By: Jon Chung Hyok
Date Reported: 2009-05-20
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24
Section 4.4 says:
on page 38
If the number of labels in the FEC stack is greater
than or equal to FEC-stack-depth {
It should say:
If the number of FECs in the FEC stack is greater
than or equal to FEC-stack-depth {
Notes:
labels -> FECs
Errata ID: 742
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Adrian Farrel
Date Held: 2010-01-02
(1) [[posted separately.]]
(2) Section 3.3.1 -- formating error
The second encoding diagram on page 27,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) Section 4.4 -- word omission
On page 35, the RFC text contains the bullet:
Best-return-code: contains the return code for the echo reply packet
as currently best known. As algorithm progresses,
this code may change depending on the results of
further checks that it performs.
It should say:
Best-return-code: contains the return code for the echo reply packet
| as currently best known. As the algorithm
progresses, this code may change depending on the
results of further checks that it performs.
(4) Section 4.4 -- word omission in pseudo-code comment
On page 38, within the pseudocode comment, the RFC says:
[...]
may be greater than Label-stack-depth. To be consistent with
the above stack-depths, the bottom is considered to entry 1.
*/
It should say:
[...]
may be greater than Label-stack-depth. To be consistent with
| the above stack-depths, the bottom is considered to be entry 1.
*/
(5) Section 4.4 -- wrong internal section reference
The last paragraph of section 4.4 (Step 7.), on page 40, says:
Send an MPLS echo reply with a Return Code of Best-return-code,
and a Return Subcode of Best-rtn-subcode. Include any TLVs
created during the above process. The procedures for sending
| the echo reply are found in subsection 4.4.1.
^^^^^
It should say:
Send an MPLS echo reply with a Return Code of Best-return-code,
and a Return Subcode of Best-rtn-subcode. Include any TLVs
created during the above process. The procedures for sending
| the echo reply are found in subsection 4.5.
(6) Section 5.1 -- outdated Normative Reference
On page 43, the tag [NTP] points to RFC 2030.
At the time of publication of RFC 4377, RFC 2030 already had been
obsoleted by RFC 4330.
Therefore, the text after [NTP] should be replaced by the
rfc-ref.txt entry for RFC 4330.
(7) Section 6 -- typo
At the end of the second paragraph on page 4, the RFC says:
[...]. However, to provide a
stronger defense, an implementation MAY also validate the TimeStamp
| Sent by requiring and exact match on this field.
^
It should say:
[...]. However, to provide a
stronger defense, an implementation MAY also validate the TimeStamp
| Sent by requiring an exact match on this field.
Notes:
from pending
Errata ID: 2978
Status: Held for Document Update
Type: Editorial
Reported By: Zhi Zheng
Date Reported: 2011-09-21
Held for Document Update by: Adrian Farrel
Section 4.4 says:
on page 36
Else {
Retrieve the associated label operation from the
corresponding NLFE and proceed to step 4 (Label Operation
check).
It should say:
Else {
Retrieve the associated label operation from the
corresponding NHLFE and proceed to step 4 (Label Operation
check).
Notes:
NLFE -> NHLFE
Errata ID: 107
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-16
Held for Document Update by: Wes Eddy
(1) Inconsistency on cryptographic algorithm (MAC) requirements
Within section 5.2.2, on the upper half of page 21, RFC 4380 states:
To maximize interoperability, this specification defines a default
algorithm in which the authentication value is computed according the
| HMAC specification [RFC2104] and the SHA1 function [FIPS-180].
Clients and servers may agree to use HMAC combined with a different
function, or to use a different algorithm altogether, such as for
example AES-XCBC-MAC-96 [RFC3566].
The default authentication algorithm is based on the HMAC algorithm
according to the following specifications:
| - the hash function shall be the SHA1 function [FIPS-180].
- the secret value shall be the shared secret with which the client
was configured.
Contrary to that, within Section 7.2.1, in the paragraph extending
from page 39 to page 40, the same RFC says:
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
authentication value. This specification suggests a default
<<page break>>
| algorithm combining HMAC and MD5. If the protection afforded by MD5
was not deemed sufficient, clients and servers can agree to use a
different algorithm, e.g., SHA1.
I have been educated repeatedly that Security Considerations in RFCs
contain normative content when describing protocol behaviour.
Therefore, it should not happen that text in Security Considerations
contradicts normative content of other sections of an RFC.
Regarding the well known security issues that make MD5 appear much
weaker than SHA-1, according to contemporary comprehension by the
cryptographic community, the former specification (Section 5.2.2)
seems to be the better choice.
I therefore strongly recommend to publish an Author's Errata Note
for RFC 4380 correcting Section 7.2.1, replacing the snippit above
by text conforming to the rules specified in Section 5.2.2, e.g.:
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
| authentication value. This specification defines a default algorithm
| combining HMAC and SHA-1. Clients and servers can agree to use a
| different message authentication algorithm, e.g. AES-XCBC-MAC-96.
| See Section 5.2.2 for details.
(2) Incomplete IANA Considerations
Section 9 of RFC 4380, on page 50, says:
This memo documents a request to IANA to allocate a 32-bit Teredo
IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
multicast address, as specified in Section 2.17.
It should say:
| On requests documented in this memo, IANA has allocated a 32-bit
| Teredo IPv6 service prefix, as specified in Section 2.6, a Teredo
| IPv4 multicast address, as specified in Section 2.17, and a Teredo
| UDP Port number, as specified in Section 2.7.
Rationale:
As per publication of the RFC, these assignments *have been* performed
by the IANA; I propose modified wording reflecting this fact.
Apparently, an IANA assignment also has been performed on behalf of the
Teredo proposal as documented in Section 2.7; for completeness, this
assignment should be mentioned in the IANA Considerations section as
well. This will also serve as an easy-to-find "pointer" for readers
looking for the purpose of the assignment found in the IANA registry.
(3) Various typos
I have found a couple of apparent typos in RFC 4380. The sub-items
below are pre-formatted for easy inclusion into an RFC errata note.
(3.1) Section 5.2.2, page 21
The first paragraph on page 21 contains the sentence:
[...]. Before transmission,
the authentication value is computed according to the specified
algorithm; on reception, the same algorithm is used to compute a
target value from the content of the receive packet. [...]
It should say:
[...]. Before transmission,
the authentication value is computed according to the specified
algorithm; on reception, the same algorithm is used to compute a
| target value from the content of the received packet. [...]
^
(3.2) Section 5.2.3, page 23
The second paragraph on page 23 [numbered list item 4)] says:
[...]. The client SHOULD reply with a unicast Teredo bubble, sent
to the source IPv4 address and source port of the local discovery
bubble; the IPv6 source address of the bubble will be set to local
Teredo IPv6 address; [...]
It should say:
[...]. The client SHOULD reply with a unicast Teredo bubble, sent
to the source IPv4 address and source port of the local discovery
| bubble; the IPv6 source address of the bubble will be set to the local
Teredo IPv6 address; [...]
^^^^
(3.3) Section 5.2.7, page 27
The long paragraph in the middle of page 27 says:
[...]. If the secondary
qualification fails, the interval determination procedure will not be
used, and the interval value will remain to the default value, 30
seconds. [...]
It should say:
[...]. If the secondary
qualification fails, the interval determination procedure will not be
| used, and the interval value will remain at the default value, 30
seconds. [...]
^^^^
(3.4) Section 5.2.9, page 30
The last paragraph of Section 5.2.9 says:
[...] The nonce value and the date at which the packet was
sent will be documented in a provisional peer entry for the IPV6
destination. The ICMPv6 packet will then be sent [...]
It should say:
[...] The nonce value and the date at which the packet was
| sent will be documented in a provisional peer entry for the IPv6
destination. The ICMPv6 packet will then be sent [...]
^^^^
(3.5) Section 7.2, page 39
The last sentence of Section 7.2 says:
[...] The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
of "man-in-the-middle" attack.
It should say:
[...] The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
| of "man-in-the-middle" attacks.
^
(4) Formatting issue
RFC 4380 contains a striking number of spurious blank lines inserted
in the middle of running text, interrupting proper paragraph formating.
Browsing through RFC 4380, I have found such spurious blank lines on
pages 23, 30, 33, 35, 41, 44, and 46.
Notes:
from pending
Errata ID: 106
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-02-27
Held for Document Update by: Ron Bonica
(1)
RFC 4384, in the table legend on page 6, and in Section 6,
at the bottom of page 9, refers to ISO 3166-2 for numeric
country codes. This is not correct.
ISO 3166-2 specifies codes for *subdivisions* of countries,
e.g. the States of the U.S.A., or the provinces of Canada.
The numeric Country Codes apparently used in RFC 4384 in fact
are defined and maintained as a part of ISO 3166-1 !
That Standard contains 3 tables: 2-character, 3-character,
and numeric Country Codes. Unfortunately, only the first
table (also used for ccTLDs in the DNS) is made publicly
(online) available by ISO; apparently this has generally
raised the impression that ISO 3166-1 just comprised that
single table. (This might have been the background for
mentioning ISO 3166-2 in the RFC.)
ISO certainly would appreciate if many people bought the
ISO 3166-2 database when looking for the numeric country
codes, but probably neither ISOC/IETF nor the RFC author
would be participating in such earnings of ISO :-)
Therefore, I propose to correct this flaw by means of an
RFC Errata Note, as follows:
RFC 4384, on mid-page 6, says:
<CC> is the 10-bit ISO-3166-2 country code [ISO3166]
Where it should say:
<CC> is the 10-bit ISO-3166-1 country code [ISO3166]
^^^
Accordingly, the final sentence of Section 6, on page 9,
saying:
[...]. Henk Uijterwaal suggested the use
of the ISO-3166-2 country codes.
should say:
[...]. Henk Uijterwaal suggested the use
of the ISO-3166-1 numeric country codes.
^^^^^^^^^
(2)
According to the explanation in Section 3 (page 5), the <Value>
filed is 16 bit wide, and the last sentence on page 5 in Section 4
emphasized the split format "<AS>:<Value>". (The references to
<Value> in section 4.1 are consistent with that terminology.)
Therefore, in the table on page 6, the "<AS>:" leaders in the
column titled "Value" are inappropriate.
Perhaps, a 'minimally invasive' correction should modify the
headline, not the table entries:
The headline of the table on page 6,
Category Value
should say:
Category <AS>:<Value>
(3)
The encoding diagram in section 4.2, on page 9, apparently
contains the concrete sample value, '0x10F2' (from the
immediately preceding example in Section 4.1), where it
probably should contain the abstract notion "<Value>".
The literal encoding as presented is misleading, hence
the following correction seems to be appropriate:
RFC 4384, in section 4.2 on page 9 contains the diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This diagram 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | <Value> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(4)
RFC 4384 makes a Normative Reference to RFC 1771.
But, almost 3 weeks ahead of the publication of RFC 4384,
RFC 1771 has been obsoleted by RFC 4271.
Has this obsolete reference been made intentionally (I cannot
see any immediate reason for doing so) -- or is it just an
editorial oversight?
Notes:
from pending
Errata ID: 1743
Status: Verified
Type: Technical
Reported By: Yaakov (J) Stein
Date Reported: 2009-03-26
Verifier Name: Adrian Farrel
Date Verified: 2011-08-03
Section 4, 4.1, 4.2 says:
The sequence number mechanism described here uses a circular unsigned 16-bit number space that excludes the value zero. ... o The sequence number that follows 65535 (maximum unsigned 16-bit number) is one. ... o If the sequence number on the packet is zero, the sequence integrity of the packets cannot be determined. In this case, the received packet is considered to be in order.
It should say:
The sequence number mechanism for all PW types except the TDM PWs SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a circular unsigned 16-bit number space that excludes the value zero. The sequence numbers for TDM PWs include the value zero. ... o For all non-TDM PWs the sequence number that follows 65535 (maximum unsigned 16-bit number) is one. ... o If the sequence number on a non-TDM-PW packet is zero, the sequence integrity of the packets cannot be determined. In this case, the received packet is considered to be in order.
Notes:
The fact that the TDM PWs always require sequence number and do not give a zero value special meaning was well-known and documented in the relevant RFCs. However, this was forgotten in this document and has caused confusion to implementers.
Errata ID: 104
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-02
(1) [word omission]
The second paragraph of section 4.2 of RFC 4388 says:
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
and troubleshooting activities at large DHCP installations, and is
primarily intended as a method of gathering performance statistics
about servers the load presented to them.
It should perhaps better say:
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
and troubleshooting activities at large DHCP installations, and is
primarily intended as a method of gathering performance statistics
| about servers and the load presented to them.
^^^^^
(2) [improper wording]
RFC 4388 repeatedly talks about
"[an] IP address most recently accessed by a client"
^^^^^^^^^^^
where, IMHO, it should talk about
| "[an] IP address most recently assigned to a client"
^^^^^^^^^^^
Rationale:
The client may access any IP address at any time. Such access
is mostly unrelated to the protocol described in RFC 4338.
The affected places in the text I found are:
- Section 5, first paragraph of both the second and the third
bulleted items, on page 10 / 11, respectively;
- Last paragraph on page 17 (within section 6.4.1).
(3) [incomplete specification]
The second paragraph of Section 6.4.1, on page 17, says:
In the event that an IP address appears in the "ciaddr" field of a
DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
server, then that IP address MUST be set in the "ciaddr" field of a
DHCPLEASEUNASSIGNED message.
It should in fact say:
In the event that an IP address appears in the "ciaddr" field of a
DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
server, then that IP address MUST be set in the "ciaddr" field of a
| DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^
Rationale:
From the remaining text, it can be inferred that the "ciaddr"
field from the DHCPLEASEQUERY message should be copied to an
DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.
IMHO, this copy should be performed generally, i.e. also in the case
described by the subsequent paragraph:
If the IP address is not managed by the DHCP server, then a
DHCPLEASEUNKNOWN message must be returned.
that therefore might be amended to say:
If the IP address is not managed by the DHCP server, then a
| DHCPLEASEUNKNOWN message MUST be returned, with that IP address
| set in the "ciaddr" field.
[The original 'must' should be a 'MUST' because the alternatives
are also specified as a 'MUST' -- or else the specification would
be incomplete.]
Taken together, it might be preferable to restate this fact by
only changing the first paragraph cited above as follows, and leave
the second paragraph unchanged with the exception of the 'must':
In the event that an IP address appears in the "ciaddr" field of a
| DHCPLEASEQUERY message, then that IP address MUST be set in the
| "ciaddr" field of any reply returned.
| If that IP address is one managed by the DHCP server, then it MUST
| reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.
If the IP address is not managed by the DHCP server, then a
| DHCPLEASEUNKNOWN message MUST be returned.
Please comment on which alternative you prefer.
Notes:
from pending
Errata ID: 103
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-04-18
(1) typo?? The last paragraph of section 5 of RFC 4389, on page 12, says: A receives this NA, processing it as usual. Hence it creates a neighbor entry for B on interface 2 in the REACHABLE state and records the link-layer address p1. Since the packet described has been sent out by node P, on its interface '1', to node A, and A has only a single interface involved in the scenarion, with link layer address 'a' (as explained at the beginning of section 5), "on interface 2" is improper in the snippit above. (This may be the result of incomplete adaptation after a copy-and-paste operation.) A minimal correction to resolve this issue might be to name the receive interface by its link layer address, hence changing the text above to say: A receives this NA, processing it as usual. Hence it creates a neighbor entry for B on interface 'a' in the REACHABLE state and records the link-layer address p1. or alternatively, more detailed: A receives this NA, processing it as usual. Hence it creates a neighbor entry for B on the interface with link layer address 'a' in the REACHABLE state and records the link-layer address p1. (2) typo! The 3rd paragraph of Section 9, on page 13, says: This document does not introduce any new mechanisms for the protection of proxy Neighbor Discovery. That is, it does not provide a mechanism from authorizing certain devices to act as proxies, and it does not provide extensions to SEND to make it possible to use both SEND and proxies at the same time. [...] It should perhaps better say ( applying 's/from/for/' ) : This document does not introduce any new mechanisms for the protection of proxy Neighbor Discovery. That is, it does not provide | a mechanism for authorizing certain devices to act as proxies, and it does not provide extensions to SEND to make it possible to use both SEND and proxies at the same time. [...] (3) outdated reference In Section 11, Normative References, RFC 4389 contains the entry (on page 14) [ICMPv6], pointing to RFC 2463. But exactly 3 weeks before RFC 4389, RFC 4443 has been published obsoleting and replacing RFC 2463. Hence that entry should have been updated to properly point to RFC 4443 instead. If you agree with my 'diagnosis', I recommend that you submit an Author's Errata Note for RFC 4389 covering the three issues listed above. But if you prefer, I can instead submit an Errata Note on my own, with your consent mailed to the RFC-Editor.
Notes:
from pending
Errata ID: 1673
Status: Verified
Type: Technical
Reported By: Larry Masinter
Date Reported: 2009-01-29
Verifier Name: RFC Editor
Date Verified: 2009-01-29
RFC Header
BCP: 115
It should say:
BCP: 35
Notes:
RFC 4395 obsoletes RFC 2717, which was BCP 35. RFC 4395 should have been published as BCP 35 (not BCP 115). Number 115 in the BCP series has been retired.
Authors and AD approved this change.
Errata ID: 102
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-07
Section 4.1.4 says:
For TYPE 3 units containing the last (trailing) modifier fragment,...
It should say:
For TYPE 3 units containing the complete modifiers,...
Notes:
from pending
Errata ID: 973
Status: Verified
Type: Editorial
Reported By: Steve Conner
Date Reported: 2006-12-16
Section 9 says:
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
It should say:
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
Notes:
from pending
Errata ID: 2460
Status: Reported
Type: Technical
Reported By: Paul Freeman
Date Reported: 2010-08-07
Section 2 says:
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
It should say:
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Notes:
In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure.
Errata ID: 101
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-03
Section 2.1 says:
The FCIP Entity table contains information about this entity's existing instances of FCIP entities.
It should say:
The FCIP Entity table contains information about this device's existing instances of FCIP entities.
Notes:
The present text is almost recursive nonsense.
* Section 2. explains the terminology.
* The DESCRIPTION clause of the fcipEntityInstanceTable OBJECT-TYPE
definition (on page 9) correctly states:
"Information about this FCIP device's existing instances of
FCIP entities."
^^^^^^
from pending
Errata ID: 100
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Alexey Melnikov
(1) On page 3 of RFC 4407, the third paragraph, Note that the results of this algorithm are only as truthful as the headers contained in the message; if a message contains fraudulent or incorrect headers, this algorithm will yield an incorrect result. [...] should say: Note that the results of this algorithm are only as truthful as the | header fields contained in the message; if a message contains | fraudulent or incorrect header fields, this algorithm will yield an incorrect result. [...] (2) On page 3, the first sentence in Section 2, The PRA of a message is determined by the following algorithm: should say more precisely: The PRA of a message is determined by the following algorithm, applied to the message header (i.e., the first mail header within the message, in case of a MIME message): (3) Subsequently, within the description of the six steps of the algorithm (on page 3/4), the term `header` should always be replaced by `header field`, and `headers` should always be replaced by `header fields` (total of 16 occurrences). (4) On page 4 (just below the emumerated algorithm steps), the paragraph, For the purposes of this algorithm, a header field is "non-empty" if and only if it contains any non-whitespace characters. Header fields that are otherwise relevant but contain only whitespace are ignored and treated as if they were not present. should say: For the purposes of this algorithm, a header field is "non-empty" if | and only if its body contains any non-whitespace characters. Header | fields that are otherwise relevant but contain only whitespace bodies are ignored and treated as if they were not present. (5) Immediately following the paragraph mentioned above in item (4), still on page 4, the substitutions from item (3) above should be applied to the next two paragraphs and the last paragraph of Section 2 as well (total of 8 occurrences). (6) On page 5, the first paragraph of section 3, The PRA, as described by this document, is extracted from message headers that have historically not been verified. Thus, anyone using the PRA for any purpose MUST be aware that the headers from which it is derived might be fraudulent, malicious, malformed, and/or incorrect. [...] should say (apply item (3) above twice): The PRA, as described by this document, is extracted from message | header fields that have historically not been verified. Thus, anyone | using the PRA for any purpose MUST be aware that the header fields from which it is derived might be fraudulent, malicious, malformed, and/or incorrect. [...] and the second paragraph of Section 3, A message's PRA will often be extracted from a header field that is not normally displayed by existing mail user agent software. If the PRA is used as part of a mechanism to authenticate the message's origin, the message SHOULD NOT be displayed with an indication of its authenticity (positive or negative) without the PRA header field also being displayed. should say: A message's PRA will often be extracted from a header field that is not normally displayed by existing mail user agent software. If the PRA is used as part of a mechanism to authenticate the message's origin, the message SHOULD NOT be displayed with an indication of its | authenticity (positive or negative) without the PRA header field body also being displayed.
Notes:
The RFC adds to the trouble of mis-used
terminology from the Internet Message Format (IMF) framework;
it repeatedly confuses the precisely defined terms, 'header',
'header field', and 'header field body'.
The most recent summary of the IETF standardized IMF terminology
(from RFC 2822 et al.) can be found on page 3 of RFC 4249:
3.1.1. Standard Terminology
Terms related to the Internet Message Format are defined in
[N2.RFC2822]. Authors specifying extension header fields should use
the same terms in the same manner in order to provide clarity and
* avoid confusion. For example, a "header" [I1.FYI18], [N2.RFC2822] is
* comprised of "header fields", each of which has a "field name" and
* usually has a "field body". Each message may have multiple
* "headers", viz. a message header and MIME-part [N4.RFC2046] headers.
* A message header has a Date header field (i.e., a field with field
* name "Date"). However, there is no "Date header"; use of such non-
* standard terms is likely to lead to confusion, possibly resulting in
* interoperability failures of implementations.
For details, see Sections 2.1 and 2.2 of RFC 2822 and other places.
I also recommend the terminology sections in RFC 4021 and RFC 3864.
from pending
Errata ID: 994
Status: Held for Document Update
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2007-11-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-01
See this page for discussion of errata for RFC 4408: <http://www.openspf.org/RFC_4408/Errata>
Notes:
Alexey: if there is interest in revising the document, then it should be updated to incorporate some changes suggested on the above web page.
Errata ID: 2250
Status: Verified
Type: Editorial
Reported By: Wayne Schlitt
Date Reported: 2006-05-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-11
Section B.3 says:
$ORIGIN _spf.example.com. mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
It should say:
$ORIGIN _spf.example.com. mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
Notes:
The DNS zone file example has incorrect line breaks.
Errata ID: 99
Status: Held for Document Update
Type: Editorial
Reported By: Wayne Schlitt
Date Reported: 2006-05-16
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-11
1) On page 1, in the IESG notes, "aParticipants" should be
"Participants".
2) On page 40, the US-ASCII normative reference has an incorrectly
indented second paragraph. Instead of:
[US-ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with slight
modifications, but the 1968 version remains definitive for
the Internet.
it should be:
[US-ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains
definitive for the Internet.
Note: This RFC has been obsoleted by RFC6409
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 1078
Status: Verified
Type: Editorial
Reported By: Stephane Bortzmeyer
Date Reported: 2006-06-26
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06
Section 7 says:
NO-SOLICITING Notification of no soliciting MAY [Msg-Track]
It should say:
NO-SOLICITING Notification of no soliciting MAY [No-soliciting]
And a new reference in Section 13:
[No-soliciting] C. Malamud, "A No Soliciting Simple Mail Transfer
Protocol (SMTP) Service Extension", RFC 3865,
September 2004.
Notes:
Section 13 says:
[Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", RFC 3885, September 2004.
Which is not correct for NO-SOLICITING, which is defined in RFC 3865
Errata ID: 2393
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-24
Section 7 says:
The list of SMTP extensions provided on page 10 of RFC 4409 unfortunately is incomplete. As far as I can see, the following RFCs with SMTP extensions predate the publication of RFC 4409: o RFC 2645 -- ATRN o RFC 2852 -- DELIVERBY o RFC 3865 (+ RFC 4095) -- NO-SOLICITING o RFC 4141 -- CONPERM, CONNEG [ o RFC 4405 ]
Notes:
Quickly browsing these RFCs, I found that only RFC 4405 has
followed the specification in Section 7 of RFC 2476 (literally
carried over to RFC 4409):
Future SMTP extensions SHOULD explicitly specify if they are valid on
the Submission port.
and contains a definitive statement to this end.
RFC 4405 therefore arguably might be excluded from the list.
It would have been useful to have a complete list, with the
proper applicability keywords for the above SMTP extensions.
Errata ID: 98
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-24
Issues with References:
a) Section 12 of RFC 4409 contains the entry:
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
and D. Crocker, "SMTP Service Extensions", STD 10,
RFC 1869, November 1995.
`STD 10` in fact should be `(ex) STD 10` according to rfcxx00.txt .
The material from RFC 1869 has been incorporated into RFC 2821,
and RFC 1869 has been reclassified to Historic.
Therefore, this reference should not have been listed as a
Normative Reference. The Ref. to RFC 2821 in fact catches all.
Section 12 of RFC 4409, under [SMTP-MTA] also contains the entry:
Partridge, C., "Mail routing and the domain
system", STD 10, RFC 974, January 1986.
`STD 10` in fact should better have been `(ex) STD 14` --
rfcxx00.txt says: "Now Historic." ^^
The non-obsolete material from RFC 974 has been incorporated
into RFC 2821 and RFC 974 has been reclassified as Historic.
Therefore, this reference should not have been listed as a
Normative Reference. The Ref. to RFC 2821 in fact catches all.
Finally, the subsequent entry,
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
also is not needed any more, because the SMTP related material
in RFC 1123 has been revised and incorporated into RFC 2821
as well. The Ref. to RFC 2821 in fact catches all.
b) Section 13 of RFC 4409, under [MESSAGE-FORMAT] contains the entry:
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
Similarly to the last item above, the IMF related material from
RFC 1233 has been revised and incorporated into RFC 2822; thus
this Ref. is not really needed any more.
The Ref. to RFC 2822 in fact catches all.
c) Section 13 of RFC 4409 contains the entry:
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998.
This Ref. was already outdated at the time of publication of
RFC 4409; it should point to the current IPSEC Architecture
document, RFC 4301 !
BTW:
This apparently is a `viral` legacy issue -- RFC 2476 also
contained an outdated Ref., to the predecessor of RFC 2401 !
Errata ID: 97
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
(1) [contradiction in specification]
The last paragraph of Section 2, on page 6 of RFC 4410, says:
SRMP is intended for general use under applications that need its
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| services and may exist in parallel instances on the same host. The
UDP port is therefore established ad hoc from available application
ports; accordingly, it would not be appropriate to have a well-known
port for SRMP.
Contrary to that, the first paragraph of Section 4.7, on page 15,
says:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| Each host will have a single instance of SRMP supporting all of its
applications. Thus, the sender's source rate is the sum of the rates
of all the clients of the same multicast group.
What's true ? What's been intended ???
(2) [simple erratum: inconsistent spelling]
At the bottom of page 7, Section 3.2 says:
Receiver_Timestamp:
| 16 bits Echo of the Receiver_Time_Stamp field (in milliseconds)
of the receiver feedback message. If the sender has
time delay between receiving the feedback and echoing
the timestamp, it MUST adjust the Receiver_Timestamp
value to compensate.
To adjust with the diagram on top of page 7 and the remainder of the
text, 'Receiver_Time_Stamp' should be spelled out 'Receiver_Timestamp'
here as well.
Thus, the RFC should say:
Receiver_Timestamp:
| 16 bits Echo of the Receiver_Timestamp field (in milliseconds)
of the receiver feedback message. If the sender has
time delay between receiving the feedback and echoing
the timestamp, it MUST adjust the Receiver_Timestamp
value to compensate.
(3) [inconsistent message layout - danger of interoperability problems]
The diagram of the Bundle Header Format (Section 3.2, on page 7),
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |fb_nr | flag | bundle_SN |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| ... |
and the diagram of the Feedback Message Format (Section 3.3, on page 9),
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | fb_nr| flag | X_r |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
show a surprising inconsistency in the order of the (otherwise
comparable) words {Sender_ID, Receiver_ID, S/R_Timestamps} .
I suspect that this might give rise to implementation faults,
leading to interoperability problems.
It better would have been avoided from the beginning by using
the same order of the fields.
BTW: It strikes that in Section 3.2, the sequence of the field
explanations does not agree with the order in the diagram (as is
the case throughout the remainder of the RFC); instead, the
explanations of just those four fields is given in the order
of the diagram and explanation sequence in Section 3.3.
Therefore, the reader could be lead to the conjecture that the
diagram in Section 3.2 is in error and in fact should be aligned
with the diagram in Section 3.3.
(4) [simple erratum: word twister]
In Section 3.6, near the top of page 12, the RFC says:
Length:
16 bits Length of the payload data in octets (does not the
include header).
It should say:
Length:
| 16 bits Length of the payload data in octets (does not include
| the header).
(5) [simple errata: inconsistent terminology]
Contrary to the remainder of the RFC text, Section 3.7 uses the
field name "Sender Address". To avoid the unfortunate embedded
space character, and to align this section with the remainder
of the RFC, the term "Sender_ID" should be used.
Therefore:
a) the diagram on page 12,
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |111 | 00000 | reserved |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
| | Sender Address |
+--------------+--------------+--------------+--------------+
should be corrected to say:
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |111 | 00000 | reserved |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
| | Sender_ID |
+--------------+--------------+--------------+--------------+
b) the explanation (at the bottom of page 12),
| Sender_ID:
| The IP address of the sender of the message being NACKed.
should be corrected to say:
| Sender_ID:
| The ID of the sender of the message being NACKed.
See also item (6) below for the full rationale.
(6) [incomplete specification - IPv4-centric]
In Section 4.2, the second paragraph on page 14 says:
Also, the bundle length MUST NOT exceed LENGTH_MAX. If adding a new
SRMP message will produce a greater length, the SRMP daemon MUST
initialize a new bundle for the new SRMP messages, and the current
| bundle should be transmitted immediately. The recommended value for
| LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header
| lengths).
Similarly, the first paragraph of Section 4.6, on page 15, says:
TFMCC is designed for traffic with a fixed message size. The maximum
| bundle size (including header) for SRMP is set to a configurable
| maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header
| lengths). The bundle size will be used in a TCP throughput equation,
to get a desired source rate. However, in SRMP, the message size is
variable because:
Without mention, the marked phrases are strictly IPv4-centric;
they do not apply to the case of IPv6.
The latter scenario is not excluded in the text, and the phrase,
"IPv4 addresses may be used." in the description of all Sender_ID
and Receiver_ID fields supports the suspicion that IPv6 in fact
was intended to be supported.
Please supply improved wording for both text fragments.
(7) [simple erratum: grammar (singular/plural mismatch)]
The first paragraph of Section 5, on page 17, says:
SRMP operates in three distinct transmission modes in order to
deliver varying levels of reliability: Mode 0 for multicast data that
| does not require reliable transmission, Mode 1 for data that must be
received reliably by all members of a multicast group, and Mode 2 for
data that must be received reliably by a single dynamically
determined member of a multicast group.
It should say:
SRMP operates in three distinct transmission modes in order to
deliver varying levels of reliability: Mode 0 for multicast data that
| do not require reliable transmission, Mode 1 for data that must be
received reliably by all members of a multicast group, and Mode 2 for
data that must be received reliably by a single dynamically
determined member of a multicast group.
Rationale: "data" *is" plural.
Notes:
from pending
Errata ID: 96
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-03-06
Held for Document Update by: Robert Sparks
Informative References say:
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
It should say:
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J.,
Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
Notes:
Informative reference points to RFC 2543, but this has been outdated by RFC 3261.
RFC 4425 gives an Informative Reference [14] to the SIP
specification, used only once, in section 4.7; but the
citation in section 10.2 points to the far outdated RFC 2543
that has been superseded by RFC 3261 on Jul 2 2002.
Because this obsolescence has happened so long ago, I have
conjectured that it must have been ignored purposely following
subtle considerations, and it is not an editorial oversight.
Errata ID: 95
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14
Section 7.1 says:
Note that the restoration resources must be pre-computed, must be signaled, and may be selected a priori, but may not cross- connected. Thus, the restoration LSP is not able to carry any extra-traffic.
It should say:
Note that the restoration resources must be pre-computed, must be signaled, and may be selected a priori, but may not be cross- connected. Thus, the restoration LSP is not able to carry any extra-traffic.
Notes:
missing verb
from pending
Errata ID: 743
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14
Section 5 says:
Failure notification phase is used 1) to inform intermediate nodes that LSP(s)/span(s) failure has occurred and has been detected and 2) to inform the recovery deciding entities (which can correspond to any intermediate or end-point of the failed LSP/span) that the corresponding LSP/span is not available.
It should say:
| The failure notification phase is used 1) to inform intermediate nodes that LSP(s)/span(s) failure has occurred and has been detected and 2) to inform the recovery deciding entities (which can correspond to any intermediate or end-point of the failed LSP/span) that the corresponding LSP/span is not available.
Notes:
missing article
from pending
Errata ID: 745
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14
Section 6.3 says:
At the egress node, the normal traffic is selected | from either its working or one of the protection LSP/span. Unprotected extra traffic can be transported over the M protection | LSP/span whenever the protection LSPs/spans is not used to carry a normal traffic.
It should say:
At the egress node, the normal traffic is selected | from either its working or one of the protection LSPs/spans. Unprotected extra traffic can be transported over the M protection | LSPs/spans whenever the protection LSPs/spans is not used to carry a normal traffic.
Notes:
singular-->plural
from pending
Errata ID: 1834
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2009-08-20
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24
Section 4.6 says:
E. M:N (M, N > 1, N >= M) type: A set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes.
It should say:
E. M:N (M, N > 1, N >= M > 1) type: A set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes.
Notes:
M > 1 is not specified
[Adrian Farrel]
M > 1 was intended by the language "M, N > 1"
This has been confused by the othe use of a comma
Errata ID: 1835
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2009-08-20
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-24
Section 6.3 says:
6.3. M:N (M, N > 1, N >= M) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic.
It should say:
6.3. M:N (M, N > 1, N >= M > 1) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic.
Notes:
M > 1 is added
[Adrian Farrel]
M > 1 was intended by the language "M, N > 1"
This has been confused by the other use of a comma
Errata ID: 94
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14
(1) [missing articles]
In Section 4.1, the third paragraph on page 7 says:
In pre-OTN networks, a failure may be masked by intermediate O-E-O
based Optical Line System (OLS), preventing a Photonic Cross-Connect
(PXC) from detecting upstream failures. In such cases, failure
detection may be assisted by an out-of-band communication channel,
and failure condition may be reported to the PXC control plane. This
can be provided by using [RFC4209] extensions that deliver IP
message-based communication between the PXC and the OLS control
plane. [...]
It should say:
| In pre-OTN networks, a failure may be masked by an intermediate O-E-O
based Optical Line System (OLS), preventing a Photonic Cross-Connect
(PXC) from detecting upstream failures. In such cases, failure
detection may be assisted by an out-of-band communication channel,
| and a failure condition may be reported to the PXC control plane.
This can be provided by using [RFC4209] extensions that deliver IP
message-based communication between the PXC and the OLS control
plane. [...]
(2) [unexpected break]
Again on page 7, later on in the same paragraph as mentioned above,
the RFC says:
[...]. If the intermediate OLS supports electrical (digital)
mechanisms, using the LMP communication channel, these failure
| conditions are reported to
|
the PXC and subsequent recovery actions are performed as described in
Section 5. As such, from the control plane viewpoint, this mechanism
turns the OLS-PXC-composed system into a single logical entity, thus
having the same failure management mechanisms as any other O-E-O
capable device.
It should say:
[...]. If the intermediate OLS supports electrical (digital)
mechanisms, using the LMP communication channel, these failure
| conditions are reported to the PXC and subsequent recovery actions
are performed as described in Section 5. As such, from the control
plane viewpoint, this mechanism turns the OLS-PXC-composed system
into a single logical entity, thus having the same failure management
mechanisms as any other O-E-O capable device.
(3) [incomplete wording]
At the end of Section 4.1, in the last bullet, on page 8, the RFC says:
o with out-of-band communication between entities: entities are
physically separated, but an out-of-band communication channel is
provided between them (e.g., using [RFCF4204]).
It should say (according to the Verifier):
o with out-of-band communication between entities: entities are
physically separated, but an out-of-band communication channel is
| provided between them (e.g., using LMP [RFC4204]).
(4) [unexpected blank line]
In Section 5.5.1, the diagram for option '2. Overbooking', near the
bottom of page 22, suffers from an unexpected blank line.
The RFC says:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
It should say:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
(5) [typo: missing underscore]
In Section 7.2, the second-to-last paragraph on page 29 says:
In SONET/SDH environments, one typically considers the VT_SPE/LOVC
and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
uses the underlying STS_SPE/HOVC LSPs as links). [...]
It should say:
In SONET/SDH environments, one typically considers the VT_SPE/LOVC
| and STS_SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
uses the underlying STS_SPE/HOVC LSPs as links). [...]
(6) [singular-->plural]
In Section 8, the second-to-last paragraph on page 33 says:
[...]. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case of
| failure) while being non-scalable and consuming recovery resource
without enabling any extra-traffic.
^^
It should say:
[...]. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case of
| failure) while being non-scalable and consuming recovery resources
without enabling any extra-traffic.
(7) [singular-->plural]
The third paragraph of Section 8.2, on page 34, says:
[...]. Dynamic restoration enables on-demand
path computation based on the information received through failure
notification message, and as such, it is more robust with respect to
the failure scenario scope.
It should say (according to the Verifier):
[...]. Dynamic restoration enables on-demand
path computation based on the information received through failure
| notification message(s), and as such, it is more robust with respect to
the failure scenario scope.
(8) [singular-->plural]
At the bottom of page 35, Section 8.3 of RFC 4428 says:
[...]. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable of reserving an adequate amount of
resource to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures, etc.
It should say:
[...]. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable of reserving an adequate amount of
| resources to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures, etc.
(9) [punctuation: adjustment for 'logical quoting']
In Section 12.2, some Informative References, as found in the RFC,
do not conform to the RFC style guidelines regarding 'logical quoting'.
E.g., the RFC says, at the bottom of page 44:
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
| Architectures," IEEE Infocom 2002, New York City, June
2002.
^^
It should say:
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
| Architectures", IEEE Infocom 2002, New York City, June
2002.
Similar changes should be applied to the following entries on page 45:
[DEMEESTER]
[GLI]
[KODIALAM1]
[KODIALAM2]
[MANCHESTER]
[T1.105]
[WANG]
[G.707]
[G.709]
and on page 46:
[G.783]
[G.798]
[G.841]
[G.842]
[G.874]
Notes:
from pending
Errata ID: 1625
Status: Held for Document Update
Type: Editorial
Reported By: Shiang-Ming Huang
Date Reported: 2008-12-03
Held for Document Update by: Jari Arkko
Date Held: 2008-12-03
Section 2.1 says:
[RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated | (in 5.5.4) addresses. Addresses that are neither are said to be Preferred. Tentative addresses may not be used for communication, and Deprecated addresses should not be used for new communications. These address states may also be used by other standards documents, for example, Default Address Selection [RFC3484].
It should say:
[RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated | (in 5.5.4) addresses. Addresses that are neither Tentative nor Deprecated are said to be Preferred. Tentative addresses may not be used for communication, and Deprecated addresses should not be used for new communications. These address states may also be used by other standards documents, for example, Default Address Selection [RFC3484].
Errata ID: 93
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Pasi Eronen
Date Held: 2009-04-30
[editorial nits moved to errata ID 1770]
(7) Section 4.2.7 (page 22/23)
(7a) Item (1b) above applies, and plaintext vs. ciphertext is unclear.
The initial text and Figure 13 unfortunately do not properly make
the distinction between unencrypted (plaintext) and encrypted
(ciphertext) values and fields.
The presentation on page 22 needs clarification, according to the
note given on page 23:
The coverage of the encrypted data begins at InnerNextPload so that
the first payload's type is kept confidential. Thus, the number of
encrypted octets is PayloadLength - 4.
On page 22, the text and Figure 13,
| The KINK_ENCRYPT payload encapsulates other KINK payloads and is
| encrypted using the session key and the algorithm specified by its
etype. This payload MUST be the final one in the outer payload chain
| of the message. The KINK_ENCRYPT payload MUST be encrypted before
the final KINK checksum is applied.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| +---------------+---------------+---------------+---------------+
| | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED2 |
+---------------+---------------+---------------+---------------+
| Payload (variable) |
+---------------+---------------+---------------+---------------+
| Figure 13: KINK_ENCRYPT Payload
should say:
| The KINK_ENCRYPT payload encapsulates other KINK payloads and its
| value is encrypted using the session key and the algorithm specified
by its etype. This payload MUST be the final one in the outer
| payload chain of the message. The plaintext KINK_ENCRYPT payload
| value MUST be encrypted before the final KINK checksum is applied.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| | |
| ~ encrypted KINK_ENCRYPT Payload value (variable) ~
| | |
+---------------+---------------+---------------+---------------+
| Figure 13a: KINK_ENCRYPT Payload
(I have chosen the more descriptive filed name,
'encrypted KINK_ENCRYPT Payload value' over the more fuzzy term,
'encryption payload' used in the text on page 23.)
After the first bullet on page 23,
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section. This payload is the last one in a
message, and accordingly, the Next Payload field must be
KINK_DONE (0).
The following text and figure should be inserted:
o encrypted KINK_ENCRYPT Payload value -- This is the
encrypted form of the plaintext form of the KINK_ENCRYPT
Payload value in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED2 |
+---------------+---------------+---------------+---------------+
| KINK Payloads (variable) |
+---------------+---------------+---------------+---------------+
| Figure 13b: unencrypted KINK_ENCRYPT Payload value
Fields:
(7b) typo, and (7a) continued
The final paragraph of Section 4.2.7, on page 23, says:
vvvvvvvvvvvvvvvvvv
| The format of the encryption payload follows the normal Kerberos
semantics. Its content is the output of an encrypt function defined
in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters
such as encrypt function itself, specific-key, and initial state are
defined with the etype. [...]
itself and there may be some garbage data at the end of the decrypted
plaintext. A KINK implementation MUST be prepared to ignore such
padding after the last sub-payload inside the KINK_ENCRYPT payload.
[...]
It should say:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The format of the encrypted KINK_ENCRYPT Payload value follows the
normal Kerberos semantics. Its content is the output of an encrypt
function defined in the Encryption Algorithm Profile section of
| [KCRYPTO]. Parameters such as the encrypt function itself, specific-
key, and initial state are defined with the etype. [...]
Notes:
Items (1)..(7) have been revised on the author's comments received.
In particular, item (7) has been revised substantially to achieve
a selfconsistent presentation in accordance with the author's intent.
I propose to incorporate the above items (1)..(7) and (9) directly
into an RFC Errata Note.
Item (8), and perhaps item (7) as well, still needs judgement from
the RFC authors.
------------------------------------------------
ERRATA RESPONSE:
From: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)
Could someone verify 1a, 4b and 9b ?
from pending
Errata ID: 1770
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Pasi Eronen
Date Held: 2009-04-30
(1) Section 4.2.1 (page 17)
(1a) typo (word omission)
The final sentence in the 3rd paragraph of Section 4.2.1 says:
[...]. A
principal name is case sensitive, and "fqdn" part MUST be lowercase
as described in [KERBEROS].
It should say:
vvvvv
[...]. A
| principal name is case sensitive, and the "fqdn" part MUST be
lowercase as described in [KERBEROS].
(1b) see (0) above
The subsequent text, above Figure 7,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload has the following format:
should say:
vvvvvvvvvvvv
| This payload has the following format:
(2) Section 4.2.2 (page 18)
Like (1b) above, the text above Figure 8,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload has the following format:
should say:
vvvvvvvvvvvv
| This payload has the following format:
(3) Section 4.2.3 (page 19)
Like (1b) above, the text above Figure 9,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload has the following format:
should say:
vvvvvvvvvvvv
| This payload has the following format:
(4) Section 4.2.4 (page 20)
(4a) Like (1b) above, the text above Figure 10,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload has the following format:
should say:
vvvvvvvvvvvv
| This payload has the following format:
(4b) The second bullet of the subsequent explanations,
o PrincName -- The name of the principal that the initiator
wants to communicate with. It is assumed that the initiator
knows the responder's principal name (including the realm
| name) in the same way as the non-User-to-User case. The TGT
returned MUST NOT be an inter-realm TGT and its cname and
crealm MUST match the requested principal name, so that the
initiator can rendezvous with the responder at the responder's
realm.
should say (filling in a missing word):
o PrincName -- The name of the principal that the initiator
wants to communicate with. It is assumed that the initiator
knows the responder's principal name (including the realm
| name) in the same way as in the non-User-to-User case. The
TGT returned MUST NOT be an inter-realm TGT and its cname and
crealm MUST match the requested principal name, so that the
initiator can rendezvous with the responder at the responder's
realm.
(5) Section 4.2.5 (page 21)
Like (1b) above, the text above Figure 11,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload contains the TGT requested in a
previous KINK_TGT_REQ payload of a GETTGT command.
should say:
vvvvvvvvvvvv
| This payload contains the TGT requested in a previous KINK_TGT_REQ
payload of a GETTGT command.
(6) Section 4.2.6 (page 21)
Like (1b) above, the text above Figure 12,
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| The value field of this payload has the following format:
should say:
vvvvvvvvvvvv
| This payload has the following format:
[see errata ID 93 for item 7]
(8) Section 4.2.8
The text of this section twice, and redundantly, specifies
on page 23 :
[...]. The error code is in network order.
and on page 24 :
o ErrorCode -- One of the following values in the network byte
order:
[...]
This looks like a big exception. But in fact, that is the general
rule as set in the first sentence of Section 4, on page 13!
At best, the former sentence should be deleted, and the latter
bullet changed to say:
o ErrorCode -- One of the following values:
[...]
If it is preferred to not delete the former sentence and the latter
clause, at least the "the" in "in the network byte order" should be
deleted.
(9) further word omissions in running text
(9a) The first paragraph of Section 6.6, on page 32, says:
A GETTGT command is only used to carry a Kerberos TGT and is not
related to SA management; therefore, it contains only KINK_TGT_REQ
payload and does not contain any DOI-specific payload.
It should say:
A GETTGT command is only used to carry a Kerberos TGT and is not
| related to SA management; therefore, it contains only a KINK_TGT_REQ
payload and does not contain any DOI-specific payload.
(9b) The first paragraph of Section 7, on page 32, says:
KINK uses the same key derivation mechanisms defined in section 5.5
of [IKE], which is:
It should say:
vvvv
| KINK uses the same key derivation mechanisms as defined in section
5.5 of [IKE], which is:
Notes:
[split everything except item 7 away from errata ID 93]
(0) Rationale for most non-trivial issues listed below:
==============
The initial text of Section 4.2 (on page 16) says:
Immediately following the header, there is a list of
Type/Length/Value (TLV) payloads. There can be any number of
payloads following the header. Each payload MUST begin with a
payload header. Each payload header is built on the generic payload
header. Any data immediately follows the generic header. Payloads
are all implicitly aligned to 4-octet boundaries, though the payload
length field MUST accurately reflect the actual number of octets in
the payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+
Figure 6: Format of a KINK Payload
Fields:
[...]
To sum up: a KINK payload consists of a (generic) payload header
and the (payload) value field.
Unfortunately, the subsequent sub-sections 4.2.* inadvertently
seem to pretend that there exists another copy of the payload
header within the payload value, which certainly was not intended.
It was the intent of the authors to always show and describe the
full payloads in these sections.
Therefore, the repeated text stating to the contrary that it will
show the payload *value*, has to be changed.
I use change bars ('|' in column 1) and (occasionally) up/down
pointing marker lines to emphasize the location of textual issues
in the snippits from the RFC text and/or the proposed modified text.
Modified text has been adjusted according to RFC formatting policy.
Items (1)..(7) have been revised on the author's comments received.
In particular, item (7) has been revised substantially to achieve
a selfconsistent presentation in accordance with the author's intent.
I propose to incorporate the above items (1)..(7) and (9) directly
into an RFC Errata Note.
Item (8), and perhaps item (7) as well, still needs judgement from
the RFC authors.
------------------------------------------------
ERRATA RESPONSE:
From: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)
Could someone verify 1a, 4b and 9b ?
from pending
Errata ID: 898
Status: Verified
Type: Technical
Reported By: Kent Leung
Date Reported: 2007-04-11
In RFC 4433 paragraph 3.4, the extension is specified as skippable with type=139. However the extension is specified in the "Long Extension Format", which should be used for non-skippable extensions only according to RFC 3344 paragraph 1.10.
It should say:
The extension should be specified in the "Short Extension Format" which is used for skippable extensions in accordance to RFC 3344 paragraph 1.11.
Notes:
This problem was reported by László Molnár.
from pending
Errata ID: 92
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Section 5.3.1 says:
The following table summarizes the behavior of the Assigned HA, based
on the value of the destination IP address and Home Agent field of
the Registration Request.
Dest IP Addr HA field Processing at Assigned HA
------------ ------------ ----------------------------------
...
Table 1: Registration Request Handling at Assigned HA
It should say:
The following table summarizes the behavior of the Requested HA,
based on the value of the destination IP address and the Home Agent
Address field of the Registration Request.
Dest IP Addr HA field Processing at Requested HA
------------ ------------ ----------------------------------
...
Table 1: Registration Request Handling at the Requested HA
Notes:
According to, e.g., the explanations in bullet 1 of Section 5.3,
"Assigned HA" is not correct; the term to be used is "Requested HA";
it will eventually become the "Assigned HA" if the conditions
mentioned are met, but the behaviour described strictly applies
to the "Requested HA" role.
from pending
Errata ID: 91
Status: Verified
Type: Editorial
Reported By: Bernard Aboba
Date Reported: 2007-01-01
Section 2.1.1 says:
If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) in the ARP Reply is matched against the target hardware address field (ar$tpa) in the ARP Request, and the IPv4 address in the sender protocol address field (ar$spa) of the ARP Reply is matched against the target protocol address field (ar$tpa) in the ARP Request. If a match is found, then the host continues to use that IPv4 address, subject to the lease re- acquisition and expiration behavior described in Section 4.4.5 of the DHCP specification [RFC2131].
It should say:
If a valid ARP Reply is received, where:
(a) the address in the sender hardware address field (ar$sha) is
the MAC address of the node being tested for, and
(b) the address in the sender protocol address field (ar$spa) is
the IPv4 address of the node being tested for,
then the host concludes that its candidate IPv4 address is valid
for this network and may continue to be used, subject to the lease
re-acquisition and expiration behavior described in Section 4.4.5
of the DHCP specification [RFC2131].
Errata ID: 90
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Keith McCloghrie
Date Verified: 2006-07-10
The DESCRIPTION clause of the t11NsRegClassOfSvc OBJECT-TYPE,on page 16/17, says:
"The class of service indicator. This object is an
array of bits that contain a bit map of the classes of
service supported by the associated port. If a bit in
this object is 1, it indicates that the class of
service is supported by the associated port. When a
bit is set to 0, it indicates that no class of service
is supported by this Nx_Port.
If this object has not been not registered for a port,
then the instance for that port is not instantiated."
It should say:
"The class of service indicator. This object is an
array of bits that contain a bit map of the classes of
service supported by the associated port. If a bit in
this object is 1, it indicates that the class of
service is supported by the associated port. When all
bits are set to 0, it indicates that no class of
service is supported by this Nx_Port.
If this object has not been registered for a port,
then the instance for that port is not instantiated."
Errata ID: 89
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Dan Romascanu
The DESCRIPTION clause for the t11FamAutoReconfigure OBJECT-TYPE macro invocation says:
If value of this object is 'true', the switch will
send an RCF (ReConfigureFabric) to rebuild the
Fabric.
It should say:
If the value of this object is 'true', the switch will
send an RCF (ReConfigureFabric) to rebuild the
Fabric.
Errata ID: 88
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-04-19
(1) text omission ???
I suspect that something went wrong in the publication process
for RFC 4443, leading to significant text omission.
Symptoms:
o Text on top of page 5 apparently *continues* specifications
that are not in the published text;
o Appendix A contains the change item:
- Added specification that all ICMP error messages shall have exactly
32 bits of type-specific data, so that receivers can reliably find
the embedded invoking packet even when they don't recognize the
ICMP message Type.
I could not find any text in the body of the RFC corresponding
to this statement.
Therefore, I suspect that general specifications for ICMPv6 error
messages have been dropped inadvertently from the end of Section
2.1, at the bottom of page 4 in the published text, or that even
a subsection dealing with the peculiar requirements for ICMPv6
error messages has been dropped, just leaving in the published text
the single sentence at top of page 5.
I expect the missing text to depict the general structure of the
Message Body of ICMPv6 error messages with all related explanations,
according to the above mentioned change note.
Appendix A also states:
- Removed the general packet format from Section 2.1. It refers to
Sections 3 and 4 for packet formats now.
This is not literally true. The general format *is* in Section 2.1.
But in fact, it would be logical to have the (missing) specifications
for error messages -- including the 4 lines of test on top of page 5 --
incorporated into (the start of) Section 3 (*before* the heading for
Section 3.1.) instead of the end of Section 2.1.
(2) possible textual improvement
in the lower third of page 3, Section 2.1 says:
The code field depends on the message type. It is used to create an
additional level of message granularity.
It should perhaps better say:
The code field depends on the message type. It is used to create an
additional level of message type granularity.
^^^^^^
(3) reference to old IPsec Architecture document
Section 5.1, at the bottom of page 15, has been updated to point
to the new IPsec Architecture document, RFC 4301, via the reference
tag [SEC-ARCH]. But immediately below, in the first paragraph of
Section 5.2, on top of page 16, the RFC text says:
ICMP messages may be subject to various attacks. A complete
discussion can be found in the IP Security Architecture [IPv6-SA].
[...]
It remains unclear why the reference is made to the previous IPsec
Architecture document, RFC 2401, in this case.
In fact, RFC 4301 has simplified ICMP handling by the introduction
of ICMP Type+Code as a Traffic Selector for the SPD, and therefore
contains restructured text on ICMP message processing.
Nevertheless, as far as I can see, RFC 4301 has not removed
significant ICMP security related material from RFC 2401.
Thus, IMHO there is no reason to explicitely refer to the obsoleted
specification, RFC 2401 [IPv6-SA], instead of the current one,
RFC 4301 [SEC-ARCH].
(4) more issues with references
According to Appendix A, RFC 4443 has
- Separated References into Normative and Informative.
The latest RFC Authoring Internet draft revisions
(cf. draft-rfc-editor-rfc2223bis-xx
and draft-hoffman-rfc-author-guide-01)
all have included the definition:
Normative references specify documents that must be read
to understand or implement the technology in the document,
or whose technology must be present for the technology in
the new RFC to work. [...] an informative reference might
provide background or historical information to the reader.
[...]
The separation performed does not match this definition.
(4a)
RFC 4443 refers to RFC 792 and RFC 1122 to point out the analogy
to ICMP[v4], but it is a self-contained specification, and ICMPv6
does not rely on the implementation of ICMP[v4] -- IPv6 only nodes
are possible and even expected for the (far?) future.
Therefore, the references [RFC-792] and [RFC-1122] should better
have been placed into section 7.2, Informative References, instead
of Section 7.1, Normative References.
(4b)
RFC 4443 also lists in Section 7.1, Normative References, the
reference to its obsoleted predecessor, RFC 2463 [RFC-2463].
This is a fatal lock on the Standards Track for RFC 4443:
RFC 4443 can *not* be advanced above the level of RFC 2463,
if the written procedures are taken literally !
(Also, RFC 4443 contains all material from RFC 2463, and thus
RFC 2463 is not needed to understand and/or implement RFC 4443.)
Therefore, all references to obsoleted documents should be
named Informative, and in the case of RFC 4443, [RFC-2463]
should have been moved into Section 7.2 as well.
(4c)
The old IPv6 Addressing Architecture document, RFC 3513, has been
replaced by RFC 4291, published more than 5 weeks before RFC 4443.
Therefore, in Section 7.2 of RFC 4443, the Informative Reference
[IPv6-ADDR] should be have been changed to point to RFC 4291
instead of the obsolete RFC 3513.
(4d)
When following my recommendations in item (3) above, the
Informative Reference [IPv6-SA] is not needed any more;
its role has been taken over by the Reference [SEC-ARCH].
(5) misleading change note
The second bulleted item in Appendix A,
- Corrected typos in Section 2.4, where references to sub-bullet e.2
were supposed to be references to e.3.
apparently is not correct; it must have been introduced in the
draft history, referring to a change in the draft.
The references in RFC 2463 to sub-bullet (e.2) were correct.
RFC 4443 has inserted a new item (e.2) into the list, incrementing
the numbers of the previous sub-bullet (e.2) and all subsequent
sub-bullets, thus making it necessary to increment the references.
Perhaps, the latter had not been done in an early draft revision,
and has then been corrected in a later one.
Thus, the above change note should not have been included in RFC 4443.
Notes:
from pending
Errata ID: 1918
Status: Reported
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-19
Section 7.2 says:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4203, December 2005.
It should say:
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
Errata ID: 1926
Status: Reported
Type: Editorial
Reported By: Thorsten Ulbricht
Date Reported: 2009-10-23
Section 7.2 says:
[IPv6-ADDR] Hinden, R. and S. Deering, "Intpernet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
It should say:
[IPv6-ADDR] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
Errata ID: 87
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
(1) erratum: disfigured object name
In the DESCRIPTION clause of the isisCircLevelType OBJECT-TYPE macro
instance, on mid-page 32, the sentence
[...]. Thus, if the
isisSysTpe is level2 and the isisCircLevelType
for a circuit is level1, the circuit will not send
or receive IS-IS packets. [...]
should say:
vvvvvvvvv
[...]. Thus, if the
| isisSysLevelType is level2 and the isisCircLevelType
for a circuit is level1, the circuit will not send
or receive IS-IS packets. [...]
(2) issue: non-use of appropriate TC (?)
The isisCircLevelIDOctet OBJECT-TYPE macro instance, on page 36,
contains the SYNTAX clause:
isisCircLevelIDOctet OBJECT-TYPE
SYNTAX Unsigned32(0..255)
After comparison with similar context in the RFC, I suspect that it
would be appropriate to use the IsisUnsigned8TC TEXTUAL-CONVENTION
in this place as well:
isisCircLevelIDOctet OBJECT-TYPE
| SYNTAX IsisUnsigned8TC
(3) issue: unexpected indexing
As described in the SMIv2 RFCs, RFC 4444 extends various tables
by "reusing" of common index objects. Surprisingly, there are
two deviations from this practice I cannot detect any reason for:
(3.1)
The isisSystemCounterTable (page 39 ff.) is indexed by the fresh,
independant index object, "isisSysStatLevel", while IMHO it would
have been logical to use the already defined index object of the
isisSysLevelTable (page 25 ff.), "isisSysLevelIndex", for this
purpose as well.
(3.2)
The isisPacketCounterTable (page 46 ff.) is indexed in the 2nd place
by the fresh, independant index object, "isisPacketCountLevel",
while IMHO it would have been logical to use the full index structure
of the isisCircLevelTable (page 34 ff.), including the index object,
"isisCircLevelIndex" in the second place, for this purpose as well.
(4) issue: many unusual UNITS clauses
The UNITS clause is intended a to contains a textual definition of
the units associated with the object (according to RFC 2578, Section
7.2). Network management systems usually provide for narrow label
space in their display screens - expecting usual [physical] unit
names like "bytes", "kilobytes", "seconds", "centiseconds", "Mbps",
"packets", "frames", "cells", "percent", etc.
For most packet counters, RFC 4444 specifies very unusual, lengthy
texts in the UNITS clauses that duplicate the text given in the
respective DESCRIPTION clauses.
This style should better have been avoided and might be noted as
an issue for any potential future update to RFC 4444.
For example, the isisPacketCountCSNP OBJECT-TYPE declaration, on
page 49 :
isisPacketCountCSNP OBJECT-TYPE
SYNTAX Counter32
| UNITS "Number of IS-IS CSNP frames seen in this direction at
| this level"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IS-IS CSNPs seen in this
direction at this level."
REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
::= { isisPacketCounterEntry 7 }
should perhaps better say:
isisPacketCountCSNP OBJECT-TYPE
SYNTAX Counter32
| UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IS-IS CSNPs seen in this
direction at this level."
REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
::= { isisPacketCounterEntry 7 }
(5) errata(?): overly restrictive RowStatus object descriptions
Some tables with conceptual rows that can be dynamically added
or deleted, contain a control object with SYNTAX RowStatus
and other control objects, e.g. with SYNTAX IsisAdminState.
I expect that the latter objects have been intended to control
the activity of "live" table rows, without the need to deactivate
these rows via the RowStatus object before setting the AdminState
to "on" or "off", so much the more the support for the
'notInServcie' state of the RowStatus objects is explicitely
"not required". Therefore, I strongly suspect that some RowStatus
object DESCRIPTION clauses have unintentionally been worded overly
restrictive and should been corrected to allow AdminStatus changes.
Some other such clauses contain statements that are void due to the
lack of accessible objects in those tables they could be applied to.
I have identified the following instances of these issues:
(5.1)
The DESCRIPTION clause of the isisManAreaAddrExistState OBJECT-TYPE
macro instance, on page 18, says:
DESCRIPTION
"The state of the isisManAreaAddrEntry. If the
isisSysAdminState for this Intermediate System is 'on' and
an attempt is made to set this object to the value
'destroy' or 'notInService' when this is the only
isisManAreaAddrEntry in state 'active' for this
Intermediate System should return inconsistentValue.
|
| A row entry cannot be modified when the value of this
| object is 'active'."
The last sentence is void, because the conceptual table rows of the
IsisManAreaAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisManAreaAddrExistState.
Therefore, this clause should be shortened to say:
DESCRIPTION
"The state of the isisManAreaAddrEntry. If the
isisSysAdminState for this Intermediate System is 'on' and
an attempt is made to set this object to the value
'destroy' or 'notInService' when this is the only
isisManAreaAddrEntry in state 'active' for this
Intermediate System should return inconsistentValue."
(5.2)
The DESCRIPTION clause of the isisRedistributeAddrExistState
OBJECT-TYPE macro instance, on pp. 23/24, says:
DESCRIPTION
"The existence state of this summary address. Support
<page break>
for createAndWait and notInService is not required.
|
| A row entry cannot be modified when the value of this
| object is 'active'."
The last sentence is void, because the conceptual table rows of the
IsisRedistributeAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisRedistributeAddrExistState.
Therefore, this clause should be shortened to say:
DESCRIPTION
"The existence state of this summary address. Support
| for 'createAndWait' and 'notInService' is not required."
(5.3)
The DESCRIPTION clause of the isisCircExistState OBJECT-TYPE macro
instance, on page 31, says:
DESCRIPTION
"The existence state of this circuit. Setting the state
to 'notInService' halts the generation and processing of
IS-IS protocol PDUs on this circuit. Setting the state
to destroy will also erase any configuration associated
with the circuit. Support for 'createAndWait' and
'notInService' is not required.
| A row entry cannot be modified when the value of this
| object is 'active'."
It should perhaps instead say:
DESCRIPTION
"The existence state of this circuit. Setting the state
to 'notInService' halts the generation and processing of
IS-IS protocol PDUs on this circuit. Setting the state
to destroy will also erase any configuration associated
with the circuit. Support for 'createAndWait' and
'notInService' is not required.
| Any other accessible object in this table row, except
| isisCircAdminState, cannot be modified when the value
| of this object is 'active'."
(5.4)
The DESCRIPTION clause of the isisRAExistState OBJECT-TYPE macro
instance, on page 58, says:
DESCRIPTION
"The existence state of this Reachable Address. This
object follows the ManualOrAutomatic behaviors. Support
for 'createAndWait' and 'notInService' is not required.
| A row entry cannot be modified when the value of this
| object is 'active'."
It should perhaps instead say:
DESCRIPTION
"The existence state of this Reachable Address. This
object follows the ManualOrAutomatic behaviors. Support
for 'createAndWait' and 'notInService' is not required.
| Any other accessible object in this table row, except
| isisRAAdminState, cannot be modified when the value
| of this object is 'active'."
(5.5)
The DESCRIPTION clause of the isisIPRAExistState OBJECT-TYPE macro
instance, on page 65, says:
DESCRIPTION
"The state of this IP Reachable Address. This object
follows the ExistenceState and ManualOrAutomatic
behaviors. Support for 'createAndWait' and
'notInService' is not required.
| A row entry cannot be modified when the value of this
| object is 'active'."
It should perhaps instead say:
DESCRIPTION
"The state of this IP Reachable Address. This object
follows the ExistenceState and ManualOrAutomatic
behaviors. Support for 'createAndWait' and
'notInService' is not required.
| Any other accessible object in this table row, except
| isisIPRAAdminState, cannot be modified when the value
| of this object is 'active'."
(6) erratum (typo)
The DESCRIPTON clause of the isisRASNPAMask OBJECT-TYPE declaration,
on page 61, says:
DESCRIPTION
"A bit mask with 1 bit indicating the positions in the
effective destination address from which embedded SNPA
information is to be extracted. [...]
It should say:
vvv
DESCRIPTION
| "A bit mask with 1 bits indicating the positions in the
effective destination address from which embedded SNPA
information is to be extracted. [...]
(7) erratum: disfigured object names
The last paragraph on page 62, within the DESCRIPTION clause of the
isisIPRAEntry OBJECT-TYPE declaration says:
Implementers need to be aware that if the total number
of elements (octets or sub-identifiers) in
isisIPRADestr, isisIPRADestPrefixLen, and
isisIPRANextHopIndex is too great, then OIDs of column
instances in this table will have more than 128
subidentifiers and cannot be accessed using SNMPv1,
<page break>
[...]
It should perhaps say:
Implementers need to be aware that if the total number
of elements (octets or sub-identifiers) in
| isisIPRADestType, isisIPRADest, isisIPRADestPrefixLen,
and isisIPRANextHopIndex is too great, then OIDs of
column instances in this table will have more than 128
subidentifiers and cannot be accessed using SNMPv1,
[...]
(8) issue: on-the-wire inefficiency in notifications
While admittedly the indexing structure of the MIB tables,
and the resulting lack of suitable accessible objects, apparently has
forced the introduction of the unusual and unusually large collection
of special objects with 'MAX-ACCESS accessible-for-notify'
(on pp. 71..74), some redundancies and inefficiencies in the
object groupings for notifications remain. Repeatedly, the
number of objects could have been reduced by including properly
indexed objects into the notifications object groups instead of
separate "special" objects. But this might have been considered
acceptable for the sake of a consistent object grouping style.
But there is one redundancy that could easily have been avoided.
The isisDatabaseOverload NOTIFICATION-TYPE declaration, on page 74,
isisDatabaseOverload NOTIFICATION-TYPE
OBJECTS {
isisNotificationSysLevelIndex,
isisSysLevelState
}
includes the object, "isisSysLevelState", that already carries
the required SysLevelIndex in the index part of its OID, because
it is contained in the isisSysLevelTable.
Therefore, without any loss of information for the receiver of the
notification, this declaration could have been simplified to specify:
isisDatabaseOverload NOTIFICATION-TYPE
OBJECTS {
isisSysLevelState
}
Notes:
All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.
I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.
Naturally, items (3) and (8) cannot be addressed any more
"after the fact" (i.e. publication of the RFC), and item (4)
should be addressed in a future update.
from pending
Errata ID: 996
Status: Verified
Type: Technical
Reported By: Danny McPherson
Date Reported: 2007-10-08
Verifier Name: Mark Townsley
Date Verified: 2007-10-08
Section 3.2 says:
0x0008 SONET/SDH Circuit Emulation Service Over
MPLS [CEP]
...
0x0010 SONET/SDH Circuit Emulation over Packet [CEP]
It should say:
0x0008 SONET/SDH Circuit Emulation Service Over
MPLS Encapsulation [CEM]
...
0x0010 SONET/SDH Circuit Emulation over Packet
[RFC4842]
Notes:
The 0x0008 value should not have been listed as
allocated to [CEP], now [RFC 4842], only the 0x0010 value is
provided for [CEP]. The 0x0008 value should be associated
with "SONET/SDH Circuit Emulation Service Over MPLS
Encapsulation [CEM]", and a corresponding informative
reference for [CEM] provided.
The IANA PW Type registry has been updated to correct this
error.
Errata ID: 938
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Edited by: Stewart Bryant
Date Edited: 2012-02-07
(3) clarification ( wrong term ?? )
Section 5.2, at the bottom of page 9, says:
- Group ID
An arbitrary 32-bit value that represents a group of PWs that is
used to create groups in the PW space. The group ID is intended
to be used as a port index, or a virtual tunnel index. To
simplify configuration, a particular PW ID at ingress could be
part of the virtual tunnel for transport to the egress router.
I suspect (but I am not 100% sure) that "PW ID" should in fact be
"PW Group ID", i.e., that this text should say:
- Group ID
An arbitrary 32-bit value that represents a group of PWs that is
used to create groups in the PW space. The group ID is intended
to be used as a port index, or a virtual tunnel index. To
| simplify configuration, a particular PW Group ID at ingress could
be part of the virtual tunnel for transport to the egress router.
Please comment.
(4) clarifications
a) The title of Section 5.3.2,
5.3.2. Encoding the Generalized ID FEC Element
for the sake of consistency should better say:
5.3.2. Encoding the Generalized PWid FEC Element
b) Within Section 5.3.2, the 2nd-to-last paragraph on page 13 says:
The PW information length field contains the length of the SAII,
TAII, and AGI, combined in octets. If this value is 0, then it
| references all PWs using the specified grouping ID. In this case,
there are no other FEC element fields (AGI, SAII, etc.) present, nor
any interface parameters TLVs.
To make the context more clear, it might preferrably be amended to say:
The PW information length field contains the length of the SAII,
TAII, and AGI, combined in octets. If this value is 0, then it
| references all PWs using the grouping ID (specifed in the PW grouping
| ID TLV). In this case, there are no other FEC element fields (AGI,
SAII, etc.) present, nor any interface parameters TLVs.
(5) consistency of terms
The headline of Section 5.3.2.2,
5.3.2.2. PW Grouping TLV
should better say, for terminological consistency:
5.3.2.2. PW Grouping ID TLV
Notes:
from pending
Errata ID: 3111
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07
(9) terminology a) The first paragraph of Section 6.3, on page 22, says: As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to withdraw all PW labels associated with a particular PW group. [...] It should say: As mentioned above, the Group ID field of the PWid FEC element, or | the PW Grouping ID TLV used with the Generalized PWid FEC element, can be used to withdraw all PW labels associated with a particular PW group. [...] b) The second paragraph of Section 6.3, on top of page 23, says: If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Grouping ID TLV is included, the Interface Parameters TLV is not present, and the Label TLV is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all PEs implementing this design are REQUIRED to accept such withdrawn message but are not required to send it. Note that the PW Grouping ID TLV only applies to PWs using the Generalized ID FEC element, while the Group ID only applies to PWid FEC element. It should say: | If the Generalized PWid FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Grouping ID TLV is included, the Interface Parameters TLV is not present, and the Label TLV is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all PEs implementing this design are REQUIRED to accept such withdrawn message but are not required to send it. Note that the PW Grouping | ID TLV only applies to PWs using the Generalized PWid FEC element, while the Group ID only applies to PWid FEC element.
Notes:
from pending
--VERIFIER NOTES--
The terminology in the RFC is correct.
It is the "generalized PW FEC Element" and not the "generalized PWid FEC element"
Errata ID: 86
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Abstract says:
It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents.
It should say:
It is also possible to use pseudowires to | provide low-rate Time Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the | pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents.
Notes:
use of articles
from pending
Errata ID: 3115
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07
(2) wrong term(s) used in table(s) Within Section 5.1 of RFC 4447, on page 8, the first 2 tables say: This document specifies the following new TLVs to be used with LDP: TLV Specified in Section Defined for Message =================================================================== PW Status TLV 5.4.2 Notification PW Interface Parameters TLV 5.3.2.1 FEC PW Grouping ID TLV 5.3.2.2 FEC Additionally, the following new FEC element types are defined: FEC Element Type Specified in Section Defined for Message =================================================================== 0x80 5.2 FEC 0x81 5.3 FEC Apparently, "FEC" is not appropriate in the last column of the first table, and "Defined for Message" makes no sense in the second table, where only "FEC" appears, as "FEC" is not an LDP message, it is a TLV. Perhaps, the latter column is dispensable, in favor of a new column showing the name of the FEC element. Hence, the text perhaps should better say, e.g.: TLV Specified in Section Defined for Message =================================================================== PW Status TLV 5.4.2 Notification | PW Interface Parameters TLV 5.3.2.1 with FEC TLV | PW Grouping ID TLV 5.3.2.2 with FEC TLV Additionally, the following new FEC element types are defined: | FEC Element Type FEC Element Name Specified in Section =================================================================== | 0x80 PWid 5.2 | 0x81 Generalized PWid 5.3
Notes:
The editors should look at this if there is an update.
The table is a quick index to information about a specific FEC and likely will be removed in a future version of this RFC.
Errata ID: 3114
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07
(6) message diagram incomplete
After consideration of the RFC text, I strongly suspect that the
message diagram in Section 5.4.2, at the bottom of page 17,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC TLV or Generalized ID FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
in fact should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC TLV with PWId or Generalized PWId FEC Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PW Grouping ID TLV |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rationale:
a) using defined terms verbatim
b) final TLV added: PW Grouping ID TLV
Notes:
The editors should consider this in an future revision, but as the PW Grouping ID TLV is optional it could be addressed in the diagram or with a note.
Errata ID: 3112
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07
(8) typo (spurious word)
The second-to-last paragraph of Section 6.2, on page 22, says:
[...]. If one endpoint prefers to use the
control word but the other does not, the one that prefers not to use
| it is has no extra protocol to execute; it just waits for a Label
Mapping message that has c=0.
It should say:
[...]. If one endpoint prefers to use the
control word but the other does not, the one that prefers not to use
| it has no extra protocol to execute; it just waits for a Label
Mapping message that has c=0.
Notes:
from pending
Errata ID: 1530
Status: Held for Document Update
Type: Editorial
Reported By: Vishwas Manral
Date Reported: 2008-09-29
Held for Document Update by: Stewart Bryant
Section 3 says:
This document specifies all the procedures necessary to set up and
maintain the pseudowires needed to support "unswitched" point-to-
point services, where each end of the pseudowire is provisioned
with the identify of the other endpoint.
^^
It should say:
This document specifies all the procedures necessary to set up and
maintain the pseudowires needed to support "unswitched" point-to-
point services, where each end of the pseudowire is provisioned
with the identity of the other endpoint.
^^
Notes:
None
Errata ID: 3113
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07
(7) clarifications, terms and wording Still in Section 5.4.2, the 2nd and 3rd paragraph on page 18 say: The PW FEC TLV SHOULD not include the interface parameter sub-TLVs, as they are ignored in the context of this message. When a PE's attachment circuit encounters an error, use of the PW Notification Message allows the PE to send a single "wild card" status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. This status message contains either the PW FEC TLV with only the group ID set, or else it contains the Generalized FEC TLV with only the PW Grouping ID TLV. As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to send a status notification for all arbitrary sets of PWs. [...] This text should better say: | The PWid FEC element SHOULD NOT include the interface parameter sub-TLVs, as they are ignored in the context of this message. When a PE's attachment circuit encounters an error, use of the PW Notification Message allows the PE to send a single "wild card" | status message, using a PWid FEC element with only the group ID set, to denote this change in status for all affected PW connections. | This status message contains either a FEC TLV with a PWid FEC element | with only the group ID set, or else it contains a FEC TLV with a | Generalized PWid FEC element together with only the PW Grouping ID TLV. As mentioned above, the Group ID field of the PWid FEC element, or | the PW Grouping ID TLV used with the Generalized PWid FEC element, can be used to send a status notification for all arbitrary sets of PWs. [...]
Notes:
from pending
--VERIFIER NOTES--
The terminology was correct at the time of writing
Errata ID: 85
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-25
Held for Document Update by: Stewart Bryant
1) a subtle typo
Section 4.5 of RFC 4448, on top of page 12, says:
The Ethernet PW management model follows the general PW management
model defined in [RFC3985] and [PWE3-MIB]. Many common PW management
facilities are provided here, with no additional Ethernet specifics
necessary. Ethernet-specific parameters are defined in an additional
MIB module, [PW-MIB].
It should say, replacing "here" by "there":
The Ethernet PW management model follows the general PW management
model defined in [RFC3985] and [PWE3-MIB]. Many common PW management
| facilities are provided there, with no additional Ethernet specifics
necessary. Ethernet-specific parameters are defined in an additional
MIB module, [PW-MIB].
(2) terminological issue / violation of reference model
Section 4.4.1 of RFC 4448, on pp. 9/10, says:
--- snip ---
When the PE receives an Ethernet frame, and the frame has a VLAN tag,
we can distinguish two cases:
1. The tag is service-delimiting. This means that the tag was
placed on the frame by some piece of service provider-operated
equipment, and the tag is used by the service provider to
distinguish the traffic. For example, LANs from different
customers might be attached to the same service provider
switch, which applies VLAN tags to distinguish one customer's
traffic from another's, and then forwards the frames to the PE.
2. The tag is not service-delimiting. This means that the tag was
placed in the frame by a piece of customer equipment, and is
not meaningful to the PE.
Whether or not the tag is service-delimiting is determined by local
configuration on the PE.
--- snip ---
IMHO, this is a very unfortunate explanation.
a) The term, "service delimiting", apparently here is defined
by the origin of the tag, not by its function.
I do not believe that this is the appropriate way to deal with;
later on in RFC 4448, it (reasonably) seems to be permitted
that a service-delimiting tag has been provided by a CE device!
b) The situation described in bullet 1), with a provider owned
switch, removes the PW terminating entity from the provider
*edge*, turning it from a "PE" device into a "P" device,
which is highly inconsistent with the service model developed
in Section 1 of RFC 4448, and leads to a clash in terminology.
To stay within that model, the "coloring" function described
in bullet 1) must conceptionally be performed by the NSP
function *within* the (PW terminating) PE device. (And it might
as well be performed in customer equipment, i.e. at the CE.)
Perhaps, the above text should be improved.
I'll try at a first proposal:
--- snip ---
When the PE receives an Ethernet frame, and the frame has a VLAN tag,
we can distinguish two cases:
1. The tag is service-delimiting.
This means that the tag was introduced for the single purpose
of identifying the frame for the PW service, e.g., to select a
specific PW for transmission of the frame. A service-
delimiting tag may have been added on the CE side or in the
(conceptual) NSP function of the PE edge.
Ordinarily, any service-delimiting tag will not be transmitted
over the PW, i.e., it will be removed before PW encapsulation.
2. The tag is not service-delimiting. This means that the tag is
not meaningful to the PW endpoints and must be transmitted over
the PW.
Such tag usually was placed in the frame by a piece of customer
equipment, but it might as well be added or modified by the NSP
function of the PW terminating PE device.
Whether or not the tag is service-delimiting is determined by local
configuration on the PE.
--- snip ---
Notes:
from pending
Errata ID: 820
Status: Reported
Type: Editorial
Reported By: Marc Blanche
Date Reported: 2007-01-09
The title of RFC 4449 is: Securing Mobile IPv6 Route Optimization Using a Static Shared Key However, the pages title is: RFC 4449 Shared Data for Precomputable Kbm June 2006
It should say:
[not submitted]
Notes:
They differ sufficiently enough that a reader think that he is
not reading the right document!
from pending
Errata ID: 776
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Eliot Lear
(1)
Near the top of page 3, section 3 of RFC 4450 states the
reasons for removal from the list -- i.e. *not* moving
to HISTORIC state:
o RFC 1584 -- an expected future dependency;
o RFC 1755 -- believed to be actively in use.
Nevertheless, these two RFCs have been moved to HISTORIC
status along with the publication of RFC 4450, as can be
seen in rfcxx00.txt .
This is quite surprising. (Perhaps, you know what happened.)
Preferrably, the final RFC text would better have been
coordinated with the actual Standards Actions performed --
for example, by addition of an IESG statement explaining the
deviation from the text.
(2)
Due to the 'numeric limitation' applied (restriction to RFCs
with numbers in the range ~700...2000) there are now a couple
of RFCs that have lost their 'normative background'.
For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
2456, 2457, and 2582) more or less depend on the now deprecated
basic SNA node MIBs, RFCs (1665->)1666 and 1747. [ "xx->yy"
is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
Arguably, in this case, these dependant RFCs might be considered
candidates for a move to HISTORIC as well.
But there certainly are other cases as well (I have not yet
checked all the details).
It therefore should perhaps be considered to repeat the
RFC 4450 'experiment' with an extended numeric range of RFCs,
e.g. up to RFC 2500.
(3)
On the other hand, the restriction to Standards Track documents
has other undesired implications:
a) In the past, usually at least an Experimental RFC has been
published as a first try for a new protocol (or an Informational
RFC, in the case of a third-party protocol), before a Standards
Track version has been developed. Unfortunately, in this process
it obviously has been avoided very often to formally OBSOLETE
the predecessor RFC[s] when the Standards Track version has been
published. (Similar undue 'politeness' can be observed, e.g.,
on the transition path of MIBs from SMIv1 to SMIv2.)
Caused by RFC 4450 we now have non-deprecated RFCs predating
RFCs moved to HISTORIC state.
(The example instances I've been aware of at first glance, though
still being listed as EXPERIMENTAL in the RFC index, fortunately
already had been removed in the past from the 'Experimental RFCs'
Section of rfcxx00.txt .)
It would be very useful, for clarity, to move these RFCs to
HISTORIC status as well.
b) There are 'companion documents' to Standards Track RFCs that
have been published as Informational RFCs for various (legitimate)
reasons. These RFCs are outdated with their respective related
specifications, and as such, for clarity, should better be moved
to HISTORIC status as well.
For example, IMHO the following Informational and Experimental RFCs,
being closely related to RFCs that now have been deprecated, should
be considered candidates for deprecation (being made HISTORIC) as
well, for clarity, consistency, and/or historical context:
o RFC 1477 (IDPR Introduction);
o RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
o RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
o RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
o RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
of which (RFCs 1552 and 1553) have been made HISTORIC;
o RFC 1791 (TCP+UDP over IPX); \ both still in
o RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !
o RFC 1834 (WHOIS++ Introduction);
o RFC 1875 (UNINETT PCA Policy) -- based on PEM.
It might therefore perhaps be useful to perform a RFC 4450 like
'experiment' for Informational and Experimental RFCs as well.
(4)
The restriction in the RFC 4450 effort on Proposed Standards
detracts from the fact that there are [Full] Standard RFCs as
well which are clearly outdated, or of questionable quality and/or
precision.
My personal (incomplete) hot list of candidates comprises:
STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
(Other legacy Standards doubtlessly should be updated, e.g.
STDs 5, 7, 13.)
Note: In particular the situation with STDs 16+17 is annoying.
Replacements are established, but vendors do not switch
to SMIv2 and the newer MIBs (and do not offer SNMPv3,
with its improved security features!) because these old
specifications are still listed as Standard.
I also strongly suspect that there are a few Draft Standard RFCs
that might be considered outdated.
It therefore might be worth repeating the RFC 4450 'experiment'
for Draft and Full Standards as well.
It should say:
[see above]
Notes:
From Eliot Lear <lear@cisco.com>
Alfred,
Thanks for taking the time to read the document. I'd like to encourage
you to share your comments with the newtrk working group. You can find
information on how to subscribe by going to http://www.ietf.org and
clicking on "Working Groups".
As to your specific comments...
Alfred ? wrote:
> Hello,
> I'd like to send you a few comments on the recently
> published RFC 4450 (Cruft Removal) authored by you.
>
> First of all, thanks for your effort!
>
> After reading the RFC and looking into the changes
> performed to rfcxx00.txt, I noticed a few issues.
>
>
> (1)
>
> Near the top of page 3, section 3 of RFC 4450 states the
> reasons for removal from the list -- i.e. *not* moving
> to HISTORIC state:
> o RFC 1584 -- an expected future dependency;
> o RFC 1755 -- believed to be actively in use.
>
> Nevertheless, these two RFCs have been moved to HISTORIC
> status along with the publication of RFC 4450, as can be
> seen in rfcxx00.txt .
> This is quite surprising. (Perhaps, you know what happened.)
>
> Preferrably, the final RFC text would better have been
> coordinated with the actual Standards Actions performed --
> for example, by addition of an IESG statement explaining the
> deviation from the text.
>
There was intended to be no deviation from the text. The RFC Editor is
also the one who keeps track of how specifications are classified.
>
> (2)
>
> Due to the 'numeric limitation' applied (restriction to RFCs
> with numbers in the range ~700...2000) there are now a couple
> of RFCs that have lost their 'normative background'.
>
> For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
> 2456, 2457, and 2582) more or less depend on the now deprecated
> basic SNA node MIBs, RFCs (1665->)1666 and 1747. [ "xx->yy"
> is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
> Arguably, in this case, these dependant RFCs might be considered
> candidates for a move to HISTORIC as well.
> But there certainly are other cases as well (I have not yet
> checked all the details).
>
> It therefore should perhaps be considered to repeat the
> RFC 4450 'experiment' with an extended numeric range of RFCs,
> e.g. up to RFC 2500.
>
I believe the problem you refer to would occur no matter what point we
stop. Also, at this time the normative limitation is being reconsidered.
>
> (3)
>
> On the other hand, the restriction to Standards Track documents
> has other undesired implications:
>
> a) In the past, usually at least an Experimental RFC has been
> published as a first try for a new protocol (or an Informational
> RFC, in the case of a third-party protocol), before a Standards
> Track version has been developed. Unfortunately, in this process
> it obviously has been avoided very often to formally OBSOLETE
> the predecessor RFC[s] when the Standards Track version has been
> published. (Similar undue 'politeness' can be observed, e.g.,
> on the transition path of MIBs from SMIv1 to SMIv2.)
> Caused by RFC 4450 we now have non-deprecated RFCs predating
> RFCs moved to HISTORIC state.
> (The example instances I've been aware of at first glance, though
> still being listed as EXPERIMENTAL in the RFC index, fortunately
> already had been removed in the past from the 'Experimental RFCs'
> Section of rfcxx00.txt .)
> It would be very useful, for clarity, to move these RFCs to
> HISTORIC status as well.
>
> b) There are 'companion documents' to Standards Track RFCs that
> have been published as Informational RFCs for various (legitimate)
> reasons. These RFCs are outdated with their respective related
> specifications, and as such, for clarity, should better be moved
> to HISTORIC status as well.
>
I think it's a matter of how you want to use the marking of "HISTORIC".
I apply it only to specifications that are only on the standards track.
You are correct that these docs are related, and the ISD effort would
probably merge them, but it's not clear to me how that would affect status.
> For example, IMHO the following Informational and Experimental RFCs,
> being closely related to RFCs that now have been deprecated, should
> be considered candidates for deprecation (being made HISTORIC) as
> well, for clarity, consistency, and/or historical context:
>
> o RFC 1477 (IDPR Introduction);
> o RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
> o RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
> o RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
> o RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
> of which (RFCs 1552 and 1553) have been made HISTORIC;
> o RFC 1791 (TCP+UDP over IPX); \ both still in
> o RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !
> o RFC 1834 (WHOIS++ Introduction);
> o RFC 1875 (UNINETT PCA Policy) -- based on PEM.
>
> It might therefore perhaps be useful to perform a RFC 4450 like
> 'experiment' for Informational and Experimental RFCs as well.
>
>
> (4)
>
> The restriction in the RFC 4450 effort on Proposed Standards
> detracts from the fact that there are [Full] Standard RFCs as
> well which are clearly outdated, or of questionable quality and/or
> precision.
> My personal (incomplete) hot list of candidates comprises:
> STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
> (Other legacy Standards doubtlessly should be updated, e.g.
> STDs 5, 7, 13.)
>
> Note: In particular the situation with STDs 16+17 is annoying.
> Replacements are established, but vendors do not switch
> to SMIv2 and the newer MIBs (and do not offer SNMPv3,
> with its improved security features!) because these old
> specifications are still listed as Standard.
>
> I also strongly suspect that there are a few Draft Standard RFCs
> that might be considered outdated.
>
> It therefore might be worth repeating the RFC 4450 'experiment'
> for Draft and Full Standards as well.
>
And you might want to run that experiment. We had to start somewhere.
There is clearly more cruft.
Thanks,
Eliot
from pending
Errata ID: 84
Status: Verified
Type: Editorial
Reported By: Sam Weiler
Date Reported: 2006-03-29
Section 8 says:
This experiment would have been completely useless without
participation of the members of the old-standards mailing list.
Most notably, Pekka Savalo, Bob...
It should say:
This experiment would have been completely useless without
participation of the members of the old-standards mailing list.
Most notably, Pekka Savola, Bob...
Notes:
Typo in Pekka Savola's name
Errata ID: 2700
Status: Held for Document Update
Type: Editorial
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-01
Held for Document Update by: Pete Resnick
Section 10.1 says:
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, RFC
4395, February 2006.
It should say:
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006.
Notes:
RFC 4395 is not BCP 115, but BCP 35
Errata ID: 82
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Rejected by: Keith McCloghrie
Date Rejected: 2007-07-10
(1) typo
Section 3.5 of RFC 4455, on page 11, says:
The management of SCSI commands is beyond the scope of this MIB
| module. Future SCSI Command MIB module can link to this MIB module,
through the use of Object Identifiers (OIDs) or INDEX values of
appropriate tables.
It should say:
v
The management of SCSI commands is beyond the scope of this MIB
| module. Future SCSI Command MIB modules can link to this MIB module,
through the use of Object Identifiers (OIDs) or INDEX values of
appropriate tables.
(2) typo
Section 4.1 of RFC 4455, on page 11, says:
The scsiDeviceGroup group contains the objects general to each SCSI
instance: instance, device, and port objects. It contains also the
objects referring to the transport(s) used by those SCSI instances.
| This group is mandatory for all SCSI managed system.
It should say:
The scsiDeviceGroup group contains the objects general to each SCSI
instance: instance, device, and port objects. It contains also the
objects referring to the transport(s) used by those SCSI instances.
| This group is mandatory for all SCSI managed systems.
^
(3) word omission
The second paragraph of Section 4.7, on page 12, says:
Managed systems acting as a SCSI target device and port and running
| at high speed supporting should implement this group.
It should say:
Managed systems acting as a SCSI target device and port and running
| at high speed supporting statistics should implement this group.
^^^^^^^^^^^
(4) word omission
The second paragraph of Section 4.11, on page 13, says:
Managed systems acting as a SCSI initiator device and port and
running at high speed supporting should implement this group.
It should say:
Managed systems acting as a SCSI initiator device and port and
| running at high speed supporting statistics should implement this
group.
^^^^^^^^^^^
(5) text truncation
The DESCRIPTION clause of the scsiTransportFCP OBJECT-IDENTITY,
on page 24, says:
"This identity identifies a Fibre Channel Protocol for SCSI,
Second Version."
This sentence omits the most significant word, "transport".
It should say:
"This identity identifies a Fibre Channel Protocol for SCSI,
| Second Version, transport."
^^^^^^^^^^^
or:
vvvvvvvvvvvvvvvvvvv
| "This identity identifies transport via the Fibre Channel
Protocol for SCSI, Second Version."
(6) incomplete description, and incomplete functionality ??
The DESCRIPTION clause of the scsiPortBusyStatuses OBJECT-TYPE,
on page 30, says:
[...]
Discontinuities in the value of this counter can occur at re-
initialization of the management system."
Admittedly, this is true, but more importantly, the counter can
wrap back from 2^32-1 to 0 !!!
That should be noted there, and it should be detectable by means
of some 'discontinuity time stamp' object in the MIB module.
(7) as (6) above
The same issue as stated in item (6) above also holds for the
scsiIntrDevOutResets OBJECT-TYPE, on page 33.
(8) as (6) above
The same issue as stated in item (6) above also holds for all
counters in the SCSI Initiator Port Table, i.e. the DESCRIPTIONs
of the scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,
scsiIntrPortReadMegaBytes, and scsiIntrPortHSOutCommands
OBJECT-TYPEs, on page 35.
(9) typo
The ASN.1 comment on top of page 36,
-- SCSI target device discovered or authorized to attach each of the
-- SCSI initiator ports of each SCSI initiator device of each
-- instance.
should say:
v
| -- SCSI target devices discovered or authorized to attach each of the
-- SCSI initiator ports of each SCSI initiator device of each
-- instance.
(10) typo (spurious word)
The DESCRIPTION clause of the scsiDscTgtIndex OBJECT-TYPE, on page 37,
says:
"This object is an arbitrary integer used to uniquely identify
a particular SCSI target device either discovered by, or
| configured for use with, one or more ports scsiDscTgtName of
a particular device within a particular SCSI instance."
The spurious word "scsiDscTgtName" should be deleted.
Thus, it should say:
"This object is an arbitrary integer used to uniquely identify
a particular SCSI target device either discovered by, or
| configured for use with, one or more ports of a particular
device within a particular SCSI instance."
(11) typo (spurious word)
The DESCRIPTION clause of the scsiDscTgtDevOrPort OBJECT-TYPE,
on page 37, says:
"This object indicates whether this entry describes a
| configured SCSI target device name (and applies to all ports
on the identified SCSI target device) or an individual SCSI
target port."
The spurious word "name" should be deleted.
Thus, it should say:
"This object indicates whether this entry describes a
| configured SCSI target device (and applies to all ports
on the identified SCSI target device) or an individual SCSI
target port."
(12) similar to (6), and semantic overloading
The DESCRIPTION clause of the scsiDscTgtInCommands OBJECT-TYPE,
on page 38, says:
[...]
Discontinuities in the value of this counter can occur at re-
initialization of the management system, and at other times as
indicated by the value of scsiDscTgtLastCreation."
The literally same wording is repeated on page 39 in the DESCRIPTION
clauses of the OBJECT-TYPEs
- scsiDscTgtWrittenMegaBytes,
- scsiDscTgtReadMegaBytes, and
- scsiDscTgtHSInCommands.
See the explanations for item (6) above.
The DESCRIPTION clause of the scsiDscTgtLastCreation OBJECT-TYPE,
at the bottom of page 39, says:
"This object represents the value of sysUpTime when this row
| was created."
Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??
(13) typo
The ASN.1 comment near the bottom of page 43,
| --***** Table of SCSI Target Device Attached to local SCSI
--***** Initiator Ports
should say:
v
| --***** Table of SCSI Target Devices Attached to local SCSI
--***** Initiator Ports
(14) as (6) above
The DESCRIPTION clauses, on page 49, of the OBJECT-TYPEs
- scsiTgtPortInCommands,
- scsiTgtPortWrittenMegaBytes,
- scsiTgtPortReadMegaBytes, and
- scsiTgtPortHSInCommands
contain the sentence,
Discontinuities in the value of this counter can occur at re-
initialization of the management system."
the explanations given for item (6) above apply here as well.
(15) improper wording
The DESCRIPTION clause of the scsiTgtPortHSInCommands OBJECT-TYPE,
on page 49, says:
"This object represents the number of commands received. This
| object provides support for systems that can quickly generate a
large number of commands because they run at high speed.
[...]
Because this object counts *incoming* commands, the word "generate"
is considered improper and should be replaced by "accept" (or similar):
"This object represents the number of commands received. This
| object provides support for systems that can quickly accept a
large number of commands because they run at high speed.
[...]
(16) like (12) above
The SCSI Authorized Initiator table suffers from the same problems
as the Target Device Discovered Table (Item (12) above):
The DESCRIPTION clauses (on pages 52/53) of the OBJECT-TYPEs
- scsiAuthIntrAttachedTimes,
- scsiAuthIntrOutCommands,
- scsiAuthIntrReadMegaBytes,
- scsiAuthIntrWrittenMegaBytes, and
- scsiAuthIntrHSOutCommands
each contain the identical sentence:
Discontinuities in the value of this counter can occur at re-
initialization of the management system, and at other times as
indicated by the value of scsiAuthIntrLastCreation."
and the DESCRIPTION clause of the scsiAuthIntrLastCreation OBJECT-TYPE,
on page 53, says:
"This object indicates the value of sysUpTime when this row was
last created."
Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??
(17) again, like (12) above
The SCSI LU table suffers from the same problems as above:
The DESCRIPTION clauses (on pages 60..62) of the OBJECT-TYPEs
- scsiLuInCommands,
- scsiLuReadMegaBytes,
- scsiLuWrittenMegaBytes,
- scsiLuInResets,
- scsiLuOutTaskSetFullStatus, and
- scsiLuHSInCommands
each contain the identical sentence:
Discontinuities in the value of this counter can occur at re-
initialization of the management system, and at other times as
indicated by the value of scsiLuLastCreation."
while the DESCRIPTION clause of the scsiLuLastCreation OBJECT-TYPE,
on page 62, says:
"This object indicates the value of sysUpTime when this row was
last created."
Again, counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??
(18) MIB structure inconsistency ???
On page 66, RFC 4455 says:
--********************** Notifications ******************************
| -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 2 }
^^^
scsiNotificationsPrefix OBJECT IDENTIFIER
::= { scsiNotifications 0 }
This is very notable, since on page 23, the same RFC has
specified:
--****************** Structure of the MIB **************************
| scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }
[...]
^^^
At least, giving different values for the same object name
(though one instance is in an ASN.1 comment) is irritating.
The trailing OID component '0' is required for SNMPv1 backwards
compatibility. Since it is already contained in the effective
'scsiNotifications' OID (as specified on page 23), the additional
introduction of 'scsiNotificationsPrefix' seems to be very
redundant. Its use could be easily substituted by the use of
'scsiNotifications' in the two NOTIFICATION-TYPE invocations
on page 66, which would have resulted in the OID assignments,
scsiTgtDeviceStatusChanged NOTIFICATION-TYPE
[...]
::= { scsiNotifications 1 }
and
scsiLuStatusChanged NOTIFICATION-TYPE
[...]
::= { scsiNotifications 2 }
as usual in IETF MIBs.
That is now too late to be corrected, but the misleading ASN.1 comment
on page 66 of the RFC, as noted above, should be corrected to say:
--********************** Notifications ******************************
| -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }
^^^
(19) typo
The ASN.1 comment on page 67,
-- Conditionally mandatory groups to be included with
-- the mandatory groups when the implementation has
| -- SCSI target device.
should say:
-- Conditionally mandatory groups to be included with
-- the mandatory groups when the implementation has
| -- SCSI target devices.
^
(20) typo
The DESCRIPTION clause of the scsiInitiatorDeviceGroup OBJECT-GROUP
invocation, on page 71, says:
"This group is relevant for s SCSI initiator device and port."
should say:
v
| "This group is relevant for a SCSI initiator device and port."
or even better:
| "This group is relevant for SCSI initiator devices and ports."
(21) duplicate / redundant text
Section 10, on page 76, contains the 5th paragraph:
We assume an HBA as the SCSI initiator device and a disk as the SCSI
target device. We assume that the SCSI target device has one logical
unit, addressed by Logical Unit Number set to 0 (LUN0), which is the
default LUN. Parallel SCSI has only port identifiers, no port names.
The transport pointer for parallel SCSI is set to 0 since there is no
reference transport (SPI) MIB module.
This text is a slightly modified restatement of what is said in the
directly preceeding paragraph.
Thus, this paragraph should be deleted.
Notes:
Notes from Keith:
I think the only one of your corrections which is needed to avoid the
possibility of causing confusion to a reader is the one regarding the
OID of scsiNotifications. If an RFC Errata Note is created because
of that one, and all the other typos that you have found are also
included in the same RFC Errata Note, then my fear is that the one
which could be important will get buried in the triviality of the
others. Thus, I suggest that an RFC Errata Note, if created, should
only mention the OID of scsiNotifications.
I don't believe there are any items which need to be considered by the
WG for a future update to the MIB module.
from pending
Errata ID: 83
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Keith McCloghrie
Date Verified: 2006-07-10
Page 66 says:
--********************** Notifications ******************************
-- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 2 }
It should say:
--********************** Notifications ******************************
-- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }
Notes:
There are two issues here:
1) a typo in the ASN.1 comments. The correct OID is { scsiMIB 0 } because
that's what the MIB compiler will process, i.e., the MIB compiler will
not process the ASN.1 comment. It is not too late to correct the typo
in the ASN.1 comment.
2) In the development of the MIB, the change to use the OID structure
recommended by Appendix D of RFC 4181 caused the use of
scsiNotificationsPrefix (as the means to include zero in the OIDs of
the notifications) to become no longer necessary, and it would have
been better if it had been removed. But, it is now too late to remove
scsiNotificationsPrefix.
Errata ID: 1409
Status: Verified
Type: Technical
Reported By: Francois AUDET
Date Reported: 2008-04-16
Verifier Name: Robert Sparks
Date Verified: 2011-02-07
Section 5 says:
target-param = "target" EQUAL pvalue
cause-param = "cause" EQUAL Status-Code
It should say:
target-param = "target=" pvalue
cause-param = "cause=" Status-Code
Notes:
The definition was too permissive and conflicted with RFC 3261 ABNF (p. 223). Since this parameter is part of the other-param of uri-parameter, only a "=" (i.e, no linear whitespace allowed) and not EQUAL (which allows linear whitespace).
Errata ID: 1621
Status: Held for Document Update
Type: Editorial
Reported By: Ben Harris
Date Reported: 2008-11-25
Held for Document Update by: Pasi Eronen
Section 9 says:
In order for the "external-keyx" user authentication method to be used, it MUST have access to user authentication information obtained as a side-effect of the key exchange. If this information is unavailable, the authentication MUST fail.
It should say:
In order for the "gssapi-keyex" user authentication method to be used, it MUST have access to user authentication information obtained as a side-effect of the key exchange. If this information is unavailable, the authentication MUST fail.
Notes:
As mentioned in section 8, the "external-keyx" name was used by an earlier version of thespec, but got replaced by "gssapi-keyex" before publication.
Errata ID: 895
Status: Verified
Type: Technical
Reported By: Alexey Melnikov
Date Reported: 2007-04-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 5 says:
X.7.8 Trust relationship required
It should say:
X.7.14 Trust relationship required
Notes:
Incorrect Enhanced Status Code. See <http://www.iana.org/assignments/smtp-enhanced-status-codes> for more details.
Errata ID: 896
Status: Verified
Type: Technical
Reported By: Alexey Melnikov
Date Reported: 2007-04-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 6 says:
554 5.7.8 URL resolution requires trust relationship
It should say:
554 5.7.14 URL resolution requires trust relationship
Notes:
Incorrect Enhanced Status Code. See <http://www.iana.org/assignments/smtp-enhanced-status-codes> for more details.
Errata ID: 2002
Status: Verified
Type: Technical
Reported By: Mike Abbott
Date Reported: 2010-01-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02
Section 5 says:
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5B /
%x5D-FE) ; Any TEXT-CHAR except "]"
It should say:
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5C /
%x5E-FE) ; Any TEXT-CHAR except "]"
Notes:
The skipped character %x5C is "\" not "]". I think the intent is to omit "]" since url-resp-text is used exclusively inside a [BADURL url-resp-text] response code, and they want to avoid aliasing the closing "]".
Errata ID: 81
Status: Verified
Type: Technical
Reported By: Sam Weiler
Date Reported: 2006-05-09
Section 2 says:
).com 3600 IN NSEC +.com ( RRSIG NSEC )
It should say:
\).com 3600 IN NSEC \+.com ( RRSIG NSEC )
Notes:
Line should use the escape characters as defined in RFC 1035.
Errata ID: 1055
Status: Verified
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2007-07-12
Section 6 says:
The verifier processes this certificate in the usual ways, including checking that it has not expired, that the chain is valid back to a trusted certification authority (CA), and that it does not appear on revocation lists. Once the certificate is acquired, it MUST be validated following the procedures in RFC 3280 [9].
It should say:
The verifier processes this certificate in the usual ways, including checking that it has not expired, that the chain is valid back to a trusted certification authority (CA), and that it does not appear on revocation lists. To fetch certificate chains, the certificate can use the SubjectInfoAccess and techniques such as RFC 4387 can be used to retrieve the chain. Once the certificate is acquired, it MUST be validated following the procedures in RFC 3280 [9].
Notes:
insert a new sentence
Errata ID: 1056
Status: Verified
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2007-07-12
Section 6 says:
This document introduces a new logical role for SIP entities called a server.
It should say:
This document introduces a new logical role for SIP entities called a verifier.
Notes:
change server to verifier.
Errata ID: 1057
Status: Verified
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2007-07-12
Section 10.1 says:
Content-Length: 147
It should say:
Content-Length: ...
Notes:
There are two places where this occurs in section 10.1.
Errata ID: 1058
Status: Verified
Type: Technical
Reported By: Cullen Jennings
Date Reported: 2007-07-12
Section 9 says:
Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT 32LHEX RDQUOT
It should say:
Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = quoted-string
Errata ID: 2963
Status: Held for Document Update
Type: Technical
Reported By: Raphael Bossek
Date Reported: 2011-09-08
Held for Document Update by: Robert Sparks
Section 7.1. says:
<dm:deviceID>mac:8asd7d7d70</dm:deviceID> ... <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
It should say:
Replace both with <dm:deviceID>urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66</dm:deviceID>
Notes:
As mentioned in Errata ID 2131 and 2962 a valid URN as defined in RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms should be used for <dm:deviceID>. This is not the case for this example.
RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the <deviceID> element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address."
Errata ID: 80
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Held for Document Update by: Robert Sparks
Section 3 says:
It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, presentity, or device. This is in contrast to a model whereby the attributes are associated with the service, presentity, or device because they were reported by that service, presentity, or device.
It should say:
It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, person, or device. This is in contrast to a model whereby the attributes are associated with the service, person, or device because they were reported by that service, person, or device.
Notes:
Regarding the definition from Section 2, on top of page 4 of the RFC,
Presentity: A presentity combines devices, services, and person
information for a complete picture of a user's presence status on
the network.
IMHO the term "presentity" should have been replaced by "person" to keep this text passage
consistent with the terminology introduced in Section 2.
Errata ID: 2131
Status: Held for Document Update
Type: Editorial
Reported By: Martin Thomson
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section 7.1 says:
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
It should say:
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
entity="pres:presentity@example.com">
Notes:
The entity attribute of the <presence> element is mandatory. It contains a URI that identifies the presentity.
The namespace prefix binding for "http://www.w3.org/2001/XMLSchema-instance" is not used in the example and need not appear.
Not corrected here: the example uses an undefined URI scheme, mac:, to identify a device.
Errata ID: 2959
Status: Reported
Type: Technical
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Section 3.2. says:
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information. ----on the next page---- lunch: The person is eating his or her midday meal.
It should say:
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information. ----on the next page---- (delete this line)
Notes:
The <lunch> activity is not allowed because not defined by the XML Schema in section in section 5.1. Because the XML Schema is immutable the documentation should be corrected.
Errata ID: 2960
Status: Reported
Type: Technical
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Section 7.2. says:
7.2. Schema Registration for Schema ............................32
'urn:ietf:params:xml:ns:pidf:status:rpid'
----on the page 32----
7.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:status:rpid'
URI: urn:ietf:params:xml:ns:pidf:status:rpid
It should say:
7.2. Schema Registration for Schema ............................32
'urn:ietf:params:xml:schema:pidf:status:rpid'
----on the page 32----
7.2. Schema Registration for Schema
'urn:ietf:params:xml:schema:pidf:status:rpid'
URI: urn:ietf:params:xml:schema:pidf:status:rpid
Notes:
The XML Schema sub-namespace is 'urn:ietf:params:xml:schema:pidf:status:rpid' (instead of 'urn:ietf:params:xml:ns:pidf:status:rpid') as registered in the IANA maintained registry at http://www.iana.org/assignments/xml-registry/schema.html
RFC 3688: The IETF XML Registry; Syntax for XML schema sub-namespace define the XML Schema namespace syntax as "urn:ietf:params:xml:schema:<id>".
Errata ID: 2961
Status: Reported
Type: Technical
Reported By: Raphael Bossek
Date Reported: 2011-09-07
Section 4. says:
<rpid:sphere>bowling league</rpid:sphere>
It should say:
<rpid:sphere><bowlingleague/></rpid:sphere>
Notes:
The <sphere> content type is 'element-only'; it's not valid to use tokens. It's possible to use XML elements from other XML namespace (e.g. <bowlingleague/>) or choose one of the following: <rpid:work/>, <rpid:home/>, <rpid:unknown/>
Errata ID: 2962
Status: Reported
Type: Technical
Reported By: Raphael Bossek
Date Reported: 2011-09-08
Section 4. says:
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID> ... <dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID> ... <dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
It should say:
Replace all three with <dm:deviceID>urn:uuid:698137d0-b395-11e0-aff2-0800200c9a66</dm:deviceID>
Notes:
"urn:device" is a not registered URN namespace as defined by RFC3406: Uniform Resource Names (URN) Namespace Definition Mechanisms. "urn:x-mac" is an experimental URN namespace. All <dm:deviceID> address point to the same device.
RFC 4479 in section 3.4. Device RECOMMENDS version 1 UUIDs for the <deviceID> element: "For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address."
Errata ID: 1001
Status: Verified
Type: Editorial
Reported By: John Huang
Date Reported: 2007-09-07
The header on every page says:
RFC 4480 RIPD July 2006
It should say:
RFC 4480 RPID July 2006
Errata ID: 79
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-06-20
Held for Document Update by: Robert Sparks
(1) Inconsistent Ref. to URI Specification
The text of RFC 4483 repeatedly refers to "RFC2396 [7]" .
This is misleading.
Every occurrence of "RFC 2396" should be replaced by "RFC 3986".
Note: Section 10.1. Normative References, holds the proper
reference to STD 66, RFC 3986 in its item [7] !
(2) Outdated Ref. to HTTP 1.1 Specification
Item [4] of Section 10.1 Normative References, points to the
outdated original specification for HTTP 1.1, RFC 2016,
which has been obsoleted by RFC 2616, 7 years ago.
Since the HTTP ETAG mechanism (referred to in the text of RFC 4483)
has been clarified substantially in RFC 2616, the reference to
"RFC2068 [4]" in Section 4, near the bottom of page 5 of RFC 4483,
should bhave been "RFC2616 [4]", and the item [4] of Section 10.1,
on page 15 of RFC 4483, should be replaced by a citation of RFC 2616
according to `rfc-ref.txt`.
(3) (Mis)Use of SIP Terminology
Unfortunately, RFC 4483 substantially adds to the confusion
of precisely defined SIP (and other) terminology.
In particular, *all* occurrences of the term "Header[s]" in RFC 4483
should be corrected to say "Header Field[s]".
RFC 4485, published just 2 weeks ahead of RFC 4483, explicitely
poses the requirement for SIP extension documents to follow the
established SIP terminology -- cf. Section 4.3 of RFC 4485
(page 10), which says:
Careful attention must be paid to the actual usage of terminology.
Many documents misuse the terms header, header field, and header
field values, for example. Document authors SHOULD do a careful
review of their documents for proper usage of these terms.
See also RFC 4249, Section 3.1.1 (page 3) for a similar statement on
the proper usage of these terms in the context of IMF and MIME, and
related (extension) specifications.
Notes:
from pending
Errata ID: 1884
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2009-09-17
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 2.1, pg. 4 says:
When the Message Digest authenticated attribute is present, the | DigestedData digest contains a 32-byte digest in little-endian representation:
It should say:
When the Message Digest authenticated attribute is present, the | DigestedData digest contains a 32-byte digest in big-endian representation:
Notes:
Rationale:
- Contradiction to other parts of the document,
which use "big-endian" == 'network byte order'
as established in the Internet architecture.
- Please also note that the ASN.1 BER/DER encoding is
based on the 'natural' byte order for left-to-right
scripts -- otherwise the intrinsically variable-length
representation used would be very complicated to deal
with in processing.
- Intrduction of varying endian-ness is a likely source
of implementation issues and, consequentially,
interoperability problems.
--VERIFIER NOTES--
authors confirmed that the DigestedData digest is encoded in little-endian representation in all
known implementations.
Errata ID: 1465
Status: Held for Document Update
Type: Editorial
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Held for Document Update by: Tim Polk
Section 4.1.1 says:
Using the secret key corresponding to the originatorKey publicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
It should say:
Using the private key corresponding to the originatorKey publicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
Notes:
Russian-English terminology translation bug
Errata ID: 1466
Status: Held for Document Update
Type: Editorial
Reported By: Serguei Leontiev
Date Reported: 2008-07-09
Held for Document Update by: Tim Polk
Section 4.2.1 says:
Using the secret key corresponding to the GostR3410- TransportParameters ephemeralPublicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
It should say:
Using the private key corresponding to the GostR3410- TransportParameters ephemeralPublicKey and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK.
Notes:
Russian-English terminology translation bug
Errata ID: 1885
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2009-09-17
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 2.3.1, 2.3.2 says:
a) Section 2.3.1, page 7 | GostR3410-94-PublicKey MUST contain 128 octets of the little-endian representation of the public key Y = a^x (mod p), where a and p are public key parameters, and x is a private key. b) Section 2.3.2, page 9 GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32 | octets contain the little-endian representation of x and the second | 32 octets contain the little-endian representation of y. [...]
It should say:
a) | GostR3410-94-PublicKey MUST contain 128 octets of the big-endian representation of the public key Y = a^x (mod p), where a and p are public key parameters, and x is a private key. b) GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32 | octets contain the big-endian representation of x and the second | 32 octets contain the big-endian representation of y. [...]
Notes:
Rationale:
Inconsistency within the RFC.
Most parts of the memo make use of the Internet-standard
"network byte order". a.k.a. "big-endian byte order", which
also is at the heart of the ASN.1 BER/DER encoding.
Use of mixed endian-ness within a single context, or even
a single specification, is a likely source of implementation
errors and, consequently, interoperability problems.
Cf. the related Errata Note for RFC 4490, EID=1884.
--VERIFIER NOTES--
authors confirmed that little-endian encoding is correct.
Errata ID: 2389
Status: Verified
Type: Technical
Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Verifier Name: Sean Turner
Date Verified: 2011-03-26
Section 5.4 says:
point: This is the byte string representation of an elliptic curve
point following the conversion routine in Section 4.3.6 of ANSI
X9.62 [7]. This byte string may represent an elliptic curve point
in uncompressed or compressed format; it MUST conform to what the
client has requested through a Supported Point Formats Extension
if this extension was used.
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic-2
field using a trinomial basis.
ec_basis_pentanomial: Indicates representation of a
characteristic-2 field using a pentanomial basis.
It should say:
point: This is the byte string representation of an elliptic curve
point following the conversion routine in Section 4.3.6 of ANSI
X9.62 [7]. This byte string may represent an elliptic curve point
in uncompressed or compressed format; it MUST conform to what the
client has requested through a Supported Point Formats Extension
if this extension was used.
enum {
ec_basis_trinomial(1), ec_basis_pentanomial(2),
(255)
} ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic-2
field using a trinomial basis.
ec_basis_pentanomial: Indicates representation of a
characteristic-2 field using a pentanomial basis.
Notes:
The ECBasisType enumeration is submitted as part of the ECParameters structure and therefore needs numerical values. It is common to assign numerical values starting from 1 to enums and maximum value of 255 should be enough, since currently there are only two known basis types and it is unlikely to change in the near future.
Errata ID: 2392
Status: Held for Document Update
Type: Editorial
Reported By: Brian Smith
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner
Section 5.2 says:
The server's Supported Point Formats Extension has the same structure as the client's Supported Point Formats Extension (see Section 5.1.2). Items in elliptic_curve_list here are ordered according to the server's preference (favorite choice first). Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format).
It should say:
The server's Supported Point Formats Extension has the same structure as the client's Supported Point Formats Extension (see Section 5.1.2). Items in ec_point_format_list here are ordered according to the server's preference (favorite choice first). Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format).
Notes:
ec_point_format_list is the field in the Supported Point Formats Extension. elliptic_curve_list is the field in the Supported Elliptic Curves Extension.
Errata ID: 78
Status: Verified
Type: Editorial
Reported By: Yitzchak M. Gottlieb
Date Reported: 2006-05-23
Section 3 says:
In particular, the "dnsname" field of the DNS URI is to be considered an internationalized domain name (IDN) unaware domain name slot, in the terminology of RFC 3940 [14].
It should say:
In particular, the "dnsname" field of the DNS URI is to be considered an internationalized domain name (IDN) unaware domain name slot, in the terminology of RFC 3490 [14].
Notes:
Reference 14 is RFC 3490 not RFC 3940.
Errata ID: 77
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-06-28
(1) clarification
The RFC 4502 text in Section 2.2, under bullet 3), on page 5,
says:
Bit Definition
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation-specific matter
| as to which bit is assigned to which
direction, but it must be consistent for
all packets received by the agent. [...]
This text certainly is intended to always (and only) cover bit #6.
Therefore, the wording, "which bit is assigned" is misleading;
it should be "which [bit] value is assigned".
Thus, the above snippit sould better say:
Bit Definition
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation-specific matter
| as to which bit value is assigned to which
direction, but it must be consistent for
all packets received by the agent. [...]
(2) Ref. issue
In Section 3.2, the third paragraph on page 9 says:
In the RMON MIB [RFC2819], the EntryStatus textual convention was
introduced to provide this mutual exclusion function. Since then,
this function was added to the SNMP framework as the RowStatus
textual convention. The RowStatus textual convention is used for the
definition of all new tables.
This text unfortunately has turned wrong by updating the (obsolete)
reference "[RFC1757]" (in RFC 2102) to "[RFC2819]".
(-- A very unusual event! --)
The text in RFC 2102 was correct, because RFC 1757 predates the
invention of the 'RowStatus' TC which was finalized in STD 58.
But STD 58 predates RFC 2819, and therefore, the clause,
vvvvvvvvvv
| Since then,
this function was added to the SNMP framework
as the RowStatus textual convention.
has turned wrong by the replacement of the Ref.!
(NOTE: RFC 2819 in fact still makes use of the 'EntryStatus' TC,
which already had been introduced in RFC 1271, the predecessor
of RFC 1757 !)
To correct this issue without causing a need to update the
References of RFC 4502 as well, I propose the following substitute
text as an Erratum for the text snippit above:
vvvvvvvvvvvvvvvvvvvv
| In the predecessors of the RMON MIB [RFC2819], the EntryStatus
textual convention was introduced to provide this mutual exclusion
function. Since then, this function was added to the SNMP framework
as the RowStatus textual convention. The RowStatus textual
convention is used for the definition of all new tables.
(3) outdated Ref.
The DESCRIPTION clause of the protocolDirID OBJECT-TYPE,
on page 21/22 of RFC 4502, says:
DESCRIPTION
"A unique identifier for a particular protocol. Standard
identifiers will be defined in such a manner that they
<< page break >>
can often be used as specifications for new protocols - i.e.,
a tree-structured assignment mechanism that matches the
protocol encapsulation 'tree' and that has algorithmic
assignment mechanisms for certain subtrees. See RFC 2074 for
more details.
[...]
RFC 2074 has been obsoleted by RFC 2895 and RFC 2896.
Therefore, the last sentence of this paragraph should better say:
[...]. See RFC 2895 and
RFC 2896 for more details.
(4) MIB indexing issue #1
As stated in the text added by RFC 4502 to the DESCRIPTION clause
of the addressMapEntry OBJECT-TYPE, the addressMapTable might run
in problems due to the cumulative length of its index object
instances.
Therefore, I suspect that it might have been better to replace the
last index object, addressMapSource, by an object mirroring the
addressMapControlIndex object (direct use of addressMapControlIndex
as the *last* index object might not be considered a valid option).
NOTE:
I know that it it too late now for any change, unfortunately.
(5) MIB indexing issue #2
The DESCRIPTION clause of the TimeFilter TEXTUAL-CONVENTION,
on page 16, explains that an index object of type TimeFilter
should be included as the *first* INDEX component for a time-
filtered table:
A time-filtered conceptual table is created by inserting a
single object of SYNTAX TimeFilter as the first INDEX component
in a copy of an existing basic conceptual table (i.e., any
SEQUENCE without a TimeFilter INDEX component). [...]
The RMON2 MIB does not follow this rule for the following tables:
- nlHostTable,
- nlMatrixSDTable,
- nlMatrixDSTable,
- alHostTable,
- alMatrixSDTable, and
- alMatrixDSTable.
Since there are arguably good reasons for the present indexing
structure of these tables, it might perhaps have been better
to have the above DESCRIPTION of the TC modified to accommodate
for the existing practice.
(6) textual issue
The first paragraph of the DESCRIPTION clause for the
alMatrixTopNControlRateBase OBJECT-TYPE, on page 78, says:
"This object controls which alMatrix[SD/DS] entry that the
alMatrixTopNEntries are sorted by, which view of the matrix
table that will be used, as well as which table the results
will be reported in.
It should perhaps better say (deleting 2 x 'that'):
| "This object controls which alMatrix[SD/DS] entry the
alMatrixTopNEntries are sorted by, which view of the matrix
| table will be used, as well as which table the results
will be reported in.
(7) wrong numerical limits in ASN.1 comment
The ASN.1 comments on the User History Collection Group,
in the second paragraph on page 86, says:
-- A sample value is stored in two objects - an absolute value and
-- a status object. This allows numbers from -(2G-1) to +4G to be
-- stored. The status object also indicates whether a sample is
-- valid. This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.
Based on the specification of usrHistoryAbsValue and
usrHistoryValStatus (on page93/94), I strongly suspect that the
specified limits are wrong, and that this text should say:
-- A sample value is stored in two objects - an absolute value and
-- a status object. This allows numbers from -(4G-1) to +(4G-1) to
-- be stored. The status object also indicates whether a sample is
-- valid. This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.
(8) inappropriate semantics specified in DESCRIPTION text
for objects in the usrHistoryControlTable
The DESCRIPTION clause of the usrHistoryControlBucketsRequested and
usrHistoryControlBucketsGranted objects (on page 87/88) seem to be
garbled a bit.
The latter contains the (3rd) paragraph:
The associated usrHistoryControlBucketsRequested object
should be set before or at the same time as this object
to allow the probe to accurately estimate the resources
required for this usrHistoryControlEntry.
This makes no sense here, because the usrHistoryControlBucketsGranted
object is read-only, and hence cannot be set.
I strongly suspect that a similar coupling in fact is needed
for the usrHistoryControlObjects object in relation to the
usrHistoryControlBucketsRequested object:
The probe cannot estimate the internal resource requirements,
and hence determine the value of usrHistoryControlBucketsGranted
without knowing the values of both the usrHistoryControlObjects
and the usrHistoryControlBucketsRequested objects in a row.
Therefore, I suspect that the above paragraph should be deleted,
and re-inserted with a slight modification as the new second
paragraph into the usrHistoryControlBucketsRequested DESCRIPTION
clause, saying:
vvvvvvv
| The associated usrHistoryControlObjects object
should be set before or at the same time as this object
to allow the probe to accurately estimate the resources
required for this usrHistoryControlEntry.
(I intentionally have omitted the appropriate line re-folding
here for clarity.)
(9) two typos
The DESCRIPTION clause of the ControlString TEXTUAL-CONVENTION,
on page 95, contains two typos:
The paragraph:
^w Wait for the reply string that follows, which is
terminated by the next command or the end of string.
Partial and case-insensitive matching is applied, i.e.,
if the reply string (any case combination) is found
anywhere in the received string, then the a match is
found. If the current timeout elapses without a match,
then the remaining control string is ignored.
should say (deleting 'the' in 'the a') :
^w Wait for the reply string that follows, which is
terminated by the next command or the end of string.
Partial and case-insensitive matching is applied, i.e.,
if the reply string (any case combination) is found
| anywhere in the received string, then a match is found.
If the current timeout elapses without a match, then
the remaining control string is ignored.
The 4th-to-last line of page 95,
^ 0x1C
should say:
^\ 0x1C
(10) textual clarification
In the Appendix of RFC 4502 (Section 8), the paragraph below
the pseudo-code on page 133 says:
The agent applies this function regardless of the lastActivationTime
of the conceptual row in question. In other words, counter
discontinuities are ignored (i.e., a conceptual row is deleted and
then re-created later). An agent should consider an object instance
'changed' when it is created (either at restart time for scalars and
static objects, or row-creation-time for dynamic tables).
It should better say:
The agent applies this function regardless of the lastActivationTime
of the conceptual row in question. In other words, counter
| discontinuities (e.g., a conceptual row is deleted and then re-
| created later) are ignored. An agent should consider an object
instance 'changed' when it is created (either at restart time for
scalars and static objects, or row-creation-time for dynamic tables).
Notes:
from pending
Errata ID: 2504
Status: Reported
Type: Editorial
Reported By: Justin Harrison
Date Reported: 2010-08-27
Section Appendix B says:
B.1. Testing Round Function and Key Setup
key = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]
[...]
B.2. Testing the IV Setup
key = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]
It should say:
B.1. Testing Round Function and Key Setup
key = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]
[...]
B.2. Testing the IV Setup
key = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]
Notes:
There is a typographical error in the example key used in sections B.1 and B.2. As a result of this error, the key does not match the examples.
Errata ID: 76
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-05-24
(1) Section 6.2, page 18 - typo (word omission)
The words in the 9th line of the text,
[...] "followed by one or hexadecimal digits" [...]
should say:
[...] "followed by one or more hexadecimal digits" [...]
^^^^^^
(2) Section 8, 2nd paragraph (page 22) - typo
The RFC says:
Care must be take to properly encode and decode data to avoid
attacks. [...]
it should say:
vv
Care must be taken to properly encode and decode data to avoid
attacks. [...]
(3) Subtle inconsistency between Section 6.1 and Section 6.2
On page 17, Section 6.1 states the Notational Convention:
(2) Terminal symbols are strings of characters surrounded by
double quotes.
^^^^^^
Nevertheless, throughout the new Section 6.2 (on page 18), all
terminal symbols, e.g. the "generalized digits" -- the terminals
to build octal, decimal, and hexadecimal constants, are specified
as characters surrounded by *single* quotes.
^^^^^^
Although this style perhaps was inspired by the `C` language,
IMHO, its use is inconsistent in that context.
Notes:
from pending
Errata ID: 2752
Status: Reported
Type: Technical
Reported By: Matt McCutchen
Date Reported: 2011-03-23
Section RFC header says:
It should say:
Updates: 4035
Notes:
This document should update RFC 4035 because the statement in section 3, "Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset", modifies the rules for authenticating referrals in RFC 4035 section 5.2.
Errata ID: 75
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Rejected by: Jim Sermersheim
Date Rejected: 2006-07-03
(2) Typo
Section 2, on page 4, contains the paragraph:
v
| The term "SASL layer" refers to Simply Authentication and Security
Layer (SASL) services used in providing security services, as well as
associations established by these services.
It should say:
v
| The term "SASL layer" refers to Simple Authentication and Security
Layer (SASL) services used in providing security services, as well as
associations established by these services.
(3) Misrepresented relationship between ISO 10646 and Unicode
Section 4.1.2 unfortunately has not corrected a misconception
initially spelled out in RFC 2251.
The first paragraph of Section 4.1.2, on page 7, says:
The LDAPString is a notational convenience to indicate that, although
strings of LDAPString type encode as ASN.1 OCTET STRING types, the
| [ISO10646] character set (a superset of [Unicode]) is used, encoded
following the UTF-8 [RFC3629] algorithm. [...]
The (..) enclosed note on the relationship of ISO 10646 and Unicode
is *not* appropriate, as far as I know:
Unicode covers exactly the same character repertoire as ISO 10646,
but it *adds* a lot of *semantics* to ISO 10646.
The character repertoire synchronization between ISO 10646 and
Unicode is said to hold since 1993, and it is promised for all
future updates.
(Details can be found in Section 1.4 and Appendix C of
The Unicode Standard (book and online version), verbatim
identical in the Unicode 3.0 and Unicode 4.0 versions.)
In particular, this congruence holds for Unicode 3.2.0
(and the coordinated edition of ISO 10646) that has been
made the invariable base for the new LDAP specs.
Therefore, the above sentence should perhaps better be
corrected to say:
The LDAPString is a notational convenience to indicate that, although
strings of LDAPString type encode as ASN.1 OCTET STRING types, the
| [ISO10646] character set (as detailed in [Unicode]) is used, encoded
following the UTF-8 [RFC3629] algorithm. [...]
(or similar).
(4) Typo (word omission)
The 3rd paragraph of Section 4.2.2, on page 18, says:
If the client receives a BindResponse where the resultCode is set to
protocolError, it is to assume that the server does not support this
| version of LDAP. While the client may be able proceed with another
version of this protocol (which may or may not require closing and
re-establishing the transport connection), how to proceed with
another version of this protocol is beyond the scope of this
document. Clients that are unable or unwilling to proceed SHOULD
terminate the LDAP session.
It should say:
vvvv
| [...]. While the client may be able to proceed with
another version of this protocol (which may or may not require
closing and re-establishing the transport connection), how to proceed
with another version of this protocol is beyond the scope of this
document. [...]
Items (2)..(4) above might be considered for an Errata Note
to be posted to the RFC Editor's "RFC Errata" web pages.
I propose that you submit an Author's Errata Note, based on the
material presented above, and/or choosing alternate text for (3).
Notes:
In any case, these items should be noted for future reference,
whenever once another revision of these RFCs is to be produced,
e.g., for advancement on the Standards Track.
[note: (1) contained general comments and has been removed.]
Author saving on file for possible revision.
from pending
Errata ID: 74
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
(E1) text truncation (?)
Apparently, the text of the first paragraph of Section 3.2,
on page 18 of RFC 4512, has been truncated inadvertently.
The RFC text says:
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
| [X.501]. Subentries are used in Directory to hold for administrative
| and operational purposes as defined in [X.501]. Their use in LDAP is
detailed in [RFC3672].
I suspect that it should in fact say:
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
| [X.501]. Subentries are used in the Directory to hold attributes for
| administrative and operational purposes as defined in [X.501]. Their
use in LDAP is detailed in [RFC3672].
(E2) typo
In Section 4.1.7.1, near the bottom of page 30, the explanation,
FORM is specifies the name form associated with this DIT structure
rule;
should say:
| FORM specifies the name form associated with this DIT structure
rule;
(E3) typo
The first paragraph of Section 5.1, on page 36, says:
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
| the DN with zero RDNs (whose [RFC4514] representation is as the
zero-length string).
It should say:
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
| the DN with zero RDNs (whose [RFC4514] representation is the zero-
length string).
(E4) word omission
The second paragraph of Section A.2.1, on page 49, says:
The <descr> syntax was changed to disallow semicolon (U+003B)
characters in order to appear to be consistent its natural language
specification "descr is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a
letter". In a related change, the statement "an AttributeDescription
can be used as the value in a NAME part of an
AttributeTypeDescription" was deleted. RFC 2252 provided no
specification of the semantics of attribute options appearing in NAME
fields.
It should say:
The <descr> syntax was changed to disallow semicolon (U+003B)
| characters in order to appear to be consistent with its natural
language specification "descr is the syntactic representation of an
object descriptor, which consists of letters and digits, starting
with a letter".
In a related change, the statement "an AttributeDescription can be
used as the value in a NAME part of an AttributeTypeDescription" was
deleted. RFC 2252 provided no specification of the semantics of
attribute options appearing in NAME fields.
And these are my side notes for future consideration.
There are a couple of missing articles in the RFC text.
I have noted the following places:
(N1)
In Section 4.1.1, on page 24, the explanation,
where:
<numericoid> is object identifier assigned to this object class;
[...]
should better say:
where:
| <numericoid> is the object identifier assigned to this object
class;
[...]
(N2)
In Section 4.1.2,
a) on page 25, the literally same correction as (N1) applies, and
b) the explanation:
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
should better say:
| SYNTAX identifies the value syntax by its object identifier and may
suggest a minimum upper bound;
c) Finally, on top of page 26, the paragraph,
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype.
should better say:
| If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype.
(N3)
In Section 4.1.3, on page 27, -- similarly to (N1) --
the explanation,
where:
<numericoid> is object identifier assigned to this matching rule;
[...]
should better say:
where:
<numericoid> is the object identifier assigned to this matching
rule;
[...]
(N4)
In Section 4.1.7.2, on page 31, -- again like in (N1) --
the explanation,
where:
<numericoid> is object identifier that identifies this name form;
[...]
should better say:
where:
<numericoid> is the object identifier that identifies this name
form;
[...]
(N5)
The final sentence of Section 4.2, i.e. the 3rd paragraph on page 33,
says:
The following subsections provide attribute type definitions for each
of schema definition attribute types.
It should say:
The following subsections provide attribute type definitions for each
| of the schema definition attribute types.
Notes:
Source: apps
Errata ID: 2281
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-05-21
Section A.3 says:
The second paragraph of Section A.3, at the bottom of page 50, says: Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
It should say:
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' | attribute type. This was integrated into Section 3.3 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
Notes:
Apparently, 'Section 3.3' would have been much more appropriate than
'Section 2.4.1'.
Source: apps
Errata ID: 73
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
Section 4 says:
This example shows the method of escaping of a special characters appearing in a common name:
It should say:
This example shows the method of escaping of special characters appearing in a common name:
Notes:
Source: apps
Errata ID: 72
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
Section 4 says:
The first example shows use of the matching rule "caseExactMatch."
It should say:
The first example shows use of the matching rule "caseExactMatch".
Notes:
Source: apps
Errata ID: 840
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
Section 2 says:
The ASN.1 term, `AttributeValue`, has been replaced by
`AssertionValue` wherever it was used previously.
Hence, in Section 2 (on page 3) of RFC 4515
- the ASN.1 line
AttributeValue ::= OCTET STRING
is not needed any more and might have been omitted, and
- in the subsequent explanation, the sentence,
[...] The AttributeValue and AssertionValue OCTET STRING have
the form defined in [RFC4517]. [...]
might have been shortened to say:
[...] The AssertionValue OCTET STRING has the form defined ib
[RFC4517]. [...]
Notes:
Source: apps
Errata ID: 71
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-06-23
Held for Document Update by: Alexey Melnikov
Date Held: 2010-05-21
Section Appendix A.2 says:
Changed the text indicate that RFC 2255 is replaced ...
It should say:
Changed the text to indicate that RFC 2255 is replaced ...
Notes:
Errata ID: 860
Status: Verified
Type: Technical
Reported By: Stephane PERBELLINI
Date Reported: 2007-02-23
Verifier Name: Kurt Zeilenga
Date Verified: 2007-02-23
Section 2.2 says:
COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also mapped to nothing.
It should say:
COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs (U+180B-180D, FE00-FE0F) code points are also
Notes:
FF00-FE0F should be FE00-FE0F
from pending
Errata ID: 1757
Status: Verified
Type: Technical
Reported By: Steven Legg
Date Reported: 2009-04-05
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section 2.6.1 says:
Otherwise, the following steps are taken:
It should say:
Otherwise, the following steps are taken:
- Any inner (non-empty) sequence of space characters is replaced
with exactly two SPACE characters;
Errata ID: 1758
Status: Verified
Type: Technical
Reported By: Steven Legg
Date Reported: 2009-04-05
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20
Section 2.6.1 says:
As an any or final substring, the same input would result in "foo<SPACE>bar<SPACE>".
It should say:
As an any or final substring, the same input would result in "foo<SPACE><SPACE>bar<SPACE>".
Errata ID: 1761
Status: Rejected
Type: Technical
Reported By: Fotis Georgatos
Date Reported: 2009-04-10
Rejected by: Alexey Melnikov
Date Rejected: 2010-09-02
Section 3.10 says:
3.10. 'organizationalRole'
The 'organizationalRole' object class is the basis of an entry that
represents a job, function, or position in an organization.
(Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
It should say:
3.10. 'organizationalRole'
The 'organizationalRole' object class is the basis of an entry that
represents a job, function, or position in an organization.
(Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
Notes:
Any object classes that include the preferredDeliveryMethod twice should be either redefined, by including it only once, OR provide an explicit reference about how it should be interpreted by the implementations; such examples are:
organizationalRole (3.10)
residentialPerson (3.13)
Note that this error has been affecting OpenLDAP implementations at least
since year 2002; with the side-effect that imported ldif data would disappear:
http://www.openldap.org/lists/ietf-ldapbis/200207/msg00002.html
It is surprising that it has remained unaddressed during so many years.
Also, Kurt Zeilinga has proposed to adopt the following (sufficient) rule:
"that implementations SHOULD be (and are) ignoring the redundant listing".
--VERIFIER NOTES--
Kurt Zeilenga said:
This issue was raised to the LDAPbis WG at the time it was working on the I-D which became RFC 4519 yet RFC 4519 did not include the suggested change. Simply put, there was insufficient support of the suggested change at that time.
The change is also bad in that in removes one of the examples of multiple listed attributes, a rarely used but still valid (for historical reasons) of X.500/LDAP schema descriptions, and hence may lead to implementations not supporting this feature and by doing so causing interop problems.
Errata ID: 70
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Alexey Melnikov
Appendix A says:
18. Removed Section 2.4 (Source). Replaced the source table with
explicit references for each definition.
It should say:
18. Removed Section 4 (Source). Replaced the source table with
explicit references for each definition.
Errata ID: 69
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-06-22
Held for Document Update by: Peter Saint-Andre
(1) Section 2.5 (page 5) -- Ref. tags
The text,
vvvvvvvv
Numerous elements of LDAP are described using ASN.1 [X.680] and are
| encoded using a particular subset [Protocol, Section 5.2] of the
Basic Encoding Rules (BER) [X.690]. To allow reuse of
parsers/generators used in implementing the LDAP "core" technical
specification [RFC4510], it is RECOMMENDED that extension elements
(e.g., extension specific contents of controlValue, requestValue,
responseValue fields) described by ASN.1 and encoded using BER be
| subjected to the restrictions of [Protocol, Section 5.2].
^^^^^^^^
should say:
Numerous elements of LDAP are described using ASN.1 [X.680] and are
| encoded using a particular subset [RFC4511, Section 5.1] of the
Basic Encoding Rules (BER) [X.690]. To allow reuse of
parsers/generators used in implementing the LDAP "core" technical
specification [RFC4510], it is RECOMMENDED that extension elements
(e.g., extension specific contents of controlValue, requestValue,
responseValue fields) described by ASN.1 and encoded using BER be
| subjected to the restrictions of [RFC4511, Section 5.1].
[ Note: the tags *and* the section numbers need correction! ]
(2) Section 3.1 (page 6), 3rd and 4th paragraph -- Ref. tags
The text:
An existing operation MAY be extended to return IntermediateResponse
| messages [Protocol, Section 4.13].
^^^^^^^^ vvvvvvvv
Specifications of controls SHALL NOT attach additional semantics to
| the criticality of controls beyond those defined in [Protocol,
Section 4.1.11]. A specification MAY mandate the criticality take on
a particular value (e.g., TRUE or FALSE), where appropriate.
should say:
An existing operation MAY be extended to return IntermediateResponse
| messages [RFC4511, Section 4.13].
Specifications of controls SHALL NOT attach additional semantics to
| the criticality of controls beyond those defined in [RFC4511, Section
4.1.11]. A specification MAY mandate the criticality take on a
particular value (e.g., TRUE or FALSE), where appropriate.
(3) Section 3.1.2 (page 7), 3rd paragraph -- typo
The text:
It is RECOMMENDED that designers consider alternative mechanisms for
providing the function. For example, an extended operation issued
subsequent to the Start TLS operation (hence, protected by the
security layers negotiated by the Start TLS operation) might be used
| to provided the desired function.
^
should say:
It is RECOMMENDED that designers consider alternative mechanisms for
providing the function. For example, an extended operation issued
subsequent to the Start TLS operation (hence, protected by the
security layers negotiated by the Start TLS operation) might be used
| to provide the desired function.
(4) Section 3.1.4 (page 8), 2nd bullet -- typo
The text:
vvvv
| - consistency: The resulting DIT state must be conform to schema
and other constraints.
should say:
| - consistency: The resulting DIT state must conform to schema and
other constraints.
(5) Section 3.2 (page 8) -- Ref. tag
The text:
vvvvvvvv
| Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
mechanism for defining new operations. [...]
should say:
| Extended Operations [RFC4511, Section 4.12] are the RECOMMENDED
mechanism for defining new operations. [...]
(6) Section 3.4 (page 9), 1st paragraph -- Ref. tag
The text:
vvvvvvvv
| Unsolicited notifications [Protocol, Section 4.4] offer a capability
for the server to notify the client of events not associated with the
operation currently being processed.
should say:
| Unsolicited notifications [RFC4511, Section 4.4] offer a capability
for the server to notify the client of events not associated with the
operation currently being processed.
(7) Section 4 (page 9) -- Ref. tags
The text:
vvvvvvvv
| LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
| definition [Protocol, Appendix B] to be made.
^^^^^^^^
should say:
| LDAP allows limited extension [RFC4511, Section 4] of the LDAP ASN.1
| definition [RFC4511, Appendix B] to be made.
(8) Section 5 (page 10), 1st paragraph -- Ref. tag
The text:
Extensions defining LDAP schema elements SHALL provide schema
| definitions conforming with syntaxes defined in [Models, Section
4.1]. [...]
^^^^^^
should say:
Extensions defining LDAP schema elements SHALL provide schema
| definitions conforming with syntaxes defined in [RFC4512, Section
4.1]. [...]
(9) Section 9.1 (page 13) -- duplicate entry
The entry at the bottom of page 13,
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
should be deleted.
This entry is a duplicate, and it recurs on page 14, at the proper
place according to the collation order (by ascending RFC#).
Notes:
Most important issue:
Apparently, the update of the Reference tags within the text has
been performed incompletely after the assignment of RFC numbers
to those many LDAP I-Ds, leaving 'unsatisfied' tags in the text
(not listed in the References Sections), wherever these tags give
detailed citations, specifying a section or an Appendix there.
The errata detail items below are listed in textual order.
I use change bars and tag lines to emphasize the corrections
proposed and/or the issues in the original text.
Changed text is re-adjusted to conform to RFC formatting rules.
from pending
Errata ID: 68
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Held for Document Update by: Peter Saint-Andre
(1) referential inconsistency
The second paragraph of Section 1, on page 3 of RFC 4524, says:
In the years that followed, X.500 Directory Services have evolved to
incorporate new capabilities and even new protocols. In particular,
the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
introduced in the early 1990s [RFC1487], with Version 3 of LDAP
introduced in the late 1990s [RFC2251] and subsequently revised in
| 2005 [RFC4510].
It should say:
In the years that followed, X.500 Directory Services have evolved to
incorporate new capabilities and even new protocols. In particular,
the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
introduced in the early 1990s [RFC1487], with Version 3 of LDAP
introduced in the late 1990s [RFC2251] and subsequently revised in
| 2006 [RFC4510].
^
(Rationale: RFC 451x and RFC 452x have been published in June 2006.)
(2) typos
(2a) The third paragraph of Section 1, on page 3 of RFC 4524, says:
| While much of the material in RFC 1274 has been superceded by
subsequently published ITU-T Recommendations and IETF RFCs, [...]
It should say:
v
| While much of the material in RFC 1274 has been superseded by
subsequently published ITU-T Recommendations and IETF RFCs, [...]
(2b) The third paragraph of Section 1.1, on page 3, says:
The description of the 'domain' object class provided in this
| document supercedes that found in RFC 2247. That is, Section 3.4 of
this document replaces Section 5.2 of [RFC2247].
It should say:
The description of the 'domain' object class provided in this
| document supersedes that found in RFC 2247. That is, Section 3.4 of
this document replaces Section 5.2 of [RFC2247].
(3) extraneous (duplicated) text
Within Section 3.1 of RFC 4524, the first line on page 14,
3.3. documentSeriesExample:
should say:
Example:
(4) incomplete information
Within Appendix A of RFC 4524, I miss a note describing the fate
of the 'pilotOrganization' object class (RFC 1274, Section 8.3.13).
Kurt:
For completeness, it would be nice if you could provide
supplementary text (similar to, and perhaps to be inserted
after, section A.3 of RFC 4524) detailing the intentions of
the authors regarding that object class.
Notes:
RFC 451x and RFC 452x have been published in June 2006.
from pending
Errata ID: 67
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15
Section 4 says:
Subject: Request for LDAP Protocol Mechanism Registration Object
Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
RFC 4526 Author/Change Controller: IESG Comments: none
It should say:
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.3
Description: True/False filters
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFC 4526
Author/Change Controller: IESG
Comments: none
Notes:
--VERIFIER NOTES--
Although the RFC text has unfortunate line breaks, the registration with the IANA is accurate at http://www.iana.org/assignments/ldap-parameters
Errata ID: 66
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov
Section 1 says:
The control may be attached to any update operation to support conditional addition, deletion, modification, and renaming of the target object. The asserted condition is evaluated as an integral part the operation.
It should say:
The control may be attached to any update operation to support
conditional addition, deletion, modification, and renaming of the
target object. The asserted condition is evaluated as an integral
| part of the operation.
^^^^
Notes:
from pending
Errata ID: 853
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-09-02
Section 3 says:
When the control is attached to an LDAP request, the processing of the request is conditional on the evaluation of the Filter as applied against the target of the operation. If the Filter evaluates to TRUE, then the request is processed normally. If the Filter evaluates to FALSE or Undefined, then assertionFailed (122) resultCode is returned, and no further processing is performed.
It should say:
When the control is attached to an LDAP request, the processing of the request is conditional on the evaluation of the Filter as applied against the target of the operation. If the Filter evaluates to TRUE, then the request is processed normally. If the Filter | evaluates to FALSE or Undefined, then the assertionFailed (122) resultCode is returned, and no further processing is performed.
Notes:
Missing an article.
Errata ID: 65
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-09-02
Section 3 says:
Servers indicate their support for this extended operation by
providing a whoamiOID object identifier as a value of the
'supportedExtension' attribute type in their root DSE. The server
SHOULD advertise this extension only when the client is willing and
^^^^^^^^^^
able to perform this operation.
It should say:
Servers indicate their support for this extended operation by
providing a whoamiOID object identifier as a value of the
'supportedExtension' attribute type in their root DSE. The server
SHOULD advertise this extension only when it is willing
^^
and able to perform this operation.
Notes:
As far as I can see, the last sentence there is misleading and
does not match the operational scenario; and hence, it should be
clarified. According to the recommendations given, the client
will not try the operation if the OID is not offered by the server,
and hence the server cannot know whether the client is willing
to send the whoami Request; and in this case, the *server* will
perform the operation, i.e., send the whoami Response.
Errata ID: 940
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Verifier Name: Tim Polk
Date Verified: 2008-11-20
Section B.4 says:
omission in ASN.1 module
Section B.3, on pp. 20/21, gives a textual introduction with ASN.1
snippits to, and Section B.4, on pp. 21/22 gives the formal ASN.1
module for, GSAKMPv1 De-Registration.
Unfortunately, there's a significant inconsistency between these
two sources of data structure and syntax.
On page 20, in Section B.3 the RFC says:
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
| terse BOOLEAN,
transport Transport
}
On page 21, in Section B.4 the RFC says:
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
transport Transport
}
Obviously, the line
terse BOOLEAN,
has been lost on its way into the ASN.1 module, and should be
re-inserted to make it consistent with the text.
Notes:
from pending
Errata ID: 942
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14
Section B.5.7 says:
On page 26, defines:
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
| sGCKSContent OCTET STRING
}
It should say:
Add the following clarification immediately after the ASN.1: The OCTET STRING in each of these is an opaque blob whose processing is subsequently defined in the vendor or domain-specific types.
Notes:
Whereas the subsequent definitions in B.5.7.{1,2} define the syntax
of two possible instantiations of SubGCKSInfo, with syntax NULL and
SEQUENCE { ... }, respectively, for the sGCKSContent element.
Again, that doesn't match!
Errata ID: 2351
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14
Section B.5.4 says:
On page 24, defines:
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
| rekeyMethodInfo OCTET STRING
}
It should say:
Add the following clarification immediately after the ASN.1: The OCTET STRING in each of these is an opaque blob whose processing is subsequently defined in the vendor or domain-specific types.
Notes:
Why doesn't it use the "ANY DEFINED BY ..." syntax construct for
'rekeyMethodInfo' ?
Subsequent definitions in B.5.4.{1,2} define the syntax of
two possible instantiations of RekeyMethod, with syntax NULL
and INTEGER, respectively, for the rekeyMethodInfo element.
That doesn't match!
Errata ID: 2352
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14
Section B.5.6 says:
On page 25, defines:
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
| reliabilityMechContent OCTET STRING
}
The reliability mechanism is defined by an OBJECT IDENTIFIER and the
information needed to operate that mechanism is defined as
| reliabilityMechContent and is an OCTET STRING (as before).
It should say:
Add the following clarification immediately after last paragraph: The OCTET STRING in each of these is an opaque blob whose processing is subsequently defined in the vendor or domain-specific types.
Notes:
whereas the subsequent definitions in B.5.6.{1,2,3} define the syntax
of three possible instantiations of Reliability, with syntax NULL,
INTEGER, and IA5String, respectively, for the reliabilityMechContent
element.
Again, that doesn't match!
Errata ID: 2371
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Sections B.5.6.1 and B.5.6.2, on page 25, talk about [the reliability of] the "networks", where the text apparently should talk about [the reliability of] the "transports" (3 instances).
Errata ID: 2372
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section C.2 says:
In the ASN.1 module of Section C.2, the IMPORTS clause on page 31
contains an unneeded object name and ID (perhaps copied-and-pasted
from other ASN.1 modules).
The current text is:
IMPORTS
LifeDate
| FROM PolicyToken {1.3.6.1.5.5.12.0.1}
|
| KeyIdentifier
| FROM PKIX1Implicit88 { iso(1) identified-organization(3)
| dod(6) internet(1) security(5) mechanisms(5) pkix(7)
| id-mod(0) id-pkix1-implicit(19) };
It should say:
This text should be shortened to just say:
IMPORTS
LifeDate
| FROM PolicyToken {1.3.6.1.5.5.12.0.1};
Errata ID: 64
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
There are three terminology issues
a)
The combination of the two roles of "Group Controller" and
"Key Server" is usually abbreviated as "GC/KS" , and such
does RFC 4534. Consistently, the full expansion should be
spelled "Group Controller / Key Server" to match the "/"
present in the acronym and to avoid the mis-understandable
unstructured word grouping, "Group Controller Key Server".
This affects Section 3.2, in the second line on page 7, and
the second line of Section B.1.1, on page 13.
b)
IMHO, the wording, "[the] rekey" is sluggish and should be
replaced by "[the] rekeying".
This affects the Section titles,
"3.3. Rekey Policy", that better should be: "3.3. Rekeying Policy"
as well as
"B.5. GSAKMPv1 Rekey Policy" and all
"B.5.*. Rekey ___" , and
"B.6. GSAKMPv1 Rekey Policy ASN.1 Module"
Other changes:
"rekey protocol" --> "rekeying protocol" and
"rekey message" --> "rekeying message" (Section 3, page 5),
"Rekey SA" --> "Rekeying SA" and
"During Rekey," --> "During Rekeying," (Section 3.3, page 7),
"Rekey SAs" --> "Rekeying SAs" (Appendix B, page 13),
"Rekey Protocol" --> "Rekeying Protocol" (2x) ,
"rekey policy" --> "rekeying policy" (2x) ,
"rekey messages" --> "rekeying messages" ,
"rekey event" --> "rekeying event" (2x) ,
"rekey message" --> "rekeying message" ,
"rekey interval" --> "rekeying interval" ,
"rekey process" --> "rekeying process" ,
"the rekey" --> "the rekeying" ,
"rekey delivery" --> "rekeying delivery" ,
"handle rekey." --> "handle rekeying." , (all in B.5., on page 22),
etc. ...
"
Notes:
from pending
Errata ID: 2368
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Within Section B.1.3.1, the last paragraph on page 16 is unexpectedly
partially indented.
The RFC says:
OpInfo provides configuration data for the operation of GSAKMP
registration. timeOut indicates the elapsed amount of time
before a sent message is considered to be misrouted or lost. It
is specified as the timestamp type LifeDate, previously defined
in the core token. terse informs a GC/KS whether the group
should be operated in terse (TRUE) or verbose (FALSE) mode. The
optional timestamp field indicates whether a timestamp (TRUE) or
a nonce (FALSE) is used for anti-replay protection. If the field
is absent, the use of nonces is the default mode for GSAKMP
registration.
It should say:
OpInfo provides configuration data for the operation of GSAKMP
registration. timeOut indicates the elapsed amount of time before a
sent message is considered to be misrouted or lost. It is specified
as the timestamp type LifeDate, previously defined in the core token.
terse informs a GC/KS whether the group should be operated in terse
(TRUE) or verbose (FALSE) mode. The optional timestamp field
indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for
anti-replay protection. If the field is absent, the use of nonces is
the default mode for GSAKMP registration.
It should say:
It should say: OpInfo provides configuration data for the operation of GSAKMP registration. timeOut indicates the elapsed amount of time before a sent message is considered to be misrouted or lost. It is specified as the timestamp type LifeDate, previously defined in the core token. terse informs a GC/KS whether the group should be operated in terse (TRUE) or verbose (FALSE) mode. The optional timestamp field indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for anti-replay protection. If the field is absent, the use of nonces is the default mode for GSAKMP registration.
Errata ID: 2370
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section B.5.4.2, on page 24, says:
v
| The GSAKMP protocol specification defined an interpretation of the
Logical Key Hierarchy (LKH) protocol as a rekey method. [...]
It should say:
It should say:
v
| The GSAKMP protocol specification defines an interpretation of the
Logical Key Hierarchy (LKH) protocol as a rekey method. [...]
Errata ID: 2369
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section B.5.4.1, on page 24, says:
vv vvv
| The group defined to work without a rekey protocols supporting it is
supported by the rekeyMethodType NONE. [...]
It should say:
It should say:
vvvv vv
| The group defined to work without a rekeying protocol supporting it
is supported by the rekeyMethodType NONE. [...]
Errata ID: 2367
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
In section 3.4, on page 8, the RFC says:
[...]. There are several protocols
that could make use of group keys, ranging from simple security
| applications that only need key for encryption and/or integrity
protection to more complex configurable security protocols such as
IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. [..]
It should say:
It should say:
[...]. There are several protocols
that could make use of group keys, ranging from simple security
| applications that only need a key for encryption and/or integrity
protection to more complex configurable security protocols such as
IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. [..]
Errata ID: 63
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Morten Jagd Christensen
Date Verified: 2006-11-13
Section 3 says:
Additionally, if a non-Querier switch spoofs any General Queries (as addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the null IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process.
It should say:
Additionally, if a non-Querier switch spoofs any General Queries (as addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the unspecified IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process.
Notes:
The term, "null" IP address is inappropriate, according to the current
IPv6 Address Architecture document. RFC 4541 should use the proper
term, "unspecified" address (cf. Section 2.5.2 of RFC 4291).
from pending
Errata ID: 914
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Morten Jagd Christensen
Date Verified: 2006-11-13
Section 3 says:
Initial allocation of IPv6 multicast addresses, as described in [RFC3307], however, cover only the lower 32 bits of group ID.
It should say:
The Initial allocation of IPv6 multicast addresses, as described in [RFC3307], however, covers only the lower 32 bits of group ID.
Notes:
from pending
Errata ID: 1821
Status: Verified
Type: Technical
Reported By: Pasi Eronen
Date Reported: 2009-07-30
Verifier Name: Pasi Eronen
Date Verified: 2009-10-08
Section 9 says:
(nothing)
It should say:
The following text should have been included in Section 9: For the negotiation of AES-GMAC in AH with IKEv1, the following values have been assigned in the IPsec AH Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use different transform identifiers. "11" for AH_AES-128-GMAC "12" for AH_AES-192-GMAC "13" for AH_AES-256-GMAC In addition, the following values have been assigned in the Authentication Algorithms registry (in isakmp-registry): "11" for AES-128-GMAC "12" for AES-192-GMAC "13" for AES-256-GMAC For the negotiation of AES-GMAC in ESP with IKEv1, the following value has been assigned from the IPsec ESP Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a different transform identifier. "23" for ESP_NULL_AUTH_AES-GMAC
Notes:
Found by Soo-Fei Chew (ipsec@ietf.org list, 2009-04-09);
approved by IESG in 2009-06-04 telechat.
Errata ID: 62
Status: Verified
Type: Editorial
Reported By: David McGrew
Date Reported: 2006-07-06
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 7 says:
In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the plaintext or the additional authenticated data.
It should say:
In AES-GCM-ESP, the IV is not included in either the plaintext or the additional authenticated data.
Notes:
This error might confuse the reader because it makes the text
contradict Figure 4.
Errata ID: 1921
Status: Verified
Type: Editorial
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Russ Housley
Date Verified: 2010-03-11
Section 11 says:
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST. http://
csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
gcm-spec.pdf, January 2004.
It should say:
[GCM] Dworkin, M. "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007.
Notes:
The original link is dead.
Errata ID: 1636
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19
The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
<<page break>>
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the header is being used."
The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the header is CRC32c."
The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the data is being used."
The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the data is CRC32c."
Notes:
The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
Errata ID: 1637
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Verifier Name: Lars Eggert
Date Verified: 2008-12-19
The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| method being used on this session, as communicated
during the login phase."
It should say:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| identity being used on this session, as communicated
during the login phase."
Errata ID: 1638
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Held for Document Update by: Lars Eggert
Date Held: 2008-12-19
(1) outdated text
Within Section 6, the first paragraph on top of page 5 says:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module, currently under development,
may be used to manage SCSI information for a device.
The last apparently sentence is outdated. There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module [RFC4455] may be used to manage
SCSI information for a device.
^^^^^^^^^^^
(3) 4 similar typos
The DESCRIPTION clause of the iscsiInstSsnFailures OBJECT-TYPE,
on page 20 of RFC 4544, says:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has been failed. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has failed. If this counter has suffered a
discontinuity, the time of the last discontinuity is indicated
in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
(4) incomplete descriptions
Within the Target Attributes Table, the objects
iscsiTgtLastFailureType,
iscsiTgtLastIntrFailureName,
iscsiTgtLastIntrFailureAddrType, and
iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
- should not be instantiated
or
- have a certain default value (t.b.d.)
in this case.
A similar issue holds for the objects in the Initiator Attributes
Table,
iscsiIntrLastFailureType,
iscsiIntrLastTgtFailureName,
iscsiIntrLastTgtFailureAddrType, and
iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)
(5) row creation / storageType restriction
Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):
[...]. Rows in this table that were
created through an external process may have a storage type of
readOnly or permanent.
It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.
(6) unpleasant alignment
Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
o IscsiPortalAttributesEntry,
o IscsiInitiatorAttributesEntry, and
o IscsiInitiatorLoginStatsEntry
(7) Semantic gap in Initiator Login Stats Table ??
The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.
Errata ID: 61
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(9) common problem with indiscontinuity tagging
The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,
[...]
If this counter has suffered a discontinuity, the time of the
last discontinuity is indicated in iscsiSsnDiscontinuityTime."
Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.
Notes:
--VERIFIER NOTES--
Item (9) - the situation in which "one of the LC counters wraps back to
zero" is a regular increment of a continuous counter, i.e., it
is not a discontinuity. Thus, this item is unfounded.
Errata ID: 1630
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(1) outdated text
Within Section 6, the first paragraph on top of page 5 says:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module, currently under development,
may be used to manage SCSI information for a device.
The last apparently sentence is outdated. There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module [RFC4455] may be used to manage
SCSI information for a device.
^^^^^^^^^^^
(2) lack of distinguishing DESCRIPTION text
The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
This obviously needs short-term correction, e.g.:
The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
<<page break>>
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the header is being used."
The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the header is CRC32c."
The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the data is being used."
The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the data is CRC32c."
(3) 4 similar typos
The DESCRIPTION clause of the iscsiInstSsnFailures OBJECT-TYPE,
on page 20 of RFC 4544, says:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has been failed. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has failed. If this counter has suffered a
discontinuity, the time of the last discontinuity is indicated
in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
(4) incomplete descriptions
Within the Target Attributes Table, the objects
iscsiTgtLastFailureType,
iscsiTgtLastIntrFailureName,
iscsiTgtLastIntrFailureAddrType, and
iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
- should not be instantiated
or
- have a certain default value (t.b.d.)
in this case.
A similar issue holds for the objects in the Initiator Attributes
Table,
iscsiIntrLastFailureType,
iscsiIntrLastTgtFailureName,
iscsiIntrLastTgtFailureAddrType, and
iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)
(5) row creation / storageType restriction
Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):
[...]. Rows in this table that were
created through an external process may have a storage type of
readOnly or permanent.
It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.
(6) unpleasant alignment
Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
o IscsiPortalAttributesEntry,
o IscsiInitiatorAttributesEntry, and
o IscsiInitiatorLoginStatsEntry
(7) Semantic gap in Initiator Login Stats Table ??
The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.
(8) typo?
The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| method being used on this session, as communicated
during the login phase."
I strongly suspect that it should say instead:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| identity being used on this session, as communicated
during the login phase."
(9) common problem with indiscontinuity tagging
The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,
[...]
If this counter has suffered a discontinuity, the time of the
last discontinuity is indicated in iscsiSsnDiscontinuityTime."
Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.
Notes:
from pending
--VERIFIER NOTES--
duplicate of Errata #61
Errata ID: 1631
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-07-04
Rejected by: Lars Eggert
Date Rejected: 2008-12-19
(1) outdated text
Within Section 6, the first paragraph on top of page 5 says:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module, currently under development,
may be used to manage SCSI information for a device.
The last apparently sentence is outdated. There already is an
appropriate Informative Reference given on page 81 of the RFC.
The RFC should say:
It is worthwhile to note that this is an iSCSI MIB module and as such
reflects only iSCSI objects. This module does not contain
information about the SCSI-layer attributes of a device. If a SCSI
| layer is present, the SCSI MIB module [RFC4455] may be used to manage
SCSI information for a device.
^^^^^^^^^^^
(2) lack of distinguishing DESCRIPTION text
The iscsiDescriptors OBJECT-IDENTITY declarations, on page 16/17
of the RFC, unfortunately contain pairwise identical DESCRIPTION
clauses, making Header and Data Integrity identifiers
indistinguishable.
This obviously needs short-term correction, e.g.:
The DESCRIPTION clause of the iscsiHdrIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
<<page break>>
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the header is being used."
The DESCRIPTION clause of the iscsiHdrIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the header is CRC32c."
The DESCRIPTION clause of the iscsiDataIntegrityNone OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when no integrity
| scheme (for either the header or data) is being
used."
should better say:
DESCRIPTION
"The authoritative identifier when no integrity
| scheme for the data is being used."
The DESCRIPTION clause of the iscsiDataIntegrityCrc32c OBJECT-IDENTITY,
DESCRIPTION
"The authoritative identifier when the integrity
| scheme (for either the header or data) is CRC32c."
should better say:
DESCRIPTION
"The authoritative identifier when the integrity
| scheme for the data is CRC32c."
(3) 4 similar typos
The DESCRIPTION clause of the iscsiInstSsnFailures OBJECT-TYPE,
on page 20 of RFC 4544, says:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has been failed. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
"This object counts the number of times a session belonging
| to this instance has failed. If this counter has suffered a
discontinuity, the time of the last discontinuity is indicated
in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnDigestErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU containing header or data digest errors. If this
counter has suffered a discontinuity, the time of the last
discontinuity is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE,
on page 22 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to a sequence
exceeding a time limit. If this counter has suffered a
discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
The DESCRIPTION clause of the iscsiInstSsnFormatErrors OBJECT-TYPE,
on page 23 of RFC 4544, says:
DESCRIPTION
| "The count of sessions that were failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
It should better say:
DESCRIPTION
| "The count of sessions that failed due to receipt of
a PDU that contained a format error. If this counter has
suffered a discontinuity, the time of the last discontinuity
is indicated in iscsiInstDiscontinuityTime."
(4) incomplete descriptions
Within the Target Attributes Table, the objects
iscsiTgtLastFailureType,
iscsiTgtLastIntrFailureName,
iscsiTgtLastIntrFailureAddrType, and
iscsiTgtLastIntrFailureAddr
apparently have no meaningful value if no error has occurred (yet).
The DESCRIPTION clauses for these objects, on page 38/39 of RFC 4544,
do not indicate the behaviour of these objects in this case, i.e.,
when the iscsiTgtLastFailureTime instance in a given conceptual
row has the value zero.
The respective DESCRIPTION clauses should indicate whether these
objects
- should not be instantiated
or
- have a certain default value (t.b.d.)
in this case.
A similar issue holds for the objects in the Initiator Attributes
Table,
iscsiIntrLastFailureType,
iscsiIntrLastTgtFailureName,
iscsiIntrLastTgtFailureAddrType, and
iscsiIntrLastTgtFailureAddr
(The corresponding DESCRIPTIONS can be found on page 46/47.)
(5) row creation / storageType restriction
Various tables contain rows that can be created/deleted dynamically.
Repeatedly, for these tables the DESCRIPTION clauses for the
corresponding StorageType objects contain the sentence
(e.g., for iscsiTgtAuthStorageType, on page 44):
[...]. Rows in this table that were
created through an external process may have a storage type of
readOnly or permanent.
It is not clear from the text what precisely 'external process'
means, and therefore it remains open whether/why the restriction
on values `readOnly` or `permanent` makes sense.
(6) unpleasant alignment
Any future update to this RFC should correct the unpleasant
staggered tabular alignment of the following row-structure
( SEQUENCE { ... } ) declarations for:
o IscsiPortalAttributesEntry,
o IscsiInitiatorAttributesEntry, and
o IscsiInitiatorLoginStatsEntry
(7) Semantic gap in Initiator Login Stats Table ??
The Initiator Login Stats Table somehow is a "dual" of the
Target Login Stats Table.
Therefore, I miss an object in the Initiator Login Stats Table
corresponding to iscsiTgtLoginAuthorizeFails, counting received
Login Response PDUs with status class 0x202.
(8) typo?
The DESCRIPTION clause of the iscsiSsnAuthIdentity OBJECT-TYPE,
on page 58 of the RFC, says:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| method being used on this session, as communicated
during the login phase."
I strongly suspect that it should say instead:
DESCRIPTION
"This object contains a pointer to a row in the
IPS-AUTH MIB module that identifies the authentication
| identity being used on this session, as communicated
during the login phase."
(9) common problem with indiscontinuity tagging
The Session Stats Table defines and admits High-Capacity (64-bit)
and Low-Capacity (32-bit) octet counters.
If both types of counters are implemented, according to the
DESCRIPTION clauses of all these counters,
[...]
If this counter has suffered a discontinuity, the time of the
last discontinuity is indicated in iscsiSsnDiscontinuityTime."
Hence, iscsiSsnDiscontinuityTime must indicate discontinuities
in the HC and the LC counters, i.e. it must be changed whenever
one of the LC counters wraps back to zero, making it almost
useless for efficient surveillance of discontinuities in all
the other counters covered by this object.
Perhaps, as it has been done in a few other IETF MIBs in the past,
inclusion of additional 32-bit counters yielding the high part
(most significant 32 bits) of the HC counters for use with SNMPv1
management stations would have allowed to change the semantics of
iscsiSsnDiscontinuityTime to avoid too frequent changes.
Notes:
from pending
--VERIFIER NOTES--
duplicate of Errata #61
Errata ID: 60
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-06-29
Held for Document Update by: Lars Eggert
(1) typo in Abstract
The Abstract, on page 1 of RFC 4545, contains the sentence:
[...]
In particular, it defines objects for managing user identities and
| the names, addresses, and credentials required manage access control,
for use with various protocols. [...]
The text should say (filling in the missing 'to'):
In particular, it defines objects for managing user identities and
| the names, addresses, and credentials required to manage access
control, for use with various protocols. [...]
(2) typo in Section 5
The first paragraph of Section 5, on page 4 of RFC 4545, says:
The User-based Security Model (USM) [RFC3414] also defines the
concept of a user, defining authentication and privacy protocols and
their credentials. The definition of USM includes the SNMP-USER-
| BASED-SM-MIB module allows configuration of SNMPv3 user credentials
to protect SNMPv3 messages. [...]
The text should say (filling in the missing 'that'):
The User-based Security Model (USM) [RFC3414] also defines the
concept of a user, defining authentication and privacy protocols and
their credentials. The definition of USM includes the SNMP-USER-
| BASED-SM-MIB module that allows configuration of SNMPv3 user
credentials to protect SNMPv3 messages. [...]
(3) clarification in Section 7
The first paragraph of Section 7, on page 5 of RFC 4545, says:
| This MIB module structure is intended to allow the configuration of a
list of user identities, each with a list of names, addresses,
| credentials, and certificates that, when combined, will distinguish
that identity.
The wording should be enhanced, and the reference to certificates
should be removed -- these apparently have been excluded from the
MIB in the published version.
Therefore, the text should perhaps better say:
| This MIB module's structure is intended to allow the configuration of
a list of user identities, each with a list of names, addresses, and
| credentials that, when combined, will distinguish that identity.
(4) improper DESCRIPTION text
The DESCRIPTION clause for the ipsAuthIdentAddrAttributesTable
OBJECT-TYPE, on page 19, says:
DESCRIPTION
"A list of address ranges that are allowed to serve
as the endpoint addresses of a particular identity.
An address range includes a starting and ending address
| and an optional netmask, and an address type indicator,
which can specify whether the address is IPv4, IPv6,
FC-WWPN, or FC-WWNN."
This text improperly mentions the use of netmasks, which has been
explicitely excluded from the MIB module, as can be seen from the
subsequent IpsAuthIdentAddrAttributesEntry syntax, and as explained
in the last paragraph of Section 7.5, on page 8 of the RFC.
Therefore, this clause should say:
DESCRIPTION
"A list of address ranges that are allowed to serve
as the endpoint addresses of a particular identity.
An address range includes a starting and ending address,
| and an address type indicator, which can specify whether
the address is IPv4, IPv6, FC-WWPN, or FC-WWNN."
(5) redundant MIB objects -- serious danger of inconsistency
Conceptually, rows of the ipsAuthCredChap, ipsAuthCredSrp, and
ipsAuthCredKerberos tables are a variant record (union in "C")
contained in the corresponding rows of the ipsAuthCredential table.
The DESCRIPTION clauses make clear, that the 'life' of the former
table rows is directly coupled to the 'life' of the latter rows --
for example, the DESCRIPTION clause of the ipsAuthCredAuthMethod
OBJECT-TYPE says:
When a row is created in this table, a corresponding
row must be created by the management station
in a corresponding table specified by this value.
When a row is deleted from this table, the corresponding
row must be automatically deleted by the agent in
the corresponding table specified by this value.
IMHO, it is inconsistent to have the agent delete the row, but
let the management station create the row; the SETting of an
ipsAuthCredAuthMethod object should create the corresponding row.
According to this explanantion and the identical indexing structure
of the four tables, the agent thus is directed to maintain exactly
one of those variant rows, matching the current value of a given
ipsAuthCredAuthMethod instance.
In the published version of the IPS-AUTH-MIB module, the rows
of the basic ipsAuthCredentialAttributesTable contains objects of
RowStatus and StorageType syntax that are used to create/activate/
delete an ipsAuthCredentialAttributesEntry conceptual row, and to
specify the persistence behaviour of that row, respectively.
Therefore, IMHO it makes no sense, and it entails the danger of
fundamental semantic inconsistencies in the MIB module, to also
maintain objects of RowStatus and StorageType syntax in the
variant table rows.
E.g.,
- no `active` row can exist in the ipsAuthCredChapAttributesTable
without a corresponding `active` row in the
ipsAuthCredentialAttributesTable;
- no ipsAuthCredChapAttributesEntry can be created by the manager,
that MUST be done automatically by the agent when the
ipsAuthCredAuthMethod instance is set to ipsAuthMethodChap;
- the ipsAuthCredentialAttributesEntry should be set inactive,
if desired, and not the ipsAuthCredChapAttributesEntry;
- the StorageType of both entries MUST be exactly the same.
Therefore, IMHO the objects
o ipsAuthCredChapRowStatus,
o ipsAuthCredChapStorageType,
o ipsAuthCredSrpRowStatus,
o ipsAuthCredSrpStorageType,
o ipsAuthCredKerbRowStatus, and
o ipsAuthCredKerbStorageType
should be deprecated as soon as possible, and its MAX-ACCESS
changed to read-only, with explanation added to the DESCRIPTION
clauses that the values of these objects (if implemented), are
agent maintained mirrors of the corresponding ipsAuthCredRowStatus
and ipsAuthCredStorageType objects, respectively.
Additionally, it should be specified that a ipsAuthCredRowStatus
instance must not be set to `active` unless the proper credentials
have been set in the appropriate ipsAuthCred* "detail" row.
If it is decided that automatic row creation by the agent should
not be specified for backwards compatibility, at least the
ipsAuthCred*StorageType objects should be deprecated.
(6) clarification in compliance statement
The DESCRIPTION clause of the ipsAuthComplianceV1 MODULE-COMPLIANCE
says:
DESCRIPTION
"Initial version of compliance statement based on
initial version of this MIB module.
The Instance and Identity groups are mandatory;
at least one of the other groups (Name, Address,
| Credential, Certificate) is also mandatory for
any given implementation."
Similar to item (3) above, the reference to 'Certificate' is
inappropriate and should be deleted; additionally, the plural
form of 'Credential' should be used.
Thus, this clause should say:
DESCRIPTION
"Initial version of compliance statement based on
initial version of this MIB module.
The Instance and Identity groups are mandatory;
at least one of the other groups (Name, Address,
| Credentials) is also mandatory for any given
implementation."
(7) incomplete citations
The following References are incomplete according to RFC-Ed policy;
they should be amended by "STD 62, " just before the RFC number.
In Section 11, on page 40, the entry:
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", RFC 3411, December
2002.
should say:
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
In Section 12, on page 41, the entry:
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 3414, December 2002.
should say:
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Notes:
I make use of change bars ('|' in column 1) to emphasize the
location of textual issues and/or proposed textual changes.
Modified text is re-adjusted according to RFC formatting rules.
The items below are listed (and enumerated) in RFC text sequence.
Item (5) apparently is a serious issue.
All other items are simple errata.
from pending
Note: This RFC has been obsoleted by RFC5550
Source of RFC: lemonade (app)
Errata ID: 59
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 1.1 says:
In particular, examples assume that Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they don't show how to deal with absence of an extension.
It should say:
In particular, examples assume that Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they don't show how to deal with the absence of an extension.
Notes:
missing article
Errata ID: 736
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Section 9.2 says:
[IMAP-DISC] Melnikov, A., "Synchronization operations for
disconnected IMAP4 clients", Work in Progress, October
2004.
It should say:
[IMAP-DISC] Melnikov, A., Ed., "Synchronization Operations for
Disconnected IMAP4 Clients", RFC 4549, June 2006.
Notes:
This I-D has been published -- synchronized with RFC 4550 -- as RFC 4549.
from pending
Errata ID: 1767
Status: Verified
Type: Editorial
Reported By: Tony Hansen
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06
Section 2.4.1, 2.4.2 says:
S: a002 OK URLFETCH completed I: a003 LOGOUT S: * BYE See you later S: a003 OK Logout successful
It should say:
I: a002 OK URLFETCH completed S: a003 LOGOUT I: * BYE See you later I: a003 OK Logout successful
Notes:
According to section 1.1 (Conventions Used in This Document):
In examples, "M:", "I:", and "S:" indicate lines sent by the client
messaging user agent, IMAP e-mail server, and SMTP submit server,
respectively.
The exact same error appears in both sections 2.4.1 and 2.4.2.
Errata ID: 2599
Status: Reported
Type: Technical
Reported By: John W. O'Brien
Date Reported: 2010-11-02
Section 3 says:
In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.
It should say:
In order to provide authentication to OSPFv3, implementations MUST support AH and MAY support ESP.
Notes:
Authentication can be provided by an implementation that supports AH only.
Errata ID: 1048
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-03-07
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04
There are two distinct "PWE3 Pseudowire Type" namespaces maintained
by IANA:
- the 'L2TPv3 Pseudowire Types' subregistry of the
"l2tp-parameters" registry, rooted in RFC 3831, and
- the 'MPLS Pseudowire Type' subregistry of the "pwe3-parameters"
registry, rooted in RFC 4446.
From the text of RFC 4553, it might be concluded that it was intended
to make identical PW type allocations in both subregistries for SAToP,
as has been done before in a similar manner in PWE3 RFCs dealing with
"<any> over MPLS PWs" and "<any> over L2TPv3 PWs".
But the IANA Considerations (Section 11) of RFC 4553 simply state,
Allocation of PW types for the corresponding SAToP PWs is defined in
[RFC4446].
... and RFC 4446 has only registered the following assignments for SAToP
over MPLS:
0x0011 Structure-agnostic E1 over Packet [SAToP]
0x0012 Structure-agnostic T1 (DS1) over Packet [SAToP]
0x0013 Structure-agnostic E3 over Packet [SAToP]
0x0014 Structure-agnostic T3 (DS3) over Packet [SAToP]
Looking into the two IANA registries quoted above, it can be seen
that indeed only "pwe3-parameters" contains these assignments,
whereas they are not listed in "l2tp-parameters".
Apparently, this has been overseen by all parties involved!
If this conclusion applies, you should urgently:
(1) submit an Author's RFC Errata Note for RFC 4553 to the RFC-Ed
with an amendment to Section 11, e.g.:
IANA should perform the same assignemnts in the L2TPv3 Pseudowire
Type subregistry.
(2) Request this action from IANA.
Notes:
--VERIFIER NOTES--
The IANA registry has been updated to correctly reflect the assignment of PW types 0x0011 to 0x0014 to RFC4553. Signalling of TDM PWS over L2TPv3 was not specified until RFC5611, thus L2TPv3 PW type assignments were out of scope of RFC4553.
These IANA assignments would not be re-requested in a future version of this document and an implementer would not be misled by the existing IANA text, thus
reject seems to be the most appropriate state for this erratum.
Errata ID: 58
Status: Held for Document Update
Type: Editorial
Reported By: Tom Petch
Date Reported: 2006-10-31
Held for Document Update by: Sean Turner
Section 3 says:
The corresponding padata-value field [RFC4120] contains the DER [X60] encoding of the following ASN.1 type:
It should say:
The corresponding padata-value field [RFC4120] contains the DER [X690] encoding of the following ASN.1 type:
Errata ID: 2912
Status: Reported
Type: Technical
Reported By: Julian Reschke
Date Reported: 2011-08-03
Section 4 says:
Notes:
The "Negotiate" authentication scheme violates basic HTTP principles, in that it attaches information to the connection on which the handshake happened, and furthermore uses syntax in the WWW-Authenticate and Authorization header fields that is in violation of the base ABNF definitions.
Errata ID: 2913
Status: Reported
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2011-08-03
Section 6 says:
Notes:
The Security Considerations require the use of the HTTP header field "Proxy-Support", which is not defined in this document nor registered with IANA.
Errata ID: 1089
Status: Verified
Type: Technical
Reported By: Colin Perkins
Date Reported: 2007-12-06
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 9 says:
IP6-multicast = hexpart [ "/" integer ]
IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
It should say:
IP6-multicast = IP6-address [ "/" integer ]
IP6-address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IP4-address
Notes:
Correct IPv6 ABNF.
Errata ID: 1795
Status: Held for Document Update
Type: Technical
Reported By: Leandro Lucarella
Date Reported: 2009-06-19
Held for Document Update by: Robert Sparks
Section 9 says:
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
It should say:
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
Notes:
The "*" is removed from the 3rd line.
The current RFC accepts any number starting with "1" and followed by
2 or more digits (like 1000 or 123456789) as a valid "decimal-uchar"
because of this error, because "1" 2*(DIGIT) means 2 or more digits
following a "1". The correction, 2(DIGIT) means *exactly* 2 digits
following a "1", which covers the range 100-199.
Errata ID: 2517
Status: Held for Document Update
Type: Technical
Reported By: Victor S. Osipov
Date Reported: 2010-09-13
Held for Document Update by: Robert Sparks
Section 5.14 says:
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.
It should say:
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, and these payload formats are listed in order of preference, with the first format listed being preferred; in that case the first acceptable payload format from the beginning of the list SHOULD be used for the session.
Notes:
The word ‘default‘ is improper here, because payload format is not implied, but explicitly indicated. This may lead to a misunderstanding and confusion.
The corrections are proposed in order to avoid confusion and to give complete clear instructions in case of multiple payload type numbers indicated.
Errata ID: 57
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Colin Perkins
Date Rejected: 2006-11-22
(1) typo
On page 7 of RFC 4566, Section 4.6 says:
The SDP specification recommends the use of the ISO 10646 character
| sets in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole.
It should say:
The SDP specification recommends the use of the ISO 10646 character
| set in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole.
(2) inconsistent specification
Contrary to the text in Section 4.6 (see above), Section 5 of RFC 4566
specifies, at the bottom of page 7:
An SDP session description is entirely textual using the ISO 10646
character set in UTF-8 encoding. SDP field names and attribute names
use only the US-ASCII subset of UTF-8, but textual fields and
attribute values MAY use the full ISO 10646 character set. [...]
These conflicting specifications might become a source of
interoperability problems, and therefore, the conflict should be
resolved by a clarification !!!
Note: Subsequent text in sections 5.* specifies behaviour related
to the "a=charset" attribute required if other charsets than UTF-8
are used in certain fields; therefore, the latter exclusive UTF-8
rule is most probably too restrictive and hence inappropriate.
(3) misleading text / inconsistency + typo (missing article)
Still in Section 5, the second-to-last paragraph on page 8 of RFC 4566
says:
An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level
| section. Each media-level section starts with an "m=" line and
| continues to the next media-level section or end of the whole session
description. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value.
The second sentence does not accomodate for an important corner case
mentioned in the first sentence, and thus should be amended with
similar wording as below. The third sentence is imprecise as well,
because the "or" does not uniquely select the 'right' condition.
It should better say:
An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level
| section (or the end of the whole description, whichever comes first).
Each media-level section starts with an "m=" line and continues to
| the next media-level section or the end of the whole session
| description - whichever comes first. In general, session-level
values are the default for all media unless overridden by an
equivalent media-level value.
(4) significant mis-specification
In the "Session description" block, on top of page 9, the RFC says:
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
It should say:
c=* (connection information -- not required if included in
all media descriptions)
b=* (zero or more bandwidth information lines)
Rationale:
Strictly differentiating between "media" and "media description"
is always required to avoid confusion! ...
And connection information is rarely (if ever) seen in the media!
(5) improper wording related with IP addresses
IP addresses (in IPv4 and IPv6) are always assigned to an interface,
not to a host or 'machine'. Therefore, a Standards Track RFC
should never talk about '*the* IP address of a machine'.
FQDNs are also not necessarily unique for a 'machine', e.g. a server
having multiple, 'role-based' FQDNs.
Therefore, in Section 5.2, the last paragraph on page 11,
| <unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either
| the fully qualified domain name of the machine or the dotted-
| decimal representation of the IP version 4 address of the machine.
| For an address type of IP6, this is either the fully qualified
domain name of the machine or the compressed textual
| representation of the IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
| SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
should say:
| <unicast-address> is an address of the machine from which the
session was created. For an address type of IP4, this is either
| a fully qualified domain name of the machine or the dotted-
| decimal representation of an IP version 4 address of the machine.
| For an address type of IP6, this is either a fully qualified
domain name of the machine or the compressed textual
| representation of an IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
| SHOULD be given unless this is unavailable, in which case a
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
(6) improper term used
a)
Section 5.6 twice uses the term, "conference", where IMHO, according
to the definitions given in Section 2, the term, "session" should
be used. This change makes the text better conform with the
classification of the "e=" and "p=" lines on page 9, as well.
The first textual paragraph of Section 5.6, on page 13, says:
The "e=" and "p=" lines specify contact information for the person
| responsible for the conference. This is not necessarily the same
| person that created the conference announcement.
It should say:
The "e=" and "p=" lines specify contact information for the person
| responsible for the session. This is not necessarily the same person
| that created the session announcement.
b)
Another instance of this issue occurs in Section 5.7, at the bottom
of page 14. There, the RFC says:
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
| which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. [...]
It should say:
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
| which multicast packets sent in this session will be sent. TTL
values MUST be in the range 0-255. [...]
c)
Finally, the last sentence of the second paragraph of Section 5.13,
on page 21,
[...]. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
to the conference as a whole rather than to individual media.
should say, accordingly:
[...]. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
| to the session as a whole rather than to individual media.
(7) clarification
The second paragraph of Section 5.9, on page 17, says:
The first and second sub-fields give the start and stop times,
respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds
since 1900 [13]. To convert these values to UNIX time, subtract
decimal 2208988800.
To make the time base unique and absolute, the time zone (UTC) needs to
be specified.
Hence, the RFC should say:
The first and second sub-fields give the start and stop times,
respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds
| since 1900, UTC [13]. To convert these values to UNIX time, subtract
decimal 2208988800.
(8) typo (missing article)
The second text paragraph of section 5.10, on page 18, says:
To make description more compact, times may also be given in units of
days, hours, or minutes. [...]
It should say:
| To make the description more compact, times may also be given in
units of days, hours, or minutes. [...]
(9) legacy term not replaced
Since the advent of SIP and the Offer/Answer Model for SDP, it is
no more appropriate, in a general context, to name a
'session description' just a 'session announcement'.
The final paragraph of Section 5.11, on page 19, says:
If a session is likely to last several years, it is expected that the
session announcement will be modified periodically rather than
transmit several years' worth of adjustments in one session
announcement.
It should say therefore:
If a session is likely to last several years, it is expected that the
| session description will be modified periodically rather than
| transmitting several years' worth of adjustments in one session
| description.
(10) clarification of 'charset' related terminology, plus typos
Section 5.13 makes use of legacy terminology related to character
sets and "charsets". It should use the stable, IESG policy based
IETF terminology.
a)
Hence, the first paragraph on page 22:
Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
values are to be interpreted as in ISO-10646 character set with UTF-8
encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset
rather than in ISO-10646.
should better say:
Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
| values are to be interpreted as in the ISO-10646 character set with
UTF-8 encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset
rather than in UTF-8.
Note: RFC 1815 has been deprecated; 'ISO-10646' is *not* considered a
"charset", whereas 'UTF-8' is.
b)
In Section 6, at the bottom of page 28, the RFC says:
a=charset:<character set>
This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP
attribute:
a=charset:ISO-8859-1
The above headline should say:
a=charset:<charset>
or perhaps even better:
a=charset:<IANA-charset>
and the text body above should be changed to say:
| This specifies the character set and encoding ("charset") to be
| used for the session name and information data. By default,
| the ISO-10646 character set in UTF-8 encoding (charset "UTF-8")
is used. If a more compact representation is required, other
| charsets may be used. For example, the ISO 8859-1 charset is
specified with the following SDP attribute:
[...]
Note: The session description does not determine how parts of it
are *displayed* (theres may be some transcoding used, and fonts
or typefaces, etc., the charset must only be specified for SDP.)
The subsequent text on page 29,
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting
mechanism that prevents these bytes from appearing within text
fields.
should be changed to say (fixing typos as well):
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
| with IANA, such as ISO-8859-1. The charset identifier is a
US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
| Note that a charset specified MUST still prohibit the use of
| bytes 0x00 (NUL), 0x0A (LF), and 0x0D (CR). Charsets requiring
the use of these characters MUST define a quoting mechanism
that prevents these bytes from appearing within text fields.
(11) language related issues, plus typos
The RFC text on pp. 29/30 does not properly distinguish between, and
messes up, the specifics of session content (and its language[s]) and
the session *description* content (and the language[s] used therein).
Note: I show more context than absolutely necessary to perform the
recommended changes, to make these better understandable.
a)
On mid-page 29, RFC 4566 says:
a=sdplang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
| multiple languages in the session description or media use
| multiple languages, in which case the order of the attributes
| indicates the order of importance of the various languages in
| the session or media from most important to least important.
(The last half-sentence is wrong and inappropriate.)
It should better say:
a=sdplang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
| multiple languages in the session or media description use
| multiple languages.
b)
Skipping one paragraph, the next one says:
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
| when a session is of sufficient scope to cross geographic
boundaries where the language of recipients cannot be assumed,
| or where the session is in a different language from the
locally assumed norm.
It should say:
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
| when a session description is of sufficient scope to cross
geographic boundaries where the language of recipients cannot
| be assumed, or where the session description is in a different
language from the locally assumed norm.
c)
Next, in the explanations for:
a=lang:<language tag>
extending from page 29 to page 30,
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
<<page break>>
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
| the session description or media use multiple languages, in
which case the order of the attributes indicates the order of
importance of the various languages in the session or media
from most important to least important.
should be corrected to say:
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
<<page break>>
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
| the session or media use multiple languages, in which case the
order of the attributes indicates the order of importance of
| the various languages in the session or media, from most
important to least important.
Note: In the meantime (since the publication of RFC 4566), RFC 3066
has been superseded by RFC 4646 plus RFC 4647, now together denoted
as BCP 47.
(12) typo
On page 31, in the second paragraph of Section 7, RFC 4566 says:
[...]. Many different transport protocols may be used to
distribute session description, and the nature of the authentication
will differ from transport to transport. [...]
It should say:
[...]. Many different transport protocols may be used to
| distribute session descriptions, and the nature of the authentication
will differ from transport to transport. [...]
(13) SDP Grammar issues (ABNF in Section 9, p. 39 ff.),
a)
The rule for 'repeat-interval' (page 41) could easily have
re-used (incorporated) the 'integer' rule:
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
is equivalent to:
repeat-interval = integer [fixed-len-time-unit]
b)
The rule for FQDN, at the bottom of page 42, is wrong;
FQDNs really should allow up to 255 characters!
v
| FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
Because details are not gived (can be found at other places),
this rule should perhaps be only minimally corrected to say:
| FQDN = *(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
At a minimum, serious issues should be addressed,
e.g. (2), (10), (11), and the ABNF mistake (13b).
Notes:
from pending
--VERIFIER COMMENT--
While you raise a number of valid minor issues, I see nothing which
needs urgent attention or correction. I'll keep a record of these
issues, to be included if there is a revision to RFC 4566, but I see
no need to submit an errata note to the RFC Editor.
Errata ID: 2247
Status: Verified
Type: Technical
Reported By: Riccardo Bernardini
Date Reported: 2010-05-06
Verifier Name: Robert Sparks
Date Verified: 2011-02-07
Section 3.2 says:
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"]
It should say:
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] ["data" "=" %22 base64 %22 ";"]
Notes:
There is an inconsistency between the ABNF for key-mgmt-spec on page 6 and the two SETUP examples on top of page 21. In both examples a field data="..." is present in the keymgmt header, but the ABNF on page 6 does not allow for it. The suggested correction solves the inconsistency.
--- From reviewer Dale Worley --
The grammar needs additional work because key-mgmt-spec is not
correctly attached to the original ABNF, and the production provided
does not allow the parameters to appear in any order. In addition,the
terminating CRLF is not shown in the ABNF. A more correct version is:
extension-header =/ KeyMgmt
(Is this the correct nonterminal to extend? RFC 4567 section 3.2 does
not make it clear what sort of header "KeyMgmt" is.)
KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) CRLF
key-mgmt-spec = "prot" "=" KMPID 0*(key-mgmt-spec-param)
key-mgmt-spec-param = ";" "uri" "=" %22 URI %22
/ ";" "data" "=" %22 base64 %22
The whole situation is troublesome because the RFC does not make it
clear to what degree the 'prot', 'uri', and 'data' elements are
required to be in a certain order. Given that many headers are copied
from HTTP, the implication is that the first element (that is,
"prot=KMPID") must appear in the first position, but the following
elements ("uri" and "data") may be in any order. But current practice
may have de-facto standardized a different rule. We need some input
from someone who is familiar with current practice.
------
The MMUSIC WG list was polled and the responses were that allowing these parameters to appear in any order was an acceptable technical solution.
Errata ID: 56
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks
The abstract says:
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
It should say:
General guidelines are also given on how the framework should be used together with SIP and SAP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined.
Notes:
As can be seen from the title and the body of the RFC, and
as has been correctly stated in the first paragraph of the Abstract,
the RFC primarily deals with SDP and RTSP; it "also" considers the use
of the SDP extensions with SIP (Section 4.1.2) and SAP (Section 4.1.3).
Hence, SAP should be mentioned in the second paragraph of the Abstract
instead of RTSP.
Errata ID: 809
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks
(1) [[posted separately.]]
(2) inappropriate text (cut&paste error?)
On page 6, the explanation below the ABNF in Section 3.2 says:
where KMPID is as defined in Section 3 of this memo, "base64" as
defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].
It should say:
where KMPID is as defined in Section 3 of this memo and "URI" as
defined in Section 3 of [RFC3986].
Rationale: "base64" does not appear in the ABNF of Section 3.2 !
(3) incomplete sentence
The first paragraph of Section 4.1.1, on page 8, says:
The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or
announcement. The processing can be divided into four different
steps:
It should say:
The processing when SDP is used is slightly different according to
the way SDP is transported, and if it uses an offer/answer or
| announcement model. The processing can be divided into four
different steps:
(4) misleading word omission
Within Section 5.4, the explanation at top of page 21,
Each RTSP header is inserted in the SETUP related to the audio and
video separately:
should be clarified to say:
| A key management RTSP header is inserted in the SETUP related to the
audio and video separately:
(5) suspected inconsistency
The last paragraph of Section 7, on page 22, says:
The server will need to be able to know the identity of the client
before creating and sending a MIKEY message. [...]
IMHO, it is not clear how this fits with the text on page 14.
Perhaps, a 3-way handshake with client auth in DESCRIBE could
be considered.
(6) inconsistency between ABNF and IANA registrations
Perhaps, a late change to the ABNF in the body of the RFC has lead
to inconsistencies in the filled out IANA registration templates
as presented in Section 9.1 and 9.3; in particular, the hypothetical
attribute name "key-mgmt-att-field" referred to in fact should be just
"key-mgmt"; "key-mgmt-att-field" is the name of the ABNF production
rule (introduced in Section 3.1) for this literal; in the template
the literal name of the attribute is needed.
Therefore:
In Section 9.1, near the bottom of page 25, change
SDP Attribute Field ("att-field"):
Name: key-mgmt-att-field
to say:
SDP Attribute Field ("att-field"):
Name: key-mgmt
and in Section 9.3, on page 26, change
Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header
to say:
| Purpose: Usage of MIKEY with the key-mgmt SDP attribute
and the keymgmt RTSP header
[ I also have added "SDP" for additional clarification. ]
(7) missing articles
The first paragraph of the Abstract, on page 1 of RFC 4567, says:
This document defines general extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. [...]
It should say:
| This document defines general extensions for the Session Description
| Protocol (SDP) and the Real Time Streaming Protocol (RTSP) to carry
messages, as specified by a key management protocol, in order to
secure the media. [...]
(8) missing article
Near the top of page 7, the paragraph,
We define one new RTSP status code to report error due to any failure
during the key management processing (Section 4.2):
should say:
| We define one new RTSP status code to report an error due to any
failure during the key management processing (Section 4.2):
(9) missing article
Within Section 4.2, the last bullet on page 15 says:
* Key management responses for the initial establishment of security
parameters for an individual media SHALL only be included in SETUP
for the corresponding media stream.
It should say:
* Key management responses for the initial establishment of security
| parameters for an individual media SHALL only be included in the
SETUP for the corresponding media stream.
(10) typo (singular/plural mismatch)
Within Section 5.2, the explanation of the example, in the lower
half of page 19,
The client checks the validity of the received MIKEY message, and, in
case of successful verification, it accept the message. [...]
should say:
The client checks the validity of the received MIKEY message, and, in
| case of successful verification, it accepts the message. [...]
Notes:
from pending
Errata ID: 55
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 6 says:
Purpose: See this document
Reference: This document
Values: See this document, and registrations below
It should say:
Purpose: See RFC 4632
Reference: RFC 4632
Values: See RFC 4632
Notes:
The filled out SDP attribute registration template in the IANA
Considerations (Section 6) on page 10 contains improper wording
-- either just being garbage (there are no 'registrations below'
in the RFC), or getting inappropriate when extracted from the RFC
and included in a stand-alone IANA document.
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)
Errata ID: 802
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 1 says:
Applications and hosts may also share the source-filter information with network elements (e.g., with routers using [IGMPv3]) so they can potentially perform the traffic | filtering operation further "upstream," closer to the source(s).
It should say:
Applications and hosts may also share the source-filter information with network elements (e.g., with routers using [IGMPv3]) so they can potentially perform the traffic | filtering operation further "upstream", closer to the source(s).
Notes:
quoting style
from pending
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)
Errata ID: 804
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 1 says:
Use of source-filters do not corrupt the ASM semantics but provide more control for receivers, at their discretion.
It should say:
| Use of source-filters does not | corrupt the ASM semantics but provides more control for receivers, at their discretion.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)
Errata ID: 54
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Held for Document Update by: Robert Sparks
Section 1 says:
The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport Protocol (RTP, [RFC3551]) does not define a method for framing RTP and RTP Control Protocol (RTCP) packets onto connection-oriented transport protocols (such as TCP). However, earlier versions of
It should say:
The Audio/Video Profile (AVP, [RFC3551]) for the Real-time Transport Protocol (RTP, [RFC3550]) does not define a method for framing RTP and RTP Control Protocol (RTCP) packets onto connection-oriented transport protocols (such as TCP). However, earlier versions of
Notes:
Apparently, the RFC numbers have been permuted inadvertently.
Errata ID: 2264
Status: Reported
Type: Technical
Reported By: William McCall
Date Reported: 2010-05-17
Section 4.2.6 says:
[...] If BGP installs
a route of one of these types in the VRF, and if that route is
selected for redistribution into OSPF, it will be advertised by
OSPF in either a type 3 or a type 5 LSA, depending on the
domain identifier.
It should say:
[...] If BGP installs
a route of one of these types in the VRF, and if that route is
selected for redistribution into OSPF, it will be advertised by
OSPF in either a type 3, type 5, or type 7 LSA, depending on the
domain identifier and the type of area the PE/CE link belongs to.
Notes:
Suggested because reading 4.2.6 is contradictory with the following:
4.2.8.1. External Routes
[...]If the route is advertised, and the PE/CE link belongs to a NSSA area, it is advertised in a type 7 LSA.[...]
Errata ID: 53
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Edited by: Stewart Bryant
Date Edited: 2012-02-07
(2) [orphaned inter-section references]
Section 4.2.4 of RFC 4577 contains three (3) distinct references
to itself. This cannot have been intended.
Within Section 4.2.2, the last two paragraphs on page 11 say:
vvvvv
A Domain Identifier is an eight-byte quantity that is a valid BGP
| Extended Communities attribute, as specified in Section 4.2.4. If a
particular OSPF instance has a non-NULL Domain Identifier, when
routes from that OSPF instance are distributed by BGP as VPN-IPv4
routes, the routes MUST carry the Domain Identifier Extended
Communities attribute that corresponds to the OSPF instance's Primary
Domain Identifier. If the OSPF instance's Domain Identifier is NULL,
the Domain Identifier Extended Communities attribute MAY be omitted
when routes from that OSPF instance are distributed by BGP;
alternatively, a value of the Domain Identifier Extended Communities
| attribute that represents NULL (see Section 4.2.4) MAY be carried
with the route.
^^^^^
If the OSPF instances of an OSPF domain are given one or more non-
NULL Domain Identifiers, this procedure allows us to determine
whether a particular OSPF-originated VPN-IPv4 route belongs to the
same domain as a given OSPF instance. We can then determine whether
the route should be redistributed to that OSPF instance as an inter-
area route or as an OSPF AS-external route. Details can be found in
| Sections 4.2.4 and 4.2.8.1.
^^^^^
I am not sure what really was intended to say. Perhaps, the
second instance of "4.2.4" should be replaced by "4.2.6".
Please check and supply corrected text.
Notes:
from pending
Errata ID: 3110
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-07
(1) [typo?]
Section 4.2.1 of RFC 4577, in the last paragraph on page 9, says:
Generally, though not necessarily, if the PE attaches to several CEs
in the same OSPF domain, it will associate the interfaces to those
PEs with a single VRF.
I strongly suspect that the final "PEs" is a typo, and should be
replaced by "CEs".
Thus, the RFC should say:
Generally, though not necessarily, if the PE attaches to several CEs
in the same OSPF domain, it will associate the interfaces to those
| CEs with a single VRF.
(3) [typo: punctuation]
Section 4.2.7 of RFC 4577, on page 16, says:
This section describes the protocol and procedures necessary for the
| support of "Sham Links," as defined herein. Support for sham links
is an OPTIONAL feature of this specification.
It should say:
This section describes the protocol and procedures necessary for the
| support of "Sham Links", as defined herein. Support for sham links
is an OPTIONAL feature of this specification.
(4) [typo: grammar]
In Section 4.2.7.1, the last paragraph on page 16 says:
If it is desired to have OSPF prefer the routes through the backbone
over the routes through the backdoor link, then the routes through
| the backbone must be appear to be intra-area routes. [...]
^^^^^^^^^^^^^^
It should say:
If it is desired to have OSPF prefer the routes through the backbone
over the routes through the backdoor link, then the routes through
| the backbone must appear to be intra-area routes. [...]
^^^^^^^^^^^
(5) [typo: inconsistent spelling/capitalization]
In Section 4.2.7.1, the second paragraph on page 17 contains
the sentence:
vvvvvvvvv
[...]. If the VRF is associated with only
| a single OSPF instance, and if the PE's router id in that OSPF
instance is an IP address, then the Sham Link Endpoint Address MAY
default to that Router ID. [...]
Consistently with all other occurrences of the term, "Router ID"
in this memo, it should say:
[...]. If the VRF is associated with only
| a single OSPF instance, and if the PE's Router ID in that OSPF
instance is an IP address, then the Sham Link Endpoint Address MAY
default to that Router ID. [...]
(6) [word omission]
The 4th paragraph of Section 4.2.7.2, near the bottom of page 17,
says:
A sham link connecting two VRFs is considered up if and only if a
route to the 32-bit remote endpoint address of the sham link has been
| installed in VRF.
It should say:
A sham link connecting two VRFs is considered up if and only if a
route to the 32-bit remote endpoint address of the sham link has been
| installed in the VRF.
Notes:
from pending
Errata ID: 712
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-12-30
Held for Document Update by: Robert Sparks
(1) [clarification] Section 4 of RFC 4583, near the top of page 4, says: If an 'm' line in an offer contains a 'floorctrl' attribute, the answerer MUST include one in the corresponding 'm' line in the answer. [...] It should better say: If a SDP media description in an offer contains a 'floorctrl' attribute, the answerer accepting that media MUST include one in the corresponding media description of the answer. [...] (2) [clarification] Section 6 of RFC 4583, on mid-page 5, says: The 'floorid' attribute is used in BFCP 'm' lines. [...] It should better say: The 'floorid' attribute is used in the SDP media description for BFCP media. [...] Please comment.
It should say:
[not submitted]
Notes:
It's always the abuse of language, talking about an SDP attribute
as being used "in" an SDP 'm' line, where in fact the attribute is
just a media-level attribute, occurring as a standalone line in an
SDP media description, i.e. the SDP part introduced by the particular
'm' line.
This is, at best, a bit confusing.
from pending
Errata ID: 741
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 6.1 says:
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets. The behavior is | similar to ICMPV6 processing, where the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header in addition to passing the mobility header to the application. In order to comply with the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API checksum calculations by default at the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return error on the IPV6_CHECKSUM socket option setting, even if the socket option is a NO-OP function for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. Again, for application portability it is recommended that the applications set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH protocol.
It should say:
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets. The behavior is | similar to ICMPv6 processing; the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header in addition to passing the mobility header to the application. In order to comply with the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API | checksum calculations by default in the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return an error on the IPV6_CHECKSUM socket option setting, even if the socket option is a NO-OP function for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. Again, for application portability it is recommended that the applications set the IPV6_CHECKSUM socket option along with | the RAW sockets for the IPPROTO_MH protocol.
Notes:
misleading wording
from pending
Errata ID: 52
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 4.6 says:
IPv6 Neighbor Discovery changes are also defined in
<netinet/icmp6.h>.
New 'Home Agent' flag in router advertisement: #define
ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent
MUST include at least one prefix option with the Router Address (R)
bit set. Advanced Socket API [1] defines data structure for prefix
option as follows:
It should say:
IPv6 Neighbor Discovery changes are also defined in
<netinet/icmp6.h>.
New 'Home Agent' flag in router advertisement:
#define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent
MUST include at least one prefix option with the Router Address (R)
bit set. The Advanced Socket API [1] defines a data structure for
the prefix option as follows:
Notes:
separation of machine readable text and RFC text, and missing articles
from pending
Errata ID: 739
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
All instances of
IPV6 and ICMPV6 For example, in section 5: Legacy IPv6 applications/implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers(Type 2), will discard the packet as per Sections 4.2 and 4.4 of IPV6 Protocol [3] specification, respectively; otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document.
It should say:
IPv6 and ICMPv6 For example, should say (also incorporating other corrections): Legacy IPv6 applications/implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers (Type 2), will discard the packet as per Sections 4.2 and 4.4 of the IPv6 Protocol [3] specification, respectively; otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document.
Notes:
unusual capitalization
Other places affected are:
Section 5.1, 1st paragraph (page 17);
Section 5.3, 1st paragraph (page 19);
Section 6.1, 1st paragraph (page 21)
from pending
Errata ID: 740
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 5.3 says:
Any user-level implementation or application that sends the Home address destination option through ancillary data objects should follow the order extension header defined in this document when using IPV6_MIPDSTOPTS socket options.
It should say:
Any user-level implementation or application that sends the Home address destination option through ancillary data objects should | follow the order of extension headers defined in this document when | using the IPV6_MIPDSTOPTS socket options.
Notes:
from pending
Errata ID: 2853
Status: Verified
Type: Technical
Reported By: Ali Begen
Date Reported: 2011-07-05
Verifier Name: Robert Sparks
Date Verified: 2011-08-05
Section 4.2 says:
OLD:
rtcp-fb-param = SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
NEW:
rtcp-fb-param = [ SP "app" [SP byte-string]
/ SP token [SP byte-string] ]
OLD:
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
NEW:
rtcp-fb-ack-param = [ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string] ]
OLD:
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
NEW:
rtcp-fb-nack-param = [ SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string] ]
Notes:
During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" is not a valid ABNF - RFC 5234 does not allow empty alternates).
The NEW text intends to fix it. There are 3 places where the same change should be applied (changes are identical).
Errata ID: 51
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17
Errors (11)-(19) of 19
(11) [formatting issue]
In Section 6, the text around the page break from page 31 to page 32
is not formatted properly.
The RFC says:
[...]
audio and DTMF) or when codec changes occur, the payload type
information may need to be conveyed explicitly as part of the FB
message. This applies to all
<< page break >>
payload-specific as well as application layer FB messages. It is
up to the specification of an FB message to define how payload
type information is transmitted.
It should say:
[...]
audio and DTMF) or when codec changes occur, the payload type
information may need to be conveyed explicitly as part of the FB
message. This applies to all payload-specific as well as
<< page break >>
application layer FB messages. It is up to the specification of
an FB message to define how payload type information is
transmitted.
(12) [inconsistent text]
Still in Section 6, the second paragraph on page 32 (immediately
following the text quotation in item (11) above) says:
vvv
| This document defines two transport layer and three (video) payload-
specific FB messages as well as a single container for application
layer FB messages. Additional transport layer and payload-specific
FB messages MAY be defined in other documents and MUST be registered
through IANA (see Section 9, "IANA Considerations").
It should say:
vvv
| This document defines one transport layer and three (video) payload-
specific FB messages as well as a single container for application
layer FB messages. Additional transport layer and payload-specific
FB messages MAY be defined in other documents and MUST be registered
through IANA (see Section 9, "IANA Considerations").
Rationale:
Cf. the third paragraph of Section 6, on page 31, and
the subsequent pages, in particular page 34, where the
second paragraph of Section 6.2 says:
| A single general purpose transport layer FB message is defined in
this document: Generic NACK. It is identified by means of the FMT
parameter as follows:
[...]
(And so it does, per Section 6.2.1.)
(13) [incomplete specification?]
Within Section 6.1, the last paragraph on page 33 says:
Each RTCP feedback packet MUST contain at least one FB message in the
FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or
not multiple FB messages MAY be compressed into a single FCI field.
| If this is the case, they MUST be of the same type, i.e., same FMT.
| If multiple types of feedback messages, i.e., several FMTs, need to
be conveyed, then several RTCP FB messages MUST be generated and
SHOULD be concatenated in the same compound RTCP packet.
I strongly suspect -- and this is supported by the examples in the
RFC -- that feedback packets to be combined MUST also have the same
payload type (PT), not only agree in their FMT values.
Otherwise, there would be no way to carry the different PT values
in the FB message according to the format specified in Figure 3.
Therefore, the RFC should say:
Each RTCP feedback packet MUST contain at least one FB message in the
FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or
not multiple FB messages MAY be compressed into a single FCI field.
| If this is the case, they MUST be of the same type, i.e., same PT and
| the same FMT. If multiple types of feedback messages, i.e., several
| PTs and/or several FMTs, need to be conveyed, then several RTCP FB
messages MUST be generated and SHOULD be concatenated in the same
compound RTCP packet.
(Authors, please supply alternative wording, if you desire.)
Note:
Perhaps, this issue arised because of the slightly differing
semantics implied for the various usages of the term "FB message"
in Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic
entity carried in the FCI field of that RTCP message.
Future updates to the RFC might try further clarifications of the
text to avoid this subtle sematic overloading.
(14) [missing article]
The last paragraph of Section 6.3, at the bottom of page 35, says:
The following subsections define the FCI formats for the payload-
| specific FB messages, Section 6.4 defines FCI format for the
application layer FB message.
It should say:
The following subsections define the FCI formats for the payload-
| specific FB messages, Section 6.4 defines the FCI format for the
application layer FB message.
(15) [extraneous words]
The second paragraph of Section 6.3.1.1, on page 36, says:
Other RTP payload specifications such as RFC 2032 [6] already define
| a feedback mechanism for some for certain codecs. An application
supporting both schemes MUST use the feedback mechanism defined in
this specification when sending feedback. For backward compatibility
reasons, such an application SHOULD also be capable to receive and
react to the feedback scheme defined in the respective RTP payload
format, if this is required by that payload format.
It should say:
Other RTP payload specifications such as RFC 2032 [6] already define
| a feedback mechanism for certain codecs. An application supporting
both schemes MUST use the feedback mechanism defined in this
specification when sending feedback. For backward compatibility
reasons, such an application SHOULD also be capable to receive and
react to the feedback scheme defined in the respective RTP payload
format, if this is required by that payload format.
(16) [misleading wording]
The first paragraph of Section 6.3.2.2, on page 37, says:
vvvvv
| The Slice Loss Indication uses one additional FCI field, the content
of which is depicted in Figure 6. The length of the FB message MUST
be set to 2+n, with n being the number of SLIs contained in the FCI
field.
To avoid the semantic overloading of the word "field", it should
perhaps better say:
vvvv
| The Slice Loss Indication uses one additional FCI word, the content
of which is depicted in Figure 6. The length of the FB message MUST
be set to 2+n, with n being the number of SLIs contained in the FCI
field.
(17) [typo]
The first paragraph of Section 6.3.3.1, on page 39, says:
v
[...]. As this reference picture is
| temporally further away then usual, the resulting predictively coded
picture will use more bits.
It should say:
v
[...]. As this reference picture is
| temporally further away than usual, the resulting predictively coded
picture will use more bits.
(18) [inappropriate wording]
The first paragraph of Section 8, on page 42, says:
RTP packets transporting information with the proposed payload format
are subject to the security considerations discussed in the RTP
specification [1] and in the RTP/AVP profile specification [2]. This
profile does not specify any additional security services.
The wording of the first sentence is inappropriate for this RFC.
(It perhaps has been copied unchanged from an RFC with an RTP Payload
specification.)
RFC 4585 should say instead:
| RTP packets transporting information as defined in various payload
| formats supporting this profile are subject to the security
considerations discussed in the RTP specification [1] and in the
RTP/AVP profile specification [2]. This profile does not specify any
additional security services.
(19) [redundant Ref.]
The Normative Reference [7] (in Section 11.1, on page 48) and
the Informative Reference [20] (in Section 11.2, on page 49)
both point to RFC 3448.
([7] and [20] are referred to once each in the RFC text.)
This is unusual and unexpected. Only one pointer to RFC 3448
should have been specified. Authors, please check.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.
We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).
Errata ID: 768
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17
Errors (1)-(10) of 19
(1)
Section 1.1 of RFC 4585, on mid-page 4, says:
Feedback (FB) message:
An RTCP message as defined in this document is used to convey
information about events observed at a receiver -- in addition to
long-term receiver status information that is carried in RTCP
receiver reports (RRs) -- back to the sender of the media stream.
| For the sake of clarity, feedback message is referred to as FB
| message throughout this document.
I do not see how and why using the abbreviation might have improved
*clarity* of the text; apparently, it has been used for *brevity* .
Therefore, the two tagged lines should better say:
| For the sake of brevity, feedback message is referred to as FB
| message throughout this document.
Similarly, at the bottom of page 4, where the RFC says:
Feedback (FB) threshold:
The FB threshold indicates the transition between Immediate
Feedback and Early RTCP mode. [...]
[...]
to application designers and is not used in any calculations. For
| the sake of clarity, the term feedback threshold is referred to as
FB threshold throughout this document.
The last 3 lines should better say:
to application designers and is not used in any calculations. For
| the sake of brevity, the term feedback threshold is referred to as
FB threshold throughout this document.
(2)
The first bulleted item in Section 3.1, on page 7, says:
vvvvvvvvvvvvv
| o Status reports are contained in sender report (SR)/received report
(RR) packets and are transmitted at regular intervals as part of
compound RTCP packets (which also include source description
(SDES) and possibly other messages); these status reports provide
an overall indication for the recent reception quality of a media
stream.
For *clarity*, it perhaps should better say -- not binding together the
words intended to being separated by the slash marking the alternative:
vvv
| o Status reports are contained in sender report (SR) / received
report (RR) packets and are transmitted at regular intervals as
part of compound RTCP packets (which also include source
description (SDES) and possibly other messages); these status
reports provide an overall indication for the recent reception
quality of a media stream.
(3) [missing article]
In Section 3.4, on mid-page 11, RFC 4585 says:
j) Let T_fd be the actual (randomized) delay for the transmission of
FB message in response to an event at time t0.
It should say:
j) Let T_fd be the actual (randomized) delay for the transmission of
| a FB message in response to an event at time t0.
^^
(4) [inappropriate wording]
The algorithm in Section 3.5.2, at the bottom of page 16, contains
the sub-step:
4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
packet for te = t0 + RND * T_dither_max with RND being a
| pseudo random function evenly distributed between 0 and 1.
^^^^^^^^
This wording is inappropriate. RND is not a *function* (that's code!),
but a *number*, the function *value*. Therefore, the RFC should say:
4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
packet for te = t0 + RND * T_dither_max with RND being a
| pseudo random number evenly distributed between 0 and 1.
^^^^^^
(5) [inappropriate wording]
The algorithm in Section 3.5.3, at the top of page 19, says:
2. Otherwise, a temporary value T_rr_current_interval is calculated
as follows:
T_rr_current_interval = RND*T_rr_interval
| with RND being a pseudo random function evenly distributed between
0.5 and 1.5. This dithered value is used to determine one of the
following alternatives:
Similar to item (4) above, the RFC should say instead:
2. Otherwise, a temporary value T_rr_current_interval is calculated
as follows:
T_rr_current_interval = RND*T_rr_interval
| with RND being a pseudo random number evenly distributed between
0.5 and 1.5. This dithered value is used to determine one of the
following alternatives:
(6) [typo / dup. wording]
Section 3.6.2 of RFC 4585, on mid-page 21, says:
Example: If a 256-kbit/s video with 30 fps is transmitted through a
network with an MTU size of some 1,500 bytes, then, in most cases,
| each frame would fit in into one packet leading to a packet rate of
30 packets per second. [...]
It should say:
Example: If a 256-kbit/s video with 30 fps is transmitted through a
network with an MTU size of some 1,500 bytes, then, in most cases,
| each frame would fit into one packet leading to a packet rate of
30 packets per second. [...]
(7) [wrong ref. tag]
On mid-page 23, Section 4.1 of RFC 4585 says:
vvv
| The AV profile defined in [4] is referred to as "AVP" in the context
of, e.g., the Session Description Protocol (SDP) [3]. The profile
specified in this document is referred to as "AVPF".
There apparently is a confusion of the ref. tags used.
The RFC should say:
vvv
| The AV profile defined in [2] is referred to as "AVP" in the context
of, e.g., the Session Description Protocol (SDP) [3]. The profile
specified in this document is referred to as "AVPF".
(8) [missing article]
In Section 4.2, near the top of page 25, the ABNF production:
rtcp-fb-pt = "*" ; wildcard: applies to all formats
| / fmt ; as defined in SDP spec
should better say, improving the ABNF comment text:
rtcp-fb-pt = "*" ; wildcard: applies to all formats
| / fmt ; as defined in the SDP spec
^^^^^
(9) [inconsistent specification]
In Section 4.2, the ABNF on page 25 contains the following productions:
rtcp-fb-val = "ack" rtcp-fb-ack-param
/ [...]
and
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
| / ; empty
This means that the feedback type "ack" *MAY* have parameters.
Contrary to that, below the ABNF, the RFC explains:
Feedback type "ack":
This feedback type indicates that positive acknowledgements for
feedback are supported.
The feedback type "ack" MUST only be used if the media session is
allowed to operate in ACK mode as defined in Section 3.6.1.
| Parameters MUST be provided to further distinguish different types
| of positive acknowledgement feedback.
[...]
The *MUST* in the tagged lines contradicts the ABNF.
Authors, please resolve the issue:
Either have the ABNF changed by omission of the tagged line above,
| / ; empty
or change the tagged explanation lines to say:
| Parameters MAY be provided to further distinguish different types
| of positive acknowledgement feedback.
(10) [incomplete specification, and an extraneous word]
At the bottom of page 26, Section 4.2 of RFC 4585 says:
Other feedback types <rtcp-fb-id>:
Other documents MAY define additional types of feedback; to keep
the grammar extensible for those cases, the rtcp-fb-id is
| introduced as a placeholder. A new feedback scheme name MUST to
be unique (and thus MUST be registered with IANA). Along with a
| new name, its semantics, packet formats (if necessary), and rules
for its operation MUST be specified.
It should say:
Other feedback types <rtcp-fb-id>:
Other documents MAY define additional types of feedback; to keep
the grammar extensible for those cases, the rtcp-fb-id is
| introduced as a placeholder. A new feedback scheme name MUST be
unique (and thus MUST be registered with IANA). Along with a new
| new name, its semantics, possible parameters, packet formats (if
necessary), and rules for its operation MUST be specified.
Rationale:
a) "MUST to be unique" should be "MUST be unique".
b) Syntax and semantics of parameters (if any) obviously MUST be
specified as well. The RFC text in the IANA Considerations
(Section 9) already reflects this requirement.
For completeness and clarity, it should be stated here as well.
I have proposed minimal additional wording -- you might choose
alternative words.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.
We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).
Errata ID: 50
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Held for Document Update by: Robert Sparks
Section 4.1 says:
We can see that in configurations where both agents use the new timing rules each of them uses, at most, about 2.5% of the session bandwidth for RTP, which sums up to 5% of the session bandwidth for both.
It should say:
We can see that in configurations where both agents use the new timing rules each of them uses, at most, about 2.5% of the session bandwidth for RTCP, which sums up to 5% of the session bandwidth for both.
Notes:
RTP -> RTCP
from pending
Errata ID: 766
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Held for Document Update by: Cullen Jennings
Section 7.3 says:
| We have shown that the limitations of RTP AVPF profile do not generate such high delay in the feedback messages that the performance of NEWPRED is degraded for sessions from 32 kbps to 2 Mbps.
It should say:
| We have shown that the limitations of the RTP AVPF profile do not generate such high delay in the feedback messages that the performance of NEWPRED is degraded for sessions from 32 kbps to 2 Mbps.
Notes:
missing article
from pending
Errata ID: 49
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-31
Held for Document Update by: Robert Sparks
(1) "Updates" relationship missing in RFC header & RFC index
In the Introduction (3rd paragraph on page 3) the RFC says:
This document obsoletes RFC 2032 and updates the "video/h261" media
type that was registered in RFC 3555.
Similar wording is in Section 6.1 (see below).
Therefore, I expect that the RFC heading should have been amended
by a "Updates: 3555" line, and that this relationship be visible in
the RFC index.
(2) Misleading packetization specification
On page 4, in the first paragraph of Section 3.2, RFC 4587 says:
[..]. The 512-bit frames are then interlaced with an audio stream
and transmitted over px 64 kbps circuits according to specification
H.221 [H221].
^^^^^^^^^^
For clarity, it should say:
[..]. The 512-bit frames are then interlaced with an audio stream
and transmitted over p x 64 kbps circuits according to specification
H.221 [H221].
^^^^^^^^^^^
(and/or replace the 'x' by an asterisk, '*' !)
(2')
The same issue recurs on page 15, in the first item of Section 11.1,
the Normative Reference, [H261] .
(3) Improper frequency specification
According to the applicable ISO standards on Measures and Weights,
there is never a special sign to be written between the numeric value
and the physical unit of any dimensioned physical value.
(Preferrably, there should not even be any white space between.)
Therefore, in Section 4.1 of RFC 4587, at the bottom of page 5,
where the RFC says:
[...]. For H.261 video streams, the RTP timestamp is based on
| a 90-kHz clock. This clock rate is a multiple of the natural H.261
frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]
it in fact should say:
[...]. For H.261 video streams, the RTP timestamp is based on
| a 90 kHz clock. This clock rate is a multiple of the natural H.261
frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]
(Rigorous application of the above principles, taking 'bit' as a unit
specification, would also forbid data amount spellings like "512-bit"
in item (2) above!)
(4) misaligned 'ruler lines' above data format diagrams
According to legacy and current RFC author guidelines, the ruler lines
above the two data format diagrams on page 6 (within Section 4.1):
| 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be indented as follows:
| 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(5) improper wording (2 instances)
Near the top of page 7, the explanations for the (I) and (V) bits
both contain the sentence:
vvvvvvv
[...]. The meaning of this bit should not be changed during the
course of the RTP session.
This is abuse of language.
The *meaning* of the bit -- i.e., the bit *values* -- is given in the
text preceding the quoted sentence, and thus intrinsically cannot be
changed during the course of the RTP session.
What in fact should not be changed during the RTP session is the
*value* of these bits!
Therefore, the RFC should say (in both places):
vvvvv
| [...]. The value of this bit should not be changed during the
course of the RTP session.
(6) typo
In Section 5, on page 9, the last sentence of the bullet (3) says:
[...]. This mode is particularly
efficient in point-to-point connection or when the number of
decoders is low.
It should say:
[...]. This mode is particularly
| efficient in a point-to-point connection or when the number of
decoders is low.
or:
[...]. This mode is particularly
| efficient in point-to-point connections or when the number of
decoders is low.
(7) misleading section headlines
In the RFC text, Section
6. IANA Considerations
contains the following sub-sections:
6.1. Media Type Registrations
6.1.1. Registration of MIME Media Type video/H261
6.2. SDP Parameters
6.2.1. Usage with the SDP Offer Answer Model
Only Section 6.1[.1] contains information addressed to the IANA.
Therefore, for clarity (and to avoid undue burden for the IANA),
the first two of the headlines quoted above should effectively be
exchanged. And, there is only one (1) registration!
Hence, singular should be used.
Furthermore, the text of Section 6.1 contains improper wording
and has no trailing fullstop (dot) character:
| This section describes the media types and names associated with this
| payload format. The section updates the previous registered version
in RFC 3555 [RFC3555]. This registration uses the template defined
| in RFC 4288 [RFC4288]
Thus, the headline
6. IANA Considerations
should be corrected to say, e.g.:
6. Media Type video/H261
and
6.1. Media Type Registrations
[... paragraph quoted above ... ]
should be replaced by:
6.1 IANA Considerations
| This section describes the media type and parameters associated with
| this payload format. It updates the previous registered version in
RFC 3555 [RFC3555]. This registration uses the template defined
| in RFC 4288 [RFC4288].
(8) typo
The last sentence (of the last bullet) of Section 6.2, on page 12,
says:
[...]. These parameters are
expressed as a MIME media type string, in the form of as a
semicolon-separated list of parameters
^^^^
It should say:
[...]. These parameters are
| expressed as a MIME media type string, in the form of a
semicolon-separated list of parameters
(9) typo and misleading wording in Section 6.2.1
The first paragraph of Section 6.2.1, on page 12, says:
When H.261 is offered over RTP using SDP in an Offer/Answer model
[RFC3264] the following considerations are necessary.
This could easily be misunderstood as talking about an
'SDP offer over RTP'.
The RFC should say instead (exchanging two pairs of words):
When H.261 over RTP is offered using SDP in an Offer/Answer model
[RFC3264] the following considerations are necessary.
Subsequently, the paragraph with the headline "Picture sizes and MPI",
Supported picture sizes and their corresponding minimum picture
interval (MPI) information for H.261 can be combined. All picture
sizes may be advertised to the other party, or only a subset of it.
Using the recvonly or sendrev direction attribute, a terminal SHOULD
announce those picture sizes (with their MPIs) that it is willing to
receive. For example, CIF=2 means that receiver can receive a CIF
picture and that the frame rate SHALL be less then 15 frames per
second.
Should be corrected and clarified to say:
Supported picture sizes and their corresponding minimum picture
interval (MPI) information for H.261 can be combined. All picture
sizes may be advertised to the other party, or only a subset of it.
| Using the recvonly or sendrec direction attribute, a terminal SHOULD
announce those picture sizes (with their MPIs) that it is willing to
| receive. For example, CIF=2 means that the SDP sender can receive a
CIF picture and that the frame rate SHALL be less then 15 frames per
second.
(There is no 'sendrev' direction attribute, and it is important to
explicitely differentiate between senders and receivers of SDP and
media, respectively!)
Finally, the second paragraph on page 13,
An example of media representation in SDP is as follows CIF at 15
frames per second, QCIF at 30 frames per second and annex D
should better say:
| An example of media representation in SDP is as follows:
CIF at 15 frames per second, QCIF at 30 frames per second and annex D
or, perhaps even better:
| An example of media representation in SDP, for CIF at 15 frames per
| second, QCIF at 30 frames per second and annex D, is as follows:
Notes:
from pending
Errata ID: 48
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Section 8.1 says:
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt". The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
It should say:
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt". The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The MIME type of the retransmission stream MUST be the same as the MIME type of the original stream. The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
Notes:
This text only addresses the use of the media *sub*-type. Apparently,
it is implied that the media *type* of the associated streams match,
but I could not find a statement to this end in the RFC.
(In accordance with the language of RFC 4588, but contrary to BCP 13,
RFC 4288, I have again used the traditional wording "MIME type" here
instead of the currently recommended "media type".)
from pending
--VERIFIER COMMENT--
Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:
"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec)."
Errata ID: 759
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Date Rejected: 2006-08-29
(1) [missing article]
Within Section 4 of RFC 4588, the second paragraph on page 8 says:
[...]. See Section 8.1 for the specification of how the
mapping between original and retransmission payload types is done
| with Session Description Protocol (SDP).
It should say:
[...]. See Section 8.1 for the specification of how the
mapping between original and retransmission payload types is done
| with the Session Description Protocol (SDP).
^^^^^
(2) [improper wording]
The 4th paragraph of Section 6.3, on page 12, says:
[...]. In such cases, an appropriate "reorder delay"
algorithm may not actually be timer based, but packet based. For
| example, if n number of packets are received after a gap is detected,
then it may be assumed that the packet was truly lost rather than out
of order. This may turn out to be far easier to code on some
platforms as a very short fixed FIFO packet buffer as opposed to the
timer-based mechanism.
It should say:
[...]. In such cases, an appropriate "reorder delay"
algorithm may not actually be timer based, but packet based. For
| example, if n packets are received after a gap is detected, then it
may be assumed that the packet was truly lost rather than out of
order. This may turn out to be far easier to code on some platforms
as a very short fixed FIFO packet buffer as opposed to the timer-
based mechanism.
(Alternatively, use "if a number n of packets ..." instead of the
offending "if n number of packets ..." )
(3) [word omission]
In the first paragraph of Section 6.4, on page 13, RFC 4588 says:
[...] v
| Sending NACKs only in regular RTCP compound decreases the maximum
delay between detecting an original packet loss and being able to
send a NACK for that packet. Implementers should consider the
possible implications of this fact for the application being used.
It should say:
[...] vvvvvvvvv
| Sending NACKs only in regular RTCP compound packets decreases the
maximum delay between detecting an original packet loss and being
able to send a NACK for that packet. Implementers should consider
the possible implications of this fact for the application being
used.
(4) [[posted separately.]]
(5) [word omission]
Later on in Section 8.1, on mid-page 15, the RFC says:
v
| The syntax is as follows:
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
It should say:
vvvvv
| The SDP syntax is as follows:
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
(There also is a syntax for these parameters when written in a full
MIME media type specification; this is not presented in the RFC,
but it must be distinguished from the SDP syntax presented!)
(6) [excessive text]
The final paragraph of Section 8.6, on mid-page 20, says:
In the following sections, some example SDP descriptions are
| presented. In some of these examples, long lines are folded to meet
| the column width constraints of this document; the backslash ("\") at
| the end of a line and the carriage return that follows it should be
| ignored.
It would suffice to say:
In the following sections, some example SDP descriptions are
| presented.
Rationale:
As will be shown below, in the examples given in Section 8.7,
there in fact is no need to perform this artificial line folding.
(7) [simplification for improved clarity]
The artificial line folding in the examples in Section 8.7 can be
avoided without change in the indentation, while still conforming
with the line length limitations:
a) In the upper half of page 21, the lines,
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
should read:
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F
b) In the lower half of page 21, the lines,
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
should read:
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
c) In the upper half of page 22, the lines,
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
should read:
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
(8) [clarification]
On mid-page 21, the text in Section 8.7 says:
A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session "m"
line, the grouping is then obvious and FID semantics MAY be omitted
in this special case only.
It should better say:
A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session "m"
| line, the grouping is then obvious and lines with grouping syntax
(FID semantics) MAY be omitted in this special case only.
Rationale:
It is impossible to only omit *semantics*.
Certain *lines* are omitted there -- the lines with grouping syntax
(and FID semantics).
Alternatively, "(FID semantics)" might be omitted entirely from
the changed text, as well.
(9) [word omission -- clarification]
The first paragraph of Section 10.2, on page 25, says:
This section shows how to combine retransmissions with layered
encoding in multicast sessions. Note that the retransmission
framework is offered only for small multicast applications. Refer to
RFC 2887 [10] for a discussion of the problems of NACK implosion,
severe congestion caused by feedback traffic, in large-group reliable
multicast applications.
It should better say:
This section shows how to combine retransmissions with layered
encoding in multicast sessions. Note that the retransmission
framework is offered only for small multicast applications. Refer to
| RFC 2887 [10] for a discussion of the problems of NACK implosion, and
severe congestion caused by feedback traffic, in large-group reliable
multicast applications.
^^^
(10) [word omission]
In the first paragraph on page 27, text within Section 13 says:
[...]. Refer to Section 9.1
of the Secure Real-Time Transport Protocol (SRTP) [12] for a
| discussion the implications of two-time pads and how to avoid them.
^
It should say:
vvvvvvvvvvvvvvv
[...]. Refer to Section 9.1
| of the Secure Real-Time Transport Protocol (SRTP) specification [12]
| for a discussion of the implications of two-time pads and how to
avoid them.
^^^^
(11) [inconsistency]
In the fourth bullet on page 29, Appendix A.1 says:
* avg-rtcp-size is approximated by 120 bytes. This is a rounded-up
average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes
for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a
RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.
[...]
I cannot follow these computations:
40+8+28+32 = 105 ??? and 40+8+64+32 = 157 ???
What is wrong there?
Authors, please correct !
BTW:
What follows in the text essentially does not depend on the exact
figures, the rough order of magnitude is all that is needed.
But the presentation should be self-consistent.
(12) [improvement of wording]
In the 6th bullet of Appendix A.1, the text on page 29/30 says:
[...]. This means that if a packet is requested for
retransmission a maximum of 2 times, the corresponding generic NACK
report block requesting that particular packet is sent in two
<< page break >>
| consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times.
[...]
It should say:
[...]. This means that if a packet is requested for
retransmission a maximum of 2 times, the corresponding generic NACK
report block requesting that particular packet is sent in two
<< page break >>
| consecutive RTCP compound packets; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times.
[...]
(13) [missing argument / clarification]
On page 31, Appendix A.2 says:
vv
| To find an estimate of the buffering time, T(), that a streaming
server shall use in order to enable a given number of retransmissions
for each packet, N. [...]
It should say:
vvv
| To find an estimate of the buffering time, T(N), that a streaming
server shall use in order to enable a given number of retransmissions
for each packet, N. [...]
(14) [fractional sign]
Within the tables in Appendix A.4, on pages 32 and 33, the RFC text
uses the comma (",") as the fractional sign (central european style).
In IETF documents, the decimal point (".") should be used instead.
Authors, Please comment.
Items (4) / (11) need agreement / text correction from you.
Items (6) + (7) might be considered non-esssential.
All other items seem to be straightforward and suitable for
inclusion in an Errata Note.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:
"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec)."
Note: This RFC has been obsoleted by RFC5090
Source of RFC: radext (ops)
Errata ID: 47
Status: Rejected
Type: Editorial
Reported By: Alexander Schrab
Date Reported: 2006-09-21
Rejected by: Dan Romascanu
Date Rejected: 2009-09-03
Section 3.5 says:
Digest-Nextnonce 106 Digest-Response-Auth 107
Notes:
--VERIFIER NOTES--
itis unclear what is wrong
Errata ID: 735
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
(1) [line folding issue]
The final part of Section 3.2, on page 5 of RFC 4591, syas:
General Result Codes regarding L2TP session establishment are defined
in [RFC3931]. Additional Frame Relay result codes are defined as
follows:
17: FR PVC was deleted permanently (no longer provisioned) 18: FR
PVC has been INACTIVE for an extended period of time 19:
Mismatched FR Header Length
For clarity, the RFC sould say instead:
General Result Codes regarding L2TP session establishment are defined
in [RFC3931]. Additional Frame Relay result codes are defined as
follows:
| 17: FR PVC was deleted permanently (no longer provisioned)
| 18: FR PVC has been INACTIVE for an extended period of time
| 19: Mismatched FR Header Length
(2) [another line folding issue]
Within Section 3.5, on page 7, the RFC text just below the diagram
says:
The Frame Relay Header Length Type is a 2-octet unsigned integer with
the following values defined in this document:
2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header
For clarity, the RFC sould say instead:
The Frame Relay Header Length Type is a 2-octet unsigned integer with
the following values defined in this document:
| 2: Two-octet Frame Relay Header
| 4: Four-octet Frame Relay Header
(3) [missing colons, and formatting]
In Section 4.1, the explanations just below the FR Header diagrams
on page 8 of the RFC read:
C/R (bit 6) FR frame C/R (command/response) bit [Q922].
F - FECN (bit 12): FR FECN (Forward Explicit Congestion
Notification) bit [Q922].
B - BECN (bit 13):
|
FR BECN (Backward Explicit Congestion Notification) bit [Q922].
D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922].
For clarity, it should better say:
vvvvv
| C (bit 6): FR frame C/R (command/response) bit [Q922].
| F (bit 12): FR FECN (Forward Explicit Congestion Notification)
| bit [Q922].
| B (bit 13): FR BECN (Backward Explicit Congestion Notification)
| bit [Q922].
| D (bit 14): FR DE bit indicates the discard eligibility [Q922].
^^^^
[ Additional rationale for the proposed clarifications:
The "full bit names" have been removed from the left hand sides
(corresponding to the diagrams), and replaced "C/R" by "C", because
these "full bit names" do not appear in the diagrams, but already do
appear in the explanatory text on the right hand side. Thus, to the
left of the colons, there now are only -- and precisely -- the terms
from the diagrams. ]
(4) [typo + word omission]
The first paragraph of Section 4.3, on page 9, says:
vv
With L2TPv3 as the tunneling protocol, the packet resulted from the
encapsulation is N bytes longer than Frame Relay frame without the
opening and closing HDLC flags or FCS. The value of N depends on the
following fields:
It should say:
vvv
| With L2TPv3 as the tunneling protocol, the packet resulting from the
| encapsulation is N bytes longer than the Frame Relay frame without
the opening and closing HDLC flags or FCS. The value of N depends on
the following fields:
It should say:
[see above]
Notes:
from pending
Errata ID: 46
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
(1) [improper/misleading wording] In the explanations to the Example in Section 2.2.1, RFC 4592 (near the top of page 9) says: | The following responses would not be synthesized from any of the | wildcards in the zone: This wording is improper/misleading. Perhaps, the RFC should better say: | The following queries would not cause RRs to be synthesized for the | answer from any of the wildcards in the zone: (2) [typo] The last paragraph of Section 2.2.2, on page 10, says: As RFC 1034 also defines "an authoritative name error indicating that | the name does not exist" in section 4.3.1, so this apparently is not the intent of the original definition, justifying the need for an updated definition in the next section. "As ..., so ..." is redundant. Thus, the RFC should say instead: As RFC 1034 also defines "an authoritative name error indicating that | the name does not exist" in section 4.3.1, this apparently is not the intent of the original definition, justifying the need for an updated definition in the next section. (3) [typo] In Section 3.3.1, the 4th paragraph, on page 12, says: A source of synthesis does not guarantee having a RRSet to use for synthesis. The source of synthesis could be an empty non-terminal. It should say: | A source of synthesis does not guarantee having an RRSet to use for synthesis. The source of synthesis could be an empty non-terminal. (4) [typo] In Section 3.3.3, the last paragraph on page 13 says: This is essentially the same text in part 'a' covering the processing of CNAME RRSets. It should say: | This is essentially the same text as in part 'a' covering the processing of CNAME RRSets. (5) [incomplete change in example?] In Section 4.4, the second-to-last paragraph on page 16 says: The DNAME specification is not clear on whether DNAME records in a cache are used to rewrite queries. In some interpretations, the rewrite occurs; in others, it does not. Allowing for the occurrence of rewriting, queries for "sub.a.b.example. A" may be rewritten as | "sub.foo.bar.tld. A" by the former caching server and may be | rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, and an operational nightmare ensues. "tld." does never appear in the preceding text; apparently it has been replaced there by "example.net." Therefore, the RFC should say instead: The DNAME specification is not clear on whether DNAME records in a cache are used to rewrite queries. In some interpretations, the rewrite occurs; in others, it does not. Allowing for the occurrence of rewriting, queries for "sub.a.b.example. A" may be rewritten as | "sub.foo.bar.example.net. A" by the former caching server and may be | rewritten as "sub.a.foo.bar.example.net. A" by the latter. Coherency is lost, and an operational nightmare ensues.
Notes:
from pending
Errata ID: 738
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Held for Document Update by: Russ Housley
Section 7.1 says:
[NIST.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", NIST 180-1, April 1995.
It should say:
[NIST.180-2.2002]
National Institute of Standards and Technology, "Secure
Hash Standard", NIST 180-2, August 2002.
Notes:
The current revision of the NIST's Secure Hash Standard is
"FIPS-PUB 180-2 + Change Notice 1",
issued "2004 Feb 25", which has added SHA-224 to the repertoire.
If NIST publications are used as References in IETF publications,
current revisions should be used.
In the case of SHA-1, perhaps preferrably, RFC 3174 is available
as a (secondary) dedicated reference that will not change.
Errata ID: 1287
Status: Verified
Type: Technical
Reported By: Eric Tremblay
Date Reported: 2008-01-16
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Throughout the document, when it says:
msgserver
It should say:
actor="msg-taker"
Notes:
Throughout RFC4596, msgserver is used as a feature tag while its use was never standardized. A standards compliant proxy server would simply ignore this msgserver parameter. msgserver was used in some UA capabilities draft but was later changed to actor="msg-taker". Somehow this change did not get through to RFC4596.
See http://www1.ietf.org/mail-archive/web/sip/current/msg08884.html for when the change took place.
Errata ID: 45
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Section 3.5.1 says:
Y2 represents an audio/video phone that should only used when needed.
It should say:
Y2 represents an audio/video phone that should only be used when needed.
Notes:
word omission
from pending
Errata ID: 761
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Section 3.1 says:
3.1. Routing of INVITE and MESSAGE to Different UA
It should say:
3.1. Routing of INVITE and MESSAGE to Different UAs
Notes:
from pending
Errata ID: 763
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Section 2 says:
The may prefer to reach the user on a device that supports video (because a video-conference is desired).
It should say:
They may prefer to reach the user on a device that supports video (because a video-conference is desired).
Notes:
from pending
Errata ID: 44
Status: Verified
Type: Technical
Reported By: "Stephen Nadas (RL/TNT)"
Date Reported: 2006-11-07
Verifier Name: David Ward
Normative References say:
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4507, August 2006.
It should say:
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC
4607, August 2006.
Notes:
Reference [6] in RFC 4601 is wrong, it says SSM for IP is
RFC 4507 when it is RFC 4607.
Errata ID: 1104
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
It should say:
immediate_olist(*,G) =
( joins(*,G) (+) pim_include(*,G) ) (-) lost_assert(*,G)
-or-
immediate_olist(*,G) =
joins(*,G) (+) ( pim_include(*,G) (-) lost_assert(*,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1105
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
It should say:
immediate_olist(S,G) =
( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)
-or-
immediate_olist(S,G) =
joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1106
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
It should say:
inherited_olist(S,G,rpt) =
( ( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
(+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )
Or:
inherited_olist(S,G,rpt) =
( ( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
(+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1107
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
It should say:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )
Or:
inherited_olist(S,G) =
( inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)
Or:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
( ( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1110
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.2.1 says:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
It should say:
void
CheckSwitchToSpt(S,G) {
if ( ( ( pim_include(*,G) (-) pim_exclude(S,G) )
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
Or:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) ( pim_exclude(S,G)
(+) pim_include(S,G) != NULL ) )
AND SwitchToSptDesired(S,G) ) {
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1113
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1/6.1.1 says:
The Generation_Identifier (GenID) Option SHOULD be included in all Hello messages. The GenID option contains a randomly generated 32-bit value that is regenerated each time PIM forwarding is started or restarted on the interface, including when the router itself restarts. When a Hello message with a new GenID is received from a neighbor, any old Hello information about that neighbor SHOULD be discarded and superseded by the information from the new Hello message. This may cause a new DR to be chosen on that interface.
Notes:
Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider state thrash due to falsified Hello messages with new Generation_Identifier Options.
Errata ID: 1114
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1 says:
Before an interface goes down or changes primary IP address, a Hello message with a zero HoldTime should be sent immediately (with the old IP address if the IP address changed). This will cause PIM neighbors to remove this neighbor (or its old IP address) immediately. After an interface has changed its IP address, it MUST send a Hello message with its new IP address. If an interface changes one of its secondary IP addresses, a Hello message with an updated Address_List option and a non-zero HoldTime should be sent immediately. This will cause PIM neighbors to update this neighbor's list of secondary addresses immediately.
Notes:
Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider forged Hello messages with zero HoldTime or with altered Address_List options.
Errata ID: 1118
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
+------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
Notes:
In state Join, when event “Receive Prune (*,*,RP)” occurs and also in state Prune Pending, when event “Expiry Timer Expires” occurs, a situation occurs where an interface will be pruned possibly more rapidly than expected as in J state, when prune is received, PP state is entered and Prune-pending timer is started, but Expiry timer is not reset/halted/etc and this does have an effect in PP state. This issue is not handled in the detailed description on page 48. Is this intentional?
Errata ID: 1119
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
The action "Send PruneEcho(*,*,RP)" is triggered when the
router stops forwarding on an interface as a result of a
prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message
sent by the upstream router on a LAN with its own address in
the Upstream Neighbor Address field. Its purpose is to add
additional reliability so that if a Prune that should have
been overridden by another router is lost locally on the LAN,
then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on an interface
that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state.
Notes:
Forged PruneEcho messages could operate as a form of Denial-of-Service (effectively the same as a Prune(*,*,RP) in this context). The issue is resolved by using AH, but it is not listed as one of the forged message types in section 6.1.1.
Errata ID: 1121
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Prune-Pending (PP)
The router has received a Prune(S,G,rpt) on this interface
from a downstream neighbor and is waiting to see whether the
prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly
like the NoInfo state.
Notes:
If a single Prune(S,G,rpt) stops forwarding, then traffic can be interrupted even when it is still needed. There is a random delay between 0 and Effective_Override_Interval(I) (0 – 2.5 seconds by specification defaults) in which traffic stops until it is overridden and traffic starts flowing again. This appears to be an optimization for efficiency vs. reliability. I believe that this should be noted and made into an optional optimization.
Errata ID: 1122
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also recommend that PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
On unnumbered interfaces on point-to-point links, the router's address SHOULD be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also RECOMMEND that PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1123
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
It should say:
these state transitions in this state machine MUST NOT occur, although seeing such a packet may cause state transitions in other state machines.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1124
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune state. The Expiry Timer (ET) is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
It should say:
A compound Join/Prune message containing a Prune(S,G<rpt) is
received on interface I with its Upstream Neighbor Address
set to the router’s primary IP address on I.
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune state. The Expiry Timer (ET) is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
Notes:
This section does not consider “Upstream Neighbor Address” as does “Receive Prune(S,G,rpt)” in “Transitions from Prune State” on page 60 or “Receive Prune(S,G,rpt)” in “Transitions from Prune-Pending State” on page 59. Is that information not important in this state transition?
Errata ID: 1128
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.6.1 says:
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )
It should say:
Too many possibilities to list.
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1133
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.2 says:
Holdtime is the amount of time a receiver must keep the neighbor
reachable, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message never times out the neighbor. This may be
used with dial-on-demand links, to avoid keeping the link up with
periodic Hello messages.
Notes:
Holdtime is tunable by the sender and is required to be kept by the receiver. This coupled with the “infinity” metric 0xffff produces the conditions necessary for a Denial of Service to be possible. This is not addressed in section 6.1.1 (Forged Link-Local Messages) or 6.4 (Denial-of-Service Attacks). Additionally, utilizing AH will not solve this issue as Hello messages instantiate state upon receipt and this state constitutes the “service” that is abused in this form of attack. A tunable option to accept a maximum Holdtime for security purposes would resolve this condition.
Errata ID: 1135
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Sections 6.4 and A.2
The rationale for this is that there is no way in PIM-SM to prune traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then pruning each source individually.
Notes:
The paragraph beginning “The rationale for this…” describes a condition where a small cause can have a great effect – a (*,*,RP) join could cause state that, if it is not needed, requires a (*,G) join and many prunes for each source. This is mentioned as the last point in section 6.4, but section 6.4 fails to mention that “undoing” this state requires a join followed by multiple prunes.
Errata ID: 1142
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.3 says:
We recommend storing this information if
It should say:
We RECOMMEND storing this information if
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1143
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.3 says:
none
It should say:
PIM (*,G) Join/Prune state begins with a Join(*,G) sent to the RP. The metric to the RP is kept in the MRIB. Because the RP for this group can be any of several PIM routers, the source of the metric information in the MRIB is populated by any of the mechanisms discussed in section 4.7.
Notes:
PIM state begins with a join for a group sent towards the RP. It is not readily evident that the BSR keeps a list of current RPs for use in the hash function to map groups onto these RPs in order to seed our state.
Errata ID: 1145
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.4 says:
However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.6.
It should say:
However, we RECOMMEND storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.6.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1146
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.5 says:
However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.6.
It should say:
However, we RECOMMEND storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.6.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1151
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1 says:
PIM implementers should enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router.
It should say:
PIM implementers SHOULD enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1152
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.4.2 says:
Note (+): Implementations are advised not to make this a special
case, but to arrange that this path rejoin the normal packet
forwarding path.
It should say:
Note (+): Implementations are SHOULD NOT to make this a special
case, but to arrange that this path rejoin the normal packet
forwarding path.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1154
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines. On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also recommend that for backwards compatibility
It should say:
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet MAY cause state transitions in other state machines. On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links it is also RECOMMENDED that for backwards compatibility
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1156
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.2 says:
If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
It should say:
If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet MAY cause state transitions in other state machines.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1157
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.2 says:
point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1159
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Figure 5.
Notes:
Why isn’t (S,G) state considered for the (S,G,rpt) state machine (depicted in Figure 5 on page 58)? Wouldn’t an (S,G) join have an effect up on (S,G,rpt)?
Errata ID: 1160
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune-Pending state. The Expiry Timer
(ET) is restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
It should say:
None suggested.
Notes:
Infinite toggle for every pair of routers where one wants (*,G) and the other wants (*,G) and (S,G,rpt). State moves from Prune -> PruneTmp -> NI -> Prune for the (S,G,rpt) state machine. This causes upstream thrash with Join(S,G,rpt) followed by Prune(S,G,rpt) in continual succession. Which causes Prune (S,G,rpt) state to be state limited to never actually enter Prune state (NI -> PP -> NI).
Errata ID: 1161
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.6 says:
bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL OR
(JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
return TRUE
else
return FALSE
}
JoinDesired(*,G) is true when the router has forwarding state that
would cause it to forward traffic for G using shared tree state.
Note that although JoinDesired is true, the router's sending of a
Join(*,G) message may be suppressed by another router sending a
Join(*,G) onto the upstream interface.
Notes:
When would immediate_olist(*,G) be NULL and forwarding state exist?
Errata ID: 1162
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
RPF'(*,G) changes not due to an Assert
An event occurred that caused the next hop towards the RP for
G to change. This may be caused by a change in the MRIB
routing database or the group-to-RP mapping. Note that this
transition does not occur if an Assert is active and the
upstream interface does not change.
The upstream (*,G) state machine remains in Joined state.
Send Join(*,G) to the new upstream neighbor, which is the new
value of RPF'(*,G). Send Prune(*,G) to the old upstream
neighbor, which is the old value of RPF'(*,G). Use the new
value of RP(G) in the Prune(*,G) message or all zeros if RP(G)
becomes unknown (old value of RP(G) may be used instead to
improve behavior in routers implementing older versions of
this spec). Set the Join Timer (JT) to expire after
t_periodic seconds.
Notes:
Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.
Errata ID: 1166
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds.
It should say:
The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. If the
Join Timer is set to expire in less than t_override seconds, leave it
unchanged.
Notes:
It would make the Join Timer clearer to understand if an explicit statement was made indicating that if the Join Timer is less than t_override, it should be left unchanged. This needs to be made for “See Prune(S,G) to RPF’(S,G)”, “See Prune(S,G,rpt) to RPF’(S,G)”, and “See Prune(*,G) to RPF’(S,G)”.
Errata ID: 1167
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
The upstream (S,G) state machine remains in Joined state.
Send Join(S,G) to the new upstream neighbor, which is the new
value of RPF'(S,G). Send Prune(S,G) to the old upstream
neighbor, which is the old value of RPF'(S,G). Set the Join
Timer (JT) to expire after t_periodic seconds.
Notes:
Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.
Errata ID: 1168
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.8 says:
# Note: we joined the shared tree, but there was an (S,G) assert
# and the source tree RPF neighbor is different.
Notes:
In the comments on the “else” clause, why would we think that we were on the shared tree if the SPTbit is false?
Errata ID: 1169
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.9 says:
In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is used to delay triggered Join(S,G,rpt) messages to prevent implosions of triggered messages.
Notes:
What does “implosions of triggered messages” refer to?
Errata ID: 1170
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.9 says:
+------------++--------------------------------------------------------+ | || Event | | ++--------------+--------------+-------------+------------+ |Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ | | || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist | | || ->True | ->False | ->False | (S,G,rpt) | | || | | | ->non-NULL | +------------++--------------+--------------+-------------+------------+ |RPTNotJoined|| -> P state | - | - | -> NP state| |(G) (NJ) || | | | | +------------++--------------+--------------+-------------+------------+ |Pruned || - | -> NP state | -> NJ state | - | |(S,G,rpt) || | Send Join | | | |(P) || | (S,G,rpt) | | | +------------++--------------+--------------+-------------+------------+ |NotPruned || -> P state | - | -> NJ state | - | |(S,G,rpt) || Send Prune | | Cancel OT | | |(NP) || (S,G,rpt); | | | | | || Cancel OT | | | | +------------++--------------+--------------+-------------+------------+
Notes:
In the intersection of “RPTNotJoined(G)” and “PruneDesired(S,G,rpt) -> True”, the state table indicates that the result is to move into “Pruned(S,G,rpt)” state. This occurs again in the text on pages 80 and 81. Why would join state be entered for (*,G) simply in order to prune (S,G,rpt)?
Errata ID: 1181
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.6.5 says:
Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does
indicate that such a join should be dropped.
It should say:
Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does
indicate that such a join SHOULD be dropped.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1183
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5 says:
Holdtime
The amount of time a receiver must keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message should hold the state until canceled by
the appropriate canceling Join/Prune message, or timed out
according to local policy. This may be used with dial-on-demand
links, to avoid keeping the link up with periodic Join/Prune
messages.
Note that the HoldTime must be larger than the
J/P_Override_Interval(I).
It should say:
Holdtime
The amount of time a receiver MUST keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message SHOULD hold the state until canceled by
the appropriate canceling Join/Prune message, or timed out
according to local policy. This MAY be used with dial-on-demand
links, to avoid keeping the link up with periodic Join/Prune
messages.
Note that the HoldTime MUST be larger than the
J/P_Override_Interval(I).
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1184
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.1 says:
Each wildcard group set may contain one or more
(*,*,RP) source list entries in either the Joined or Pruned
lists.
A (*,*,RP) source list entry may only exist in a wildcard group
set. When added to a Joined source list, this type of source
entry expresses the router's interest in receiving traffic for
all groups mapping to the specified RP.
It should say:
Each wildcard group set MAY contain one or more
(*,*,RP) source list entries in either the Joined or Pruned
lists.
A (*,*,RP) source list entry MAY only exist in a wildcard group
set. When added to a Joined source list, this type of source
entry expresses the router's interest in receiving traffic for
all groups mapping to the specified RP.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1185
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.1 says:
Each group-
specific set may contain (*,G), (S,G,rpt), and (S,G) source list
entries in the Joined or Pruned lists.
(*,G)
The (*,G) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic sent to the
group through the Rendezvous-Point shared tree. There may
only be one such entry in both the Joined and Pruned lists of
a group-specific set.
(*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set
to the full length of the IP address, and both the WC and RPT
bits of the Encoded-Source-Address set.
(S,G,rpt)
The (S,G,rpt) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic through the
shared tree sent by the specified source to this group. For
each source address, the entry may exist in only one of the
Joined and Pruned source lists of a group-specific set, but
not both.
(S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address, and the WC bit cleared
and the RPT bit set in the Encoded-Source-Address.
(S,G)
The (S,G) source list entry is used in Join/Prune messages
sent towards the specified source. It expresses interest (or
lack thereof) in receiving traffic through the shortest path
tree sent by the source to the specified group. For each
source address, the entry may exist in only one of the Joined
and Pruned source lists of a group-specific set, but not both.
It should say:
Each group-
specific set MAY contain (*,G), (S,G,rpt), and (S,G) source list
entries in the Joined or Pruned lists.
(*,G)
The (*,G) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic sent to the
group through the Rendezvous-Point shared tree. There MUST
be one such entry in both the Joined and Pruned lists of
a group-specific set.
(*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set
to the full length of the IP address, and both the WC and RPT
bits of the Encoded-Source-Address set.
(S,G,rpt)
The (S,G,rpt) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic through the
shared tree sent by the specified source to this group. For
each source address, the entry MUST exist in only one of the
Joined and Pruned source lists of a group-specific set, but
not both.
(S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address, and the WC bit cleared
and the RPT bit set in the Encoded-Source-Address.
(S,G)
The (S,G) source list entry is used in Join/Prune messages
sent towards the specified source. It expresses interest (or
lack thereof) in receiving traffic through the shortest path
tree sent by the source to the specified group. For each
source address, the entry MUST exist in only one of the Joined
and Pruned source lists of a group-specific set, but not both.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1192
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
This list of (S,G,rpt) Pruned source-list entries MUST not be split in multiple messages.
It should say:
This list of (S,G,rpt) Pruned source-list entries MUST NOT be split in multiple messages.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1193
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune message, but the router has more than N (S,G,rpt) Prunes to add, then the router MUST choose to include the first N (numerically smallest in network byte order) IP addresses.
Notes:
Only N (S,G,rpt) Prune entries are transmitted in the biggest Join/Prune message, what about the remaining (S,G,rpt) entries? Are they ignored? Is a second message generated? This should be made clear.
Errata ID: 1194
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
Assert messages may also be sent in response to an Assert message from another router.
It should say:
Assert messages MAY also be sent in response to an Assert message from another router.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1195
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.2 says:
Either static configuration of IP addresses or an IPsec security association may be used.
It should say:
Either static configuration of IP addresses or an IPsec security association MAY be used.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1198
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.3.2.2 says:
In order to simplify the management problem, it may be acceptable to use the same authentication algorithm and authentication parameters, regardless of the sending RP and regardless of the destination DR. Although a unique SA is needed for each DR, the same authentication
It should say:
In order to simplify the management problem, it MAY be acceptable to use the same authentication algorithm and authentication parameters, regardless of the sending RP and regardless of the destination DR. Although a unique SA is needed for each DR, the same authentication
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1200
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.4 says:
- Forging a (*,*,RP) join presents a possibility for a denial-of-
service attack by causing all traffic in the domain to flow to the
PMBR issuing the join. (*,*,RP) behavior is included here
primarily for backwards compatibility with prior revisions of the
spec. However, the implementation of (*,*,RP) and PMBR is
optional. When using (*,*,RP), the security concerns should be
carefully considered.
It should say:
- Forging a (*,*,RP) join presents a possibility for a denial-of-
service attack by causing all traffic in the domain to flow to the
PMBR issuing the join. (*,*,RP) behavior is included here
primarily for backwards compatibility with prior revisions of the
spec. However, the implementation of (*,*,RP) and PMBR is
optional. When using (*,*,RP), the security concerns SHOULD be
carefully considered.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1201
Status: Held for Document Update
Type: Technical
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6 says:
See note.
It should say:
IPsec usage is recommended to secure PIM messages, but PIM relies upon an MRIB populated outside of PIM and it should be noted that for PIM security to be effective, securing the sources of change to the MRIB in a similar fashion to IPsec is required to be consistent and secure.
Notes:
An additional note should be made with regard to PIM security, possibly as
section 6.3.3?
Errata ID: 2927
Status: Verified
Type: Editorial
Reported By: Ang Way Chuang
Date Reported: 2011-08-09
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18
Section 4.2.2 says:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) {
Set SPTbit(S,G) to TRUE
}
}
It should say:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
Set SPTbit(S,G) to TRUE
}
}
Notes:
The logical evaluation is not properly enclosed.
Errata ID: 1094
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section Table of Con says:
A.2. Sources Internal to the PIM-SM Domain ...................144
It should say:
A.2. Sources Internal to the PIM-SM Domain ...................144
Notes:
One extra space is listed after the heading and before the item.
Errata ID: 1095
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 1. Per-(S,G) register state machine at a DR ................38
It should say:
Figure 1. Per-(S,G) register state machine at a DR ................39
Notes:
Figure 1 occurs on page 39, is listed as occurring on page 38.
Errata ID: 1096
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 4. Downstream per-interface (S,G) state machine ............53
It should say:
Figure 4. Downstream per-interface (S,G) state machine ............54
Notes:
Figure 1 occurs on page 54, is listed as occurring on page 53.
Errata ID: 1097
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
It should say:
Figure 5. Downstream per-interface (S,G,rpt) state machine ........58
Notes:
Figure 1 occurs on page 58, is listed as occurring on page 57.
Errata ID: 1098
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 6. Upstream (*,*,RP) state machine .........................62
It should say:
Figure 6. Upstream (*,*,RP) state machine ......................63-64
Notes:
Figure 1 occurs on pages 63-64, is listed as occurring on page 62.
Errata ID: 1101
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section List of Figu says:
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................77
It should say:
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................78
Notes:
Figure 1 occurs on page 78, is listed as occurring on page 77.
Errata ID: 1108
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section 4.2 says:
Second, we check to see if the SPTbit should be set because we've now switched from the RP tree to the SPT.
It should say:
See notes
Notes:
The dependent clause does not follow from the independent clause.
Errata ID: 1109
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section 4.2 says:
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in a implementation-dependent manner.
It should say:
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in an implementation-dependent manner.
Notes:
Misspelling
Errata ID: 1111
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2.2 says:
3. Noone wants the packet on the RP tree.
It should say:
3. No one wants the packet on the RP tree.
Notes:
Misspelling
Errata ID: 1112
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.1 says:
We note that some implementations do not send Hello messages on
point-to-point interfaces. This is non-compliant behavior. A
compliant PIM router MUST send Hello messages, even on point-to-
point interfaces.
It should say:
We note that some implementations do not send Hello messages on point-to-point interfaces. This is non-compliant behavior. A compliant PIM router MUST send Hello messages, even on point-to- point interfaces.
Notes:
It is not clear why this text is indented.
Errata ID: 1115
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.2 says:
We note that some PIM implementations do not send Hello messages on
point-to-point interfaces and thus cannot perform DR election on
such interfaces. This is non-compliant behavior. DR election MUST
be performed on ALL active PIM-SM interfaces.
It should say:
See notes.
Notes:
Are the different references to PIM and PIM-SM intentional? Does PIM-DM enter into this?
Errata ID: 1116
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.3 says:
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the LAN Prune Delay Hello option:
It should say:
In addition to the information recorded for the DR Election, the following per-neighbor information is obtained from the LAN Prune Delay Hello option:
Notes:
Misspelling.
Errata ID: 1117
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.3 says:
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective_Propagation_Delay of interface I is: … When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
It should say:
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Propagation Delay of interface I is: … When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
Notes:
Inconsistency. Either “Effective_Override_Interval” should be used or “Effective Override Interval” should be used.
Errata ID: 1126
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
See pages 72-76
It should say:
See notes
Notes:
The figure given on pages 72-73 lists additional state changes, the last three of which are “RPF’(S,G) changes not due to an Assert”, “RPF’(S,G) GenID changes”, “RPF’(S,G) changes due to an Assert”, but the order given in the descriptions after the diagram on pages 74-76 lists the last three as: “RPF’(S,G) changes due to an Assert”, “RPF’(S,G) changes not due to an Assert”, and “RPF’(S,G) GenID changes.”
Errata ID: 1127
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.9 says:
See pages 78-80
It should say:
See notes
Notes:
The figure given on page 78 lists additional state changes. The order given does not match the order given in the detailed descriptions that follow on pages 79-80.
Errata ID: 1129
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.1 says:
An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on an downstream interface that
is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state and perform
Actions A1 (below), which will initiate the assert negotiation
for (S,G).
It should say:
An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on a downstream interface that
is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state and perform
Actions A1 (below), which will initiate the assert negotiation
for (S,G).
Notes:
Misspelling.
Errata ID: 1130
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.1 says:
A4: Send AssertCancel(S,G).
Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default
values).
A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default
values).
It should say:
A4: Send AssertCancel(S,G).
Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default
values).
A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default
values).
Notes:
Missing words.
Errata ID: 1131
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.7.2 says:
The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router:
It should say:
See notes.
Notes:
The term “transients” is not defined in section 2.1. Does this refer to the same “transients” as in RFC 1112, section2, paragraph 3?
Errata ID: 1134
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.2 says:
The T bit specifies the ability of the
sending router to disable joins suppression.
It should say:
The T bit specifies the ability of the
sending router to disable join suppression.
Notes:
Misspelling.
Errata ID: 1136
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. The list of definitions that I was able to determine are given below. Some definitions are not given and these are marked below. Address_List 31* Assert(*,G) 128* Assert(S,G) 128* AssertCancel(*,G) 99* AssertCancel(S,G) 99* AssertTimer(*,G,I) not listed X AssertTimer(S,G,I) not listed X AssertTrackingDesired(*,G,I) 93* AssertTrackingDesired(S,G,I) 86* AssertWinner(*,G,I) 100* AssertWinner(S,G,I) 100* AssertWinnerMetric(*,G,I) 101* AssertWinnerMetric(S,G,I) 101* assert_metric 98* Assert_Override_Interval 132* Assert_Time 132* AT(*,G,I) 129* AT(S,G,I) 129* CheckSwitchToSpt(S,G) 28* CouldAssert(*,G,I) 93* CouldAssert(S,G,I) 86* CouldRegister(S,G) 41* Default_Hello_Holdtime not listed X DirectlyConnected(S) 27* DownstreamJPState(*,*,RP,I) 45* (state of FSM in section 4.5.1) DownstreamJPState(*,G,I) 49* (state of FSM in section 4.5.2) DownstreamJPState(S,G,I) 53* (state of FSM in section 4.5.3) DownstreamJPState(S,G,rpt,I) 56* (state of FSM in section 4.5.4) DR(I) 33* dr_is_better(a,b,I) 33* DR_Priority 31* Effective_Override_Interval(I) 36* Effective_Propagation_Delay(I) 35* ET(*,*,RP,I) 128* ET(*,G,I) 128* ET(S,G,I) 129* ET(S,G,rpt,I) 129* GenID 31* Hash_Function not listed X Hello_Holdtime 131* Hello_Period 130* HT(I) 31* IGMP 6* immediate_olist(*,*,RP) 22* immediate_olist(*,G) 22* immediate_olist(S,G) 22* infinite_assert_metric() 99* inherited_olist(S,G) 22* inherited_olist(S,G,rpt) 22* I_Am_Assert_Loser(*,G,I) not listed X I_Am_Assert_Loser(S,G,I) not listed X I_am_DR(I) 33* I_am_RP(G) 44* J/P_Holdtime 131* J/P_Override_Interval(I) 132* JoinDesired(*,*,RP) 64* JoinDesired(*,G) 68* JoinDesired(S,G) 73* joins(*,*,RP(G)) not listed X joins(*,*,RP) 23* joins(*,G) 23* joins(S,G) 23* JT(*,*,RP) 129* JT(*,G) 129* JT(S,G) 129* KAT(S,G) 129* KeepaliveTimer(S,G) not listed X Keepalive_Period 134* lan_delay_enabled(I) 35* LAN_Prune_Delay not listed X local_receiver_exclude(S,G,I) 23* local_receiver_include(*,G,I) not listed X local_receiver_include(S,G,I) not listed X lost_assert(*,G) 24* lost_assert(*,G,I) 100* lost_assert(S,G) 24* lost_assert(S,G,I) 100* lost_assert(S,G,rpt) 24* lost_assert(S,G,rpt,I) 100* MBGP 6* MFIB 6* MLD 6* MRIB 6* MRIB.next_hop(host) 25* my_assert_metric(*,G,I) not listed X my_assert_metric(S,G,I) 98* NBR(Interface,IP_address) not listed X NLT(N,I) not listed X OT(S,G,rpt) 77* Override_Interval(I) 130? (Why is it termed a “variable”?) packet_arrives_on_rp_tunnel(pkt) 43* pim_exclude(S,G) 22* pim_include(*,G) 22* pim_include(S,G) 22* PPT(*,*,RP,I) not listed X PPT(*,G,I) not listed X PPT(S,G,I) not listed X PPT(S,G,rpt,I) not listed X Propagation_Delay(I) 130? (Why is it termed a “variable”?) Propagation_delay_default 130* PruneDesired(S,G,rpt) 79* prunes(S,G,rpt) 23* Register-Stop(*,G) not listed X Register-Stop(S,G) not listed X Register-StopTimer(S,G) not listed X Register_Probe_Time 135* Register_Suppression_Time 135* RP(G) not listed X RPF 6* RPF’(*,G) 24* RPF’(S,G) 25* RPF’(S,G,rpt) 24* RPF_interface not listed X RPF_interface(host) not listed X RPFJoinDesired(G) 79* rpt_assert_metric(G,I) not listed X RST(S,G) 135? SPTbit(S,G) not listed X spt_assert_metric(S,I) 98* SSM 106* Suppression_Enabled(I) 36* SwitchToSptDesired(S,G) 28* TIB 6* Triggered_Hello_Delay 130* t_joinsuppress not listed X t_override 133* t_override_default 130* t_periodic 133* t_suppressed 133* Update_SPTbit(S,G,iif) 29* UpstreamJPState(S,G) not listed X
Notes:
The locations of the definitions of functions are not given. Given that there are so many functions, it would be useful to have a notation that indicates this. I propose adding a “*” next to the page reference that contains the definition of that function as well as adding an explanatory note to the index, such as:
For function definitions, see the pages marked with an asterisk (*).
Errata ID: 1137
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Index not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. AssertTimer(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertTimer(*,G,I) page 24 (missing on the page referred) AssertTimer(*,G,I) page 132 (missing on the page referred) AssertTimer(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AssertTimer(S,G,I) page 24 (missing on the page referred) AssertTimer(S,G,I) page 132 (missing on the page referred) AssertWinner(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertWinner(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AssertWinner(S,G,I) page 100 (duplicate reference) AssertWinnerMetric(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertWinnerMetric(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AT(*,G,I) page 24 (missing on the page referred) AT(*,G,I) page 91 (no explicit function reference is found, but it is referred to on the page) AT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AT(S,G,I) page 24 (missing on the page referred) AT(S,G,I) page 84 (no explicit function reference is found, but it is referred to on the page) CouldRegister(S,G) page 39 (no explicit function reference is found, but it is referred to on the page) DirectlyConnected(S) page 27 (duplicate reference) dr_is_better(a,b,I) page 33 (duplicate reference) ET(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page) ET(*,*,RP,I) page 46 (no explicit function reference is found, but it is referred to on the page) ET(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) ET(*,G,I) page 50 (no explicit function reference is found, but it is referred to on the page) ET(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) ET(S,G,I) page 53 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 57 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 59 (no explicit function reference is found, but it is referred to on the page) Hash_Function page 12 (no explicit function reference is found, but it is referred to on the page) Hash_Function page 105 (no explicit function reference is found, but it is referred to on the page) IGMP page 17 (missing on the page referred) IGMP page 23 (missing on the page referred) IGMP page 105 (missing on the page referred) J/P_Holdtime page 47 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 51 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 55 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 59 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 65 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 69 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 74 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 121 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 133 (no explicit function reference is found, but it is referred to on the page) JoinDesired(*,G) page 17 (missing on the page referred) joins(*,*,RP) page 86 (missing on the page referred) joins(*,*,RP) page 93 (missing on the page referred) JT(*,*,RP) page 15 (no explicit function reference is found, but it is referred to on the page) JT(*,G) page 16 (no explicit function reference is found, but it is referred to on the page) JT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KAT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KAT(S,G) page 26 (missing on the page referred) KAT(S,G) page 27 (missing on the page referred) KAT(S,G) page 28 (missing on the page referred) KAT(S,G) page 41 (missing on the page referred) KAT(S,G) page 43 (missing on the page referred) KAT(S,G) page 73 (missing on the page referred) KAT(S,G) page 108 (missing on the page referred) KeepaliveTimer(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KeepaliveTimer(S,G) page 26 (missing on the page referred) KeepaliveTimer(S,G) page 27 (duplicate reference) KeepaliveTimer(S,G) page 108 (missing on the page referred) KeepaliveTimer(S,G) page 129 (missing on the page referred) KeepaliveTimer(S,G) page 134 (missing on the page referred) LAN_Prune_Delay page 31 (no explicit function reference is found, but it is referred to on the page) local_receiver_include(S,G,I) page 23 (missing on the page referred) Next line duplicates the previous line (reference on page 144 is correct) MFIB page 13 (missing on the page referred) MLD page 17 (missing on the page referred) MLD page 23 (missing on the page referred) MLD page 105 (missing on the page referred) MRIB page 66 (duplicate reference) MRIB page 75 (missing on the page referred) NBR(Interface,IP address) page 37 (missing on the page referred) OT(S,G,rpt) page 20 (no explicit function reference is found, but it is referred to on the page) Override_Interval(I) page 14 (missing on the page referred) Override_Interval(I) page 34 (missing on the page referred) Override_Interval(I) page 132 (missing on the page referred) pim_exclude(S,G) page 22 (duplicate reference) pim_include(*,G) page 22 (duplicate reference) pim_include(S,G) page 22 (duplicate reference) PPT(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page) PPT(*,*,RP,I) page 46 (missing on the page referred) PPT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) PPT(*,G,I) page 50 (missing on the page referred) PPT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) PPT(S,G,I) page 53 (missing on the page referred) PPT(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page) PPT(S,G,rpt,I) page 57 (missing on the page referred) PPT(S,G,rpt,I) page 59 (missing on the page referred) Propagation_Delay(I) page 31 (missing on the page referred) Propagation_Delay(I) page 132 (missing on the page referred) Register-StopTimer(S,G) page 38 (missing on the page referred) Register-StopTimer(S,G) page 39 (missing on the page referred) Register-StopTimer(S,G) page 129 (missing on the page referred) Register-StopTimer(S,G) page 135 (no explicit function reference is found, but it is referred to on the page) RP(G) page 5 (missing on the page referred) RP(G) page 99 (missing on the page referred) RPF’(*,G) page 101 (missing on the page referred) RPF’(S,G) page 101 (missing on the page referred) rpt_assert_metric(G,I) page 99 (missing on the page referred) RST(S,G) page 38 (missing on the page referred) RST(S,G) page 39 (missing on the page referred) SPTbit(S,G) page 19 (no explicit function reference is found, but it is referred to on the page) SPTbit(S,G) page 53 (no explicit function reference is found, but it is referred to on the page) SPTbit(S,G) page 86 (duplication reference) SPTbit(S,G) page 108 (missing on the page referred) SSM page 10 (missing on the page referred) SwitchToSptDesired(S,G) page 28 (duplicate reference) t_joinsuppress page 64 (missing on the page referred) t_joinsuppress page 68 (missing on the page referred) t_suppressed page 73 (missing on the page referred)
Notes:
The items above are referred to in the Index, but were not found at the locations specified in the Index.
Errata ID: 1138
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. GenID page 14 RPF page 15 IGMP page 16 MLD page 16 JoinDesired(*,G) page 17 MRIB page 17 IGMP page 19 pim_exclude(S,G) page 21 immediate_olist(S,G) page 21 inherited_olist(S,G) page 21 inherited_olist(S,G,rpt) page 21 immediate_olist(*,*,RP) page 21 immediate_olist(*,G) page 21 lost_assert(S,G,rpt) page 22 inherited_olist(S,G,rpt) page 22 local_receiver_include(*,G,I) page 22 local_receiver_include(S,G,I) page 22 IGMP page 22 MLD page 22 NBR(Interface,IP_address) page 24 I_Am_Assert_Loser(S,G,I) page 25 AssertWinner(S,G,I) page 25 RPF_interface(Interface,IP_address) page 25 RPF’(*,G) page 25 RPF’(S,G,rpt) page 25 RPF’(*,G) page 25 Assert(S,G) page 25 RPF_interface(host) page 25 RP(G) page 25 I_Am_Assert_Loser(*,G,I) page 25 RPF_interface(host) page 26 MRIB page 26 RP(G) page 27 inherited_olist(S,G) page 28 inherited_olist(S,G,rpt) page 28 Update_SPTbit(S,G,iif) page 28 UpstreamJPState(S,G) page 28 Keepalive_Period page 28 RP(G) page 29 I_Am_Assert_Loser(S,G,I) page 29 Assert(S,G) page 29 RPF’(S,G) page 30 RPF’(*,G) page 30 Assert(S,G) page 30 JoinDesired(S,G) page 30 GenID page 32 MRIB page 37 Register_Probe_Time page 40 Register_Suppression_Time page 40 Register-Stop(S,G) page 42 inherited_olist(S,G,rpt) page 43 KeepaliveTimer(S,G) page 44 inherited_olist(S,G) page 44 RPF_interface(host) page 62 JoinDesired(*,*,RP) page 63 t_periodic page 63 MRIB page 63 t_joinsuppress page 63 t_override page 63 RPF_interface(host) page 64 JoinDesired(*,*,RP) page 65 immediate_olist(*,*,RP) page 65 NBR(Interface,IP_address) page 65 RPF_interface(host) page 65 MRIB page 65 t_periodic page 65 t_override page 65 RPF_interface(host) page 66 t_periodic page 66 t_override page 66 JoinDesired(*,G) page 67 t_periodic page 67 t_joinsuppress page 67 t_override page 67 JoinDesired(*,*,RP) page 68 AssertWinner(*,G,I) page 68 JoinDesired(*,G) page 69 immediate_olist(*,G) page 69 RPF’(*,G) page 69 t_periodic page 69 RP(G) page 69 t_override page 70 RPF_interface(host) page 70 RP(G) page 70 t_periodic page 70 MRIB page 71 JoinDesired(S,G) page 72 t_periodic page 72 SPTbit(S,G) page 72 RPF’(S,G) page 72 t_joinsuppress page 72 t_override page 72 RPF’(S,G) page 73 JoinDesired(S,G) page 74 inherited_olist(S,G) page 74 RPF’(S,G) page 74 t_override page 75 RPF’(S,G) page 75 RPF_interface(host) page 75 t_periodic page 76 t_override page 76 PruneDesired(S,R,rpt) page 78 RPTJoinDesired(G) page 78 inherited_olist(S,G,rpt) page 78 RPF’(S,G,rpt) page 78 RPF’(*,G) page 78 RP(G) page 79 t_override page 80 RPF’(S,G,rpt) page 80 RPF’(*,G) page 80 RPF’(S,G,rpt) page 81 PruneDesired(S,G,rpt) page 81 Assert(*,G) page 82 RPF’(*,G) page 82 JoinDesired(*,G) page 82 JoinDesired(*,*,RP) page 82 AssertTrackingDesired(S,G,I) page 84 RPF_interface(host) page 85 joins(*,*,RP) page 86 lost_assert(S,G,I) page 86 GenID page 89 RPF_interface(host) page 90 Assert(S,G) page 90 UpstreamJPState(S,G) page 90 AssertTrackingDesired(*,G,I) page 92 joins(*,*,RP) page 93 GenID page 96 RPF_interface(host) page 97 RP(G) page 97 Assert(*,G) page 97 rpt_assert_metric(G,I) page 98 infinite_assert_metric() page 98 rpt_assert_metric(G,I) page 98 MRIB page 99 RP(G) page 100 AssertWinnerMetric(S,G,I) page 100 Assert(S,G) page 100 Assert(*,G) page 100 Assert(S,G) page 101 Assert(*,G) page 101 AssertWinner(S,G,I) page 101 MRIB page 101 RPF’(*,G) page 102 IGMP page 104 MLD page 104 SSM page 107 SSM page 108 Assert(S,G) page 108 Triggered_Hello_Delay page 131 Default_Hello_Holdtime page 131 Hello_Period page 131 JT(*,G) page 131 AssertTimer(*,G,I) page 132 AssertTimer(S,G,I) page 132 Effective_Override_Interval(I) page 133 Register_Suppression_Time page 134 Register_Probe_Time page 134 SSM page 137 RPF_interface(host) page 144 local_receiver_include(S,G,I) page 145 local_receiver_include(*,G,I) page 145 DownstreamJPState(*,G,I) page 145 DownstreamJPState(S,G,rpt,I) page 145
Notes:
Functions were found in the document that were mentioned in the Index, but there was no reference given in the Index.
Errata ID: 1139
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. NotJoined(*,*,RP) page 15 NotJoined(*,G) page 16 NotJoined(S,G) page 18 Prune(*,*,RP) page 15 Join(*,G) page 17 Prune(*,G) page 17 Join(S,G) page 19 Prune(S,G) page 19 Prune(S,G,rpt) page 21 Join(*,G) page 21 Prune(S,G,rpt) page 25 Join(*,G) page 25 Join(S,G) page 29 Prune(S,G,rpt) page 29 Prune(*,*,RP) page 46 Join(*,*,RP) page 46 Join(*,*,RP) page 47 Prune(*,*,RP) page 47 Prune(*,*,RP) page 48 Join(*,*,RP) page 48 Prune(*,*,RP) page 49 Join(*,G) page 49 Prune(*,G) page 49 Join(*,G) page 50 Prune(*,G) page 50 Join(*,G) page 51 Prune(*,G) page 51 Join(*,G) page 52 Prune(*,G) page 52 Join(S,G) page 54 Prune(S,G) page 54 PruneEcho(*,*,RP) page 46 PruneEcho(*,*,RP) page 48 PruneEcho(*,*,RP) page 49 PruneEcho(*,G) page 50 PruneEcho(*,G) page 52 PruneEcho(S,G) page 54 Join(S,G) page 55 Prune(S,G) page 55 PruneEcho(S,G) page 56 Prune(S,G) page 56 Prune(S,G,rpt) page 57 Join(*,G) page 58 Join(S,G,rpt) page 58 Prune(S,G,rpt) page 58 Prune(S,G,rpt) page 59 Join(*,G) page 59 Join(S,G,rpt) page 59 Join(*,G) page 60 Join(S,G,rpt) page 60 Prune(S,G,rpt) page 60 Prune(S,G,rpt) page 61 Prune(*,G) page 61 Join(*,*,RP) page 61 Join(*,G) page 61 Join(*,*,RP) page 62 Prune(*,*,RP) page 62 Prune(*,*,RP) page 63 Join(*,*,RP) page 64 Prune(*,*,RP) page 64 Prune(*,*,RP) page 65 Join(*,*,RP) page 65 Join(*,*,RP) page 63 Join(*,*,RP) page 66 Prune(*,*,RP) page 66 Join(*,G) page 66 Prune(*,G) page 66 Join(*,G) page 67 Prune(*,G) page 67 Join(S,G) page 73 Prune(*,G) page 73 Join(*,G) page 68 Prune(*,G) page 68 Prune(*,G) page 69 Join(*,G) page 69 Join(*,G) page 70 Prune(*,G) page 70 Join(S,G) page 71 Prune(S,G) page 71 Prune(S,G,rpt) page 71 Join(S,G) page 74 Prune(S,G) page 74 Prune(*,G) page 75 Prune(S,G,rpt) page 75 Join(S,G) page 76 Prune(S,G) page 76 Prune(S,G,rpt) page 76 Join(*,G) page 76 Join(S,G,rpt) page 76 Join(S,G,rpt) page 77 Prune(S,G,rpt) page 78 Join(S,G,rpt) page 78 Prune(S,G) page 78 Join(S,G,rpt) page 79 Prune(S,G,rpt) page 79 Prune(S,G) page 80 Join(S,G,rpt) page 80 Prune(S,G,rpt) page 80 Prune(S,G,rpt) page 81 Join(*,G) page 81 Join(*,*,RP) page 81 Join(S,G,rpt) page 81 Prune(S,G,rpt) page 82 Join(*,G) page 82 Prune(S,G,rpt) page 82 Join(*,*,RP) page 82 Prune(*,G) page 82 Prune(*,*,RP) page 82 Join(*,*,RP) page 83 Prune(S,G,rpt) page 83 Join(S,G) page 85 Join(S,G) page 90 Join(*,G) page 93 Join(*,*,RP) page 93 Join(*,G) page 97 Join(*,*,RP) page 97 Join(*,G) page 101 Join(S,G) page 101 Join(S,G) page 102 Join(*,*,RP) page 102 Join(*,G) page 102 Prune(S,G,rpt) page 102 Join(S,G,rpt) page 102 Join(*,G) page 125 Prune(*,G) page 125 Join(S,G,rpt) page 125 Prune(S,G,rpt) page 125 Join(S,G) page 125 Prune(S,G) page 125 Join(*,*,RP) page 125 Prune(*,*,RP) page 125 Join(S,G) page 143 Join(*,*,RP) page 144 Joined(*,*,RP) page 15 Joined(*,G) page 16 Joined(S,G) page 18 Join(S,G) page 72 Prune(S,G) page 72 Prune(S,G,rpt) page 72 Join(S,G,rpt) page 82 IGMPv3 page 19 IGMPv3 page 20 IGMPv3 page 21 RPTNotJoined(G) page 20 NotPruned(S,G,rpt) page 20 Pruned(S,G,rpt) page 20 RPTNotJoined(G) page 77 Pruned(S,G,rpt) page 77 NotPruned(S,G,rpt) page 77 RPTNotJoined(G) page 78 Pruned(S,G,rpt) page 78 NotPruned(S,G,rpt) page 78 RPTNotJoined(host) page 80 RPTNotJoined(host) page 81 Pruned(S,G,rpt) page 81 NotPruned(S,G,rpt) page 81 immediate_olist(S,G,rpt) page 21 PMBR(S,G) page 43 RP_Keepalive_Period page 43 next_hop(host) page 63 next_hop(host) page 65 next_hop(host) page 66 Assert(*,*,RP) page 82 pref(S) page 98 metric(S) page 98 my_ip_address(I) page 98 pref(S) page 99 metric(S) page 99 my_ip_address(I) page 99 Value(G,M,C) page 105 C(i) page 105 pref(S) page 128 metric(S) page 128
Notes:
Some functions were found in the document that did not have any entry in the Index. These are itemized above.
Errata ID: 1140
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 2.1 says:
Upstream
Towards the root of the tree. The root of tree may be either
the source or the RP, depending on the context.
It should say:
Upstream
Towards the root of the tree. The root of the tree may be either
the source or the RP, depending on the context.
Notes:
Misspelling.
Errata ID: 1141
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 3.6 says:
This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source-specific trees.
It should say:
This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source for source-specific trees.
Notes:
Word choice.
Errata ID: 1144
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.1.4 says:
Local membership is the result of the local source-specific membership mechanism (such as IGMP version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won a (S,G) assert on this interface for this group.
It should say:
Local membership is the result of the local source-specific membership mechanism (such as IGMP version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won an (S,G) assert on this interface for this group.
Notes:
Misspelling.
Errata ID: 1147
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2 says:
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to RP, except at the RP when it is the
It should say:
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to the RP, except at the RP when it is the
Notes:
Missing word.
Errata ID: 1149
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2.2 says:
Basically, Update_SPTbit will set the SPTbit if we have the appropriate (S,G) join state, and if the packet arrived on the correct upstream interface for S, and if one or more of the following conditions applies:
It should say:
See notes
Notes:
Should “Basically, Update_SPTbit will set” be “Basically, Update_SPTbit(S,G,iif) will set”?
Errata ID: 1150
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.1 says:
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
It should say:
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay(I) and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
Notes:
Misspelling.
Errata ID: 1155
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.1 says:
PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
PIM Join/Prune messages with an upstream neighbor address field of all zeros also be accepted.
Notes:
Word choice.
Errata ID: 1163
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
If a (S,G) Assert occurs on the upstream interface,
It should say:
If an (S,G) Assert occurs on the upstream interface,
Notes:
Misspelling.
Errata ID: 1164
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
and this changes the this router's idea of the upstream neighbor,
It should say:
and this changes the router's idea of the upstream neighbor, -or- and this changes this router's idea of the upstream neighbor,
Notes:
Word choice.
Errata ID: 1165
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
In addition, if MRIB changes
It should say:
In addition, if the MRIB changes
Notes:
Missing word.
Errata ID: 1172
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.9 says:
If the router was previously in RPTNotJoined(G)
state, then there is no need to trigger an action in this state
machine because sending a Prune(S,G,rpt) is handled by the rules
for sending the Join(*,G) or Join(*,*,RP).
It should say:
See notes.
Notes:
A reference to a page would be very helpful at the end of the event description in reference to the “rules for sending the Join(*,G) or Join(*,*,RP).”
Errata ID: 1178
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.2 says:
See notes.
It should say:
See notes.
Notes:
The figure given on page 92 lists state changes which are “Assert Timer Expires”, “Receive Inferior Assert”, “Receive Preferred Assert”, and “CouldAssert(*,G,I) -> FALSE”, but the order given in the descriptions after the diagram on page 95 does not match this order.
Errata ID: 1179
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.2 says:
A4: Send AssertCancel(*,G).
Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return their default
values).
A5: Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return their default
values).
It should say:
A4: Send AssertCancel(*,G).
Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default
values).
A5: Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default
values).
Notes:
Missing words.
Errata ID: 1180
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.5 says:
In this case, it needs to ignore the assert state if it will win the assert once the SPTbit is set.
It should say:
In this case, it needs to ignore the assert state if it will win the assert once the SPT bit is set.
Notes:
Misspelling.
Errata ID: 1182
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9 says:
Type Types for specific PIM messages. PIM Types are:
It should say:
Type Types for specific PIM messages. PIM Types are:
Notes:
Spacing.
Errata ID: 1186
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same
message is redundant as the (*,G) entry covers the information
provided by the (S,G,rpt) entry.
It should say:
o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
message is redundant as the (*,G) entry covers the information
provided by the (S,G,rpt) entry.
Notes:
Misspelling.
Errata ID: 1187
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.
It should say:
o The same applies for a (*,G) Prune and (S,G,rpt) Prunes.
Notes:
Misspelling.
Errata ID: 1188
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
generated.
It should say:
o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
generated.
Notes:
Misspelling.
Errata ID: 1189
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o As Join/Prune messages are targeted to a single PIM neighbor,
including both a (S,G) Join and a (S,G,rpt) Prune in the same
message is usually redundant.
It should say:
o As Join/Prune messages are targeted to a single PIM neighbor,
including both an (S,G) Join and an (S,G,rpt) Prune in the same
message is usually redundant.
Notes:
Misspellings.
Errata ID: 1190
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The combination of a (S,G) Prune and a (S,G,rpt) Join could
possibly be used by a router to switch from receiving a particular
source on the shortest-path tree back to receiving it on the shared
tree (provided that the RPF neighbor for the shortest-path and
shared trees is common). However, Sparse-Mode PIM does not provide
a mechanism for explicitly switching back to the shared tree.
It should say:
o The combination of an (S,G) Prune and an (S,G,rpt) Join could
possibly be used by a router to switch from receiving a particular
source on the shortest-path tree back to receiving it on the shared
tree (provided that the RPF neighbor for the shortest-path and
shared trees is common). However, Sparse-Mode PIM does not provide
a mechanism for explicitly switching back to the shared tree.
Notes:
Misspellings.
Errata ID: 1196
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2011-05-09
Section 6.3.2.1 says:
In this "single shared key" mode of operation, the network administrator must choose an SPI for each DR that will be used to send it PIM protocol packets.
It should say:
See notes.
Notes:
What does “it” refer to?
s/it/the/
Errata ID: 1197
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 6.3.2.1 says:
The Security Policy Database at every DR is configured to select an SA (including the authentication algorithm, authentication parameters, and this SPI) when sending Register messages to this RP.
It should say:
The Security Policy Database at every DR is configured to select an SA (including the authentication algorithm, authentication parameters, and this SPI) when sending Register messages to an RP.
Notes:
Word choice.
Errata ID: 1199
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-26
Section 6.4 says:
There are a number of possible denial-of-service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating data false traffic.
It should say:
See notes.
Notes:
What does “or even by generating data false traffic” mean?
[Adrian Farrel] Clearly "or even by generating false data traffic."
Errata ID: 1202
Status: Held for Document Update
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section A.2 says:
o If the router receives a (S,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
It should say:
o If the router receives an (S,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
Notes:
Misspelling.
Errata ID: 2662
Status: Held for Document Update
Type: Editorial
Reported By: Ang Way Chuang
Date Reported: 2010-12-08
Held for Document Update by: Adrian Farrel
Section 4.1.4 says:
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.2.
It should say:
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.3.
Notes:
Section 4.5.2 deals with (*,G) Join/Prune messages, not (S,G) Join/Prune messages.
Errata ID: 1099
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 7. Upstream (*,G) state machine ............................67
It should say:
Figure 7. Upstream (*,G) state machine .........................67-68
Notes:
Figure 1 occurs on pages 67-68, is listed as occurring on page 67.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1100
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 8. Upstream (S,G) state machine ............................71
It should say:
Figure 8. Upstream (S,G) state machine .........................72-73
Notes:
Figure 1 occurs on page 72-73, is listed as occurring on page 71.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1102
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 10. Per-interface (S,G) Assert State machine ...............84
It should say:
Figure 10. Per-interface (S,G) Assert State machine ............84-85
Notes:
Figure 1 occurs on pages 84-85, is listed as occurring on page 84.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1103
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 11. Per-interface (*,G) Assert State machine ...............92
It should say:
Figure 11. Per-interface (*,G) Assert State machine ............92-93
Notes:
Figure 1 occurs on pages 92-93, is listed as occurring on page 92.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1120
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.2 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,G) | Prune(*,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,G) | | +------------++-------------+--------------+-------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,G) | Prune(*,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,G) | | +------------++-------------+--------------+-------------+-------------+
Notes:
In NoInfo state and in the Prune Pending state, upon receipt of the “Receive Prune(*,G)” event, there is an explicit state transition back to its own state. These seem redundant.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1125
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.7 says:
+----------------------------------------------------------------------+ | In Joined (J) State | +-----------------+-----------------+-----------------+----------------+ | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | | | RPF'(S,G) | +-----------------+-----------------+-----------------+----------------+ | Send | Increase Join | Decrease Join | Decrease Join | | Join(S,G); Set | Timer to | Timer to | Timer to | | Join Timer to | t_joinsuppress | t_override | t_override | | t_periodic | | | | +-----------------+-----------------+-----------------+----------------+
It should say:
+----------------------------------------------------------------------+ | In Joined (J) State | +-----------------+-----------------+-----------------+----------------+ | Event | Timer Expires | See Join(S,G) | See Prune(S,G) | | | | to RPF'(S,G) | to RPF'(S,G) | | | | | +-----------------+-----------------+-----------------+----------------+ | Action | Send | Increase Join | Decrease Join | | | Join(S,G); Set | Timer to | Timer to | | | Join Timer to | t_joinsuppress | t_override | | | t_periodic | | | +-----------------+-----------------+-----------------+----------------+
Notes:
The remaining portions would be inserted into the left portion of the remaining table on Page 73 and the two overflowing items in that table would go into a continuation beneath the table on Page 73.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1132
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.9 says:
All PIM control messages have IP protocol number 103.
It should say:
All PIM control messages have IP protocol number 103, per RFC 1700.
Notes:
The IP protocol assignment information is given without a reference to RFC 1700/STD 2.
--VERIFIER NOTES--
Per RFC 3232, RFC 1700 is replaced by an online database. A reference is no longer appropriate.
Errata ID: 1148
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.2 says:
# or Assert(*,G) message to be sent out interface iif.
It should say:
# or Assert(*,G) message to be sent out iif.
Notes:
“should be sent out interface iif” is redundant as “iif” stands for “incoming interface” and this expands to: “should be sent out interface incoming interface”, which is redundant.
--VERIFIER NOTES--
In this case "iif" is the identifier of an interface. It reads better as it is.
Errata ID: 1153
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.1 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+-------------+--------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,*,RP) | Prune | Pending | Expires | | || | (*,*,RP) | Timer | | | || | | Expires | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+-------------+--------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,*,RP) | Prune | Pending | Expires | | || | (*,*,RP) | Timer | | | || | | Expires | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | - | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
Notes:
At the intersection of “NoInfo (NI)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1158
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.3 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(S,G) | Prune(S,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(S,G) | | +------------++-------------+--------------+-------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(S,G) | Prune(S,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | - | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(S,G) | | +------------++-------------+--------------+-------------+-------------+
Notes:
At the intersection of “NoInfo (NI)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1171
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.9 says:
+----------------------------------------------------------------------+ | In NotPruned(S,G,rpt) State | +----------+--------------+--------------+--------------+--------------+ |Override | See Prune | See Join | See Prune | RPF' | |Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> | |expires | RPF' | RPF' | RPF' | RPF' (*,G) | | | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | | +----------+--------------+--------------+--------------+--------------+ |Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, | |(S,G,rpt);| t_override) | | t_override) | t_override) | |Leave OT | | | | | |unset | | | | | +----------+--------------+--------------+--------------+--------------+
It should say:
See notes
Notes:
The table at the bottom of page 78 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “NotPruned(S,G,rpt) State”.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1173
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.4 says:
+----------------------------------------------------------------------+ | In NoInfo (NI) State | +---------------+-------------------+------------------+---------------+ | Receive | Receive Assert | Data arrives | Receive | | Inferior | with RPTbit | from S to G on | Acceptable | | Assert with | set and | I and | Assert with | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | and | (S,G,I) | (S,G,I) | and AssTrDes | | CouldAssert | | | (S,G,I) | | (S,G,I) | | | | +---------------+-------------------+------------------+---------------+ | -> W state | -> W state | -> W state | -> L state | | [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] | +---------------+-------------------+------------------+---------------+ +----------------------------------------------------------------------+ | In I Am Assert Winner (W) State | +----------------+------------------+-----------------+----------------+ | Assert Timer | Receive | Receive | CouldAssert | | Expires | Inferior | Preferred | (S,G,I) -> | | | Assert | Assert | FALSE | +----------------+------------------+-----------------+----------------+ | -> W state | -> W state | -> L state | -> NI state | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | +----------------+------------------+-----------------+----------------+
It should say:
See notes.
Notes:
The tables at the bottom of page 84 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and “I AM Assert Winner” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1174
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.1 says:
+---------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +-------------+-------------+-------------+-------------+-------------+ |Receive |Receive |Receive |Assert Timer |Current | |Preferred |Acceptable |Inferior |Expires |Winner's | |Assert |Assert with |Assert or | |GenID | | |RPTbit clear |Assert | |Changes or | | |from Current |Cancel from | |NLT Expires | | |Winner |Current | | | | | |Winner | | | +-------------+-------------+-------------+-------------+-------------+ |-> L state |-> L state |-> NI state |-> NI state |-> NI state | |[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] | +-------------+-------------+-------------+-------------+-------------+ +----------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +----------------+-----------------+------------------+----------------+ | AssTrDes | my_metric -> | RPF_interface | Receive | | (S,G,I) -> | better than | (S) stops | Join(S,G) on | | FALSE | winner's | being I | interface I | | | metric | | | +----------------+-----------------+------------------+----------------+ | -> NI state | -> NI state | -> NI state | -> NI State | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | +----------------+-----------------+------------------+----------------+
It should say:
See notes.
Notes:
The table at the top of page 85 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1175
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.2 says:
It must not
forward packets for G onto interface I with the exception of
traffic from sources for which is has (S,G) "I am Assert Winner"
state.
It should say:
It must not
forward packets for G onto interface I with the exception of
traffic from sources for which it has (S,G) "I am Assert Winner"
state.
Notes:
Misspelling.
--VERIFIER NOTES--
Cannot see difference between reported and corredted text
Errata ID: 1176
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.2 says:
+----------------------------------------------------------------------+ | In NoInfo (NI) State | +-----------------------+-----------------------+----------------------+ | Receive Inferior | Data arrives for G | Receive Acceptable | | Assert with RPTbit | on I and | Assert with RPTbit | | set and | CouldAssert | set and AssTrDes | | CouldAssert(*,G,I) | (*,G,I) | (*,G,I) | +-----------------------+-----------------------+----------------------+ | -> W state | -> W state | -> L state | | [Actions A1] | [Actions A1] | [Actions A2] | +-----------------------+-----------------------+----------------------+ +---------------------------------------------------------------------+ | In I Am Assert Winner (W) State | +----------------+-----------------+-----------------+----------------+ | Assert Timer | Receive | Receive | CouldAssert | | Expires | Inferior | Preferred | (*,G,I) -> | | | Assert | Assert | FALSE | +----------------+-----------------+-----------------+----------------+ | -> W state | -> W state | -> L state | -> NI state | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | +----------------+-----------------+-----------------+----------------+
It should say:
See notes.
Notes:
The tables at the bottom of page 92 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and the “I Am Assert Winner” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.
Errata ID: 1177
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.2 says:
+---------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +-------------+-------------+-------------+-------------+-------------+ |Receive |Receive |Receive |Assert Timer |Current | |Preferred |Acceptable |Inferior |Expires |Winner's | |Assert with |Assert from |Assert or | |GenID | |RPTbit set |Current |Assert | |Changes or | | |Winner with |Cancel from | |NLT Expires | | |RPTbit set |Current | | | | | |Winner | | | +-------------+-------------+-------------+-------------+-------------+ |-> L state |-> L state |-> NI state |-> NI state |-> NI state | |[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] | +-------------+-------------+-------------+-------------+-------------+ +----------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +----------------+----------------+-----------------+------------------+ | AssTrDes | my_metric -> | RPF_interface | Receive | | (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or | | FALSE | Winner's | being I | Join | | | metric | | (*,*,RP(G)) on | | | | | Interface I | +----------------+----------------+-----------------+------------------+ | -> NI state | -> NI state | -> NI state | -> NI State | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | +----------------+----------------+-----------------+------------------+
It should say:
See notes.
Notes:
The tables at the top of page 93 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.
Errata ID: 1191
Status: Rejected
Type: Editorial
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.9.5.2 says:
On a router with a large amount of multicast state,
It should say:
On a router with a large amount of multicast states, -or- On a router with a large amount of multicast state information, -or- On a router with a large multicast state,
Notes:
Word choice.
--VERIFIER NOTES--
This is common usage.
"state information" might have been clearer, but "state" is acceptable.
Errata ID: 2804
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Edited by: Adrian Farrel
Date Edited: 2011-05-08
(2) typo
In Section 3, at the bottom of page 11, the RFC says:
[...]. The standard definition for virtual
concatenation allows each virtual concatenation components to travel
over diverse paths. [...]
^
It should say:
[...]. The standard definition for virtual
| concatenation allows each virtual concatenation component to travel
over diverse paths. [...]
or perhaps better:
[...]. The standard definition for virtual
| concatenation allows the virtual concatenation components to travel
over diverse paths. [...]
(4) inconsistency in examples
Still within Section 3, in the lower half of page 15,
under the headline:
Examples of Labels
there are multiple occurrances of an index shift that makes the text
inconsistent with the tables on page 14 and the upper half of page 15.
E.g., "Kth-1" for "K>0" would result in "0th, 1st, 2nd" where the
appropriate table (at tho bottom of page 14) gives "1st, 2nd, 3rd" :
K SDH VC-4
---------------
0 other
1 1st TUG-3
2 2nd TUG-3
3 3rd TUG-3
Hence,
a)
vv
| Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
should be corrected to say:
| Example 2: the label for the VC-3 within the Kth TUG-3 within the
VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
b)
vv
| Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth
STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
should be corrected to say:
| Example 3: the label for the Uth STS-1_SPE/VC-3 within the Sth
STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
c)
vv
| Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2
| in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
^^
is: S>0, U>0, K=0, L>0, M=0.
should be corrected to say:
| Example 4: the label for the VT6/VC-2 in the Lth VT Group/TUG-2
| in the Uth STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
is: S>0, U>0, K=0, L>0, M=0.
and
d)
vv
| Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT
| Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the
^^
Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
should be corrected to say:
| Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth VT
| Group/TUG-2 within the Uth STS-1_SPE/VC-3 within the
Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
(5) incomplete example
In Annex 1, at the bottom of page 21, the last list item says:
10. An STS-1-3v SPE signal is formed by the application of RCC with
value 0, NVC with value 3 (virtual concatenation of 3
components), MT with value 1, and T with value 0 to an STS-1 SPE
Elementary Signal.
This text does not specify the significant NCC value.
It should say instead:
10. An STS-1-3v SPE signal is formed by the application of RCC with
| value 0, NCC with value 0, NVC with value 3 (virtual
concatenation of 3 components), MT with value 1, and T with
value 0 to an STS-1 SPE Elementary Signal.
Notes:
This Erratum was duplicated from Erratum 43 in order to separate the issues raised
Errata ID: 43
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Adrian Farrel
Date Rejected: 2011-05-08
(1) use of "N"
In Section 2.1 of RFC 4606, on page 6, the explanations for
the NCC field contain the Note:
Note 2: When a transparent STS-N/STM-N signal is requested that is
limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the
signal type must be STS-N/STM-N, RCC with flag 1, NCC set to 1.
Such text (and similar) contains an unfortunate mess-up of two
distinct uses of "N", with different range of admissible values
for STS-N and STM-N.
This becomes particularly confusing in phrases like
"a single contiguously concatenated STS-Nc_SPE/VC-4-Nc".
I strongly recommend to avoid this overloaded use of "N"
in a single context.
Using "M" for one of these two "N"s instead, i.e. talking
about "STS-M/STM-N", or talking about "STS-<3*N>/STM-N" or
even "STS-3N/STM-N", would remove the ambiguity and add to
the clarity of the text.
(3) continuation of (1)
Within section 3, the numbered rules on mid-page 13 would also
benefit from application of the arguments given in item (1) above:
1. S=1->N is the index of a particular STS-3/AUG-1 inside an
STS-N/STM-N multiplex. S is only significant for SONET STS-N
(N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and
STM-0.
should better be specified as:
1. S=1->N is the index of a particular STS-3/AUG-1 inside an
| STS-3N/STM-N multiplex.
| S is only significant for SONET STS-3N and SDH STM-N (N>0).
S must be 0 and ignored for STS-1 and STM-0.
and
2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and SDH
STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0.
should better be specified as:
2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
STS-3/AUG-1.
| U is only significant for SONET STS-3N and SDH STM-N (N>0).
U must be 0 and ignored for STS-1 and STM-0.
Notes:
Erratum 43 has been duplicated to allow separate treatment of the different elements reported. This copy is used to address the rejected parts. The rest of the Erratum is now 2804.
--VERIFIER NOTES--
Points 1) and 3) are rejected. Although the repeated use of "N" could lead a reader to be confused, this is common usage amongst writers on TDM, and the readership within CCAMP has so far been unconfused.
Errata ID: 905
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
problems with IPv6 SSM address range, and with related text
The 4th paragraph of Section 1, on page 3, RFC 4607 says:
Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the
range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic
allocation by a host, as described in [IPv6-MALLOC]. Addresses in
the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6
SSM addresses. ([IPv6-MALLOC] indicates that FF3x::0000:0001 to
FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM]
mandates that P=1 and T=1, hence their designation as invalid.) ...
I see a lot of problems in that reasoning.
a) The most obvious issue first:
As far as I can see, RFC 3307 [IPv6-MALLOC] only requires for
"Permanent IPv6 Multicast Addresses":
Multicast addresses assigned by IANA MUST have the T bit set to 0 and
the P bit set to 0.
(RFC 3307, Section 4, top of page 4)
This restriction is not mentioned for other cases.
Since the '3' nibbles in "FF3x::0000:0000 through FF3x::3FFF:FFFF"
just mean P=1 and T=1 (cf. RFC 3306 [IPv6-UBM], Section 4, pp. 2/3),
IMHO the phrase from the above quotation,
[IPv6-MALLOC] indicates that FF3x::0000:0001 to
FF3x::3FFF:FFFF must set P=0 and T=0,
is neither logical nor conclusive. Hence the final conclusion,
"hence their designation as invalid."
does not hold.
Perhaps it would have been much more simple and clear to just
declare the range FF3x::0000:0000 through FF3x::3FFF:FFFF as
reserved or invalid -- without giving any reason.
b) Delving into further details of RFC 3307, one can find that
Section 4.2 reserves the range 0x40000000 to 0x7FFFFFFF for
"Permanent IPv6 Multicast Group Identifiers" with the intent that
assignments in that range hold
"regardless of the upper 96 bits of the multicast address".
On the other hand, the current IPv6 Addressing Architecture document
clearly states that
T=0 means "well known" / "permanently-assiged" / IANA allocated,
while
T=1 means "transient" / "dynamically allocated".
Under this rule, the above "regardless" in RFC 3307 is partially
invalid, because upper 96 bits containing T=1 are not allowed for
IANA allocated MC addresses.
[Note: Perhaps, this statement is also inappropriate, because
RFC 3307 initially states (in Section 4, at the bottom of page 3):
.... The following guidelines assume that the prefix of the
multicast address has been initialized according to [ADDRARCH] or
[UNIMCAST].
and both specifications quoted restrict or fix the values of some
of these upper 96 bits ...]
Hence, there is a subtle conflict between RFC 3307 and RFC 4291 !
c) Taking the ADDRARCH and RFC 3307 rules together, it is clear
that the first sentence of the RFC 4607 quotation above,
Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
reserved in [IPv6-MALLOC] for allocation by IANA.
does not hold, as T=1 in these addresses !
Later on, in Section 9 (IANA Cosiderations, page 15), RFC 4607 says:
IANA allocates IPv4 addresses in the range 232.0.0.1 through
232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to
FF3x::7FFF:FFFF. [...]
The latter clearly contradicts RFC 4291 for this reason (T=1).
Therefore, this range might better have been reserved/forbidden,
or excluded from the IPv6 SSM address range.
Taking all together:
There are serious conflicts between RFC 4291, RFC 3307, and RFC 4607.
Sadly enough, it seems that it was not a good idea to assign
FF3x::/32 for IPv6 SSM.
I'm sure that RFC 4291 should NOT be called in question.
Perhaps, it would have been better to restrict the IPv6 SSM range to
FF3x::8000:0000/31, and *not* provide for any subrange available
for specific IANA assignments.
Then, should there really arise the serious need for IANA allocated,
specific IPv6 SSM addresses, another (small) range (with T=0 and P=0)
could be assigned additionally for this purpose.
[Note 1: Thus, this address range would indeed fall under the regime
of Section 4.1 of RFC 3307, "Permanent IPv6 Multicast Addresses".
Note 2: T=0 + P=1 would necessitate a formal update to RFC 3306 that
does not allow this combination, and maybe to RFC 3956 as well.]
Notes:
from pending
Errata ID: 906
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Section 7.5 says:
applied to all source address
It should say:
applied to all source addresses
Notes:
from pending
Errata ID: 904
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Rejected by: Adrian Farrel
Date Rejected: 2011-05-08
Section 16 says:
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
It should say:
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Notes:
Unfortunately, Section 1 (first paragraph) and Section 11
of RFC 4607 refer to the previous IPv6 Address Architecture
document, RFC 3513, that has been superseded by RFC 4291 (February 2006).
from pending
--VERIFIER NOTES--
At the time of document approval for 4607, 4291 had not been published and the authors needed to make a normative reference to an RFC and not to an I-D.
However, this is not an issue because anyone tracking the reference to 3513 will find that it has been obsoleted by 4291 and will read the correct document.
Errata ID: 42
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Section 4 says:
Additional information:
Magic number(s): File extension(s): Macintosh File Type Code(s):
It should say:
Additional information:
Magic number(s):
File extension(s):
Macintosh File Type Code(s):
Notes:
line folding issue
Errata ID: 731
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Section 5 says:
Consider the following example, which describes a media stream that allows the transport of G.711 audio and T.38 fax information: m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF
It should say:
Consider the following example, which describes a media stream that
allows the transport of G.711 audio and T.38 fax information:
m=audio 6800 RTP/AVP 0 98
a=rtpmap:98 t38/8000
a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF
Notes:
line folding issue
Errata ID: 732
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-08-11
Section 7 says:
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
It should say:
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Notes:
Item [2] refers to RFC 2327.
That RFC had been obsoleted by RFC 4566 at the time of publication
of RFC 4612 (RFC 4566 had been published 3 weeks before RFC 4612).
Errata ID: 2629
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2010-11-12
Held for Document Update by: Tim Polk
Section 1 says:
Specifications for IETF protocols that indicate that this mechanism is an applicable authentication mechanism MUST mandate that implementations support an strong data security service, such as TLS.
It should say:
Specifications for IETF protocols that indicate that this mechanism is an applicable authentication mechanism MUST mandate that implementations support a strong data security service, such as TLS.
Notes:
Just a typo in "a strong data security service".
Errata ID: 41
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Andrew G. Malis
Date Verified: 2006-11-01
Section 1 says:
The main functions required to support frame relay PW by a Provider Edge (PE) include:
It should say:
The main functions required to support frame relay PWs by a Provider Edge (PE) include:
Notes:
from pending
Errata ID: 817
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Verifier Name: Andrew G. Malis
Date Verified: 2006-11-01
(1) [[posted separately.]]
(2) improper wording (mismatch with what follows)
On page 3, the last paragraph above Figure 1 says:
v vvv
The following figure describes the reference models that are derived
from [RFC3985] to support the frame relay PW emulated services.
It should say:
| The following figure describes the reference model that is derived
from [RFC3985] to support the frame relay PW emulated services.
(3) typo (missing article)
Within Section 5, the 2nd list item on page 6 says:
- Frame relay Local Management Interface (LMI) is terminated locally
in the PE connected to the frame relay attachment circuit.
It should say:
| - The Frame relay Local Management Interface (LMI) is terminated
locally in the PE connected to the frame relay attachment circuit.
(4) missing article
The last bullet within Section 7.2, near the top of page 8, says:
- Payload
The payload field corresponds to X.36/X.76 frame relay frame
information field with the following components removed: bit/byte
stuffing, frame relay header, and FCS. [...]
It should say:
- Payload
| The payload field corresponds to an X.36/X.76 frame relay frame
information field with the following components removed: bit/byte
stuffing, frame relay header, and FCS. [...]
(5) typos/grammar
The last bulleted item in Section 7.6.2, on top of page 12, says:
vvvvvv
| - Otherwise, if the payload is longer, then the length specified in
| the control word padding characters are removed according to the
length field.
^
It should say:
v v
| - Otherwise, if the payload is longer than the length specified in
| the control word, padding characters are removed according to the
length field.
^
(6) typo
The second sentence in the first paragraph of Section 7.9, on page 12,
v
[...]. If the PE detects a service-affecting condition for a
| particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA
FRF1.1, the PE MUST communicate to the remote PE the status of the PW
that corresponds to the frame relay DLCI status. [...]
should say:
v
[...]. If the PE detects a service-affecting condition for a
| particular DLCI, as defined in [Q933] Q.933, Annex A.5, cited in IA
FRF1.1, the PE MUST communicate to the remote PE the status of the PW
that corresponds to the frame relay DLCI status. [...]
(7) typo/grammar
The last sentence in the second paragraph of Section 7.9, on page 12,
[...]. The IANA allocation registry of "Pseudowire Type" is defined
in [RFC4446] along with initial allocated values.
should say:
| [...]. The IANA allocation registry of "Pseudowire Types" is defined
| in [RFC4446] along with initially allocated values.
Notes:
from pending
Errata ID: 40
Status: Verified
Type: Technical
Reported By: Carlos Pignataro
Date Reported: 2006-10-25
Section 5.5 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Extraneous part of the AVP Header in Figure 6.
Errata ID: 598
Status: Verified
Type: Technical
Reported By: Carlos Pignataro
Date Reported: 2006-10-25
Section 5.3 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 94 | MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Missing "Attribute Type" in the AVP Header of Figure 4.
Errata ID: 599
Status: Verified
Type: Technical
Reported By: Carlos Pignataro
Date Reported: 2006-10-25
Section 5.4 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 95 | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Missing "Attribute Type" in the AVP Header of Figure 5.
Errata ID: 600
Status: Verified
Type: Technical
Reported By: Carlos Pignataro
Date Reported: 2006-10-25
Section 5.6 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Extraneous part of the AVP Header in Figure 7.
Errata ID: 607
Status: Verified
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2007-10-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-24
Section 2.2 says:
object = begin-object [ member *( value-separator member ) ]
end-object
It should say:
object = begin-object [ member *( value-separator member ) ]
end-object
Notes:
(edited by Alexey): Wrong indentation on the second line of the ABNF production, otherwise this is not legal ABNF.
Errata ID: 825
Status: Rejected
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel
(1) [[posted separately.]]
(2) [plaintext flaw]
In the second paragraph of Section 8, near the bottom of page 9,
RFC 4631 says:
[...]. The interrelation of entries in the
ifTable is defined by Interfaces Stack Group defined in [RFC2863].
It should say:
[...]. The interrelation of entries in the
| ifTable is defined by the Interfaces Stack Group defined in
[RFC2863].
^^^^^
(2') [punctuation] -- legacy, but not reported for RFC 4327
Conformant to the punctuation newly introduced in the REFERENCE
clauses, parts of the DESCRIPTION subclauses of the MODULE-IDENTITY
macro invocation should also be amended with a trailing full-stop:
On top of page 13, change:
This revision published as RFC 4631"
REVISION
"200601110000Z" -- 11 January 2006
DESCRIPTION
"Initial version published as RFC 4327"
::= { transmission 227 }
to say:
| This revision published as RFC 4631."
REVISION
"200601110000Z" -- 11 January 2006
DESCRIPTION
| "Initial version published as RFC 4327."
::= { transmission 227 }
(3) LmpInterval TEXTUAL-CONVENTION (page 13)
The clause,
DESCRIPTION
"The interval delay in milliseconds."
perhaps should better say:
DESCRIPTION
| "The delay interval in milliseconds."
or even:
DESCRIPTION
| "The interval period for a periodically performed LMP operation,
| in milliseconds."
[Rationale: It's not the interval that's getting delayed ...]
(4) LmpRetransmitInterval TEXTUAL-CONVENTION (page 13)
The clause,
DESCRIPTION
"The retransmission interval delay in milliseconds."
perhaps should better say:
DESCRIPTION
| "The retransmission delay interval in milliseconds."
or even better:
DESCRIPTION
| "The (initial) retransmission interval in milliseconds."
[Rationale: It's not the interval that's getting delayed ...]
(old #5) lmpNbrRetransmitInterval OBJECT-TYPE (page 15) -- resolved
(new #5) lmpNbrRetransmitInterval OBJECT-TYPE (page 15)
-- legacy, but originally not reported
There's an extraneous blank line in the middle of the REFERENCE clause
that should be deleted (cf. lmpNbrRetryLimit OBJECT-TYPE, below).
(old #6) lmpNbrRetryLimit OBJECT-TYPE (page 15) -- resolved
(new #6) lmpCcUnderlyingIfIndex and lmpCcIsIf OBJECT-TYPEs (page 20)
-- newly introduced
The punctuation within the DESCRIPTION clauses for these objects
has been changed using one semicolon each.
IMHO, this is unfortunate because it might be misinterpreted as
excluding the subsequent half-sentences from the initial "If"
condition in these sentences that in fact are also preconditions
for the statements now after the semicolons.
(7) lmpCcRemoteAddressType OBJECT-TYPE (page 21)
DESCRIPTION
"This value represents the remote control channel IP address
type. In point-to-point configuration, this value can be set
to unknown(0)."
::= { lmpControlChannelEntry 6 }
should better say:
DESCRIPTION
"This value represents the remote control channel IP address
| type. In point-to-point configurations, this value can be set
to unknown(0)."
::= { lmpControlChannelEntry 6 }
^
[ The possible alternative, "In a point-to-point configuration, ..."
is not proposed here, to maintain a style similar to the minimal
change for the next object -- see (8) below.]
(8) lmpCcRemoteIpAddr OBJECT-TYPE (page 21) -- partially resolved
DESCRIPTION
"[...]
The Control channel must be numbered on non-point-to-point
configuration. For point-to-point configuration, the
remote control channel address can be of type unknown
in which case this object must be a zero-length string. The
lmpCcRemoteId object then identifies the unnumbered
address."
::= { lmpControlChannelEntry 7 }
should better say:
DESCRIPTION
"[...]
The control channel must be numbered on non-point-to-point
| configurations. For point-to-point configurations, the
remote control channel address can be of type unknown
in which case this object must be a zero-length string. The
lmpCcRemoteId object then identifies the unnumbered
address."
::= { lmpControlChannelEntry 7 }
(9) lmpCcHelloInterval OBJECT-TYPE (page 22)
An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
The default is never 'set', it is defined in the specification.
Hence,
DESCRIPTION
"This object specifies the value of the HelloInterval
parameter. The default value for this object should be
set to lmpCcHelloIntervalDefault."
::= { lmpControlChannelEntry 10 }
should better say:
DESCRIPTION
"This object specifies the value of the HelloInterval
| parameter. The default value to be used for this object
| is lmpCcHelloIntervalDefault."
::= { lmpControlChannelEntry 10 }
(9') lmpCcHelloIntervalMin OBJECT-TYPE (page 22) ,
(9'') lmpCcHelloIntervalMax OBJECT-TYPE (page 22) ,
(10) lmpCcHelloDeadInterval OBJECT-TYPE (page 23) ,
(10') lmpCcHelloDeadIntervalMin OBJECT-TYPE (page 23) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE (page 23)
The change from item (9) above should be applied there similarly:
Replace the phrase,
"[...]. The default value for this object should be
set to lmp<*>Default."
by:
| "[...]. The default value to be used for this object
| is lmp<*>Default."
using, at all instances, the appropriate value for the placeholder <*>.
(11) lmpControlChannelPerfEntry OBJECT-TYPE (page 25)
DESCRIPTION
"An entry in this table is created by a LMP-enabled device for
every control channel. lmpCcCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
in this table."
The latter is not true.
In this MIB module, the discontinuity is monitored per table *entry*
(conceptual row), not for the table as a whole -- see the DESCRIPTIONs
for lmp<*>DiscontinuityTime later in the RFC.
Therefore, the above clause should say:
DESCRIPTION
"An entry in this table is created by a LMP-enabled device for
every control channel. lmpCcCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
| in this entry (conceptual row)."
(12) lmpCcChannelStatusAckSent OBJECT-TYPE (page 35)
The clause,
DESCRIPTION
"This object counts the number of ChannelStatus messages
that have been sent on this control channel."
::= { lmpControlChannelPerfEntry 47 }
refers to the wrong message type; it should say:
DESCRIPTION
| "This object counts the number of ChannelStatusAck messages
that have been sent on this control channel."
::= { lmpControlChannelPerfEntry 47 }
(13) lmpTeLinkEntry OBJECT-TYPE (page 37)
The DESCRIPTION clause contains the sentence:
[...]. The
administrative status value is controlled from the ifEntry.
[...]
This sentence should say:
[...]. The
| administrative status is controlled from the ifEntry.
[...]
(13') lmpLinkVerifyTransportMechanism OBJECT-TYPE (page 41) -- new
Missing punctution between the two parts of the REFERENCE clause:
REFERENCE
"Link Management Protocol, RFC 4204
Synchronous Optical Network (SONET)/Synchronous Digital
Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
Test Messages, RFC 4207."
should say:
REFERENCE
"Link Management Protocol, RFC 4204.
Synchronous Optical Network (SONET)/Synchronous Digital
Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
Test Messages, RFC 4207."
[... or use a semicolon after "RFC 4204".]
[Note: This item not reported for RFC 4327 -- there was a page
break effectively hiding the issue.]
(14) lmpTeLinkPerfEntry OBJECT-TYPE (page 43)
The correction from item (11) above is to be applied here as well:
Replace:
DESCRIPTION
"An entry in this table is created by an LMP-enabled device for
every TE link. lmpTeCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
in this table."
by:
DESCRIPTION
"An entry in this table is created by an LMP-enabled device for
every TE link. lmpTeCounterDiscontinuityTime is used
to indicate potential discontinuity for all counter objects
| in this entry (conceptual row)."
(15) lmpTeEndVerifyRetransmit OBJECT-TYPE (page 46)
-- rationale given now extended
DESCRIPTION
"This object counts the number of EndVerify messages that
have been retransmitted over this control channel."
::= { lmpTeLinkPerfEntry 12 }
is inappropriate -- it does not match the indexing structure of the
LMP TE Link Performance Table. In accordance with the text supplied
for the other objects in this Table, it should say:
DESCRIPTION
"This object counts the number of EndVerify messages that
| have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 12 }
(16) lmpTeTestStatusFailureRetransmit OBJECT-TYPE (page 48)
DESCRIPTION
"This object counts the number of TestStatusFailure messages
that have been retransmitted on this TE link."
::= { lmpTeLinkPerfEntry 20 }
should say:
DESCRIPTION
"This object counts the number of TestStatusFailure messages
that have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 20 }
[ According to Section 12.5.8. of the LMP specification [RFC 4204],
LMP TestStatusFailure messages are transmitted over the control
channel; hence, "retransmitted *on* this TE Link" is wrong! ]
(17) lmpTeLinkSummaryRetransmit OBJECT-TYPE (page 49)
The correction from item (15) above is to be applied here as well:
Replace:
DESCRIPTION
"This object counts the number of LinkSummary messages that
have been retransmitted over this control channel."
::= { lmpTeLinkPerfEntry 25 }
by:
DESCRIPTION
"This object counts the number of LinkSummary messages that
| have been retransmitted for this TE link."
::= { lmpTeLinkPerfEntry 25 }
(18) lmpTeChannelStatusAckSent OBJECT-TYPE (page 50)
The correction from item (12) above is to be applied here as well:
Replace:
DESCRIPTION
"This object counts the number of ChannelStatus messages
that have been sent for this TE link."
::= { lmpTeLinkPerfEntry 34 }
by:
DESCRIPTION
| "This object counts the number of ChannelStatusAck messages
that have been sent for this TE link."
::= { lmpTeLinkPerfEntry 34 }
(19) lmpDataLinkEntry OBJECT-TYPE (page 52)
The correction from item (13) above is to be applied here as well:
The sentence in the DESCRIPTION clause,
[...]. The administrative status value is
controlled from the ifEntry. [...]
should say:
| [...]. The administrative status is controlled
from the ifEntry. [...]
(20) lmpDataLinkPerfEntry OBJECT-TYPE (page 56)
The correction from item (11) above is to be applied here as well:
Replace:
DESCRIPTION
"An entry in this table contains information about
the LMP performance counters for the data-bearing links.
lmpDataLinkDiscontinuityTime is used to indicate potential
discontinuity for all counter objects in this table."
by:
DESCRIPTION
"An entry in this table contains information about
the LMP performance counters for the data-bearing links.
lmpDataLinkDiscontinuityTime is used to indicate potential
| discontinuity for all counter objects in this entry."
(21a) lmpNotificationMaxRate OBJECT-TYPE (page 58)
-- item was numbered (21) previously; recent punctuation
updates now incorporated in text below
The DESCRIPTION text (near the end of its 2nd paragraph, ff.) says:
[...]. For instance, a network of 100 nodes
with 5 links of 128 wavelengths each and a link verification
of 1 minute, with no more than 10% of the links failed at any
given time, would have 1 notification per second sent from
each node, or 100 notifications per second for the whole
network. The rest of the notifications are negligible
compared to this number.
To alleviate the congestion problem, the
lmpNotificationMaxRate object can be used to implement a
throttling mechanism. It is also possible to enable/disable
certain type of notifications.
It should say, correcting two flaws (line breaks adjusted):
[...]. For instance, a network of 100 nodes
with 5 links of 128 wavelengths each and a link verification
| interval of 1 minute, with no more than 10% of the links failed
at any given time, would have 1 notification per second sent
from each node, or 100 notifications per second for the whole
network. The rest of the notifications are negligible
compared to this number.
To alleviate the congestion problem, the
lmpNotificationMaxRate object can be used to implement a
throttling mechanism. It is also possible to enable/disable
| certain types of notifications.
(21b) lmpUnprotected NOTIFICATION-TYPE (page 61) -- newly introduced
In the DESCRIPTION clause,
[...]. If the remaining operational
control channel fails, then there will be no more control
channels between the pair of nodes and all the TE links
| between the pair of nodes, will go to degraded state. [...]
^
the newly added comma makes no sense, it separates the noun from the
verb after 'and'; this sentence should say:
[...]. If the remaining operational
control channel fails, then there will be no more control
channels between the pair of nodes and all the TE links
| between the pair of nodes will go to degraded state. [...]
Perhaps, a comma migth instead be inserted before the 'and':
[...]. If the remaining operational
control channel fails, then there will be no more control
| channels between the pair of nodes, and all the TE links
| between the pair of nodes will go to degraded state. [...]
(21c) lmpModuleReadOnlyCompliance MODULE-COMPLIANCE, restriction
clause for (lmpDataLinkTable) OBJECT lmpDataLinkIPAddr (page 71)
DESCRIPTION
"The size of the data-bearing link IP address depends on
the type of data-bearing link. Data-bearing link IP
address size is zero if the link is unnumbered, four if
the link IP address is IPv4, and sixteen if the link IP
address is IPv6."
should better say:
DESCRIPTION
"The size of the data-bearing link IP address depends on
| the type of data-bearing link. The data-bearing link IP
address size is zero if the link is unnumbered, four if
the link IP address is IPv4, and sixteen if the link IP
address is IPv6."
(22) lmpNodeGroup OBJECT-GROUP (page 72)
The RFC says:
DESCRIPTION
"Collection of objects that represent LMP node
configuration."
::= { lmpGroups 1 }
It should say:
DESCRIPTION
| "Collection of objects that represents the LMP node
configuration."
::= { lmpGroups 1 }
[ In fact, it is *the collection* (singular) that represents
the node configuration! ]
(23) lmpControlChannelGroup OBJECT-GROUP (page 72/73)
On mid-pge 73, the RFC says:
DESCRIPTION
"Objects that can be used to configure LMP interface."
It should say:
DESCRIPTION
| "Objects that can be used to configure LMP interfaces."
(24) lmpDataLinkGroup OBJECT-GROUP (page 77)
Similar to item (22) above, the clause,
DESCRIPTION
"Collection of objects that represent data-bearing link
configuration."
::= { lmpGroups 9 }
should better say:
DESCRIPTION
"Collection of objects that represents data-bearing link
configurations."
::= { lmpGroups 9 }
Notes:
Some of the errata listed above correspond to errata also reported for RFC 4327 (referred to as "old").
from pending
--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.
In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.
Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.
Errata ID: 39
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel
Date Rejected: 2007-02-24
Section 7 says:
In lmpDataLinkTable:
{
It should say:
In lmpDataLinkTable:
{
Notes:
spurious indentation
from pending
--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.
In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.
Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.
Errata ID: 2955
Status: Verified
Type: Technical
Reported By: Olivier Le Rigoleur
Date Reported: 2011-09-03
Verifier Name: ron bonica
Date Verified: 2011-09-09
Section 6.1 says:
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
~~~~~
It should say:
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/22 \ | |
Notes:
~Should be 10.24.12.0/22 as described just above
Errata ID: 1577
Status: Held for Document Update
Type: Technical
Reported By: Tony Li
Date Reported: 2008-10-23
Held for Document Update by: Ron Bonica
Section 3.1 says:
For example, the legacy "Class B" network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16, the "/16" indicating that the mask to extract the network portion of the prefix is a 32-bit value where the most significant 16 bits are ones and the least significant 16 bits are zeros. Similarly, the legacy "Class C" network number 192.168.99.0 is defined as the prefix 192.168.99.0/24; the most significant 24 bits are ones and the least significant 8 bits are zeros.
It should say:
For example, the legacy "Class B" network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16, the "/16" indicating that the mask to extract the network portion of the prefix is a 32-bit value where the most significant 16 bits are ones and the least significant 16 bits are zeros. Similarly, the legacy "Class C" network number 192.168.99.0 is defined as the prefix 192.168.99.0/24; the most significant 24 bits are ones and the least significant 8 bits are zeros. In cases where a prefix has 1, 2, or 3 trailing insignificant octets, it is permissible to elide the insignificant octets and trailing '.' separators. Thus, 172.16.0.0/16 may also be represented as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24.
Notes:
This adds some clarifying text and documents a common convention for displaying prefixes. It was never the intention of the authors to exclude the alternative notation and it has since come into vogue. It should be explicitly documented as being acceptable.
Errata ID: 1824
Status: Held for Document Update
Type: Editorial
Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
Held for Document Update by: Ron Bonica
Section 6.1 says:
To make this example more realistic, assume that C4 and C5 are multi-
homed through some other service provider, "PB". Further assume the
existence of a site, "C7", that was originally connected to "RB" but
that has moved to "PA". For this reason, it has a block of network
numbers that are assigned out PB's block of (the next) 2048 x /24.
o C7. Assign 10.32.0 through 10.32.15. This block is described by
the route 10.32.0.0/20 (mask 255.255.240.0).
For the multi-homed sites, assume that C4 is advertised as primary
via "RA" and secondary via "RB"; and that C5 is primary via "RB" and
secondary via "RA". In addition, assume that "RA" and "RB" are both
connected to the same transit service provider, "BB".
Graphically, this topology looks something like this:
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
It should say:
To make this example more realistic, assume that C4 and C5 are multi-
homed through some other service provider, "PB". Further assume the
existence of a site, "C7", that was originally connected to "PB" but
that has moved to "PA". For this reason, it has a block of network
numbers that are assigned out PB's block of (the next) 2048 x /24.
o C7. Assign 10.32.0 through 10.32.15. This block is described by
the route 10.32.0.0/20 (mask 255.255.240.0).
For the multi-homed sites, assume that C4 is advertised as primary
via "PA" and secondary via "PB"; and that C5 is primary via "PB" and
secondary via "PA". In addition, assume that "PA" and "PB" are both
connected to the same transit service provider, "BB".
Graphically, this topology looks something like this:
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
Notes:
All the reference of "RA" and "RB" to be replaced with "PA" and "PB".
Errata ID: 38
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01
Section 2 says:
3. Eventual exhaustion of the 32-bit IPv4 address space.
It was clear that then-current rates of Internet growth would
cause the first two problems to become critical sometime between
1993 and 1995. Work already in progress on topological
assignment of addressing for Connectionless Network Service
(CLNS), which was presented to the community at the Boulder IETF
in December of 1990, led to thoughts on how to re-structure the
32-bit IPv4 address space to increase its lifespan. Work in the
ROAD group followed and eventually resulted in the publication of
[RFC1338], and later, [RFC1519].
The design and deployment of CIDR was intended to solve these
problems by providing a mechanism to slow the growth of global
routing tables and to reduce the rate of consumption of IPv4
address space. It did not and does not attempt to solve the
third problem, which is of a more long-term nature; instead, it
endeavors to ease enough of the short- to mid-term difficulties
to allow the Internet to continue to function efficiently while
progress is made on a longer-term solution.
More historical background on this effort and on the ROAD group
may be found in [RFC1380] and at [LWRD].
3. Classless Addressing as a Solution
It should say:
3. Eventual exhaustion of the 32-bit IPv4 address space. It was clear that then-current rates of Internet growth would cause the first two problems to become critical sometime between 1993 and 1995. Work already in progress on topological assignment of addressing for Connectionless Network Service (CLNS), which was presented to the community at the Boulder IETF in December of 1990, led to thoughts on how to re-structure the 32-bit IPv4 address space to increase its lifespan. Work in the ROAD group followed and eventually resulted in the publication of [RFC1338], and later, [RFC1519]. The design and deployment of CIDR was intended to solve these problems by providing a mechanism to slow the growth of global routing tables and to reduce the rate of consumption of IPv4 address space. It did not and does not attempt to solve the third problem, which is of a more long-term nature; instead, it endeavors to ease enough of the short- to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer-term solution. More historical background on this effort and on the ROAD group may be found in [RFC1380] and at [LWRD]. 3. Classless Addressing as a Solution
Notes:
In Section 2, on page 4 of RFC 4632, the text after the
enumerated item '3.' up to the end of the section is indented
too much (by 4 columns), making it erroneously appear to belong
to that item '3.'
--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.
Errata ID: 799
Status: Rejected
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01
(1) [[posted separately.]]
(2) typo (word replication)
In the second paragraph of Section 5.2, at the bottom of page 12,
RFC 4632 says:
[...]. If the "child"
network were to lose internal connectivity to 192.168.65.0/24 (which
| is part of its aggregate), traffic from the "parent" to the to the
"child" destined for 192.168.65.1 will follow the "child's"
advertised route. [...]
^^^^^^^^^^^^^
It should say:
[...]. If the "child"
network were to lose internal connectivity to 192.168.65.0/24 (which
| is part of its aggregate), traffic from the "parent" to the "child"
destined for 192.168.65.1 will follow the "child's" advertised route.
[...]
(3) garbled sentence
The second paragraph of Section 7, on page 18, says:
A description of techniques to populate the IN-ADDR.ARPA zone when
and used address that blocks that do not align to octet boundaries is
described in [RFC2317].
Apparently, this sentence is garbled; as written, it makes no sense.
Perhaps, it was intended to say:
A description of techniques to populate the IN-ADDR.ARPA zone when
| used address blocks do not align to octet boundaries is described in
[RFC2317].
(4) typo (singular/plural mismatch)
On page 19, the second enumerated bullet in Section 9 says:
2. Acceleration of the exponential trend in late 1993 and early 1994
as CIDR "supernet" blocks were first assigned by the NIC and
routed as separate legacy class-C networks by service provider.
It should say:
2. Acceleration of the exponential trend in late 1993 and early 1994
as CIDR "supernet" blocks were first assigned by the NIC and
| routed as separate legacy class-C networks by service providers.
^
(5) incomplete status change of legacy documents
Section 11 (pp. 21/22) re-classifies a couple of legacy RFCs as
Historic.
Unfortunately, there are additional documents closely related to
these re-classified documents left alone -- and apparently still
current.
IMHO, it would have been much clearer to also re-classify RFC 1797
and RFC 1879 as Historic, as well.
Note:
Admittedly, there may be a gap in the IETF document maintenance
procedures not formally allowing Informational and Experimental
RFCs to be re-classified as Historic. If this was the reason for
omitting the named RFCs from Section 11 of RFC 4632, it would
perhaps have been useful to "obsolete" these RFCs by RFC 4632.
This situation is bound to recur with more Informational RFCs
published as companion documents to Standards Track RFCs;
thus, a general procedural solution should be sought to visibly
(in the RFC index) 'outdate' such RFCs when updates get published.
Notes:
from pending
--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.
Note: This RFC has been obsoleted by RFC6234
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 2415
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.1 says:
The initial Description in the file, on page 18 of the RFC, says:
vvvvvvvvvvvvvvvvvv
* Description:
* This file implements the Secure Hash Signature Standard
* algorithms as defined in the National Institute of Standards
* and Technology Federal Information Processing Standards
* Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
* published on August 1, 2002, and the FIPS PUB 180-2 Change
* Notice published on February 28, 2004.
It should say:
It should say: * Description: |* This file implements the Secure Hash Algorithms * as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 * published on August 1, 2002, and the FIPS PUB 180-2 Change * Notice published on February 28, 2004.
Notes:
Avoiding the term "Signature" in accordance with the Standards
mentioned. The NIST consistently uses the acronyms "SHA" for
"Secure Hash Algorithm" and "SHS" for "Secure Hash Standard"
and precisely distinguished between these two terms.
Errata ID: 2426
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
Similar to item (9) above, the Description comment of SHA224Result contains improper wording and unpleasent formatting. Additionally, counting 28 elements as ranging from the "0th" up to the "28th" is unpleasant and wrong -- it would indicate 29 elements (octets) ! On mid-page 36, the RFC says: * Description: * This function will return the 224-bit message * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 28th element. For correctness and consistency, and for improved readability, it should say: * Description: * This function will return the 224-bit message digest * into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 27.
Errata ID: 37
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
The Description of SHA1PadMessage, on page 30, says: * Description: * According to the standard, the message must be padded to an * even 512 bits. The first padding bit must be a '1'. The last * 64 bits represent the length of the original message. All bits * in between should be 0. This helper function will pad the * message according to those rules by filling the Message_Block * array accordingly. When it returns, it can be assumed that the * message digest has been computed. For clarity, it should say: * Description: |* According to the standard, the message must be padded to the next |* proper multiple of 512 bits. The first padding bit must be a '1'. * The last 64 bits represent the length of the original message. * All bits in between should be 0. This helper function will pad * the message according to those rules by filling the Message_Block * array accordingly. When it returns, it can be assumed that the * message digest has been computed.
Errata ID: 2421
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
The Description of SHA1ProcessMessageBlock, on page 31, says: * Parameters: * None. This is not true, as can be seen subsequently in the source code. The RFC should say: * Parameters: * context: [in/out] * The SHA context to update
Errata ID: 2422
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
The initial Description in this file, on page 33, says: * Description: * This file implements the Secure Hash Signature Standard * algorithms as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 * published on August 1, 2002, and the FIPS PUB 180-2 Change * Notice published on February 28, 2004. It should say: * Description: * This file implements the Secure Hash Algorithms SHA-224 and * SHA-256, as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-2 published on August 1, 2002, and * the FIPS PUB 180-2 Change Notice published on February 28, 2004. Rationale: FIPS-PUB 180-1 only specified SHA-1, neither SHA-224 nor SHA-256. FIPS-PUB 180-2 has introduced SHA-256 (and SHA-384 and SHA-512 as well), and SHA-224 has been introduced by the "Change Notice 1". Thus, citation of FIPS PUB 180-1 is void and inappropriate in the context of SHA-224 and SHA-256. Avoiding the term "Signature" also conforms to the above Standards -- cf. item (4) and (5) above. Restricting the text to the scope of the file -- cf. item (5) above.
Errata ID: 2423
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
The comment text, near the bottom of page 33, says: * Caveats: * SHA-224 and SHA-256 are designed to work with messages less * than 2^64 bits long. This implementation uses SHA224/256Input() * to hash the bits that are a multiple of the size of an 8-bit * character, and then uses SHA224/256FinalBits() to hash the * final few bits of the input. It should better say -- cf. item (6) above: * Caveats: * SHA-224 and SHA-256 are designed to work with messages less * than 2^64 bits long. This implementation uses SHA224/256Input() * to hash the bits that are a multiple of the size of an 8-bit |* character, and then optionally uses SHA224/256FinalBits() * to hash the final few bits of the input.
Errata ID: 2424
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
On mid-page 34, there is the code:
/*
* add "length" to the length
*/
static uint32_t addTemp;
#define SHA224_256AddLength(context, length) \
(addTemp = (context)->Length_Low, (context)->Corrupted = \
(((context)->Length_Low += (length)) < addTemp) && \
(++(context)->Length_High == 0) ? 1 : 0)
It should say (modifying the last line):
/*
* add "length" to the length
*/
static uint32_t addTemp;
#define SHA224_256AddLength(context, length) \
(addTemp = (context)->Length_Low, (context)->Corrupted = \
(((context)->Length_Low += (length)) < addTemp) && \
(++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )
Rationale: Same as for item (7) above.
Errata ID: 2427
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
Similar to item (9) and (16) above, the Description of SHA256Result contains improper wording and unpleasent formatting. Additionally, counting 32 elements as ranging from the "0th" up to the "32nd" is unpleasant and wrong -- it would indicate 33 elements (octets) ! On page 39, the RFC says: * Description: * This function will return the 256-bit message * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 32nd element. For correctness and consistency, and for improved readability, it should say: * Description: * This function will return the 256-bit message digest * into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 31.
Errata ID: 2429
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
The Description of SHA224_256PadMessage, near the bottom of page 40, says: * Description: * According to the standard, the message must be padded to an * even 512 bits. The first padding bit must be a '1'. The * last 64 bits represent the length of the original message. * All bits in between should be 0. This helper function will pad * the message according to those rules by filling the * Message_Block array accordingly. When it returns, it can be * assumed that the message digest has been computed. For clarity, it should say (cf. item (10) above): * Description: |* According to the standard, the message must be padded to the next |* proper multiple of 512 bits. The first padding bit must be a '1'. * The last 64 bits represent the length of the original message. * All bits in between should be 0. This helper function will pad * the message according to those rules by filling the * Message_Block array accordingly. When it returns, it can be * assumed that the message digest has been computed.
Errata ID: 2435
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
Within the '#ifdef USE_32BIT_ONLY' macro definition branch of the
file, on mid-page 50 the RFC says:
/*
* add "length" to the length
*/
static uint32_t addTemp[4] = { 0, 0, 0, 0 };
#define SHA384_512AddLength(context, length) ( \
addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
(context)->Corrupted = (((context)->Length[3] == 0) && \
((context)->Length[2] == 0) && ((context)->Length[1] == 0) && \
((context)->Length[0] < 8)) ? 1 : 0 )
It should say:
/*
* add "length" to the length
*/
static uint32_t addTemp[4] = { 0, 0, 0, 0 };
#define SHA384_512AddLength(context, length) ( \
addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
(context)->Corrupted = (((context)->Length[0] < addTemp[3]) && \
((context)->Length[1] == 0) && ((context)->Length[1] == 0) && \
((context)->Length[0] == 0)) ? shaInputTooLong : shaSuccess )
Rationale:
The context words Lenght[0] ... Length[3] represent the unsigned
128-bit-wide running (bit-)length of the message text hash so far,
in most-significant word first order.
The code fragment above is intended to add to this value the
unsigned 32-bit value (uint32_t) length, and to detect overflow
(to 2^128 and above).
The given code is wrong.
(Apparently it has never been tested with messages long enough to
exhibit this misbehaviour.)
Other parts of the sample code show how this can be done correctly
in the case of long accumulators consisting of two 32-bit words
-- cf. the code snippits in item (7) and (14) above, and item (27)
below, as well,
The replacement code corrects this issue.
Furthermore, the original code suffers from the same problem as
in item (7) and (14) above; this has been corrected accordingly,
as well.
Errata ID: 2437
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the function prototypes for SHA384_512Reset do not
supply the expected size of the formal argument 'H0'.
This inconsistency should be corrected -- as in item (18) above.
There are two instances of the issue (see item (xx) below for
another two similar instances, with the function declarations):
(28a)
Within the function prototype definition part of the
'#ifdef USE_32BIT_ONLY'
branch of the sample code, near the bottom of page 50, the RFC says:
static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
For consistency and clarity, it should say:
static int SHA384_512Reset(SHA512Context *context,
uint32_t H0[SHA512HashSize/4]);
(28b)
Within the function prototype definition part of the
'#else /* !USE_32BIT_ONLY */'
branch of the sample code, near the bottom of page 51, the RFC says:
static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
For consistency and clarity, it should say:
static int SHA384_512Reset(SHA512Context *context,
uint64_t H0[SHA512HashSize/8]);
Errata ID: 2441
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
Similar to item (9), (16), (17), (22), (29), and (30) above, the Description of SHA384_512ResultN contains improper wording. Additionally, counting 48/64 elements as ranging from the "0th" up to the "48th/64nd" is unpleasant and wrong -- that erroneously indicates 49/65 elements (octets) ! On page 65/66, the RFC says: * Description: * This helper function will return the 384-bit or 512-bit message << page break >> * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 48th/64th element. For correctness, it should say: * Description: * This helper function will return the 384-bit or 512-bit message << page break >> * digest into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 47/63.
Errata ID: 2413
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 3 says:
The last two text lines of Section 3, on mid-page 6, say:
v
| ROTL^n(x) = ROTR^(w-x)(x)
ROTR^n(x) = ROTL^(w-n)(x)
It should say:
They should say:
v
| ROTL^n(x) = ROTR^(w-n)(x)
ROTR^n(x) = ROTL^(w-n)(x)
Errata ID: 747
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
The Description of SHA224_256ProcessMessageBlock, on top of page 42, says: * Description: * This function will process the next 512 bits of the message * stored in the Message_Block array. Consistently with the remainder of the test, it should say: * Description: |* This helper function will process the next 512 bits of the * message stored in the Message_Block array.
Errata ID: 2430
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
Near the bottom of page 43, the Description of SHA224_256Reset says:
* Description:
* This helper function will initialize the SHA256Context in
* preparation for computing a new SHA256 message digest.
For completeness and consistency, it should say:
* Description:
* This helper function will initialize the SHA256Context in
|* preparation for computing a new SHA-224 or SHA-256 message digest.
^^^^^^^^^^ ^
Errata ID: 2432
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The initial Description in this file, on page 45, says: * Description: * This file implements the Secure Hash Signature Standard * algorithms as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 * published on August 1, 2002, and the FIPS PUB 180-2 Change * Notice published on February 28, 2004. It should say: * Description: * This file implements the Secure Hash Algorithms SHA-384 and * SHA-512, as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-2 published on August 1, 2002, and * the FIPS PUB 180-2 Change Notice published on February 28, 2004. Rationale: FIPS-PUB 180-1 only specified SHA-1, neither SHA-384 nor SHA-512. FIPS-PUB 180-2 has introduced SHA-384 and SHA-512 (and SHA-256 as well), and the "Change Notice 1" has introduced SHA-224. Thus, citation of FIPS PUB 180-1 is void and inappropriate in the context of SHA-384 and SHA-512. Avoiding the term "Signature" also conforms to the above Standards -- cf. item (4), (5), and (12) above. Restricting the text to the scope of the file -- cf. item (5) and (12) above.
Errata ID: 2436
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
Within the '#ifndef USE_32BIT_ONLY' macro definition branch of the
file, on mid-page 51 the RFC says:
/*
* add "length" to the length
*/
static uint64_t addTemp;
#define SHA384_512AddLength(context, length) \
(addTemp = context->Length_Low, context->Corrupted = \
((context->Length_Low += length) < addTemp) && \
(++context->Length_High == 0) ? 1 : 0)
It should say:
/*
* add "length" to the length
*/
static uint64_t addTemp;
#define SHA384_512AddLength(context, length) \
(addTemp = (context)->Length_Low, (context)->Corrupted = \
(((context)->Length_Low += length) < addTemp) && \
(++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )
Rationale:
Same as for item (7) and (14) above, cf. item (26) as well.
Additionally, parentheses have been added around all invocations of
the macro argument `context` to protect it against various artifacts,
as has been done consistently in the remainder of the sample code.
Errata ID: 2438
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
Similar to item (9), (16), (17), and (22) above, the Description of SHA384Result contains improper wording and unpleasent formatting. Additionally, counting 48 elements as ranging from the "0th" up to the "48th" is unpleasant and wrong -- indicating 49 elements (octets) ! Near the bottom of page 53, the RFC says: * Description: * This function will return the 384-bit message * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 48th element. For correctness and consistency, and for improved readability, it should say: * Description: * This function will return the 384-bit message digest * into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 47.
Errata ID: 2445
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.3 says:
On mid-page 75, the comment within the function hmacReset says: * The HMAC transform looks like: * * SHA(K XOR opad, SHA(K XOR ipad, text)) * * where K is an n byte key. * ipad is the byte 0x36 repeated blocksize times * opad is the byte 0x5c repeated blocksize times * and text is the data being protected. It should say: * The HMAC transform looks like: * * SHA(K XOR opad, SHA(K XOR ipad, text)) * | * where K is an n byte key, 0-padded to a total of blocksize bytes, | * ipad is the byte 0x36 repeated blocksize times, | * opad is the byte 0x5c repeated blocksize times, * and text is the data being protected. Rationale: Without the addition, the 'XOR' operations in the formula are undefined. Additionally, punctuation is made uniform.
Errata ID: 2447
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.4 says:
The initial Description of the file, as presented on page 78, contains in its first paragraph the lines: * the seven tests documented for each algorithm in * "The Secure Hash Algorithm Validation System (SHAVS)", * three of which are bit-level tests * (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf) For clarity, it should better say: * the seven tests documented for each algorithm in |* "The Secure Hash Algorithm Validation System (SHAVS)" |* (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf), |* three of which are bit-level tests
Errata ID: 2449
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.4 says:
On mid-page 91, there is the comment: /* * Print the string, converting non-printable characters to hex "## ". */ It should say: /* * Print the string, converting all characters to hex "## ". */ Rationale: There is a significant mismatch between the comment and the subsequent code. This is being resolved by the replacement text.
Errata ID: 748
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
Similar to item (9), (16), (17), (22), and (29) above, the Description of SHA512Result contains improper wording and unpleasent formatting. Additionally, counting 64 elements as ranging from the "0th" up to the "64th" is unpleasant and wrong -- indicating 65 elements (octets) ! Near the bottom of page 44, the RFC says: * Description: * This function will return the 512-bit message * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 64th element. For correctness and consistency, and for improved readability, it should say: * Description: * This function will return the 512-bit message digest * into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 63.
Errata ID: 2439
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The Description of SHA384_512PadMessage, on page 58, says: * Description: * According to the standard, the message must be padded to an * even 1024 bits. The first padding bit must be a '1'. The * last 128 bits represent the length of the original message. * All bits in between should be 0. This helper function will * pad the message according to those rules by filling the * Message_Block array accordingly. When it returns, it can be * assumed that the message digest has been computed. For clarity, it should say (cf. items (10) and (19) above): * Description: |* According to the standard, the message must be padded to the next |* proper multiple of 1024 bits. The first padding bit must be a '1'. * The last 128 bits represent the length of the original message. * All bits in between should be 0. This helper function will * pad the message according to those rules by filling the * Message_Block array accordingly. When it returns, it can be * assumed that the message digest has been computed.
Errata ID: 2443
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.3 says:
The code for (the message oriented) function hmac,
on page 73/74, reads:
int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
const unsigned char *key, int key_len,
uint8_t digest[USHAMaxHashSize])
<< page break >>
{
HMACContext ctx;
return hmacReset(&ctx, whichSha, key, key_len) ||
hmacInput(&ctx, text, text_len) ||
hmacResult(&ctx, digest);
}
It should say:
int hmac(SHAversion whichSha,
const unsigned char *message_array, int length,
const unsigned char *key, int key_len,
uint8_t digest[USHAMaxHashSize])
<< page break >>
{
HMACContext ctx;
return hmacReset(&ctx, whichSha, key, key_len) ||
hmacInput(&ctx, message_array, length) ||
hmacResult(&ctx, digest);
}
Rationale:
The argument names `message_array` and `length` are used
throughout the sample code, including the Description of the
function hmac, on page 73.
The code shown above was not aligned with this practise and
hence inconsistent with the Description.
This has been resolved by the proposed update, bay changing
the names of 'text' and 'text_len'.
>>>>> NOTE / Caution :
>>>>>
>>>>> Similar (and additional) inconsistencies between the
>>>>> argument names in the 'Parameters:' documentation
>>>>> and the variable names used in the subsequent code
>>>>> exist for all hmac* functions, on pages 74..77 ;
>>>>> in particular, the described 'context' is always
>>>>> named `ctx` in the code.
>>>>> Also, capitalization of the leading "HMAC"/"hmac"
>>>>> in the function names is totally inconsistent.
>>>>>
>>>>> Resolution of these issues is left as an exercise
>>>>> to the reader of this note -- or the author of any
>>>>> future update of the sample code.
>>>>>
>>>>> Furthermore, the use of "characters" as units of the
>>>>> message_text in the descriptions is dangerous in the
>>>>> days of Unicode and UTF-8; "characters" should better
>>>>> be replaced by "octets" throughout hmac.c !
Errata ID: 750
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.4 says:
on mid-page 96, the code section,
if (bitcount > 0)
err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
USHAFinalBits(&sha, bits, bitcount);
if (err != shaSuccess) {
fprintf(stderr, "hashfile(): %s Error %d.\n",
keyarray ? "hmacResult" : "shaResult", err);
if (hashfp != stdin) fclose(hashfp);
return err;
}
should in fact say:
if (bitcount > 0)
err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
USHAFinalBits(&sha, bits, bitcount);
if (err != shaSuccess) {
fprintf(stderr, "hashfile(): %s Error %d.\n",
keyarray ? "hmacFinalBits" : "shaFinalBits", err);
if (hashfp != stdin) fclose(hashfp);
return err;
}
Rationale:
Self-evident; perhaps cloning error.
Errata ID: 2412
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 3 says:
Section 3 of RFC 4634, on page 5, defines the elementary word operations to be used subsequently in the text, including the left shift operation, '<<'. Unfortunately, the right shift operation '>>' is used frequently as well, but not defined in Section 3. I propose to amend the second paragraph of Section 3, on page 5, In the operations below, x<<n is obtained as follows: discard the left-most n bits of x and then pad the result with n zeroed bits on the right (the result will still be the same number of bits).
It should say:
to read: In the operations below, x<<n is obtained as follows: discard the left-most n bits of x and then pad the result with n zeroed bits on the right (the result will still be the same number of bits). | Similarly, x>>n is obtained as follows: discard the right-most n bits | of x and then prepend the result with n zeroed bits on the left (the | result will still be the same number of bits).
Errata ID: 2428
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the definition of SHA256Result does not supply
the expected size of the formal argument 'Message_Digest'.
At the bottom of page 39, RFC 4634 says:
int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
{
For consistency and clarity, it should say:
int SHA256Result(SHA256Context *context,
uint8_t Message_Digest[SHA256HashSize])
{
Errata ID: 2431
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
Similar to item (9), (16), and (17) above, the Description of SHA224_256ResultN contains improper wording. Additionally, counting 28/32 elements as ranging from the "0th" up to the "28th/32nd" is unpleasant and wrong -- that erroneously indicates 29/33 elements (octets) ! Near the bottom of page 44, the RFC says: * Description: * This helper function will return the 224-bit or 256-bit message * digest into the Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 28th/32nd element. For correctness and consistency, it should say: * Description: * This helper function will return the 224-bit or 256-bit message * digest into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 27/31.
Errata ID: 2433
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The comment text, near the top of page 46, says: * Caveats: * SHA-384 and SHA-512 are designed to work with messages less * than 2^128 bits long. This implementation uses * SHA384/512Input() to hash the bits that are a multiple of the * size of an 8-bit character, and then uses SHA384/256FinalBits() * to hash the final few bits of the input. It should better say -- cf. item (6) and (13) above: * Caveats: * SHA-384 and SHA-512 are designed to work with messages less * than 2^128 bits long. This implementation uses SHA384/512Input() * to hash the bits that are a multiple of the size of an 8-bit |* character, and optionally then uses SHA384/256FinalBits() * to hash the final few bits of the input.
Errata ID: 2442
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The Description for USHAResult, on top of page 69, says: * Description: * This function will return the 160-bit message digest into the * Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 19th element. It should say: * Description: * This function will return the message digest of the appropriate * bit size, as returned by USHAHashSizeBits(whichSHA) for the * 'whichSHA' value used in the preceeding call to USHAReset, * into the Message_Digest array provided by the caller. Rationale: The given text roughly matches the SHA-1 case, it is wrong for all other cases. The arguments presented for items (9), (16), (17), (22), (29), (30), and (33) above apply as well. The changed text tries to remain precise while avoiding too much repetition of facts presented elsewhere in the sample code.
Errata ID: 2444
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.3 says:
The Description of hmacResult, on top of page 77, says: * Description: * This function will return the N-byte message digest into the * Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the Nth element. It should perhaps just say: * Description: * This function will return the N-byte message digest into the * Message_Digest array provided by the caller. Rationale: Cf. items (9), (16), (17), (22), (29), (30), and (33) above. Full replacement text for the last two lines is deemed unnecessary.
Errata ID: 2446
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.3 says:
The Description of hmacResult, on top of page 77, says: * Description: * This function will return the N-byte message digest into the * Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the Nth element. It should perhaps just say: * Description: * This function will return the N-byte message digest into the * Message_Digest array provided by the caller. Rationale: Cf. items (9), (16), (17), (22), (29), (30), and (33) above. Full replacement text for the last two lines is deemed unnecessary.
Errata ID: 2418
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
Near the top of page 25, there is the code:
/*
* add "length" to the length
*/
static uint32_t addTemp;
#define SHA1AddLength(context, length) \
(addTemp = (context)->Length_Low, \
(context)->Corrupted = \
(((context)->Length_Low += (length)) < addTemp) && \
(++(context)->Length_High == 0) ? 1 : 0)
It should say:
It should say (modifying the last line):
/*
* add "length" to the length
*/
static uint32_t addTemp;
#define SHA1AddLength(context, length) \
(addTemp = (context)->Length_Low, \
(context)->Corrupted = \
(((context)->Length_Low += (length)) < addTemp) && \
(++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )
Notes:
As can be found on page 19 (upper half), sha.h contains:
#ifndef _SHA_enum_
#define _SHA_enum_
/*
* All SHA functions return one of these values.
*/
enum {
shaSuccess = 0,
shaNull, /* Null pointer parameter */
shaInputTooLong, /* input data too long */
shaStateError, /* called Input after FinalBits or Result */
shaBadParam /* passed a bad parameter */
};
#endif /* _SHA_enum_ */
This leaves it to the compiler to assign values, but ordinarily,
shaNull will be assigned the value 1,
shaInputTooLong will be assigned the value 2, etc. ...
The value assigned to context->Corrupted in the #define listed
above will later on repeatedly be used to generate return values,
via code lines:
return context->Corrupted;
These return values are expected to be SHA_enum values.
In the case where Corrupted gets assigned the value 0, it apparently
was intended to eventually get the return value 'shaSuccess', and
in the case where Corrupted gets assigned the value 1, it apparently
was intended to eventually get the return value 'shaInputTooLong'.
With the code shown above, the former will work, but the latter
will usually *not* work as intended.
To obtain portable source code behaving as documented, the proposed
change has to be applied.
Errata ID: 2417
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
The comment text, at the bottom of page 24, says: * Caveats: * SHA-1 is designed to work with messages less than 2^64 bits * long. This implementation uses SHA1Input() to hash the bits * that are a multiple of the size of an 8-bit character, and then * uses SHA1FinalBits() to hash the final few bits of the input. */
It should say:
It should better say: * Caveats: * SHA-1 is designed to work with messages less than 2^64 bits * long. This implementation uses SHA1Input() to hash the bits * that are a multiple of the size of an 8-bit character, and then |* optionally uses SHA1FinalBits() to hash the final few bits of * the input. */
Errata ID: 2414
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8 says:
In the introductory text in Section 8, function prototype arguments
are inconsistently presented; all should be presented in ANSI-C style
consistently.
Also, the indentation of two lines breaks the otherwise consistent
layout.
On mid-page 16, the lines,
Functions:
| int SHA$$$Reset(SHA$$$Context *);
Reset the hash context state
| int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
unsigned int bytecount);
Incorporate bytecount octets into the hash.
should read:
Functions:
| int SHA$$$Reset(SHA$$$Context *context);
Reset the hash context state
| int SHA$$$Input(SHA$$$Context *context, const uint8_t *octets,
unsigned int bytecount);
Incorporate bytecount octets into the hash.
and on page 17, the lines,
Functions:
| int USHAReset(USHAContext *, SHAversion whichSha);
Reset the hash context state.
| int USHAInput(USHAContext *,
const uint8_t *bytes, unsigned int bytecount);
Incorporate bytecount octets into the hash.
| int USHAFinalBits(USHAContext *,
const uint8_t bits, unsigned int bitcount);
| Incorporate bitcount bits into the hash.
should read:
Functions:
| int USHAReset(USHAContext *context, SHAversion whichSha);
Reset the hash context state.
| int USHAInput(USHAContext *context,
const uint8_t *bytes, unsigned int bytecount);
Incorporate bytecount octets into the hash.
| int USHAFinalBits(USHAContext *context,
const uint8_t bits, unsigned int bitcount);
| Incorporate bitcount bits into the hash.
Notes:
inconsistent prototypes, unpleasant/inconsistent indentation
Errata ID: 2416
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
The initial Description in the file, on page 24 of the RFC, says:
vvvvvvvvvvvvvvvvvv
* Description:
* This file implements the Secure Hash Signature Standard
* algorithms as defined in the National Institute of Standards
* and Technology Federal Information Processing Standards
* Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
* published on August 1, 2002, and the FIPS PUB 180-2 Change
* Notice published on February 28, 2004.
It should say:
It should say: * Description: |* This file implements the Secure Hash Algorithm SHA-1 * as defined in the National Institute of Standards * and Technology Federal Information Processing Standards * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 * published on August 1, 2002, and the FIPS PUB 180-2 Change * Notice published on February 28, 2004.
Notes:
See Errata 2415.
Also replace "algorithms" by "Algorithm SHA-1" to properly match
the description with the scope of the file.
Errata ID: 2440
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The sample code presents almost all formal function arguments of type
array with predefined (constant) length with this explicit length.
Contrary to that, the function definitions for SHA384_512Reset do not
supply the expected size of the formal argument 'H0'.
This inconsistency should be corrected -- as in items (18) and (28)
above.
Near the top of page 65, RFC 4634 says:
#ifdef USE_32BIT_ONLY
static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
#else /* !USE_32BIT_ONLY */
static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
#endif /* USE_32BIT_ONLY */
For consistency and clarity, it should say:
#ifdef USE_32BIT_ONLY
static int SHA384_512Reset(SHA512Context *context,
uint32_t H0[SHA512HashSize/4]);
#else /* !USE_32BIT_ONLY */
static int SHA384_512Reset(SHA512Context *context,
uint64_t H0[SHA512HashSize/8]);
#endif /* USE_32BIT_ONLY */
Errata ID: 2419
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
Througout the sample source code, ANSI-C style is used for the function prototypes, i.e. giving type and name for function arguments. This rule is broken on mid-page 25, just below the offending snippit from item (5) above. For consistency and portability, the source code fragment: /* Local Function Prototypes */ static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte); static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte); static void SHA1ProcessMessageBlock(SHA1Context *); should better say, amending the last two lines: /* Local Function Prototypes */ static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte); static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte); static void SHA1ProcessMessageBlock(SHA1Context *context);
Errata ID: 2420
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.1 says:
The Description comments for the SHA$$$Result functions repeatedly contains improper wording and unpleasent formatting. See below for significant flaws. This change is proposed for the sake of consistency. The Description of SHA1Result on page 28, says: * Description: * This function will return the 160-bit message digest into the * Message_Digest array provided by the caller. * NOTE: The first octet of hash is stored in the 0th element, * the last octet of hash in the 19th element. For correctness and consistency, it should better say: * Description: * This function will return the 160-bit message digest * into the Message_Digest array provided by the caller. * NOTE: * The first octet of the hash is stored in the element with index 0, * the last octet of the hash in the element with index 19. [The additional line break has been added to keep the first part of the last sentence on a single line, under RFC formatting rules.]
Errata ID: 2448
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.4 says:
On mid-page 82, the RFC text defines the constant: #define PRINTBASE64 4 which is never used in the subsequent test driver code (Base64 output is not supported). Hence, this line should be deleted.
Errata ID: 2425
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.2 says:
On top of page 35, the Description of SHA224Reset says:
vvv
* Description:
* This function will initialize the SHA384Context in preparation
* for computing a new SHA224 message digest.
It should say:
* Description:
|* This function will initialize the SHA224Context in preparation
* for computing a new SHA224 message digest.
Errata ID: 2434
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06
Section 8.2.3 says:
The first line on page 50 says: #else /* !USE_32BIT_ONLY */ It should say: #else /* !USE_MODIFIED_MACROS */ Rationale: Look at the #if[n]def structure of the file.
Errata ID: 1301
Status: Held for Document Update
Type: Technical
Reported By: Jan Andres
Date Reported: 2008-01-21
Held for Document Update by: Sean Turner
Section 6.2 says:
1. Prepare the message schedule W:
For t = 0 to 15
Wt = M(i)t
For t = 16 to 63
Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
It should say:
1. Prepare the message schedule W:
For t = 0 to 15
Wt = M(i)t
For t = 16 to 63
Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)
Notes:
Cf. FIPS180-2, section 6.2.2.
(http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf)
Errata ID: 1302
Status: Held for Document Update
Type: Technical
Reported By: Jan Andres
Date Reported: 2008-01-21
Held for Document Update by: Sean Turner
Section 6.4 says:
1. Prepare the message schedule W:
For t = 0 to 15
Wt = M(i)t
For t = 16 to 79
Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
It should say:
1. Prepare the message schedule W:
For t = 0 to 15
Wt = M(i)t
For t = 16 to 79
Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(W(t-15)) + W(t-16)
Notes:
Cf. FIPS180-2, section 6.3.2.
(http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf)
Errata ID: 2332
Status: Reported
Type: Technical
Reported By: Donald Eastlake 3rd
Date Reported: 2010-07-19
Section top 1st page says:
Network Working Group D. Eastlake 3rd Request for Comments: 4635 Motorola Laboratories Category: Standards Track August 2006
It should say:
Network Working Group D. Eastlake 3rd Request for Comments: 4635 Motorola Laboratories Updates 2845 Category: Standards Track August 2006
Notes:
This RFC, which I authored, clearly updates the Original RFC 2845 for TSIG: It makes it MANDATORY to implement HMAC-SHA1 and HMAC-SHA256 if you claim to support TSIG. It defines a new TSIG error code, BADTRUC, and specifies when it is to be returned. This are *significant* *normative* updates to RFC 2845. The RFC index for 2845 and 4635 should be updated to show this.
Errata ID: 822
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Section 4 of RFC 4636, on page 3, clearly states: This document updates the Mobile IP base specification [4] regarding the procedures followed by the foreign agent in the case that the home agent fails authentication. [...] ... and [4] is RFC 3344. Furthermore, RFC 4636 is on the Standards Track as well. Therefore, I would have expected to find an Updates: 3344 line in the RFC heading, and appropriate links in the RFC index. Has this been omitted by accident, or have there been strong arguments to omit this significant link ? In the former case, can that be corrected 'after the fact' ?
Notes:
from pending
Errata ID: 824
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Section 8 says:
The extension in this document improves the security features of Mobile IPv4 by allowing the mobile node to be assured of the authenticity of the information supplied within a Registration Request.
It should say:
The extension in this document improves the security features of Mobile IPv4 by allowing the mobile node to be assured of the authenticity of the information supplied within a Registration Reply.
Notes:
From the body of the RFC, I would have expected to find "Reply"
as the last word of that sentence -- cf. Section 1, 2nd sentence,
and Section 4, 1st sentence.
from pending
Errata ID: 811
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
(1) typo/grammar
On page 3 of RFC 4640, the seconf paragraph of Section 1.2 says:
Typically, bootstrapping happens when a mobile node does not have all
the information it needs to set up the Mobile IPv6 service. This
includes, but is not limited to, situations in which the mobile node
does not having any information when it boots up for the first time
(out of the box), or does not retain any information during reboots.
It should say:
Typically, bootstrapping happens when a mobile node does not have all
the information it needs to set up the Mobile IPv6 service. This
includes, but is not limited to, situations in which the mobile node
| does not have any information when it boots up for the first time
(out of the box), or does not retain any information during reboots.
(2) missing line break
Near the end of Section 1.3, on page 5, there should be an additional
blank line above the term "Home Mobility Service Provider".
(3) typo
On page 6, the last sub-bullet of the first bulleted list in Section 3
says:
* IPsec Security Association (SA) between MN and HA, Intenet Key
Exchange Protocol (IKE) pre-shared secret between MN and HA
It should say:
v
| * IPsec Security Association (SA) between MN and HA, Internet Key
Exchange Protocol (IKE) pre-shared secret between MN and HA
(4) grammar (singluar/plural mismatch)
The first sentence of Section 5.1.3, on page 9, says:
vv
| The home agent discovery protocol does not support an "opportunistic"
| or local discovery mechanisms in an ASP's local access network. [..]
^
It either should say:
The home agent discovery protocol does not support an "opportunistic"
| or local discovery mechanism in an ASP's local access network. [..]
or it should say:
| The home agent discovery protocol does not support "opportunistic" or
local discovery mechanisms in an ASP's local access network. [..]
Please decide what was intended.
(5) missing articles
The last paragraph of Section 5.3.1, on page 11, says:
Bootstrapping does not explicitly try to solve this problem of home
network renumbering when MN is in dormant mode. If the MN can
configure itself after it 'comes back on' by reinitiating the
bootstrapping process, then network renumbering problem is fixed as a
side effect.
It should better say:
Bootstrapping does not explicitly try to solve this problem of home
| network renumbering when the MN is in dormant mode. If the MN can
configure itself after it 'comes back on' by reinitiating the
| bootstrapping process, then the network renumbering problem is fixed
as a side effect.
(6) missing article
The second paragraph of Section 7, on page 13, says:
For each scenario, the underlying assumptions are described. The
basic assumption is that there is a trust relationship between mobile
user and the MSA. Typically, [...]
It should better say:
For each scenario, the underlying assumptions are described. The
| basic assumption is that there is a trust relationship between the
mobile user and the MSA. Typically, [...]
(7) missing article
The second paragraph of Section 7.2, on page 14, says:
Figure 1 describes an AAA design example for integrated ASP scenario.
It should better say:
Figure 1 describes an AAA design example for the integrated ASP
scenario.
(8) flawed artwork
Figure 2, on page 15,
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA |
| \ | | \ || (e.g., corporate NW)|
| \ +------+ | | \ | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
should perhaps be corrected/improved to:
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA (e.g., |
| \ | | \ | | corporate NW)|
| \ +------+ | | \ | | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
[ Note: I intentionally have refrained from horizontally extending
the box on the rigth side of the figure, which would have been
possible while still conforming to RFC formatting rules. ]
(9) word omissions
Within the large first paragraph of Section 9.1, at the bottom of
page 17, there are two word omissions:
In the 2nd line of the paragraph, replace
... between the home agent and mobile node
by:
... between the home agent and the mobile node
and in the 5th line from the bottom of the page, insert "be", changing
[...]. The best way to minimize the
probability of such a compromise is to have the cryptographic
material only known or calculable by the two end nodes that share the
SA -- in this case, the home agent and mobile node. [...]
to:
[...]. The best way to minimize the
probability of such a compromise is to have the cryptographic
| material only be known or calculable by the two end nodes that share
the SA -- in this case, the home agent and mobile node. [...]
(10) [[posted separately.]]
Notes:
from pending
Errata ID: 36
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Section 12 says:
[RFC3776] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
It should say:
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
Notes:
In Section 12, near the bottom of page 20, a strange accident must
have hit the Ref. tagged [RFC3776]. This indeed should be a citation of the Mobile IP related RFC 3776, but it is a citiation of the unrelated RFC 3777.
from pending
Errata ID: 35
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01
Section 4.2.1.1 says:
Pre-publish key rollover involves four stages as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
It should say:
Pre-publish key rollover involves four stages as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
| DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover
Notes:
The mis-alignment of the indicated line breaks the intended
presentation of the procedure; cf. subsequent RFC text.
from pending
Errata ID: 790
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01
Section 4.2.1.2 says:
Double signature ZSK rollover involves three stages as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
It should say:
Double signature ZSK rollover involves three stages as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
| RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
| DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
| RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
Notes:
The mis-alignment of the indicated 3 lines breaks the
intended presentation of the procedure; cf. subsequent RFC text.
The initial report was corrected by Yue Luo 2007-11-16 so that "RRSIG11" in the last row is in "New DNSKEY" stage instead of "initial" stage.
Errata ID: 791
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Section 3.5 says:
As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger then the others.
It should say:
As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger than the others.
Notes:
then -> than
from pending
Errata ID: 792
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Section 4.2.1.2 says:
Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in initial version of the zone is recommended.
It should say:
Making sure that the "new DNSKEY" phase lasts until the signature | expiration time of the data in the initial version of the zone is recommended.
Notes:
missing article
from pending
Errata ID: 814
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Ron Bonica
Section 7.1 says:
[3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
Flag", RFC 3757, May 2004.
It should say:
[should be omitted.]
Notes:
RFC 3757 has been formally obsoleted by (and incorporated into)
the new DNSSEC RFCs, RFC 4033..4035.
Therefore, RFC 3757 should not appear as a Normative Reference
in new RFCs any more.
The two instances where [3] is cited in the text,
- page 6, Section 3.1, first paragraph, and
- page 24, Section 4.1.1, second paragraph
should have been changed to refer to [5], RFC 4034, instead.
from pending
Errata ID: 2391
Status: Held for Document Update
Type: Editorial
Reported By: Tony Finch
Date Reported: 2010-07-23
Held for Document Update by: Ron Bonica
Section Appendix C says:
Notes:
There are some NSEC-related errors in the example zone. The NSEC record is missing from the zone apex (though its RRSIG is present). The TTL on the NSEC and RRSIG NSEC records for a.example.net should be the same as the zone's SOA minimum TTL, i.e. 28800 not 86400.
Errata ID: 1520
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2008-09-23
Held for Document Update by: Lisa Dusseault
Section 1 says:
TLS is complimentary to both simple authentication-only SASL mechanisms and deployed clear-text password login commands.
It should say:
TLS is complementary to both simple authentication-only SASL mechanisms and deployed clear-text password login commands.
Errata ID: 1787
Status: Verified
Type: Technical
Reported By: Antti-Juhani Kaijanaho
Date Reported: 2009-05-24
Verifier Name: Lisa Dusseault
Date Verified: 2009-11-25
Section 3.1 says:
user-pass-char = B-CHAR NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO PASS specially so as to allow white space to be used within the username or password. Such implementations accept the additional syntax (making these two items inconsistent with "token" in Section 9.8 of [NNTP]): user-pass-char =/ SP / TAB
It should say:
user-pass-char = CTRL / %x21-FF NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO PASS specially so as to allow white space to be used within the username or password. Such implementations accept the additional syntax (making these two items inconsistent with "token" in Section 9.8 of [NNTP]): user-pass-char =/ SP / TAB
Notes:
RFC 3977 defines B-CHAR in section 9.8 as:
B-CHAR = CTRL / TAB / SP / %x21-FF
It already contains TAB (%x09) and SP (%x20). Therefore, we have
to define user-pass-char as any byte character except NUL, TAB, LF, CR
and SP. Otherwise, the note does not make sense.
--- RFC Editor Note ---
This report was updated 2009-12-07 per a request from Julien Élie.
Errata ID: 1995
Status: Held for Document Update
Type: Editorial
Reported By: Julien Élie
Date Reported: 2010-01-10
Held for Document Update by: Alexey Melnikov
Date Held: 2010-01-11
Section 1.1 says:
This document assumes you familiarity with NNTP [NNTP].
It should say:
This document assumes familiarity with NNTP [NNTP].
Notes:
A simple typo.
Also note that earlier drafts on which this RFC is based used "This document assumes you are familiar with NNTP [NNTP]."
Note: This RFC has been obsoleted by RFC5646
Source of RFC: ltru (app)
Errata ID: 34
Status: Verified
Type: Editorial
Reported By:
Date Reported: 2006-09-29
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19
Appendix B says:
sl-rozaj (Resian dialect of Slovenian
It should say:
sl-rozaj (Resian dialect of Slovenian)
Notes:
Missing ")"
Errata ID: 1061
Status: Verified
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-11-09
Verifier Name: Alexey Melnikov
Date Verified: 2009-06-19
Section 3.1 says:
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR = "&#x" 2*6HEXDIG ";"
It should say:
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR = %x26.23.78 2*6HEXDIG ";" ; starts with "&#x"
Notes:
It has to be a lower case "x", i.e. %x78 in RFC 5234 ABNF.
(All quoted strings in ABNF are case-insensitive.)
Errata ID: 2837
Status: Verified
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2011-06-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-16
Section 16.2 says:
http://zgp.org/pipermail/p2p-hackers/2001-September/000315.html
It should say:
http://zgp.org/pipermail/p2p-hackers/2001-September/000316.html
Notes:
The same "off by one" issue was already present in RFC 3548 (obsoleted by RFC 4648). The archived article 315 has another author. Articles 316 and 319 are from the author noted in the RFCs, belong to a discussion of "web-safe base64" formats (incl. hex. + base32 alternatives), and specify the relevant base64 modification:
316 is shorter than 319, and nearer to the erroneous 315, so that was likely the intended article.
Errata ID: 2387
Status: Verified
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20
(15) typo -- results in wrong Endpoint identifier specified The 3rd paragraph of Appendix A, on page 25, says: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. [...]
It should say:
It should say: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint A; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. [...]
Notes:
from pending
Errata ID: 2377
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(6) missing comma, causing possible mis-interpretation
The last sentence of Section 3, at the bottom of page 9, says:
[...]. The HMAC SHALL be
computed over the entire message, excluding the MAC field using
auth_key; see also section 4.2.
It should say:
It should say:
[...]. The HMAC SHALL be
| computed over the entire message, excluding the MAC field, using
auth_key; see also section 4.2.
or perhaps even better and clearer:
[...]. The HMAC SHALL be
| computed (using auth_key) over the entire message excluding the MAC
| field; see also section 4.2.
Notes:
from pending
Errata ID: 2379
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
missing comma, causing possible mis-interpretation
The last sentence of the second paragraph of Section 4.2,
on page 12, says:
[...]. The HMAC is then calculated over the entire MIKEY
message, excluding the MAC field using auth_key as described in [2]
section 5.2, and then stored within the MAC field.
It should say:
It should say:
[...]. The HMAC is then calculated over the entire MIKEY
| message, excluding the MAC field, using auth_key as described in [2]
section 5.2, and then stored within the MAC field.
or perhaps even better and clearer:
| [...]. The HMAC is then calculated using auth_key, over the
| entire MIKEY message, excluding the MAC field, as described in [2]
section 5.2, and then stored within the MAC field.
Notes:
from pending
Errata ID: 33
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(1) word omission In Section 1, the first text line on page 2 says: There is work done in IETF to develop key management schemes. [..]
It should say:
It should say: | There is work done in the IETF to develop key management schemes. [..]
Notes:
from pending
Errata ID: 2373
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
In Section 1, the last indented paragraph on page 4 says:
However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide full
perfect forward secrecy (PFS) and further have to both parties
actively involved in session key generation. This special
security property (despite the somewhat higher computational
costs) makes Diffie-Hellman techniques attractive in practice.
It should say:
It should say:
However, the Diffie-Hellman key agreement protocol is known for
its subtle security strengths in that it is able to provide full
| perfect forward secrecy (PFS) and further have both parties
actively involved in session key generation. This special
security property (despite the somewhat higher computational
costs) makes Diffie-Hellman techniques attractive in practice.
Errata ID: 2374
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
typo (line folding problem?) The second paragraph of Section 2, on page 7, says: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment.
It should say:
It should say: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, | pre-shared master secrets are assumed to be available among the entities in such an environment.
Notes:
from pending
Errata ID: 2375
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
In Section 2.1, the last paragraph on page 7 says:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
offer/answer see RFC 3264 [27]) handshake, as described in [4];
It should say:
It should say:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
| offer/answer (see RFC 3264 [27]) handshake, as described in [4];
or perhaps even better:
a) SIP [13] and SDP, where the encoded MIKEY messages are
encapsulated and transported in SDP containers of the SDP
| offer/answer handshake (see RFC 3264 [27]), as described in [4];
Notes:
from pending
Errata ID: 2376
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Sean Turner
Date Held: 2010-07-30
Section 3 says:
Figure 1 in Section 3, on page 8, says:
Initiator Responder
I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
<----------------------
It should say:
To avoid optional empty protocol elements,
it should perhaps better say:
Initiator Responder
| I_message = HDR, T, RAND, [IDi,] IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
| [IDr,] IDi, DHr,
DHi, KEMAC
<----------------------
Similar corrections would be suitable in Section 3.1 for Figure 2,
on page 10.
Notes:
error in message syntax notation:
Errata ID: 2378
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Extraneous (duplicate) word error: In Section 4.1, the last sentence on page 11, says: Other defined next payload values defined in [2] SHALL not be applied to DHHMAC.
It should say:
It should say: | Other next payload values defined in [2] SHALL not be applied to DHHMAC.
Notes:
from pending
Errata ID: 2380
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
missing article:
The last paragraph on page 13, i.e. the 2nd bullet in Section 5.2, says:
* Eavesdropping of other, transmitted keying information: DHHMAC
protocol does not explicitly transmit the TGK at all. [...]
It should say:
It should say:
| * Eavesdropping of other, transmitted keying information: The DHHMAC
protocol does not explicitly transmit the TGK at all. [...]
Notes:
from pending
Errata ID: 2381
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
[missing "/"]
The 3rd paragraph on page 14, i.e. the 4th bullet in Section 5.2, says:
* Man-in-the-middle attacks: Such attacks threaten the security of
exchanged, non-authenticated messages. Man-in-the-middle attacks
usually come with masquerade and or loss of message integrity (see
below). [...]
It should say:
It should say:
* Man-in-the-middle attacks: Such attacks threaten the security of
exchanged, non-authenticated messages. Man-in-the-middle attacks
| usually come with masquerade and/or loss of message integrity (see
below). [...]
Notes:
from pending
Errata ID: 2382
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(11) missing comma (potential for mis-interpretation)
The second paragraph on page 15 (within Section 5.2) says:
* Identity protection: Like MIKEY, identity protection is not a major
design requirement for MIKEY-DHHMAC, either; see [2]. No security
protocol is known so far that is able to provide the objectives of
DHHMAC as stated in section 5.3, including identity protection
within just a single roundtrip. [...]
It should say:
It should say:
* Identity protection: Like MIKEY, identity protection is not a major
design requirement for MIKEY-DHHMAC, either; see [2]. No security
protocol is known so far that is able to provide the objectives of
| DHHMAC as stated in section 5.3, including identity protection,
within just a single roundtrip. [...]
Notes:
from pending
Errata ID: 2383
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(12) extraneous word
The 3rd paragraph on page 18 (within Section 5.3) says:
If a very high security level is desired for long-term secrecy of
the negotiated Diffie-Hellman shared secret, longer hash values may
be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in
| conjunction with stronger Diffie-Hellman groups. This is left as
for further study.
It should say:
It should say:
| [...]. This is left for
further study.
Notes:
from pending
Errata ID: 2384
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(13) extraneous words (left over from changing the sentence?)
The last lines on page 18 (within Section 5.3) say:
Public-key infrastructures may not always be available in certain
environments, nor may they be deemed adequate for real-time
multimedia applications when additional steps are taken for
certificate validation and certificate revocation methods with
additional roundtrips into account.
It should say:
The RFC should say:
Public-key infrastructures may not always be available in certain
environments, nor may they be deemed adequate for real-time
multimedia applications when additional steps are taken for
certificate validation or certificate revocation methods require
additional roundtrips.
Notes:
Minor edits to corrected text by Tim Polk.
Errata ID: 2386
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
(14) outdated Informative Reference This RFC references the now-outdated RFC 1750. All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750!
It should say:
Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650, should be replaced by the proper RFC-style citation for RFC 4086.
Notes:
from pending
Errata ID: 1653
Status: Held for Document Update
Type: Editorial
Reported By: Arnd Hannemann
Date Reported: 2009-01-15
Held for Document Update by: Lars Eggert
Section 0 says:
8. Acknowledgments ................................................14
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
It should say:
8. Acknowledgments ................................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Notes:
Typo in table of contents
Errata ID: 32
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Verifier Name: Cullen Jennings
Date Verified: 2008-11-16
Section 11.1 says:
[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4663, September 2006.
It should say:
[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
Errata ID: 921
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks
(1) [[posted separately.]]
(2) general issue: presentation/formatting of XML text
Although it carries no functional relevance, uniform formatting
and consistent indentation of XML text significantly adds to
the readability and furthers the understanding of the structure.
Unfortunately, there are many places in the two RFCs where --
perhaps as a result of the use of various tools in the publication
process -- non-uniform and inconsistent indentation in XML text
impedes the readability of the XML schemata and the XML examples.
At a minimum, pairing opening and closing XML tags, if on different
lines, should be indented by the same amount of white space,
and XML elements on the same hierarchical level (within another
XML element) should be indented equally.
For brevity of this message, I omit detailing the numerous places
affected I have marked in my printed copies of the two RFCs.
(3) repeated word replications and grammar (RFC 4660)
The second paragraph of Section 3.3.1 of RFC 4660, at the bottom
of page 3, says:
A SUBSCRIBE request destined to a list URI [4] MAY include multiple
filters specific to individual resources. This is achieved by
including multiple <filter> elements with different URIs of resources
| in each of those elements. This resource specific resource-specific
| filter are processed first before any list specific list-specific
| filter, if any. The list specific list-specific filter may or may
not include a URI.
It should perhaps say:
A SUBSCRIBE request destined to a list URI [4] MAY include multiple
filters specific to individual resources. This is achieved by
including multiple <filter> elements with different URIs of resources
| in each of those elements. This resource-specific filter is
| processed first, before any list-specific filter, if any. The
| list-specific filter may or may not include a URI.
(4) distorting extra blank line (RFC4660)
The example scenario description in Section 4.1 of RFC 4660,
on top of page 8, are made less comprehensible by the additional
blank line in between:
List1 (list1@example.com) on RLS1 has: bob@example.com
list2@biloxi.com
Should perhaps better say:
List1 (list1@example.com) on RLS1 has: bob@example.com
list2@biloxi.com
or even better:
List1 (list1@example.com) on RLS1 has:
bob@example.com list2@biloxi.com
(5) inappropriate Section headlines (RFC4660)
The ToC and the body of RFC 4660 (on page 9) contains the Section
headlines:
5. Server Operation
5.1. NOTIFY Bodies
should better say:
5. Notifier Operation
5.1 SUBSCRIBE Bodies
Rationale:
Obviously, these titles are inappropriate.
a) The document deals with two kinds of 'server' roles:
* Resource List Server (RLS), and
* SIP servers in the Notifier role
Since Section 4 deals with RLS behaviour (and does tell so
in its headline), and Section 5 deals with Notifier behaviour,
the latter should tell so as well, and not pretend to be
applicable to server operation in general.
b) NOTIFY bodies/content are dealt with in Section 5.3 ff.
As can be seen immediately, Section 5.1 talks about
SUBSCRIBE bodies.
(6) typo/grammar (RFC 4660)
Within Section 5.2.1, at the bottom of page 10, RFC 4660 says:
[...]. Notifiers belonging to the
| domain MUST apply the filter to all notifications it sends for that
subscription, unless policy dictates otherwise.
^^^^^^^^
It should say:
[...]. Notifiers belonging to the
| domain MUST apply the filter to all notifications they send for that
subscription, unless policy dictates otherwise.
^^^^^^^^^
(7) placement of text ?? (RFC 4660)
The first paragraph of Section 5.3, on page 11,
Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD
retain the filter as long as the subscription persists. The filter
MAY be incorporated within an existing subscription (in an active
dialog) by sending a re-SUBSCRIBE that includes the filter in the
body.
apparently should have been moved up to the end of Section 5.2
because it is related to behaviour during
"Notifier Processing of SUBSCRIBE Requests" == Section 5.2
(8) improper use of articles (RFC 4660)
There are two related issues with text in the 2nd and 3rd paragraph
of Section 5.3, on mid-page 11:
If the response sent to the SUBSCRIBE was a "202" and the "202" was
| chosen because the filter could not be accepted that time, the NOTIFY
MAY be used to terminate the subscription if the filter is found
unacceptable.
| As described in [3], the NOTIFY message MAY contain a body that
describes the state of the resource. This body is in one of the
formats listed in the Accept header field of the SUBSCRIBE, or in the
package-specific default if the Accept header field is omitted.
The first occurrence of "the NOTIFY" is improper because this is the
first place the text talks about a NOTIFY message in this context.
The definite article should either be omitted entirely, or better
be replaced by "a NOTIFY message".
The second "the NOTIFY" is improper because it (re-)states a general
property of all NOTIFY messages, not of a specific NOTIFY message.
Therefore, the above text should say:
If the response sent to the SUBSCRIBE was a "202" and the "202" was
| chosen because the filter could not be accepted that time, a NOTIFY
maeeage MAY be used to terminate the subscription if the filter is
found unacceptable.
| As described in [3], a NOTIFY message MAY contain a body that
describes the state of the resource. This body is in one of the
formats listed in the Accept header field of the SUBSCRIBE, or in the
package-specific default if the Accept header field is omitted.
(9) missing articles (RFC 4660)
Within Section 7.1.3, near the top of page 20, where RFC 4660 says:
Notification containing both tuples is sent to the subscriber in this
case:
it should better say:
| A Notification containing both tuples is sent to the subscriber in
this case:
and within Section 7.2.3, in the upper half of page 26, where the RFC
says:
Notification to the subscriber is created, taking into account the
<trigger> and <what> elements:
it should better say:
| A Notification to the subscriber is created, taking into account the
<trigger> and <what> elements:
Notes:
from pending
Errata ID: 925
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks
significant issues with filter syntax ( ABNF in RFC 4661 )
Many of the filter examples in RFC 4661 and RFC 4660 do not conform
with the ABNF presented in Section 5, on page 11, of RFC 4661.
Further, that ABNF allows unexpected, strange instantiations of
'elem-path', and there's at least one significant semantical
ambiguity in the syntax described.
Because I am a bloody XML and XML XPATH layman, I am not in a
position to exactly diagnose what is wrong, and to quickly propose
suitable corrections, in a way that keeps the specification as
close to XPATH as possible.
I just present some of the strange outcomes of strict application
of the RFC 4661 ABNF and a few pointers to examples in the RFC
text that do not conform with that syntax.
a) ambiguous semantics / insufficient syntax
The ABNF production,
expression = "[" (elem-expr / attr-expr)
1*[oper (elem-expr / attr-expr)] "]"
entails
oper = "and" / "or"
Accordingly, these rules allow to build up expressions containing
multiple terms of the form '(elem-expr / attr-expr)' separated
by "and" and/or "or" operators.
There are no operator precedence rules specified, and there's no
possibility to insert parentheses to build sub-expressions / groups
to enforce the desired operator precedence.
Thus, it remains unclear whether, e.g., an expression of the form,
[ <expr1> or <expr2> and <expr3> ]
means:
[ <expr1> or ( <expr2> and <expr3> ) ]
(corresponding to commonly used precedence rules),
or:
[ ( <expr1> or <expr2> ) and <expr3> ]
(corresponding to simple left-to-right operator evaluation).
b) strange productions (#1)
The ABNF production,
elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
together with:
element = [ns] string
ns = string ":"
admits 'elem-path' values of strange and unexpected forms, e.g.,
****
*<ns_string1>:<elem_string1><elem_string2><ns_strind3>:<elem_string3>
without any intervening separator characters.
I am quite sure that this was not intended.
Looking at the 'elem-path' production, it can be observed:
The construction '1*[ ... ]' apparently does not make much
sense; since a group in brackets, '[ ... ]', means "optional",
this construction would be equivalent to the simpler '*( ...)'.
Perhaps, the '1*[ ... ]' group should look similar to the
'1*( ... )' group in
elem-reference = "/" 1*("/" / "/*" / ("/" element))
including the required "/" in all alternatives.
This also make the final, optional group questionable.
c) strange productions (#2)
The ABNF productions,
reference = elem-reference / attr-reference
attr-reference = reference attribute
together with:
attribute = "@" [ns] string
ns = string ":"
admits 'reference' values with multiple attribute references like
<elem-reference>@<ns1>:<attr1>@<attr2>@<attr3>@<ns4>:<attr4>
I am quite sure that this was not intended.
c) front end of examples not matching the syntax
Successive substitution of the ABNF productions of RFC 4661 leads
to the following observations:
* each 'elem-reference' must start with a double-slash, "//" ;
* each 'reference' starts with an 'elem-reference',
and hence it must start with a double-slash;
* each 'selection' starts with a 'reference,
and hence it must start with a double-slash.
Many examples do not conform to this restriction, starting from
the short examples at the bottom of page 11 up to many of the
detailed XML examples in both RFCs.
d) back end of examples not matching the syntax
Further observations from the ABNF:
* (un-escaped) square brackets, "[" and "]" only appear
in the 'expression' production, forming the leading and
the trailing character of it, respectively;
* each 'selection' contains at most one 'expression', and
this 'expression' is the trailing part of the 'selection;
* hence, each 'selection' contains at most one matching pair
of square brackets, and if it does, the "]" must be the
last character of it.
There are examples given, e.g. in Section 6.1 of RFC 4661,
on top of page 13, and in Section 6.6 of RFC 4661, on page 15,
where this restriction is not adhered to!
Final conclusion: Apparently, all (or most) examples presented
are expected to be crafted as intended, i.e. with valid syntax.
Hence, the ABNF needs to be substantially reworked to allow
production of these examples, and to really produce exactly what
it should. Otherwise, implementations based on the ABNF will
drastically fail, will not conform to the intended behaviour,
and will not be interoperable with implementations not based
on the ABNF of RFC 4661.
Notes:
from pending
Errata ID: 918
Status: Verified
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Section 3.6.1 says:
Previous XML document" in this context refers to the raw version of the most recent XML document that was sent to the subscriber, before the filters were applied to it.
It should say:
"Previous XML document" in this context refers to the raw version of the most recent XML document that was sent to the subscriber, before the filters were applied to it.
Notes:
missing quotation marks
from pending
Errata ID: 31
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-08
Held for Document Update by: Robert Sparks
Section 11.2 says:
[17] Roach, A. B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4663, September 2006.
It should say:
[17] Roach, A. B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
Errata ID: 923
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Robert Sparks
Section 6.5 says:
A user wants to know if a group of his friends is available for gaming. He orders notifications about the current status and future changes of the game-specific presence information.
It should say:
A user wants to know if a group of his friends is available for gaming. He orders notifications about the current status and future | changes of the (hypothetical) game-specific presence information.
Notes:
The example in Section 6.5 of RFC 4661 makes us of an XML namespace
"game-ext".
I strongly suspect that this