RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4615 records.

Status: Verified (2160)

RFC 5, "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.

RFC 20, "ASCII format for network interchange", October 1969

Source of RFC: Legacy

Errata ID: 4217

Status: Verified
Type: Editorial

Reported By: John Levine
Date Reported: 2015-01-03
Verifier Name: Barry Leiba
Date Verified: 2015-01-05

Section 4.2 says:

      2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14
   as diacritical marks is described in Appendix A, A5.2
      3 These characters should not be used in international interchange
   without determining that there is agreement between sender and
   recipient.  (See Appendix B4.)

It should say:

     2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14
   as diacritical marks is described in Appendix A, A5.2, of X3.4-1968.
      3 These characters should not be used in international interchange
   without determining that there is agreement between sender and
   recipient.  (See Appendix B4 of X3.4-1968.)

Notes:

The appendixes are in the original standard, not the RFC.

In the abstract, it says "X3, 4-" rather than "X3.4-" which is surely an OCR or transcription error.

RFC 31, "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. 

RFC 33, "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.

RFC 640, "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

RFC 783, "TFTP Protocol (revision 2)", June 1981

Note: This RFC has been obsoleted by RFC 1350

Source of RFC: Legacy

Errata ID: 580

Status: Verified
Type: Editorial

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

RFC 791, "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.

RFC 792, "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).

RFC 793, "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"

RFC 804, "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.

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

Note: This RFC has been obsoleted by RFC 2822

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

RFC 868, "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.

RFC 879, "The TCP Maximum Segment Size and Related Topics", November 1983

Note: This RFC has been obsoleted by RFC 7805

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 4053

Status: Verified
Type: Editorial

Reported By: Susumu Endoh
Date Reported: 2014-07-17
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 14 says:

For example, if the IP Security option (11 octets) were in use and
the IP maximum datagram size remained at 576 octets, then the TCP
should send the MSS with a value of 525 (536-11).

It should say:

For example, if the IP Security option (11 octets) were in use and
the IP maximum datagram size remained at 576 octets, then the TCP
should send the MSS with a value of 524 (536-11-1).

Notes:

IP and TCP header must be multiple of 4 octets.

A side note: The value 11 for the IP security option is apparently copied from RFC 791 without considering that a padding to 32 bit word boundaries is required.

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

Source of RFC: Legacy

Errata ID: 570

Status: Verified
Type: Technical

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

In Section Frame Format:

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

It should say:

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

RFC 952, "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."

RFC 959, "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.

Errata ID: 4138

Status: Verified
Type: Editorial

Reported By: Eugene Adell
Date Reported: 2014-10-21
Verifier Name: Barry Leiba
Date Verified: 2014-11-27

Section 2.1 says:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, and to add some new
      optional commands.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification.

It should say:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, to add some new
      optional commands, and to remove obsolete ones.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      All commands for the mail service are now obsolete and removed
      from this FTP specification. These commands are MLFL, MAIL,
      MSND, MSOM, MSAM, MRSQ, MRCP.  The return codes used for the
      mail service are also removed: 151, 152, 354.  Return code 215
      is reassigned here to another use.

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification, as
      long as it does not use the obsolete commands.

Notes:

Before claiming the specification is compliant with the previous version, noting what is added is not enough; we need to note what was removed also.

RFC 994, "Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service", March 1986

Source of RFC: Legacy
Area Assignment: int

Errata ID: 4208

Status: Verified
Type: Technical

Reported By: Jean-Baptiste Cayrou
Date Reported: 2014-12-24
Verifier Name: Brian Haberman
Date Verified: 2015-03-09

Section 7.5.4 says:

7.5.4    Source Routing

   The source routing parameter specifies, either completely or partial-
   ly, the route to be taken from Source Network Address to Destination
   Network Address.

   Parameter Code:        1100 0101

It should say:

7.5.4    Source Routing

   The source routing parameter specifies, either completely or partial-
   ly, the route to be taken from Source Network Address to Destination
   Network Address.

   Parameter Code:        1100 1000

Notes:

The Source Routing (7.5.4) and the Security (7.5.3) options have the same parameter code.
See RFC926 7.5.4 for the correction.

RFC 1034, "Domain names - concepts and facilities", November 1987

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

RFC 1035, "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.

RFC 1036, "Standard for interchange of USENET messages", December 1987

Note: This RFC has been obsoleted by RFC 5536 RFC 5537

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.

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

Note: This RFC has been obsoleted by RFC 1155

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

RFC 1071, "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;

RFC 1122, "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| | | | |

Errata ID: 4446

Status: Verified
Type: Editorial

Reported By: Marek Perny
Date Reported: 2015-08-16
Verifier Name: RFC Editor
Date Verified: 2015-08-18

Section 1.1.1 says:

         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.1.3 on "Terminology".

It should say:

         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.3.3 on "Terminology".

Notes:

"Section 1.1.3" should be "Section 1.3.3".

RFC 1123, "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.

RFC 1150, "FYI on FYI: Introduction to the FYI Notes", March 1990

Note: This RFC has been obsoleted by RFC 6360

Source of RFC: Legacy

Errata ID: 3829

Status: Verified
Type: Editorial

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

Section 2 says:

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

It should say:

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

Notes:

spelling error

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

Source of RFC: Legacy

Errata ID: 2601

Status: Verified
Type: Editorial

Reported By: Vivek Gupta
Date Reported: 2010-11-03
Verifier Name: Dan Romascanu
Date Verified: 2010-11-04

Section 4.2 says:

Each such subject type is uniquely named by its OBJECT IDENTIFIER

It should say:

Each such object type is uniquely named by its OBJECT IDENTIFIER

Notes:

The word "subject" should be replaced by the word "object" in the referred context

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

Note: This RFC has been obsoleted by RFC 1213

Source of RFC: Legacy

Errata ID: 557

Status: Verified
Type: Technical

Reported By: Vincent Berger
Date Reported: 2002-03-27

Section 5.4.2 says:

   egp(5),
   ggp(6),
   hello(7),
   rip(8),
   is-is(9),
   es-is(10),
   ciscoIgrp(11),
   bbnSpfIgp(12),
   ospf(13)
   bgp(14)

It should say:

   egp(5),
   ggp(6),
   hello(7),
   rip(8),
   is-is(9),
   es-is(10),
   ciscoIgrp(11),
   bbnSpfIgp(12),
   ospf(13),
   bgp(14)

RFC 1180, "TCP/IP tutorial", January 1991

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

RFC 1258, "BSD Rlogin", September 1991

Note: This RFC has been obsoleted by RFC 1282

Source of RFC: Legacy

Errata ID: 2772

Status: Verified
Type: Editorial

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Verifier Name: ron bonica
Date Verified: 2011-10-12

Throughout the document, when it says:


Notes:

RFC 1258 is obsoleted by RFC 1282, that is clearly stated in the last document. However no such entry was added to RFC Editor database. It should be added once this errata report is verified.

RFC 1319, "The MD2 Message-Digest Algorithm", April 1992

Note: This RFC has been obsoleted by RFC 6149

Source of RFC: pem (sec)

Errata ID: 554

Status: Verified
Type: Technical

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.

RFC 1320, "The MD4 Message-Digest Algorithm", April 1992

Note: This RFC has been obsoleted by RFC 6150

Source of RFC: pem (sec)

Errata ID: 2163

Status: Verified
Type: Technical

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

RFC 1321, "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). */

RFC 1340, "Assigned Numbers", July 1992

Note: This RFC has been obsoleted by RFC 1700

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.


RFC 1345, "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...

RFC 1349, "Type of Service in the Internet Protocol Suite", July 1992

Note: This RFC has been obsoleted by RFC 2474

Source of RFC: rreq (rtg)

Errata ID: 4456

Status: Verified
Type: Technical

Reported By: Anton
Date Reported: 2015-08-26
Verifier Name: Alvaro Retana
Date Verified: 2015-08-26

Section 7.1 says:

where type 1 entries result from the receipt of code 3 (or code 1)
Redirects and type 2 entries result from the receipt of code 2 (or
code 0) Redirects.

It should say:

where type 1 entries result from the receipt of code 3 (or code 2)
Redirects and type 2 entries result from the receipt of code 1 (or
code 0) Redirects.

Notes:

I think that original text has no sense, especially considering that routers MUST NOT send 0 and 2 Redirects, type 2 routing entries has no chance to occur. Sorry if I'm mistaking and not fully understand ideas behind RFC 1349
=====
(Alvaro Retana) The report and correction are valid. I did edit them for completeness.

RFC 1361, "Simple Network Time Protocol (SNTP)", August 1992

Note: This RFC has been obsoleted by RFC 1769

Source of RFC: Legacy
Area Assignment: int

Errata ID: 3905

Status: Verified
Type: Editorial

Reported By: J. Stals
Date Reported: 2014-02-18
Verifier Name: Brian Haberman
Date Verified: 2014-05-16

Section 4 says:

(original NTP described in RFC-959) messages are no longer supported.

It should say:

(original NTP described in RFC-958) messages are no longer supported.

Notes:

RFC959 is the FTP protocol, not NTP version 0 (RFC958). It should be noted that RFC 1361 is obsolete.

RFC 1413, "Identification Protocol", February 1993

Source of RFC: ident (sec)

Errata ID: 548

Status: Verified
Type: Editorial

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

Section 6 says:

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

It should say:

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

RFC 1459, "Internet Relay Chat Protocol", May 1993

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4091

Status: Verified
Type: Technical

Reported By: Peter Kovacs
Date Reported: 2014-08-23
Verifier Name: Barry Leiba
Date Verified: 2014-09-17

Section 2.3 says:

The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which must be the first character of the
   message itself.

It should say:

The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3a), which must be the first character of the
   message itself.

Notes:

The ASCII colon character is represented by 0x3A, not 0x3B (which is the semicolon).

Errata ID: 4318

Status: Verified
Type: Editorial

Reported By: Lucas Satabin
Date Reported: 2015-03-31
Verifier Name: Barry Leiba
Date Verified: 2015-04-02

Section 1.3 says:

There are two types of channels allowed by this protocol.  One is a
distributed channel which is known to all the servers that are
connected to the network. These channels are marked by the first
character being a only clients on the server where it exists may join
it.  These are distinguished by a leading '&' character.

It should say:

There are two types of channels allowed by this protocol.  One is a
distributed channel, which is known to all the servers that are
connected to the network. These channels are marked by the first
character being a '#'.  The other type of channel is limited to one
server, and only clients on the server where it exists may join
it.  These channels are distinguished by a leading '&' character.

Notes:

There is a missing chunk of text between "being a" and "only clients".

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

Source of RFC: IESG ()

Errata ID: 547

Status: Verified
Type: Technical

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

Section 1 says:

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

It should say:

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

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

Note: This RFC has been obsoleted by RFC 4632

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

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

Source of RFC: Legacy

Errata ID: 1755

Status: Verified
Type: Editorial

Reported By: Samuel Bronson
Date Reported: 2009-04-03
Verifier Name: ron bonica
Date Verified: 2011-10-12

Section B says:

         # Mailcap file for Bellcore lab 214.
         #
         # The next line sends "richtext" to the richtext
         program
         text/richtext; richtext %s; copiousoutput
         #
         # Next, basic u-law audio
         audio/*; showaudio; test=/usr/local/bin/hasaudio
         #
         # Next, use the xview program to handle several image
         formats
         image/*; xview %s; test=/usr/local/bin/RunningX
         #
         # The ATOMICMAIL interpreter uses curses, so needs a
         terminal
         application/atomicmail; /usr/local/bin/atomicmail %s; \
             needsterminal
         #
         # The next line handles Andrew format,
         #   if ez and ezview are installed
         x-be2; /usr/andrew/bin/ezview %s; \
            print=/usr/andrew/bin/ezprint %s ; \
            compose=/usr/andrew/bin/ez -d %s \;
            edit=/usr/andrew/bin/ez -d %s; \;
            copiousoutput
         #
         # The next silly example demonstrates the use of
         quoting
         application/*; echo "This is \"%t\" but \
            is 50 \% Greek to me" \; cat %s; copiousoutput

It should say:

         # Mailcap file for Bellcore lab 214.
         #
         # The next line sends "richtext" to the richtext
         # program
         text/richtext; richtext %s; copiousoutput
         #
         # Next, basic u-law audio
         audio/*; showaudio; test=/usr/local/bin/hasaudio
         #
         # Next, use the xview program to handle several image
         # formats
         image/*; xview %s; test=/usr/local/bin/RunningX
         #
         # The ATOMICMAIL interpreter uses curses, so needs a
         # terminal
         application/atomicmail; /usr/local/bin/atomicmail %s; \
             needsterminal
         #
         # The next line handles Andrew format,
         #   if ez and ezview are installed
         x-be2; /usr/andrew/bin/ezview %s; \
            print=/usr/andrew/bin/ezprint %s ; \
            compose=/usr/andrew/bin/ez -d %s \;
            edit=/usr/andrew/bin/ez -d %s; \;
            copiousoutput
         #
         # The next silly example demonstrates the use of
         # quoting
         application/*; echo "This is \"%t\" but \
            is 50 \% Greek to me" \; cat %s; copiousoutput

Notes:

Some comment lines in the example termcap file appear to have improperly reformatted to fit the 78-character limit; the needed "# " was ommitted.

RFC 1531, "Dynamic Host Configuration Protocol", October 1993

Note: This RFC has been obsoleted by RFC 1541

Source of RFC: dhc (int)

Errata ID: 546

Status: Verified
Type: Technical

Reported By: Jim Withnall
Date Reported: 2001-10-31

Section 4.4.4 says:

   Any DHCPACK messages that arrive with an 'xid' that does not match the
   When the client receives a DHCPACK from the server, the client
   computes the lease expiration time as the sum of the time at which the
   client sent the DHCPREQUEST message and the duration of the lease in
   the DHCPACK message.

It should say:

   Any DHCPACK messages that arrive with an 'xid' that does not match the
   'xid' of the client's DHCPREQUEST message are silently discarded.
   When the client receives a DHCPACK from the server, the client
   computes the lease expiration time as the sum of the time at which the
   client sent the DHCPREQUEST message and the duration of the lease in
   the DHCPACK message.  

RFC 1534, "Interoperation Between DHCP and BOOTP", October 1993

Source of RFC: dhc (int)

Errata ID: 545

Status: Verified
Type: Technical

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

Section 2 says:

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

It should say:

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

RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol", October 1993

Source of RFC: Legacy

Errata ID: 544

Status: Verified
Type: Technical

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

Section 3.1.1 says:

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

It should say:

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

Notes:

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

RFC 1628, "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.

RFC 1661, "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.

RFC 1662, "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.

RFC 1685, "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.

RFC 1724, "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,

RFC 1725, "Post Office Protocol - Version 3", November 1994

Note: This RFC has been obsoleted by RFC 1939

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.

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

Note: This RFC has been obsoleted by RFC 4271

Source of RFC: Legacy

Errata ID: 539

Status: Verified
Type: Technical

Reported By: Pete Young
Date Reported: 2003-10-01

Section 4.3 says:

Total Path Attribute Length:

          This 2-octet unsigned integer indicates the total length of
	  the Path Attributes field in octets.  Its value must allow
	  the length of the Network Layer Reachability field to be
	  determined as specified below. 

          A value of 0 indicates that no Network Layer Reachability
          Information field is present in this UPDATE message.

It should say:

          A value of 0 indicates that the Path Attributes field is
	  not present in this UPDATE message.

RFC 1810, "Report on MD5 Performance", June 1995

Source of RFC: Legacy

Errata ID: 1059

Status: Verified
Type: Editorial

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

In the References, it says:

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

It should say:

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

Notes:

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

RFC 1812, "Requirements for IP Version 4 Routers", June 1995

Source of RFC: rreq (rtg)

Errata ID: 537

Status: Verified
Type: Editorial

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.

RFC 1867, "Form-based File Upload in HTML", November 1995

Note: This RFC has been obsoleted by RFC 2854

Source of RFC: html (app)

Errata ID: 536

Status: Verified
Type: Technical

Reported By: Dirk Nimmich
Date Reported: 2002-03-09

Every occurance of the string:

   , boundary=

It should say:

   ; boundary=

RFC 1878, "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

RFC 1891, "SMTP Service Extension for Delivery Status Notifications", January 1996

Note: This RFC has been obsoleted by RFC 3461

Source of RFC: notary (app)

Errata ID: 535

Status: Verified
Type: Editorial

Reported By: Florian Weimer
Date Reported: 2002-10-21

Section 6.2 says:

   DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
   be sent with a NULL return address ("reverse-path").

It should say:

   DISCUSSION: RFC 1123, section 5.3.3 requires error notifications to
   be sent with a NULL return address ("reverse-path"). 

Notes:

RFC 1123, section 2.3.3., does not exist. The correct section is 5.3.3.

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

Note: This RFC has been obsoleted by RFC 3464

Source of RFC: notary (app)

Errata ID: 534

Status: Verified
Type: Technical

Reported By: Bruce Lilly
Date Reported: 2002-02-25

Section 9.4 says:

   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
   Sun, 10 Jul 1994 00:36:51 +0100
   To: owner-info-mime@cs.utk.edu
   Date: Sun, 10 Jul 1994 00:36:51 +0100
   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
   content-type: multipart/report; report-type=delivery-status;
         boundary=foobar

It should say:

   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
             Sun, 10 Jul 1994 00:36:51 +0100
   To: owner-info-mime@cs.utk.edu
   Date: Sun, 10 Jul 1994 00:36:51 +0100
   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
   MIME-Version: 1.0
   content-type: multipart/report; report-type=delivery-status;
         boundary=foobar

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

Source of RFC: Legacy

Errata ID: 533

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2002-02-26

In the Title:

                           Variance for
               The PPP Connection Control Protocol
                               and
               The PPP Encryption Control Protocol

It should say:

                           Variance for
               The PPP Compression Control Protocol
                               and
               The PPP Encryption Control Protocol

RFC 1925, "The Twelve Networking Truths", April 1996

Source of RFC: Legacy

Errata ID: 532

Status: Verified
Type: Technical

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

Section 2 says:

   the word is "agglutinate", not "aglutenate"

RFC 1927, "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

RFC 1928, "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]

RFC 1936, "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.

RFC 1939, "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.

RFC 1959, "An LDAP URL Format", June 1996

Note: This RFC has been obsoleted by RFC 2255

Source of RFC: asid (app)

Errata ID: 528

Status: Verified
Type: Technical

Reported By: Kurt D. Zeilenga
Date Reported: 2001-02-07

Section 2 says:

   <dn> ::= a string as defined in RFC 1485

It should say:

   <dn> ::= a string as defined in RFC 1779

RFC 1979, "PPP Deflate Protocol", August 1996

Source of RFC: pppext (int)

Errata ID: 527

Status: Verified
Type: Technical

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

Section 3 says:

   Length

      3

It should say:

   Length

      4

RFC 1985, "SMTP Service Extension for Remote Message Queue Starting", August 1996

Source of RFC: Legacy

Errata ID: 4130

Status: Verified
Type: Editorial

Reported By: Michael Slusarz
Date Reported: 2014-10-13
Verifier Name: Barry Leiba
Date Verified: 2014-10-14

Section 5.2 says:

If one of the 500 level error codes (550 or 551) are sent, the client
should assume that the protocol is not supported in the remote host
or that the protocol has not been implemented correctly on either the
client or server host. 

It should say:

If one of the 500 level error codes (500 or 501) is sent, the client
should assume that the protocol is not supported in the remote host
or that the protocol has not been implemented correctly on either the
client or server host. 

Notes:

550 (mailbox unavailable) and 551 (user not local) are clearly not the codes intended here; this text is meant to refer to the two syntax error codes specified in Section 5.1.

RFC 1995, "Incremental Zone Transfer in DNS", August 1996

Source of RFC: dnsind (int)

Errata ID: 3197

Status: Verified
Type: Technical

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

Section 4, pg.3 says:

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

It should say:

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

Notes:

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

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

Source of RFC: Legacy

Errata ID: 526

Status: Verified
Type: Editorial

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

Section 5 says:

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

It should say:

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

RFC 2018, "TCP Selective Acknowledgment Options", October 1996

Source of RFC: tcplw (tsv)

Errata ID: 1610

Status: Verified
Type: Technical

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

Section 5.1 says:

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

It should say:

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

Notes:

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

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

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

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

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

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

Note: This RFC has been obsoleted by RFC 4502

Source of RFC: rmonmib (ops)

Errata ID: 525

Status: Verified
Type: Technical

Reported By: Frank McKiernan
Date Reported: 2002-06-25

The DESCRIPTION of probeDownloadAction uses the wrong INTEGER definitions for downloadToPROM and downloadToRAM. On page 92, it reads:

   probeDownloadAction  OBJECT-TYPE
    SYNTAX     INTEGER {
                  notDownloading(1),
                  downloadToPROM(2),
                  downloadToRAM(3)
               }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "When this object is set to downloadToRAM(2) or
        downloadToPROM(3), the device will discontinue its
        normal operation and begin download of the image specified
        by probeDownloadFile from the server specified by
        probeDownloadTFTPServer using the TFTP protocol.  If
        downloadToRAM(2) is specified, the new image is copied
        to RAM only (the old image remains unaltered in the flash
        EPROM).  If downloadToPROM(3) is specified
        the new image is written to the flash EPROM
        memory after its checksum has been verified to be correct.
        When the download process is completed, the device will
	warm boot to restart the newly loaded application.
        When the device is not downloading, this object will have
        a value of notDownloading(1)."
    ::= { probeConfig 8 }

It should say:

probeDownloadAction  OBJECT-TYPE
    SYNTAX     INTEGER {
                  notDownloading(1),
                  downloadToPROM(2),
                  downloadToRAM(3)
               }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "When this object is set to downloadToRAM(3) or
        downloadToPROM(2), the device will discontinue its
        normal operation and begin download of the image specified
        by probeDownloadFile from the server specified by
        probeDownloadTFTPServer using the TFTP protocol.  If
        downloadToRAM(3) is specified, the new image is copied
        to RAM only (the old image remains unaltered in the flash
        EPROM).  If downloadToPROM(2) is specified
        the new image is written to the flash EPROM
        memory after its checksum has been verified to be correct.
        When the download process is completed, the device will
        warm boot to restart the newly loaded application.
        When the device is not downloading, this object will have
        a value of notDownloading(1)."
    ::= { probeConfig 8 }

RFC 2026, "The Internet Standards Process -- Revision 3", October 1996

Source of RFC: poised95 (gen)

Errata ID: 522

Status: Verified
Type: Technical

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:

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

RFC 2028, "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.

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

Note: This RFC has been obsoleted by RFC 4330

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

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

Source of RFC: Legacy

Errata ID: 514

Status: Verified
Type: Technical

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.

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

Source of RFC: 822ext (app)

Errata ID: 2586

Status: Verified
Type: Technical

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.

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

Source of RFC: 822ext (app)

Errata ID: 507

Status: Verified
Type: Technical

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.

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

Source of RFC: 822ext (app)

Errata ID: 504

Status: Verified
Type: Technical

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.

RFC 2049, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", November 1996

Source of RFC: 822ext (app)

Errata ID: 3933

Status: Verified
Type: Technical

Reported By: Peter Occil
Date Reported: 2014-03-26
Verifier Name: Barry Leiba
Date Verified: 2014-05-07

Section 2 says:

    (10)  Conforming user agents must be able to distinguish
          encoded-words from "text", "ctext", or "word"s,
          according to the rules in section 4, anytime they
          appear in appropriate places in message headers.

It should say:

    (10)  Conforming user agents must be able to distinguish
          encoded-words from "text", "ctext", or "word"s,
          according to the rules in section 3.2.2 of [RFC5322], 
          any time they appear in appropriate places in 
          message headers.

Notes:

The correct reference at publication was Section 3.3 of RFC 822; Section 3.2.2 of RFC 5322 is currently correct. In any case, Section 4 of RFC 2049 was never right.

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

Note: This RFC has been obsoleted by RFC 3501

Source of RFC: Legacy

Errata ID: 503

Status: Verified
Type: Technical

Reported By: Mathieu Fenniak
Date Reported: 2002-05-28

Section 6.4.8 says:

   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
               S: A999 UID FETCH completed

It should say:

   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
               S: A999 OK UID FETCH completed

Notes:

A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata

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

Note: This RFC has been obsoleted by RFC 2617

Source of RFC: http (app)

Errata ID: 749

Status: Verified
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2005-02-06
Verifier Name: Alexey Melnikov
Date Verified: 2010-07-11

Section 2.4 says:

RfC 2069 (digest access authentication) chapter 2.4 is an example,
the userame is "Mufasa", the password is "CircleOfLife":

| username="Mufasa",
| realm="testrealm@host.com",
| nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
| uri="/dir/index.html",
| response="e966c932a9242554e42c8ee200cec7f6",
| opaque="5ccc069c403ebaf9f0171e9517f40e41"

The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 ))

MD5( A1 ) = MD5( username || ':' || realm || ':' || password )
          = MD5( "Mufasa:testrealm@host.com:CircleOfLife" )
          = "4945ecf42b1bb868634058a845bedde8"

MD5( A2 ) = MD5( Method || ':' || digest-uri-value )
          = MD5( "GET:/dir/index.html" )
          = "39aff3a2bab6126f332b942af96d3366"

This results in a response = "1949323746fe6a43ef61f9606e7febea"
instead of the shown value = "e966c932a9242554e42c8ee200cec7f6".

Quick reality check, the RFC 2617 example uses the same values
    username = "Mufasa"
    nonce    = "dcd98b7102dd2f0e8b11d0f600bfb0c093"
    realm    = "testrealm@host.com"
    A2       = "GET:/dir/index.html"
with a slightly different
    password = "Circle Of Life"
resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9"

The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 ))
for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth"
and here the response = "6629fae49393a05397450978507c4ef1" works as
expected.

It should say:

[not submitted]

Notes:

I've tried to contact two of the RFC 2069 authors about this issue,
but got no reply.

Alexey: note that this problem was addressed in RFC 2617.

RFC 2092, "Protocol Analysis for Triggered RIP", January 1997

Source of RFC: rip (rtg)

Errata ID: 502

Status: Verified
Type: Technical

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

Section 3.3. says:

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

It should say:

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

RFC 2104, "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:


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

Source of RFC: IETF - NON WORKING GROUP
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.

RFC 2127, "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 }

RFC 2131, "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.

RFC 2132, "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.

RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997

Source of RFC: dnsind (int)

Errata ID: 4469

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2015-09-09
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 3.4.2.2 says:

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

It should say:

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

Notes:

In the vice versa case it it not a CNAME Update RR, just a plain Update RR. Removing the word "CNAME" make the sentence cover both cases as intended.

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

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3982

Status: Verified
Type: Technical

Reported By: Peter Occil
Date Reported: 2014-05-08
Verifier Name: Pete Resnick
Date Verified: 2014-06-04

Section Definitions says:

               Character   ASCII & Unicode Value (decimal)

                 [...]       [...]

                  '           96

It should say:

               Character   ASCII & Unicode Value (decimal)

                 [...]       [...]

                  `           96

Notes:

The wrong character is used in the left column: code point 96 corresponds to "Grave Accent", not "Apostrophe".

Errata ID: 862

Status: Verified
Type: Editorial

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

In "UTF-7 Definition", it says:

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

It should say:

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

Notes:

missing word

RFC 2154, "OSPF with Digital Signatures", June 1997

Source of RFC: Legacy

Errata ID: 2081

Status: Verified
Type: Editorial

Reported By: Vishwas Manral
Date Reported: 2010-03-19
Verifier Name: Ross Callon
Date Verified: 2010-03-19

Section 5 says:

Because of these properties of OSFP routing, an AS can
   contain signed and unsigned areas, and achieve a predictable level of
   authentication.

It should say:

Because of these properties of OSPF routing, an AS can
   contain signed and unsigned areas, and achieve a predictable level of
   authentication.

Notes:

s/OSFP/OSPF

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

Source of RFC: Legacy

Errata ID: 485

Status: Verified
Type: Technical

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

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

Note: This RFC has been obsoleted by RFC 2231

Source of RFC: 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 "?="

RFC 2192, "IMAP URL Scheme", September 1997

Note: This RFC has been obsoleted by RFC 5092

Source of RFC: Legacy

Errata ID: 483

Status: Verified
Type: Editorial

Reported By: Chris Newman
Date Reported: 2005-02-09
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-18

Section 12 says:

     imessagelist     = enc_mailbox [ "?" enc_search ] [uidvalidity]

It should say:

     imessagelist     = enc_mailbox [uidvalidity] [ "?" enc_search ]

Notes:

Wrong order of fields

RFC 2196, "Site Security Handbook", September 1997

Source of RFC: ssh ()

Errata ID: 482

Status: Verified
Type: Editorial

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

RFC 2202, "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

RFC 2203, "RPCSEC_GSS Protocol Specification", September 1997

Source of RFC: oncrpc (tsv)

Errata ID: 4067

Status: Verified
Type: Editorial

Reported By: Benjamin Kaduk
Date Reported: 2014-07-30
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 5.1 says:

The client should assume that the server supports RPCSEC_GSS_VERS_1
and issue a Context Creation message (as described in the section
RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
AUTH_REJECTED_CRED.

It should say:

The client should assume that the server supports RPCSEC_GSS_VERS_1
and issue a Context Creation message (as described in the section
'Context Creation'). If the server does not support
RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
AUTH_REJECTED_CRED.

Notes:

This line was somehow lost in the transition from draft-ietf-oncrpc-rpcsec_gss-04 to RFC 2203.

RFC 2229, "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.]

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

Source of RFC: Legacy

Errata ID: 476

Status: Verified
Type: Technical

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

RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997

Note: This RFC has been obsoleted by RFC 4234

Source of RFC: drums (app)

Errata ID: 472

Status: Verified
Type: Technical

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.



RFC 2236, "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.

RFC 2241, "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

RFC 2244, "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.

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

Note: This RFC has been obsoleted by RFC 4510 RFC 4517 RFC 4523 RFC 4512

Source of RFC: asid (app)

Errata ID: 467

Status: Verified
Type: Technical

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

RFC 2254, "The String Representation of LDAP Search Filters", December 1997

Note: This RFC has been obsoleted by RFC 4510 RFC 4515

Source of RFC: asid (app)

Errata ID: 466

Status: Verified
Type: Technical

Reported By: Charles Bates
Date Reported: 2002-10-30

Section 4 says:

   greater = ">="

It should say:

   greater than or equal = ">="

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

Source of RFC: Legacy

Errata ID: 465

Status: Verified
Type: Technical

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

Section 6 says:

   RC2Version ::= INTEGER -- 1-1024

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

It should say:

   RC2Version ::= INTEGER -- 0-1024

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

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

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


RFC 2286, "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:


RFC 2308, "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".

Errata ID: 4489

Status: Verified
Type: Editorial

Reported By: Wes Hardaker
Date Reported: 2015-09-29
Verifier Name: Brian Haberman
Date Verified: 2015-10-14

In the References


It should say:

ADD:

[RFC2136]  P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
           Updates in the Domain Name System (DNS UPDATE)", 
           RFC 2136, April 1997.

-------

OR:  define SERVFAIL inside of the terminology section (section 1):

"SERVFAIL" - a name for the "Server failure" (2) RCODE described in
[RFC1035 Section 4.1.1].

Notes:

Section 2.1.1 uses the term SERVFAIL to reference DNS RCODE 2, but this term isn't defined in the document nor in the referenced documents. It's first defined in 2136 and thus the two options available are to either add a reference to 2136 or to add a definition of SERVFAIL to the document in the terminology section.

RFC 2324, "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......
=========================================

RFC 2325, "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", April 1998

Source of RFC: Legacy

Errata ID: 3993

Status: Verified
Type: Technical

Reported By: Jack Lawson
Date Reported: 2014-05-20
Verifier Name: Nevil Brownlee (ISE)
Date Verified: 2014-06-03

Section 4 says:

   potType OBJECT-TYPE
        SYNTAX     INTEGER {
           automatic-drip(1),
           percolator(2),
           french-press(3),
           espresso(4),
           }
        MAX-ACCESS read-write
        STATUS current
        DESCRIPTION
                "The brew type of the coffee pot."
        ::= { coffee 3 }

It should say:

   potType OBJECT-TYPE
        SYNTAX     INTEGER {
           automatic-drip(1),
           percolator(2),
           french-press(3),
           espresso(4),
           }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
                "The brew type of the coffee pot."
        ::= { coffee 3 }

Notes:

potName and potCapacity are read-only, as name and capacity will not change after instantiation; type should be as well, as potType will not change over time (reincarnation as a separate pot would constitute a new instance.) potLocation should remain read-write, as a pot may change locations.

RFC 2327, "SDP: Session Description Protocol", April 1998

Note: This RFC has been obsoleted by RFC 4566

Source of RFC: mmusic (rai)

Errata ID: 459

Status: Verified
Type: Technical

Reported By: Not recorded
Date Reported: 2000-12-31

In the document, the following characters should be replaced with corrected text.

       '|' should be  '/'
       '"""' and '"' should be 'DQUOTE'
       '0x01..0x09'  should be '%x01-09'

Notes:

The date reported was not recorded. The estimate is during 2000.

RFC 2328, "OSPF Version 2", April 1998

Source of RFC: ospf (rtg)

Errata ID: 2953

Status: Verified
Type: Technical

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

Status: Verified
Type: Technical

Reported By: Mike Dubrovsky
Date Reported: 2014-04-24
Verifier Name: Alia Atlas
Date Verified: 2014-05-12

Section 13 says:

    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

    (7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

It should say:

    (6) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (7) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

Notes:

The problem arises when the routing domain has two instances of LSA
with the same sequence number and the same checksum,
but with an age difference bigger than MaxAgeDiff.

The above could take place in multiple scenarios. Here are two examples:

1) There is a demand circuit somewhere in the routing domain
2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs
but later on gained the ASBR status back and re-originated Type 5.
If the network was partitioned, each partition can have two instances of LSA
with an age difference bigger than MaxAgeDiff.

The two instances of LSA can temporarily prevent the adjacency formation.

Consider the example below:


Topology
========


RT1 ----- RT2

Initial state:
==============
The physical link between RT1 and R2 just came up
The routers are about to form ospf adjacency.

Initial link-state databases:
=============================
R1 ospf database has LSA 10.0.0.1 age 910 seq # 0x80000001
R2 ospf database has the same LSA 10.0.0.1 age 9 seq # 0x80000001

RT1 Event Sequence:
===============

RT1 is starting to form adjacency with RT2.

1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328).
2) So RT1 requests the LSA
3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay).
4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now).

So RT1 aborts Loading according to step (6) of section 13.


Solution:
=========

Swap steps (6) and (7) of section 13.

Acee Lindem adds:
"This situation comes into play when a router views an LSA as being
more recent when the LSA is requested (via Link-State Request) but as the
same instance when the LSA is actually received."

Errata ID: 4022

Status: Verified
Type: Technical

Reported By: Alexander Okonnikov
Date Reported: 2014-06-23
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 10.5 says:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For these network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

It should say:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For broadcast and NBMA network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

Notes:

This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values.

Errata ID: 3734

Status: Verified
Type: Editorial

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

Section 8.2 says:

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

It should say:

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

Notes:

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

Errata ID: 4023

Status: Verified
Type: Editorial

Reported By: Alexander Okonnikov
Date Reported: 2014-06-24
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 12.4.1 says:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for virtual links in Section 12.4.1.2,
for broadcast and NBMA interfaces in 12.4.1.3, and for
Point-to-MultiPoint interfaces in 12.4.1.4.

It should say:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2,
for virtual links in Section 12.4.1.3, and for 
Point-to-MultiPoint interfaces in 12.4.1.4.

Notes:

Incorrect references.

Errata ID: 4330

Status: Verified
Type: Editorial

Reported By: Ramakrishna Rao DTV
Date Reported: 2015-04-08
Verifier Name: Alia Atlas
Date Verified: 2015-04-09

Section 3.4 says:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers R10 and R11.

It should say:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers RT10 and RT11.

Notes:

s/R10/RT10
s/R11/RT11

RFC 2347, "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.

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

Note: This RFC has been obsoleted by RFC 4601 RFC 5059

Source of RFC: idmr (rtg)

Errata ID: 457

Status: Verified
Type: Technical

Reported By: RFC Editor
Date Reported: 2001-01-03

Throughout the document:

   [Figures are present only in the postscript version]

Notes:

There is no postscript version available.

RFC 2373, "IP Version 6 Addressing Architecture", July 1998

Note: This RFC has been obsoleted by RFC 3513

Source of RFC: ipngwg (int)

Errata ID: 455

Status: Verified
Type: Technical

Reported By: Tim Hutchinson
Date Reported: 2000-10-31

In the reference:

   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 1993, April 1996.

Notes:

the RFC number cited is incorrect; it should be RFC 1933.

RFC 2384, "POP URL Scheme", August 1998

Source of RFC: Legacy

Errata ID: 2943

Status: Verified
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2011-08-18
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-14

Section 7 says:

        S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
        C: APOP rg c4c9334bac560ecc979e58001b3e22fb

It should say:

        S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
        C: APOP rg 8f5de26536bc248ba202a9ca612e71bd

Notes:

If the password for user "rg" is "secret" as in the plain PASS example before this APOP example, then
MD5("<1896.697170952@mail.eudora.com>secret") should be as shown in the corrected text.

The original text is a modification of the APOP example in RFC 1939, and
MD5("<1896.697170952@dbc.mtview.ca.us>tanstaaf") almost certainly will not match any plausible
MD5("<1896.697170952@mail.eudora.com>"||password).

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

Note: This RFC has been obsoleted by RFC 7578

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4030

Status: Verified
Type: Technical

Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Verifier Name: Barry Leiba
Date Verified: 2014-07-01

Section Appendix A says:

Required parameters:
  none

It should say:

Required parameters:
  boundary (see Section 4.1)

Notes:

Without that parameter you cannot parse the payload body.

Errata ID: 2937

Status: Verified
Type: Editorial

Reported By: Anne van Kesteren
Date Reported: 2011-08-14
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 5.6 says:

application/x-url-encoded

It should say:

application/x-www-form-urlencoded

Notes:

This incorrect media type appears twice and should be replaced both times. In the last paragraph of this section "both" and "as well" can be removed.

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

Source of RFC: mhtml (app)

Errata ID: 454

Status: Verified
Type: Technical

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>

RFC 2395, "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.

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

Note: This RFC has been obsoleted by RFC 3986

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

RFC 2397, "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).

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

Note: This RFC has been obsoleted by RFC 4306

Source of RFC: ipsec (sec)

Errata ID: 449

Status: Verified
Type: Technical

Reported By: Jan Wuyts
Date Reported: 2004-03-04
Report Text:

The section 4 header is missing from the document.  Presently, the document is structured as follows:

1. Abstract
2. Introduction
3. Terms and definitions
   4.1  IPSEC naming scheme
   4.2  IPSEC situation definition
...etc.


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

Source of RFC: Legacy

Errata ID: 448

Status: Verified
Type: Technical

Reported By: C. M. Heard
Date Reported: 2003-08-11

Section 3 says:

   IMPORTS
       MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
           FROM SNMPv2-CONF
       snmpModules, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,
           Integer32, Unsigned32, OBJECT-TYPE, IpAddress
           FROM SNMPv2-SMI

It should say:

   IMPORTS
       MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
           FROM SNMPv2-CONF
       mib-2, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,
           Integer32, Unsigned32, OBJECT-TYPE, IpAddress
           FROM SNMPv2-SMI

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

Note: This RFC has been obsoleted by RFC 3801

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

RFC 2426, "vCard MIME Directory Profile", September 1998

Note: This RFC has been obsoleted by RFC 6350

Source of RFC: asid (app)

Errata ID: 868

Status: Verified
Type: Technical

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!

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

Note: This RFC has been obsoleted by RFC 5545

Source of RFC: calsch (app)

Errata ID: 435

Status: Verified
Type: Technical

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.

RFC 2453, "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.

Errata ID: 3996

Status: Verified
Type: Editorial

Reported By: Ramakrishna DTV
Date Reported: 2014-05-22
Verifier Name: Adrian Farrel
Date Verified: 2014-05-29

Section 3.4.2 says:

   Unfortunately, the question of how long convergence will take is not
   amenable to quite so simple an answer.  Before going any further, it
   will be useful to look at an example (taken from [2]).

It should say:

   Unfortunately, the question of how long convergence will take is not
   amenable to quite so simple an answer.  Before going any further, it
   will be useful to look at an example (taken from [5]).

Notes:

Correct the reference.

Errata ID: 3999

Status: Verified
Type: Editorial

Reported By: Ramakrishna DTV
Date Reported: 2014-05-25
Verifier Name: Alia Atlas
Date Verified: 2014-05-28

Section 3.4 says:

"   4.ne The method so far only has a way to lower the metric, as the
   existing metric is kept until a smaller one shows up.  It is possible
   that the initial estimate might be too low."

It should say:

"  The method so far only has a way to lower the metric, as the
   existing metric is kept until a smaller one shows up.  It is possible
   that the initial estimate might be too low."

Notes:

Spurious text "4.ne"

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

Note: This RFC has been obsoleted by RFC 3280

Source of RFC: pkix (sec)

Errata ID: 432

Status: Verified
Type: Technical

Reported By: Yaron Sella
Date Reported: 2001-02-13

In Appendix D.3:

   0587 03 81 81      47: . BIT STRING

It should say:

   0587 03 81 81      129: . BIT STRING

RFC 2462, "IPv6 Stateless Address Autoconfiguration", December 1998

Note: This RFC has been obsoleted by RFC 4862

Source of RFC: ipngwg (int)

Errata ID: 431

Status: Verified
Type: Editorial

Reported By: Tim Shepard
Date Reported: 2004-08-10

It currently says:

2.  TERMINOLOGY

   IP - Internet Protocol Version 6.  The terms IPv4 and are used
        only in contexts where necessary to avoid ambiguity.

It should say:

2.  TERMINOLOGY

   IP - Internet Protocol Version 6.  The terms IPv4 and IPv6 are used
        only in contexts where necessary to avoid ambiguity.

RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks", December 1998

Source of RFC: ipngwg (int)

Errata ID: 430

Status: Verified
Type: Technical

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

The URL in this reference is incorrect:

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

It should say:

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

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

Source of RFC: diffserv (tsv)

Errata ID: 3279

Status: Verified
Type: Technical

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

Section Header says:

-

It should say:

Updates: 791

Notes:

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

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

RFC 2486, "The Network Access Identifier", January 1999

Note: This RFC has been obsoleted by RFC 4282

Source of RFC: roamops (ops)

Errata ID: 428

Status: Verified
Type: Technical

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

RFC 2489, "Procedure for Defining New DHCP Options", January 1999

Note: This RFC has been obsoleted by RFC 2939

Source of RFC: dhc (int)

Errata ID: 855

Status: Verified
Type: Editorial

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

Section 4 says:

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

It should say:

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

Notes:

References to RFC 2142 should be to 2242.

from pending

RFC 2518, "HTTP Extensions for Distributed Authoring -- WEBDAV", February 1999

Note: This RFC has been obsoleted by RFC 4918

Source of RFC: webdav (app)

Errata ID: 426

Status: Verified
Type: Technical

Reported By: Julian Reschke
Date Reported: 2002-05-11
Report Text:

Errata for this document can be found at: http://www.webdav.org/wg/rfcdev/issues.htm


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

Note: This RFC has been obsoleted by RFC 3647

Source of RFC: pkix (sec)

Errata ID: 425

Status: Verified
Type: Technical

Reported By: Sid Sidner
Date Reported: 2002-08-05

In the NOTES Section:

   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
     See http://www.abanet.com for ordering details.

It should say:

   1 The ABA Digital Signature Guidelines can be purchased from the ABA.
     See http://www.abanet.org for ordering details.

RFC 2544, "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.

RFC 2548, "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.

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

Source of RFC: mhtml (app)

Errata ID: 418

Status: Verified
Type: Technical

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:



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

Note: This RFC has been obsoleted by RFC 6960

Source of RFC: pkix (sec)

Errata ID: 2253

Status: Verified
Type: Editorial

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.

RFC 2579, "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:


RFC 2581, "TCP Congestion Control", April 1999

Note: This RFC has been obsoleted by RFC 5681

Source of RFC: tcpimpl (tsv)

Errata ID: 414

Status: Verified
Type: Technical

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

Section 4.3 says:

   The algorithms outlined in [Hoe96,FF96,MM96a,MM6b] follow the
   principles of the basic four congestion control algorithms outlined
   in this document.

It should say:

   The algorithms outlined in [Hoe96,FF96,MM96a,MM96b] follow the
   principles of the basic four congestion control algorithms outlined
   in this document.

Notes:


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

Source of RFC: pkix (sec)

Errata ID: 1831

Status: Verified
Type: Technical

Reported By: Paul Hoffman
Date Reported: 2009-08-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.1 and 4.2 says:

Optional parameters: version (default value is "1")

It should say:

Optional parameters: none

[Note: legacy implementations MAY include a version parameter, which SHOULD be ignored if present.]

Notes:

The optional parameters is ambiguous because it does not state what the version refers to. It is unlikely to be the version of PKIX, because RFC 2459 preceded this document, and the versions of the PKIX format described in RFC 2459 was 2 and 3. The authors note that we did not have a reference to the PKIX specification. Because of this, we suggest that the "version" parameter be ignored if present, and that no assumption of what the default of "1" means. Further, we suggest that "version" not be used when generating MIME bodies.

RFC 2608, "Service Location Protocol, Version 2", June 1999

Source of RFC: svrloc (int)

Errata ID: 4290

Status: Verified
Type: Editorial

Reported By: Peter Budny
Date Reported: 2015-03-06
Verifier Name: Brian Haberman
Date Verified: 2015-03-09

Section 4.1 says:

This substring is the Naming Authority, as described in Section 9.6.

It should say:

This substring is the Naming Authority, as described in Section 4.2.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999

Note: This RFC has been obsoleted by RFC 7230 RFC 7231 RFC 7232 RFC 7233 RFC 7234 RFC 7235

Source of RFC: http (app)

Errata ID: 408

Status: Verified
Type: Technical

Reported By: Greg Robson
Date Reported: 2001-10-08

Section 3.6 says:

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the
   following tokens: "chunked" (section 3.6.1), "identity" (section
   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and
   "deflate" (section 3.5).

Notes:

There is no section 3.6.2; there is no such thing as Transfer-Coding:
identity in the RFC 2616 specification (note that there would not be
quotes around "identity" in the actual header!).

Errata ID: 412

Status: Verified
Type: Technical

Reported By: Justin Erenkrantz
Date Reported: 2001-01-05
Report Text:

From Scott Lawrence:
All known errata for this HTTP RFC will be found at: 
http://purl.org/NET/http-errata and 
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/




Errata ID: 411

Status: Verified
Type: Editorial

Reported By: WooJin Chung
Date Reported: 2006-10-31
Verifier Name: Barry Leiba
Date Verified: 2014-06-03

Section 14.3 says:

The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.

       Accept-Encoding  = "Accept-Encoding" ":"

                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

 Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding:
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

It should say:

The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.

       Accept-Encoding  = "Accept-Encoding" ":"

                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

 Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Notes:

As you can see, Accept-Encoding has to consist of 1 or more ( codings [ ";"
"q" "=" qvalue ] ). So you can't just leave the value of "Accept-Encoding:"
empty. The second example is, therefore, incorrect.

------------------------------------------------
Alexey: This issue was fixed in HTTPBIS WG, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/25>

Errata ID: 652

Status: Verified
Type: Editorial

Reported By: Justin Erenkrantz
Date Reported: 2000-12-23

Section 4.4 says:

4.If the message uses the media type "multipart/byteranges", and the
  ransfer-length is not otherwise specified, then this self-
  elimiting media type defines the transfer-length. This media type
  UST NOT be used unless the sender knows that the recipient can arse
  it; the presence in a request of a Range header with ultiple byte-
  range specifiers from a 1.1 client implies that the lient can parse
  multipart/byteranges responses.

It should say:

4.If the message uses the media type "multipart/byteranges", and the
  Transfer-length is not otherwise specified, then this self-
  delimiting media type defines the transfer-length. This media type
  MUST NOT be used unless the sender knows that the recipient can parse
  it; the presence in a request of a Range header with multiple byte-
  range specifiers from a 1.1 client implies that the client can parse
  multipart/byteranges responses.

Notes:

Missing the first character of 6 words.

Errata ID: 653

Status: Verified
Type: Editorial

Reported By: Justin Erenkrantz
Date Reported: 2000-12-23

Section 1.3 says:

Each of these representations is termed a `varriant'.

It should say:

Each of these representations is termed a `variant'.


Errata ID: 4522

Status: Verified
Type: Editorial

Reported By: Christophe JAILLET
Date Reported: 2015-11-03
Verifier Name: Barry Leiba
Date Verified: 2016-01-21

Section 13.5.1 says:

 The following HTTP/1.1 headers are hop-by-hop headers:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailers
      - Transfer-Encoding
      - Upgrade

It should say:

 The following HTTP/1.1 headers are hop-by-hop headers:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailer
      - Transfer-Encoding
      - Upgrade

Notes:

Trailers (with a s) does not seem to a header field, just a keyword for TE.
I think that Trailer (without a s) is expected here.

AFAIK, RFC 7230 does not have such an explicit list and is not concerned.

RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication", June 1999

Note: This RFC has been obsoleted by RFC 7235 RFC 7615 RFC 7616 RFC 7617

Source of RFC: http (app)

Errata ID: 410

Status: Verified
Type: Technical

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

RFC 2625, "IP and ARP over Fibre Channel", June 1999

Note: This RFC has been obsoleted by RFC 4338

Source of RFC: ipfc (int)

Errata ID: 407

Status: Verified
Type: Technical

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

RFC 2626, "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

RFC 2630, "Cryptographic Message Syntax", June 1999

Note: This RFC has been obsoleted by RFC 3369 RFC 3370

Source of RFC: smime (sec)

Errata ID: 406

Status: Verified
Type: Editorial

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.

RFC 2631, "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.

RFC 2633, "S/MIME Version 3 Message Specification", June 1999

Note: This RFC has been obsoleted by RFC 3851

Source of RFC: smime (sec)

Errata ID: 405

Status: Verified
Type: Technical

Reported By: Joni Yrjana
Date Reported: 2003-03-12

Section 3.5 says:

   This may be useful in an environment were automatic signature
   verification is desired, as no private key material is required to
   verify a signature.

It should say:

   This may be useful in an environment where automatic signature
   verification is desired, as no private key material is required to
   verify a signature.

RFC 2645, "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.

RFC 2648, "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)

RFC 2655, "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/>

RFC 2656, "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/>

RFC 2661, "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

RFC 2663, "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).

RFC 2673, "Binary Labels in the Domain Name System", August 1999

Note: This RFC has been obsoleted by RFC 6891

Source of RFC: dnsind (int)

Errata ID: 1679

Status: Verified
Type: Technical

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

Section headers says:

(none)

It should say:

Updates: 1035

Notes:

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

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

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

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

RFC 2676, "QoS Routing Mechanisms and OSPF Extensions", August 1999

Source of RFC: ospf (rtg)

Errata ID: 399

Status: Verified
Type: Technical

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

Section 3.2.1 says:

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

It should say:

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

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

Note: This RFC has been obsoleted by RFC 7680

Source of RFC: ippm (tsv)

Errata ID: 1528

Status: Verified
Type: Technical

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

Section 2.7 says:

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

It should say:

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

Notes:

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

RFC 2683, "IMAP4 Implementation Recommendations", September 1999

Source of RFC: Legacy

Errata ID: 3129

Status: Verified
Type: Technical

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

Section 3.2.1.3 says:

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

It should say:

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

Notes:

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

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

RFC 2731, "Encoding Dublin Core Metadata in HTML", December 1999

Note: This RFC has been obsoleted by RFC 5791

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

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

Note: This RFC has been obsoleted by RFC 3986

Source of RFC: ipngwg (int)

Errata ID: 1422

Status: Verified
Type: Editorial

Reported By: Paul Suhler
Date Reported: 2008-05-13
Verifier Name: Lisa Dusseault
Date Verified: 2008-05-14

Section Page 2 says:

A literal address is incorrectly rendered as a URL:

Literal:
      1080:0:0:0:8:800:200C:4171

As rendered as a URL:
      http://[1080:0:0:0:8:800:200C:417A]/index.html

It should say:

Should be:
      http://[1080:0:0:0:8:800:200C:4171]/index.html


Notes:

Larry Masinter & I verified this errata

RFC 2737, "Entity MIB (Version 2)", December 1999

Note: This RFC has been obsoleted by RFC 4133

Source of RFC: entmib (ops)

Errata ID: 395

Status: Verified
Type: Technical

Reported By: RFC Editor
Date Reported: 2001-09-21

In the header:

   Network Working Group                                      K. McCloghrie
   Request for Comments: 2737                           Cisco Systems, Inc.
   Obsoletes: 2037                                               A. Bierman
                                                        Cisco Systems, Inc.
                                                              December 1999

It should say:

   Network Working Group                                      K. McCloghrie
   Request for Comments: 2737                           Cisco Systems, Inc.
   Obsoletes: 2037                                               A. Bierman
   Category: Standards Track                            Cisco Systems, Inc.
                                                              December 1999

RFC 2740, "OSPF for IPv6", December 1999

Note: This RFC has been obsoleted by RFC 5340

Source of RFC: ospf (rtg)

Errata ID: 392

Status: Verified
Type: Technical

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


RFC 2743, "Generic Security Service Application Program Interface Version 2, Update 1", January 2000

Source of RFC: cat (sec)

Errata ID: 4151

Status: Verified
Type: Technical

Reported By: Nicolas Williams
Date Reported: 2014-11-03
Verifier Name: Stephen Farrell
Date Verified: 2015-05-01

Section 2.2.4 says:

   o  GSS_S_FAILURE indicates that the context is recognized, but that
   the GSS_Process_context_token() operation could not be performed for
   reasons unspecified at the GSS-API level.

It should say:

   o  GSS_S_FAILURE indicates that the context is recognized, but
   either the GSS_Process_context_token() operation could not be
   performed for reasons unspecified at the GSS-API level, or the peer
   had an error consuming the last context token sent to it.  The latter
   occurs when the local side became fully established and produced one
   last token which was sent to the peer, but the peer encountered an
   error while processing that last context token.  In either case the
   minor status code provides additional information.

   In the case of successful processing of error tokens, the minor
   status code provides information from the input token.  The display
   string outputs of GSS_Display_status() as applied to such minor
   status codes should indicate that the error originated on the remote
   peer, along with the nature of the error.  Note that there is no
   way to distinguish failures of GSS_Process_context_token() from
   error token information other than to read the human-readable status
   display strings.

Notes:

The other major status codes that GSS_Process_context_token() can return are: GSS_S_COMPLETE (input token successfully processed), GSS_S_DEFECTIVE_TOKEN (e.g., integrity protection for the input token failed), GSS_S_NO_CONTEXT (invalid input security context).

This leaves a) no way to report error token information, b) no purpose for GSS_S_FAILURE, since the other major status codes cover all plausible error conditions.

But clearly the intention was that "asynchronous error tokens" should be passed to GSS_Process_context_token(), and for such tokens to be useful as far as conveying information about the error goes.

There are at least two easy ways to fix this: either have GSS_Process_context_token() report the error information in the minor status with a major status of GSS_S_COMPLETE, or decide that the GSS_S_FAILURE description was incorrect, that it should have been used to convey error token information. The latter is the more natural fix.

The KITTEN WG will have to review this erratum and decide whether to reject it, accept one fix, or the other. That review happened resulting in the corrected
text above.

RFC 2744, "Generic Security Service API Version 2 : C-bindings", January 2000

Source of RFC: cat (sec)

Errata ID: 3810

Status: Verified
Type: Technical

Reported By: Benjamin Kaduk
Date Reported: 2013-11-22
Verifier Name: Stephen Farrell
Date Verified: 2014-05-08

Section Appendix A says:

 ,

It should say:

 *,

Notes:

The author of draft-ietf-cat-gssv2-cbind (which became RFC2744) switched to a different formatting process between versions 05 and 06 of that draft. This inadvertently introduced errors into the function prototypes in the example gssapi.h header, removing the asterisk which indicates that an argument is of pointer type from pointer arguments which are not the last argument in the argument list of their respective function. All sixty-eight occurrences of <space><comma> in Appendix A should be replaced by the sequence <space><asterisk><comma> as a fix. Additionally, the minor_status argument of gss_export_name() is not caught by this pattern, but also should be changed from scalar to pointer type in order for all function prototypes in the header to be corrected ("OM_uint32," becomes "OM_uint32 *,"). As another concrete example, at the top of page 91, the first argument to gss_acquire_cred should change from "OM_uint32 , /* minor_status */" to "OM_uint32 *, /* minor_status */".

RFC 2747, "RSVP Cryptographic Authentication", January 2000

Source of RFC: rsvp (tsv)

Errata ID: 4313

Status: Verified
Type: Technical

Reported By: Nikolai Malykh
Date Reported: 2015-03-25
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-21

Section 3.2 says:

   In this approach, we could use an NTP based timestamp value as the
   sequence number.  The roll-over period of an NTP timestamp is about
   136 years, much longer than any reasonable lifetime of a key.  In
   addition, the granularity of the NTP timestamp is fine enough to
   allow the generation of an RSVP message every 200 picoseconds for a
   given key.  Many real time clock modules do not have the resolution
   of an NTP timestamp.  In these cases, the least significant bits of
   the timestamp can be generated using a message counter, which is
   reset every clock tick.  For example, when the real time clock
   provides a resolution of 1 second, the 32 least significant bits of
   the sequence number can be generated using a message counter.  The
   remaining 32 bits are filled with the 32 least significant bits of
   the timestamp.  Assuming that the recovery time after failure takes
   longer than one tick of the real time clock, the message counter for
   the low order bits can be safely reset to zero after a restart.

It should say:

   In this approach, we could use an NTP based timestamp value as the
   sequence number.  The roll-over period of an NTP timestamp is about
   136 years, much longer than any reasonable lifetime of a key.  In
   addition, the granularity of the NTP timestamp is fine enough to
   allow the generation of an RSVP message every 200 picoseconds for a
   given key.  Many real time clock modules do not have the resolution
   of an NTP timestamp.  In these cases, the least significant bits of
   the sequence number can be generated using a message counter, which
   is reset every clock tick.  For example, when the real time clock
   provides a resolution of 1 second, the 32 least significant bits of
   the sequence number can be generated using a message counter.  The
   remaining 32 bits are filled with the 32 most significant bits of
   the timestamp.  Assuming that the recovery time after failure takes
   longer than one tick of the real time clock, the message counter for
   the low order bits can be safely reset to zero after a restart.

Notes:

32 least significant bits of the timestamp will in this case be set to zero.

RFC 2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000

Source of RFC: pppext (int)

Errata ID: 391

Status: Verified
Type: Technical

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.

RFC 2763, "Dynamic Hostname Exchange Mechanism for IS-IS", February 2000

Note: This RFC has been obsoleted by RFC 5301

Source of RFC: isis (rtg)

Errata ID: 390

Status: Verified
Type: Technical

Reported By: Brian Vine
Date Reported: 2002-06-28

Section 4 says:

   A router may also optionally insert this TLV in it's pseudo node LSP
   for the association of a symbolic name to a local LAN.

It should say:

   A router may also optionally insert this TLV in its pseudo node LSP
   for the association of a symbolic name to a local LAN.

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

Source of RFC: Legacy

Errata ID: 389

Status: Verified
Type: Technical

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

There is a case of sections being numbered wrong:

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

RFC 2784, "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.

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

Source of RFC: Legacy

Errata ID: 388

Status: Verified
Type: Technical

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

The title was mis-spelled:

   Diffie-Helman USM Key Management Information Base and Textual
   Convention 

It should say:

   Diffie-Hellman USM Key Management Information Base and Textual
   Convention

RFC 2797, "Certificate Management Messages over CMS", April 2000

Note: This RFC has been obsoleted by RFC 5272

Source of RFC: pkix (sec)

Errata ID: 4037

Status: Verified
Type: Technical

Reported By: Russ Housley
Date Reported: 2014-07-03
Verifier Name: Stephen Farrell
Date Verified: 2014-07-03

Section Appendix A says:

EnrollmentMessageSyntax
   { iso(1) identified-organization(3) dod(4) internet(1)
   security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }

It should say:

EnrollmentMessageSyntax
   { iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }

Notes:

The PKIX Object Identifier arc is:

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

So, the third element in the object identifier should be "dod(6)" instead of "dod(4)".

Errata ID: 4038

Status: Verified
Type: Technical

Reported By: Russ Housley
Date Reported: 2014-07-03
Verifier Name: Stephen Farrell
Date Verified: 2014-07-03

Section Appendix A says:

   id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}

It should say:

   id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}

Notes:

This is a typo in the ASN.1 module. The proper definition for this object identifier is {id-cmc 24}.

RFC 2810, "Internet Relay Chat: Architecture", April 2000

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 387

Status: Verified
Type: Technical

Reported By: Christophe Kalt
Date Reported: 2004-02-25

Section 5.2.1 says:

   In IRC the channel has a role equivalent to that of the multicast
   group; their existence is dynamic and the actual conversation carried
   out on a channel MUST only be sent to servers which are supporting
   users on a given channel.  Moreover, the message SHALL only be sent
   once to every local link as each server is responsible to fan the
   original message to ensure that it will reach all the recipients.

   The following examples all refer to Figure 2.

It should say:

   In IRC the channel has a role equivalent to that of the multicast
   group; their existence is dynamic and the actual conversation carried
   out on a channel MUST only be sent to servers which are supporting
   users on a given channel.  Moreover, the message SHALL only be sent
   once to every local link as each server is responsible to fan the
   original message to ensure that it will reach all the recipients.

   The following examples all refer to Figure 1.

Notes:


There is no "Figure 2".

RFC 2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING 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

Errata ID: 4289

Status: Verified
Type: Editorial

Reported By: Tony Tam
Date Reported: 2015-03-06
Verifier Name: Barry Leiba
Date Verified: 2015-03-06

Section 2.3.1 says:

target     =  nickname / server

It should say:

target     =  nickname / servername

Notes:

There is no "server" rule.

RFC 2813, "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

RFC 2817, "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>

RFC 2821, "Simple Mail Transfer Protocol", April 2001

Note: This RFC has been obsoleted by RFC 5321

Source of RFC: drums (app)

Errata ID: 375

Status: Verified
Type: Technical

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

RFC 2822, "Internet Message Format", April 2001

Note: This RFC has been obsoleted by RFC 5322

Source of RFC: drums (app)

Errata ID: 373

Status: Verified
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2006-01-10
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-21

Section 3.2.6 says:

   unstructured    =       *([FWS] utext) [FWS]

It should say:

   unstructured    =       *([FWS] utext) (*WSP / obs-FWS)

Notes:

A prominent example is the <subject> defined in section 3.6.5:

subject = "Subject:" unstructured CRLF

Expanding the [FWS] at the end (ignoring <obs-FWS>) results in:

subject = "Subject:" *([FWS] utext) [[*WSP CRLF] 1*WSP] CRLF


Alexey: note that this was fixed in RFC 5322 (which obsoleted RFC 2821) in a slightly different way.

RFC 2826, "IAB Technical Comment on the Unique DNS Root", May 2000

Source of RFC: IAB

Errata ID: 4523

Status: Verified
Type: Editorial

Reported By: Dave Thaler
Date Reported: 2015-11-05
Verifier Name: Andrew Sullivan
Date Verified: 2016-01-07

Section 2 says:

The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
a locating information when the user doesn't precisely know the
correct names.

It should say:

The DNS type of unique naming and name-mapping system may not be
ideal for a number of purposes for which it was never designed, such
as locating information when the user doesn't precisely know the
correct names.

Notes:

Typo: "such a locating" should be "such as locating"

Also typo in section 1.2. It says
"any set of resources records"
and should say
"any set of resource records"

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

Source of RFC: IETF - NON WORKING 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.

RFC 2839, "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

RFC 2846, "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 )

RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification", June 2000

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

Errata ID: 4009

Status: Verified
Type: Technical

Reported By: Giovanni Cannata
Date Reported: 2014-06-09
Verifier Name: Barry Leiba
Date Verified: 2014-06-11

Section LDIF Syntax says:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

It should say:

change-moddn             = ("modrdn" / "moddn") SEP
                            "newrdn:" (    FILL rdn /
                                       ":" FILL base64-rdn) SEP
                            "deleteoldrdn:" FILL ("0" / "1")  SEP [8]
                            0*1("newsuperior:"
                            (    FILL distinguishedName /
                             ":" FILL base64-distinguishedName) SEP)

Note 8: If deleteoldrdn is "0" the old rdn will be kept; if it is "1"
the old rdn will be deleted.

Notes:

There is no formal specification of the meaning of the "deleteoldrdn" value 0 or 1. 1 stands for deletion, 0 stands for keeping the old rdn. Add a note to explain the value meaning.

-----
Verifier note:
It is correct that the meaning of "deleteoldrdn" is never explained in the document. The proposed resolution is a reasonable fix for that, and such an explanation is needed.

Errata ID: 4377

Status: Verified
Type: Technical

Reported By: Keita Kondou
Date Reported: 2015-05-28
Verifier Name: Barry Leiba
Date Verified: 2015-05-28

Section LDIF Syntax says:

ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

It should say:

ldap-oid                 = 1*DIGIT 0*("." 1*DIGIT)
                           ; An LDAPOID, as defined in [4]

Notes:

ldap-oid syntax on RFC2849 allow only ONE dot.
But it should allow decimal string separated by multi dots.

RFC2251 LDAPOID definition:
The LDAPOID is a notational convenience to indicate that the
permitted value of this string is a (UTF-8 encoded) dotted-decimal
representation of an OBJECT IDENTIFIER.

LDAPOID ::= OCTET STRING

For example,

1.3.6.1.4.1.1466.1.2.3

RFC 2861, "TCP Congestion Window Validation", June 2000

Note: This RFC has been obsoleted by RFC 7661

Source of RFC: tsvwg (tsv)

Errata ID: 1303

Status: Verified
Type: Editorial

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

Section 7 says:

None.

It should say:

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

Notes:

Missing citation. Reported by Emmanuel Papirakis.

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

Source of RFC: radius (ops)

Errata ID: 368

Status: Verified
Type: Technical

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.

RFC 2866, "RADIUS Accounting", June 2000

Source of RFC: radius (ops)

Errata ID: 4485

Status: Verified
Type: Technical

Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Benoit Claise
Date Verified: 2015-10-05

Section 5.1 says:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting (for
example, upon booting) by specifying Accounting-On and to mark the
end of accounting (for example, just before a scheduled reboot) by
specifying Accounting-Off.

It should say:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting for the
NAS (for example, upon booting) by specifying Accounting-On
and to mark the end of accounting for the NAS (for example, just
before a scheduled reboot) by specifying Accounting-Off.

Notes:

Some RADIUS client implementations send scoped Accounting-On and Accounting-Off Accounting-Request packets. This is seen, for example, with some wireless APs that include a Called-Station-Id attribute to scope to a Basic Service Set (BSS).

This is an incorrect interpretation of the RFC that is not backwards compatible with consumers of RADIUS accounting information, yet the RFC is ambiguous on this point.

The RFC must be clear that Accounting-On and Accounting-Off apply to the whole NAS and cannot be scoped in this manner.

New Acct-Status-Type values must instead be defined to allow this, perhaps named something like Scoped-Accounting-On and Scoped-Accounting-Off.

Errata ID: 2713

Status: Verified
Type: Editorial

Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13

Section 5 says:

      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      ^^^^^^^^^^

It should say:

      [7] characters and String contains 8-bit binary data.  Servers and
      clients MUST be able to deal with embedded nulls.

Notes:

Same as RFC 2865 , extraneous "servers and" can be deleted. ;)

Errata ID: 3896

Status: Verified
Type: Editorial

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

Section 3 says:

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

Notes:

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

RFC 2867, "RADIUS Accounting Modifications for Tunnel Protocol Support", June 2000

Source of RFC: radius (ops)

Errata ID: 367

Status: Verified
Type: Editorial

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

Section 3.5 says:

            Acct-Multi-Session-Id (51)

It should say:

            Acct-Multi-Session-Id (50)

Notes:

RFC 2868, "RADIUS Attributes for Tunnel Protocol Support", June 2000

Source of RFC: radius (ops)

Errata ID: 2714

Status: Verified
Type: Technical

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"

RFC 2873, "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.

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

Source of RFC: smime (sec)

Errata ID: 1839

Status: Verified
Type: Technical

Reported By: Sean Turner
Date Reported: 2009-08-25
Verifier Name: Tim Polk
Date Verified: 2010-04-19

Section 7 says:

300b 0609 6086 4801 6502 0101 0400

It should say:

300b 0609 6086 4801 6502 0101 04

Notes:

The SMIMECapability for SKIPJACK should be 300b 0609 6086 4801 6502 0101 04, which is the DER encoding of the id-fortezzaConfidentialityAlgorithm OID. The extra 00 should not be included.

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

Source of RFC: tsvwg (tsv)

Errata ID: 365

Status: Verified
Type: Editorial

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

Section 4.2.3 says:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

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

It should say:

         Transmitted    Received    ACK Sent
         Segment        Segment     (Including SACK Blocks)

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

RFC 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000

Source of RFC: ipp (app)

Errata ID: 4172

Status: Verified
Type: Editorial

Reported By: Michael Sweet
Date Reported: 2014-11-12
Verifier Name: Barry Leiba
Date Verified: 2014-11-12

Section 3.5 says:

   a value that the parser treats atomically.  Values from 0x00 to
   0x37777777 are reserved for definition in future IETF standard track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

It should say:

   a value that the parser treats atomically.  Values from 0x00 to
   0x3FFFFFFF are reserved for definition in future IETF standard track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

RFC 2911, "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.

Errata ID: 4173

Status: Verified
Type: Editorial

Reported By: Michael Sweet
Date Reported: 2014-11-12
Verifier Name: Barry Leiba
Date Verified: 2014-11-12

Section 4.4.15 says:

    0x4000-0x8FFF       reserved for vendor extensions (see section 6.4)

It should say:

    0x4000-0x7FFF       reserved for vendor extensions (see section 6.4)

Notes:

operation code is a 16-bit signed integer; max is therefore 0x7FFF...

RFC 2916, "E.164 number and DNS", September 2000

Note: This RFC has been obsoleted by RFC 3761

Source of RFC: enum (rai)

Errata ID: 362

Status: Verified
Type: Technical

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.

RFC 2919, "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."

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

Note: This RFC has been obsoleted by RFC 4560

Source of RFC: disman (ops)

Errata ID: 360

Status: Verified
Type: Technical

Reported By: Randy Presuhn
Date Reported: 2002-03-26

Section 4.1 says:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(4)."

It should say:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(2)."

RFC 2927, "MIME Directory Profile for LDAP Schema", September 2000

Source of RFC: schema (app)

Errata ID: 359

Status: Verified
Type: Technical

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

Section 3 says:

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

It should say:

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

RFC 2938, "Identifying Composite Media Features", September 2000

Source of RFC: conneg (app)

Errata ID: 1080

Status: Verified
Type: Technical

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

Section 4 says:

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

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

It should say:

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

Notes:

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

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

Source of RFC: dhc (int)

Errata ID: 358

Status: Verified
Type: Technical

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

RFC 2965, "HTTP State Management Mechanism", October 2000

Note: This RFC has been obsoleted by RFC 6265

Source of RFC: http (app)

Errata ID: 2644

Status: Verified
Type: Technical

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.

RFC 2978, "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.

RFC 2985, "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

RFC 2988, "Computing TCP's Retransmission Timer", November 2000

Note: This RFC has been obsoleted by RFC 6298

Source of RFC: tsvwg (tsv)

Errata ID: 1308

Status: Verified
Type: Editorial

Reported By: Michael Scharf
Date Reported: 2008-02-05
Verifier Name: Lars Eggert
Date Verified: 2009-02-16

Section References says:

   [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
           Communication Review, vol. 18, no. 4, pp. 314-329, Aug.  1988.

   [JK88]  Jacobson, V. and M. Karels, "Congestion Avoidance and
           Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

It should say:

   [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer
           Communication Review, vol. 18, no. 4, pp. 314-329, Aug.  1988.

   [JBB92] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for High
           Performance", RFC 1323, May 1992.

   [JK88]  Jacobson, V. and M. Karels, "Congestion Avoidance and
           Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

Notes:

Reference [JBB92] is mentioned two times in section 3, but it is not included in the reference section.

RFC 3003, "The audio/mpeg Media Type", November 2000

Source of RFC: Legacy

Errata ID: 355

Status: Verified
Type: Technical

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

 

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

It should say:

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

RFC 3010, "NFS version 4 Protocol", December 2000

Note: This RFC has been obsoleted by RFC 3530

Source of RFC: nfsv4 (tsv)

Errata ID: 354

Status: Verified
Type: Technical

Reported By: Matthew Wilcox
Date Reported: 2002-06-11
Report Text:

RFC 3010 claims that it obsoletes RFC 1813 and RFC 1094, when in fact it does not.


RFC 3015, "Megaco Protocol Version 1.0", November 2000

Note: This RFC has been obsoleted by RFC 3525

Source of RFC: megaco (rai)

Errata ID: 353

Status: Verified
Type: Technical

Reported By: Brian Rosen
Date Reported: 2001-09-04

In Section Annex B

   V4hex                = 1*3(DIGIT) ; "0".."225"

It should say:

   V4hex                = 1*3(DIGIT) ; "0".."255"

RFC 3023, "XML Media Types", January 2001

Note: This RFC has been obsoleted by RFC 7303

Source of RFC: Legacy

Errata ID: 352

Status: Verified
Type: Technical

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

Section 8.13 says:

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

   or

   {BOM}<?xml?>

It should say:

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

RFC 3024, "Reverse Tunneling for Mobile IP, revised", January 2001

Source of RFC: mobileip (int)

Errata ID: 351

Status: Verified
Type: Technical

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

Section 4.3.1 says:

    Upon receipt of a Registration Reply that satisfies validity
    checks,

It should say:

    Upon receipt of a Registration Request that satisfies validity
    checks,

RFC 3028, "Sieve: A Mail Filtering Language", January 2001

Note: This RFC has been obsoleted by RFC 5228 RFC 5429

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

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

Source of RFC: Legacy

Errata ID: 349

Status: Verified
Type: Technical

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

Section 4.2 says:

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

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

Notes:

You can see the last line is missing a 0.

RFC 3031, "Multiprotocol Label Switching Architecture", January 2001

Source of RFC: mpls (rtg)

Errata ID: 348

Status: Verified
Type: Editorial

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

RFC 3032, "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).

RFC 3036, "LDP Specification", January 2001

Note: This RFC has been obsoleted by RFC 5036

Source of RFC: mpls (rtg)

Errata ID: 346

Status: Verified
Type: Technical

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

Section 3.5.1.2.2 says:

   If the TLV type is >= 0x8000 (high order bit 1) the TLV is
   silently dropped.  Section "Unknown TLV in Known Message Type"
   elaborates on this behavior.

Notes:

There is no section with this title. The sentence in question should
have been deleted. It refers to a section that was deleted in a
version of the I-D that led to the RFC.

RFC 3037, "LDP Applicability", January 2001

Source of RFC: mpls (rtg)

Errata ID: 344

Status: Verified
Type: Technical

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

Section 1 says:

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

It should say:

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

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

Note: This RFC has been obsoleted by RFC 5577

Source of RFC: avt (rai)

Errata ID: 343

Status: Verified
Type: Technical

Reported By: Colin Perkins
Date Reported: 2002-06-04

Section 4 says:

   Encoding considerations:
         This type is only defined for transfer via RTP as specified
	 in a Work in Progress.

It should say:

   Encoding considerations:
         This type is only defined for transfer via RTP as specified
	 in RFC 3047.

RFC 3052, "Service Management Architectures Issues and Review", January 2001

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


RFC 3056, "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:


RFC 3061, "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.

RFC 3062, "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.

RFC 3066, "Tags for the Identification of Languages", January 2001

Note: This RFC has been obsoleted by RFC 4646 RFC 4647

Source of RFC: Legacy

Errata ID: 336

Status: Verified
Type: Technical

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/

RFC 3069, "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!

RFC 3080, "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

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

Source of RFC: ipcdn (ops)

Errata ID: 334

Status: Verified
Type: Technical

Reported By: Rich Woundy
Date Reported: 2001-04-10

Section 4 says:

   docsBpiCmAuthState      OBJECT-TYPE
   SYNTAX                  INTEGER {
    
                                   authWait(2),
                                   authorized(3),
                                   reauthWait(4),
                                   authRejectWait(5)

It should say:

   docsBpiCmAuthState      OBJECT-TYPE
   SYNTAX                  INTEGER {

                                   start(1),
                                   authWait(2),
                                   authorized(3),
                                   reauthWait(4),
                                   authRejectWait(5)

Notes:

2014-07-14: comma added. Thanks to Mark Ellison for the correction.

RFC 3092, "Etymology of "Foo"", April 2001

Source of RFC: INDEPENDENT

Errata ID: 1454

Status: Verified
Type: Editorial

Reported By: Frank Ellermann
Date Reported: 2008-06-15
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section Appendix says:

   | 2818 |  X  |  X  |         |       | 190 |
   | 2828 |     |  X  |    X    |       | 191 |
   | 2830 |  X  |     |         |       | 192 |
   | 2831 |  X  |  X  |    X    |       | 193 |
   | 2839 |     |  X  |         |       | 194 |
   | 2846 |  X  |  X  |         |       | 195 |
   | 2853 |     |  X  |         |       | 196 |
   | 2863 |     |  X  |         |       | 197 |
   | 2910 |     |  X  |    X    |       | 198 |
   | 2912 |     |  X  |    X    |       | 199 |
   | 2915 |     |  X  |         |       | 200 |
   | 2926 |     |     |    X    |       | 201 |
   | 2942 |     |  X  |         |       | 202 |
   | 2965 |     |  X  |         |       | 203 |
   | 2967 |  X  |  X  |    X    |       | 204 |
   | 2970 |     |  X  |         |       | 205 |
   | 2993 |  X  |  X  |         |       | 206 |
   | 3010 |  X  |  X  |         |       | 207 |
   | 3023 |     |  X  |         |       | 208 |
   | 3028 |     |  X  |         |       | 209 |
   | 3075 |  X  |  X  |         |       | 210 |
   | 3080 |     |  X  |         |       | 211 |
   | 3092 |  X  |  X  |    X    |   X   | 212 |
   +------+-----+-----+---------+-------+-----+
   | RFC# | bar | foo | foo.bar | fubar |  #  |

It should say:

   | 2818 |  X  |  X  |         |       | 190 |
   | 2821 |  X  |  X  |         |       | 191 |
   | 2828 |     |  X  |    X    |       | 192 |
   | 2830 |  X  |     |         |       | 193 |
   | 2831 |  X  |  X  |    X    |       | 194 |
   | 2839 |     |  X  |         |       | 195 |
   | 2846 |  X  |  X  |         |       | 196 |
   | 2853 |     |  X  |         |       | 197 |
   | 2863 |     |  X  |         |       | 198 |
   | 2910 |     |  X  |    X    |       | 199 |
   | 2912 |     |  X  |    X    |       | 200 |
   | 2915 |     |  X  |         |       | 201 |
   | 2926 |     |     |    X    |       | 202 |
   | 2942 |     |  X  |         |       | 203 |
   | 2965 |     |  X  |         |       | 204 |
   | 2967 |  X  |  X  |    X    |       | 205 |
   | 2970 |     |  X  |         |       | 206 |
   | 2993 |  X  |  X  |         |       | 207 |
   | 3010 |  X  |  X  |         |       | 208 |
   | 3023 |     |  X  |         |       | 209 |
   | 3028 |     |  X  |         |       | 210 |
   | 3075 |  X  |  X  |         |       | 211 |
   | 3080 |     |  X  |         |       | 212 |
   | 3092 |  X  |  X  |    X    |   X   | 213 |
   +------+-----+-----+---------+-------+-----+
   | RFC# | bar | foo | foo.bar | fubar |  #  |

Notes:

RFC 2821 contains foo.com (34 occurences), bar.com (18 occurences),
bar.org (5 occurences), foo.org (4 occurences), and one foo-u.edu.

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

Source of RFC: nat (tsv)

Errata ID: 333

Status: Verified
Type: Technical

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

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

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

It should say:

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

Notes:




RFC 3107, "Carrying Label Information in BGP-4", May 2001

Source of RFC: mpls (rtg)

Errata ID: 4497

Status: Verified
Type: Technical

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2015-12-30

Section 2 says:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute [RFC 2283].

It should say:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute
defined in RFC 2858 [BGP-MP].

Notes:

No reference [RFC 2283] in Reference section of RFC 3107. The reference is called [BGP-MP].

Errata ID: 4498

Status: Verified
Type: Technical

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2016-02-11

Section 3 says:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Next Hop attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Next Hop attribute of the route.

It should say:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

Notes:

Next Hop address for labeled routes is conveyed within MP_REACH_NLRI attribute.

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

Source of RFC: mmusic (rai)

Errata ID: 332

Status: Verified
Type: Technical

Reported By: Rajesh Kumar
Date Reported: 2002-05-22

Section 5.6 says:

   The base specification for SDP, RFC 2327 [1], allows the definition f
   new attributes.  In keeping with this spirit, some of the attributes
   defined in this document can also be used in SDP descriptions of IP
   nd other non-ATM sessions.  For example, the 'vsel', 'dsel' and
   'fsel' attributes defined below refer generically to codec-s.  These
   can be bed for service-specific codec negotiation and assignment in
   non-ATM s well as ATM applications.

It should say:

   The base specification for SDP, RFC 2327 [1], allows the definition of
   new attributes.  In keeping with this spirit, some of the attributes
   defined in this document can also be used in SDP descriptions of IP
   and other non-ATM sessions.  For example, the 'vsel', 'dsel' and
   'fsel' attributes defined below refer generically to codecs.  These
   can be used for service-specific codec negotiation and assignment in
   non-ATM as well as ATM applications.

Notes:

In Section 5.6.3: (First, Second and Third Bulleted items in List)
* The 'silenceSupp' attribute, used to indicate the use of of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.

* The 'ecan' attribute, used to indicate the use of of echo
cancellation, and to parameterize the this function.

* The 'gc' attribute, used to indicate the use of of gain
control, and to parameterize the this function.
Should be:
* The 'silenceSupp' attribute, used to indicate the use of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.

* The 'ecan' attribute, used to indicate the use of echo
cancellation, and to parameterize the this function.

* The 'gc' attribute, used to indicate the use of gain
control, and to parameterize the this function.
In Section 5.6.3.3:
When present, the 'ecan' attribute s is used to indicate the use or
non-use of echo cancellation. There can be several 'ecan' lines in
an SDP description.
Should be:
When present, the 'ecan' attribute is used to indicate the use or
non-use of echo cancellation. There can be several 'ecan' lines in
an SDP description.
In Section 5.6.6: (First numbered item)
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
controlsmessage to the originating media gateway (OMG).
Should be:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
control message to the originating media gateway (OMG).
In Section 6: (Sixth definition from top)
<vci> Virtual Circui t Decimal or hex equivalent
Identifier of 16 bits
Should be:
<vci> Virtual Circuit Decimal or hex equivalent
Identifier of 16 bits

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

Source of RFC: dnsext (int)

Errata ID: 2811

Status: Verified
Type: Technical

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

Section 3 says:

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

It should say:

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

Notes:

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

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

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

Errata ID: 4502

Status: Verified
Type: Editorial

Reported By: Mikko Rantanen
Date Reported: 2015-10-14
Verifier Name: Brian Haberman
Date Verified: 2015-10-14

Section 4 says:

conservative choice would be 65537 (F4, the fourth fermat number).

It should say:

conservative choice would be 65537 (F4, the fifth Fermat number).

Notes:

Numbering of Fermat numbers starts from zero. F4 and 65537 agree, but F4 is fifth Fermat number in the series, not fourth.

RFC 3118, "Authentication for DHCP Messages", June 2001

Source of RFC: dhc (int)

Errata ID: 3474

Status: Verified
Type: Technical

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

Section 2 says:

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

It should say:

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

Notes:

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

Strictly following that definition in the current section 2 would allow replays of captured packets. Changing the term to "strictly increasing" requires that subsequent values are greater than previous values. This would mean that a captured packet replayed with the same Authentication Information value would not meet the criteria described in my proposed corrected text, and should consequently be detected as a replay attack by a recipient.

The term monotonically increasing is also used at the end of Section 6 and should also be replaced with strictly increasing.

Also, the use of the term "time of day" could be problematic. If the first packet were sent just before midnight, and the second sent just after midnight, then the value of the second would be much lower than the value of the first. To align with the NTP example, I'm suggesting a change in text to be something that is actually increasing.

RFC 3119, "A More Loss-Tolerant RTP Payload Format for MP3 Audio", June 2001

Note: This RFC has been obsoleted by RFC 5219

Source of RFC: avt (rai)

Errata ID: 331

Status: Verified
Type: Technical

Reported By: Ross Finlayson
Date Reported: 2001-11-03

Section 8 says:

   the encoding name SHALL be "mp3" (the same as the MIME subtype).

It should say:

   the encoding name SHALL be "mpa-robust" (the same as the MIME
   subtype). 

Notes:

Appendix A:
"backpointer": the size (in bytes) of the backpointer for this
frame
Should be:
"backpointer": the value (expressed in bytes) of the backpointer for
this frame
Appendix A2:
In the function "insertDummyADUsIfNecessary()":
curADU
Should be:
prevADU
Appendix B2:
The two occurrences of "32" should be "256"

RFC 3122, "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", June 2001

Source of RFC: ipngwg (int)

Errata ID: 3696

Status: Verified
Type: Technical

Reported By: Arnold Plankl
Date Reported: 2013-08-14
Verifier Name: Brian Haberman
Date Verified: 2013-09-10

Section 2.2 says:

The sender node MUST send the following options in the Advertisement
   message:

   Source Link-Layer Address The link-layer address of the sender.

      Target Link-Layer Address
         The link-layer address of the target, that is, the sender of
         the advertisement.

It should say:

The sender node MUST send the following options in the Advertisement
message:

   Source Link-Layer Address
      The link-layer address of the node transmitting the
      Advertisement message

   Target Link-Layer Address
      The link-layer address of the node that transmitted the
      Solicitation message

Notes:

There is an ambiguity with the Source Link-Layer and Target Link-Layer Address option in the Inverse Neighbor Discovery Advertisement Message. It is unclear if SLLA is set to sender of the Advertisement or of the Solicitation, the same with TLLA. The RFC-text as it is would lead to SLL=TLL=sender of advertisement.

Here is an example for clarification of the problem (with 2 Ethernet-nodes, no FR):
Eth Node A - Eth Node B:
1. A sends IND S with SLLA=A, TLLA=B
2. B takes the address pair from SLLA and source-IP in ND cache
3. B answers with IND A with TAL(identified by TLLA in solicitation), SLLA=B,TLLA=B <- problem is here (SLLA=TLLA=B). Is that acceptable?
Or modify to: SLLA=A or TLLA=A? Or omit TLLA?
4. A takes the address pair from SLLA and the TAL in ND cache

Solution 1: B answers with IND A with TAL, SLLA=B, and TLLA=A => Then carries TLLA the address of the requesting node (is that acceptable as “target” address?)

Solution 2: B answers with IND A with TAL, SLLA=A, and TLLA=B => Then A could not take the address pair from SLLA and the TAL in ND cache.

RFC 3126, "Electronic Signature Formats for long term electronic signatures", September 2001

Note: This RFC has been obsoleted by RFC 5126

Source of RFC: smime (sec)

Errata ID: 1067

Status: Verified
Type: Technical

Reported By: Petra Barzin
Date Reported: 2003-02-13
Verifier Name: Russ Housley
Date Verified: 2003-02-17

Section 4.3.2 says:

   RevocationValues ::=  SEQUENCE {
      crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
      ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
      otherRevVals      [2] OtherRevVals
   }

It should say:

  RevocationValues ::=  SEQUENCE {
     crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
     ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
     otherRevVals      [2] OtherRevVals                    OPTIONAL
     }

Notes:

"OPTIONAL" is present in ETSI TS 101 733 V1.4.0

RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Source of RFC: pkix (sec)

Errata ID: 1879

Status: Verified
Type: Technical

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.

RFC 3165, "Definitions of Managed Objects for the Delegation of Management Scripts", August 2001

Source of RFC: disman (ops)

Errata ID: 330

Status: Verified
Type: Technical

Reported By: Juergen Schoenwaelder
Date Reported: 2001-09-03

Section 6 says:

       SYNTAX      Integer32 (1..2147483647)

It should say:

       SYNTAX      Integer32 (0..2147483647)

RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001

Source of RFC: tsvwg (tsv)

Errata ID: 3639

Status: Verified
Type: Technical

Reported By: Richard Scheffenegger
Date Reported: 2013-06-05
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17

Section 6.1 / 6.1.3 says:

Section 6.1 says:


      * The receiver receives the packet with the CE codepoint set, and
        sets the ECN-Echo flag in its next TCP ACK sent to the sender.
[...]

      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

Section 6.1.3 says:


   When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet. 

   [...]
                                               The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag.
   

It should say:

Section 6.1.3 should say:
 
   The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag. This check has to be performed before  
   checking if the received segment is CE marked.

Notes:

The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.


If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs.


All derivatives of BSD used to

First, set ECE because of CE
Second, reset ECE because of CWR

However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE

The latter approach seems to be the sensible one, and it was quickly fixed:

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html

Errata ID: 2307

Status: Verified
Type: Editorial

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.

RFC 3171, "IANA Guidelines for IPv4 Multicast Address Assignments", August 2001

Note: This RFC has been obsoleted by RFC 5771

Source of RFC: mboned (ops)

Errata ID: 1794

Status: Verified
Type: Technical

Reported By: Simon Perreault
Date Reported: 2009-06-17
Verifier Name: Ron Bonica
Date Verified: 2009-10-06

Section 2 says:

   224.0.2.0   - 224.0.255.0                   AD-HOC Block

It should say:

   224.0.2.0   - 224.0.255.255                 AD-HOC Block

Notes:

Section 5 mentions the AD-HOC block as being 224.0.2.0/24 - 224.0.255.0/24, which fits with the corrected text.

Furthermore, IANA has already assigned 224.0.255.0 - 224.0.255.255 for an AD-HOC usage.

RFC 3174, "US Secure Hash Algorithm 1 (SHA1)", September 2001

Source of RFC: INDEPENDENT

Errata ID: 328

Status: Verified
Type: Technical

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.

RFC 3180, "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].

RFC 3182, "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.

RFC 3183, "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.

RFC 3189, "RTP Payload Format for DV (IEC 61834) Video", January 2002

Note: This RFC has been obsoleted by RFC 6469

Source of RFC: avt (rai)

Errata ID: 326

Status: Verified
Type: Editorial

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

RFC 3196, "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"...

RFC 3204, "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

RFC 3207, "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>


RFC 3208, "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.

RFC 3209, "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.

RFC 3217, "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.

RFC 3219, "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.

RFC 3226, "DNSSEC and IPv6 A6 aware server/resolver message size requirements", December 2001

Source of RFC: dnsext (int)

Errata ID: 2810

Status: Verified
Type: Editorial

Reported By: Edward Lewis
Date Reported: 2011-05-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 2.1 says:

DNSSEC OK[OK] specifies how ...

It should say:

DNSSEC OK[RFC3225] specifies how ...

Notes:

Reference "link" is broken.

RFC 3245, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", March 2002

Source of RFC: IAB

Errata ID: 319

Status: Verified
Type: Technical

Reported By: Derrick D. Daugherty
Date Reported: 2004-01-02

Section 4.2 says:

4.2. Name server operator requirements

   RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the
   requirements for operating DNS root servers."

It should say:

4.2. Name server operator requirements

   RFC 2870 (http://www.ietf.org/rfc/rfc2870.txt) describes the
   requirements for operating DNS root servers."

RFC 3247, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", March 2002

Source of RFC: diffserv (tsv)

Errata ID: 318

Status: Verified
Type: Editorial

Reported By: "laercio cruvinel"
Date Reported: 2006-02-02

Section 2.1 says:

   Finally, there is an additional recommendation in [6] that an EF
   compliant node SHOULD NOT reorder packets within a micorflow.

It should say:

   Finally, there is an additional recommendation in [6] that an EF
   compliant node SHOULD NOT reorder packets within a microflow.

Notes:

micorflow --> microflow

RFC 3253, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", March 2002

Source of RFC: deltav (app)

Errata ID: 317

Status: Verified
Type: Technical

Reported By: Julian Reschke
Date Reported: 2003-10-11
Report Text:

The WebDAV working group maintains an errata list for RFC3253 at:
http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 316

Status: Verified
Type: Technical

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

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2015-12-17
Verifier Name: Ben Campbell
Date Verified: 2015-12-17

Section 20.11 says:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 [19].

It should say:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required" 
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

Errata ID: 2051

Status: Verified
Type: Editorial

Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 26.3.1 says:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to their canonical hostname. 

It should say:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to the DNS name other SIP devices will use to reach them. 

Notes:

The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.

RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

Source of RFC: sip (rai)

Errata ID: 315

Status: Verified
Type: Technical

Reported By: Steve Conner
Date Reported: 2002-07-04
Report Text:

This document obsoletes RFC 2543.


Errata ID: 4600

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 3 says:

The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header field.  The value
of the header field for the first reliable provisional response in a
transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
it be chosen uniformly in this range.  The RSeq numbering space is
within a single transaction.  This means that provisional responses
for different requests MAY use the same values for the RSeq number.

It should say:

The provisional response to be sent reliably is constructed by the
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing the
option tag 100rel, and MUST include an RSeq header field.  The
value of the header field for the first reliable provisional 
response in a transaction MUST be between 1 and 2**31 - 1.  It is
RECOMMENDED that it be chosen uniformly in this range. The RSeq 
numbering space is within a single transaction. This means that
the RSeq value of a provisional response within a fork of a request
is independent of the RSeq value of a provisional response within 
any other fork of that request, or for the responses for any other
request. It thus may be higher, lower, or the same as any other such
RSeq value.

Errata ID: 4601

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

If a provisional response is received for an initial request, and
that response contains a Require header field containing the option
tag 100rel, the response is to be sent reliably.  If the response is
a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
ignored, and the procedures below MUST NOT be used.

It should say:

If a provisional response is received for an initial request, and
that response contains a Require header field containing the option
tag 100rel, the response was sent by the UAS reliably.  If the
response is a 100 (Trying) (as opposed to 101 to 199), this option
tag MUST be ignored, and the procedures below MUST NOT be used.

Errata ID: 4602

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Assuming the response is to be transmitted reliably, the UAC MUST
create a new request with method PRACK.  This request is sent within
the dialog associated with the provisional response (indeed, the
provisional response may have created the dialog).  PRACK requests
MAY contain bodies, which are interpreted according to their type and
disposition.

It should say:

Assuming the response was transmitted reliably by the UAS, the UAC
MUST create a new request with method PRACK.  This request is sent
within the dialog associated with the provisional response (indeed,
the provisional response may have created the dialog). PRACK 
requests MAY contain bodies, which are interpreted according to
their type and disposition.

Errata ID: 4603

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Once a reliable provisional response is received, retransmissions of
that response MUST be discarded.  A response is a retransmission when
its dialog ID, CSeq, and RSeq match the original response.  The UAC
MUST maintain a sequence number that indicates the most recently
received in-order reliable provisional response for the initial
request.  This sequence number MUST be maintained until a final
response is received for the initial request.  Its value MUST be
initialized to the RSeq header field in the first reliable
provisional response received for the initial request.

It should say:

Once a reliable provisional response is received, retransmissions of
that response MUST be discarded.  A response is a retransmission 
when its dialog ID, CSeq, and RSeq match the original response. The
UAC MUST maintain, independently for each dialog ID, a sequence
number that indicates the most recently received in-order reliable
provisional response for the initial request.  This sequence number
MUST be maintained until a final response is received for the
initial request. Its value MUST, for each dialog (or early dialog),
be initialized to the RSeq header field in the first reliable
provisional response associated with the dialog received for the
initial request.

Notes:

Verifier edit: I removed two commas around "associated with the dialog" from the last sentence of the corrected text.

Errata ID: 4604

Status: Verified
Type: Technical

Reported By: Christer Holmberg
Date Reported: 2016-01-25
Verifier Name: Ben Campbell
Date Verified: 2016-01-25

Section 4 says:

Handling of subsequent reliable provisional responses for the same
initial request follows the same rules as above, with the following
difference: reliable provisional responses are guaranteed to be in
order.  As a result, if the UAC receives another reliable provisional
response to the same request, and its RSeq value is not one higher
than the value of the sequence number, that response MUST NOT be
acknowledged with a PRACK, and MUST NOT be processed further by the
UAC.  An implementation MAY discard the response, or MAY cache the
response in the hopes of receiving the missing responses.

It should say:

Subsequent reliable provisional responses for the same initial
request are guaranteed  to have been generated by the UAS in the
order of their RSeq values and must be acknowledged in that order.
As a result, if the UAC receives another reliable provisional
response to the same request, and its RSeq value is one higher than
the value of the previously received RSeq value in the dialog (or 
early dialog), then the new RSeq value is saved and the response is
handled as described above. If the RSeq value is not one higher than
the value of the sequence number, that response MUST NOT be
acknowledged with a PRACK, and MUST NOT be processed further by the
UAC. An implementation MAY discard the response, or MAY cache the
response to be processed (and acknowledged) after receiving the
missing responses.

RFC 3264, "An Offer/Answer Model with Session Description Protocol (SDP)", June 2002

Source of RFC: mmusic (rai)

Errata ID: 3818

Status: Verified
Type: Technical

Reported By: Jörgen Axell
Date Reported: 2013-12-02
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-12-03

Section 4 says:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the answer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

It should say:

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the offer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

Notes:

You can't reject an answer. When the answer is received the SDP negotiation is completed.

RFC 3265, "Session Initiation Protocol (SIP)-Specific Event Notification", June 2002

Note: This RFC has been obsoleted by RFC 6665

Source of RFC: sip (rai)

Errata ID: 314

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2002-07-23

In the Header:

   Updates: 2543

It should say:

   Updates: 3261

RFC 3266, "Support for IPv6 in Session Description Protocol (SDP)", June 2002

Note: This RFC has been obsoleted by RFC 4566

Source of RFC: mmusic (rai)

Errata ID: 313

Status: Verified
Type: Editorial

Reported By: Bernie Hoeneisen
Date Reported: 2004-01-15

 

Section 1 refers to RFC 2328 as follows:

   Accordingly, the address type "IP6" indicating an IPv6 address,
   should be allowed in the connection field, "c=", of the SDP.  The
   ABNF already reflects this, though the "Connection Data" text under
   section 6 of RFC 2328 currently only defines the "IP4" address type.
                    ^^^^
It should refer to RFC 2327.

RFC 3267, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", June 2002

Note: This RFC has been obsoleted by RFC 4867

Source of RFC: avt (rai)

Errata ID: 312

Status: Verified
Type: Technical

Reported By: Frederic Turgis
Date Reported: 2002-07-29

Section 5.3 says:

   The FT field and the Q bit are defined in the same way as in
   Section 4.1.2. The P bits are padding and MUST be set to 0.

It should say:

   The FT field and the Q bit are defined in the same way as in
   Section 4.3.2. The P bits are padding and MUST be set to 0.

RFC 3271, "The Internet is for Everyone", April 2002

Source of RFC: IETF - NON WORKING 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.

RFC 3272, "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.

RFC 3275, "(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


RFC 3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Source of RFC: pkix (sec)

Errata ID: 307

Status: Verified
Type: Technical

Reported By: Olivier Dierick
Date Reported: 2005-08-01

Section 1 says:

   This document specifies algorithm identifiers and ASN.1 [X.660]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

It should say:

   This document specifies algorithm identifiers and ASN.1 [X.690]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

Notes:


In Section 4, it says:
[X.660] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
It should say:
[X.690] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.



Errata ID: 2048

Status: Verified
Type: Technical

Reported By: Jim Wigginton
Date Reported: 2009-10-12
Verifier Name: Pasi Eronen
Date Verified: 2010-02-22

Section 2.3.5 says:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }

It should say:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(3) }

Notes:

Note that this bug is only in Section 2.3.5; the ASN.1 module in Section 3 has the correct OID.

Errata ID: 4036

Status: Verified
Type: Technical

Reported By: Matthias Koenig
Date Reported: 2014-07-03
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 2.3.3 says:

g specifies the generator of the multiplicative subgroup of order g;

It should say:

g specifies the generator of the multiplicative subgroup of order q;

Notes:

RFC2631 states that g is of order q mod p (section 2.1.1).
Also, X9.42 (which is referenced in section 2.3.3 of RFC3279) defines g as
"generator of the q-order cyclic subgroup of GF(p), that is, an element of order q in the multiplicative group of GF(p)" (X9.42:2001, section 4.1)

Errata ID: 4102

Status: Verified
Type: Editorial

Reported By: Annie Yousar
Date Reported: 2014-09-07
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 1 says:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adelman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

It should say:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adleman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

Notes:

Len is "Adleman" and not "Adelman". The error repeats a few lines later again. The spelling in 2.2.1 is correct.

RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Note: This RFC has been obsoleted by RFC 5280

Source of RFC: pkix (sec)

Errata ID: 305

Status: Verified
Type: Technical

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.

RFC 3281, "An Internet Attribute Certificate Profile for Authorization", April 2002

Note: This RFC has been obsoleted by RFC 5755

Source of RFC: pkix (sec)

Errata ID: 302

Status: Verified
Type: Technical

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

RFC 3289, "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).


RFC 3297, "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)

RFC 3300, "Internet Official Protocol Standards", November 2002

Note: This RFC has been obsoleted by RFC 3600

Source of RFC: INDEPENDENT

Errata ID: 298

Status: Verified
Type: Technical

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

RFC 3304, "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

RFC 3305, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", August 2002

Source of RFC: 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]

RFC 3315, "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

RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002

Source of RFC: sip (rai)

Errata ID: 3744

Status: Verified
Type: Technical

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.

RFC 3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Source of RFC: sip (rai)

Errata ID: 3799

Status: Verified
Type: Technical

Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14

Section Appendix A says:

spivalue           = 10DIGIT; 0 to 4294967295

It should say:

spivalue           = 1*10DIGIT; 0 to 4294967295

Notes:

The number string does not have to have 10 digit characters if the number is not 10 digits in length.

RFC 3339, "Date and Time on the Internet: Timestamps", July 2002

Source of RFC: impp (app)

Errata ID: 4110

Status: Verified
Type: Technical

Reported By: Derek P. Moore
Date Reported: 2014-09-12
Verifier Name: Barry Leiba
Date Verified: 2014-09-29

Section Appendix A says:

   ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
   be proceeded by a "0" if less than unity.  Annex B.2 of ISO 8601
   gives examples where the decimal fractions are not preceded by a "0".
   This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
   in error.

It should say:

   ISO 8601/Cor1:1991 also requires (in section 5.3.1.3) that a decimal
   fraction be proceeded by "00" if less than unity.


Notes:

ISO 8601:1988/Cor 1:1991 says:

"Subclause 5.3.1.3
"Last line, delete “shall be preceded by a zero” and insert “shall be preceded by two zeros in accordance with 4.6” "

The RFC3339 grammar never allowed just one zero ("0") preceding the fraction and has always been compliant with ISO 8601/Cor 1:1991.

----- Note from the RFC authors -----
There are interpretations of ISO 8601 under which section 5.3.1.3 and Annex B.2 are entirely consistent, and the implication that they are in conflict can cause confusion.

----- Note from the Area Director -----
There is a newer version of the ISO spec, ISO 8601:2004. That version came after this RFC, so it cannot be a definitive reference with respect to this RFC, but readers should be aware of the newer version.

Errata ID: 293

Status: Verified
Type: Editorial

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

RFC 3345, "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.

RFC 3348, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", July 2002

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 2020

Status: Verified
Type: Editorial

Reported By: Barry Leiba
Date Reported: 2010-01-26
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10

Section 3 says:

   In some instances a server that supports the CHILDREN extension MAY
   NOT be able to determine whether a mailbox has children.

It should say:

   In some instances a server that supports the CHILDREN extension might
   not be able to determine whether a mailbox has children.

Notes:

The "may not" in this sentence is not normative text, but is just a statement of fact. It should not be rendered as an RFC 2119 term.

RFC 3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", August 2002

Source of RFC: dnsext (int)

Errata ID: 1680

Status: Verified
Type: Technical

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

Section "Bitlabels" says:

addresses, it proposes to use a new kind of DNS label (a "bit label")
to represent binary addresses directly in the DNS.

It should say:

addresses, it proposes to use a new kind of DNS label (a "bit label"), 
specified in [RFC2673],
to represent binary addresses directly in the DNS.

*** RFC 2673 should also appear in the References section.***

Notes:

This document is listed as updating RFC 2673. That claim is actually dubious, since it simply explains why one particular application of 2673 may not be appropriate, an application that is not even mentioned in 2673 itself. But, if it does actually update 2673, then it should be possible for the reader to deduce how the two document interact without extensive detective work.

An alternative fix would be to remove the entry indicating updating of 2673 from the header of this document and corresponding indexes and references -- what this actually updates is 2874, which specifies a particular application of 2673.

RFC 3369, "Cryptographic Message Syntax (CMS)", August 2002

Note: This RFC has been obsoleted by RFC 3852

Source of RFC: smime (sec)

Errata ID: 291

Status: Verified
Type: Technical

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.


RFC 3370, "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.

RFC 3372, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", September 2002

Source of RFC: sipping (rai)

Errata ID: 288

Status: Verified
Type: Technical

Reported By: Feng Zhang
Date Reported: 2002-09-22
Report Text:

References to Figures 3, 5, and 7 should refer to Figures 2, 3, and 4, respectively.


RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Source of RFC: idmr (rtg)

Errata ID: 1501

Status: Verified
Type: Editorial

Reported By: Dave Thaler
Date Reported: 2008-09-08
Verifier Name: Adrian Farrel
Date Verified: 2013-05-11

The header says:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

It should say:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Updates: 2236                                                 S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

Notes:

RFC 3376 does not completely replace RFC 2236, so it should say "updates" instead of "obsoletes". Specifically, to have a compliant implementation of RFC 3376 section 4, one MUST understand and implement the "Version 2 Membership Report" and "Version 2 Leave Group" messages. This is why RFC 2236 is listed as a normative reference of RFC 3376.

RFC 3377, "Lightweight Directory Access Protocol (v3): Technical Specification", September 2002

Note: This RFC has been obsoleted by RFC 4510

Source of RFC: ldapbis (app)

Errata ID: 287

Status: Verified
Type: Technical

Reported By: Jeff Hodges
Date Reported: 2002-09-26
Report Text:

This document updates RFCs 2251-2256, 2829 and 2830.


RFC 3381, "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'.

RFC 3385, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", September 2002

Source of RFC: Legacy

Errata ID: 286

Status: Verified
Type: Technical

Reported By: Vicente Cavanna
Date Reported: 2002-11-18

Section 8.1 says:

   ///////////////////////////////////////////////////////////////////////
   // File:  CRC32_D1.v
   // Date:  Mon Nov 18 18:51:31 2002
   //
   // Copyright (C) 1999 Easics NV.
   // This source file may be used and distributed without restriction
   // provided that this copyright statement is not removed from the file
   // and that any derivative work contains the original copyright notice
   // and the associated disclaimer.
   //
   // THIS SOURCE FILE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS
   // OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
   // WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
   //
   // Purpose: Verilog module containing a synthesizable CRC function
   //   * polynomial: p(0 to 32) := "100000101111011000111011011110001"
   //   * data width: 1
   //
   // Info: jand@easics.be (Jan Decaluwe)
   //       http://www.easics.com
   ///////////////////////////////////////////////////////////////////////


   module CRC32_D1;
 
     // polynomial: p(0 to 32) := "100000101111011000111011011110001"
     // data width: 1
     function [31:0] nextCRC32_D1;

       input Data;
       input [31:0] CRC;
 
       reg [0:0] D;
       reg [31:0] C;
       reg [31:0] NewCRC;

     begin

       D[0] = Data;
       C = CRC;

       NewCRC[0] = D[0] ^ C[31];
       NewCRC[1] = C[0];
       NewCRC[2] = C[1];
       NewCRC[3] = C[2];
       NewCRC[4] = C[3];
       NewCRC[5] = C[4];
       NewCRC[6] = D[0] ^ C[5] ^ C[31];
       NewCRC[7] = C[6];
       NewCRC[8] = D[0] ^ C[7] ^ C[31];
       NewCRC[9] = D[0] ^ C[8] ^ C[31];
       NewCRC[10] = D[0] ^ C[9] ^ C[31];
       NewCRC[11] = D[0] ^ C[10] ^ C[31];
       NewCRC[12] = C[11];
       NewCRC[13] = D[0] ^ C[12] ^ C[31];
       NewCRC[14] = D[0] ^ C[13] ^ C[31];
       NewCRC[15] = C[14];
       NewCRC[16] = C[15];
       NewCRC[17] = C[16];
       NewCRC[18] = D[0] ^ C[17] ^ C[31];
       NewCRC[19] = D[0] ^ C[18] ^ C[31];
       NewCRC[20] = D[0] ^ C[19] ^ C[31];
       NewCRC[21] = C[20];
       NewCRC[22] = D[0] ^ C[21] ^ C[31];
       NewCRC[23] = D[0] ^ C[22] ^ C[31];
       NewCRC[24] = C[23];
       NewCRC[25] = D[0] ^ C[24] ^ C[31];
       NewCRC[26] = D[0] ^ C[25] ^ C[31];
       NewCRC[27] = D[0] ^ C[26] ^ C[31];
       NewCRC[28] = D[0] ^ C[27] ^ C[31];
       NewCRC[29] = C[28];
       NewCRC[30] = C[29];
       NewCRC[31] = C[30];

       nextCRC32_D1 = NewCRC;

     end

     endfunction

   endmodule

RFC 3389, "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", September 2002

Source of RFC: avt (rai)

Errata ID: 285

Status: Verified
Type: Editorial

Reported By: Magnus Westerlund
Date Reported: 2004-01-22

 

In section 5.1, it says:

         m=audio 49230 RTP/AVP 101 102
         a=rtpmap:101 G7221/16000
         a=fmtp:121 bitrate=24000
         a=rtpmap:102 CN/16000

It should say:

         m=audio 49230 RTP/AVP 101 102
         a=rtpmap:101 G7221/16000
         a=fmtp:101 bitrate=24000
                ^^^
         a=rtpmap:102 CN/16000

RFC 3390, "Increasing TCP's Initial Window", October 2002

Source of RFC: tsvwg (tsv)

Errata ID: 4569

Status: Verified
Type: Technical

Reported By: Nikolai Malykh
Date Reported: 2015-12-22
Verifier Name: Martin Stiemerling
Date Verified: 2016-01-12

Section 8.1 says:

   A second set of experiments explored TCP performance over dialup
   modem links.  In experiments over a 28.8 bps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A simulation study [RFC2416] investigated the effects of using
   a larger initial window on a host connected by a slow modem link and
   a router with a 3 packet buffer.  The study concluded that for the
   scenario investigated, the use of larger initial windows was not
   harmful to TCP performance.

It should say:

   A second set of experiments explored TCP performance over dialup
   modem links.  In experiments over a 28.8 kbps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A simulation study [RFC2416] investigated the effects of using
   a larger initial window on a host connected by a slow modem link and
   a router with a 3 packet buffer.  The study concluded that for the
   scenario investigated, the use of larger initial windows was not
   harmful to TCP performance.

Notes:

Error bit rate - kbps instead of bps.

Errata ID: 4583

Status: Verified
Type: Technical

Reported By: Joe Touch
Date Reported: 2016-01-06
Verifier Name: Martin Stiemerling
Date Verified: 2016-04-03

Section 1. says:

   This increased initial window is optional: a TCP MAY start with a
   larger initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

It should say:

   This increased initial window is optional: a TCP MAY start with a
   smaller initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

Notes:

The MAY allows use of values smaller than this document allows, not larger.

RFC 3394, "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.

RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002

Source of RFC: urn (app)

Errata ID: 283

Status: Verified
Type: Editorial

Reported By: Olaf M. Kolkman
Date Reported: 2005-12-29
Verifier Name: Alexey Melnikov
Date Verified: 2010-04-02

Section 5 says:

Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]

It should say:

Part Three: The Domain Name System (DNS) Database" (RFC 3403) [2]

RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002

Source of RFC: urn (app)

Errata ID: 282

Status: Verified
Type: Editorial

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

RFC 3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002

Source of RFC: urn (app)

Errata ID: 2687

Status: Verified
Type: Technical

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.

RFC 3406, "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.

RFC 3410, "Introduction and Applicability Statements for Internet-Standard Management Framework", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 281

Status: Verified
Type: Technical

Reported By: C. M. Heard
Date Reported: 2003-01-29

Section 10.2 says:

  [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
       "Coexistence between Version 1 and Version 2 of the Internet-
       Standard Network Management Framework", RFC 2576, January 1996.

It should say:

  [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
       "Coexistence between Version 1 and Version 2 of the Internet-
       Standard Network Management Framework", RFC 1908, January 1996.

RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2459

Status: Verified
Type: Technical

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


RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 278

Status: Verified
Type: Technical

Reported By: Piotr Bandur
Date Reported: 2003-10-28

Section 6.3.1 says:

   4) Prepend K2 to the result of the step 4 and calculate MD5 digest
      over it according to [RFC1321].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

It should say:

   4) Prepend K2 to the result of the step 3 and calculate MD5 digest
      over it according to [RFC1321].  Take the first 12 octets of the
      final digest - this is Message Authentication Code (MAC).

Notes:

In Section 7.3.1:
4) Prepend K2 to the result of the step 4 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).
Should be:
4) Prepend K2 to the result of the step 3 and calculate SHA digest
over it according to [SHA-NIST]. Take the first 12 octets of
the final digest - this is Message Authentication Code (MAC).

RFC 3415, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 277

Status: Verified
Type: Technical

Reported By: Guan Hai Bing
Date Reported: 2002-12-27

In Section A.1:

   (a) "system"       (subtree 1.3.6.1.2.1.1)      [RFC3918]
   (b) "snmp"         (subtree 1.3.6.1.2.1.11)     [RFC3918]

It should say:

   (a) "system"       (subtree 1.3.6.1.2.1.1)      [RFC3418]
   (b) "snmp"         (subtree 1.3.6.1.2.1.11)     [RFC3418]

RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2757

Status: Verified
Type: Technical

Reported By: Mikhail Kulinich
Date Reported: 2011-03-27
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03

Section 3 says:

PDU ::= SEQUENCE {
           request-id INTEGER (-214783648..214783647),

           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-214783648..214783647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

It should say:

PDU ::= SEQUENCE {
           request-id INTEGER (-2147483648..2147483647),
           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-2147483648..2147483647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

Notes:

Consider the following dump as a Response to a Get Request:

Received 125 bytes from UDP: [127.0.0.1]:161->[0.0.0.0]
0000: 30 7B 02 01 03 30 11 02 04 5B 70 9B 75 02 03 00 0{...0...[p.u...
0016: FF E3 04 01 01 02 01 03 04 2E 30 2C 04 0D 80 00 ..........0,....
0032: 1F 88 80 82 0B 53 2D 67 01 8A 4D 02 01 01 02 03 .....S-g..M.....
0048: 02 7B 92 04 03 77 65 73 04 0C DF 8B 2A FE 4A C5 .{...wes....*.J.
0064: 4C 33 63 A6 2C C8 04 00 30 33 04 0D 80 00 1F 88 L3c.,...03......
0080: 80 82 0B 53 2D 67 01 8A 4D 04 00 A2 20 02 04 67 ...S-g..M... ..g
0096: DB 56 C4 02 01 00 02 01 00 30 12 30 10 06 0A 2B .V.......0.0...+
0112: 06 01 02 01 5C 01 01 01 00 42 02 03 E8 ....\....B...

NOTIFICATION-LOG-MIB::nlmConfigGlobalEntryLimit.0 = Gauge32: 1000

It was produced with the following command:
$ snmpget -v3 -n "" -c public -u wes -a md5 -A setup_passphrase -l authNoPriv -d localhost nlmConfigGlobalEntryLimit.0

While decoding (with my own tool) the message above, I met a constraint error with ASN.1 describing SNMPv3 message.
The actual issue with request-id parameter inside PDU & BulkPDU definitions.

Received value (from dump):
request-id = 1742427844

ASN.1:
request-id INTEGER (-214783648..214783647)

You can see that may be in number = 214783647, 4 is missed. I.e.: should be the following: 2147_4_83647

----------

Verifier Note:

There is indeed an error in the RFC, but the "correction" text is also incorrect.
The two changes needed are:

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),

RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 276

Status: Verified
Type: Technical

Reported By: Glenn M. Keeni
Date Reported: 2003-08-22

In the text, it says:

   6.1.  Informative References

It should say:

   6.2.  Informative References

RFC 3420, "Internet Media Type message/sipfrag", November 2002

Source of RFC: sip (rai)

Errata ID: 274

Status: Verified
Type: Technical

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:


RFC 3424, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", November 2002

Source of RFC: IAB

Errata ID: 273

Status: Verified
Type: Technical

Reported By: Leslie Daigle
Date Reported: 2002-11-19

The center page header:

   IAB Considerations for UNSAP Across NAT

It should say:

   IAB Considerations for UNSAF Across NAT

RFC 3433, "Entity Sensor Management Information Base", December 2002

Source of RFC: entmib (ops)

Errata ID: 2008

Status: Verified
Type: Editorial

Reported By: Minoru Teraoka
Date Reported: 2010-01-18
Verifier Name: Dan Romascanu
Date Verified: 2010-05-10

Section 4 says:

        exa(14),    -- 10^15
        peta(15),   -- 10^18

It should say:

        peta(14),   -- 10^15
        exa(15),    -- 10^18

RFC 3435, "Media Gateway Control Protocol (MGCP) Version 1.0", January 2003

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

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.

RFC 3439, "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.

RFC 3445, "Limiting the Scope of the KEY Resource Record (RR)", December 2002

Note: This RFC has been obsoleted by RFC 4033 RFC 4034 RFC 4035

Source of RFC: dnsext (int)

Errata ID: 272

Status: Verified
Type: Editorial

Reported By: "Scott Rose"
Date Reported: 2005-02-22
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Values for the key protocol octet are incorrect. They should be:

        VALUE   Protocol

          0      -reserved
          1     reserved (was TLS)
          2     reserved (was email)
          3     dnssec
          4     reserved (was IPSEC)
         5-255   reserved

Notes:

Rationale: Looking at RFC2535, the values are the original assignments. The
numbers in RFC3445 are incorrect and don't match. I guess since the
registry was closed, they are all reserved now and no one double checked.

RFC 2535 has the original correct assignments, and the registry is correct
in stating that they are now all reserved.

RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003

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

RFC 3448, "TCP Friendly Rate Control (TFRC): Protocol Specification", January 2003

Note: This RFC has been obsoleted by RFC 5348

Source of RFC: tsvwg (tsv)

Errata ID: 270

Status: Verified
Type: Technical

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)

RFC 3454, "Preparation of Internationalized Strings ("stringprep")", December 2002

Note: This RFC has been obsoleted by RFC 7564

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

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

RFC 3461, "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", January 2003

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

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

RFC 3464, "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.

RFC 3468, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", February 2003

Source of RFC: mpls (rtg)

Errata ID: 695

Status: Verified
Type: Technical

Reported By: Alex Zinin
Date Reported: 2004-10-23
Verifier Name: Adrian Farrel
Date Verified: 2010-01-02

The header says:

Network Working Group                                       L. Andersson
Request for Comments: 3468                                    Consultant
Category: Informational                                       G. Swallow
                                                           Cisco Systems
                                                           February 2003

It should say:

Network Working Group                                       L. Andersson
Request for Comments: 3468                                    Consultant
Updates: 3212, 3472, 3475, 3476                               G. Swallow
Category: Informational                                    Cisco Systems
                                                           February 2003

Notes:

RFC3468 documents the MPLS WG's decision to ice CR-LDP.
However, RFC3468 is not marked as updating RFC3212 (CR-LDP base spec) in the registry.

The RFCs updated by 3468 are:
3212, 3472, 3475, 3476

[Note that the RFC Editor index has been updated accordingly, but the document itself remains incorrect.]

Originally sent by Adrian Farrel.

from pending

RFC 3470, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003

Source of RFC: IETF - NON WORKING 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."

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", January 2003

Source of RFC: ccamp (rtg)

Errata ID: 1977

Status: Verified
Type: Editorial

Reported By: Zongpeng Du
Date Reported: 2009-12-24
Verifier Name: Adrian Farrel
Date Verified: 2009-12-27

Section 2 says:

Another basic difference between traditional and non-PSC types of
generalized MPLS LSPs, is that bandwidth allocation for an LSP can be
performed only in discrete units, see Section 3.1.3. 

It should say:

Another basic difference between traditional and non-PSC types of
generalized MPLS LSPs, is that bandwidth allocation for an LSP can be
performed only in discrete units, see Section 3.1.2. 

Notes:

Fix to point to correct section number.

RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003

Source of RFC: ccamp (rtg)

Errata ID: 267

Status: Verified
Type: Technical

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

Status: Verified
Type: Technical

Reported By: Alexander Okonnikov
Date Reported: 2016-01-08
Verifier Name: Deborah Brungard
Date Verified: 2016-02-10

Section 5.2.1 says:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label ERO subobjects
   for both downstream and upstream labels MUST be included.

It should say:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label RRO subobjects
   for both downstream and upstream labels MUST be included.

Notes:

RRO in place of ERO.

Errata ID: 2159

Status: Verified
Type: Editorial

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

Errata ID: 4467

Status: Verified
Type: Editorial

Reported By: Alexander Okonnikov
Date Reported: 2015-09-08
Verifier Name: Deborah Brungard
Date Verified: 2015-09-10

Section 2.4 says:

Waveband switching uses the same format as the generalized label, see
   section 2.2.

It should say:

Waveband switching uses the same format as the generalized label, see
   section 2.3.

Notes:

Incorrect reference.

RFC 3490, "Internationalizing Domain Names in Applications (IDNA)", March 2003

Note: This RFC has been obsoleted by RFC 5890 RFC 5891

Source of RFC: idn (int)

Errata ID: 266

Status: Verified
Type: Technical

Reported By: Adam Costello
Date Reported: 2003-04-28

Section 4.2 says:

   The ToUnicode output never contains more code points than its
   input.

This is not true; I have constructed a counterexample.  

It should say:

    The Punycode decoder can never output more code points than it
    inputs, but Nameprep can, and therefore ToUnicode can.

RFC 3492, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", March 2003

Source of RFC: idn (int)

Errata ID: 265

Status: Verified
Type: Technical

Reported By: Adam Costello
Date Reported: 2003-04-28

Section 6.4 says:

   where maxint is the greatest integer for which maxint + 1 cannot be
   represented.

It should say:

   where maxint is the maximum value of an integer variable.

RFC 3494, "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", March 2003

Source of RFC: Legacy

Errata ID: 264

Status: Verified
Type: Technical

Reported By: Marshall Price
Date Reported: 2004-10-15

In the "Dependent Specifications" section, it says:

RFC 1781 is a technical specification for "User Friendly Naming"
which replies on particular syntaxes described in RFC 1779.

It should say:

RFC 1781 is a technical specification for "User Friendly Naming"
which relies on particular syntaxes described in RFC 1779.

RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003

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.

RFC 3507, "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/





RFC 3514, "The Security Flag in the IPv4 Header", April 2003

Source of RFC: Legacy

Errata ID: 4390

Status: Verified
Type: Editorial

Reported By: -
Date Reported: 2015-06-10

Section 5 says:

this permit easy encoding

It should say:

this permits easy encoding

Notes:

permit -> permits. Singular verb form instead of plural

RFC 3516, "IMAP4 Binary Content Extension", April 2003

Source of RFC: INDEPENDENT

Errata ID: 3978

Status: Verified
Type: Editorial

Reported By: Michael Slusarz
Date Reported: 2014-04-29
Verifier Name: Nevil Brownlee
Date Verified: 2014-08-18

Section 4.3 says:

If the domain of the decoded data is "8bit" and the data does
not contain the NUL octet, the server SHOULD return the data in
a <string> instead of a <literal8>; this allows the client to
determine if the "8bit" data contains the NUL octet without
having to explicitly scan the data stream for for NULs.

It should say:

If the domain of the decoded data is "8bit" and the data does
not contain the NUL octet, the server SHOULD return the data in
a <string> instead of a <literal8>; this allows the client to
determine if the "8bit" data contains the NUL octet without
having to explicitly scan the data stream for NULs.

Notes:

Typo: duplication of "for".

RFC 3525, "Gateway Control Protocol Version 1", June 2003

Note: This RFC has been obsoleted by RFC 5125

Source of RFC: megaco (rai)

Errata ID: 256

Status: Verified
Type: Editorial

Reported By: Tom Taylor
Date Reported: 2005-09-13
Report Text:

Errata can be found in the ITU-T Implementor's Guide at:
http://www.itu.int/itudoc/itu-t/com16/implgd/h248.1v1.html


RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003

Note: This RFC has been obsoleted by RFC 7530

Source of RFC: nfsv4 (tsv)

Errata ID: 2613

Status: Verified
Type: Technical

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

RFC 3537, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", May 2003

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


RFC 3542, "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".

RFC 3548, "The Base16, Base32, and Base64 Data Encodings", July 2003

Note: This RFC has been obsoleted by RFC 4648

Source of RFC: INDEPENDENT

Errata ID: 3916

Status: Verified
Type: Editorial

Reported By: Daira Hopwood
Date Reported: 2014-03-10
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section References says:

   [12]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
         http://zgp.org/pipermail/p2p-hackers/2001-September/
         000315.html, September 2001.

It should say:

   [8]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
         http://zgp.org/pipermail/p2p-hackers/2001-September/
         000313.html, September 2001.

Notes:

Noticed by Zancas Wilcox.

This erratum was submitted as a correct to reference [12], however
RFC 3548 has it as [8].

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Source of RFC: IAB

Errata ID: 2142

Status: Verified
Type: Editorial

Reported By: Lev Novikov
Date Reported: 2010-04-08
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.2.2 says:

   Note that if the client has a certificate than SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

It should say:

   Note that if the client has a certificate then SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

Notes:

Changed "than" to "then".

Errata ID: 2248

Status: Verified
Type: Editorial

Reported By: Glen Zorn
Date Reported: 2010-05-07
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.1 says:

modifying with the kernel or installing new drivers.  

It should say:

modifying the kernel or installing new drivers.  

Notes:

Correct poor grammar.

Errata ID: 3828

Status: Verified
Type: Editorial

Reported By: Eliot Lear
Date Reported: 2013-12-09
Verifier Name: RFC Editor
Date Verified: 2014-09-03

Section 5 says:

Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In

It should say:

Part of the purpose of the Security Considerations section
is to explain what attacks are in and out of scope and what
countermeasures can be applied to defend against them.

Notes:

Note dangling "In".

Not sure if this is exactly what the authors had in mind, and might suggest a more substantial change in a document update. For the moment I *think* this covers it.

Errata ID: 4563

Status: Verified
Type: Editorial

Reported By: Walter Dolce
Date Reported: 2015-12-13
Verifier Name: Andrew Sullivan
Date Verified: 2016-01-07

Section 4.2. says:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can very widely in the degree of security offered.

It should say:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can vary widely in the degree of security offered.

Notes:

At the end of the paragraph, I think "very" should be changed to "vary"

RFC 3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003

Source of RFC: IETF - NON WORKING 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.

RFC 3580, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", September 2003

Source of RFC: INDEPENDENT

Errata ID: 1503

Status: Verified
Type: Technical

Reported By: Avi Lior
Date Reported: 2008-09-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 3.21 says:

For IEEE 802.1X Authenticators, this attribute is used to store the
   Supplicant MAC address in ASCII format (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".

It should say:

For IEEE Std 802.1X-2001 authenticators, this attribute is used to store
the Supplicant MAC address, represented as an ASCII character string in
Canonical format (see IEEE Std 802). For example, "00-10-A4-23-19-C0".

Notes:

The IETF Informational RFC needed to specify that the representation of the MAC address is in Canonical Format.

This is the case in the IEEE document 802_1x-2001 which is the corrected text provided.

I would be okay if the authors wanted to use Supplicant MAC address instead of "bridge or Access Point" in the proposed corrected text.

Errata ID: 4484

Status: Verified
Type: Technical

Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 2.2 says:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Access Points to cause multiple RADIUS accounting packets to be sent
   by different Access Points.

It should say:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Basic Service Sets to cause multiple RADIUS accounting packets to be
   sent by the same or different Access Points.

Notes:

This was written in the context of an Access Point only offering a single Basic Service Set, predating Access Points containing multiple radios or supporting Virtual Access Points. It is not accurate today.

Errata ID: 4491

Status: Verified
Type: Technical

Reported By: Nick Lowe
Date Reported: 2015-10-04
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 3.20 says:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge or Access Point MAC address in ASCII format (upper case only),
   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   Access Point MAC address, separated from the MAC address with a ":".
   Example "00-10-A4-23-19-C0:AP1".

It should say:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   BSSID, separated from the BSSID with a ":".
   Example "00-10-A4-23-19-C0:AP1".

   The Called-Station-Id MUST be UTF-8 encoded.

Notes:

The RFC was written in the context of an Access Point only offering a
single Basic Service Set, predating and not anticipating Access Points
containing multiple radios or supporting Virtual Access Points. It is
not accurate today and the RFC should originally have stated a Basic
Service Set. It was an error to not state this.

This errata, however, emphatically does not change the original
meaning or intention of the RFC. Basic Service Set was always meant.

Since 802.11 SSIDs may be UTF-8 encoded, the Called-Station-Id MUST always be treated as being UTF-8 encoded in the context of 802.1X to accommodate 802.11 where the SSID has been appended. (This inherently encodes the bridge MAC address or IEEE 802.11 BSSID as ASCII would.)

RFC 3588, "Diameter Base Protocol", September 2003

Note: This RFC has been obsoleted by RFC 6733

Source of RFC: aaa (ops)

Errata ID: 773

Status: Verified
Type: Technical

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.

Notes:

(There is no such AVP named Disconnection-Reason)

RFC 3589, "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5", September 2003

Source of RFC: INDEPENDENT

Errata ID: 4310

Status: Verified
Type: Editorial

Reported By: Alexander Okonnikov
Date Reported: 2015-03-23
Verifier Name: Nevil Brownlee
Date Verified: 2015-06-30

Section ToC says:

...
   4.  Acknowledgements............................................... 3
   5.  Intellectual Property Statement................................ 3
...

It should say:

...
   4.  Intellectual Property Statement................................ 3
   5.  Acknowledgements............................................... 3
...

Notes:

Interchanged references to sections 4 and 5.

RFC 3597, "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.

RFC 3605, "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".

RFC 3611, "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".

Errata ID: 3795

Status: Verified
Type: Technical

Reported By: Stephen James
Date Reported: 2013-11-11
Verifier Name: Ben Campbell
Date Verified: 2015-07-22

Section 5.1 says:

rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

It should say:

rtcp-xr-attrib = "a=" "rtcp-xr" [ ":" xr-format *(SP xr-format)] CRLF

Notes:

The ABNF for the attribute is causing some interoperability issues.
The text as written shows that the colon is required while the parameters are optional.
This leaves the format: "a=rtcp-xr:" the required format. Vendors are using "a=rtcp-xr" which strictly violates the ABNF above. Moving the ':' into the optional part seems correct.

Errata ID: 4597

Status: Verified
Type: Technical

Reported By: Liu Yuanlong
Date Reported: 2016-01-22
Verifier Name: Ben Campbell
Date Verified: 2016-05-25

Section 4.7.2 says:

burst density 84, which corresponds to 33%

It should say:

burst density 85, which corresponds to 33%

Notes:

error calculation for burst density, burst density=4/12*256=85.33...?85

RFC 3625, "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)

RFC 3627, "Use of /127 Prefix Length Between Routers Considered Harmful", September 2003

Note: This RFC has been obsoleted by RFC 6547

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)

RFC 3633, "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.

RFC 3647, "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
   ------------------------------------------------------

RFC 3650, "Handle System Overview", November 2003

Source of RFC: INDEPENDENT

Errata ID: 4466

Status: Verified
Type: Editorial

Reported By: Michael Message
Date Reported: 2015-09-07
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 10 says:

[1] Kahn, R. and R. Wilensky, "A Framework for Distributed 
Digital Object Services", D-Lib Magazine, 1995.

It should say:

1] Kahn, R. and R. Wilensky, "A Framework for Distributed 
Digital Object Services", D-Lib Magazine, 1995.
This paper is now out of print.  A more recent version of it is
accessible at
https://www.doi.org/topics/2006_05_02_Kahn_Framework.pdf

Notes:

A search of the on-line index to that Journal,
http://www.dlib.org/author-index.html#K,
for that article fails.

Per the Managing Editor of D-Lib Magazine (in March 2016):

A correct citation for the original paper in the RFC should simply be:

Kahn, Robert E., Robert Wilensky, "A Framework for Distributed Digital Object Services", May 1995. http://hdl.handle.net/4263537/5001.

RFC 3651, "Handle System Namespace and Service Definition", November 2003

Source of RFC: INDEPENDENT

Errata ID: 3966

Status: Verified
Type: Editorial

Reported By: Dale Worley
Date Reported: 2014-04-16
Verifier Name: Nevil Brownlee
Date Verified: 2014-12-22

Section 3 says:

       <NamingAuthority> = *(<NamingAuthority>  ".") <NAsegment>

It should say:

       <NamingAuthority> = *(<NAsegment>  ".") <NAsegment>

Notes:

Strictly speaking, this is an editorial change because the corrected
BNF generates the same strings as the original BNF. But the corrected
BNF is far easier for the reader to understand; it matches how people
think about the syntax.

RFC 3659, "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

RFC 3665, "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.

RFC 3666, "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

RFC 3677, "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

RFC 3678, "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.

RFC 3680, "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.

RFC 3696, "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.

RFC 3700, "Internet Official Protocol Standards", July 2004

Note: This RFC has been obsoleted by RFC 5000

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

RFC 3712, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", February 2004

Note: This RFC has been obsoleted by RFC 7612

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.

RFC 3715, "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.

RFC 3720, "Internet Small Computer Systems Interface (iSCSI)", April 2004

Note: This RFC has been obsoleted by RFC 7143

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

RFC 3728, "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.

RFC 3730, "Extensible Provisioning Protocol (EPP)", March 2004

Note: This RFC has been obsoleted by RFC 4930

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:

RFC 3733, "Extensible Provisioning Protocol (EPP) Contact Mapping", March 2004

Note: This RFC has been obsoleted by RFC 4933

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>

RFC 3736, "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.

RFC 3739, "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.

RFC 3741, "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




RFC 3742, "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,

RFC 3744, "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





RFC 3770, "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 RFC 4334

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

RFC 3777, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", June 2004

Note: This RFC has been obsoleted by RFC 7437

Source of RFC: nomcom (gen)

Errata ID: 4179

Status: Verified
Type: Technical

Reported By: Brian Carpenter
Date Reported: 2014-11-13
Verifier Name: Barry Leiba
Date Verified: 2014-11-13

Section 4 says:

   3.  The nominating committee comprises at least a Chair, 10 voting
       volunteers, 3 liaisons, and an advisor.

It should say:

   3.  The nominating committee comprises at least a Chair, 10 voting
       volunteers, two liaisons, and an advisor.

Notes:

The ISOC liaison is optional. Saying "at least ... two" is future-proof.

RFC 3779, "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.

RFC 3781, "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))


RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC 6582

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:


RFC 3783, "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.

RFC 3798, "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.

RFC 3811, "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.

RFC 3813, "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.

RFC 3822, "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

RFC 3829, "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:


RFC 3830, "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.

RFC 3834, "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:



RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004

Note: This RFC has been obsoleted by RFC 5652

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.

RFC 3856, "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.

RFC 3863, "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.

RFC 3866, "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.



RFC 3877, "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)

RFC 3886, "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".

RFC 3887, "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 ***

RFC 3920, "Extensible Messaging and Presence Protocol (XMPP): Core", October 2004

Note: This RFC has been obsoleted by RFC 6120

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.

RFC 3931, "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:



RFC 3933, "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.

RFC 3939, "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.



RFC 3944, "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.

RFC 3945, "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

RFC 3954, "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.

RFC 3958, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", January 2005

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

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.

RFC 3961, "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"

RFC 3964, "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

RFC 3965, "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

RFC 3966, "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

RFC 3971, "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".

RFC 3973, "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.

RFC 3977, "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.

RFC 3978, "IETF Rights in Contributions", March 2005

Note: This RFC has been obsoleted by RFC 5378

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.


RFC 3981, "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: Stéphane 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].

RFC 3982, "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.

RFC 3986, "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.

RFC 3987, "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

RFC 3998, "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”.

RFC 4004, "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.

RFC 4010, "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.

RFC 4013, "SASLprep: Stringprep Profile for User Names and Passwords", February 2005

Note: This RFC has been obsoleted by RFC 7613

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.

RFC 4028, "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>

RFC 4029, "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.



RFC 4033, "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.

RFC 4034, "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: 4552

Status: Verified
Type: Technical

Reported By: Ben Laurie
Date Reported: 2015-12-04
Verifier Name: Brian Haberman
Date Verified: 2015-12-14

Section Appendix B says:

These groups are then added together, ignoring any carry bits.

It should say:

These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes:

Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part of the corrected text is from 2681.

Its worth pointing this out because a naive analysis says in fact the keytag is exactly the same as reduction modulo 65535, and this has already wasted a fair amount of time.

It is also worth pointing out, perhaps, that this is a poor choice of algorithm for this particular application as it interacts badly with the properties of keys.

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

RFC 4035, "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

RFC 4043, "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:


RFC 4048, "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

RFC 4051, "Additional XML Security Uniform Resource Identifiers (URIs)", April 2005

Note: This RFC has been obsoleted by RFC 6931

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

RFC 4052, "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.


RFC 4055, "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".

RFC 4057, "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.

RFC 4060, "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. 

RFC 4090, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005

Source of RFC: mpls (rtg)

Errata ID: 4203

Status: Verified
Type: Technical

Reported By: Yakov Rekhter
Date Reported: 2014-12-17
Verifier Name: Alia Atlas
Date Verified: 2015-01-06

Section 6 says:

Whenever the PLR has a backup path available, the PLR MUST set
the "local protection available" flag.

It should say:

Whenever the PLR has a backup path available, the PLR MUST set
the "local protection available" flag.  For example, if the PLR 
has determined to use a bypass tunnel and set up the necessary 
local forwarding state to be able to use it as a backup path, 
then that PLR has a backup path available.

Notes:

In the case of facility-based FRR the PLR must set the "local protection available" flag if it has the bypass tunnel available and the local forwarding state is set up.

RFC 4106, "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.

RFC 4108, "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", August 2005

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

Errata ID: 4093

Status: Verified
Type: Technical

Reported By: George Taylor
Date Reported: 2014-09-03
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section Appendix A says:


It should say:

id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) aa(2) 41 }
and 
FirmwarePackageMessageDigest ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        msgDigest OCTET STRING }
from section 2.2.10 do not appear in the ASN.1 module.

Notes:



Yes the two items are missing from the ASN.1 module at the end of the document.

RFC 4111, "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.

RFC 4114, "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.

RFC 4117, "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------------------->|

RFC 4119, "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.

RFC 4122, "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.)

RFC 4130, "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".

RFC 4133, "Entity MIB (Version 3)", August 2005

Note: This RFC has been obsoleted by RFC 6933

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.

RFC 4134, "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.

RFC 4141, "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

Errata ID: 4762

Status: Verified
Type: Editorial

Reported By: Andris Reinman
Date Reported: 2016-08-04
Verifier Name: Alexey Melnikov
Date Verified: 2016-08-11

Section 9.1 says:

S: 250-<June@some.example.com> recipient ok

It should say:

S: 250 <June@some.example.com> recipient ok

Notes:

The example in section 9.1 incorrectly lists a hyphen between the status code (250) and message text (<June...) as if there would be more data coming from the server regarding the "RCPT TO:<June..." command but there is not.

RFC 4143, "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.)

RFC 4147, "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.

RFC 4151, "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.

RFC 4171, "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

RFC 4175, "RTP Payload Format for Uncompressed Video", September 2005

Source of RFC: avt (rai)

Errata ID: 4581

Status: Verified
Type: Editorial

Reported By: John Fletcher
Date Reported: 2016-01-06
Verifier Name: Ben Campbell
Date Verified: 2016-01-06

Section 6.1 says:

Security considerations: See section 9 of RFC 4175.

It should say:

Security considerations: See section 8 of RFC 4175.

Notes:

Wrong section number for Security considerations

RFC 4181, "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

RFC 4182, "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.

RFC 4186, "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

RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006

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

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