Hi Roman and all,

Thanks again for the review. Version 11 posted to address below and Jim's 
review. 

https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-local-protection-enforcement-10&url2=draft-ietf-pce-local-protection-enforcement-11&difftype=--html

Andrew



On 2023-06-23, 9:18 AM, "Roman Danyliw" <r...@cert.org <mailto:r...@cert.org>> 
wrote:

Hi Andrew!

This text suggested below addresses the feedback in my DISCUSS position.

Thanks,
Roman


> -----Original Message-----
> From: Andrew Stone (Nokia) <andrew.st...@nokia.com 
> <mailto:andrew.st...@nokia.com>>
> Sent: Thursday, June 22, 2023 1:51 PM
> To: Roman Danyliw <r...@cert.org <mailto:r...@cert.org>>; The IESG 
> <i...@ietf.org <mailto:i...@ietf.org>>
> Cc: draft-ietf-pce-local-protection-enforcem...@ietf.org 
> <mailto:draft-ietf-pce-local-protection-enforcem...@ietf.org>; 
> pce-cha...@ietf.org <mailto:pce-cha...@ietf.org>;
> pce@ietf.org <mailto:pce@ietf.org>; julien.meu...@orange.com 
> <mailto:julien.meu...@orange.com>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-pce-local-protection-
> enforcement-10: (with DISCUSS and COMMENT)
>
> Hi Roman,
>
> Thank you for the review.
>
> Regarding the 3 text statements, thank you for catching that and can see how
> it looks inconsistent. Dhruv has kindly suggested the following text changes 
> to
> help the text be more consistent (Thanks again Dhruv!). If you agree this 
> helps
> clear the conflict, I'll submit the change in the next revision.
>
>
> OLD:
> * E Flag (Protection Enforcement): This flag controls the strictness
> in which the PCE must apply the L flag. When set to 1, the value
> of the L flag MUST be respected during resource selection by the
> PCE. When E flag is set to 0, the value of the L flag SHOULD be
> respected as selection criteria; however, the PCE is permitted to
> relax or ignore the L flag when computing a path. The statements
> below indicate preference when E flag is set to 0 in combination
> with the L flag value.
> NEW:
> * E Flag (Protection Enforcement): This flag controls the strictness
> in which the PCE must apply the L flag. When set to 1, the value
> of the L flag needs to be respected during resource selection by the
> PCE. When E flag is set to 0, an attempt to respect the value of the
> L flag is made; however, the PCE could relax or ignore the L flag when
> computing a path. The statements below indicate preference when the E
> flag is set to 0 in combination with the L flag value.
> END
>
>
> Regarding "respecting" vs "considering," the use of "respecting" was intended
> to indicate that PCE should adhere to the user's request ('respect the law') 
> but
> permitted to breaking it when E=0. On the other hand, the term "considering"
> is used in the context of how PCE should interpret the meaning of the bit 
> flags
> in relation to the definition terms.
>
> The nits will also be corrected within next revision. [
> https://mailarchive.ietf.org/arch/msg/pce/KZIGUYK1D2lPPgD8HLITczgCKaw/ 
> <https://mailarchive.ietf.org/arch/msg/pce/KZIGUYK1D2lPPgD8HLITczgCKaw/> ]
>
> Thanks
> Andrew
>
>
>
>
> On 2023-06-21, 10:39 AM, "Roman Danyliw via Datatracker"
> <nore...@ietf.org <mailto:nore...@ietf.org> <mailto:nore...@ietf.org 
> <mailto:nore...@ietf.org>>> wrote:
>
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-local-protection-enforcement-10: Discuss
>
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling- 
> <https://www.ietf.org/about/groups/iesg/statements/handling->
> ballot-positions/
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot- 
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot->
> positions/>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/ 
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/>
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/>
>  
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/&gt;>
>
>
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> ** Section 5. There is seemingly conflicting guidance on the interpreting the 
> E
> and L flag.
>
>
> Statement #1
> When E flag is set to 0, the value of the L flag SHOULD be respected as
> selection criteria;
>
>
> Statement #2
> When the L flag is set to 1 and the E flag is set to 0, then the PCE MUST
> consider the protection eligibility as a PROTECTION PREFERRED constraint.
>
>
> Statement #3
> When L flag is set to 0 and E flag is set to 1, then the PCE MUST consider the
> protection eligibility as an UNPROTECTED MANDATORY constraint.
>
>
> -- The Statement #1 appears to be weaker (SHOULD) than Statement #2 and 3.
>
>
> -- What is the difference between “respecting [something] in the selection
> criteria” and “consider[ing] the protection eligibility”?
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Thank you to Rifaat Shekh-Yusef for the SECDIR review.
>
>
> ** Abstract. This document updates RFC5440 but does not explicitly say that in
> this section.
>
>
> ** Section 7.
> Securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as
> per the recommendations and best current practices in [RFC7525] is
> RECOMMENDED.
>
>
> RFC7525 has been replaced by RFC9325.
>
>
>
>
>
>
>
>





_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to