RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (2)

RFC 5520, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", April 2009

Source of RFC: pce (rtg)

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

Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Verifier Name: Adrian Farrel
Date Verified: 2009-11-07

Section 7.3, pg. 17 says:

   IANA maintains a registry of bit flags carried in the PCEP RP object
   as defined in [RFC5440].  IANA assigned a new bit flag as follows:

|  Bit Number  Hex       Name                             Reference
|  23          0x000017  Path-Key (P-bit)                 [RFC5520]

It should say:

   IANA maintains a registry of bit flags carried in the PCEP RP object
   as defined in [RFC5440].  IANA assigned a new bit flag as follows:

|  Bit Number    Name                                     Reference
|  23            Path-Key (P-bit)                         [RFC5520]

Notes:

Rationale: 'translating' the decimal bit number into a 6-digit (!)
hexadecimal value does not add specific insight and might even be
considered confusing; at most a hexadecimal bit mask might have
some additional value -- but it should be specified as an /8/-digit
mask in this case (the RP Flags field is 32 bits wide).
Because the definition of the addressed sub-registry (Section 9.6
of RFC 5440) did not specify a 'Hex' item and the IANA Registry
consequentially does not contain such column, the 'Hex' column
should have been dropped from Section 7.3 of RFC 5520 as well.

Downgraded to Editorial as the change makes no difference to the technical reading of the text.

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

Reported By: Dhruv Dhody
Date Reported: 2013-04-05
Verifier Name: Adrian Farrel
Date Verified: 2013-04-10

Section 3.2.3 says:

<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>


It should say:

<request>::= <RP>
                    <segment-computation> | <path-key-expansion>

       where:
          <segment-computation> ::= <END-POINTS>
                                    [<LSPA>]
                                    [<BANDWIDTH>]
                                    [<metric-list>]
                                    [<RRO>[<BANDWIDTH>]]
                                    [<IRO>]
                                    [<LOAD-BALANCING>]
          <path-key-expansion> ::= <PATH-KEY>


Notes:

This document defines <path-key-expansion> to allow path request message to be used for getting the confidential path segment. The <segment-computation> should be as per RFC5440 itself.
There is a mistake in the second BANDWIDTH object which should be placed with RRO as per RFC5440.

Report New Errata