Early Review of draft-ietf-pce-lsp-extended-flags-03
review-ietf-pce-lsp-extended-flags-03-rtgdir-early-hardwick-2022-09-08-00

Request Review of draft-ietf-pce-lsp-extended-flags
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-09-09
Requested 2022-08-17
Requested by John Scudder
Authors Quan Xiong
I-D last updated 2022-09-08
Completed reviews Rtgdir Early review of -03 by Jonathan Hardwick (diff)
Opsdir Last Call review of -05 by Bo Wu (diff)
Genart Last Call review of -05 by Roni Even (diff)
Secdir Last Call review of -05 by Shivan Kaul Sahib (diff)
Dnsdir Last Call review of -07 by Andrew Campling (diff)
Assignment Reviewer Jonathan Hardwick
State Completed
Review review-ietf-pce-lsp-extended-flags-03-rtgdir-early-hardwick-2022-09-08
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/s_AgzafiD-5MjiNI_lHTGDjSHtE
Reviewed revision 03 (document currently at 09)
Result Has issues
Completed 2022-09-08
review-ietf-pce-lsp-extended-flags-03-rtgdir-early-hardwick-2022-09-08-00
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>.

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.