Re: [auth48] AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

["Andrew Stone (Nokia)" <[e-mail]>]

Hi RFC Editor, 

Thank you very much for undertaking this work and doing a thorough review. Much appreciated.

I've edited the XML document and attached in the reply. Most recommendations adopted, comments resolved within the XML have been removed. Thank you for the abbreviation expansions. 

A few outstanding comments/replies embedded in the XML with [andrew].  

Outstanding points (see reply inline in xml): 

- (12) reordered table to align with IANA and left-to-right reading, but should bit field description be re-ordered as well? Or okay to keep descriptions in order as is?
- (17) reference re-ordering. No preference, okay with selection by RFC editor
- (18.f) text should remain LSPA, but rfceditor to confirm LSPA citation to 5440 required or not

Thanks
Andrew



On 2023-09-28, 5:03 PM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] Please note that the title of the document has been updated as
follows. We expanded the abbreviation "PCEP" per Section 3.6 of RFC 7322
("RFC Style Guide"). Please review.


Original:
Local Protection Enforcement in PCEP


Current:
Local Protection Enforcement in the Path Computation Element
Communication Protocol (PCEP)


Note that we also updated the abbreviated title (only appears in the running
header of the pdf output) to match the document title as there was space.


Original:
Protection Enforcement


Current:
Local Protection Enforcement in PCEP
-->




2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. -->




3) <!-- [rfced] For this sentence in the Abstract, is "protection strictness"
okay, or would "protection enforcement" (like in the document title) be
better?


Original:
This document also introduces a new flag for
signalling protection strictness in PCEP.
-->




4) <!-- [rfced] Please review "define enforcement, or strictness of the
protection requirement" here. Would it be helpful to update to either
"define the enforcement of the protection requirement" or "define the
strictness of the protection enforcement requirement"?


Original:
It is desirable for an operator to be able to define the enforcement,
or strictness of the protection requirement.


Perhaps:
It is desirable for an operator to be able to define the enforcement
of the protection requirement.


Or:
It is desirable for an operator to be able to define the strictness
of the protection enforcement requirement.
-->




5) <!-- [rfced] Will readers understand what is meant by "reference notes"? Also,
we revised "is path setup type and data plane technology agnostic" as
follows to improve readability.


Original:
The document contains reference notes for Segment Routing, however
the content described is path setup type and data plane technology
agnostic.


Current:
The document contains reference notes for Segment Routing; however,
the content described is agnostic in regard to path setup type and
data plane technology.
-->




6) <!-- [rfced] We are having trouble understanding how the last part of this
sentence (i.e., "and the use case...") connects with the first
part. Also, would a citation be helpful for "RSVP"?


Original:
The name of the flag uses the term "Desired", which by
definition means "strongly wished for or intended" and the use case
originated from the RSVP.


Perhaps:
The name of the flag uses the term "Desired", which by
definition means "strongly wished for or intended". The use case
for this flag originated in RSVP.
-->




7) <!-- [rfced] May we update "Implementations of [RFC5440]" as follows for
clarity?


Original:
Implementations of [RFC5440] have either interpreted the L flag as
PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
differences.


Perhaps:
Implementations that use PCEP [RFC5440] have interpreted the L flag as
either PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
differences.
-->




8) <!-- [rfced] Should "service agreement definitions" here read "Service Level
Agreement definitions" or "SLA definitions"? Or is the current correct?


Original:
A network may be providing transit to
multiple service agreement definitions against the same base topology
network, whose behavior could vary, such as wanting local protection
to be invoked on some LSPs and not wanting local protection on
others.
-->




9) <!-- [rfced] Please review "The boolean bit L flag". Would one of the
following options improve clarity and readability?


Original:
The boolean bit L flag is unable to distinguish between the different
options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
PREFERRED and UNPROTECTED PREFERRED.


Perhaps:
The L flag is a boolean bit and thus unable to distinguish between the different
options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
PREFERRED and UNPROTECTED PREFERRED.


Or:
Because it is a boolean bit, the L flag is unable to distinguish between the different
options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
PREFERRED, and UNPROTECTED PREFERRED.
-->




10) <!-- [rfced] Two consecutive paragraphs in Section 4.2 begin with "For
example". Is "For example" needed here? Or should the second one be
updated to something like "As another example"? Please review.


Also, in the second paragraph below, we updated "is when an operator" to "is
for use cases in which an operator" for clarity and for consistency with the
previous paragraph. Please review.


Original:
For example, PROTECTION MANDATORY is for use cases where an operator
may need the LSP to follow a path which has local protection provided
along the full path, ensuring that if there is a failure anywhere
along the path that traffic will be fast re-routed at the point.


For example, UNPROTECTED MANDATORY is when an operator may
intentionally prefer an LSP to not be locally protected, and thus
would rather local failures cause the LSP to go down. ...


Perhaps:
PROTECTION MANDATORY is for use cases in which an operator
may need the LSP to follow a path that has local protection provided
along the full path, ensuring that if there is a failure anywhere
along the path that traffic will be fast re-routed at the point.


UNPROTECTED MANDATORY is for use cases in which an operator may
intentionally prefer an LSP to not be locally protected and thus
would rather local failures cause the LSP to go down.
-->




11) <!-- [rfced] Please review "protected with path protection" here. Would
updating to just "protected" retain the intended meaning?


Original:
An example
scenario is one where an LSP is protected with path protection via a
secondary diverse LSP.


Perhaps:
An example
scenario is one where an LSP is protected via a secondary diverse LSP.
-->




12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first and then bit 7
(matches IANA registry)? Or do you prefer the current (matches order mentioned in
text before table)?
-->




13) <!-- [rfced] We updated this sentence as follows to more accurately describe
the figure. Please let us know any objections.


Original:
The format of the LSPA Object as defined in [RFC5440] is:


Current:
The following shows the format of the LSPA object as defined in
[RFC5440] with the addition of the E flag defined in this document:
-->




14) <!-- [rfced] May we rephrase this sentence to improve clarity?


Original:
Considerations in the message passing between the PCC and the PCE for
the E flag bit which are not supported by the entity are outlined in
this section, with requirements for the PCE and the PCC implementing
this document described at the end.


Perhaps:
This section outlines considerations for the E flag bit in the message
passing between the PCC and the PCE that are not supported by the entity.
The requirements for the PCE and the PCC implementing this document are described
at the end.
-->




15) <!-- [rfced] Should "PCUpd E flag (and L flag)" be updated to "the E flag (and
L flag) in a PCUpd message" or something similar? Also, we used a
semicolon and changed "therefore" to "so" for clarity. Please review.


Original:
For PCC-initiated LSPs, PCUpd E flag (and L flag) is an echo from the
previous PCRpt however the bit value is ignored on the PCE from the
previous PCRpt, therefore the E flag value set in the PCUpd is zero.


Perhaps:
For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message is an echo from the
previous PCRpt message; however, the bit value is ignored on the PCE from the
previous PCRpt message, so the E flag value set in the PCUpd message is 0.
-->




16) <!-- [rfced] Will readers understand what "it" refers to here?


Original:
For a PCC which does support this document, it MAY set the E flag to
1 depending on local configuration.


Perhaps:
A PCC that does support this document MAY set the E flag to
1 depending on local configuration.


Or:
For a PCC that does support this document, the E flag MAY be set to
1 depending on local configuration.
-->




17) <!-- [rfced] Would you like the references to be alphabetized or left in their
current order?
-->




18) <!-- [rfced] Terminology


a) Please confirm the name/description for the E flag defined in this
document. We see the following forms used in the document:


Enforcement
Protection Enforcement
Local Protection Enforcement


Note: The current name in the "LSPA Object Flag Field" registry is "Protection
Enforcement" (see
https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field>); if
needed, we will request an update to the registry prior to publication.




b) Should "a local protection desired" here read "the L flag"?


Original:
Therefore, a local protection desired does
not require the transit router to satisfy protection in order to
establish the RSVP signalled path.


Perhaps:
Therefore, the L flag does
not require the transit router to satisfy protection in order to
establish the RSVP-signaled path.




c) FYI - We have updated instances of "PCRpt", "PCUpd", "PCReq", and
"PCInitiate" with the word "message" (i.e., "PCRpt message", "PCUpd message",
"PCReq message", and "PCInitiate message").




d) We see "Session Attribute" (initial caps and no hyphen) in RFC 3209, but we
do not see "SESSION-ATTRIBUTE" (all caps with hyphen). Please review and let
us know if any updates are needed in the following sentence.


Original:
One such concept in PCEP is the 'Local Protection
Desired' (L flag in the LSPA Object in [RFC5440]), which was
originally defined in the SESSION-ATTRIBUTE Object in RFC3209.




e) "Segment Routed path" does not appear in RFC 8664, but "Segment
Routing path" does. Are any changes needed in these sentences?


Original:
PCEP Extensions for Segment Routing ([RFC8664]) extends support in
PCEP for Segment Routed paths.
...
When computing a Segment Routed path, It is RECOMMENDED that a PCE
assume a Node SID is protected.


f) We see that "LSP object" is used in both RFCs 8231 and 8281,
but "LSP Attribute Object" (or "LSPA") is not used in either. Should the
sentence below be updated to reflect usage in the cited documents?


Original:
It is
important to note that [RFC8231] and [RFC8281] permit the LSP
Attribute Object to be included in PCUpd messages for PCC-initiated
and PCE-initiated LSPs.
-->




19) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.


Path Computation Element Communication Protocol (PCEP)
Label Switched Path (LSP)
Border Gateway Protocol - Link State (BGP-LS)
Service Level Agreement (SLA)
-->




20) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>
and let us know if any changes are needed.


Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->




Thank you.


RFC Editor/rv/ap


On Sep 28, 2023, at 2:02 PM, [e-mail] <mailto:[e-mail]> wrote:


*****IMPORTANT*****


Updated 2023/09/28


RFC Author(s):
--------------


Instructions for Completing AUTH48


Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/ <https://www.rfc-editor.org/faq/>).


You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.


Planning your review
---------------------


Please review the following aspects of your document:


* RFC Editor questions


Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:


<!-- [rfced] ... -->


These questions will also be sent in a subsequent email.


* Changes submitted by coauthors


Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.


* Content


Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references


* Copyright notices and legends


Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info/ <https://trustee.ietf.org/license-info/>).


* Semantic markup


Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.


* Formatted output


Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.




Submitting changes
------------------


To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:


* your coauthors


* [e-mail] <mailto:[e-mail]> (the RPC team)


* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).


* [e-mail] <mailto:[e-mail]>, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:


* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>


* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/ <https://mailarchive.ietf.org/arch/browse/auth48archive/>


* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[e-mail] <mailto:[e-mail]> will be re-added to the CC list and
its addition will be noted at the top of the message.


You may submit your changes in one of two ways:


An update to the provided XML file
— OR —
An explicit list of changes in this format


Section # (or indicate Global)


OLD:
old text


NEW:
new text


You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.


We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.




Approving for publication
--------------------------


To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.




Files
-----


The files are available here:
https://www.rfc-editor.org/authors/rfc9488.xml <https://www.rfc-editor.org/authors/rfc9488.xml>
https://www.rfc-editor.org/authors/rfc9488.html <https://www.rfc-editor.org/authors/rfc9488.html>
https://www.rfc-editor.org/authors/rfc9488.pdf <https://www.rfc-editor.org/authors/rfc9488.pdf>
https://www.rfc-editor.org/authors/rfc9488.txt <https://www.rfc-editor.org/authors/rfc9488.txt>


Diff file of the text:
https://www.rfc-editor.org/authors/rfc9488-diff.html <https://www.rfc-editor.org/authors/rfc9488-diff.html>
https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html> (side by side)


Diff of the XML:
https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html>


The following files are provided to facilitate creation of your own
diff files of the XML.


Initial XMLv3 created using XMLv2 as input:
https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml <https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml>


XMLv3 file that is a best effort to capture v3-related format updates
only:
https://www.rfc-editor.org/authors/rfc9488.form.xml <https://www.rfc-editor.org/authors/rfc9488.form.xml>




Tracking progress
-----------------


The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9488 <https://www.rfc-editor.org/auth48/rfc9488>


Please let us know if you have any questions.


Thank you for your cooperation,


RFC Editor


--------------------------------------
RFC9488 (draft-ietf-pce-local-protection-enforcement-11)


Title : Local Protection Enforcement in PCEP
Author(s) : A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan
WG Chair(s) : Julien Meuric, Dhruv Dhody


Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston