Skip to main content

Last Call Review of draft-ietf-pce-lsp-control-request-08
review-ietf-pce-lsp-control-request-08-genart-lc-palombini-2019-08-26-00

Request Review of draft-ietf-pce-lsp-control-request
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-08-28
Requested 2019-08-14
Authors Aswatnarayan Raghuram , Al Goddard , Jay Karthik , Siva Sivabalan , Mahendra Singh Negi
I-D last updated 2019-08-26
Completed reviews Rtgdir Last Call review of -06 by Tomonori Takeda (diff)
Secdir Last Call review of -07 by Shawn M Emery (diff)
Genart Last Call review of -08 by Francesca Palombini (diff)
Genart Telechat review of -09 by Francesca Palombini (diff)
Assignment Reviewer Francesca Palombini
State Completed
Request Last Call review on draft-ietf-pce-lsp-control-request by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/x0g28tF0smPvyFJevPwErx6dR0k
Reviewed revision 08 (document currently at 11)
Result Ready w/issues
Completed 2019-08-26
review-ietf-pce-lsp-control-request-08-genart-lc-palombini-2019-08-26-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-lsp-control-request-08
Reviewer: Francesca Palombini
Review Date: 2019-08-26
IETF LC End Date: 2019-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is almost ready for publication, but has minor issues/open
points that should be fixed before publication.

Major issues: N/A

Minor issues / questions:

* Section 3: At the end of season 3, you indicate that this new flag has no
meaning in PCRpt and PCInitiate messages. RFC8231 defines that the SRP Object
MAY be carried in PCErr as well, shouldn't there be such requirements (MUST be
set to 0, MUST be ignored on reception) for PCErr?

* In the following text (Section 4): "The PCE SHOULD NOT
   send control request for LSP which is already delegated to the PCE,
   i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
   NOT be set." Why is there a SHOULD NOT instead of MUST NOT? In which
   situation could it be acceptable or useful to request control for a
   delegated LSP?

Nits/editorial comments:

* Terminology should also include a sentence about the reader being familiar
with at least RFC8231.

* Terminology could also include what SRP stand for.

* Section 3. When introducing SRP, it would have been helpful to the reader to
reference section 7.2 of RFC8231.

* Section 3. "PCE sets the C Flag to 1 to indicate that, it wishes" -- remove
","

* Section 3. "MUST be ignored on receipt" -- "MUST be ignored on reception"

* Section 4. When introducing the D flag, it would have been helpful to the
reader to reference section 7.3 of RFC8231.

* Section 4. "Note that, the PCUpd message with C Flag set is received" --
"Note that, if the PCUpd message with C Flag set is received"

(Please keep my address in the To: field if you want to make sure I see any
response to this thread)

Thanks,
Francesca