Hi Dhruv, Yes, that looks good to me, I agree with the changes and I'm fine with letting the RFC editor figure the last nit out. Thanks!
Francesca On 06/09/2019, 11:46, "Dhruv Dhody" <[email protected]> wrote: Hi Francesca, Thanks for your review. Few thoughts... On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker <[email protected]> wrote: > > Reviewer: Francesca Palombini > Review result: Ready with Issues > > 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? > I agree. I suggest to make this generic, something like - "The C Flag has no meaning in other PCEP messages that carry SRP object and the flag MUST be set to 0 on transmission and MUST be ignored on receipt." > * 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? > It wont be useful, but if received it would be silently ignored. It does not rise up to a high level of error and I suspect that is why authors used SHOULD. > Nits/editorial comments: > Thanks for these, just one comment ... > * 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" > I have noticed 'on receipt' in many of our documents. We should leave this one for the RFC-EDITOR maybe... > * 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 > Thanks again for your review. Regards, Dhruv _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
