RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (4)

RFC 5440, "Path Computation Element (PCE) Communication Protocol (PCEP)", March 2009

Note: This RFC has been updated by RFC 7896, RFC 8253, RFC 8356, RFC 9488

Source of RFC: pce (rtg)

Errata ID: 2940
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ramon Casellas
Date Reported: 2011-08-18
Verifier Name: Adrian Farrel
Date Verified: 2011-08-19

Section 5 says:

PCEP operates over TCP using a registered TCP port (4189).  This allows 
the requirements of reliable messaging and flow control to be met without 
further protocol work.  All PCEP messages MUST be sent using the registered 
TCP port for the source and destination TCP port.

It should say:

PCEP operates over TCP using a registered TCP port (4189).  This allows 
the requirements of reliable messaging and flow control to be met without 
further protocol work.  A PCE MUST listen for incoming connections at the 
registered port and a PCC SHOULD use the registered port as source port 
but MAY use any source port (e.g. ephemeral port).

Notes:

As discussed / agreed during IETF80, IETF81 and following chairs / AD suggestion

Errata ID: 2941
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ramon Casellas
Date Reported: 2011-08-18
Verifier Name: Adrian Farrel
Date Verified: 2011-08-19

Section 10.7.1 says:

 o  PCEP uses a single registered port for all communications.  The
    PCE SHOULD listen for TCP connections only on ports where
    communication is expected.

 o  The PCE SHOULD NOT allow parallel TCP connections from the same
    PCC on the PCEP-registered port.

It should say:

 o  PCEP uses a single registered port for all communications.  The
    PCE MUST listen for TCP connections only on ports where
    communication is expected.

 o  The PCE MUST NOT allow parallel TCP connections from the same
    PCC on the PCEP-registered port.

Notes:

RFC 5440 is not consistent regarding the use of RFC2119 keywords. In section 5 the RFC states "MUST" regarding the registered port and in section 10.7.1 it is stated "SHOULD". Section 10.7.1 seems to imply the PCE could listen at any port (which is technically possible, but not in line with the rest of the document). Finally, the restriction about multiple connections is confusing: Section 4.2.1 "Only one PCEP session can exist between a pair of PCEP peers at any one time" but section 10.7.1 uses "SHOULD NOT". Technically, without the TCP source restriction, it should be possible to accept multiple connections from a PCEP peer, but such a change could have broader implications

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

Reported By: Mahendra Singh Negi
Date Reported: 2015-12-06
Verifier Name: Deborah Brungard
Date Verified: 2015-12-30

In Appendix A

   The following set of variables are initialized:

      TCPRetry=0,


It should say:

   The following set of variables are initialized:

      ConnectRetry=0,

Notes:

Variable TCPRetry is not defined, defined variable is
ConnectRetry.

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

Reported By: Adrian Farrel
Date Reported: 2017-03-01
Verifier Name: Deborah Brungard
Date Verified: 2017-03-02

Section 9.3 says:


Notes:

This section does not tell IANA the range for the Object-Types to be registered for each Object-Class, nor what to do with the values not assigned in this document.

IANA has correctly recognised that the top value is 15, and that the values between those shown here and 15 should be marked as "Unassigned."

However, there is confusion over the value 0 for an Object-Type. The old entries (arising from RFC 5440) do not mention 0. Newer entries for RFC 7470 and several I-Ds in the pipe mark 0 as Unassigned.

For consistency, ALL 0 Object-Types should be marked "Reserved".

(This might need an Errata Report against some other RFCs if you are particularly fussy, but I think we can do it all on this report.)

Status: Held for Document Update (2)

RFC 5440, "Path Computation Element (PCE) Communication Protocol (PCEP)", March 2009

Note: This RFC has been updated by RFC 7896, RFC 8253, RFC 8356, RFC 9488

Source of RFC: pce (rtg)

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

Reported By: Phaneendra Manda
Date Reported: 2015-07-23
Held for Document Update by: Deborah Brungard
Date Held: 2015-11-18

Section 6.9 says:

A PCEP implementation that receives an unrecognized PCEP message MUST
   send a PCErr message with Error-value=2 (capability not supported).

It should say:

A PCEP implementation that receives an unrecognized PCEP message MUST
   send a PCErr message with Error-Type=2 (capability not supported).

Notes:

Error-value=2 is not defined, it should be Error-Type=2

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

Reported By: VENUGOPAL REDDY KONDREDDY
Date Reported: 2018-06-06
Held for Document Update by: Deborah Brungard
Date Held: 2018-06-07

Section 6.8 says:

The Close message MUST contain exactly one CLOSE object (see
   Section 6.8). 

It should say:

The Close message MUST contain exactly one CLOSE object (see
   Section 7.17). 

Notes:

Section pointed in the text is incorrect.

Report New Errata



Advanced Search