Hi Jon and chairs,
Thanks for your suggestions! A new version of I-D,
draft-ietf-pce-lsp-extended-flags-04.txt
has been uploaded.Name: draft-ietf-pce-lsp-extended-flagsRevision:
04Title: Label Switched Path (LSP) Object Flag Extension of Stateful
PCEDocument date: 2022-09-14Group: pcePages: 9URL:
https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-04.txtStatus:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/Html:
https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-04.htmlHtmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flagsDiff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-extended-flags-04Best
Regards,
Quan
Original
From: 熊泉00091065
To: [email protected] <[email protected]>;
Cc: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
Date: 2022年09月09日 15:13
Subject: Re:[Pce] Routing directorate early review of
draft-ietf-pce-lsp-extended-flags
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 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 PCEThe 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)ir>. Summary I have some minor concerns about this document
that I think should be resolved before 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
[email protected]
https://www.ietf.org/mailman/listinfo/pce
