errata logo graphic

Found 4 records.

Status: Verified (2)

RFC5520, "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

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

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.


Status: Held for Document Update (2)

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

Source of RFC: pce (rtg)

Errata ID: 1776

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-05-05
Held for Document Update by: Adrian Farrel

Section 8.2, pg. 18 says:

|  [RBNF]     Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
|             in Various Protocol Specifications", Work in Progress,
|             November 2008.

It should say:

|  [RBNF]     Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
|             in Various Protocol Specifications", RFC 5511, April 2009.

Notes:

Rationale: [[ may be deleted on approval of this erratum ]]

a) The referenced document has been published as RFC 5511 shortly
*before* this RFC.

b) The expansion of "RBNF" in general, and in particular the title
of that document, have been changed before IESG approval, with
the -09 draft version submitted to the RFC Editor.
"RBNF" officially stands for "Routing BNF".
Also, the clarifying colon is missing in the citation.

It could have been expected that the RFC Editor better coordinate
between the documents in his Queue.

Hint: b) also affects other RFCs published since the draft of RFC 5511
has entered the RFC Editor Queue, e.g. RFC 5440 ff. and RFC 5455.


Errata ID: 3583

Status: Held for Document Update
Type: Editorial

Reported By: Abdussalam Baryun
Date Reported: 2013-04-07
Held for Document Update by: Adrian Farrel

Section 3.2.3 says:

The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<SVEC-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

It should say:

The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

Notes:

The corrected text is as RFC5440 section 6.4, the editorial difference is <SVEC-list> in RFC5520 and in RFC5440 is <svec-list>.


Report New Errata