RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (6)

RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003

Source of RFC: ccamp (rtg)

Errata ID: 267

Status: Verified
Type: Technical

Reported By: Steve Conner
Date Reported: 2003-02-16

OLD:

    [RFC2402]        Kent, S. and R. Atkinson, "IP Authentication
                     Header", RFC 2401, November 1998.

    [RFC2406]        Kent, S. and R. Atkinson, "IP Encapsulating
                     Security Payload (ESP)", RFC 2401, November 1998.

It should say:

    [RFC2402]        Kent, S. and R. Atkinson, "IP Authentication
                     Header", RFC 2402, November 1998.

    [RFC2406]        Kent, S. and R. Atkinson, "IP Encapsulating
                     Security Payload (ESP)", RFC 2406, November 1998.

Errata ID: 1518

Status: Verified
Type: Technical

Reported By: Pontus Sköldström
Date Reported: 2008-09-18
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

Section 4.2.1 says:

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (1) |  C-Type (1)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Notify Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Notify Node Address: 32 bits

      The IP address of the node that should be notified when generating
      an error message.

      o  IPv6 Notify Request Object

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (2) |  C-Type (2)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    IPv6 Notify Node Address                   |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num(195)|  C-Type (1)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Notify Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Notify Node Address: 32 bits

      The IP address of the node that should be notified when generating
      an error message.

      o  IPv6 Notify Request Object

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num(195)|  C-Type (2)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    IPv6 Notify Node Address                   |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The figures showing the format of the Notify Request objects have the wrong Class-Number (seems to have used the C-Type instead).

Errata ID: 2159

Status: Verified
Type: Editorial

Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 12 says:

Alternatively, the sending of no-hop-by-hop Notify messages can be disabled.

It should say:

Alternatively, the sending of non-hop-by-hop Notify messages can be disabled.

Notes:

r/no-hop-by-hop/non-hop-by-hop

Errata ID: 2160

Status: Verified
Type: Editorial

Reported By: Sean Turner
Date Reported: 2010-04-12
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section 12 says:

Configured keys MAY be used.

It should say:

Manually configured keys MAY be used.

Notes:

Assumed that this sentence is talking about the opposite of an automated key management system, which is manually configured keys.

Errata ID: 2173

Status: Verified
Type: Editorial

Reported By: Vishwas Manral
Date Reported: 2010-04-25
Verifier Name: Adrian Farrel
Date Verified: 2010-06-11

Section TOC says:

   10. RSVP Message Formats and Handling  .........................  30
    10.1  RSVP Message Formats  ...................................  30
    10.2  Addressing Path and PathTear Messages   .................  32


It should say:

   10. RSVP Message Formats and Handling  .........................  30
    10.1  RSVP Message Formats  ...................................  30
    10.2  Addressing Path, PathTear and ResvConf Messages   .......  32

Notes:

The section is called "Addressing Path, PathTear and ResvConf Messages" while the TOC does not talk about ResvConf Message

Errata ID: 4467

Status: Verified
Type: Editorial

Reported By: Alexander Okonnikov
Date Reported: 2015-09-08
Verifier Name: Deborah Brungard
Date Verified: 2015-09-10

Section 2.4 says:

Waveband switching uses the same format as the generalized label, see
   section 2.2.

It should say:

Waveband switching uses the same format as the generalized label, see
   section 2.3.

Notes:

Incorrect reference.

Status: Reported (1)

RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003

Source of RFC: ccamp (rtg)

Errata ID: 4585

Status: Reported
Type: Technical

Reported By: Alexander Okonnikov
Date Reported: 2016-01-08

Section 5.2.1 says:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label ERO subobjects
   for both downstream and upstream labels MUST be included.

It should say:

   Label RRO subobjects are included in RROs as described in [RFC3209].
   The only modification to usage and processing from [RFC3209] is that
   when labels are recorded for bidirectional LSPs, label RRO subobjects
   for both downstream and upstream labels MUST be included.

Notes:

RRO in place of ERO.

Report New Errata



Search RFCs
Advanced Search
×