RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (6)

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 559
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

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

 

Section 1.1.3 incorrectly implies that all support protocols are 
at the Application layer.  In particular, it mentions that support 
protocol RARP (Reverse ARP), which is not an application-layer protocol.

Errata ID: 618
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bob Braden
Date Reported: 2007-10-25
Verifier Name: Bob Braden
Date Verified: 2007-11-12

Section 4.2.5 says:

  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |

It should say:

  OPEN to broadcast/multicast IP Address         |4.2.3.10| | | | |x|
  Silently discard seg to bcast/mcast addr       |4.2.3.10|x| | | | |

Errata ID: 4446
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

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

Section 1.1.1 says:

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

It should say:

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

Notes:

"Section 1.1.3" should be "Section 1.3.3".

Errata ID: 6468
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 3.3.1.4 says:

                      acknowleged data must have been transmitted

It should say:

                      acknowledged data must have been transmitted

Notes:

Misspelled "acknowledged".

Errata ID: 6469
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 4.1.3.5 says:

            application layer (e.g, so that the application can later

It should say:

            application layer (e.g., so that the application can later

Notes:

Missing full stop.

Errata ID: 6470
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-09
Verifier Name: Barry Leiba
Date Verified: 2021-03-10

Section 4.2.3.4 says:

                 (1)  if a maximum-sized segment can be sent, i.e, if:

It should say:

                 (1)  if a maximum-sized segment can be sent, i.e., if:

Notes:

Missing full stop.

Status: Held for Document Update (6)

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 1740
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Hannes Hennig
Date Reported: 2009-03-24
Held for Document Update by: Brian Haberman

Section 2.5 says:

                                                  |       | | | |S| |
                                                  |       | | | |H| |F
                                                  |       | | | |O|M|o
                                                  |       | |S| |U|U|o
                                                  |       | |H| |L|S|t
                                                  |       |M|O| |D|T|n
                                                  |       |U|U|M| | |o
                                                  |       |S|L|A|N|N|t
                                                  |       |T|D|Y|O|O|t
FEATURE                                           |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--

It should say:

                                                  |       | | | |S| |
                                                  |       | | | |H| |
                                                  |       | | | |O|M|F
                                                  |       | |S| |U|U|o
                                                  |       | |H| |L|S|o
                                                  |       |M|O| |D|T|t
                                                  |       |U|U|M| | |n
                                                  |       |S|L|A|N|N|o
                                                  |       |T|D|Y|O|O|t
FEATURE                                           |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--

Same on section 3.5 and 4.2.5.

Notes:

Footnote instead of "Footnotte" in eighth column.

Errata ID: 1936
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Thorsten Ulbricht
Date Reported: 2009-10-30
Held for Document Update by: Brian Haberman

Section 4.2.3.5 says:

            (d)  TCP SHOULD inform the application of the delivery
                 problem (unless such information has been disabled by
                 the application; see Section 4.2.4.1), when R1 is
                 reached and before R2.  This will allow a remote login
                 (User Telnet) application program to inform the user,
                 for example.

It should say:

            (e)  TCP SHOULD inform the application of the delivery
                 problem (unless such information has been disabled by
                 the application; see Section 4.2.4.1), when R1 is
                 reached and before R2.  This will allow a remote login
                 (User Telnet) application program to inform the user,
                 for example.

Notes:

The paragraph numbering got out of sequence. Letter (d) was used twice.

Errata ID: 4464
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Welzl
Date Reported: 2015-09-04
Held for Document Update by: Brian Haberman
Date Held: 2015-09-14

Section 4.2.4.2 says:

            It not required, but the application SHOULD be able to
            change the TOS during the connection lifetime.  TCP SHOULD

It should say:

            It is not required, but the application SHOULD be able to
            change the TOS during the connection lifetime.  TCP SHOULD

Notes:

just a typo (missing "is" as second word)

Errata ID: 4778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Sanjeev Ranot
Date Reported: 2016-08-18
Held for Document Update by: Martin Duke
Date Held: 2021-01-08

Section 4.2.3.4 says:

(3) or if at least a fraction Fs of the maximum window
    can be sent, i.e., if:
        [SND.NXT = SND.UNA and]

                min(D.U) >= Fs * Max(SND.WND);

It should say:

(3) or if at least a fraction Fs of the maximum window
    can be sent, i.e., if:
        [SND.NXT = SND.UNA and]

                min(D,U) >= Fs * Max(SND.WND);

Notes:

correct min(D.U) to min(D,U)

Errata ID: 5033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Eric Gray
Date Reported: 2017-06-08
Held for Document Update by: Eric Vyncke
Date Held: 2024-01-12

Section 2.3.2 says:

Section 2.3.2, and subsections 2.3.2.1 and 2.3.2.2, do not belong where 
they are in this RFC.



It should say:

Move the text in this section either under section 2.4, or in section 
3.


Notes:

ARP is a protocol used by Internet devices for the purpose of mapping Internet Addresses to MAC addresses. Link layer devices and associated protocols will only support and/or use ARP to the extent that they are also Internet devices (for example if participating in management protocols developed to operate between IP addressed devices).

Hence referring to ARP as a Link Layer Protocol will only continue to confuse the industry.

Because the number of references to ARP refering to Link.2, perhaps it would be easiest to move the text to section 2.4, adding a new subsection header 2.4.1 for the text currently in section 2.4, and renumbering current section 2.3.2 to 2.4.2 (as well as renumbering subsections 2.3.2.1 and 2.3.2.2 to 2.4.2.1 and 2.4.2.2, respectively).

Refering to ARP as a part of the Link/Internet Layer Interface is more accurate.

-- Verifier Note (EV) --

The erratum is correct, i.e., ARP is not a layer-2 protocol. The erratum reflects more the modern thinking though of ARP position in the OSI stack and does not impact the protocol itself.

Therefore, the status if "held for document update" even of RFC 1122 will probably never be updated in the world of NDP and IPv6.

Errata ID: 7507
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Antonio Cota
Date Reported: 2023-05-04
Held for Document Update by: Eric Vyncke
Date Held: 2023-08-03

Section 1.2 says:

 There are two important lessons that vendors of Internet host
 software have learned and which a new vendor should consider
 seriously.

It should say:

 There are four important lessons that vendors of Internet host
 software have learned and which a new vendor should consider
 seriously.

Notes:

I'm suggesting to replace "two" with "four" because below the 1.2 section there are 4 subsections (1.2.1, 1.2.2, 1.2.3 and 1.2.4) which lead to think that there are 4 "important lessons".

Status: Rejected (1)

RFC 1122, "Requirements for Internet Hosts - Communication Layers", October 1989

Note: This RFC has been updated by RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293

Source of RFC: Legacy
Area Assignment: int

Errata ID: 6381
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Patrick Ni
Date Reported: 2021-01-07
Rejected by: Martin Duke
Date Rejected: 2021-01-08

Section 4.2.2.6 says:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

It should say:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize 

Notes:

In Section 3.3.3 Fragmentation: MMS_S = EMTU_S - <IP header size> .... Note that <IP header size> in this equation will be 20, unless the IP reserves space to insert IP options for its own purposes in addition to any options inserted by the transport layer

IPoptionsize was already subtracted once when calculating MMS_S. It is being subtracted again upon calculating Eff.snd.MSS when MMS_S is smaller than sendMSS+20. In other words, if IP options are in use, its size is subtracted twice.
--VERIFIER NOTES--
In Section 3.3.3, it says "Note that <IP header size> in this equation will be 20, unless
the IP reserves space to insert IP options for its own purposes
in addition to any options inserted by the transport layer."

4.2.2.6 defines IPoptionsize as "IPoptionsize is the size of any IP options that TCP
will pass to the IP layer with the current message."

So MMS_S incorporates IP options from the IP layer, but IPoptionsize counts options coming from TCP. The terminology is a little confusing but careful reading of the definitions indicates that the math is correct.

Report New Errata



Advanced Search