Hi John, WG, Oscar is correct in pointing this issue with RBNF when multiple I-Ds extend the PCEP message. The erratum could be marked as "Held for Document Update" so that any future update to RFC8231 could handle it.
Note that the RBNF grammar inconsistency was discussed in the past [1]. Since PCEP messages will keep getting extended it might be worth checking if a living document (wiki, GitHub) could be used to maintain the full RBNF of PCEP messages. Thanks! Dhruv & Julien [1] https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt On Thu, Jul 1, 2021 at 3:08 PM RFC Errata System <[email protected]> wrote: > The following errata report has been submitted for RFC8231, > "Path Computation Element Communication Protocol (PCEP) Extensions for > Stateful PCE". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6627 > > -------------------------------------- > Type: Technical > Reported by: Oscar Gonzalez de Dios <[email protected]> > > Section: 6.4 > > Original Text > ------------- > <request>::= <RP> > <END-POINTS> > [<LSP>] > [<LSPA>] > [<BANDWIDTH>] > [<metric-list>] > [<RRO>[<BANDWIDTH>]] > [<IRO>] > [<LOAD-BALANCING>] > > Corrected Text > -------------- > <request>::= <RP> > <END-POINTS> > [<LSP>] > [<CLASSTYPE>] > [<LSPA>] > [<BANDWIDTH>] > [<metric-list>] > [<RRO>[<BANDWIDTH>]] > [<IRO>] > [<LOAD-BALANCING>] > > Notes > ----- > RFC 5455 defines the CLASSTYPE object and specifies that the CLASSTYPE > object MUST > be inserted after the END-POINT objects. RFC 8231 defines the LSP > object and specifies that the LSP object MUST be inserted after the > END-POINTS object. Hence, it is not clear if CLASSTYPE or LSP goes after > END-POINTS. Hence, to disambiguate and avoid interoperability issues, the > proposal is to include the CLASSTYPE object in the updated grammar. The > order would be <END-POINTS>[<LSP>][<CLASSTYPE>] > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8231 (draft-ietf-pce-stateful-pce-21) > -------------------------------------- > Title : Path Computation Element Communication Protocol > (PCEP) Extensions for Stateful PCE > Publication Date : September 2017 > Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga > Category : PROPOSED STANDARD > Source : Path Computation Element > Area : Routing > Stream : IETF > Verifying Party : IESG >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
