Hi Jon and chairs, Thanks for your review and comments! I will update a new version to modify the first text of Section 3.2 shown as following:
"The LSP Extended Flags field is an array of units of 32 flags and to be allocated starting from the most significant bit. The bits of the LSP Extended Flags field will be assigned by future documents. This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag. This flags should follow the specification as per RFC8786." What is your suggestion? Best Regards, Quan <<[Pce] Routing directorate early review of draft-ietf-pce-lsp-extended-flags Jon Hardwick <jonhardw...@microsoft.com> Thu, 08 September 2022 15:08 UTCShow header Hi there I have been selected to do a routing directorate "early" review of this draft. draft-ietf-pce-lsp-extended-flags-03 - Label Switched Path (LSP) Object Flag Extension of Stateful PCE<https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/03/>The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is already post working group last call, my focus for the review was to determine whether the document is ready to be published. For more information about the routing area directorate, please see RtgDir - Routing Area Wiki (ietf.org)<https://trac.ietf.org/trac/rtg/wiki/RtgDir>ir>. Summary I have some minor concerns about this document that I think should be resolved be fore the publication process begins. Comments Section 3.2 Please could you add explicit statements that unused flags should be set to zero on sending and ignored on receipt? I know we have RFC 8786 which covers this, but I think it does no harm to say it explicitly anyway. Probably worth adding a normative reference to RFC 8786 as well. Section 5.1.2 Please note in the instructions to IANA that bits 0-31 should initially be marked as "Unassigned" and that bits with a higher ordinal than 31 will be added to the registry in future documents if necessary. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
