errata logo graphic

Found 3851 records.

Status: Verified (1845)

RFC0005, "Decode Encode Language (DEL)", June 1969

Source of RFC: Legacy

Errata ID: 582

Status: Verified
Type: Editorial

Reported By: Zhang Xin Liang
Date Reported: 2005-05-23

In the Forward, it says:

It was generally agreed beforehand that the runmning of interactive
programs across the network was the first problem that would be
faced.

It should say:

It was generally agreed beforehand that the running of interactive
programs across the network was the first problem that would be
faced.


RFC0031, "Binary Message Forms in Computer", February 1968

Source of RFC: Legacy

Errata ID: 581

Status: Verified
Type: Technical

Reported By: Jim Ursetto
Date Reported: 2000-09-25

Section 7 says:

   This size declaration should appear at the end of the
   message description; thus, forcing the reader to postpone an early
   consideration of bit details. xmodmap -e "add lock = Caps_Lock"

It should say:

   This size declaration should appear at the end of the
   message description; thus, forcing the reader to postpone an early
   consideration of bit details. 


RFC0033, "New Host-Host Protocol", February 1970

Source of RFC: Legacy

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.


RFC0060, "Simplified NCP Protocol", July 1970

Source of RFC: Legacy

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.


RFC0640, "Revised FTP reply codes", June 1974

Source of RFC: Legacy

Errata ID: 3435

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2012-12-25
Verifier Name: Barry Leiba
Date Verified: 2012-12-25

Section 11a says:

       There are four values for the first digit of the reply code:      11a

It should say:

       There are five values for the first digit of the reply code:      11a

Notes:

Technical type (vs. Editorial) although operation was not affected ("four" cannot reasonably be considered a misspelling of "five")

Reply code first digit values per sections 11b through 11f are 1, 2, 3, 4, and 5


RFC0783, "TFTP Protocol (revision 2)", June 1981

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


RFC0791, "Internet Protocol", September 1981

Source of RFC: Legacy
Area Assignment: int

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.


RFC0792, "Internet Control Message Protocol", September 1981

Source of RFC: Legacy
Area Assignment: int

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).

RFC0793, "Transmission Control Protocol", September 1981

Source of RFC: Legacy
Area Assignment: tsv

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: 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: 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: 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: 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"


RFC0804, "CCITT draft recommendation T.4", January 1981

Source of RFC: Legacy

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.


RFC0822, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982

Note: This RFC has been obsoleted by RFC2822

Source of RFC: Legacy
Area Assignment: app

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

RFC0868, "Time Protocol", May 1983

Source of RFC: Legacy

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.


RFC0894, "A Standard for the Transmission of IP Datagrams over Ethernet Networks", April 1984

Source of RFC: Legacy

Errata ID: 570

Status: Verified
Type: Technical

Reported By: Gerald Park
Date Reported: 2001-03-28

In Section Frame Format:

   The minimum length of the data field of a packet sent over an
   Ethernet is 1500 octets, thus the maximum length of an IP datagram
   sent over an Ethernet is 1500 octets.

It should say:

   The maximum length of the data field of a packet sent over an
   Ethernet is 1500 octets, thus the maximum length of an IP datagram
   sent over an Ethernet is 1500 octets.


RFC0952, "DoD Internet host table specification", October 1985

Source of RFC: Legacy

Errata ID: 3584

Status: Verified
Type: Editorial

Reported By: Matthew Gast
Date Reported: 2013-04-08
Verifier Name: Ted Lemon
Date Verified: 2013-04-08

In the header, it says:

(none)

It should say:

Updates: RFC 952

Notes:

The text of RFC 1123 clearly states is updating RFC 952, but it is not called out as updating RFC 952.

RFC 1123 section 2.1 states:

"The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax."


RFC0959, "File Transfer Protocol", October 1985

Source of RFC: Legacy
Area Assignment: app

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: 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: 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.


RFC1034, "Domain names - concepts and facilities", November 1987

Source of RFC: Legacy
Area Assignment: int

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: 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


RFC1035, "Domain names - implementation and specification", November 1987

Source of RFC: Legacy
Area Assignment: int

Errata ID: 562

Status: Verified
Type: Technical

Reported By: CFeng
Date Reported: 2003-02-09

Section 6.4.2 says:

                         +-----------------------------------------+
           Header        |         OPCODE=RESPONSE, ID=997         |
                         +-----------------------------------------+
          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
                         +-----------------------------------------+
           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
                         +-----------------------------------------+
          Authority      |                 <empty>                 |
                         +-----------------------------------------+
         Additional      |                 <empty>                 |
                         +-----------------------------------------+

It should say:

                         +-----------------------------------------+
           Header        |      OPCODE=IQUERY, ID=997, QR=1        |
                         +-----------------------------------------+
          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
                         +-----------------------------------------+
           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
                         +-----------------------------------------+
          Authority      |                 <empty>                 |
                         +-----------------------------------------+
         Additional      |                 <empty>                 |
                         +-----------------------------------------+

Notes:

There is an error in the Header line. It should be
"OPCODE=IQUERY, ID=997, QR=1" because the OPCODE does not have a
value of RESPONSE (see Section 4.1.1).


Errata ID: 2130

Status: Verified
Type: Technical

Reported By: Alexei A. Smekalkine
Date Reported: 2010-04-05
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 3.2.1 says:

TTL             a 32 bit signed integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.  Zero
                values are interpreted to mean that the RR can only be
                used for the transaction in progress, and should not be
                cached.  For example, SOA records are always distributed
                with a zero TTL to prohibit caching.  Zero values can
                also be used for extremely volatile data.

It should say:

TTL             a 32 bit unsigned integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted.  Zero
                values are interpreted to mean that the RR can only be
                used for the transaction in progress, and should not be
                cached.  For example, SOA records are always distributed
                with a zero TTL to prohibit caching.  Zero values can
                also be used for extremely volatile data.

Notes:

Conflicting descriptions of the type of TTL field.

Section 3.2.1 says "a 32 bit signed integer" while section 4.1.3 says "a 32 bit unsigned integer".


Errata ID: 563

Status: Verified
Type: Editorial

Reported By: Allan Edward Prentice
Date Reported: 2006-03-04
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.1 says:

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:

                of the root.

@               A free standing @ is used to denote the current origin.

It should say:

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:

@               A free standing @ is used to denote the current origin.

Notes:

"of the root." makes no sense here.


RFC1036, "Standard for interchange of USENET messages", December 1987

Note: This RFC has been obsoleted by RFC5536 RFC5537

Source of RFC: Legacy
Area Assignment: app

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.


RFC1065, "Structure and identification of management information for TCP/IP-based internets", August 1988

Note: This RFC has been obsoleted by RFC1155

Source of RFC: Legacy
Area Assignment: ops

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


RFC1071, "Computing the Internet checksum", September 1988

Source of RFC: Legacy
Area Assignment: int

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;

RFC1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Source of RFC: Legacy
Area Assignment: int

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| | | | |


RFC1123, "Requirements for Internet Hosts - Application and Support", October 1989

Source of RFC: Legacy

Errata ID: 558

Status: Verified
Type: Technical

Reported By: Ben Harris
Date Reported: 2003-02-12

Section 2.5 says:

Host names of up to 635 characters |2.1 |x| | | | | 

It should say:

Host names of up to 63 characters |2.1 |x| | | | | 

Notes:

Section 2.1 says "Host software MUST handle host names of up to 63 characters" and doesn't mention the number 635 at all.


Errata ID: 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.


RFC1150, "FYI on FYI: Introduction to the FYI Notes", March 1990

Note: This RFC has been obsoleted by RFC6360

Source of RFC: Legacy

Errata ID: 3829

Status: Verified
Type: Editorial

Reported By: Marek Perny
Date Reported: 2013-12-09
Verifier Name: RFC Editor

Section 2 says:

The formost reason is that the distribution
   mechanisms for RFCs are tried and true.

It should say:

The foremost reason is that the distribution
   mechanisms for RFCs are tried and true.

Notes:

spelling error


RFC1155, "Structure and identification of management information for TCP/IP-based internets", May 1990

Source of RFC: Legacy

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


RFC1158, "Management Information Base for network management of TCP/IP-based internets: MIB-II", May 1990

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)


RFC1180, "TCP/IP tutorial", January 1991

Source of RFC: Legacy
Area Assignment: int

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.

RFC1258, "BSD Rlogin", September 1991

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.


RFC1319, "The MD2 Message-Digest Algorithm", April 1992

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.


Errata ID: 3575

Status: Verified
Type: Editorial

Reported By: Andrew Clark
Date Reported: 2013-03-29
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 3.2 says:

      Set L to 0.

      /* Process each 16-word block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */

It should say:

      Set L to 0.

      /* Process each 16-byte block. */
      For i = 0 to N/16-1 do

         /* Checksum block i. */

Notes:

The comment should note that this section of the algorithm operates on a 16 byte -- rather than 16 word -- block.


Errata ID: 3576

Status: Verified
Type: Editorial

Reported By: Andrew Clark
Date Reported: 2013-03-29
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 3.4 says:

   Do the following:

      /* Process each 16-word block. */
      For i = 0 to N'/16-1 do

It should say:

   Do the following:

      /* Process each 16-byte block. */
      For i = 0 to N'/16-1 do

Notes:

The comment should note that this section of the algorithm operates on a 16 byte -- rather than 16 word -- block.


RFC1320, "The MD4 Message-Digest Algorithm", April 1992

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);

RFC1321, "The MD5 Message-Digest Algorithm", April 1992

Source of RFC: pem (sec)

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: 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: 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: 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). */

RFC1340, "Assigned Numbers", July 1992

Note: This RFC has been obsoleted by RFC1700

Source of RFC: Legacy
Area Assignment: gen

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.



RFC1345, "Character Mnemonics and Character Sets", June 1992

Source of RFC: 822ext (app)

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...


RFC1413, "Identification Protocol", February 1993

Source of RFC: ident (sec)

Errata ID: 548

Status: Verified
Type: Editorial

Reported By: Tymon Rzes'niowiecki
Date Reported: 2004-08-17

Section 6 says:

   3)   The 512 character limit on user IDs and the 64
        character limit on tokens should be understood to mean
        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
        token will be defined that has a length greater than 64

It should say:

   3)   The 512 character limit on user IDs and the 64
        character limit on tokens should be understood to mean
        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
        will be defined that has a length greater than 64

RFC1517, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", September 1993

Source of RFC: IESG ()

Errata ID: 547

Status: Verified
Type: Technical

Reported By: Mr. Sharky
Date Reported: 2002-03-30

Section 1 says:

   It has become clear that the first two of these problems are likely
   to become critical in the near term.  Classless Inter-Domain
   Routing (CIDR) ttempts to deal with these problems by defining a
   mechanism to slow the growth of routing tables and reduce the need
   to allocate new IP network numbers.

It should say:

   It has become clear that the first two of these problems are likely
   to become critical in the near term.  Classless Inter-Domain
   Routing (CIDR) attempts to deal with these problems by defining a
   mechanism to slow the growth of routing tables and reduce the need
   to allocate new IP network numbers.


RFC1519, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", September 1993

Note: This RFC has been obsoleted by RFC4632

Source of RFC: Legacy
Area Assignment: rtg

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.


RFC1524, "A User Agent Configuration Mechanism For Multimedia Mail Format Information", September 1993

Source of RFC: Legacy

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.


RFC1531, "Dynamic Host Configuration Protocol", October 1993

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.  


RFC1534, "Interoperation Between DHCP and BOOTP", October 1993

Source of RFC: dhc (int)

Errata ID: 545

Status: Verified
Type: Technical

Reported By: Tyler Tidman
Date Reported: 2001-09-05

Section 2 says:

   Any message received by a DHCP server that includes a 'DHCP message
   type' (51) option is assumed to have been sent by a DHCP client.

It should say:

   Any message received by a DHCP server that includes a 'DHCP message
   type' (53) option is assumed to have been sent by a DHCP client.


RFC1542, "Clarifications and Extensions for the Bootstrap Protocol", October 1993

Source of RFC: Legacy

Errata ID: 544

Status: Verified
Type: Technical

Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-24

Section 3.1.1 says:

  If a client falls into this category, it SHOULD set (to 1) the
  newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
  messages it generates.  This will provide a hint to BOOTP servers
  and relay agents that they should attempt to broadcast their
  BOOTREPLY messages to the client.

It should say:

  If a client falls into this category, it SHOULD set (to 1) the
  newly-defined BROADCAST flag in the 'flags' field of BOOTREQUEST
  messages it generates.  This will provide a hint to BOOTP servers
  and relay agents that they should attempt to broadcast their BOOTREPLY
  messages to the client.

Notes:

(i.e. the first instance of "BOOTREPLY" should be "BOOTREQUEST".)


RFC1628, "UPS Management Information Base", May 1994

Source of RFC: upsmib (ops)

Errata ID: 3275

Status: Verified
Type: Technical

Reported By: Jürgen Sellinath
Date Reported: 2012-07-03
Verifier Name: Ron Bonica
Date Verified: 2012-07-03

Section 4 says:

UPS-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       OBJECT-IDENTITY, Counter32, Gauge32, Integer32
           FROM SNMPv2-SMI
       DisplayString, TimeStamp, TimeInterval, TestAndIncr,
         AutonomousType
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF;


It should say:

UPS-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
       OBJECT-IDENTITY, Counter32, Gauge32, Integer32
           FROM SNMPv2-SMI
       DisplayString, TimeStamp, TimeInterval, TestAndIncr,
         AutonomousType, TEXTUAL-CONVENTION
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF;


Notes:

Textual conventions are used within this MIB, but the macro "TEXTUAL-CONVENTION" itself is not imported, as it should (RFC 2578 §3.2).


Errata ID: 3276

Status: Verified
Type: Technical

Reported By: Jürgen Sellinath
Date Reported: 2012-07-03
Verifier Name: Ron Bonica
Date Verified: 2012-07-03

Section 4.8 says:

upsShutdownAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483648)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION
               "Setting this object will shutdown (i.e., turn off)
               either the UPS output or the UPS system (as determined
               by the value of upsShutdownType at the time of
               shutdown) after the indicated number of seconds, or
               less if the UPS batteries become depleted. Setting
               this object to 0 will cause the shutdown to occur
               immediately.  Setting this object to -1 will abort the
               countdown.  If the system is already in the desired
               state at the time the countdown reaches 0, then
               nothing will happen.  That is, there is no additional
               action at that time if upsShutdownType = system and
               the system is already off.  Similarly, there is no
               additional action at that time if upsShutdownType =
               output and the output is already off.  When read,
               upsShutdownAfterDelay will return the number of
               seconds remaining until shutdown, or -1 if no shutdown
               countdown is in effect.  On some systems, if the agent
               is restarted while a shutdown countdown is in effect,
               the countdown may be aborted.  Sets to this object
               override any upsShutdownAfterDelay already in effect."
       ::= { upsControl 2 }

   upsStartupAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483648)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION

It should say:

upsShutdownAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483647)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION
               "Setting this object will shutdown (i.e., turn off)
               either the UPS output or the UPS system (as determined
               by the value of upsShutdownType at the time of
               shutdown) after the indicated number of seconds, or
               less if the UPS batteries become depleted. Setting
               this object to 0 will cause the shutdown to occur
               immediately.  Setting this object to -1 will abort the
               countdown.  If the system is already in the desired
               state at the time the countdown reaches 0, then
               nothing will happen.  That is, there is no additional
               action at that time if upsShutdownType = system and
               the system is already off.  Similarly, there is no
               additional action at that time if upsShutdownType =
               output and the output is already off.  When read,
               upsShutdownAfterDelay will return the number of
               seconds remaining until shutdown, or -1 if no shutdown
               countdown is in effect.  On some systems, if the agent
               is restarted while a shutdown countdown is in effect,
               the countdown may be aborted.  Sets to this object
               override any upsShutdownAfterDelay already in effect."
       ::= { upsControl 2 }

   upsStartupAfterDelay OBJECT-TYPE
       SYNTAX     INTEGER (-1..2147483647)
       UNITS      "seconds"
       MAX-ACCESS read-write
       STATUS     current
       DESCRIPTION

Notes:

The upper limit of the ranges of upsShutdownAfterDelay and upsStartupAfterDelay points to the intention to use a 32-bit signed integer.
The biggest positive value of a 32-bit singed integer, however, is 2147483647. On a 32-Bit system the upper range given within RFC1628 (2147483648) is so large that is is unsigned, which conflicts with the limitation to 32 bits.
As 2147483648 seconds is more than 68 years, it seems preferable to change this to 2147483647, loosing 1 second but gaining the ability to be implemented with 32 bits.


RFC1661, "The Point-to-Point Protocol (PPP)", July 1994

Source of RFC: pppext (int)

Errata ID: 543

Status: Verified
Type: Editorial

Reported By: Stuart Cheshire
Date Reported: 2006-09-27
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.4 says:

On reception of a Configure-Reject, the Identifier field MUST
match that of the last transmitted Configure-Request.
Additionally, the Configuration Options in a Configure-Reject MUST
be a proper subset of those in the last transmitted Configure-
Request.  Invalid packets are silently discarded.

It should say:

On reception of a Configure-Reject, the Identifier field MUST
match that of the last transmitted Configure-Request.
Additionally, the Configuration Options in a Configure-Reject MUST
be a subset of those in the last transmitted Configure-
Request.  Invalid packets are silently discarded.

Notes:

The word "proper" should be deleted. (I discussed this a while ago with
the author, Bill Simpson, and he agreed.)

If A is a subset of B, then set A contains only elements that are also in
set B, up to and including all the elements of B (in which case A == B).

If A is a PROPER subset of B, then A contains only elements that are in
B, up to BUT NOT including all the elements of B.

In this case, the word "proper" is just a mistake, perhaps added because
someone thought it made the sentence sound better, without realizing that
the mathematical term "proper subset" has a specific precise meaning,
which is the wrong meaning in this case. As written in the RFC, the
sentence states that if a Configure-Request packet has n Configuration
Options in it, ALL of which are not recognizable or not acceptable, then
when the implementation returns its Configure-Reject packet, it's only
allowed to indicate that up to n-1 options were rejected, when in truth
ALL were rejected. Removing the word "proper" removes this unintended and
incorrect limitation.


RFC1662, "PPP in HDLC-like Framing", July 1994

Source of RFC: pppext (int)

Errata ID: 542

Status: Verified
Type: Technical

Reported By: Charles Cranford
Date Reported: 2002-03-07

In the References Section:

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 
         STD 50, RFC 1661, Daydreamer, July 1994.

It should say:

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 
         STD 51, RFC 1661, Daydreamer, July 1994.


RFC1685, "Writing X.400 O/R Names", August 1994

Source of RFC: Legacy
Area Assignment: app

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.


RFC1724, "RIP Version 2 MIB Extension", November 1994

Source of RFC: ripv2 (rtg)

Errata ID: 540

Status: Verified
Type: Editorial

Reported By: Orly Nicklass
Date Reported: 2004-05-27

Section 9 says:

            rip2IfConfAuthKey
                OCTET STRING (SIZE(0..16)),

It should say:

            rip2IfConfAuthKey
                OCTET STRING,


RFC1725, "Post Office Protocol - Version 3", November 1994

Note: This RFC has been obsoleted by RFC1939

Source of RFC: Legacy
Area Assignment: app

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.


RFC1771, "A Border Gateway Protocol 4 (BGP-4)", March 1995

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.


RFC1810, "Report on MD5 Performance", June 1995

Source of RFC: Legacy

Errata ID: 1059

Status: Verified
Type: Editorial

Reported By: Denis Duault
Date Reported: 2007-08-28

In the References, it says:

   [7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
       papers/touch/md5-opt.tar>.

It should say:

   [7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
       papers/touch/md5-opt.tar.Z>.

Notes:

I noticed a broken link.
(the final ".Z" is missing)


RFC1812, "Requirements for IP Version 4 Routers", June 1995

Source of RFC: rreq (rtg)

Errata ID: 537

Status: Verified
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2005-05-12

Section 11 says:

   ROUTE:4.
        Lougheed, K., and Y.  Rekhter, "A Border Gateway Protocol 3
        (BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM
        Corp., October 1991.

It should say:

   ROUTE:4.
        Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 
        RFC 1771, March 1995.


Errata ID: 538

Status: Verified
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2005-05-12

Section 7.3.1 says:

   Although it was not designed as an exterior gateway protocol, RIP
   (described in Section [7.2.4]) is sometimes used for inter-AS
   routing.

It should say:

   Although it was not designed as an exterior gateway protocol, RIP
   (described in Appendix F.2) is sometimes used for inter-AS
   routing.

RFC1867, "Form-based File Upload in HTML", November 1995

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=


RFC1878, "Variable Length Subnet Table For IPv4", December 1995

Source of RFC: Legacy
Area Assignment: int

Errata ID: 2171

Status: Verified
Type: Editorial

Reported By: Clark Rossdale
Date Reported: 2010-04-23

Section global says:

illistrate

It should say:

illustrate

RFC1891, "SMTP Service Extension for Delivery Status Notifications", January 1996

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.


RFC1894, "An Extensible Message Format for Delivery Status Notifications", January 1996

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


RFC1915, "Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol", February 1996

Source of RFC: Legacy

Errata ID: 533

Status: Verified
Type: Technical

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


RFC1925, "The Twelve Networking Truths", April 1996

Source of RFC: Legacy

Errata ID: 532

Status: Verified
Type: Technical

Reported By: John Ioannidis
Date Reported: 2003-04-08

Section 2 says:

   the word is "agglutinate", not "aglutenate"


RFC1927, "Suggested Additional MIME Types for Associating Documents", April 1996

Source of RFC: Legacy

Errata ID: 531

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2003-10-07

Section 7 says:

          1) they should not be used on data flines which might end
             up in the hands of very small children

It should say:

          1) they should not be used on data files which might end up
             in the hands of very young children


RFC1928, "SOCKS Protocol Version 5", March 1996

Source of RFC: aft (sec)

Errata ID: 3198

Status: Verified
Type: Technical

Reported By: Andreas Cudok
Date Reported: 2012-04-19
Verifier Name: Sean Turner
Date Verified: 2012-05-04

Section 7 says:

o if ATYP is X’04’ - 20+method_dependent octets smaller

It should say:

o if ATYP is X’04’ - 22+method_dependent octets smaller

Notes:

RSV[2]+FRAG[1]+ATYP[1]+DST.ADDR[16]+DST.PORT[2]=22
if ATYP is X’04’ [IPv6 address]


RFC1936, "Implementing the Internet Checksum in Hardware", April 1996

Source of RFC: Legacy

Errata ID: 530

Status: Verified
Type: Editorial

Reported By: Joe Touch
Date Reported: 2005-05-11

Section 4 says:

            4-bit carry-lookahead 2's complement adder:
                    a,b : input data
                    p   : carry propagate, where pi = ai*bi = (ai)(bi)
                    g   : carry generate, where gi = ai + bi

It should say:

             4-bit carry-lookahead 2's complement adder:
                    a,b : input data
                    p   : carry propagate, where pi = ai + bi
                    g   : carry generate, where gi = ai*bi = (ai)(bi)

Notes:

Note: This change affects only page 4; the PLD code is known correct.


RFC1939, "Post Office Protocol - Version 3", May 1996

Source of RFC: Legacy
Area Assignment: app

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.


RFC1959, "An LDAP URL Format", June 1996

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


RFC1979, "PPP Deflate Protocol", August 1996

Source of RFC: pppext (int)

Errata ID: 527

Status: Verified
Type: Technical

Reported By: Bartlomiej Molenda
Date Reported: 2003-11-03

Section 3 says:

   Length

      3

It should say:

   Length

      4


RFC1995, "Incremental Zone Transfer in DNS", August 1996

Source of RFC: dnsind (int)

Errata ID: 3197

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2012-04-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 4, pg.3 says:

|  RRs in the incremental transfer messages may be partial.  That is, if
   a single RR of multiple RRs of the same RR type changes, only the
   changed RR is transferred.

It should say:

|  RRsets in the incremental transfer messages may be partial.  That is,
|  if a single RR out of multiple RRs of the same RR type at the same
|  owner name and CLASS changes, only the changed RR is transferred.

Notes:

Rationale:
DNS resource records (RRs) are always transferred as integral
entities in the DNS protocol, and IXFR is no exception for this
rule. So there never are partial RRs in any IXFR response packets.
However, as indicated more precisely in the adjusted text above,
it is intended that partial _RRsets_ are carried in IXFR responses;
unchanged RRs are not sent inside incremental response messages.
Historical Note:
The above issue has been identified by the submitter in 2008,
but no Errata have been filed so far. However, it already had
been observed in 1999 by Andreas Gustafsson, who, in the context of
the work on RFC 1995bis, recently has provided the DNSEXT WG access
to a privately archived DNSIND mailing list thread on RFC 1995,
in which such issues have been discussed in November 1999.
For the record, the technical issues in RFC 1995 that can be
addressed by Errata Notes are now being submitted this way.


RFC2015, "MIME Security with Pretty Good Privacy (PGP)", October 1996

Source of RFC: Legacy

Errata ID: 526

Status: Verified
Type: Editorial

Reported By: Bruce Lilly
Date Reported: 2004-01-11

Section 5 says:

&railing whitespace that occurs on lines in order to ensure  =20

It should say:

& trailing whitespace that occurs on lines in order to ensure  =20

RFC2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 1610

Status: Verified
Type: Technical

Reported By: Matt Mathis
Date Reported: 2008-11-22
Verifier Name: Lars Eggert
Date Verified: 2008-12-19

Section 5.1 says:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender MUST ignore prior SACK information in determining
   which data to retransmit.

It should say:

   The use of time-outs as a fall-back mechanism for detecting dropped
   packets is unchanged by the SACK option.  Because the data receiver
   is allowed to discard SACKed data, when a retransmit timeout occurs
   the data sender SHOULD ignore prior SACK information in determining
   which data to retransmit.

Notes:

At least one OS (Linux) violates the MUST to good effect: Even when timeout
driven, it keeps old SACK data so it can avoid retransmitting data already at
the receiver. Thus even under severe bandwidth exhaustion, 100% of the data
delivered to the receiver causes forward progress and the system is not subject
to classical congestion collapse (that is, congestion collapse from
unnecessarily-retransmitted packets).

When this draft is reopened, this text should be further refined to address a
number of additional issues. In particular:

- It has been observed that clearing the scoreboard on timeouts sometimes
causes very inefficient network utilization, with large quantities of
duplicated data delivered to the receiver.

- There is some risk of deadlock if the timeout was caused a corrupted
scoreboard or if the receiver reneges SACK blocks. It is important that the
checks for reneging and inconsistent scoreboards are robust. Furthermore,
there probably should be a mandatory fall back mechanism, such as requiring
classical fast retransmit and new reno behavior, or ultimately under repeated
timeouts with no forward progress, clearing the scoreboard.

- Making SACK more robust in the presence of timeouts may increase the risk of
congestion collapse associated with cascaded bottlenecks, because it may
enable TCP to function under unreasonably high loss rates.


RFC2021, "Remote Network Monitoring Management Information Base Version 2 using SMIv2", January 1997

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 }


RFC2026, "The Internet Standards Process -- Revision 3", October 1996

Source of RFC: poised95 (gen)

Errata ID: 522

Status: Verified
Type: Technical

Reported By: Scott Bradner
Date Reported: 2002-08-01

Section 10.4 says:

   "The IETF takes no position regarding the validity or scope of
   any intellectual property or other rights that might be claimed
   to  pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; neither does
   it represent that it has made any effort to identify any such
   rights.  Information on the IETF's procedures with respect to
   rights in standards-track and standards-related documentation
   can be found in BCP-11..."

Notes:

The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).


Errata ID: 524

Status: Verified
Type: Technical

Reported By: Bob Harvey
Date Reported: 2002-12-30

Section 2.1 says:

   Some RFCs standardize the results of community deliberations about
   statements of principle or conclusions about what is the best way to
   perform some operations or IETF process function.  These RFCs form
   the specification has been adopted as a BCP, it is given the
   additional label "BCPxxx", but it keeps its RFC number and its place
   in the RFC series. (see section 5)

It should say:

   Some RFCs standardize the results of community deliberations about
   statements of principle or conclusions about what is the best way
   to perform some operations or IETF process function.  These RFCs
   form the 'BCP' (Best Current Practice) subseries of the RFC
   series.  When a specification has been adopted as a BCP, it is
   given the additional label "BCPxxx", but it keeps its RFC number
   and its place in the RFC series. (see section 5)

Notes:

The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).


Errata ID: 523

Status: Verified
Type: Editorial

Reported By: Morris M. Keesan
Date Reported: 2003-10-07

Section 9.1 says:

    This variance procedure is for use when a one-time waving of some
    provision of this document is felt to be required.

It should say:

    This variance procedure is for use when a one-time waiving of some
    provision of this document is felt to be required.

Errata ID: 586

Status: Verified
Type: Editorial

Reported By: Morris M. Keesan
Date Reported: 2003-10-07

Section 10.3.1 says:

    4. The contributor represents that contribution properly
       acknowledge major contributors.

    5. The contribuitor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution.

It should say:

    4. The contributor represents that the contribution properly
       acknowledges major contributors.

    5. The contributor, the organization (if any) he represents and
       the owners of any proprietary rights in the contribution, agree
       that no information in the contribution is confidential and
       that the ISOC and its affiliated organizations may freely
       disclose any information in the contribution.

Notes:

verb agreement ("acknowledges") and spelling correction ("contributor")


Errata ID: 1622

Status: Verified
Type: Editorial

Reported By: Stéphane Bortzmeyer
Date Reported: 2008-12-01
Verifier Name: Russ Housley
Date Verified: 2009-10-01

Section 6.5.2 says:

ISEG Chair

It should say:

IESG Chair


Errata ID: 2007

Status: Verified
Type: Editorial

Reported By: Julian Reschke
Date Reported: 2010-01-17
Verifier Name: Russ Housley
Date Verified: 2010-03-02

Section 10.4 says:

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

It should say:

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implementation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

Notes:

"implementations" is misspelled.


Errata ID: 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./


RFC2028, "The Organizations Involved in the IETF Standards Process", October 1996

Source of RFC: poised95 (gen)

Errata ID: 521

Status: Verified
Type: Editorial

Reported By: Pete Resnick
Date Reported: 2006-03-21
Verifier Name: Russ Housley
Date Verified: 2009-10-01

Section 3.6 says:

The IAB appoints the IETF chair and is responsible for approving
other IESG candidates put forward by the IETF nominating committee.

It should say:

Full IAB members, including the IETF chair, are selected and 
appointed according to the procedures defined in [E].

Notes:

The document references include:

[E] Galvin, J (Ed.), "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall Committees",
RFC 2027, October 1996.

Of course, this document has been revised since RFC 2028 was written.


Errata ID: 764

Status: Verified
Type: Editorial

Reported By: Pete Resnick
Date Reported: 2006-03-21
Verifier Name: Russ Housley
Date Verified: 2010-03-02

Section 3.6 says:

The IAB is also responsible for reviewing and approving the charters of new Working Groups that are proposed for the IETF.

It should say:

The formation of a working group requires a charter which is primarily negotiated 
between a prospective working group Chair and the relevant Area 
Director(s), although final approval is made by the IESG with advice 
from the Internet Architecture Board (IAB).

Notes:

from pending


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.

RFC2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", October 1996

Note: This RFC has been obsoleted by RFC4330

Source of RFC: Legacy
Area Assignment: int

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: 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: 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


RFC2040, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", October 1996

Source of RFC: Legacy

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: 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: 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.

RFC2045, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996

Source of RFC: 822ext (app)

Errata ID: 2586

Status: Verified
Type: Technical

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.


RFC2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996

Source of RFC: 822ext (app)

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: 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: 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: 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: 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.


RFC2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996

Source of RFC: 822ext (app)

Errata ID: 504

Status: Verified
Type: Technical

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.


RFC2060, "Internet Message Access Protocol - Version 4rev1", December 1996

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


RFC2069, "An Extension to HTTP : Digest Access Authentication", January 1997

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.


RFC2092, "Protocol Analysis for Triggered RIP", January 1997

Source of RFC: rip (rtg)

Errata ID: 502

Status: Verified
Type: Technical

Reported By: Kwan Jong Yoo
Date Reported: 2004-03-30

Section 3.3. says:

   Triggered RIP will NOT fuction properly (and should NOT be used) if a
   routing information will be retained/advertised for an arbitrarily
   long period of time (until an update in the opposite direction fails
   to obtain a response).

It should say:

   Triggered RIP will NOT function properly (and should NOT be used) if a
   routing information will be retained/advertised for an arbitrarily
   long period of time (until an update in the opposite direction fails
   to obtain a response).


RFC2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997

Source of RFC: ipsec (sec)

Errata ID: 501

Status: Verified
Type: Editorial

Reported By: Gregory Ogonowski
Date Reported: 2005-06-23

Section 9 says:

        MD5Update(&context, k_ipad, 64)      /* start with inner pad */

It should say:

        MD5Update(&context, k_ipad, 64);     /* start with inner pad */

Notes:



RFC2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Source of RFC: Legacy
Area Assignment: gen

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: 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: 498

Status: Verified
Type: Technical

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It should say:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED", means that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


Errata ID: 500

Status: Verified
Type: Technical

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

It should say:

3. SHOULD   This word, or the adjective "RECOMMENDED", means that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.


Errata ID: 494

Status: Verified
Type: Editorial

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Verifier Name: RFC Editor
Date Verified: 2007-11-07

Section 6 says:

(e.g., limiting retransmisssions)

It should say:

(e.g., limiting retransmissions)

Errata ID: 499

Status: 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.


RFC2127, "ISDN Management Information Base using SMIv2", March 1997

Source of RFC: isdnmib (int)

Errata ID: 1952

Status: Verified
Type: Technical

Reported By: Yigal Hachmon
Date Reported: 2009-12-01
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section Conformance says:

isdnMibConformance OBJECT IDENTIFIER ::= { isdnMib 2 }




It should say:

isdnMibConformance OBJECT IDENTIFIER ::= { isdnMib 3 }

Notes:

Maybe this was already reported as Errata 491, which I couldn't read.
Anyhow

isdnMib 2 is already used as
isdnMibTrapPrefix OBJECT IDENTIFIER ::= { isdnMib 2 }


RFC2131, "Dynamic Host Configuration Protocol", March 1997

Source of RFC: dhc (int)

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: 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
unicast delivery.

Notes:

typo (uicast -> unicast). Updated 2013-06-05. Thanks to Carlos Prendes for the correction.


RFC2132, "DHCP Options and BOOTP Vendor Extensions", March 1997

Source of RFC: dhc (int)

Errata ID: 486

Status: Verified
Type: Technical

Reported By: George V. Neville-Neil
Date Reported: 2001-12-12

Section 9.6 says:

    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-9 |
   +-----+-----+-----+

It should say:

    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-8 |
   +-----+-----+-----+


Errata ID: 2305

Status: Verified
Type: Technical

Reported By: Richard Chen
Date Reported: 2010-06-17
Verifier Name: Brian Haberman
Date Verified: 2012-12-12

Section 3.10. says:

The code for the log server option is 8.

It should say:

The code for the cookie server option is 8.

Notes:

Copy error.


RFC2152, "UTF-7 A Mail-Safe Transformation Format of Unicode", May 1997

Source of RFC: Legacy

Errata ID: 862

Status: Verified
Type: Editorial

Reported By: Christian Aymon
Date Reported: 2006-05-16

In "UTF-7 Definition", it says:

Such characters
include control characters such as carriage returns and line
feeds; thus, a Unicode shifted sequence always terminates at the
of a line.

It should say:

Such characters
include control characters such as carriage returns and line
feeds; thus, a Unicode shifted sequence always terminates at the
end of a line.

Notes:

missing word


RFC2154, "OSPF with Digital Signatures", June 1997

Source of RFC: Legacy

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


RFC2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997

Source of RFC: Legacy

Errata ID: 485

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-05

Section 2 says:

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)

It should say:

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)


Errata ID: 1457

Status: Verified
Type: Editorial

Reported By: Julian Reschke
Date Reported: 2008-06-20
Verifier Name: Lisa Dusseault
Date Verified: 2008-10-06

Section Boilerplate says:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Updates: 1806                                                  S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

It should say:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Obsoletes: 1806                                                S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

Notes:

RFC 2183 completely replaces RFC 1806, so it should say "obsoletes" instead of "updates".


Errata ID: 3847

Status: Verified
Type: Editorial

Reported By: Eric Reitmaier
Date Reported: 2013-12-23
Verifier Name: Barry Leiba
Date Verified: 2013-12-23

Section 3 says:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

It should say:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
        Content-Description: a complete map of the human genome

Notes:

In section 2 it states:

disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)

The semicolon should not be at the end of a header field.
And in the example there is a semicolon behind the disposition-parm "modification-date".


RFC2184, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", August 1997

Note: This RFC has been obsoleted by RFC2231

Source of RFC: Legacy
Area Assignment: app

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 "?="


RFC2192, "IMAP URL Scheme", September 1997

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


RFC2196, "Site Security Handbook", September 1997

Source of RFC: ssh ()

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


RFC2202, "Test Cases for HMAC-MD5 and HMAC-SHA-1", September 1997

Source of RFC: Legacy
Area Assignment: sec

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: 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


RFC2229, "A Dictionary Server Protocol", October 1997

Source of RFC: Legacy

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.]


RFC2231, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", November 1997

Source of RFC: Legacy

Errata ID: 476

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2003-02-09

Section 4 says:

   A single quote is used to separate the character set, language, and
   actual value information in the parameter value string, and an
   percent sign is used to flag octets encoded in hexadecimal.

It should say:

   A single quote is used to separate the character set, language, and
   actual value information in the parameter value string, and a
   percent sign is used to flag octets encoded in hexadecimal.


Errata ID: 477

Status: Verified
Type: Technical

Reported By: Shuhei KOBAYASHI
Date Reported: 2001-04-17

Section 7 says:

    extended-parameter := (extended-initial-name "="
                          extended-value) /
                         (extended-other-names "="
                          extended-other-values)

It should say:

    extended-parameter := (extended-initial-name "="
                          extended-initial-value) /
                         (extended-other-names "="
                          extended-other-values)



Errata ID: 478

Status: Verified
Type: Technical

Reported By: Jeffrey Stedfast
Date Reported: 2001-11-24

Section 7 says:

   encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

It should say:

   encoded-word := "=?" charset ["*" language] "?" encoding "?"
                   encoded-text "?="


Errata ID: 590

Status: Verified
Type: Technical

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!"

RFC2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997

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: 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: 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: 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.



RFC2236, "Internet Group Management Protocol, Version 2", November 1997

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.


RFC2241, "DHCP Options for Novell Directory Services", November 1997

Source of RFC: dhc (int)

Errata ID: 469

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-31

Section 15 says:

   Content-type: message/disposition-notification

   Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail
   3.0)

   Original-Recipient: rfc822;22722@vm.company.com

It should say:

   Content-type: message/disposition-notification

   Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail
   3.0)
   Original-Recipient: rfc822;22722@vm.company.com


RFC2244, "ACAP -- Application Configuration Access Protocol", November 1997

Source of RFC: acap (app)

Errata ID: 468

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

return-metadata = nil / string / value-list / acl

It should say:

return-metadata = nil / string / number / value-list / acl
                ;; number is only used for "size" metadata items
                ;; acl is only used for "acl" metadata items

Notes:

Bug/clarification in formal syntax (where it doesn't match examples).



Errata ID: 613

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

   acl                = "(" [acl-identrights *(SP acl-identrights)] ")"
                              *(SPACE acl-identrights)] ")"

It should say:

   acl                = "(" [acl-identrights *(SP acl-identrights)] ")"

Errata ID: 614

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

[Formal syntax for UPDATECONTEXT was missing.] 

It should say:

command-updatectx  = "UPDATECONTEXT" 1*(SP context)


Errata ID: 615

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 6.6.2 says:

   Example:    C: Z4S9 DELETEDSINCE "/folder/site/" 19951205103412
               S: Z4S9 DELETED "blurdybloop"
               S: Z4S9 DELETED "anteaters"
               S: Z4S9 OK "DELETEDSINCE completed"
               C: Z4U3 DELETEDSINCE "/folder/site/" 19951009040854
               S: Z4U3 NO (TOOOLD) "Don't have that information"

It should say:

   Example:    C: Z4S9 DELETEDSINCE "/folder/site/" "19951205103412"
               S: Z4S9 DELETED "blurdybloop"
               S: Z4S9 DELETED "anteaters"
               S: Z4S9 OK "DELETEDSINCE completed"
               C: Z4U3 DELETEDSINCE "/folder/site/" "19951009040854"
               S: Z4U3 NO (TOOOLD) "Don't have that information"
 

Notes:

Fix DELETEDSINCE example to include quotes around timestamps


Errata ID: 616

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

"count" metadata-type is not documented in prose.  Will be removed in next revision.

Errata ID: 617

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 8 says:

command-lang       = "LANG" *(SP lang-tag)

It should say:

command-lang       = "LANG" 1*(SP lang-tag)

Notes:

Formal syntax for LANG command didn't require at least one language tag. Since it doesn't make sense to change the language to an unspecified value, the ABNF needs to be changed.


Errata ID: 619

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 6.4.5. says:

    C: A049 SEARCH "/addressbook/~/public" RETURN ("addressbook.Alias"
           "addressbook.Email") MAKECONTEXT ENUMERATE "blob" LIMIT 100 1
           SORT ("addressbook.Alias" "i;octet") NOT EQUAL
           "addressbook.Email" NIL

It should say:

    C: A049 SEARCH "/addressbook/~/public" RETURN ("addressbook.Alias"
           "addressbook.Email") MAKECONTEXT ENUMERATE "blob" LIMIT 100 1
           SORT ("addressbook.Alias" "i;octet") NOT EQUAL
           "addressbook.Email" "i;octet" NIL


Notes:

One SEARCH example is missing comparator in EQUAL statement.


Errata ID: 620

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Need to use entry-path on notifications when DEPTH > 1 is specified.



Errata ID: 621

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Note explicitly that client commands must be transmitted in full
before starting a new command. This includes literals and the
AUTHENTICATE exchange.

Errata ID: 622

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23
Report Text:

Note that "revocation of rights" is also know as "negative rights".



Errata ID: 623

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 2.6.1. says:

An atom consists of one to 1024 non-special characters.  It must
begin with a letter.  Atoms are used for protocol keywords.

Notes:

Need to define the term "non-special" as equivalent to the syntax for "ATOM-CHAR".


Errata ID: 624

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 2.6.2. says:

A number consists of one or more digit characters, and represents a
numeric value.  Numbers are restricted to the range of an unsigned
32-bit integer: 0 < number < 4,294,967,296.

Notes:

Permit number to include 0 to match formal syntax.


Errata ID: 625

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 1.5. says:

   UTC  Universal Coordinated Time as maintained by the Bureau
        International des Poids et Mesures (BIPM).

Notes:

"Universal Coordinated Time" should be "Coordinated Universal Time".


Errata ID: 626

Status: Verified
Type: Technical

Reported By: Chris Newman
Date Reported: 2001-01-23

Section 3.5. says:

An ACL is represented by a multi-value with each value containing an 
identifier followed by a tab character followed by the rights. 

Notes:

This is incorrect and should be deleted from the document. The formal syntax in errata 1 is normative.


RFC2252, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997

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

RFC2254, "The String Representation of LDAP Search Filters", December 1997

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 = ">="


RFC2268, "A Description of the RC2(r) Encryption Algorithm", March 1998

Source of RFC: Legacy

Errata ID: 465

Status: Verified
Type: Technical

Reported By: Simon Josefsson
Date Reported: 2001-10-17

Section 6 says:

   RC2Version ::= INTEGER -- 1-1024

   RC2 in CBC mode has two parameters: an 8-byte initialization vector
   (IV) and a version number in the range 1-1024 which specifies in a
   roundabout manner the number of effective key bits to be used for
   the RC2 encryption/decryption.

It should say:

   RC2Version ::= INTEGER -- 0-1024

   RC2 in CBC mode has two parameters: an 8-byte initialization vector
   (IV) and a version number in the range 0-1024 which specifies in a
   roundabout manner the number of effective key bits to be used for
   the RC2 encryption/decryption.


RFC2281, "Cisco Hot Standby Router Protocol (HSRP)", March 1998

Source of RFC: Legacy

Errata ID: 464

Status: Verified
Type: Technical

Reported By: Bob Braden
Date Reported: 2003-05-22
Report Text:

Section 2, "Conditions of Use" was mistakenly included in the
document and is incorrect.

Current information on ownership claims for protocols documented
in RFCs is available from http://www.ietf.org/ietf/IPR.


RFC2286, "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", February 1998

Source of RFC: Legacy

Errata ID: 463

Status: Verified
Type: Technical

Reported By: Kevin Springle
Date Reported: 2002-09-17

In the Appendix:

/* The HMAC_SHA1 transform looks like:

It should say:

/* The HMAC_RMD160 transform looks like:

 

Errata ID: 627

Status: Verified
Type: Technical

Reported By: Kevin Springle
Date Reported: 2002-09-17

In the Appendix:

    /* if key is longer than 64 bytes reset it to key=SHA1(key) */

It should say:

   /* if key is longer than 64 bytes reset it to key=RMD160(key) */

Notes:



RFC2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998

Source of RFC: dnsind (int)

Errata ID: 461

Status: Verified
Type: Editorial

Reported By: Hideshi Enokihara
Date Reported: 2006-02-01
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 7.2 says:

7.2 Dead / Unreachable Server (OPTIONAL)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.

   Examples of transport layer indications are:

      ICMP error messages indicating host, net or port unreachable.
      TCP resets
      IP stack error messages providing similar indications to those above.

   A server MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.

It should say:

7.2 Dead / Unreachable Server (OPTIONAL)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.

   Examples of transport layer indications are:

      ICMP error messages indicating host, net or port unreachable.
      TCP resets
      IP stack error messages providing similar indications to those above.

   A resolver MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.

Notes:

Last sentence says, "A server MAY cache a dead server indication.".
But, this "server" is typo, I think.
This "server" should be "resolver" because section 7.1's last sentence uses "resolver".


RFC2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", April 1998

Source of RFC: Legacy

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: 3492

Status: Verified
Type: Technical

Reported By: Giles Saunders
Date Reported: 2013-02-21
Verifier Name: Barry Leiba
Date Verified: 2013-02-21

Section 3 says:

               | "caf%C3%E8"                ; Catalan, French, Galician

It should say:

               | "caf%C3%E9"                ; Catalan, French, Galician

Notes:

This error was originally reported by Larry Masinter in 2005.

=============== Verifier Notes ===============
OK, I feel really silly verifying errata on a joke RFC, but......
=========================================


RFC2327, "SDP: Session Description Protocol", April 1998

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.


RFC2328, "OSPF Version 2", April 1998

Source of RFC: ospf (rtg)

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: 3746

Status: Verified
Type: Technical

Reported By: Ramakrishna DTV
Date Reported: 2013-10-09
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Throughout the document, when it says:

*. Section 3.3. (Classification of routers) says:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS.  This classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) says:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.

*. Section 13. (The Flooding Procedure) says:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

It should say:

*. Section 3.3. (Classification of routers) should say:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS (except stub areas).  This
            classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) should say:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, or if this is a type-4 summary LSA and the neighbor
		is associated with a stub area, generate the neighbor event
        SeqNumberMismatch and stop processing the packet.

*. Section 13. (The Flooding Procedure) should say:

There should be an additional step in between steps 3 and 4  in
Section 13. The additional step below is denoted 3.5:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the
        area has been configured as a stub area, discard the LSA and get
        the next one from the Link State Update Packet.  Type-4 Summary
        LSAs are not flooded into/throughout stub areas.

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

Notes:

This whole note is regarding stub areas.

RFC 2328 is already consistent with respect to AS-external-LSAs
(LS type =5). The RFC explicitly indicates that they should be neither
sent nor received in stub areas.

But RFC 2328 seems to have some omissions with respect to type-4
Summary LSA (LS type = 4). The RFC explicitly indicates that these
LSAs should never be sent in stub areas. But it does not mention what
should be done if these LSAs are received in stub areas.

The above updates try to remedy this omission.

If the neighbor is associated with a stub area, then we should never
receive a type-4 summary LSA from that neighbor. Here are the relevant
quotes from the RFC:

Section 12.4.3.1.(Originating summary-LSAs into stub areas):

"As specified in Section 12.4.3, Type 4 summary-LSAs
(ASBR-summary-LSAs) are never originated into stub
areas."

Section 4.2. (AS external routes):

"To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers."


This is an omission from RFC 2328.

http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html


Errata ID: 3734

Status: Verified
Type: Editorial

Reported By: Ramakrishna DTV
Date Reported: 2013-09-23
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Section 8.2 says:

            The AuType specified in the packet must match the AuType
            specified for the associated area.

It should say:

            The AuType specified in the packet must match the AuType
            specified for the associated interface.

Notes:

In OSPFv2, authentication is configured per interface and not per area.
Appendix D clarifies this: "The authentication type is configurable on a per-interface
(or equivalently, on a per-network/subnet) basis."


RFC2347, "TFTP Option Extension", May 1998

Source of RFC: Legacy
Area Assignment: app

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.


RFC2362, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", June 1998

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.


RFC2373, "IP Version 6 Addressing Architecture", July 1998

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.


RFC2384, "POP URL Scheme", August 1998

Source of RFC: Legacy

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).


RFC2388, "Returning Values from Forms: multipart/form-data", August 1998

Source of RFC: Legacy
Area Assignment: app

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.


RFC2392, "Content-ID and Message-ID Uniform Resource Locators", August 1998

Source of RFC: mhtml (app)

Errata ID: 454

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-03-07

Section 2 says:

   example, "cid:foo4%25foo1@bar.net" corresponds to

     Content-ID: <foo4%25foo1@bar.net>

It should say:

   example, "cid:foo4%25foo1@bar.net" corresponds to

     Content-ID: <foo4%foo1@bar.net>


RFC2395, "IP Payload Compression Using LZS", December 1998

Source of RFC: ippcp (int)

Errata ID: 453

Status: Verified
Type: Editorial

Reported By: John Border
Date Reported: 2000-08-30

Section 7 says:

-

It should say:

   [Deutsch96] Deutsch, P., "DEFLATE Compressed Data Format
               Specification version 1.3", RFC 1951, May 1996.

Notes:

the above reference (cited in Section 5) should appear.


RFC2396, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998

Note: This RFC has been obsoleted by RFC3986

Source of RFC: Legacy
Area Assignment: app

Errata ID: 450

Status: Verified
Type: Technical

Reported By: Carl Douglas
Date Reported: 2001-04-26

Section 3.4 says:

   The query component is a string of information to be interpreted by
   the resource.

      query         = *uric

   Within a query component, the characters ";", "/", "?", ":", "@",
   "&", "=", "+", ",", and "$" are reserved.

Notes:

Section 3.4, "Query Component", of RFC 2396 (URI syntax) refers to the
"/" character as being reserved.

Reserving this character creates an inconsistency for some of today's
web servers, which confuse part of the Query Component as being part of
the Path Component when the "/" character is present in the Query
Component.

The "/" character should only be permitted in the Path Component of a
URI, and elsewhere in the URI it should be escaped by using it's hex
value.


Errata ID: 451

Status: Verified
Type: Technical

Reported By: Marc Warne
Date Reported: 2002-09-18

Section 1.2 says:

   A URN differs from a URL in that it's primary purpose is persistent
   labeling of a resource with an identifier.

It should say:

   A URN differs from a URL in that its primary purpose is persistent
   labeling of a resource with an identifier.


Errata ID: 452

Status: 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: 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


RFC2397, "The "data" URL scheme", August 1998

Source of RFC: Legacy

Errata ID: 2009

Status: Verified
Type: Technical

Reported By: Alexander Gebel
Date Reported: 2010-01-18
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-11

Section 4 says:

data:text/plain;charset=iso-8859-7,%be%fg%be

It should say:

data:text/plain;charset=iso-8859-7,%be%d3%be

Notes:

The given hex encoding "%fg" is incorrect, because there is no hexadecimal digit "g" ("f" is last). A correct hex encoding of any character is permissible here.


Errata ID: 2045

Status: Verified
Type: Technical

Reported By: Julian Reschke
Date Reported: 2010-02-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-11

Section 3 says:

3. Syntax


       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *urlchar
       parameter  := attribute "=" value

   where "urlchar" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

It should say:

3. Syntax


       dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
       mediatype  := [ type "/" subtype ] *( ";" parameter )
       data       := *uric
       parameter  := attribute "=" value

   where "uric" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

Notes:

"urlchar" is not defined in RFC2396, but "uric" is (which I think is what was supposed to be used).


RFC2407, "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998

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.


RFC2417, "Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks", September 1998

Source of RFC: Legacy

Errata ID: 448

Status: Verified
Type: Technical

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


RFC2421, "Voice Profile for Internet Mail - version 2", September 1998

Note: This RFC has been obsoleted by RFC3801

Source of RFC: Legacy
Area Assignment: app

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).


RFC2426, "vCard MIME Directory Profile", September 1998

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!


RFC2445, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", November 1998

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

Examples in various sections (2.4, 2.4.18, etc.)

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas, NV, USA
[...]

     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management
[...]
     ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
[...]
     LOCATION:Conference Room - F123, Bldg. 002

     LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
      Conference Room - F123, Bldg. 002
[...]

      Atlanta, Georgia END:VEVENT END:VCALENDAR
[...]
     CATEGORY:Project Report, XYZ, Weekly Meeting

[...]
      Participants: John Smith, Jane Doe, Jim Dandy\n-It was

It should say:

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas\, NV\, USA
[...]

     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview\, (b) Finances\, (c) Project Management
[...]
     ORGANIZER;SENT-BY="mailto:sray@host.com":mailto:jsmith@host.com
[...]
     LOCATION:Conference Room - F123\, Bldg. 002

     LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
      Conference Room - F123\, Bldg. 002
[...]

      Atlanta\, Georgia END:VEVENT END:VCALENDAR
[...]
     CATEGORIES:Project Report,XYZ,Weekly Meeting

[...]
      Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was

Notes:

This report comes from the following diff.

The following diff on RFC 2445 as archived also incorporates the
change to Section 4.2.18 reported by Tilghman Lesher on 2003-01-12.

960c960
< Conference - - Las Vegas, NV, USA
- ---
> Conference - - Las Vegas\, NV\, USA
1027c1027
< Market Overview, (b) Finances, (c) Project Management
- ---
> Market Overview\, (b) Finances\, (c) Project Management
1664c1664
< ORGANIZER;SENT-BY:"mailto:sray@host.com":mailto:jsmith@host.com
- ---
> ORGANIZER;SENT-BY="mailto:sray@host.com":mailto:jsmith@host.com
4699c4699
< LOCATION:Conference Room - F123, Bldg. 002
- ---
> LOCATION:Conference Room - F123\, Bldg. 002
4702c4702
< Conference Room - F123, Bldg. 002
- ---
> Conference Room - F123\, Bldg. 002
7626c7626
< Atlanta, Georgia END:VEVENT END:VCALENDAR
- ---
> Atlanta\, Georgia END:VEVENT END:VCALENDAR
7760c7760
< CATEGORY:Project Report, XYZ, Weekly Meeting
- ---
> CATEGORIES:Project Report,XYZ,Weekly Meeting
7763c7763
< Definition
- ---
> Definition
7765c7765
< Participants: John Smith, Jane Doe, Jim Dandy\n-It was
- ---
> Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was


Errata ID: 434

Status: Verified
Type: Editorial

Reported By: Ryan King
Date Reported: 2005-10-10
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-01

Section 4.2.7 says:

    Example:

      ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
       CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
       qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
       <...remainder of "BASE64" encoded binary data...>

It should say:

    Example:

      ATTACH;FMTTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
               ^
       CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
       qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
       <...remainder of "BASE64" encoded binary data...>

Notes:

Typo in FMTTYPE.


Errata ID: 640

Status: Verified
Type: Editorial

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: 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.


RFC2453, "RIP Version 2", November 1998

Source of RFC: ripv2 (rtg)

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: 3437

Status: Verified
Type: Editorial

Reported By: Bharat Joshi
Date Reported: 2012-12-26
Verifier Name: Adrian Farrel
Date Verified: 2013-05-06

Section 3.9.1 says:

   There is one special case.  If there is exactly
   one entry in the request, and it has an address family identifier of
   zero and a metric of infinity (i.e., 16), then this is a request to
   send the entire routing table.


It should say:

   There is one special case. If there is exactly
   one entry in the request, (in addition to any authentication entry)
   and it has an address family identifier of zero and a metric of
   infinity (i.e., 16), then this is a request to send the entire 
   routing table.

Notes:

Note that in RFC 2453 an authentication header is not considered to be an RTE.

There was obviously some confusion on this point and the additional parenthetic text clarifies that if an authentication entry is also present (as the first entry) then it is not included in the special case described in section 3.9.1.


RFC2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999

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


RFC2462, "IPv6 Stateless Address Autoconfiguration", December 1998

Note: This RFC has been obsoleted by RFC4862

Source of RFC: ipngwg (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.

RFC2464, "Transmission of IPv6 Packets over Ethernet Networks", December 1998

Source of RFC: ipngwg (int)

Errata ID: 430

Status: Verified
Type: Technical

Reported By: Peter Koch
Date Reported: 2004-04-29

The URL in this reference is incorrect:

   [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
           http://standards.ieee.org/db/oui/tutorials/EUI64.html

It should say:

   [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
           http://standards.ieee.org/regauth/oui/tutorials/EUI64.html


RFC2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", December 1998

Source of RFC: diffserv (tsv)

Errata ID: 3279

Status: Verified
Type: Technical

Reported By: Brian Carpenter
Date Reported: 2012-07-04
Verifier Name: Martin Stiemerling
Date Verified: 2012-07-12

Section Header says:

-

It should say:

Updates: 791

Notes:

RFC 2474 obsoletes RFC 1349. However, RFC 1349 updates RFC 791, by changing the definition of the Type of Service octet. RFC 2474 changes it again. Therefore, 2474 should also be marked as updating 791.

This does lead to occasional confusion, since the Type of Service octet is named as the Differentiated Services Field by RFC 2474.


RFC2486, "The Network Access Identifier", January 1999

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


RFC2489, "Procedure for Defining New DHCP Options", January 1999

Note: This RFC has been obsoleted by RFC2939

Source of RFC: dhc (int)

Errata ID: 855

Status: Verified
Type: Editorial

Reported By: Frank Ellermann
Date Reported: 2007-02-02
Verifier Name: Brian Haberman
Date Verified: 2012-07-24

Section 4 says:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2142, November 1997.

It should say:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2242, November 1997.

Notes:

References to RFC 2142 should be to 2242.

from pending


RFC2518, "HTTP Extensions for Distributed Authoring -- WEBDAV", February 1999

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


RFC2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", March 1999

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.


RFC2544, "Benchmarking Methodology for Network Interconnect Devices", March 1999

Source of RFC: Legacy
Area Assignment: ops

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: 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: 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.


RFC2548, "Microsoft Vendor-specific RADIUS Attributes", March 1999

Source of RFC: radius (ops)

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.


RFC2557, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", March 1999

Source of RFC: mhtml (app)

Errata ID: 418

Status: Verified
Type: Technical

Reported By: Les Kramer
Date Reported: 2001-01-07

In the reference:

   [REL]           Levinson, E., "The MIME Multipart/Related Content-
                   Type", RFC 2389, August 1998.

Notes:

The RFC number cited is incorrect; it should be RFC 2387.


Errata ID: 419

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 4.2 says:

resolution of relative URIs). However, URI-s in Content-Location
headers (if absolute, or resolvable to absolute URIs) SHOULD still
be

It should say:

resolution of relative URIs). However, URIs in Content-Location
headers (if absolute, or resolvable to absolute URIs) SHOULD still be

Errata ID: 645

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.2 says:

Content-Type: multipart/related; boundary="boundary-example";
       type="text/html"; start="<foo3@foo1@bar.net>"

--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>

It should say:

Content-Type: multipart/related; boundary="boundary-example";
       type="text/html"; start="<foo3.foo1@bar.net>"

--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3.foo1@bar.net>

Notes:




Errata ID: 646

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.3 says:

Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading

It should say:

Content-Location: images/ietflogo2.gif
Comments: Note - Relative Content-Location is resolved by base
specified in the Multipart/Related Content-Location heading

Errata ID: 647

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.3 says:

Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading

It should say:

Content-Location: images/ietflogo2.gif
Comments: Note - Relative Content-Location is resolved by base
specified in the Multipart/Related Content-Location heading

Errata ID: 648

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-ID: <foo3@foo1@bar.net>

It should say:

Content-ID: <foo3.foo1@bar.net>

Errata ID: 649

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-Type: multipart/related; boundary="boundary-example-2";
          type="text/html"
--boundary-example-2

It should say:

Content-Type: multipart/related; boundary="boundary-example-2";
          type="text/html"

--boundary-example-2

Notes:



Errata ID: 650

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-ID: <foo4@foo1@bar.net>

It should say:

Content-ID: <foo4.foo1@bar.net>

Notes:



Errata ID: 651

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-21

Section 9.6 says:

Content-Type: multipart/related; boundary="boundary-example-3";
          type="text/html"
--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4@foo@bar.net>

It should say:

Content-Type: multipart/related; boundary="boundary-example-3";
          type="text/html"

--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4.foo@bar.net>


Notes:




RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC6960

Source of RFC: pkix (sec)

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"


Errata ID: 3417

Status: Verified
Type: Editorial

Reported By: John Soltes
Date Reported: 2012-11-26
Verifier Name: Sean Turner
Date Verified: 2012-11-26

Section 4.2.2.2 says:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-ad-ocspSigning value as
described above.

and

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage

It should say:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-kp-OCSPSigning value as
described above.

and

3. Includes a value of id-kp-ocspSigning in an ExtendedKeyUsage

Notes:

The first paragraph specifies that an "id-kp-OCSPSigning" value be included, and it then defines that value as "id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed alternative specify the use of an "id-ad-ocspSigning" value, which is not defined.

Also, the double quote mark at the end of the third listed alternative should be removed.


RFC2579, "Textual Conventions for SMIv2", April 1999

Source of RFC: Legacy

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: 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: 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:



RFC2581, "TCP Congestion Control", April 1999

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:



RFC2585, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", May 1999

Source of RFC: pkix (sec)

Errata ID: 1831

Status: Verified
Type: Technical

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.


RFC2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999

Source of RFC: http (app)

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: 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: 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'.



RFC2617, "HTTP Authentication: Basic and Digest Access Authentication", June 1999

Source of RFC: http (app)

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: 1649

Status: Verified
Type: Technical

Reported By: Ganga Mahesh Siddem
Date Reported: 2009-01-08
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-21

Section 5 says:

 /* calculate H(A1) as per spec */
      void DigestCalcHA1(
          IN char * pszAlg,
          IN char * pszUserName,
          IN char * pszRealm,
          IN char * pszPassword,
          IN char * pszNonce,
          IN char * pszCNonce,
          OUT HASHHEX SessionKey
          )
      {
            MD5_CTX Md5Ctx;
            HASH HA1;

            MD5Init(&Md5Ctx);
            MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
            MD5Final(HA1, &Md5Ctx);
            if (stricmp(pszAlg, "md5-sess") == 0) {
                  MD5Init(&Md5Ctx);
|                 MD5Update(&Md5Ctx, HA1, HASHLEN);
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
                  MD5Final(HA1, &Md5Ctx);
            };
            CvtHex(HA1, SessionKey);
      };

It should say:

 /* calculate H(A1) as per spec */
      void DigestCalcHA1(
          IN char * pszAlg,
          IN char * pszUserName,
          IN char * pszRealm,
          IN char * pszPassword,
          IN char * pszNonce,
          IN char * pszCNonce,
          OUT HASHHEX SessionKey
          )
      {
            MD5_CTX Md5Ctx;
            HASH HA1;
|           HASHHEX HA1Hex;

            MD5Init(&Md5Ctx);
            MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
            MD5Update(&Md5Ctx, ":", 1);
            MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
            MD5Final(HA1, &Md5Ctx);
            if (stricmp(pszAlg, "md5-sess") == 0) {
|                 CvtHex(HA1, HA1Hex);
                  MD5Init(&Md5Ctx);
|                 MD5Update(&Md5Ctx, HA1Hex, HASHHEXLEN);
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
                  MD5Update(&Md5Ctx, ":", 1);
                  MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
                  MD5Final(HA1, &Md5Ctx);
            };
            CvtHex(HA1, SessionKey);
      };

Notes:

DigestCalcHA1 sample implemention has to be corrected.


Errata ID: 1959

Status: Verified
Type: Technical

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: 3720

Status: Verified
Type: Technical

Reported By: Brett Tate
Date Reported: 2013-09-06
Verifier Name: Barry Leiba
Date Verified: 2013-09-06

Section 3.2.2.4 says:

username="Mufasa", realm=myhost@testrealm.com

It should say:

username="Mufasa", realm="myhost@testrealm.com"

Notes:

The realm value within the Authorization header example is missing the quotes.


Errata ID: 606

Status: Verified
Type: Editorial

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)"...


RFC2625, "IP and ARP over Fibre Channel", June 1999

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


RFC2626, "The Internet and the Millennium Problem (Year 2000)", June 1999

Source of RFC: 2000 (ops)

Errata ID: 2753

Status: Verified
Type: Editorial

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-25
Verifier Name: Ron Bonica
Date Verified: 2011-03-26

Section 3.6 says:

3.6 "Network News"


   There does exist a problem in both NNTP, RFC 977, and the Usenet News
   Message Format, RFC 10336.  They both specify two-digit year format.
   A working group has been formed to update the network news protocols
   in general, and addressing this problem is on their list of work
   items.

It should say:

3.6 "Network News"


   There does exist a problem in both NNTP, RFC 977, and the Usenet News
   Message Format, RFC 1036.  They both specify two-digit year format.
   A working group has been formed to update the network news protocols
   in general, and addressing this problem is on their list of work
   items.

Notes:

s/RFC 10336/RFC 1036


RFC2630, "Cryptographic Message Syntax", June 1999

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.


RFC2631, "Diffie-Hellman Key Agreement Method", June 1999

Source of RFC: smime (sec)

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.


RFC2633, "S/MIME Version 3 Message Specification", June 1999

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.


RFC2645, "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", August 1999

Source of RFC: Legacy
Area Assignment: app

Errata ID: 404

Status: Verified
Type: Technical

Reported By: Tony Finch
Date Reported: 2005-08-30
Verifier Name: Barry Leiba
Date Verified: 2012-05-17

Section 5.2.1 says:

   If the authentication used by the customer does not provide access to
   all of the domains specified in ATRN, the provider MUST NOT send mail
   for any domains to the customer; the provider MUST reject the ATRN
   command with a 450 code.

It should say:

   If the authentication used by the customer does not provide access to
   all of the domains specified in ATRN, the provider MUST NOT send mail
   for any domains to the customer; the provider MUST reject the ATRN
   command with a 550 code.

Notes:

This seems to be contrary to SMTP's theory of reply codes:

A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)

If the ODMR client repeats the ATRN request in this situation, it will be rejected again. So a 550 response would be more appropriate.


RFC2648, "A URN Namespace for IETF Documents", August 1999

Source of RFC: urn (app)

Errata ID: 3145

Status: Verified
Type: Technical

Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02

Section A.2 says:

      print "Status:  302 Moved temporarily0;

It should say:

      print "Status:  302 Moved temporarily";

Notes:

might be both editorial and technical error (typo, causing the Perl code invalid)


Errata ID: 3146

Status: Verified
Type: Technical

Reported By: Michal Bozon
Date Reported: 2012-03-02
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-02

Section A.3 says:

    if ($accept =~ /text\/uri-list/) { #look for text/uri-list,
        otherwise text/html

It should say:

    if ($accept =~ /text\/uri-list/) {
        # look for text/uri-list, otherwise text/html

Notes:

Appears 4 times in the same section. Might be both editorial and technical error (forced line break in the middle of the comment, making the Perl code invalid)


RFC2655, "CIP Index Object Format for SOIF Objects", August 1999

Source of RFC: find (app)

Errata ID: 403

Status: Verified
Type: Technical

Reported By: Kang-Jin Lee
Date Reported: 2002-09-04

Section 8 says:

   [2]  The Harvest Information Discovery and Access System:
        <URL:http://harvest.transarc.com/>

It should say:

   [2]  Harvest: A distributed Search System:
        <URL:http://harvest.sourceforge.net/>


RFC2656, "Registration Procedures for SOIF Template Types", August 1999

Source of RFC: find (app)

Errata ID: 402

Status: Verified
Type: Technical

Reported By: Kang-Jin Lee
Date Reported: 2002-09-04

Section 5 says:

   [2]  The Harvest Information Discovery and Access System:
        <URL:http://harvest.transarc.com/>

It should say:

   [2]  Harvest: A distributed Search System:
        <URL:http://harvest.sourceforge.net/>


RFC2661, "Layer Two Tunneling Protocol "L2TP"", August 1999

Source of RFC: pppext (int)

Errata ID: 401

Status: Verified
Type: Technical

Reported By: Ming Deng
Date Reported: 2007-03-17

Section 3 says:

SSHTRESH

It should say:

SSTHRESH

Notes:

Occurs 3 times.

from pending


RFC2663, "IP Network Address Translator (NAT) Terminology and Considerations", August 1999

Source of RFC: nat (tsv)

Errata ID: 400

Status: Verified
Type: Technical

Reported By: Javier Waisbrot
Date Reported: 2002-11-14

Section 2.6 says:

   the NAT device cannot safely assume that the segments containing
   FINs or SYNs will be the last packets of the session (i.e., there
   could be retransmissions).

It should say:

   the NAT device cannot safely assume that the segments containing
   FINs or RSTs will be the last packets of the session (i.e., there
   could be retransmissions).


RFC2673, "Binary Labels in the Domain Name System", August 1999

Note: This RFC has been obsoleted by RFC6891

Source of RFC: dnsind (int)

Errata ID: 1679

Status: Verified
Type: Technical

Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section headers says:

(none)

It should say:

Updates: 1035

Notes:

This document introduces a type of label not explicitly anticipated in the core DNS documents. Not having an "updating" entry that threads it back to 1035 (or 1034) makes this specification hard to find and likely to be omitted from any compendium or overview of DNS specifications.

The situation is obviously a little complicated by our usual difficulties in updating full standards from documents that are earlier on the standards track or not on the standards track at all. 2673 was published (in 1999) as a Proposed Standard, making an intention to update 1035 well within the rules. A suggestion then appears to in 3363 (published in 2002) to change it to Experimental, but, since 3363 is itself Informational, it clearly did make that change. I can find no record of an explicit IESG action making it, but such records are hard to find. For completeness (of the confusion), RFC 3364 is also listed as updating 2673, but not only is it also Informational, it doesn't even reference 2673 -- one has to deduce the relationship to 2673 by making an inference from the discussion of 2874.

Obviously, while the erratum, and probably one for 1034 with a forward pointer to 2673, should be recorded, the key problem can be fixed by updating the rfc-index and its various clones.

An alternative, which clearly requires IESG and DNSEXT involvement (the above suggestion may or may not do so) is to decide that, after nearly a decade of presumed experience with 2673, either it is useful for something (even if not IPv6 reverse mapping) or that ten years is enough and it isn't worth the trouble. If it is useful, it should be put it back on the standards track, presumably with an applicability statement about what it is useful for. If it is not, it is time to make it Historic. Either decision would clear up the questions of its status vis-a-vis introduction of new label types and updating 1035.


RFC2676, "QoS Routing Mechanisms and OSPF Extensions", August 1999

Source of RFC: ospf (rtg)

Errata ID: 399

Status: Verified
Type: Technical

Reported By: Jussi Savolainen
Date Reported: 2002-07-09

Section 3.2.1 says:

    0       8       16
    |       |       |
    -----------------
   |EXP| MANT        |
    -----------------

It should say:

    0       8       15
    |       |       |
    -----------------
   |EXP| MANT        |
    -----------------


RFC2680, "A One-way Packet Loss Metric for IPPM", September 1999

Source of RFC: ippm (tsv)

Errata ID: 1528

Status: Verified
Type: Technical

Reported By: Wenxia Dong
Date Reported: 2008-09-24
Verifier Name: Lars Eggert
Date Verified: 2009-05-14

Section 2.7 says:

The first two sources are interrelated and could result in a test
packet with finite delay being reported as lost.  Type-P-One-way-
Packet-Loss is 0 if the test packet does not arrive, or if it does
arrive and the difference between Src timestamp and Dst timestamp is
greater than the "reasonable period of time", or loss threshold.  

It should say:

The first two sources are interrelated and could result in a test
packet with finite delay being reported as lost.  Type-P-One-way-
Packet-Loss is 1 if the test packet does not arrive, or if it does
arrive and the difference between Src timestamp and Dst timestamp is
greater than the "reasonable period of time", or loss threshold.

Notes:

Type-P-One-way-Packet-Loss is 1 if the test packet does not arrive, according to section 2.4 Definition in RFC2680.


RFC2683, "IMAP4 Implementation Recommendations", September 1999

Source of RFC: Legacy

Errata ID: 3129

Status: Verified
Type: Technical

Reported By: Karl Fenech
Date Reported: 2012-02-19
Verifier Name: Pete Resnick
Date Verified: 2012-03-29

Section 3.2.1.3 says:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20001.20000>
       S: * 3 FETCH (BODY[1]<20001> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40001.20000>
       ...etc...

It should say:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS (\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20000.20000>
       S: * 3 FETCH (BODY[1]<20000> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40000.20000>
       ...etc...

Notes:

The main erratum is an off-by-one error. The starting index of an IMAP partial body fetch is zero-based. A request for BODY[1]<0.20000> would fetch octets 0 to 19999 (inclusive). A request for BODY[1]<20001.20000> would fetch octets 20001 to 40000 (inclusive). As a consequence, octet 2000 is skipped in the original suggested implementation, with the strong possibility of leading to data corruption if the message body is reconstructed by concatenating the retrieved substrings.

There is a secondary erratum: There should be a mandatory space between the "FLAGS" string and the parenthesized list of flags. Refer to the definition for msg-att-dynamic in the Formal Syntax of RFC 3501.


RFC2731, "Encoding Dublin Core Metadata in HTML", December 1999

Note: This RFC has been obsoleted by RFC5791

Source of RFC: Legacy
Area Assignment: app

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/>).


RFC2732, "Format for Literal IPv6 Addresses in URL's", December 1999

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


RFC2737, "Entity MIB (Version 2)", December 1999

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


RFC2740, "OSPF for IPv6", December 1999

Note: This RFC has been obsoleted by RFC5340

Source of RFC: ospf (rtg)

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: 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: 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                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



RFC2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000

Source of RFC: pppext (int)

Errata ID: 391

Status: Verified
Type: Technical

Reported By: Andrew Roughan
Date Reported: 2002-08-26

Section 9.3 says:

  0-to-256-unicode-char Password:
  4D 79 50 77

  16-octet PasswordHash:
  FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC

It should say:

  0-to-256-char Password:
  4D 79 50 77

  0-to-256-unicode-char NtPassword:
  4D 00 79 00 50 00 77 00

  16-octet NtPasswordHash:
  FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC


Errata ID: 1924

Status: Verified
Type: Technical

Reported By: Alexey Melnikov
Date Reported: 2009-10-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-09

Section 8.3 says:

   NtPasswordHash(
   IN  0-to-256-unicode-char Password,
   OUT 16-octet              PasswordHash )
   {
      /*
       * Use the MD4 algorithm [5] to irreversibly hash Password
       * into PasswordHash.  Only the password is hashed without
       * including any terminating 0.
       */
   }

It should say:

   NtPasswordHash(
   IN  0-to-256-unicode-char Password,
   OUT 16-octet              PasswordHash )
   {
      /*
       * Use the MD4 algorithm [5] to irreversibly hash Password
       * encoded in UTF-16-LE into PasswordHash.
       * Only the password is hashed without
       * including any terminating 0.
       */
   }

Notes:

Section 8.3 is silent on Unicode encoding used for passwords.
Section 9.2 seem to imply that the Unicode encoding used in UTF-16-LE.


RFC2763, "Dynamic Hostname Exchange Mechanism for IS-IS", February 2000

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.


RFC2764, "A Framework for IP Based Virtual Private Networks", February 2000

Source of RFC: Legacy

Errata ID: 389

Status: Verified
Type: Technical

Reported By: Elena Taguer
Date Reported: 2001-02-01

There is a case of sections being numbered wrong:

   5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
   5.3.3.1 Routing Protocol Instance ............................... 31


RFC2784, "Generic Routing Encapsulation (GRE)", March 2000

Source of RFC: Legacy
Area Assignment: rtg

Errata ID: 3719

Status: Verified
Type: Technical

Reported By: C, . M. Heard
Date Reported: 2013-09-04
Verifier Name: Stewart Bryant
Date Verified: 2013-09-17

Section 2.3 and 5.2 says:

2.3. Reserved0 (bits 1-12)

   A receiver MUST discard a packet where any of bits 1-5 are non-zero,
   unless that receiver implements RFC 1701. Bits 6-12 are reserved for
   future use. These bits MUST be sent as zero and MUST be ignored on
   receipt.
...
5.2. RFC 1701 Compliant Transmitter

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 5.3, a packet
   with non-zero bits in any of bits 1-5 MUST be discarded unless the
   receiver implements RFC 1701.

It should say:

2.3. Reserved0 (bits 1-12)

   A receiver MUST discard a packet where any of bits 1-4 are non-zero,
   unless that receiver implements RFC 1701. Bits 5-12 are reserved for
   future use. These bits MUST be sent as zero and MUST be ignored on
   receipt.
...
5.2. RFC 1701 Compliant Transmitter

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 2.3, a packet
   with non-zero bits in any of bits 1-4 MUST be discarded unless the
   receiver implements RFC 1701.

Notes:

In the section entitled "Packet header," RFC 1701 defined the one-bit Routing Present, Key Present, Sequence Number Present, and Strict Source Route fields in bits 1-4 , the Recursion Control field in bits 5-7, and a Flags field in bits 8-12. It further stated that "[b]its 5 through 12 are reserved for future use and MUST be transmitted as zero." The language in RFC 2784 Section 5.2 makes it clear that incompatibilities between an RFC 1701 transmitter and an RFC 2784 receiver arise only when one or more of the the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits are set, i.e., when any of bits 1-4 are set.

Verifier's note: This looks like it was the intent of the authors, but the reader should note also RFC2890 which restores the K and S bits.


Errata ID: 1706

Status: Verified
Type: Editorial

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.


RFC2786, "Diffie-Helman USM Key Management Information Base and Textual Convention", March 2000

Source of RFC: Legacy

Errata ID: 388

Status: Verified
Type: Technical

Reported By: David Harrington
Date Reported: 2001-08-17

The title was mis-spelled:

   Diffie-Helman USM Key Management Information Base and Textual
   Convention 

It should say:

   Diffie-Hellman USM Key Management Information Base and Textual
   Convention


RFC2810, "Internet Relay Chat: Architecture", April 2000

Source of RFC: IETF - NON WORKING GROUP

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".


RFC2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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: 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: 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: 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: 3783

Status: Verified
Type: Technical

Reported By: Diman Todorov
Date Reported: 2013-11-05
Verifier Name: Barry Leiba
Date Verified: 2013-11-05

Section 2.3.1 says:

chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
chanstring =/ %x2D-39 / %x3B-FF

It should say:

chanstring = *49(%x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B /
             %x2D-39 / %x3B-FF)

Notes:

Unfortunately the text in 1.3 which elaborates the interpretation of this BNF rule is unclear as to whether it's permitted to have 0 chanstring characters. The total length of the "channel" construct is 50 characters, so no chanstring can ever be more than 49 characters... but not all 49 characters will always be available, depending upon how "channel" is constructed.

Note that errata 385 addresses the same rule but a different issue. Errata 385 has been taken into consideration in this correction.


Errata ID: 3255

Status: Verified
Type: Editorial

Reported By: Robrecht Dewaele
Date Reported: 2012-06-12
Verifier Name: Barry Leiba
Date Verified: 2012-06-13

Section 5. Replies says:

353    RPL_NAMREPLY
              "( "=" / "*" / "@" ) <channel>
               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
         - "@" is used for secret channels, "*" for private
           channels, and "=" for others (public channels).

It should say:

353    RPL_NAMREPLY
              "( "=" / "*" / "@" ) <channel>
               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )"
         - "@" is used for secret channels, "*" for private
           channels, and "=" for others (public channels).

Notes:

Missing double qoutes to end the reply string.


Errata ID: 3573

Status: Verified
Type: Editorial

Reported By: Matthew Helsley
Date Reported: 2013-03-29
Verifier Name: Barry Leiba
Date Verified: 2013-03-29

Section 5.1 says:

           returned.  The exception to this is when a NAMES
           message is sent with no parameters and all visible
           channels and contents are sent back in a series of
           RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
           the end.

It should say:

           returned.  The exception to this is when a NAMES
           message is sent with no parameters and all visible
           channels and contents are sent back in a series of
           RPL_NAMREPLY messages with a RPL_ENDOFNAMES to mark
           the end.

Notes:

RPL_NAMEREPLY should be RPL_NAMREPLY


RFC2813, "Internet Relay Chat: Server Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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

RFC2817, "Upgrading to TLS Within HTTP/1.1", May 2000

Source of RFC: tls (sec)

Errata ID: 1801

Status: Verified
Type: Technical

Reported By: Mark Nottingham
Date Reported: 2009-07-05
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 7.1 says:

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1 [1].

It should say:

     Values to be added to this name space are subject to IETF review
     ([12], Section 4.1).

(where [12] would refer to RFC 5226 in the References Section)

Notes:

Since RFC 2817 was published, it has become harder to publish non-WG
documents on the Standards Track. The "IETF review" policy is defined in
RFC 5226 as:

IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.

To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.

which should address this nicely.

Furthermore, overloading the "Updates" relation for specifications that
use a well-defined extension point plus an IANA registry is misleading.

Reviewed by the HTTPbis WG; see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>


RFC2821, "Simple Mail Transfer Protocol", April 2001

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: 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: 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: 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: 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.

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".


RFC2822, "Internet Message Format", April 2001

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.


RFC2834, "ARP and IP Broadcast over HIPPI-800", May 2000

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: int

Errata ID: 680

Status: Verified
Type: Editorial

Reported By: Sebastian Kulpa
Date Reported: 2002-03-24
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 6.3 says:

On page 19 :

Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

On page 20, there is :

Where :
     ar$hrd  - SHALL contain 28. (HIPARP)
     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).
     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK
     ar$pln  - SHALL contain 4.
     ar$rln  - SHALL contain 10 IF this is a HIPPI-800 HW address 
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$rha  - in requests and NAKs it SHALL contain the requester's
               HW address. In replies it SHALL contain the target
               port's HW address.
     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.
     ar$tha  - in requests and NAKs it SHALL contain the target's
               HW address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               HW addressA.
     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.

It should say:

On page 19 :

Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

On page 20, there is :

Where :
     ar$hrd  - SHALL contain 28. (HIPARP)
     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).
     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK
     ar$pln  - SHALL contain 4.
     ar$rhl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.
     ar$rha  - in requests and NAKs it SHALL contain the requester's
               HW address. In replies it SHALL contain the target
               port's HW address.
     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.
     ar$tha  - in requests and NAKs it SHALL contain the target's
               HW address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               HW addressA.
     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.

Notes:

The descriptive text references ar$rln rather than the correct ar$rhl.


RFC2839, "Internet Kermit Service", May 2000

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3700

Status: Verified
Type: Editorial

Reported By: Amanda Baber
Date Reported: 2013-08-20
Verifier Name: Barry Leiba
Date Verified: 2013-09-06

Section 6 says:

http://www.iana.org/assignment/port-numbers

It should say:

http://www.iana.org/assignments/port-numbers

RFC2846, "GSTN Address Element Extensions in E-mail Services", June 2000

Source of RFC: fax (app)

Errata ID: 371

Status: Verified
Type: Editorial

Reported By: RFC Editor
Date Reported: 2004-05-28

Section 8 says:

 global-phone = "+" 1*( DIGIT , written-sep )

It should say:

 global-phone = "+" 1*( DIGIT / written-sep )

RFC2861, "TCP Congestion Window Validation", June 2000

Source of RFC: tsvwg (tsv)

Errata ID: 1303

Status: Verified
Type: Editorial

Reported By: Sally Floyd
Date Reported: 2008-01-23
Verifier Name: Lars Eggert
Date Verified: 2009-02-16

Section 7 says:

None.

It should say:

[B97] Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

Notes:

Missing citation. Reported by Emmanuel Papirakis.


RFC2865, "Remote Authentication Dial In User Service (RADIUS)", June 2000

Source of RFC: radius (ops)

Errata ID: 368

Status: Verified
Type: Technical

Reported By: Aaron Webb
Date Reported: 2002-09-12

Section 5.18 says:

   Multiple Reply-Message's MAY be included and if any are displayed,
   they MUST be displayed in the same order as they appear in the
   packet.

It should say:

   Multiple Reply-Messages MAY be included and if any are displayed,
   they MUST be displayed in the same order as they appear in the
   packet.


Errata ID: 1469

Status: 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.


RFC2866, "RADIUS Accounting", June 2000

Source of RFC: radius (ops)

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: 3896

Status: Verified
Type: Editorial

Reported By: Andrew Kowal
Date Reported: 2014-02-18
Verifier Name: Benoit Claise
Date Verified: 2014-02-18

Section 3 says:

This memo documents the RADIUS Accounting protocol.  The early
deployment of RADIUS Accounting was done using UDP port number 1646,
which conflicts with the "sa-msg-port" service.  The officially
assigned port number for RADIUS Accounting is 1813.

Notes:

The whole 3rd paragraph of section 3 is a duplicate of "Implementation Note" section and is barely related to packet format description.


RFC2867, "RADIUS Accounting Modifications for Tunnel Protocol Support", June 2000

Source of RFC: radius (ops)

Errata ID: 367

Status: Verified
Type: Editorial

Reported By: Unai Pildain
Date Reported: 2005-05-31

Section 3.5 says:

            Acct-Multi-Session-Id (51)

It should say:

            Acct-Multi-Session-Id (50)

Notes:


RFC2868, "RADIUS Attributes for Tunnel Protocol Support", June 2000

Source of RFC: radius (ops)

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"


RFC2873, "TCP Processing of the IPv4 Precedence Field", June 2000

Source of RFC: Legacy

Errata ID: 366

Status: Verified
Type: Technical

Reported By: Kurt D. Zeilenga
Date Reported: 2001-11-06

In the References Section:

   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2587, June 1999.

It should say:

   [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
             "Assured Forwarding PHB Group", RFC 2597, June 1999.


RFC2876, "Use of the KEA and SKIPJACK Algorithms in CMS", July 2000

Source of RFC: smime (sec)

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.


RFC2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", July 2000

Source of RFC: tsvwg (tsv)

Errata ID: 365

Status: Verified
Type: Editorial

Reported By: Noritoshi Demizu
Date Reported: 2004-06-21

Section 4.2.3 says:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

         500-999        500-999     1000
         1000-1499      (data packet dropped)
         1500-1999      (delayed)
         2000-2499      (data packet dropped)
         2500-2999      (delayed)
         3000-3499      (data packet dropped)
         3500-3999      3500-3999   1000, SACK=3500-4000
         1000-1499      (data packet dropped)
         1500-2999      1500-1999   1000, SACK=1500-2000, 3500-4000
                        2000-2499   1000, SACK=2000-2500, 1500-2000,
                                            3500-4000
                        1500-2999   1000, SACK=1500-2000, 1500-3000,
                                               ---------
                                            3500-4000

It should say:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

         500-999        500-999     1000
         1000-1499      (data packet dropped)
         1500-1999      (delayed)
         2000-2499      (data packet dropped)
         2500-2999      (delayed)
         3000-3499      (data packet dropped)
         3500-3999      3500-3999   1000, SACK=3500-4000
         1000-1499      (data packet dropped)
         1500-2999      1500-1999   1000, SACK=1500-2000, 3500-4000
                        2500-2999   1000, SACK=2500-3000, 1500-2000,
                                            3500-4000
                        1500-2999   1000, SACK=1500-2000, 1500-3000,
                                               ---------
                                            3500-4000

RFC2911, "Internet Printing Protocol/1.1: Model and Semantics", September 2000

Source of RFC: ipp (app)

Errata ID: 364

Status: Verified
Type: Technical

Reported By: Tom Hastings
Date Reported: 2002-07-17

Section 13 says:

"redirection" - 0x0200 to 0x02FF

It should say:

"redirection" - 0x0300 to 0x03FF

Errata ID: 694

Status: Verified
Type: Technical

Reported By: Tom Hastings
Date Reported: 2002-07-17

Section 13, Appendix B says:

The top half (128 values) of each range (0x0n40 to 0x0nFF, for 
n = 0 to 5) is reserved for vendor use within each status code
class. 

It should say:

The top half (128 values) of each range (0x0n80 to 0x0nFF, for 
n = 0 to 5) is reserved for vendor use within each status code
class.   

Notes:





Errata ID: 3365

Status: Verified
Type: Technical

Reported By: Michael Sweet
Date Reported: 2012-09-25
Verifier Name: Barry Leiba
Date Verified: 2012-10-01

Section 4.1.2.2 says:

4.1.2.2 'nameWithLanguage'

   The 'nameWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'nameWithoutLanguage' part encoded
   in a maximum of 1023 (MAX) octets plus an additional

It should say:

4.1.2.2 'nameWithLanguage'

   The 'nameWithLanguage' attribute syntax is a compound attribute
   syntax consisting of two parts: a 'nameWithoutLanguage' part (see
   Section 4.1.2.1) plus an additional

Notes:

The maximum length of the nameWithoutLanguage value (section 4.1.2.1) is 255 octets, not 1023. Better to just do it by reference, rather than by repeating the information.


RFC2916, "E.164 number and DNS", September 2000

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.


RFC2919, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", March 2001

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3951

Status: Verified
Type: Technical

Reported By: Peter Occil
Date Reported: 2014-04-03
Verifier Name: Pete Resnick
Date Verified: 2014-04-04

Section 3 says:

   The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

It should say:

   The syntax of the List-Id header follows:

   list-id-header = "List-ID:" [phrase / CFWS] "<" list-id ">" CRLF

Notes:

This change is needed to conform with the second and fifth examples
given just after the syntax definition. Without it, the case "List-ID: <list.example.com>" (with a space after "List-ID:") would not be valid; only "List-ID:<list.example.com>" (without a space) would be, especially since it states that "the List-Id header does not allow free insertion of whitespace and comments around tokens."


RFC2925, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", September 2000

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)."


RFC2927, "MIME Directory Profile for LDAP Schema", September 2000

Source of RFC: schema (app)

Errata ID: 359

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-01-04

Section 3 says:

   Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8"
   Content-Transfer-Encoding: Quoted-Printable
   ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =
   ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =
   1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )

It should say:

   Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8"
   Content-Transfer-Encoding: Quoted-Printable
   
   ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =
   ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =
   1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )


RFC2938, "Identifying Composite Media Features", September 2000

Source of RFC: conneg (app)

Errata ID: 1080

Status: Verified
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2007-11-19
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-03

Section 4 says:

(h.QGEOPMCF02P09QC016CEPU22FO)
where
(h.QGEOPMCF02P09QC016CEPU22FO) :-
 (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MH) )
    (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MR) )
    (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) )
    (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)

       (color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end

It should say:

(h.U965DKFHDGT0344VRHI6OONIBS)
where
(h.U965DKFHDGT0344VRHI6OONIBS) :-
 (| (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MH) )
    (& (ua-media=continuous) (dpi=200) (dpi-xyratio=200/100)
       (color=Binary) (paper-size=B4) (image-coding=MR) )
    (& (ua-media=stationery) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) )
    (& (ua-media=transparency) (dpi=300) (dpi-xyratio=1)
       (color=Binary) (paper-size=A4) (image-coding=JBIG) ) )
end

Notes:

In an MD5 test suite the other three RFC 2938 examples work as expected


RFC2939, "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", September 2000

Source of RFC: dhc (int)

Errata ID: 358

Status: Verified
Type: Technical

Reported By: Tyler Tidman
Date Reported: 2001-09-04

Section 1 says:

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 51).

It should say:

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 53).


Errata ID: 854

Status: Verified
Type: Editorial

Reported By: Frank Ellermann
Date Reported: 2007-02-02
Verifier Name: Brian Haberman
Date Verified: 2012-07-24

Section 4 says:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2142, November 1997.

It should say:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2242, November 1997.

Notes:

References to RFC 2142 should be to 2242.

from pending


RFC2965, "HTTP State Management Mechanism", October 2000

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.


RFC2978, "IANA Charset Registration Procedures", October 2000

Source of RFC: Legacy

Errata ID: 357

Status: Verified
Type: Technical

Reported By: Ned Freed
Date Reported: 2003-02-09
Report Text:

(1) All references in RFC 2978 to RFC 2184 should be replaced by RFC
    2231.  RFC 2231 obsoleted RFC 2184 before RFC 2978 was published.

(2) The fact that vertical bar and backslash characters are now
    excluded from charset names was a change from RFC 2278 that should
    have been noted in section 7.


Errata ID: 1912

Status: Verified
Type: Technical

Reported By: Ned Freed
Date Reported: 2009-10-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-10-15

Section 2.3 says:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "'" / "+" / "-" / "^" / "_" /
            "`" / "{" / "}" / "~"
    

It should say:

mime-charset-chars = ALPHA / DIGIT /
            "!" / "#" / "$" / "%" / "&" /
            "+" / "-" / "^" / "_" / "`" /
            "{" / "}" / "~"

Notes:

RFC 2231 uses single quotes as delimiters around charset names. As such, single quote should have been excluded from the list of legal characters that can appear in a charset name.


RFC2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 356

Status: Verified
Type: Technical

Reported By: Robert Moskowitz
Date Reported: 2000-12-13

The Table of Contents says:

5.6  Attributes defined in S/MIMIE .............................. 18

It should say:

5.6  Attributes defined in S/MIME ..............................  18


RFC2988, "Computing TCP's Retransmission Timer", November 2000

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.


RFC3003, "The audio/mpeg Media Type", November 2000

Source of RFC: Legacy

Errata ID: 355

Status: Verified
Type: Technical

Reported By: Colin Perkins
Date Reported: 2000-11-22

 

   * NOTE: The audio/MPS mime type is in use in addition to the
   audio/mpeg. 

It should say:

   * NOTE: The audio/MPA mime type is in use in addition to the
   audio/mpeg. 


RFC3010, "NFS version 4 Protocol", December 2000

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.


RFC3015, "Megaco Protocol Version 1.0", November 2000

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"


RFC3023, "XML Media Types", January 2001

Source of RFC: Legacy

Errata ID: 352

Status: Verified
Type: Technical

Reported By: Murata Makoto
Date Reported: 2003-05-09

Section 8.13 says:

   {BOM}<?xml encoding="utf-16"?>

   or

   {BOM}<?xml?>

It should say:

   {BOM}<?xml encoding="utf-16"?>


RFC3024, "Reverse Tunneling for Mobile IP, revised", January 2001

Source of RFC: mobileip (int)

Errata ID: 351

Status: Verified
Type: Technical

Reported By: Gabriel Montenegro
Date Reported: 2003-06-02

Section 4.3.1 says:

    Upon receipt of a Registration Reply that satisfies validity
    checks,

It should say:

    Upon receipt of a Registration Request that satisfies validity
    checks,


RFC3028, "Sieve: A Mail Filtering Language", January 2001

Note: This RFC has been obsoleted by RFC5228 RFC5429

Source of RFC: Legacy
Area Assignment: app

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.


RFC3030, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", December 2000

Source of RFC: Legacy

Errata ID: 349

Status: Verified
Type: Technical

Reported By: Emmanuel Papirakis
Date Reported: 2003-01-14

Section 4.2 says:

   The following dialogue illustrates the use of the large message
   extension to send a BINARYMIME object to two recipients using the
   CHUNKING and PIPELINING extensions:

   R: 
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING
   S: MAIL FROM: BODY=BINARYMIME
   S: RCPT TO:
   S: RCPT TO:
   R: 250 ... Sender and BINARYMIME ok
   R: 250 ... Recipient ok
   R: 250 ... Recipient ok
   S: BDAT 100000
   S: (First 10000 octets of canonical MIME message data)

Notes:

You can see the last line is missing a 0.


RFC3031, "Multiprotocol Label Switching Architecture", January 2001

Source of RFC: mpls (rtg)

Errata ID: 348

Status: Verified
Type: Editorial

Reported By: John Kristoff
Date Reported: 2005-03-01

Section 2.3 says:

   LDP                       Label Distribution Protocol
   L2                        Layer 2 L3                        Layer 3
   LSP                       Label Switched Path

It should say:

   LDP                       Label Distribution Protocol
   L2                        Layer 2 
   L3                        Layer 3
   LSP                       Label Switched Path

Notes:

there is a missing CR/LF


Errata ID: 696

Status: Verified
Type: Editorial

Reported By: John Kristoff
Date Reported: 2005-03-01

Section 3.20 says:

For example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the the traffic 
to the egress node. 

It should say:

For example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the traffic 
to the egress node. 

Notes:

Notice the double 'the'.


Errata ID: 1893

Status: Verified
Type: Editorial

Reported By: Dande Rajasekhar
Date Reported: 2009-09-24
Verifier Name: Ross Callon
Date Verified: 2009-09-29

Section 4.1.6 says:

It is important to note that if Ru and Rd are adjacent LSRs in an LSP
   for X1 and X2, forwarding will still be done correctly if Ru assigns
   distinct labels to X1 and X2 while Rd assigns just one label to the
   both of them.  This just means that R1 will map different incoming
   labels to the same outgoing label, an ordinary occurrence.

It should say:

It is important to note that if Ru and Rd are adjacent LSRs in an LSP
   for X1 and X2, forwarding will still be done correctly if Ru assigns
   distinct labels to X1 and X2 while Rd assigns just one label to the
   both of them.  This just means that Rd will map different incoming
   labels to the same outgoing label, an ordinary occurrence.

Notes:

R1 should be replaced by Rd since there is no reference for R1.


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


RFC3032, "MPLS Label Stack Encoding", January 2001

Source of RFC: mpls (rtg)

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).


RFC3036, "LDP Specification", January 2001

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.


RFC3037, "LDP Applicability", January 2001

Source of RFC: mpls (rtg)

Errata ID: 344

Status: Verified
Type: Technical

Reported By: Elena Taguer
Date Reported: 2001-01-29

Section 1 says:

   LDP is also useful in situations that require efficient hop-by-hop
   routed tunnels, such as MPLS-based VPN architectures [RFC2574] and
   tunneling between BGP border routers.  

It should say:

   LDP is also useful in situations that require efficient hop-by-hop
   routed tunnels, such as MPLS-based VPN architectures [RFC2547] and
   tunneling between BGP border routers.


RFC3047, "RTP Payload Format for ITU-T Recommendation G.722.1", January 2001

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.


RFC3052, "Service Management Architectures Issues and Review", January 2001

Source of RFC: Legacy

Errata ID: 342

Status: Verified
Type: Technical

Reported By: Sid Nag
Date Reported: 2002-11-20
Report Text:

In Section 7, Sid Nag has reverted back to his original EMail address: 

   thinker@monmouth.com


RFC3056, "Connection of IPv6 Domains via IPv4 Clouds", February 2001

Source of RFC: ngtrans (ops)

Errata ID: 341

Status: Verified
Type: Technical

Reported By: Brian Carpenter
Date Reported: 2002-11-20

Section 5.3 says:

then
apply any security checks (see Section 8);

It should say:

then
apply any security checks (see Section 9);

Errata ID: 697

Status: Verified
Type: Technical

Reported By: Brian Carpenter
Date Reported: 2002-11-20

Section 5.3 says:

apply any security checks (see Section 8);

It should say:

apply any security checks (see Section 9);

Notes:



RFC3061, "A URN Namespace of Object Identifiers", February 2001

Source of RFC: Legacy

Errata ID: 1751

Status: Verified
Type: Technical

Reported By: John Klensin
Date Reported: 2009-04-02
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 1 says:

   o  0.9.2342.19200300.100.4 - Object ID's used in the directory pilot
      project to identify X.500 Object Classes.  Mostly defined in RFC
      1274.

   This document specifies the "oid" URN namespace [2].  This namespace
   is for encoding an Object Identifier as specified in ASN.1 [3] as a
   URI.  RFC 3001 [1] is obsoleted by this specification.

   The namespace specification is for a formal namespace.

It should say:

   o  0.9.2342.19200300.100.4 - Object ID's used in the directory pilot
      project to identify X.500 Object Classes.  Mostly defined in RFC
      1274.  RFC 1274 is now obsolete.  The usage description of these 
      identifiers now appears in RFC 4524 and the relevant registry is 
      defined in RFC 4520.

   This document specifies the "oid" URN namespace [2].  This namespace
   is for encoding an Object Identifier as specified in ASN.1 [3] as a
   URI.  RFC 3001 [1] is obsoleted by this specification.

   The namespace specification is for a formal namespace.

   A complete database of OIDs appears at http://www.oid-info.com/

Notes:

This suggested change is not substantive and makes no change to the spec itself. Instead, it supplies some additional, up-to-date, information that might be helpful to the reader and is intended to act as a placeholder to record that information for any future revision or update to 3061.

Note to RFC Editor: the source for this document is listed as "legacy", perhaps because it was published as Informational. However, it is the definition source for a Formal URN Namespace and those namespaces require IETF consensus action (see http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml), so the erratum should probably be processed as if it were a standards-track document.


RFC3062, "LDAP Password Modify Extended Operation", February 2001

Source of RFC: Legacy

Errata ID: 340

Status: Verified
Type: Technical

Reported By: Kurt Zeilenga
Date Reported: 2001-03-07

Section 1 says:

   Traditionally, LDAP users where identified by the Distinguished Name
   [RFC2253] of a directory entry and this entry contained a userPassword
   [RFC2256] attribute containing one or more passwords.

It should say:

   Traditionally, LDAP users were identified by the Distinguished
   Name [RFC2253] of a directory entry and this entry contained a
   userPassword [RFC2256] attribute containing one or more passwords.


RFC3066, "Tags for the Identification of Languages", January 2001

Note: This RFC has been obsoleted by RFC4646 RFC4647

Source of RFC: Legacy

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: 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/


RFC3069, "VLAN Aggregation for Efficient IP Address Allocation", February 2001

Source of RFC: Legacy

Errata ID: 335

Status: Verified
Type: Technical

Reported By: Bob Braden
Date Reported: 2007-06-06

Section 1 says:

customer C and resides in it's own virtual LAN, VLAN C.

It should say:

customer C and resides in its own virtual LAN, VLAN C.

Notes:

Notes/ Ooops. Ouch!


RFC3080, "The Blocks Extensible Exchange Protocol Core", March 2001

Source of RFC: beep (app)

Errata ID: 992

Status: Verified
Type: Technical

Reported By: Ozz Nixon
Date Reported: 2007-06-13
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 2.2.1.1 says:

   The answer number ("ansno") must be a non-negative integer (in the
   range 0..4294967295) and must have a different value than all other
   answers in progress for the message being replied to.

It should say:

   The answer number ("ansno") must be a non-negative integer (in the
   range 0..2147483647) and must have a different value than all other
   answers in progress for the message being replied to.

Notes:

Page 8 says:

channel = 0..2147483647
msgno = 0..2147483647
more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647

If page 8 is correct, page then 9 needs to be changed to suggested text above.

from pending


RFC3083, "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", March 2001

Source of RFC: ipcdn (ops)

Errata ID: 334

Status: Verified
Type: Technical

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)


RFC3092, "Etymology of "Foo"", April 2001

Source of RFC: INDEPENDENT

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.


RFC3104, "RSIP Support for End-to-end IPsec", October 2001

Source of RFC: nat (tsv)

Errata ID: 333

Status: Verified
Type: Technical

Reported By: Matt Holdrege
Date Reported: 2004-03-13

In the References section, "Holdrege" is spelled incorrectly. It says:

   [NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

It should say:

   [NAT-TERMS] Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

Notes:





RFC3108, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", May 2001

Source of RFC: mmusic (rai)

Errata ID: 332

Status: Verified
Type: Technical

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


RFC3110, "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", May 2001

Source of RFC: dnsext (int)

Errata ID: 2811

Status: Verified
Type: Technical

Reported By: George Barwood
Date Reported: 2011-05-21
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 3 says:

Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.

It should say:

Leading zero bytes MUST be added to the RSA/SHA1 algorithm signature 
so that the signature size in bytes is equal to the size of n in bytes.

Notes:

The Original Text implies that zero-padding of RSA signaturs is optional, however the underlying standard requires zero padding, http://tools.ietf.org/html/rfc2437#section-8.1.1

"4. Convert the signature representative s to a signature S of length k octets: S = I2OSP (s, k)"

where k is the length of the modulus in bytes. If the extra bytes are not added, standard RSA libraries will fail to verify the signature about 1% of the time when the padding occurs.


RFC3118, "Authentication for DHCP Messages", June 2001

Source of RFC: dhc (int)

Errata ID: 3474

Status: Verified
Type: Technical

Reported By: Chris Lonvick
Date Reported: 2013-02-02
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 2 says:

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  Using a
   counter value such as the current time of day (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

It should say:

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a strictly increasing counter.  Using a
   counter value such as the time since the epoch (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

Notes:

The term "monotonically increasing" does not actually mean what the authors and editors hope it means. :-) An example of a monotonically increasing sequence is:
1, 2, 2, 2, 2, 2, 2...

Strictly following that definition in the current section 2 would allow replays of captured packets. Changing the term to "strictly increasing" requires that subsequent values are greater than previous values. This would mean that a captured packet replayed with the same Authentication Information value would not meet the criteria described in my proposed corrected text, and should consequently be detected as a replay attack by a recipient.

The term monotonically increasing is also used at the end of Section 6 and should also be replaced with strictly increasing.

Also, the use of the term "time of day" could be problematic. If the first packet were sent just before midnight, and the second sent just after midnight, then the value of the second would be much lower than the value of the first. To align with the NTP example, I'm suggesting a change in text to be something that is actually increasing.


RFC3119, "A More Loss-Tolerant RTP Payload Format for MP3 Audio", June 2001

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"


RFC3122, "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", June 2001

Source of RFC: ipngwg (int)

Errata ID: 3696

Status: Verified
Type: Technical

Reported By: Arnold Plankl
Date Reported: 2013-08-14
Verifier Name: Brian Haberman
Date Verified: 2013-09-10

Section 2.2 says:

The sender node MUST send the following options in the Advertisement
   message:

   Source Link-Layer Address The link-layer address of the sender.

      Target Link-Layer Address
         The link-layer address of the target, that is, the sender of
         the advertisement.

It should say:

The sender node MUST send the following options in the Advertisement
message:

   Source Link-Layer Address
      The link-layer address of the node transmitting the
      Advertisement message

   Target Link-Layer Address
      The link-layer address of the node that transmitted the
      Solicitation message

Notes:

There is an ambiguity with the Source Link-Layer and Target Link-Layer Address option in the Inverse Neighbor Discovery Advertisement Message. It is unclear if SLLA is set to sender of the Advertisement or of the Solicitation, the same with TLLA. The RFC-text as it is would lead to SLL=TLL=sender of advertisement.

Here is an example for clarification of the problem (with 2 Ethernet-nodes, no FR):
Eth Node A - Eth Node B:
1. A sends IND S with SLLA=A, TLLA=B
2. B takes the address pair from SLLA and source-IP in ND cache
3. B answers with IND A with TAL(identified by TLLA in solicitation), SLLA=B,TLLA=B <- problem is here (SLLA=TLLA=B). Is that acceptable?
Or modify to: SLLA=A or TLLA=A? Or omit TLLA?
4. A takes the address pair from SLLA and the TAL in ND cache

Solution 1: B answers with IND A with TAL, SLLA=B, and TLLA=A => Then carries TLLA the address of the requesting node (is that acceptable as “target” address?)

Solution 2: B answers with IND A with TAL, SLLA=A, and TLLA=B => Then A could not take the address pair from SLLA and the TAL in ND cache.


RFC3126, "Electronic Signature Formats for long term electronic signatures", September 2001

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


RFC3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Source of RFC: pkix (sec)

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.


RFC3165, "Definitions of Managed Objects for the Delegation of Management Scripts", August 2001

Source of RFC: disman (ops)

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)


RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

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.


RFC3171, "IANA Guidelines for IPv4 Multicast Address Assignments", August 2001

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.


RFC3174, "US Secure Hash Algorithm 1 (SHA1)", September 2001

Source of RFC: INDEPENDENT

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.


RFC3180, "GLOP Addressing in 233/8", September 2001

Source of RFC: mboned (ops)

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].


RFC3182, "Identity Representation for RSVP", October 2001

Source of RFC: rap (ops)

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.


RFC3183, "Domain Security Services using S/MIME", October 2001

Source of RFC: smime (sec)

Errata ID: 3757

Status: Verified
Type: Technical

Reported By: Russ Housley
Date Reported: 2013-10-18
Verifier Name: Sean Turner
Date Verified: 2013-12-03

Section 3.1.2 says:

   An S/MIME signed attribute is used to indicate the type of signature.
   This should be used in conjunction with the naming conventions
   specified in the previous section.  When an S/MIME signed message
   containing the signature type attribute is received it triggers the
   software to verify that the correct naming convention has been used.

   The ASN.1 [4] notation of this attribute is: -

      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

It should say:

   An S/MIME signed attribute is used to indicate the type of signature.
   This should be used in conjunction with the naming conventions
   specified in the previous section.  When an S/MIME signed message
   containing the signature type attribute is received it triggers the
   software to verify that the correct naming convention has been used.

   The following object identifier identifies the SignatureType
   attribute:

      id-aa-signatureType OBJECT IDENTIFIER ::= { iso(1) 
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 28 }

   The ASN.1 [4] notation of this attribute is:

      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

Notes:

The specification provides the syntax for the SignatureType attribute,
but it fails to provide the object identifier for the attribute. The object
identifier was assigned, but for some reason it is not provided in the
document.


RFC3189, "RTP Payload Format for DV (IEC 61834) Video", January 2002

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


RFC3196, "Internet Printing Protocol/1.1: Implementor's Guide", November 2001

Source of RFC: ipp (app)

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: 3161

Status: Verified
Type: Editorial

Reported By: Michael Sweet
Date Reported: 2012-03-22
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-22

Section 4.5 says:

   The IPP object model does not prohibit a job that contains no
   documents.  Such a job may be created in a number of ways including a
   'create-job' followed by an 'add-document' that contains no data and
   has the 'last-document' flag set.

It should say:

   The IPP object model does not prohibit a job that contains no
   documents.  Such a job may be created in a number of ways including a
   'Create-Job' followed by a 'Send-Document' that contains no data and
   has the 'last-document' flag set.

Notes:

The operation is called "Send-Document", not "add-document"...


RFC3204, "MIME media types for ISUP and QSIG Objects", December 2001

Source of RFC: sip (rai)

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


RFC3207, "SMTP Service Extension for Secure SMTP over Transport Layer Security", February 2002

Source of RFC: Legacy

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>


RFC3208, "PGM Reliable Transport Protocol Specification", December 2001

Source of RFC: Legacy
Area Assignment: tsv

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.


RFC3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001

Source of RFC: mpls (rtg)

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.


RFC3217, "Triple-DES and RC2 Key Wrapping", December 2001

Source of RFC: smime (sec)

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.


RFC3219, "Telephony Routing over IP (TRIP)", January 2002

Source of RFC: iptel (rai)

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.


RFC3226, "DNSSEC and IPv6 A6 aware server/resolver message size requirements", December 2001

Source of RFC: dnsext (int)

Errata ID: 2810

Status: Verified
Type: Editorial

Reported By: Edward Lewis
Date Reported: 2011-05-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 2.1 says:

DNSSEC OK[OK] specifies how ...

It should say:

DNSSEC OK[RFC3225] specifies how ...

Notes:

Reference "link" is broken.


RFC3245, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", March 2002

Source of RFC: IAB

Errata ID: 319

Status: Verified
Type: Technical

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."


RFC3247, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", March 2002

Source of RFC: diffserv (tsv)

Errata ID: 318

Status: Verified
Type: Editorial

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


RFC3253, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", March 2002

Source of RFC: deltav (app)

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

RFC3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

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: 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: 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: 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: 3183

Status: Verified
Type: Technical

Reported By: Bruno CHATRAS
Date Reported: 2012-04-10
Verifier Name: Robert Sparks

Section 23.4.3 says:

         --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required
         Content-Length: 231


It should say:

   --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required


Notes:

A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.

This was discussed on both the SIP Implementors and SIP Core mailing lists.


Errata ID: 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.


RFC3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

Source of RFC: sip (rai)

Errata ID: 315

Status: Verified
Type: Technical

Reported By: Steve Conner
Date Reported: 2002-07-04
Report Text:

This document obsoletes RFC 2543.


RFC3264, "An Offer/Answer Model with Session Description Protocol (SDP)", June 2002

Source of RFC: mmusic (rai)

Errata ID: 3818

Status: Verified
Type: Technical

Reported By: Jörgen Axell
Date Reported: 2013-12-02
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-12-03

Section 4 says:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the answer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

It should say:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the offer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

Notes:

You can't reject an answer. When the answer is received the SDP negotiation is completed.


RFC3265, "Session Initiation Protocol (SIP)-Specific Event Notification", June 2002

Note: This RFC has been obsoleted by RFC6665

Source of RFC: sip (rai)

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


RFC3266, "Support for IPv6 in Session Description Protocol (SDP)", June 2002

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.


RFC3267, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", June 2002

Note: This RFC has been obsoleted by 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.


RFC3271, "The Internet is for Everyone", April 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

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.


RFC3272, "Overview and Principles of Internet Traffic Engineering", May 2002

Source of RFC: tewg (subip)

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.


RFC3275, "(Extensible Markup Language) XML-Signature Syntax and Processing", March 2002

Source of RFC: xmldsig (sec)

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


RFC3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Source of RFC: pkix (sec)

Errata ID: 307

Status: Verified
Type: Technical

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.


RFC3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

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.

RFC3281, "An Internet Attribute Certificate Profile for Authorization", April 2002

Note: This RFC has been obsoleted by RFC5755

Source of RFC: pkix (sec)

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: 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: 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


RFC3289, "Management Information Base for the Differentiated Services Architecture", May 2002

Source of RFC: diffserv (tsv)

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).


RFC3297, "Content Negotiation for Messaging Services based on Email", July 2002

Source of RFC: fax (app)

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)


RFC3300, "Internet Official Protocol Standards", November 2002

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: Verified
Type: Editorial

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-17
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section TOC says:

2.  Contacts . . . . . . . . . . . . . . . . . . . . . . . . .   2

It should say:

2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . .   2


RFC3304, "Middlebox Communications (midcom) Protocol Requirements", August 2002

Source of RFC: midcom (tsv)

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


RFC3305, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", August 2002

Source of RFC: Legacy
Area Assignment: app

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]


RFC3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003

Source of RFC: dhc (int)

Errata ID: 294

Status: Verified
Type: Technical

Reported By: Hideshi Enokihara
Date Reported: 2006-06-29
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 20.1.2 says:

   The relay agent copies the source address from the IP datagram in
   which the message was received from the client into the peer-address
   field in the Relay-forward message and sets the hop-count field to
   the value of the hop-count field in the received message incremented
   by 1.

It should say:

   The relay agent copies the source address from the IP datagram in
   which the message was received from the relay agent into the peer-address
   field in the Relay-forward message and sets the hop-count field to
   the value of the hop-count field in the received message incremented
   by 1.

Notes:


Errata ID: 2472

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.2.2 says:

If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes only a Status Code option with
code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.

It should say:

If the server will not assign any addresses to an IA in a
subsequent Request from the client, the server MUST send an Advertise
message to the client that includes the IA containing a Status Code option
with status code NoAddrsAvail and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID. The server SHOULD include other stateful IA options
(like IA_PD) and other configuration options in the Advertise message.

Errata ID: 2471

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.1.3 says:

The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.

It should say:

The client MUST ignore any IAs in an Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message to the
user.

Errata ID: 1373

Status: Verified
Type: Technical

Reported By: Robert Marks
Date Reported: 2008-03-19
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 22.17 says:

      option-code          OPTION_VENDOR_OPTS (17)

      option-len           4 + length of option-data field

      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

      option-data          An opaque object of option-len octets,
                           interpreted by vendor-specific code on the
                           clients and servers

It should say:

      option-code          OPTION_VENDOR_OPTS (17)

      option-len           4 + length of option-data field

      enterprise-number    The vendor's registered Enterprise Number as
                           registered with IANA [6].

      option-data          An opaque object,
                           interpreted by vendor-specific code on the
                           clients and servers

Notes:

option-len is defined to be the size of the option-data + 4. Thus the size of option-data cannot option-len, but is actually option-len - 4.


Errata ID: 2928

Status: Verified
Type: Technical

Reported By: Leaf Yeh
Date Reported: 2011-08-09
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 17.2.1 says:

   For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client indicates with a Reconfigure
   Accept option in the Solicit message that it will not accept a
   Reconfigure message, the servers discard the Solicit message.

It should say:

   For example, if the administrative policy for the server is 
   that it may only respond to a client that is willing to accept a 
   Reconfigure message, if the client does not include a Reconfigure 
   Accept option (see section 22.20) in the Solicit message, the 
   servers discard the Solicit message.


Errata ID: 1815

Status: Verified
Type: Editorial

Reported By: Michelle Cotton
Date Reported: 2009-07-22
Verifier Name: Brian Haberman
Date Verified: 2012-07-29

Section 26 says:

 [6]  IANA.  Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers.html.

It should say:

 [6]  IANA.  Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers

Notes:

The URL for the enterprise numbers registry is incorrect.


Errata ID: 3577

Status: Verified
Type: Editorial

Reported By: Pablo Armando
Date Reported: 2013-03-31
Verifier Name: Ted Lemon
Date Verified: 2013-04-02

Section 9.3 says:

An example DUID of this type might look like this:

 +---+---+---+---+---+---+---+---+
 | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
 +---+---+---+---+---+---+---+---+
 |132|221| 3 | 0 | 9 | 18|
 +---+---+---+---+---+---+

This example includes the two-octet type of 2, the Enterprise Number
(9), followed by eight octets of identifier data
(0x0CC084D303000912).

It should say:

An example DUID of this type might look like this:

 +---+---+---+---+---+---+---+---+
 | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
 +---+---+---+---+---+---+---+---+
 |132|211| 3 | 0 | 9 | 18|
 +---+---+---+---+---+---+

This example includes the two-octet type of 2, the Enterprise Number
(9), followed by eight octets of identifier data
(0x0CC084D303000912).

Notes:

0xD3 is 211 decimal, not 221.

I am assuming that this number is the correct one: 0x0CC084D303000912


RFC3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Source of RFC: sip (rai)

Errata ID: 3744

Status: Verified
Type: Technical

Reported By: Brett Tate
Date Reported: 2013-10-08
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.1 says:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.


Errata ID: 3894

Status: Verified
Type: Technical

Reported By: Richard Barnes
Date Reported: 2014-02-15
Verifier Name: Richard Barnes
Date Verified: 2014-02-15

Section 9.2 says:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.

It should say:

A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec.  If the URI contains a comma, the URI MUST
be enclosed in angle brackets (< and >).

Notes:

While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we note that usage of ";" and "?" also must be enclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.


RFC3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Source of RFC: sip (rai)

Errata ID: 3799

Status: Verified
Type: Technical

Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14

Section Appendix A says:

spivalue           = 10DIGIT; 0 to 4294967295

It should say:

spivalue           = 1*10DIGIT; 0 to 4294967295

Notes:

The number string does not have to have 10 digit characters if the number is not 10 digits in length.


RFC3339, "Date and Time on the Internet: Timestamps", July 2002

Source of RFC: impp (app)

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)


Errata ID: 3710

Status: Verified
Type: Editorial

Reported By: Thomas B
Date Reported: 2013-08-26
Verifier Name: Barry Leiba
Date Verified: 2013-08-26

Section 6 says:

[IERS] International Earth Rotation Service Bulletins,
       <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.

It should say:

[IERS] International Earth Rotation Service Bulletins,
       <http://hpiers.obspm.fr/eop-pc/products/bulletins
        /bulletins.html>.

Notes:

Original link is missing a "bulletins/" before the terminal "bulletins.html".
This leads to a 404


RFC3345, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", August 2002

Source of RFC: idr (rtg)

Errata ID: 3787

Status: Verified
Type: Editorial

Reported By: Ramakrishna DTV
Date Reported: 2013-11-05
Verifier Name: Stewart Bryant
Date Verified: 2014-01-16

Section 2.1 says:

      1) Ra has the following installed in its BGP table, with the path
         learned via AS2 marked best:

It should say:

      1) Ra has the following installed in its BGP table, with the path
         learned via AS10 marked best:

Notes:

The above text is related to a discussion of topology depicted in Figure 1. This figure does not have AS2 at all. The text should refer to AS10 instead.


RFC3348, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", July 2002

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2020

Status: Verified
Type: Editorial

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.


RFC3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", August 2002

Source of RFC: dnsext (int)

Errata ID: 1680

Status: Verified
Type: Technical

Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section "Bitlabels" says:

addresses, it proposes to use a new kind of DNS label (a "bit label")
to represent binary addresses directly in the DNS.

It should say:

addresses, it proposes to use a new kind of DNS label (a "bit label"), 
specified in [RFC2673],
to represent binary addresses directly in the DNS.

*** RFC 2673 should also appear in the References section.***

Notes:

This document is listed as updating RFC 2673. That claim is actually dubious, since it simply explains why one particular application of 2673 may not be appropriate, an application that is not even mentioned in 2673 itself. But, if it does actually update 2673, then it should be possible for the reader to deduce how the two document interact without extensive detective work.

An alternative fix would be to remove the entry indicating updating of 2673 from the header of this document and corresponding indexes and references -- what this actually updates is 2874, which specifies a particular application of 2673.


RFC3369, "Cryptographic Message Syntax (CMS)", August 2002

Note: This RFC has been obsoleted by RFC3852

Source of RFC: smime (sec)

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: 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: 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.



RFC3370, "Cryptographic Message Syntax (CMS) Algorithms", August 2002

Source of RFC: smime (sec)

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.


RFC3372, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", September 2002

Source of RFC: sipping (rai)

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.


RFC3376, "Internet Group Management Protocol, Version 3", October 2002

Source of RFC: idmr (rtg)

Errata ID: 1501

Status: Verified
Type: Editorial

Reported By: Dave Thaler
Date Reported: 2008-09-08
Verifier Name: Adrian Farrel
Date Verified: 2013-05-11

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.


RFC3377, "Lightweight Directory Access Protocol (v3): Technical Specification", September 2002

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.


RFC3381, "Internet Printing Protocol (IPP): Job Progress Attributes", September 2002

Source of RFC: ipp (app)

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'.


RFC3385, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", September 2002

Source of RFC: Legacy

Errata ID: 286

Status: Verified
Type: Technical

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


RFC3389, "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", September 2002

Source of RFC: avt (rai)

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


RFC3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm", September 2002

Source of RFC: smime (sec)

Errata ID: 3671

Status: Verified
Type: Editorial

Reported By: Lucas Garron
Date Reported: 2013-06-26
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 2.2.3.1 says:

If unwrapping produces A[0] any other value,

It should say:

If unwrapping produces A[0] equal to any other value,

Notes:

This resembles a copy-paste typo, where the last portion of "If unwrapping produces A[0]" was not removed in the second of two sentences.

I edited this based on comments from the authors.


RFC3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002

Source of RFC: urn (app)

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]


RFC3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002

Source of RFC: urn (app)

Errata ID: 282

Status: Verified
Type: Editorial

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


RFC3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002

Source of RFC: urn (app)

Errata ID: 2687

Status: Verified
Type: Technical

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.


RFC3406, "Uniform Resource Names (URN) Namespace Definition Mechanisms", October 2002

Source of RFC: urn (app)

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.


RFC3410, "Introduction and Applicability Statements for Internet-Standard Management Framework", December 2002

Source of RFC: snmpv3 (ops)

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.


RFC3413, "Simple Network Management Protocol (SNMP) Applications", December 2002

Source of RFC: snmpv3 (ops)

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: 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."



RFC3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 278

Status: Verified
Type: Technical

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).


RFC3415, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 277

Status: Verified
Type: Technical

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]


RFC3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2757

Status: Verified
Type: Technical

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),


RFC3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 276

Status: Verified
Type: Technical

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


RFC3420, "Internet Media Type message/sipfrag", November 2002

Source of RFC: sip (rai)

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: 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:



RFC3424, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", November 2002

Source of RFC: IAB

Errata ID: 273

Status: Verified
Type: Technical

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


RFC3433, "Entity Sensor Management Information Base", December 2002

Source of RFC: entmib (ops)

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

RFC3435, "Media Gateway Control Protocol (MGCP) Version 1.0", January 2003

Source of RFC: IETF - NON WORKING GROUP

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.


RFC3439, "Some Internet Architectural Guidelines and Philosophy", December 2002

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

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.


RFC3445, "Limiting the Scope of the KEY Resource Record (RR)", December 2002

Note: This RFC has been obsoleted by RFC4033 RFC4034 RFC4035

Source of RFC: dnsext (int)

Errata ID: 272

Status: Verified
Type: Editorial

Reported By: "Scott Rose"
Date Reported: 2005-02-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Values for the key protocol octet are incorrect. They should be:

        VALUE   Protocol

          0      -reserved
          1     reserved (was TLS)
          2     reserved (was email)
          3     dnssec
          4     reserved (was IPSEC)
         5-255   reserved

Notes:

Rationale: Looking at RFC2535, the values are the original assignments. The
numbers in RFC3445 are incorrect and don't match. I guess since the
registry was closed, they are all reserved now and no one double checked.

RFC 2535 has the original correct assignments, and the registry is correct
in stating that they are now all reserved.


RFC3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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).


RFC3448, "TCP Friendly Rate Control (TFRC): Protocol Specification", January 2003

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)


RFC3454, "Preparation of Internationalized Strings ("stringprep")", December 2002

Source of RFC: IETF - NON WORKING GROUP

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


RFC3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

Source of RFC: IETF - NON WORKING GROUP

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


RFC3464, "An Extensible Message Format for Delivery Status Notifications", January 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC3468, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", February 2003

Source of RFC: mpls (rtg)

Errata ID: 695

Status: Verified
Type: Technical

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


RFC3470, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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."


RFC3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", January 2003

Source of RFC: ccamp (rtg)

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.


RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003

Source of RFC: ccamp (rtg)

Errata ID: 267

Status: Verified
Type: Technical

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


RFC3490, "Internationalizing Domain Names in Applications (IDNA)", March 2003

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.


RFC3492, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", March 2003

Source of RFC: idn (int)

Errata ID: 265

Status: Verified
Type: Technical

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.


RFC3494, "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", March 2003

Source of RFC: Legacy

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.

RFC3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC3507, "Internet Content Adaptation Protocol (ICAP)", April 2003

Source of RFC: Legacy

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/





RFC3525, "Gateway Control Protocol Version 1", June 2003

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


RFC3530, "Network File System (NFS) version 4 Protocol", April 2003

Source of RFC: nfsv4 (tsv)

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).


RFC3537, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", May 2003

Source of RFC: smime (sec)

Errata ID: 254

Status: Verified
Type: Editorial

Reported By: Russ Housley
Date Reported: 2004-10-14

Section 3.4 says:

    PAD          :  38be62

It should say:

    PAD          :  be62fe

Notes:



RFC3542, "Advanced Sockets Application Program Interface (API) for IPv6", May 2003

Source of RFC: ipv6 (int)

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".


RFC3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Source of RFC: IAB

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.


RFC3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 3378

Status: Verified
Type: Technical

Reported By: Bernard Aboba
Date Reported: 2012-10-13
Verifier Name: Benoit Claise
Date Verified: 2012-12-13

Section Metadata says:

Updates: 2865


It should say:

Updates: 2865, 2868

Notes:


IANA needs to be updated as well.

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-14

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]


http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-15

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]

=======================================================



Some background information:

RFC 3575 Section 2.1 states the following:

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS. Values 1-16 of the Service-Type attribute have
been allocated. Allocation of new Service-Type values are by IETF
Consensus. The intention is that any allocation will be accompanied
by a published RFC.

Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not.

Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata.

In other words:

The discussion, as I understand it, is about "IETF consensus" versus "Designated Expert"

From RFC 2868

6.1. Tunnel-Type Attribute Values

Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
the remaining values are available for assignment by the IANA with
IETF Consensus [16].

6.2. Tunnel-Medium-Type Attribute Values

Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
Section 5.2; the remaining values are available for assignment by the
IANA with IETF Consensus [16].

From RFC 3575

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS.

So Tunnel-Type and Tunnel-Medium-Type are "IETF consensus" or "Designated Expert"?

From the IETF 80 meeting minutes, https://www.ietf.org/proceedings/80/minutes/radext.txt:

2. IANA issues
A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as 3575 assigns based on expert review but didn’t update 2868). Omission of RFC 2868 could be an errata; this is basically a request for metadata.
- Asks Dan for comment: was looking for input from the working group before proceeding.
- Alan thought it was an errata.
- Stefan states no opinion.
- Klaas also states no opinion.
- Nancy asks for further understanding. Bernard clarifies: RFC 2868 states “standards action” and 3575 is more lenient in saying just expert review.
- Now Dan remembers: when there’s conflicts such as this, 2 solutions: take the stricter or take the latest. But if it’s the latest, then it needs to be clearer. Believes in this case, explicit clarification is justified since 3575 is more recent and the request is justified. But need IESG perspective review by WG.
- Bernard suggests to get a sense of this group and then take it to the mailgroup.
Asks: proposal is to accept and verify the errata and update 3575 to include 2868.
In favor: 10, non oppose. Given consensus, will take to the mail list.


RFC3580, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", September 2003

Source of RFC: INDEPENDENT

Errata ID: 1503

Status: Verified
Type: Technical

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.


RFC3588, "Diameter Base Protocol", September 2003

Note: This RFC has been obsoleted by RFC6733

Source of RFC: aaa (ops)

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: 3280

Status: Verified
Type: Technical

Reported By: Hans Liu
Date Reported: 2012-07-04
Verifier Name: Benoit Claise
Date Verified: 2012-07-17

Section 5.6 says:

Section 5.6 says for both I- and R-:

Open - "Rcv-DPR" - "Snd-DPA,Disc" - "Closed"  

It should say:

Per section 5.4, the receiver of the Disconnect-Peer-Answer 
initiates the transport disconnect, so it should say, for 
both I- and R-:

Open - "Rcv-DPR" - "Snd-DPA" - "Closing"  

Notes:

In RFC3588bis-34, section 5.4 states more clearly as below

The receiver of the Disconnect-Peer-Answer initiates the transport disconnect. The sender of the Disconnect-Peer-Answer should be able to detect the transport closure and cleanup the connection.


Errata ID: 250

Status: Verified
Type: Editorial

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: 3266

Status: Verified
Type: Editorial

Reported By: Jack Teng
Date Reported: 2012-06-25
Verifier Name: RonBonica
Date Verified: 2012-06-28

Section 5.4. says:

The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect-Peer-Request message.

It should say:

The Disconnect-Cause AVP contains the reason the Diameter node issued the Disconnect-Peer-Request message.

(There is no such AVP named Disconnection-Reason)

RFC3597, "Handling of Unknown DNS Resource Record (RR) Types", September 2003

Source of RFC: dnsext (int)

Errata ID: 1063

Status: Verified
Type: Technical

Reported By: Peter Koch
Date Reported: 2005-09-13
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 7 says:

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
   DNAME, and A6.

It should say:

[not supplied]

Notes:

Compare with RFC 4034 (section 6.2):

"3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;"

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.


RFC3605, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", October 2003

Source of RFC: mmusic (rai)

Errata ID: 1050

Status: Verified
Type: Technical

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".


RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003

Source of RFC: avt (rai)

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".


RFC3625, "The QCP File Format and Media Types for Speech Data", September 2003

Source of RFC: INDEPENDENT

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: 3383

Status: Verified
Type: Editorial

Reported By: Tom Ritter
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-16

Section 3 says:

   rate-map-table  = 8rate-map-entry

It should say:

   rate-map-table  = *rate-map-entry

Notes:

I believe this is a simple typo specifying that there are num-rates number of rate-map-entries

Yes. Something like n-rate-map-entries would be even clearer (* implies a pointer to me)


RFC3627, "Use of /127 Prefix Length Between Routers Considered Harmful", September 2003

Note: This RFC has been obsoleted by RFC6547

Source of RFC: INDEPENDENT

Errata ID: 2465

Status: Verified
Type: Editorial

Reported By: Fernando Gont
Date Reported: 2010-08-15
Verifier Name: Nevil Brownlee
Date Verified: 2012-11-05

Section 6.2 says:

   [ICMPv3]    Conta, A., Deering, S., "Internet Control Message
               Protocol (ICMPv6)", Work in Progress.

It should say:

   [ICMPv6]    Conta, A., Deering, S., "Internet Control Message
               Protocol (ICMPv6)", Work in Progress.

Notes:

Pointer to this reference should be fixed accordingly (i.e., s/ICMPv3/ICMPv6/ across the document)


RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", December 2003

Source of RFC: dhc (int)

Errata ID: 2468

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 12.1 / 12.2 says:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

It should say:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached.

New last paragraph of 12.2:
  When the DR delegates prefixes to a Requesting Router, the
  Requesting Router has sole authority for assignment of those
  prefixes, and the Delegating Router MUST NOT assign any prefixes
  from that delegated prefix to any of its own links.

Notes:

This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).

2011-08-02: Notes updated per request from Ole Troan and Leaf Yeh.


Errata ID: 2469

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.1 says:

The requesting router MUST ignore any Advertise message that includes
a Status Code option containing the value NoPrefixAvail, with the
exception that the requesting router MAY display the associated
status message to the user.

It should say:

The requesting router MUST ignore any IA_PDs in an Advertise message that includes
a Status Code option containing the value NoPrefixAvail, with the
exception that the requesting router MAY display the associated
status message to the user.

Errata ID: 2470

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.2 says:

If the delegating router will not assign any prefixes to any IA_PDs
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID.

It should say:

If the delegating router will not assign any prefixes to an IA_PD
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID. The server SHOULD include other stateful IA options
(like IA_NA) and other configuration options in the Advertise message.

Notes:

Edited by Ralph Droms on 2010-08-20 to correct reference to IA_NA (was IA_PD) in last line.


RFC3647, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", November 2003

Source of RFC: pkix (sec)

Errata ID: 247

Status: Verified
Type: Editorial

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
   ------------------------------------------------------


RFC3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

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


RFC3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

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: 3295

Status: Verified
Type: Technical

Reported By: David Waiting
Date Reported: 2012-07-26
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 3.8. says:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

It should say:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Notes:

Proxy 1 includes an incorrect Via header in the ACK.


RFC3666, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", December 2003

Source of RFC: sipping (rai)

Errata ID: 728

Status: Verified
Type: Editorial

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

RFC3677, "IETF ISOC Board of Trustee Appointment Procedures", December 2003

Source of RFC: IAB

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

RFC3678, "Socket Interface Extensions for Multicast Source Filters", January 2004

Source of RFC: magma (int)

Errata ID: 2524

Status: Verified
Type: Technical

Reported By: YOSHIFUJI Hideaki
Date Reported: 2010-09-16
Verifier Name: Brian Haberman
Date Verified: 2012-04-27

Section 5.2.2 says:

   The interface argument holds the local IP address of the interface.

It should say:

   The interface argument holds the interface index of the interface.

Notes:

See Section 5.2.1.


Errata ID: 1395

Status: Verified
Type: Editorial

Reported By: Dave Thaler
Date Reported: 2008-03-27
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5.1 says:

The rules for generating errors are the same as those given in
Section 5.1.3.

It should say:

The rules for generating errors are the same as those given in
Section 4.1.3.

Notes:

There is no section 5.1.3.


RFC3680, "A Session Initiation Protocol (SIP) Event Package for Registrations", March 2004

Source of RFC: sipping (rai)

Errata ID: 3494

Status: Verified
Type: Technical

Reported By: Brett Tate
Date Reported: 2013-02-24
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 6 says:

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1288 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

It should say:

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1288 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Subscription-State:active;expires=3600
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Subscription-State:active;expires=3000
   Max-Forwards: 70
   Content-Type: application/reginfo+xml
   Content-Length: ...

Notes:

The two NOTIFY examples are missing mandatory Subscription-State header.


RFC3696, "Application Techniques for Checking and Transformation of Names", February 2004

Source of RFC: INDEPENDENT

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.


Errata ID: 3563

Status: Verified
Type: Technical

Reported By: David Hoerl
Date Reported: 2013-03-22
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 3.4 says:

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com


It should say:

Section 3 says:

   The exact rule is that any ASCII character, including control
   characters, may appear quoted, or in a quoted string.  When quoting
   is needed, the backslash character is used to quote the following
   character.  For example

      Abc\@def@example.com
or      
      "Abc@def"@example.com

   is a valid form of an email address.  Blank spaces may also appear,
   as in

      Fred\ Bloggs@example.com
or      
      "Fred Bloggs"@example.com

   The backslash character may also be used to quote itself, e.g.,

      Joe.\\Blow@example.com
or      
      " Joe.\Blow"@example.com


Notes:

Errata 246 is clearly wrong. The author changed the quoting to make it appear backslash quoting was required to use a single backquote. This is totally wrong, and contradicts the RFC text:

"may appear quoted, or in a quoted string".

I tested today with several mailers sending to the google pseudo-alias of first.last+note@gmail.com, where note can be arbitrary text. By testing numerous versions of quoting I was able to see that my corrected text was what appeared in the destination email.


RFC3700, "Internet Official Protocol Standards", July 2004

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

RFC3712, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", February 2004

Source of RFC: INDEPENDENT

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.

RFC3715, "IPsec-Network Address Translation (NAT) Compatibility Requirements", March 2004

Source of RFC: ipsec (sec)

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.


RFC3720, "Internet Small Computer Systems Interface (iSCSI)", April 2004

Note: This RFC has been obsoleted by RFC7143

Source of RFC: ips (tsv)

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


RFC3728, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", February 2004

Source of RFC: adslmib (ops)

Errata ID: 1791

Status: Verified
Type: Technical

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.


RFC3730, "Extensible Provisioning Protocol (EPP)", March 2004

Note: This RFC has been obsoleted by RFC4930

Source of RFC: provreg (app)

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 :-).


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:


RFC3733, "Extensible Provisioning Protocol (EPP) Contact Mapping", March 2004

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>


RFC3736, "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", April 2004

Source of RFC: dhc (int)

Errata ID: 3796

Status: Verified
Type: Technical

Reported By: Ralph Droms
Date Reported: 2013-11-11
Verifier Name: Ted Lemon
Date Verified: 2014-03-02

Section 5.2 says:

   Client message: sent by a DHCP relay agent in a Relay-forward message
                   to carry the client message to a server (section 20)

   Server message: sent by a DHCP server in a Relay-reply message to
                   carry a response message to the relay agent (section
                   20)

It should say:

   Relay Message: sent by a DHCP relay agent in a Relay-forward
                  message to carry the client message to a server or
                  sent by a DHCP server in a Relay-reply message to
                  carry a response message to the relay agent (section
                  20)

Notes:

The correct name for the option carries in the Relay-forward message is "Relay Message". That option is shared by both Relay-forward and Relay-reply messages to carry a DHCPv6 message from or to (respectively) a DHCPv6 client.

I've marked this errata as "technical" because it might have an impact on implementations.


RFC3739, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", March 2004

Source of RFC: pkix (sec)

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.


RFC3741, "Exclusive XML Canonicalization, Version 1.0", March 2004

Source of RFC: xmldsig (sec)

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




RFC3742, "Limited Slow-Start for TCP with Large Congestion Windows", March 2004

Source of RFC: tsvwg (tsv)

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,


RFC3744, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", May 2004

Source of RFC: webdav (app)

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





RFC3770, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", May 2004

Note: This RFC has been obsoleted by 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).


RFC3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004

Source of RFC: pkix (sec)

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.


RFC3781, "Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)", May 2004

Source of RFC: INDEPENDENT

Errata ID: 733

Status: Verified
Type: Editorial

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))



RFC3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC6582

Source of RFC: tsvwg (tsv)

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:



RFC3783, "Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI", May 2004

Source of RFC: ips (tsv)

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.

RFC3798, "Message Disposition Notification", May 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC3811, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", June 2004

Source of RFC: mpls (rtg)

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.


RFC3813, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", June 2004

Source of RFC: mpls (rtg)

Errata ID: 228

Status: Verified
Type: Technical

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.


RFC3822, "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", July 2004

Source of RFC: ips (tsv)

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

RFC3829, "Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls", July 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 224

Status: Verified
Type: Technical

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:



RFC3830, "MIKEY: Multimedia Internet KEYing", August 2004

Source of RFC: msec (sec)

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.


RFC3834, "Recommendations for Automatic Responses to Electronic Mail", August 2004

Source of RFC: IETF - NON WORKING GROUP

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:




RFC3852, "Cryptographic Message Syntax (CMS)", July 2004

Note: This RFC has been obsoleted by RFC5652

Source of RFC: smime (sec)

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.


RFC3856, "A Presence Event Package for the Session Initiation Protocol (SIP)", August 2004

Source of RFC: INDEPENDENT

Errata ID: 3676

Status: Verified
Type: Technical

Reported By: Liangxing Wang
Date Reported: 2013-07-01
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 6.11.1 says:

In a presence edge server (where the PUA is co-located with the PUA),

It should say:

In a presence edge server (where the PA is co-located with the PUA),

Notes:

According to section 3 definitions, an edge presence server is a presence agent
that is co-located with a PUA.


RFC3863, "Presence Information Data Format (PIDF)", August 2004

Source of RFC: impp (app)

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.


RFC3866, "Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)", July 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 221

Status: Verified
Type: Technical

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.




RFC3877, "Alarm Management Information Base (MIB)", September 2004

Source of RFC: disman (ops)

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)


RFC3886, "An Extensible Message Format for Message Tracking Responses", September 2004

Source of RFC: msgtrk (app)

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".


RFC3887, "Message Tracking Query Protocol", September 2004

Source of RFC: msgtrk (app)

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: 3721

Status: Verified
Type: Technical

Reported By: Ned Freed
Date Reported: 2013-09-10
Verifier Name: Barry Leiba
Date Verified: 2013-09-11

Section 4.1 says:

S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status

It should say:

S: Content-Type: multipart/related; boundary=%%%%;
S:  type="message/tracking-status"

Notes:

According to RFC 2387 section 3.1, the value of the type parameter for
multipart/related is supposed to be the "MIME media type of the 'root' body
part." Additionaly, section 3 of RFC 3886 specifically states that the value is
supposed to be "message/tracking-status". But all seven examples in section 4.1
show just the subtype as the parameter value.

*** This errata report applies to all of the examples in Section 4.1 ***


RFC3920, "Extensible Messaging and Presence Protocol (XMPP): Core", October 2004

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.


RFC3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005

Source of RFC: l2tpext (int)

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: Verified
Type: Technical

Reported By: Stefan Puiu
Date Reported: 2008-05-30
Verifier Name: Brian Haberman
Date Verified: 2012-05-09

Section 4.5 says:

The LCCE then checks the Cookie field in the data packet against 
the Cookie value received in the Assigned Cookie AVP during session
establishment.

It should say:

The LCCE then checks the Cookie field in the data packet against 
the Cookie value sent in the Assigned Cookie AVP during session 
establishment.

Notes:

Section 5.4.4 contradicts this directly ("All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP"), and seems consistent with the rest of the 'assigned ...' fields.


Errata ID: 211

Status: Verified
Type: Editorial

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:




RFC3933, "A Model for IETF Process Experiments", November 2004

Source of RFC: IETF - NON WORKING GROUP

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.


RFC3939, "Calling Line Identification for Voice Mail Messages", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.



RFC3944, "H.350 Directory Services", December 2004

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC3945, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", October 2004

Source of RFC: ccamp (rtg)

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


RFC3954, "Cisco Systems NetFlow Services Export Version 9", October 2004

Source of RFC: INDEPENDENT

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: Verified
Type: Technical

Reported By: Paul Aitken
Date Reported: 2011-09-26
Verifier Name: Nevil Brownlee
Date Verified: 2012-03-12

Section 5.1 says:

   Source ID
         A 32-bit value that identifies the Exporter Observation Domain.
         NetFlow Collectors SHOULD use the combination of the source IP
         address and the Source ID field to separate different export
         streams originating from the same Exporter.

It should say:

   Source ID
         A 32-bit value that identifies the Exporter Observation Domain.
         NetFlow Collectors SHOULD use the combination of the source IP
         address, source port, and the Source ID field to separate different export
         streams originating from the same Exporter.

Notes:

Addition of "source port" to separate multiple export streams.

This is already addressed in RFC5101 (IPFIX) as so:

Collecting Processes SHOULD use the Transport Session and the
Observation Domain ID field to separate different export streams

NB transport session = address + ports.


RFC3958, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", January 2005

Source of RFC: IETF - NON WORKING GROUP

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.


RFC3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Source of RFC: krb-wg (sec)

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"

RFC3964, "Security Considerations for 6to4", December 2004

Source of RFC: v6ops (ops)

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


RFC3965, "A Simple Mode of Facsimile Using Internet Mail", December 2004

Source of RFC: fax (app)

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


RFC3966, "The tel URI for Telephone Numbers", December 2004

Source of RFC: iptel (rai)

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


RFC3971, "SEcure Neighbor Discovery (SEND)", March 2005

Source of RFC: send (int)

Errata ID: 3538

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.3 says:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, and Name fields), in units of 8 octets.

It should say:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, Name, and Padding fields), in units of 8 octets.

Notes:

mis-specification ?
Rationale: See the explanation for the 'Padding' field, at the bottom of page 35.


Errata ID: 3539

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.4 says:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Pad Length, and Certificate fields), in units of 8 octets.

It should say:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Reserved, Certificate, and Padding fields), in units of 8 octets.

Notes:

mis-specification ?

Rationale:
Apparently, there's no 'Pad Length' field in the Certificate Option;
the artwork on top of page 36 shows a 'Reserved' field in the same
octet where the Trust Anchor Option carries a 'Pad Length' field,
and the text contains a description of that 'Reserved' field.
According to the explanation for the 'Padding' field at the bottom
of page 36, the length of the 'Padding' field must be derived
implicitely from the ASN.1 encoding of the 'Certificate' field,
and the 'Length' field comprises the length of the 'Padding' field.

Note:
Because the extensible format potentially allows for other Cert Type
values and other Certificate encodings, I am in doubt whether the
decision to include a Reserved octet in place of a Pad Length octet
was very wise.
The current description of the 'Reserved' field will admit a future
revision of that decision.


Errata ID: 3540

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10

Section 6.4.5 says:

                                                  Future, backward-
|  compatible changes to the protocol may specify the contents of the
|  Reserved field or add new options; backward-incompatible changes may
   use different Code values.

It should say:

                                                  Future, backward-
|  compatible changes to the protocol MAY specify the contents of the
|  Reserved field or add new options; backward-incompatible changes MUST
   use different Code values.

Notes:

Section 6.4.5 vs. Section 6.4.6 -- contradiction!

Contrary to 6.4.5, the first paragraph of Section 6.4.6 says:

Future, backward-
compatible changes to the protocol MAY specify the contents of the
Reserved field or add new options; backward-incompatible changes MUST
use different Code values.

I suspect that the first "may" above should be a "MAY" and the second
"may" should have been a "MUST" as well.

If that's correct, the first paragraph of Section 6.4.5 should be corrected as above.


Errata ID: 2290

Status: Verified
Type: Technical

Reported By: Tony Cheneau
Date Reported: 2010-05-25
Verifier Name: Brian Haberman
Date Verified: 2012-10-04

Section 5.1 says:

CGA Parameters

  A variable-length field containing the CGA Parameters data
  structure described in Section 4 of [11].
                         ^^^^^^^^^

It should say:

CGA Parameters

  A variable-length field containing the CGA Parameters data
  structure described in Section 3 of [11].
                         ^^^^^^^^^

Notes:

The current text points to Section 4 of RFC 3972, which is "CGA Generation". I believe it should point to Section 3 that is "CGA Parameters and Hash Values".


RFC3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005

Source of RFC: pim (rtg)

Errata ID: 3271

Status: Verified
Type: Technical

Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Verifier Name: Adrian Farrel
Date Verified: 2012-08-22

Section 4.5.1 says:

if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

It should say:

if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to the Holdtime from an active Prune received on
         interface I. The Holdtime used SHOULD be the largest active one
         but MAY be the most recently received active Prune Holdtime.

Notes:

It is not clear what is meant by the "largest active holdtime", and in any event sec. 4.4.2.3 specifies a slightly different rule:

Send State Refresh(S,G) out interface I
The router has refreshed the Prune(S,G) state on interface I.
The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
from an active Prune received on interface I. The Holdtime used
SHOULD be the largest active one but MAY be the most recently
received active Prune Holdtime.

Additionally...
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).

The concept of an "active Prune" is not defined in this RFC, but simply means those prunes which have not expired.


Errata ID: 967

Status: Verified
Type: Editorial

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.


RFC3977, "Network News Transfer Protocol (NNTP)", October 2006

Source of RFC: nntpext (app)

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: 2720

Status: Verified
Type: Technical

Reported By: Julien Élie
Date Reported: 2011-02-15
Verifier Name: Barry Leiba
Date Verified: 2012-05-12

Section 9.4.3 says:

   This syntax defines the content of the various multi-line responses;
   more precisely, it defines the part of the response in the multi-line
   data block after any "dot-stuffing" has been undone.  The numeric
|  portion of each non-terminal name indicates the response code that is
   followed by this data.

It should say:

   This syntax defines the content of the various multi-line responses;
   more precisely, it defines the part of the response in the multi-line
   data block after any "dot-stuffing" has been undone.  The numeric
|  portion of each non-terminal name indicates the response code of the
|  initial-response-line that is followed by this data.

Notes:

The last sentence in the RFC text is misleading; there may be (and in fact, in several cases — cf. Section 9.4.2, there indeed are) response-arguments between the response code and the data specified by the multi-line-response-content production.

First reported by Alfred Hönes.


Errata ID: 1533

Status: Verified
Type: Editorial

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.


RFC3978, "IETF Rights in Contributions", March 2005

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.



RFC3981, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", January 2005

Source of RFC: crisp (app)

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:



RFC3982, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", January 2005

Source of RFC: crisp (app)

Errata ID: 1305

Status: Verified
Type: Technical

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.


RFC3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC3987, "Internationalized Resource Identifiers (IRIs)", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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&#233";

It should say:

[semicolon inside]
"http://example.org/ros&#233;"

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


RFC3998, "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", March 2005

Source of RFC: ipp (app)

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”.


RFC4004, "Diameter Mobile IPv4 Application", August 2005

Source of RFC: aaa (ops)

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: 3234

Status: Verified
Type: Editorial

Reported By: Kurt Wimmer
Date Reported: 2012-05-28
Verifier Name: Benoit Claise
Date Verified: 2012-06-06

Section 7 says:

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Home-Agent-  348  7.11    DiamIdent  | M  |  P  |    |  V  | N  |
     Host


It should say:

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Home-Agent-  348  7.11    Grouped    | M  |  P  |    |  V  | N  |
     Host


Notes:

The Value Type for MIP-Home-Agent-Host should be Grouped, but the table in section 7 says DiamIdent.

Section 7.11 MIP-Home-Agent-Host AVP says it is grouped, the text in 4004 indicates it is grouped.

RFC 5447 further clarifies that MIP-Home-Agent-Host is a grouped AVP.


RFC4010, "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)", February 2005

Source of RFC: smime (sec)

Errata ID: 3865

Status: Verified
Type: Technical

Reported By: Russ Housley
Date Reported: 2014-01-10
Verifier Name: Sean Turner
Date Verified: 2014-01-12

Section Appendix A. says:

     SeedEncryptionAlgorithmInCMS
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) }

It should say:

     SeedEncryptionAlgorithmInCMS
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs9(9) smime(16) modules(0) id-mod-cms-seed(25) }

Notes:

The value assigned for id-mod-cms-seed in 25, not 24. This error will not impact interoperability, but it could impact developers using some ASN.1 tools.


RFC4013, "SASLprep: Stringprep Profile for User Names and Passwords", February 2005

Source of RFC: sasl (sec)

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.


RFC4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005

Source of RFC: sip (rai)

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: 3614

Status: Verified
Type: Technical

Reported By: José María González Calabozo
Date Reported: 2013-05-06
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-05-21

Section 13 says:

   Record-Route: sips:p1.atlanta.example.com;lr
   Route: sips:p1.atlanta.example.com;lr

It should say:

   Record-Route: <sips:p1.atlanta.example.com;lr>
   Route: <sips:p1.atlanta.example.com;lr>

Notes:

In the examples, all the Record-Route and Route headers are wrong.

They are:
Record-Route: sips:p1.atlanta.example.com;lr
Route: sips:p1.atlanta.example.com;lr

But according with the section "25.1 Basic Rules" of RFC3261 those headers are defined as:

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )

So the headers should be:
Record-Route: <sips:p1.atlanta.example.com;lr>
Route: <sips:p1.atlanta.example.com;lr>


RFC4029, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", March 2005

Source of RFC: v6ops (ops)

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.




RFC4033, "DNS Security Introduction and Requirements", March 2005

Source of RFC: dnsext (int)

Errata ID: 3043

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

RFC 4033, 4034 and 4035 all list 3007 as being updated but none of them update 3007.


RFC4034, "Resource Records for the DNS Security Extensions", March 2005

Source of RFC: dnsext (int)

Errata ID: 1062

Status: Verified
Type: Technical

Reported By: Peter Koch
Date Reported: 2005-09-13
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 6.2 says:

   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;

It should say:

[not supplied]

Notes:

Compare with RFC 3597 (section 7):

"As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6."

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.


Errata ID: 3045

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

4033, 4034 and 4035 all list 3007 as being updated but none do so.


Errata ID: 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).


RFC4035, "Protocol Modifications for the DNS Security Extensions", March 2005

Source of RFC: dnsext (int)

Errata ID: 3044

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

4033, 4034 and 4035 all list 3007 as being updated but none update 3007


RFC4043, "Internet X.509 Public Key Infrastructure Permanent Identifier", May 2005

Source of RFC: pkix (sec)

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:



RFC4048, "RFC 1888 Is Obsolete", April 2005

Source of RFC: IETF - NON WORKING GROUP

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


RFC4051, "Additional XML Security Uniform Resource Identifiers (URIs)", April 2005

Note: This RFC has been obsoleted by RFC6931

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 191

Status: Verified
Type: Technical

Reported By: Donald Eastlake III
Date Reported: 2005-11-08

Section 2.3.5 says:

Identifier:
  http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160

...

<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />

It should say:

Identifier:
  http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160

...

<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160" />

Notes:

In Section 2.3.5, the two URLs should have their right-most slash ("/") replaced with a pound sign ("#").


RFC4052, "IAB Processes for Management of IETF Liaison Relationships", April 2005

Source of RFC: IAB

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.



RFC4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", June 2005

Source of RFC: pkix (sec)

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".


RFC4057, "IPv6 Enterprise Network Scenarios", June 2005

Source of RFC: v6ops (ops)

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.


RFC4060, "RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding", May 2005

Source of RFC: avt (rai)

Errata ID: 188

Status: Verified
Type: Editorial

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. 


RFC4106, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", June 2005

Source of RFC: ipsec (sec)

Errata ID: 1919

Status: Verified
Type: Editorial

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.


RFC4111, "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005

Source of RFC: l3vpn (int)

Errata ID: 3143

Status: Verified
Type: Editorial

Reported By: Adam Roach
Date Reported: 2012-02-29
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 14 says:

   [RFC3889]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 3889, October 2004.

It should say:

   [RFC4593]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 4593, October 2006.

Notes:

Although the cited document appears to have reached the AUTH48 stage in 2004 and was provisionally assigned an RFC number of 3889, it was withdrawn for further editing and was never actually published under that number. Its eventual publication in 2006 was under the RFC number 4593.


RFC4114, "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", June 2005

Source of RFC: enum (rai)

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.


RFC4117, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", June 2005

Source of RFC: sipping (rai)

Errata ID: 185

Status: Verified
Type: Editorial

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------------------->|


RFC4119, "A Presence-based GEOPRIV Location Object Format", December 2005

Source of RFC: geopriv (rai)

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: 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.


RFC4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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: 3641

Status: Verified
Type: Technical

Reported By: Douglas Ray
Date Reported: 2013-06-06
Verifier Name: Barry Leiba
Date Verified: 2013-06-06

Throughout the document, when it says:

Advice on generating cryptographic-quality random numbers can be
   found in RFC1750 [5].

It should say:

Advice on generating cryptographic-quality random numbers can be
   found in RFC4086 [5].

Notes:

(Above sample is from section 4.5).
References to RFC 1750 should currently refer to RFC 4086.
(Likewise in Appendix A.)
The note [5] actually references RFC4086, but this is the only
point that is updated, ie, the document is inconsistent in its references.
The references in Appendix A are not cross-referenced to note [5].

------------------------ Verifier notes ------------------------
This is correct: reference [5] was updated to point to 4086, but the text in the
document body was not changed accordingly.


Errata ID: 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: 3476

Status: Verified
Type: Editorial

Reported By: Simon Kissane
Date Reported: 2013-02-02
Verifier Name: Barry Leiba
Date Verified: 2013-02-03

Section Appendix A,B says:

In Appendix A, the line:
    uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
In Appendix B, the line:
     uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f

It should say:

In Appendix A, the line:
    uuid_create_md5_from_name(&u, NameSpace_DNS, "www.example.com", 15);
In Appendix B, the line:
     uuid_create_md5_from_name(): 5df41881-3aed-3515-88a7-2f4a814cf09e

Notes:

Per RFC2606 section 5, it is best practice for standards and other documentation (including RFCs) to use the reserved example domains (e.g. example.com) rather than domains which could be in actual use. Indeed, the domain in question (www.widgets.com) is in actual use at the time of writing. So this proposed change uses "www.example.com" instead, and changes the example output accordingly. (Note that original output was wrong for the original input, as already noted in verified errata 1352.)


RFC4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005

Source of RFC: ediint (app)

Errata ID: 3028

Status: Verified
Type: Technical

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: 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".


RFC4133, "Entity MIB (Version 3)", August 2005

Note: This RFC has been obsoleted by RFC6933

Source of RFC: entmib (ops)

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.

RFC4134, "Examples of S/MIME Messages", July 2005

Source of RFC: smime (sec)

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.


RFC4141, "SMTP and MIME Extensions for Content Conversion", November 2005

Source of RFC: fax (app)

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


RFC4143, "Facsimile Using Internet Mail (IFAX) Service of ENUM", November 2005

Source of RFC: fax (app)

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.)


RFC4147, "Proposed Changes to the Format of the IANA IPv6 Registry", August 2005

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 179

Status: Verified
Type: Editorial

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.


RFC4151, "The 'tag' URI Scheme", October 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC4171, "Internet Storage Name Service (iSNS)", September 2005

Source of RFC: ips (tsv)

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


RFC4181, "Guidelines for Authors and Reviewers of MIB Documents", September 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

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


RFC4182, "Removing a Restriction on the use of MPLS Explicit NULL", September 2005

Source of RFC: mpls (rtg)

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.


RFC4186, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

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


RFC4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

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


RFC4188, "Definitions of Managed Objects for Bridges", September 2005

Source of RFC: bridge (ops)

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


RFC4207, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", October 2005

Source of RFC: ccamp (rtg)

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.


RFC4217, "Securing FTP with TLS", October 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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


RFC4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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


RFC4227, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", January 2006

Source of RFC: IETF - NON WORKING GROUP

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.


RFC4230, "RSVP Security Properties", December 2005

Source of RFC: nsis (tsv)

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


RFC4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005

Note: This RFC has been obsoleted by RFC5234

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

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.


RFC4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", November 2005

Source of RFC: sipping (rai)

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: 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.


RFC4237, "Voice Messaging Directory Service", October 2005

Source of RFC: vpim (app)

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.

RFC4238, "Voice Message Routing Service", October 2005

Source of RFC: vpim (app)

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.]


RFC4241, "A Model of IPv6/IPv4 Dual Stack Internet Access Service", December 2005

Source of RFC: INDEPENDENT

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: 3462

Status: Verified
Type: Technical

Reported By: Pengfei Liu
Date Reported: 2013-01-16
Verifier Name: Nevil Brownlee
Date Verified: 2014-02-03

Section 3 says:

          |---Configure-Request-->| \
          |<--Configure-Request---|  |
          |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
          |<----Configure-Ack-----|  | (IPCP)
          |---Configure-Request-->|  |
          |<----Configure-Ack-----| /

It should say:

          |---Configure-Request-->| \
          |<--Configure-Request---|  |
          |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
          |-----Configure-Ack---->|  | (IPCP)
          |---Configure-Request-->|  |
          |<----Configure-Ack-----| /

Notes:

Wrong IPCP process in Figure 2.
In the IPCP phase of original Figure 2, there're both Configure-Nak and Configure-Ack for the first Configure-Request and it's impossible. The first Configure-Ack in IPCP phase of original Figure 2 should be sent to PE from CPE.


Errata ID: 153

Status: Verified
Type: Editorial

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.


RFC4253, "The Secure Shell (SSH) Transport Layer Protocol", January 2006

Source of RFC: secsh (sec)

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).


RFC4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006

Source of RFC: secsh (sec)

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


RFC4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006

Source of RFC: secsh (sec)

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.


RFC4268, "Entity State MIB", November 2005

Source of RFC: entmib (ops)

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


RFC4270, "Attacks on Cryptographic Hashes in Internet Protocols", November 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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."


RFC4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006

Source of RFC: idr (rtg)

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: 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.


RFC4281, "The Codecs Parameter for "Bucket" Media Types", November 2005

Note: This RFC has been obsoleted by RFC6381

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: tsv

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 ":="


RFC4282, "The Network Access Identifier", December 2005

Source of RFC: radext (ops)

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>.


RFC4286, "Multicast Router Discovery", December 2005

Source of RFC: magma (int)

Errata ID: 142

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 3.1.2 says:

  3.1.2.  AdvertisementJitter

     This is the maximum time (in seconds) by which the
     AdvertisementInterval is perturbed for each unsolicited
     Advertisement.  Note that the purpose of this jitter is to avoid
     synchronization of multiple routers on a network, hence choosing a
     value of zero is discouraged.  This value MUST be an integer no less
     than 0 seconds and no greater than AdvertisementInterval.

     The AdvertisementJitter MUST be  0.025*AdvertisementInterval .

It should say:

  3.1.2.  AdvertisementJitter

     This is the maximum time (in seconds) by which the
     AdvertisementInterval is perturbed for each unsolicited
     Advertisement.  Note that the purpose of this jitter is to avoid
     synchronization of multiple routers on a network.
     The value of AdvertisementJitter is not independently configurable;
     it is a variable derived internally within the implementation
     from the configured value for AdvertisementInterval.

    The AdvertisementJitter MUST be set to 0.025*AdvertisementInterval.


RFC4287, "The Atom Syndication Format", December 2005

Source of RFC: atompub (app)

Errata ID: 3701

Status: Verified
Type: Editorial

Reported By: Amanda Baber
Date Reported: 2013-08-20
Verifier Name: Barry Leiba
Date Verified: 2013-08-20

Section 4.2.7.2 says:

http://www.iana.org/assignments/relation/

It should say:

http://www.iana.org/assignments/link-relations/

RFC4288, "Media Type Specifications and Registration Procedures", December 2005

Note: This RFC has been obsoleted by RFC6838

Source of RFC: IETF - NON WORKING GROUP

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


RFC4291, "IP Version 6 Addressing Architecture", February 2006

Source of RFC: ipv6 (int)

Errata ID: 3480

Status: Verified
Type: Technical

Reported By: Erik Hugne
Date Reported: 2013-02-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 2.7 says:

Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.

It should say:

Interface-Local scope spans only a single interface on a node 
and is useful only for loopback transmission of multicast.
Packets with interface-local scope received from another node 
must be discarded.

Notes:

It should be explicitly stated that interface-local scoped multicast packets
received from the link must be discarded.
The BSD implementation currently does this, but not Linux.
http://www.ietf.org/mail-archive/web/ipv6/current/msg17154.html


RFC4293, "Management Information Base for the Internet Protocol (IP)", April 2006

Source of RFC: ipv6 (int)

Errata ID: 140

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 3.2.11 says:

   The circumstances used in the compliance section are implementing
   IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
   than 20MB, between 20MB and 650MB, or greater than 650MB.

It should say:

   The circumstances used in the compliance section are implementing
   IPv4, IPv6, or IPv6 router functions and having a bandwidth of less
|  than 20Mbps, between 20Mbps and 650Mbps, or greater than 650Mbps.

Notes:

from pending


Errata ID: 3520

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsHCOctetGroup (p. 87) says:

           "This group is mandatory for systems that have an aggregate
            bandwidth of greater than 20MB.  Including this group does
            not allow an entity to neglect the 32 bit versions of these
            objects."

It should say:

           "This group is mandatory for systems that have an aggregate
|           bandwidth of greater than 20Mbps.  Including this group does
            not allow an entity to neglect the 32 bit versions of these
            objects."

Notes:

from pending


Errata ID: 3529

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsOutFragCreates OBJECT-TYPE (p. 53) says:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
|           created datagram fragment.

            [...]

Notes:

improperly replicated description text.
A "mirror" of Errata ID 3526 recurs, for the Interface Statistics.


Errata ID: 3521

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsHCPacketGroup (p. 87-88) says:

           "This group is mandatory for systems that have an aggregate
            bandwidth of greater than 650MB.  Including this group
            does not allow an entity to neglect the 32 bit versions of
            these objects."

It should say:

           "This group is mandatory for systems that have an aggregate
|           bandwidth of greater than 650Mbps.  Including this group
            does not allow an entity to neglect the 32 bit versions of
            these objects."

Notes:

from pending


Errata ID: 3522

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsHCOctetGroup (p. 88) says:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
            than 20MB.  Including this group does not allow an entity to
            neglect the 32 bit versions of these objects."

It should say:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
|           than 20Mbps.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

Notes:

from pending


Errata ID: 3523

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsHCPacketGroup (p. 88) says:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
            than 650MB.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

It should say:

           "This group is mandatory for systems that include the
            ipIfStatsGroup and include links with bandwidths of greater
|           than 650Mbps.  Including this group does not allow an entity
            to neglect the 32 bit versions of these objects."

Notes:

from pending


Errata ID: 3524

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipv4SystemStatsHCPacketGroup (p. 88) says:

           "This group is mandatory for all systems supporting IPv4 and
            that have an aggregate bandwidth of greater than 650MB.
            Including this group does not allow an entity to neglect the
            32 bit versions of these objects."

It should say:

           "This group is mandatory for all systems supporting IPv4 and
|           that have an aggregate bandwidth of greater than 650Mbps.
            Including this group does not allow an entity to neglect the
            32 bit versions of these objects."

Notes:

from pending


Errata ID: 3525

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION of the ipSystemStatsOutFragReqds and OBJECT-TYPE (p. 35) says:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
            fragmented datagram.

            [...]

It should say:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a datagram requiring
|           fragmentation.

            [...]

Notes:

The DESCRIPTION clauses of the ipSystemStatsOutFragReqds OBJECT-TYPE and the ipSystemStatsOutFragOKs OBJECT-TYPE erroneously contain identical clauses. After analysis of the context it becomes apparent that the DESCRIPTION clause of the ipSystemStatsOutFragReqds OBJECT-TYPE should be updated as above. (Note: The original text is appropriate in the DESCRIPTION clause of the ipSystemStatsOutFragOKs OBJECT-TYPE, where it appears again.)


Errata ID: 3526

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipSystemStatsOutFragCreates (p. 36) says:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of output datagram fragments that have been
            generated as a result of IP fragmentation.

            When tracking interface statistics, the counter of the
            outgoing interface is incremented for a successfully
|           created datagram fragment.

            [...]

Notes:

improperly replicated description text.
Obviously, the second sentence contradicts the first one.
( Apparently, this is an un-edited copy from the DESCRIPTION clauses
mentioned above, in Errata ID 3525, that needs editing to be appropriate.)


Errata ID: 3527

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipIfStatsOutFragReqds OBJECT-TYPE (p. 52) says:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a successfully
|           fragmented datagram.

            [...]

It should say:

           "The number of IP datagrams that would require fragmentation
            in order to be transmitted.

            When tracking interface statistics, the counter of the
|           outgoing interface is incremented for a datagram requiring
|           fragmentation.

            [...]

Notes:

improperly replicated description text.
A "mirror" of Errata ID 3525 recurs, for the Interface Statistics.


Errata ID: 3530

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The DESCRIPTION clause of the ipAddressPrefixType OBJECT-TYPE (p. 60) says:

           "The address type of ipAddressPrefix."

It should say:

|          "The address type of ipAddressPrefixPrefix."

Notes:

mentions an object that does not exist in the MIB module.


Errata ID: 2526

Status: Verified
Type: Editorial

Reported By: Raphael Garti
Date Reported: 2010-09-19
Verifier Name: Brian Haberman
Date Verified: 2012-04-26

Section 5 (p.76) says:

ipDefaultRouterLifetime OBJECT-TYPE
    SYNTAX     Unsigned32 (0..65535)
    UNITS      "seconds"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The remaining length of time, in seconds, that this router
            will continue to be useful as a default router.  A value of
            zero indicates that it is no longer useful as a default
            router.  It is left to the implementer of the MIB as to
            whether a router with a lifetime of zero is removed from the
            list.

            For IPv6, this value should be extracted from the router
            advertisement messages."
    REFERENCE "For IPv6 RFC 2462 sections 4.2 and 6.3.4"
    ::= { ipDefaultRouterEntry 4 }

It should say:

ipDefaultRouterLifetime OBJECT-TYPE
    SYNTAX     Unsigned32 (0..65535)
    UNITS      "seconds"
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The remaining length of time, in seconds, that this router
            will continue to be useful as a default router.  A value of
            zero indicates that it is no longer useful as a default
            router.  It is left to the implementer of the MIB as to
            whether a router with a lifetime of zero is removed from the
            list.

            For IPv6, this value should be extracted from the router
            advertisement messages."
    REFERENCE "For IPv6 RFC 2461 sections 4.2 and 6.3.4"
    ::= { ipDefaultRouterEntry 4 }

Notes:

The REFERENCE clause of ipDefaultRouterLifetime (p.76) refers to an RFC which does not contain the sections referred to. The correct reference should be to RFC 2461.


Errata ID: 3531

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-07-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

The ipDefaultRouterPreference OBJECT-TYPE (p. 76) says:

           "An indication of preference given to this router as a
            default router as described in he Default Router
            Preferences document.  [...]

and

    REFERENCE "RFC 4291, section 2.1"

It should say:

           "An indication of preference given to this router as a
|           default router as described in the Default Router
            Preferences document.  [...]

and                                        

|   REFERENCE "RFC 4191, section 2.1"

Notes:

two typos: he/the and 4291/4191.


RFC4294, "IPv6 Node Requirements", April 2006

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].


RFC4295, "Mobile IPv6 Management Information Base", April 2006

Source of RFC: mip6 (int)

Errata ID: 3548

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 5 says:

(in the DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, in the 12th line on page 28)

This object is a 64-bit version of mip6NodeOutOctets.

It should say:

This object is a 64-bit version of mip6NodeOutPkts.

Notes:

The DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, on page 28 of RFC 4295, apparently has been
cloned from another object without proper editing, and thus
refers to a wrong object, mip6NodeOutOctets, where it should
refer to the object, mip6NodeOutPkts.


Errata ID: 3553

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

 

The DESCRIPTION clause of the mip6CnCompliance MODULE-COMPLIANCE,
on page 94, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
|                  support monitoring of the basic correspondent node
|                  functionality.

This is the same description text as supplied for the
mip6CnCoreCompliance (on the same page), and hence does not
suffice to distinguish these two compliance statements.

The above text perhaps should say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and support
                   monitoring of the basic correspondent node
|                  functionality and per-MN BU traffic.

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending


RFC4296, "The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols", December 2005

Source of RFC: rddp (tsv)

Errata ID: 136

Status: Verified
Type: Technical

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.


RFC4301, "Security Architecture for the Internet Protocol", December 2005

Source of RFC: ipsec (sec)

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


RFC4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

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.


RFC4303, "IP Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

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)


RFC4305, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", December 2005

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


RFC4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC5996

Source of RFC: ipsec (sec)

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.


RFC4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", December 2005

Source of RFC: ipsec (sec)

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).


RFC4308, "Cryptographic Suites for IPsec", December 2005

Source of RFC: ipsec (sec)

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.


RFC4314, "IMAP4 Access Control List (ACL) Extension", December 2005

Source of RFC: imapext (app)

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


RFC4319, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", December 2005

Source of RFC: adslmib (ops)

Errata ID: 796

Status: Verified
Type: Technical

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: 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: 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


RFC4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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').


RFC4326, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", December 2005

Source of RFC: ipdvb (int)

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


RFC4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 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.


RFC4330, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", January 2006

Note: This RFC has been obsoleted by RFC5905

Source of RFC: INDEPENDENT

Errata ID: 2263

Status: Verified
Type: Technical

Reported By: Scott Barnes
Date Reported: 2010-05-15
Verifier Name: Nevil Brownlee
Date Verified: 2013-05-23

Section 5 says:

4.  The server reply should be discarded if any of the LI, Stratum,
    or Transmit Timestamp fields is 0 or the Mode field is not 4
    (unicast) or 5 (broadcast).

It should say:

4.  The server reply should be discarded if any of the VN, Stratum, 
    or Transmit Timestamp fields is 0 or the Mode field is not 4 
    (unicast) or 5 (broadcast).

Notes:

Zero is a legal value for the LI field under normal conditions. Zero is not legal for VN field, however.


Errata ID: 2480

Status: Verified
Type: Technical

Reported By: Dave Higton
Date Reported: 2010-08-20
Verifier Name: Nevil Brownlee
Date Verified: 2013-03-20

Section 4 says:

      MSF        Rugby (UK) Radio 60 kHz

It should say:

      MSF        Anthorn (UK) Radio 60 kHz

Notes:

The MSF transmitter was relocated from Rugby to Anthorn, in Cumbria, on 2007 March 31. See http://www.npl.co.uk/science-+-technology/time-and-frequency/npl-ensures-accurate-uk-time-for-the-next-15-years

http://www.npl.co.uk/educate-explore/what-is-time/what-is-msf confirms this.


RFC4334, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", February 2006

Source of RFC: pkix (sec)

Errata ID: 122

Status: Verified
Type: Technical

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


RFC4340, "Datagram Congestion Control Protocol (DCCP)", March 2006

Source of RFC: dccp (tsv)

Errata ID: 974

Status: Verified
Type: Technical

Reported By: Eddie Kohler
Date Repor