RFC ERRATA

Published RFCs never change. Although every published RFC has been submitted to careful proof reading by the RFC Editor and the author(s), errors do sometimes go undetected. As a service to the readers of RFCs, this page contains a list of technical and editorial errors that have been reported to the RFC Editor and verified by the authors or the IESG.

To report typos in published RFCs, please send email to rfc-editor@rfc-editor.org. To report suspected errors that are more technical in nature, please verify the errors with the authors and/or appropriate area directors of the IESG before sending them to the RFC Editor for posting.

Suggested changes that appear to modify the sense of an RFC will not be posted. If there is credible evidence that an error claim is incorrect or misleading, the posting will be removed from this list.

In general, we cannot guarantee the correctness of these errata; the reader must make her own judgment.

RFC 3424, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", November 2002
Reported by: Leslie Daigle; leslie@thinkingcat.com
Date: Tue, 19 Nov 2002 20:53:55 -0500

The center page header: IAB Considerations for UNSAP Across NAT Should be: IAB Considerations for UNSAF Across NAT
RFC 3385, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", September 2002
Reported by: Vicente Cavanna; vince_cavanna@agilent.com
Date: Mon, 18 Nov 2002 11:48:53 -0700
In Section 8.1, the Verilog [ieee1364] code should read:
/////////////////////////////////////////////////////////////////////// // 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 3377, "Lightweight Directory Access Protocol (v3): Technical Specification", September 2002
Reported by: Jeff Hodges; Jeff.Hodges@sun.com
Date: Thu, 26 Sep 2002 10:28:49 -0700
This document updates RFCs 2251-2256, 2829 and 2830.
RFC 3372, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", September 2002
Reported by: Feng Zhang; y01317@njupt.edu.cn
Date: Sun, 22 Sep 2002 17:42:53 +0800
References to Figures 3, 5, and 7 should refer to Figures 2, 3, and 4, respectively.
RFC 3300, "Internet Official Protocol Standards", November 2002
Reported by: Siegfried Schmitt; lsvadm@rz.uni-karlsruhe.de
Date: Fri, 15 Nov 2002 22:10:26 +0100
In Section 3.1 and Section 3.2:
-------- Internet Official Protocol Standards 3003 1* Should be: -------- Internet Official Protocol Standards 3300 1*
RFC 3281, "An Internet Attribute Certificate Profile for Authorization", April 2002
Reported by: Russ Housley
Date: Tue, 30 Jul 2002 12:07:41 -0400
In Section 7.1:
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. Should be: 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 }
RFC 3275, "(Extensible Markup Language) XML-Signature Syntax and Processing", March 2002
Reported by: Joseph Reagle; reagle@w3.org
Date: Thu, 18 Apr 2002 11:24:40 -0400
A list of errata can be found at: http://www.w3.org/2001/10/xmldsig-errata
RFC 3272, "Overview and Principles of Internet Traffic Engineering", May 2002
Reported by: Jean-Michel Grimaldi; jihem@via.ecp.fr
Date: 19 Jun 2002 08:44:37 +0200
In Section 4.2.2:
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. Should be: 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 3271, "The Internet is for Everyone", April 2002
Reported by: Robert deMallac; rsauzier@sfsu.edu
Date: Wed, 31 Jul 2002 13:55:37 -0700
In Section 1:
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. Should be: 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 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
Reported by: Frederic Turgis; f-turgis@ti.com
Date: Mon, 29 Jul 2002 19:22:11 +0200
In Section 5.3
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. Should be: 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 3265, "Session Initiation Protocol (SIP)-Specific Event Notification", June 2002
Reported by: Alfred Hoenes; ah@tr-sys.de
Date: Tue, 23 Jul 2002 0:18:15
In the Header:
Updates: 2543 Should be: Updates: 3261
RFC 3262, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", June 2002
Reported by: Steve Conner; steve@networksorcery.com
Date: Thu, 4 Jul 2002 11:14:41 -0700
This document obsoletes RFC 2543.
RFC 3219, "Telephony Routing over IP (TRIP)", January 2002
Reported by: Jonathan Rosenberg; jdrosen@dynamicsoft.com
Date: Fri, 06 Sep 2002 12:27:08 -0400
In Section 10.3.1.1
- 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. Should be: - 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 3208, "PGM Reliable Transport Protocol Specification", December 2001
Reported by: Lorenzo Vicisano; lorenzo@cisco.com
Date: Tue, 17 Sep 2002 16:14:52 -0700
In Section 8:
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. Should be: 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 3207, "SMTP Service Extension for Secure SMTP over Transport Layer Security", February 2002
Reported by: Simon Josefsson; simon@josefsson.org
Date: Wed, 13 Feb 2002 11:00:46 +0100
The document is missing a reference:
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S., and Freed, N., "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
RFC 3204, "MIME media types for ISUP and QSIG Objects", December 2001
Reported by: Francois Audet
Date: Thu, 13 Dec 2001 09:06:34 -0800
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 Should be: 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
BCP 53, RFC 3180, "GLOP Addressing in 233/8", September 2001
Reported by: Steve Mattson; hobbes@engin.umich.edu
Date: Mon, 22 Oct 2001 12:48:25 -0400
Sections 1 and 3:
The IANA has allocated 223/8 as per RFC 2770 [RFC2770]. Should be: The IANA has allocated 233/8 as per RFC 2770 [RFC2770].

RFC 3165, "Definitions of Managed Objects for the Delegation of Management Scripts", August 2001
Reported by: Juergen Schoenwaelder; schoenw@ibr.cs.tu-bs.de
Date: Mon, 3 Sep 2001 18:07:04 +0200
In Section 6:
The definition of smLaunchRunIndexNext on page 33 uses the following SYNTAX clause: SYNTAX Integer32 (1..2147483647) This range is inconsistent with the text in the DESCRIPTION clause, which in some cases requires to return 0 as a special value. Hence, the SYNTAX clause should be: SYNTAX Integer32 (0..2147483647)
RFC 3119, "A More Loss-Tolerant RTP Payload Format for MP3 Audio", June 2001
Reported by: Ross Finlayson; finlayson@live.com
Date: Sat, 03 Nov 2001 08:03:54 -0800
In Section 8:
the encoding name SHALL be "mp3" (the same as the MIME subtype). Should be: the encoding name SHALL be "mpa-robust" (the same as the MIME subtype). 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 3108, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", May 2001
Reported by: Rajesh Kumar; rkumar@cisco.com
Date: Wed, 22 May 2002 11:39:26 -0700
In Section 5.6:
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. Should be: 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. 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) Virtual Circui t Decimal or hex equivalent Identifier of 16 bits Should be: Virtual Circuit Decimal or hex equivalent Identifier of 16 bits
RFC 3083, "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", March 2001
Reported by: Rich Woundy; rwoundy@cisco.com
Date: Tue, 10 Apr 2001 10:52:21 -0400
In Section 4:
docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { authWait(2), authorized(3), reauthWait(4), authRejectWait(5) Should be: docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1) authWait(2), authorized(3), reauthWait(4), authRejectWait(5)
BCP 47, RFC 3066, "Tags for the Identification of Languages", January 2001
Reported by: Dr. Carsten Bormann; cabo@tzi.org
Date: Fri, 2 Feb 2001 00:24:46 +0100
In Section 2.2:
URL: http://www.loc.gov/standards/iso639 Should be: http://www.loc.gov/standards/iso639-2/

Reported by: David Hopwood; david.hopwood@zetnet.co.uk
Date: Tue, 30 Jul 2002 20:22:19 +0000
In Section 2.3:
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. Should be: 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.
RFC 3062, "LDAP Password Modify Extended Operation", February 2001
Reported by: Kurt Zeilenga; Kurt@OpenLDAP.org
Date: Wed, 07 Mar 2001 10:33:53 -0800
In Section 1:
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. Should be: 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 3047, "RTP Payload Format for ITU-T Recommendation G.722.1", January 2001
Reported by: Colin Perkins; csp@ISI.EDU
Date: Tue, 04 Jun 2002 12:43:26 -0400
In Section 4:
Encoding considerations: This type is only defined for transfer via RTP as specified in a Work in Progress. Should be: Encoding considerations: This type is only defined for transfer via RTP as specified in RFC 3047.
RFC 3037, "LDP Applicability", January 2001
Reported by: Elena Taguer; etaguer@nortelnetworks.com
Date: Mon, 29 Jan 2001 17:14:29 -0500
In Section 1:
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. Should be: 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 3036, "LDP Specification", January 2001
Reported by: Elena Taguer; etaguer@nortelnetworks.com
Date: Thu, 01 Feb 2001 09:53:13 -0500
In Section 3.5.1.2.2:
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. 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 3015, "Megaco Protocol Version 1.0", November 2000
Reported by: Brian Rosen; Brian.Rosen@marconi.com
Date: Tue, 4 Sep 2001 09:45:08 -0400
In Section Annex B
V4hex = 1*3(DIGIT) ; "0".."225" Should be: V4hex = 1*3(DIGIT) ; "0".."255"
RFC 3003, "The audio/mpeg Media Type", November 2000
Reported by: Colin Perkins; csp@ISI.EDU
Date: Wed, 22 Nov 2000 21:23:30 -0500

* NOTE: The audio/MPS mime type is in use in addition to the audio/mpeg. Should be: * NOTE: The audio/MPA mime type is in use in addition to the audio/mpeg.
RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000
Reported by: Robert Moskowitz; rgm@icsa.net
Date: Wed, 13 Dec 2000 22:02:34 -0800

* 5.6 Attributes defined in S/MIMIE .............................. 18 Should be: * 5.6 Attributes defined in S/MIME .............................. 18
RFC 2939, "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", September 2000
Reported by: Tyler Tidman; tyler.tidman@alcatel.com
Date: Tue, 04 Sep 2001 12:24:30 -0400
In Section 1:
DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Should be: DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 53).
RFC 2927, "MIME Directory Profile for LDAP Schema", September 2000
Reported by: Bruce Lilly; blilly@erols.com
Date: Fri, 04 Jan 2002 17:51:49 -0500
In Section 3:
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 ) ) Should be: 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 2925, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", September 2000
Reported by: Randy Presuhn; rpresuhn@dorothy.bmc.com
Date: Tue, 26 Mar 2002 15:16:54 -0800

In Section 4.1: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(4)." Should be: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(2)."
RFC 2916, "E.164 number and DNS", September 2000
Reported by: Dr. Carsten Bormann; cabo@tzi.org
Date: Wed, 27 Sep 2000 10:20:30 +0200

* IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=01!" . Should be: * IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=0\1!" .
RFC 2911, "Internet Printing Protocol/1.1: Model and Semantics", September 2000
Reported by: Tom Hastings; hastings@cp10.es.xerox.com
Date: Wednesday, July 17, 2002 17:52
In Section 13, Appendix B:
"redirection" - 0x0200 to 0x02FF Should be: "redirection" - 0x0300 to 0x03FF
In Section 13, Appendix B:
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. Should be: 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.
RFC 2873, "TCP Processing of the IPv4 Precedence Field", June 2000,
Reported by: Kurt D. Zeilenga; Kurt@OpenLDAP.org
Date: Tue, 06 Nov 2001 12:59:14 -0800
In the References Section:
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2587, June 1999. Should be: [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
RFC 2865, "", June 2000,
Reported by: Aaron Webb; awebb@solutioninc.com
Date: Thu, 12 Sep 2002 09:18:22 -0300
In Section 5.18:
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. Should be: 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.
RFC 2786, "Diffie-Helman USM Key Management Information Base and Textual Convention", March 2000
Reported by: David Harrington; dbh@enterasys.com
Date: Fri, 17 Aug 2001 16:59:49 -0400
The title was mis-spelled:
Diffie-Helman USM Key Management Information Base and Textual Convention Should be: Diffie-Hellman USM Key Management Information Base and Textual Convention
RFC 2764, "A Framework for IP Based Virtual Private Networks", February 2000
Reported by: Elena Taguer; etaguer@nortelnetworks.com
Date: Thu, 01 Feb 2001 09:53:13 -0500
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 2763, "Dynamic Hostname Exchange Mechanism for IS-IS", February 2000
Reported by: Brian Vine, Brian.Vine@marconi.com
Date: Fri, 28 Jun 2002 07:39:17 -0400
In Section 4:
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. Should be: 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 2759, "Microsoft PPP CHAP Extensions, Version 2", January 2000
Reported by: Andrew Roughan; andrew.roughan@writeme.com
Date: Mon, 26 Aug 2002 23:10:48 -0500
In Section 9.3:
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 Should be: 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
RFC2740, "OSPF for IPv6", December 1999
Reported by: Wu Qian; wuqian@csnet1.cs.tsinghua.edu.cn
Date: Wed, 22 Aug 2001 09:32:22 +0800
In section 3.1.2
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. Should be: 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.

Reported by: John Moy; John.Moy@sycamorenet.com
Date: Thu, 17 Jan 2002 14:00:41 -0500
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| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ Should be: 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
In Section A.3.2 The Hello packet:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In Section A.3.3 The Database Description packet:
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 -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In Section A.3.4 The Link State Request packet:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | In Section A.3.5 The Link State Update packet:
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 | +- +-+ | ... | Should be: 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 | +- +-+ | ... |
In Section A.3.6 The Link State Acknowledgment packet:
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 -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In Section A.4.2 The LSA header:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Section A.4.3 Router-LSAs:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In Section A.4.4 Network-LSAs:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In Section A.4.5 Inter-Area-Prefix-LSAs:
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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Section A.4.6 Inter-Area-Router-LSAs:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Section A.4.7 AS-external-LSAs:
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Section A.4.8 Link-LSAs:
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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In Section A.4.9 Intra-Area-Prefix-LSAs:
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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 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 2737, "Entity MIB (Version 2)", December 1999
Reported by: RFC Editor
Date: Date: Fri, 21 Sep 2001 17:34:38 GMT
In the header:
Network Working Group K. McCloghrie Request for Comments: 2737 Cisco Systems, Inc. Obsoletes: 2037 A. Bierman Cisco Systems, Inc. December 1999 Should be: 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 2731, "Encoding Dublin Core Metadata in HTML", December 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 11:
[HARVEST] Harvest Web Indexing. http://www.tardis.ed.ac.uk/harvest/ The URL has been updated to: [HARVEST] Harvest: A distributed Search System. http://harvest.sourceforge.net/

RFC 2676, "QoS Routing Mechanisms and OSPF Extensions", August 1999
Reported by: Jussi Savolainen; jussi@tct.hut.fi
Date: Tue, 9 Jul 2002 18:18:38 +0300
In Section 3.2.1:
0 8 16 | | | ----------------- |EXP| MANT | ----------------- Should be: 0 8 15 | | | ----------------- |EXP| MANT | -----------------

RFC 2656, "Registration Procedures for SOIF Template Types", August 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 5:
[2] The Harvest Information Discovery and Access System: <URL:http://harvest.transarc.com/> The URL has been updated to: [2] Harvest: A distributed Search System: <URL:http://harvest.sourceforge.net/>

RFC 2655, "CIP Index Object Format for SOIF Objects", August 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 8:
[2] The Harvest Information Discovery and Access System: <URL:http://harvest.transarc.com/> The URL has been updated to: [2] Harvest: A distributed Search System: <URL:http://harvest.sourceforge.net/>

RFC 2630, "Cryptographic Message Syntax", June 1999
Reported by: Joseph Baran; joebaran@extol.com
Date: Tue, 26 Dec 2000 11:04:32 -0500
In Section 12.2.2:
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. Should be: 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.

In the References section:
NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2347, October 1998. Should be: NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
RFC 2617, "HTTP Authentication: Basic and Digest Access", June 1999
All known errata for these two HTTP RFCs will be found at: http://purl.org/NET/http-errata.
Reported by: Justin Erenkrantz; justin@erenkrantz.com
Date: Sat, 23 Dec 2000 00:55:12 -0800
In Section 4.4:
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. Should be: 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.
In Section 1.3:
Each of these representations is termed a `varriant'. Should be: Each of these representations is termed a `variant'.

Reported by: Greg Robson; Greg.Robson@BHPBilliton.com
Date: Tue, 9 Oct 2001 14:42:20 +1000
In Section 3.6:
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). 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!).

RFC 2579, "Textual Conventions for SMIv2", April 1999
Reported by: Juergen Schoenwaelder; schoenw@ibr.cs.tu-bs.de
Date: Tue, 31 Jul 2001 16:36:04 +0200
In Section 2:
RFC 2579 lists an invalid range for the year in the DateAndTime TC: field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 Should be: field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65535

Reported by: Juergen Schoenwaelder; schoenw@ibr.cs.tu-bs.de
Date: Sat, 8 Dec 2001 00:55:51 +0100
In Section 7.1.1
"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].) Should be: "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].)

RFC 2557, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", March 1999
Reported by: Les Kramer; lkramer@towertechnology.com.au
Date: Mon, 8 Jan 2001 10:53:14 +1100
In the reference:
[REL] Levinson, E., "The MIME Multipart/Related Content- Type", RFC 2389, August 1998.

The RFC number cited is incorrect; it should be RFC 2387.
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 21 Jan 2002 23:05:03 -0500

In Section 4.2: resolution of relative URIs). However, URI-s in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be Should be: resolution of relative URIs). However, URIs in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be In Section 9.2: 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> Should be: 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> In Section 9.3: Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif ; Note - Absolute Content-Location does not require a ; base Should be: Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif Comments: Note - Absolute Content-Location does not require a base In Section 9.3: Content-Location: images/ietflogo2.gif ; Note - Relative Content-Location is resolved by base ; specified in the Multipart/Related Content-Location heading Should be: Content-Location: images/ietflogo2.gif Comments: Note - Relative Content-Location is resolved by base specified in the Multipart/Related Content-Location heading In Section 9.6: Content-ID: <foo3@foo1@bar.net> Should be: Content-ID: <foo3.foo1@bar.net> In Section 9.6: Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 Should be: Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 In Section 9.6: Content-ID: <foo4@foo1@bar.net> Should be: Content-ID: <foo4.foo1@bar.net> In Section 9.6: 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> Should be: 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>

RFC 2544, "Benchmarking Methodology for Network Interconnect Devices", March 1999
Reported by: Scott Campbell; scott.campbell@Sun.COM
Date: Thu, 20 Sep 2001 19:30:12 -0600
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. Should be: The network addresses 198.18.0.0 through 198.19.255.255 have been assigned to the BMWG by the IANA for this purpose.

Reported by: Lu Jian Xiong; lujianxiong@hotmail.com
Date: Wed, 7 Aug 2002 21:54:54 +0800
In Section 6:
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. Should be: 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.

RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", March 1999
Reported by: Sid Sidner; sidners@aciworldwide.com
Date: Mon, 5 Aug 2002 15:04:20 -0500
In the NOTES Section:
1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. Should be: 1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.org for ordering details.

RFC 2518, "HTTP Extensions for Distributed Authoring -- WEBDAV", February 1999
Reported by: Julian Reschke; julian.reschke@greenbytes.de
Date: Sat, 11 May 2002 22:47:31 +0200
Errata for this document can be found at: http://www.webdav.org/wg/rfcdev/issues.htm

RFC 2486, "The Network Access Identifier", June 2000
Reported by: Dale Worley; worley@agranat.com
Date: Thu, 31 Aug 2000 19:51:19 -0400
Section 3, page 3 contains:

x = %x00-7F ; all 127 ASCII characters, no exception

The comment should read "all 128 ASCII characters", as it is clear that that is what the author meant. It might also help the reader to add a comment after the definition of "special":
special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" / %x22 / Ctl ; %x22 is '"'

RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999
Reported by: Yaron Sella; ysella@ndsisrael.com
Date: Tue, 13 Feb 2001 17:41:17 +0200
In Appendix D.3:
0587 03 81 81 47: . BIT STRING Should be: 0587 03 81 81 129: . BIT STRING

RFC 2421, "Voice Profile for Internet Mail - version 2", September 1998
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 07 Jan 2002 18:02:04 -0500
In Appendix B:
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary_ Should be: SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary--

RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998
Reported by: Carl Douglas; aaron.douglas@fuse.net
Date: Thu, 26 Apr 2001 20:43:47 -0400
In Section 3.4:
Section 3.4, "Query Component", of RFC2396 (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.

Reported by: Marc Warne; marc@indivisibilities.com
Date: Wed, 18 Sep 2002 13:14:25 +0100
In Section 1.2:
A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. Should be: A URN differs from a URL in that its primary purpose is persistent labeling of a resource with an identifier.

RFC 2392, "IP Payload Compression Protocol (IPComp)", December 1998
Reported by: Bruce Lilly; blilly@erols.com
Date: Fri, 08 Mar 2002 00:42:08 -0500
In Section 2:
example, "cid:foo4%25foo1@bar.net" corresponds to Content-ID: <foo4%25foo1@bar.net> should be: example, "cid:foo4%25foo1@bar.net" corresponds to Content-ID: <foo4%foo1@bar.net>

RFC 2373, "IP Version 6 Addressing Architecture", July 1998
Reported by: Tim Hutchinson; Tim.Hutchinson@gbr.xerox.com
Date: Tue Oct 31 07:21:20 2000
In the reference:
[TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1993, April 1996.

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

RFC 2362, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", June 1998
Throughout the document:
[Figures are present only in the postscript version]

There is no postscript version available.

RFC 2286,"Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", February 1998
Reported by: Kevin Springle; kevins@kadak.com
Date: Tue, 17 Sep 2002 16:48:00 -0800
In the Appendix:
/* if key is longer than 64 bytes reset it to key=SHA1(key) */ Should be: /* if key is longer than 64 bytes reset it to key=RMD160(key) */
In the Appendix:
/* The HMAC_SHA1 transform looks like: Should be: /* The HMAC_RMD160 transform looks like:

RFC 2268,"A Description of the RC2(r) Encryption Algorithm", March 1998
Reported by: Simon Josefsson; sjosefsson@rsasecurity.com
Date: Wed, 17 Oct 2001 13:47:05 +0200
In Section 6:
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. Should be: 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 2244, "ACAP -- Application Configuration Access Protocol", November 1997
Reported by: Chris Newman; cnewman@iplanet.com
Date: Tue, 23 Jan 2001 12:11:39 -0800

1. Formal syntax typo for ACL: acl = "(" [acl-identrights *(SP acl-identrights)] ")" *(SPACE acl-identrights)] ")" Should be: acl = "(" [acl-identrights *(SP acl-identrights)] ")" 2. Formal syntax for UPDATECONTEXT was missing. Syntax should be: command-updatectx = "UPDATECONTEXT" 1*(SP context) 3. Fix DELETEDSINCE example to include quotes around timestamps 4. "count" metadata-type is not documented in prose. Will be removed in next revision. 5. 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: command-lang = "LANG" *(SP lang-tag) to: command-lang = "LANG" 1*(SP lang-tag) 6. One SEARCH example is missing comparator in EQUAL statement: 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 Should be: 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 7. Need to use entry-path on notifications when DEPTH > 1 is specified. 8. Note explicitly that client commands must be transmitted in full before starting a new command. This includes literals and the AUTHENTICATE exchange. 9. Bug/clarification in formal syntax (where it doesn't match examples): return-metadata = nil / string / value-list / acl Should be: return-metadata = nil / string / number / value-list / acl ;; number is only used for "size" metadata items ;; acl is only used for "acl" metadata items 10. Note that "revocation of rights" is also know as "negative rights". 11. Need to define the term "non-special" in section 2.6.1 as equivalent to the syntax for "ATOM-CHAR". 12. Section 2.6.2, permit number to include 0 to match formal syntax. 13. "Universal Coordinated Time" should be "Coordinated Universal Time".

RFC 2241, "DHCP Options for Novell Directory Services", November 1997
Reported by: Bruce Lilly; blilly@erols.com
Date: Thu, 31 Jan 2002 03:55:01 -0500

In Section 15: Content-type: message/disposition-notification Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) Original-Recipient: rfc822;22722@vm.company.com Should be: Content-type: message/disposition-notification Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) Original-Recipient: rfc822;22722@vm.company.com

RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997
Reported by: Tanaka Akira; akr@m17n.org
Date: 19 Nov 2001 18:54:10 +0900
In Section 3.9:
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 Both English and ABNF definition of comment doesn't permit comment continues to next line.
In Section 4:
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 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

RFC 2231, "MIME Parameter Value and Encoded Word Extension: Character Sets, Languages, and Continuations", June 1996
Reported by: Shuhei KOBAYASHI; shuhei@aqua.ocn.ne.jp
Date: 17 Apr 2001 20:29:25 +0900
In Section 4.1:
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!" Should be: 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!" In Section 7: extended-parameter := (extended-initial-name "=" extended-value) / (extended-other-names "=" extended-other-values) Should be: extended-parameter := (extended-initial-name "=" extended-initial-value) / (extended-other-names "=" extended-other-values)

Reported by: Jeffrey Stedfast; fejj@ximian.com
Date: Sat, 24 Nov 2001 16:10:12 -0800
In Section 7:
encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" Should be: encoded-word := "=?" charset ["*" language] "?" encoding "?" encoded-text "?="

RFC 2202, "Test Cases for HMAC-MD5 and HMAC-SHA-1", September 1997
Reported by: Kevin Springle; kevins@kadak.com
Date: Tue, 17 Sep 2002 16:48:00 -0800
In Section 3:
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 Should be: 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 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997
Reported by: Bruce Lilly blilly@erols.com
Date: Sat, 05 Jan 2002 13:30:28 -0500
In Section 2:
NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) Should be: NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)

RFC 2132, "DHCP Options and BOOTP Vendor Extensions", March 1997
Reported by: George V. Neville-Neil; gnn@neville-neil.com
Date: Wed, 12 Dec 2001 23:33:47 -0800
In section 9.6:
Code Len Type +-----+-----+-----+ | 53 | 1 | 1-9 | +-----+-----+-----+ Should be: Code Len Type +-----+-----+-----+ | 53 | 1 | 1-8 | +-----+-----+-----+

RFC 2126, "ISO Transport Service on top of TCP (ITOT)", March 1997
RFC 2127, "ISDN Management Information Base using SMIv2", March 1997
Reported by: Larry Masinter
Date: Thu, 21 Mar 2002 17:20:22 -0800
All errata for these documents can be found at: http://purl.org/net/http-errata

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997
Reported by: Kurt Zeilenga; Kurt@OpenLDAP.org
Date: Wed, 31 Jan 2001 17:00:38 -0800
In section 6:
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. Should be: 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.

RFC 2060, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", December 1996
Reported by: Mathieu Fenniak; laotzu@pobox.com
Date: Tue, 28 May 2002 12:07:04 -0600
In Section 6.4.8:
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 Should be: 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
A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Reported by: Jose M. Cainzos; jmcainzos@airtel.net
Date: Sat, 10 Nov 2001 22:50:12 +0100
In Section 5:
(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'. Should be: (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'.

RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Reported by: Jon Steinhart; jon@fourwinds.com
Date: Thu, 17 Jan 2002 10:26:35 -0800
In Section 2:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" Should be: especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" <"> / "/" / "[" / "]" / "?" / "." / "="

RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996
Reported by: Bruce Lilly; blilly@erols.com
Date: Sat, 22 Dec 2001 12:47:44 -0500
In Section 5.2.3.7:
Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Should be: Content-Type: message/external-body; access-type=mail-server; server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
In Section 5.1.5:
"undesireble" should be "undesirable" "seperate" should be "separate" In Section 5.2.2.2: Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail Message-ID: Should be: Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Message-ID: Subject: Audio mail

RFC 2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", June 1996
Reported by: Joe Hutcheson; hutch@gte.net
Date: Fri, 16 Mar 2001 16:56:46 -0800
In Section 3:
Note that when calculating the correspondence, 2000 is not a leap year. Please disregard above statement regarding Leap Year, as the year 2000 was indeed a Leap Year.

Reported by: David L. Mills; mills@udel.edu
Date: Fri, 04 May 2001 20:50:27 +0100
In Section 5:
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2. Should be: d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.

RFC 2026, "The Internet Standards Process -- Revision 3", October 1996
Reported by: Scott Bradner; sob@harvard.edu
Date: Thu, 1 Aug 2002 10:50:52 -0400
In Section 10.4:
"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..." The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).

RFC 1959, "An LDAP URL Format", June 1996
Reported by: Kurt D. Zeilenga; Kurt@OpenLDAP.org
Date: Wed, 07 Feb 2001 20:26:44 -0800
In Section 2:
::= a string as defined in RFC 1485 Should be: ::= a string as defined in RFC 1779

RFC 1915, "Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol", February 1996
In the Title:
Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol Should be: Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol

RFC 1894"An Extensible Message Format for Delivery Status Notifications", January 1996
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 25 Feb 2002 12:44:47 -0500

In Section 9.4: 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 Should be: 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 1867"Form-based File Upload in HTML", November 1995
Reported by: Dirk Nimmich; nimmich@muenster.de
Date: Sat, 9 Mar 2002 15:32:38 +0100

Every occurance of the string: , boundary= Should be replaced by: ; boundary=

RFC 1662"PPP in HDLC-like Framing", July 1994
Reported by: Charles Cranford; ctc@cablespeed.com
Date: Thu, 7 Mar 2002 22:42:43 -0500

In the References Section: [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 50, RFC 1661, Daydreamer, July 1994. Should be: [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

RFC 1534"Interoperation Between DHCP and BOOTP", October 1993
Reported by: Tyler Tidman; tyler.tidman@alcatel.com
Date: Wed, 05 Sep 2001 16:15:43 -0400
In Section 2:
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. Should be: 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 1531, "Dynamic Host Configuration Protocol", October 1993
Reported by: Jim Withnall; withnall@bigpond.net.au
Date: Thu, 1 Nov 2001 15:04:52 +1000
In Section 4.4.4:
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. Should be: 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 1517, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", September 1993
Reported by: Mr. Sharky; mrsharky@mindspring.com
Date: Sat, 30 Mar 2002 18:43:53 -0700

In Section 1: 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. Should be: 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 1321, "The MD5 Message-Digest Algorithm", April 1992
Reported by: Michael Amling; mamling@futurenext.com
Date: Wed, 12 Apr 2000 20:05:27 -0400
In Section 3.4:
the each bit of F(X,Y,Z) will be independent Should be: then each bit of F(X,Y,Z) will be independent

Reported by: Matt Borland; matt@b-swing.com
Date: Fri, 19 Jan 2001 15:04:59 -0600
In Section A.4:
#define MD MD5 Should be: #define MD 5

Reported by: Gregory Smith; smithgrege@meditech.com
Date: Fri, 14 Jun 2002 11:07:24 -0400
In Section 3.4:
/* 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. */ should be /* 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. */
In Section 3.4:
/* Round 4. */ /* Let [abcd k s t] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */ should be /* Round 4. */ /* Let [abcd k s i] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */

RFC 1319, "The MD2 Message-Digest Algorithm", April 1992
Reported by: Jem Berkes; jb2002@pc9.org
Date: Wed, 30 Jan 2002 20:29:46 -0600
In Section 3.1:
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. Should be: 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.

Reported by: David Hopwood; david.hopwood@zetnet.co.uk
Date: Mon, 11 Feb 2002 21:23:10 +0000
In Section 3.2:
... /* 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. Should be: ... /* 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.

RFC 1180, "A TCP/IP Tutorial", January 1991
Reported by: Chao Yel; charles.ye@eng.sun.com
Date: Mon, 28 Feb 2000 16:15:21 -0800
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 1158, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", May 1990
Reported by: Vincent Berger; vincent.berger@afp.com
Date: Wed, 27 Mar 2002 18:19:26 +0100

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

RFC 1036, "Standard for Interchange of USENET Messages", December 1987
Reported by: Florian Weimer; Florian.Weimer@RUS.Uni-Stuttgart.DE
Date: 17 May 2001 17:23:21 +0200
In Section 2.1.4:
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. Should be: 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.

RFC 0959, "FILE TRANSFER PROTOCOL (FTP)", October 1985
Reported by: Juan Li; juanli@cc.hut.fi
Date: Wed, 3 Jan 2001 16:11:05 +0200 (EET)
In Section 2.1:

The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1982. Should be: The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1972.

RFC 0894, "A Standard for the Transmission of IP Datagrams over Ethernet Networks", April 1984
Reported by: Gerald Park; Gerald.Park@hsc.com
Date: Wed, 28 Mar 2001 14:00:55 -0800
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. Should be: 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 2737, "Entity MIB (Version 2)", December 1999
Reported by: RFC Editor
Date: Date: Fri, 21 Sep 2001 17:34:38 GMT
In the header:
Network Working Group K. McCloghrie Request for Comments: 2737 Cisco Systems, Inc. Obsoletes: 2037 A. Bierman Cisco Systems, Inc. December 1999 Should be: 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 2731, "Encoding Dublin Core Metadata in HTML", December 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 11:
[HARVEST] Harvest Web Indexing. http://www.tardis.ed.ac.uk/harvest/ The URL has been updated to: [HARVEST] Harvest: A distributed Search System. http://harvest.sourceforge.net/
RFC 2676, "QoS Routing Mechanisms and OSPF Extensions", August 1999
Reported by: Jussi Savolainen; jussi@tct.hut.fi
Date: Tue, 9 Jul 2002 18:18:38 +0300
In Section 3.2.1:
0 8 16 | | | ----------------- |EXP| MANT | ----------------- Should be: 0 8 15 | | | ----------------- |EXP| MANT | -----------------
RFC 2656, "Registration Procedures for SOIF Template Types", August 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 5:
[2] The Harvest Information Discovery and Access System: <URL:http://harvest.transarc.com/> The URL has been updated to: [2] Harvest: A distributed Search System: <URL:http://harvest.sourceforge.net/>
RFC 2655, "CIP Index Object Format for SOIF Objects", August 1999
Reported by: Kang-Jin Lee; lee@arco.de
Date: Wed, 4 Sep 2002 23:20:36 +0200
In Section 8:
[2] The Harvest Information Discovery and Access System: <URL:http://harvest.transarc.com/> The URL has been updated to: [2] Harvest: A distributed Search System: <URL:http://harvest.sourceforge.net/>
RFC 2630, "Cryptographic Message Syntax", June 1999
Reported by: Joseph Baran; joebaran@extol.com
Date: Tue, 26 Dec 2000 11:04:32 -0500
In Section 12.2.2:
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. Should be: 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.

In the References section:
NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2347, October 1998. Should be: NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998.
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
RFC 2617, "HTTP Authentication: Basic and Digest Access", June 1999
All known errata for these two HTTP RFCs will be found at: http://purl.org/NET/http-errata.
Reported by: Justin Erenkrantz; justin@erenkrantz.com
Date: Sat, 23 Dec 2000 00:55:12 -0800
In Section 4.4:
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. Should be: 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.
In Section 1.3:
Each of these representations is termed a `varriant'. Should be: Each of these representations is termed a `variant'.

Reported by: Greg Robson; Greg.Robson@BHPBilliton.com
Date: Tue, 9 Oct 2001 14:42:20 +1000
In Section 3.6:
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). 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!).
RFC 2579, "Textual Conventions for SMIv2", April 1999
Reported by: Juergen Schoenwaelder; schoenw@ibr.cs.tu-bs.de
Date: Tue, 31 Jul 2001 16:36:04 +0200
In Section 2:
RFC 2579 lists an invalid range for the year in the DateAndTime TC: field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 Should be: field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65535

Reported by: Juergen Schoenwaelder; schoenw@ibr.cs.tu-bs.de
Date: Sat, 8 Dec 2001 00:55:51 +0100
In Section 7.1.1
"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].) Should be: "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].)
RFC 2557, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", March 1999
Reported by: Les Kramer; lkramer@towertechnology.com.au
Date: Mon, 8 Jan 2001 10:53:14 +1100
In the reference:
[REL] Levinson, E., "The MIME Multipart/Related Content- Type", RFC 2389, August 1998.

The RFC number cited is incorrect; it should be RFC 2387.
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 21 Jan 2002 23:05:03 -0500

In Section 4.2: resolution of relative URIs). However, URI-s in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be Should be: resolution of relative URIs). However, URIs in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be In Section 9.2: 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> Should be: 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> In Section 9.3: Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif ; Note - Absolute Content-Location does not require a ; base Should be: Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif Comments: Note - Absolute Content-Location does not require a base In Section 9.3: Content-Location: images/ietflogo2.gif ; Note - Relative Content-Location is resolved by base ; specified in the Multipart/Related Content-Location heading Should be: Content-Location: images/ietflogo2.gif Comments: Note - Relative Content-Location is resolved by base specified in the Multipart/Related Content-Location heading In Section 9.6: Content-ID: <foo3@foo1@bar.net> Should be: Content-ID: <foo3.foo1@bar.net> In Section 9.6: Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 Should be: Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 In Section 9.6: Content-ID: <foo4@foo1@bar.net> Should be: Content-ID: <foo4.foo1@bar.net> In Section 9.6: 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> Should be: 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>
RFC 2544, "Benchmarking Methodology for Network Interconnect Devices", March 1999
Reported by: Scott Campbell; scott.campbell@Sun.COM
Date: Thu, 20 Sep 2001 19:30:12 -0600
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. Should be: The network addresses 198.18.0.0 through 198.19.255.255 have been assigned to the BMWG by the IANA for this purpose.

Reported by: Lu Jian Xiong; lujianxiong@hotmail.com
Date: Wed, 7 Aug 2002 21:54:54 +0800
In Section 6:
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. Should be: 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.
RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", March 1999
Reported by: Sid Sidner; sidners@aciworldwide.com
Date: Mon, 5 Aug 2002 15:04:20 -0500
In the NOTES Section:
1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. Should be: 1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.org for ordering details.
RFC 2518, "HTTP Extensions for Distributed Authoring -- WEBDAV", February 1999
Reported by: Julian Reschke; julian.reschke@greenbytes.de
Date: Sat, 11 May 2002 22:47:31 +0200
Errata for this document can be found at: http://www.webdav.org/wg/rfcdev/issues.htm
RFC 2486, "The Network Access Identifier", June 2000
Reported by: Dale Worley; worley@agranat.com
Date: Thu, 31 Aug 2000 19:51:19 -0400
Section 3, page 3 contains:

x = %x00-7F ; all 127 ASCII characters, no exception

The comment should read "all 128 ASCII characters", as it is clear that that is what the author meant. It might also help the reader to add a comment after the definition of "special":
special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" / %x22 / Ctl ; %x22 is '"'
RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999
Reported by: Yaron Sella; ysella@ndsisrael.com
Date: Tue, 13 Feb 2001 17:41:17 +0200
In Appendix D.3:
0587 03 81 81 47: . BIT STRING Should be: 0587 03 81 81 129: . BIT STRING
RFC 2421, "Voice Profile for Internet Mail - version 2", September 1998
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 07 Jan 2002 18:02:04 -0500
In Appendix B:
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary_ Should be: SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321> REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary--
RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998
Reported by: Carl Douglas; aaron.douglas@fuse.net
Date: Thu, 26 Apr 2001 20:43:47 -0400
In Section 3.4:
Section 3.4, "Query Component", of RFC2396 (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.

Reported by: Marc Warne; marc@indivisibilities.com
Date: Wed, 18 Sep 2002 13:14:25 +0100
In Section 1.2:
A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. Should be: A URN differs from a URL in that its primary purpose is persistent labeling of a resource with an identifier.
RFC 2392, "IP Payload Compression Protocol (IPComp)", December 1998
Reported by: Bruce Lilly; blilly@erols.com
Date: Fri, 08 Mar 2002 00:42:08 -0500
In Section 2:
example, "cid:foo4%25foo1@bar.net" corresponds to Content-ID: <foo4%25foo1@bar.net> should be: example, "cid:foo4%25foo1@bar.net" corresponds to Content-ID: <foo4%foo1@bar.net>
RFC 2373, "IP Version 6 Addressing Architecture", July 1998
Reported by: Tim Hutchinson; Tim.Hutchinson@gbr.xerox.com
Date: Tue Oct 31 07:21:20 2000
In the reference:
[TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1993, April 1996.

the RFC number cited is incorrect; it should be RFC 1933.
RFC 2362, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", June 1998
Throughout the document:
[Figures are present only in the postscript version]

There is no postscript version available.
RFC 2286,"Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", February 1998
Reported by: Kevin Springle; kevins@kadak.com
Date: Tue, 17 Sep 2002 16:48:00 -0800
In the Appendix:
/* if key is longer than 64 bytes reset it to key=SHA1(key) */ Should be: /* if key is longer than 64 bytes reset it to key=RMD160(key) */
In the Appendix:
/* The HMAC_SHA1 transform looks like: Should be: /* The HMAC_RMD160 transform looks like:
RFC 2268,"A Description of the RC2(r) Encryption Algorithm", March 1998
Reported by: Simon Josefsson; sjosefsson@rsasecurity.com
Date: Wed, 17 Oct 2001 13:47:05 +0200
In Section 6:
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. Should be: 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 2244, "ACAP -- Application Configuration Access Protocol", November 1997
Reported by: Chris Newman; cnewman@iplanet.com
Date: Tue, 23 Jan 2001 12:11:39 -0800

1. Formal syntax typo for ACL: acl = "(" [acl-identrights *(SP acl-identrights)] ")" *(SPACE acl-identrights)] ")" Should be: acl = "(" [acl-identrights *(SP acl-identrights)] ")" 2. Formal syntax for UPDATECONTEXT was missing. Syntax should be: command-updatectx = "UPDATECONTEXT" 1*(SP context) 3. Fix DELETEDSINCE example to include quotes around timestamps 4. "count" metadata-type is not documented in prose. Will be removed in next revision. 5. 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: command-lang = "LANG" *(SP lang-tag) to: command-lang = "LANG" 1*(SP lang-tag) 6. One SEARCH example is missing comparator in EQUAL statement: 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 Should be: 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 7. Need to use entry-path on notifications when DEPTH > 1 is specified. 8. Note explicitly that client commands must be transmitted in full before starting a new command. This includes literals and the AUTHENTICATE exchange. 9. Bug/clarification in formal syntax (where it doesn't match examples): return-metadata = nil / string / value-list / acl Should be: return-metadata = nil / string / number / value-list / acl ;; number is only used for "size" metadata items ;; acl is only used for "acl" metadata items 10. Note that "revocation of rights" is also know as "negative rights". 11. Need to define the term "non-special" in section 2.6.1 as equivalent to the syntax for "ATOM-CHAR". 12. Section 2.6.2, permit number to include 0 to match formal syntax. 13. "Universal Coordinated Time" should be "Coordinated Universal Time".
RFC 2241, "DHCP Options for Novell Directory Services", November 1997
Reported by: Bruce Lilly; blilly@erols.com
Date: Thu, 31 Jan 2002 03:55:01 -0500

In Section 15: Content-type: message/disposition-notification Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) Original-Recipient: rfc822;22722@vm.company.com Should be: Content-type: message/disposition-notification Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) Original-Recipient: rfc822;22722@vm.company.com
RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", November 1997
Reported by: Tanaka Akira; akr@m17n.org
Date: 19 Nov 2001 18:54:10 +0900
In Section 3.9:
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 Both English and ABNF definition of comment doesn't permit comment continues to next line.
In Section 4:
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 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
RFC 2231, "MIME Parameter Value and Encoded Word Extension: Character Sets, Languages, and Continuations", June 1996
Reported by: Shuhei KOBAYASHI; shuhei@aqua.ocn.ne.jp
Date: 17 Apr 2001 20:29:25 +0900
In Section 4.1:
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!" Should be: 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!" In Section 7: extended-parameter := (extended-initial-name "=" extended-value) / (extended-other-names "=" extended-other-values) Should be: extended-parameter := (extended-initial-name "=" extended-initial-value) / (extended-other-names "=" extended-other-values)

Reported by: Jeffrey Stedfast; fejj@ximian.com
Date: Sat, 24 Nov 2001 16:10:12 -0800
In Section 7:
encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" Should be: encoded-word := "=?" charset ["*" language] "?" encoding "?" encoded-text "?="
RFC 2202, "Test Cases for HMAC-MD5 and HMAC-SHA-1", September 1997
Reported by: Kevin Springle; kevins@kadak.com
Date: Tue, 17 Sep 2002 16:48:00 -0800
In Section 3:
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 Should be: 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 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997
Reported by: Bruce Lilly blilly@erols.com
Date: Sat, 05 Jan 2002 13:30:28 -0500
In Section 2:
NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) Should be: NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
RFC 2132, "DHCP Options and BOOTP Vendor Extensions", March 1997
Reported by: George V. Neville-Neil; gnn@neville-neil.com
Date: Wed, 12 Dec 2001 23:33:47 -0800
In section 9.6:
Code Len Type +-----+-----+-----+ | 53 | 1 | 1-9 | +-----+-----+-----+ Should be: Code Len Type +-----+-----+-----+ | 53 | 1 | 1-8 | +-----+-----+-----+
RFC 2126, "ISO Transport Service on top of TCP (ITOT)", March 1997
RFC 2127, "ISDN Management Information Base using SMIv2", March 1997
Reported by: Larry Masinter
Date: Thu, 21 Mar 2002 17:20:22 -0800
All errata for these documents can be found at: http://purl.org/net/http-errata
RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997
Reported by: Kurt Zeilenga; Kurt@OpenLDAP.org
Date: Wed, 31 Jan 2001 17:00:38 -0800
In section 6:
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. Should be: 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.
RFC 2060, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", December 1996
Reported by: Mathieu Fenniak; laotzu@pobox.com
Date: Tue, 28 May 2002 12:07:04 -0600
In Section 6.4.8:
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 Should be: 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
A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Reported by: Jose M. Cainzos; jmcainzos@airtel.net
Date: Sat, 10 Nov 2001 22:50:12 +0100
In Section 5:
(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'. Should be: (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'.
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", November 1996
Reported by: Jon Steinhart; jon@fourwinds.com
Date: Thu, 17 Jan 2002 10:26:35 -0800
In Section 2:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" Should be: especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" <"> / "/" / "[" / "]" / "?" / "." / "="
RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996
Reported by: Bruce Lilly; blilly@erols.com
Date: Sat, 22 Dec 2001 12:47:44 -0500
In Section 5.2.3.7:
Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Should be: Content-Type: message/external-body; access-type=mail-server; server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
In Section 5.1.5:
"undesireble" should be "undesirable" "seperate" should be "separate" In Section 5.2.2.2: Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail Message-ID: Should be: Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Message-ID: Subject: Audio mail
RFC 2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", June 1996
Reported by: Joe Hutcheson; hutch@gte.net
Date: Fri, 16 Mar 2001 16:56:46 -0800
In Section 3:
Note that when calculating the correspondence, 2000 is not a leap year. Please disregard above statement regarding Leap Year, as the year 2000 was indeed a Leap Year.

Reported by: David L. Mills; mills@udel.edu
Date: Fri, 04 May 2001 20:50:27 +0100
In Section 5:
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2. Should be: d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
RFC 2026, "The Internet Standards Process -- Revision 3", October 1996
Reported by: Scott Bradner; sob@harvard.edu
Date: Thu, 1 Aug 2002 10:50:52 -0400
In Section 10.4:
"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..." The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).
RFC 1959, "An LDAP URL Format", June 1996
Reported by: Kurt D. Zeilenga; Kurt@OpenLDAP.org
Date: Wed, 07 Feb 2001 20:26:44 -0800
In Section 2:
::= a string as defined in RFC 1485 Should be: ::= a string as defined in RFC 1779
RFC 1915, "Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol", February 1996
In the Title:
Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol Should be: Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
RFC 1894"An Extensible Message Format for Delivery Status Notifications", January 1996
Reported by: Bruce Lilly; blilly@erols.com
Date: Mon, 25 Feb 2002 12:44:47 -0500

In Section 9.4: 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 Should be: 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 1867"Form-based File Upload in HTML", November 1995
Reported by: Dirk Nimmich; nimmich@muenster.de
Date: Sat, 9 Mar 2002 15:32:38 +0100

Every occurance of the string: , boundary= Should be replaced by: ; boundary=
RFC 1662"PPP in HDLC-like Framing", July 1994
Reported by: Charles Cranford; ctc@cablespeed.com
Date: Thu, 7 Mar 2002 22:42:43 -0500

In the References Section: [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 50, RFC 1661, Daydreamer, July 1994. Should be: [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
RFC 1534"Interoperation Between DHCP and BOOTP", October 1993
Reported by: Tyler Tidman; tyler.tidman@alcatel.com
Date: Wed, 05 Sep 2001 16:15:43 -0400
In Section 2:
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. Should be: 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 1531, "Dynamic Host Configuration Protocol", October 1993
Reported by: Jim Withnall; withnall@bigpond.net.au
Date: Thu, 1 Nov 2001 15:04:52 +1000
In Section 4.4.4:
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. Should be: 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 1517, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", September 1993
Reported by: Mr. Sharky; mrsharky@mindspring.com
Date: Sat, 30 Mar 2002 18:43:53 -0700

In Section 1: 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. Should be: 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 1321, "The MD5 Message-Digest Algorithm", April 1992
Reported by: Michael Amling; mamling@futurenext.com
Date: Wed, 12 Apr 2000 20:05:27 -0400
In Section 3.4:
the each bit of F(X,Y,Z) will be independent Should be: then each bit of F(X,Y,Z) will be independent

Reported by: Matt Borland; matt@b-swing.com
Date: Fri, 19 Jan 2001 15:04:59 -0600
In Section A.4:
#define MD MD5 Should be: #define MD 5

Reported by: Gregory Smith; smithgrege@meditech.com
Date: Fri, 14 Jun 2002 11:07:24 -0400
In Section 3.4:
/* 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. */ should be /* 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. */
In Section 3.4:
/* Round 4. */ /* Let [abcd k s t] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */ should be /* Round 4. */ /* Let [abcd k s i] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
RFC 1319, "The MD2 Message-Digest Algorithm", April 1992
Reported by: Jem Berkes; jb2002@pc9.org
Date: Wed, 30 Jan 2002 20:29:46 -0600
In Section 3.1:
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. Should be: 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.

Reported by: David Hopwood; david.hopwood@zetnet.co.uk
Date: Mon, 11 Feb 2002 21:23:10 +0000
In Section 3.2:
... /* 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. Should be: ... /* 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.
RFC 1180, "A TCP/IP Tutorial", January 1991
Reported by: Chao Yel; charles.ye@eng.sun.com
Date: Mon, 28 Feb 2000 16:15:21 -0800
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 1158, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", May 1990
Reported by: Vincent Berger; vincent.berger@afp.com
Date: Wed, 27 Mar 2002 18:19:26 +0100

In Section 5.4.2: egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13) bgp(14) Should be: egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14)
RFC 1036, "Standard for Interchange of USENET Messages", December 1987
Reported by: Florian Weimer; Florian.Weimer@RUS.Uni-Stuttgart.DE
Date: 17 May 2001 17:23:21 +0200
In Section 2.1.4:
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. Should be: 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.
RFC 0959, "FILE TRANSFER PROTOCOL (FTP)", October 1985
Reported by: Juan Li; juanli@cc.hut.fi
Date: Wed, 3 Jan 2001 16:11:05 +0200 (EET)
In Section 2.1:

The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1982. Should be: The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1972.
RFC 0894, "A Standard for the Transmission of IP Datagrams over Ethernet Networks", April 1984
Reported by: Gerald Park; Gerald.Park@hsc.com
Date: Wed, 28 Mar 2001 14:00:55 -0800
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. Should be: 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.

This page was last updated on 11-18-02.