Re: [Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

2019-09-13 Thread Francesca Palombini 
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"  wrote:

Hi Francesca,

Thanks for your review. Few thoughts...

On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker
 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
>
> .
>
> 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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

2019-09-06 Thread Dhruv Dhody 
Hi Francesca,

Thanks for your review. Few thoughts...

On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker
 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
>
> .
>
> 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

2019-08-26 Thread Francesca Palombini via Datatracker 
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

.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art