Hi Dhruv, Regarding whether this is a verifiable erratum or not, the submitter notes, “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 use of the word “proposal” suggests to me that this goes beyond the scope of an erratum, which is limited to correcting errors in a manner consistent with the consensus at time of publication (https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/). Unless there was specific consensus for the proposed sorting order, it seems to me the erratum oversteps this boundary.
Thanks for your reference to draft-cmfg-pce-pcep-grammar-02. Looking at the list traffic, it doesn’t appear there was much (any, really) discussion of it, unfortunately. It also led me to find https://mailarchive.ietf.org/arch/msg/pce/VUM5GymISrBiPgoUEVH8IkaM3tU/ , where the AD at the time (Adrian) rejected erratum 3672, which is similar to 6627 in that it complains about ambiguous ordering and asks for a fix. Adrian ends his rejection comment with “In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group. The fix, therefore, if it is to be applied needs to be achieved through a consensus document.” AFAICT this reasoning applies equally in the current case. Actually, it applies even more so, because the WG was offered draft-cmfg-pce-pcep-grammar-02 and didn’t do anything with it, which implies a lack of consensus to go forward with a solution to the identified problem. I do agree that since this topic won't be going away, it seems worth expending some effort to solve it instead of ignoring it. Unless someone wants to make the argument that the RBNF grammar isn’t subject to IETF consensus, I’m not sure the methods you suggest are suitable, at least not without some additional consideration for how to make sure they reliably reflect consensus. Finally I note this other paragraph from Adrian’s message: “Discussion of this point led to a debate about whether the RBNF is normative and should be "compilable". Some hold the view that being conservative in what you send and liberal in what you receive could only make this text normative for building messages not parsing them. Others noted that, as with RSVP, the object ordering is advisory not mandatory except as where noted explicitly in the text.” (FYI the discussion he references is here: https://mailarchive.ietf.org/arch/msg/pce/Og5fW8dZU2VgDjQywSIPm9jU87w/) This implies to me that there’s at least one other possible way forward, which would be to update RFC5440, making object ordering optional. Something like this: OLD: An implementation MUST form the PCEP messages using the object ordering specified in this document. NEW: An implementation SHOULD form the PCEP messages using the object ordering specified in this and subsequent documents when an ordering can be unambiguously determined; an implementation MUST be prepared to receive a PCEP message with objects in any order. In other words, fix the problem by fiat, retroactively declaring it to be a non-problem. Let me be the first to say that this proposal might be technically unsound for some reason, but since it was mentioned in the earlier email and represents a different way forward, I thought I’d include it here. I’ll wait for further discussion, but for now my plan is to reject the erratum for the same reason 3672 was rejected. Thanks, —John On Sep 30, 2021, at 12:04 PM, Dhruv Dhody <[email protected]<mailto:[email protected]>> wrote: 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<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-cmfg-pce-pcep-grammar-02.txt__;!!NEt6yMaO-gk!UQN1qCMKzSbkTI8Rrsuon-yIYbBWV3jjfq4aE_B-dY1CpwZH8u0oWlaZrF1eYg$> On Thu, Jul 1, 2021 at 3:08 PM RFC Errata System <[email protected]<mailto:[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<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6627__;!!NEt6yMaO-gk!UQN1qCMKzSbkTI8Rrsuon-yIYbBWV3jjfq4aE_B-dY1CpwZH8u0oWlYLm_GsQA$> -------------------------------------- Type: Technical Reported by: Oscar Gonzalez de Dios <[email protected]<mailto:[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
