Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review

["Acee Lindem (acee)" <[e-mail]>]

Hi RFC Editor, Dhruv,

I concur with Dhruv on thanking the RFC Editors for the excellent work!!!

See a couple inlines.

From: Dhruv Dhody <[e-mail]>
Date: Sunday, January 1, 2023 at 11:28 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Acee Lindem (acee) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review
Hello,

Happy New Year! Thanks for making the document better with your excellent work. See inline...

On Sat, Dec 24, 2022 at 1:43 AM <[e-mail]<mailto:[e-mail]>> wrote:
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:

a) Abbreviations have been expanded per Section 3.6 of RFC 7322 (“RFC
Style Guide”). Please review.

Original:
IGP extension for PCEP security capability support in PCE discovery

Current:
IGP Extension for Path Computation Element Communication Protocol
(PCEP) Security Capability Support in PCE Discovery (PCED)

Dhruv: This is fine.



b) The short title (in the running header of the PDF version) has been updated.  Please review and let us know any objections.

Current:
IGP Extension: PCEP Security in PCED
-->

Dhruv: No objection.



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


Dhruv: Can't think of any other keywords


3) <!-- [rfced]  Please review our suggested rephrase of the following text. Does it retain your intended meaning?

Original:
When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in the IGP, its presence and path computation capabilities can be advertised using IGP flooding.

Perhaps:
When a Path Computation Element (PCE) is a Label Switching Router
(LSR) or a server participating in the Interior Gateway Protocol (IGP), its
presence and path computation capabilities can be advertised using IGP
flooding. -->

Dhruv: I am happy with the rephrasing.



4) <!--[rfced] Please review the updates we have made to the following
     text (to avoid awkward hyphenation) to ensure the changes have
     retained your intended meaning.

Original:
As described in [RFC5440], Path Computation Element Communication
Protocol (PCEP) communication privacy and integrity are important
issues, as an attacker that intercepts a PCEP message could obtain
sensitive information related to computed paths and resources.

Current:
As described in RFC 5440, privacy and
integrity are important issues for communication using the Path
Computation Element Communication Protocol (PCEP); an attacker that
intercepts a PCEP message could obtain sensitive information related
to computed paths and resources.

-->

Dhruv: It is fine; just s/RFC 5440/[RFC5440]/ and I noticed that in the link that is exactly what you have already :)



5) <!-- [rfced] We have updated this sentence to include TCP-AO as a
     method to advertise PCEP security to make the text parallel to
     the Abstract. Please let us know any objections.

Original:
[RFC5088] and [RFC5089] define a method to advertise path computation
capabilities using IGP flooding for OSPF and IS-IS respectively.
However, these specifications lack a method to advertise PCEP security
(e.g., TLS) support capability.

Current:
[RFC5088] and [RFC5089] define a method to advertise path computation
capabilities using IGP flooding for OSPF and IS-IS, respectively.
However, these specifications lack a method to advertise PCEP security
(e.g., TLS and TCP-AO) support capability. -->


Dhruv: Sure!


6) <!--[rfced] Is text missing here?  "...the IS-IS" what?  Protocol?
     Sub-TLVs?  Please clarify.

Original:
[RFC5089] states that the IS-IS uses the same registry as OSPF.
-->

Dhruv: Perhaps -

[RFC5089] states that the IS-IS PCE-CAP-FLAGS sub-TLV uses the
same registry as OSPF.

Dhruv’s suggested text is fine.



7) <!--[rfced] Please review the following text for clarity.  We were
     unsure about the last sentence when comparing it with the IANA
     actions in the IANA Considerations section and RFC 8306.  If the
     suggested text is incorrect, please provide another rephrasing.

Original:
This document updates [RFC8306] where it uses the term "OSPF PCE
Capability Flag" and request assignment from OSPF Parameters registry
with "PCE Capability Flag" and the IGP Parameters registry.

Perhaps:
This document also updates [RFC8306] by changing the term "OSPF PCE
Capability Flag" to read as "Path Computation Element (PCE) Capability
Flags" and to note the corresponding registry now exits in the

"Interior Gateway Protocol (IGP) Parameters" registry.
-->

Dhruv: Happy with the rephrasing!

Please change “exits” to “exists”.



8) <!--[rfced] Please review whether any of the notes in this document
     should be in the <aside> element. It is defined as "a container
     for content that is semantically less important or tangential to
     the content that surrounds it"
     (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Original (1):
Note that [RFC5557] uses the term "OSPF registry" instead of the "IGP
registry" whereas [RFC8623] and [RFC9168] uses the term "OSPF
Parameters" instead of "IGP Parameters".

Original (2):
Note that the PCEP Open message exchange is another way to discover
PCE capabilities information, but in this instance, the TCP security
related key parameters need to be known before the PCEP session is
established and the PCEP Open messages are exchanged.  Thus, the use
of the PCE Discovery and capabilities advertisement of the IGP needs
to be leveraged. -->

Dhruv: Happy to use <aside> element in the xml!



9) <!--[rfced] The Web Portion of the RFC Style Guide
     (https://www.rfc-editor.org/styleguide/part2/) recommends using
     the abbreviated form of an abbreviation after it has been
     introduced. We will implement this style for each of the
     following abbreviations unless we hear objection.

PCE Discovery (PCED)
TCP Authentication Option (TCP-AO)
Master Key Tuple (MKT) -->

Dhruv: No objection



10) <!--[rfced] The following text is difficult to follow with regard to subject/verb agreement.  Would either of the following suggestions work?

Original:
Thus, the use of the PCE discovery and capabilities
advertisement of the IGP needs to be leveraged.

Perhaps A:
Thus, PCE discovery and capabilities
advertisement of the IGP need to be leveraged.

Perhaps B:
Thus, the leveraging of PCE discovery and capabilities
advertisement of the IGP is necessary.
-->

Dhruv: A is fine with me!

I’d suggest:
     Thus, the IGP advertisement and flooding mechanisms need to be
     leveraged for PCE discovery and capabilities advertisement.

However, I don’t feel that strongly and would be happy with A.



11) <!--[rfced] We have received guidance from Benoit Claise and the YANG
Doctors that "YANG module" and "YANG data model" are preferred.
We have updated the text to use these forms.  Please review.

Original:
The YANG model for PCEP [I-D.ietf-pce-pcep-yang] supports PCEP
security parameters (key, key chain, and TLS).

Current:
The YANG module for PCEP [I-D.ietf-pce-pcep-yang] supports PCEP
security parameters (key, key chain, and TLS). -->


Dhruv: Ack


12) <!--[rfced] We suggest rephrasing this sentence for the ease of the
     reader. Does the following suggestion retain your intended
     meaning?

Original:
Thus, before advertising the PCEP security parameters, using the
mechanism described in this document, the IGP MUST be known to provide
authentication and integrity for the PCED TLV using the mechanisms
defined in [RFC5304], [RFC5310] or [RFC5709].

Perhaps:
Thus, before advertising the PCEP security parameters by using the
mechanism described in this document, the IGP MUST be known to provide
authentication and integrity for the PCED TLV using the mechanisms
defined in [RFC5304], [RFC5310], or [RFC5709]. -->


Dhruv: It does! Happy with the rephrase!


13) <!--[rfced] Should the title change for the following IANA registry?
     We note that RFC 5086 expanded PCED on first use and capped
     "sub-" when in a title.  If these changes are agreeable, we will
     communicate them to IANA during AUTH48 and update the text of
     this document accordingly.  See:
     https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml:

Current:
PCED sub-TLV Type Indicator

Perhaps:
PCE Discovery (PCED) Sub-TLV Type Indicator

>From RFC 5089:
   This document defines a new sub-TLV (named the PCE Discovery (PCED))
   to be carried within the IS-IS Router Capability TLV ([RFC4971]).
-->

Dhruv: Happy with the change!



14) <!-- [rfced] RFC 2385 has been obsoleted by RFC 5925. Would the following update be agreeable?  We note that RFC 5925 is already in the References section.

Original:
   As described in Section 10.2 of [RFC5440], an PCEP speaker MUST
   support TCP MD5 [RFC2385], so no capability advertisement is needed
   to indicate support.

Perhaps:
   As described in Section 10.2 of [RFC5440], an PCEP speaker MUST
   support TCP MD5 [RFC2385], so no capability advertisement is needed
   to indicate support.  (Note that RFC 2385 has been obsoleted by RFC
   5925.)
-->

Dhruv: I think the reference RFC2385 itself needs to change. I see two option, we could either -

A: Not using any reference, I see published RFCs which include the term "MD5" without a reference as it is quite well-known.
B: Use the reference as RFC 1321 (can also say that is obsoleted by RFC 5925)

I think it should be “a PCEP speaker” rather than “an PCEP speaker since neither “P” or “Path” would be preceded by “an”.
I don’t feel strongly about the reference – FBOW MD5 is deployed. Either option is fine with me stating that it has been
obsoleted.

I would like to know the opinion of the RFC editor team and others in CC!





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

Dhruv: Please alphabetize them.

16) <!-- [rfced] We note that the URL provided for the reference below
     goes to a page titled "Unicode Security Considerations" instead
     of "Character Encoding Model". Please let us know how we should
     update this reference.

Original:
   [UTR36]    Davis, M., "Unicode Technical Report #36, Character
              Encoding Model",
              UTR17 https://www.unicode.org/unicode/reports/tr36/,
              February 2005. -->


Dhruv: Thanks for spotting this! Please correct this to ->

Davis, M., Ed. and M. Suignard, Ed., "Unicode Security Considerations", Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/<https://unicode.org/reports/tr36/>>.

This is what I see in RFC 9003.


17) <!-- [rfced] We had the following questions related to terminology use
     throughout the document:

a) We see the following variations with regard to spacing,
hyphenation, and capping. Please review occurrences and let us know
if/how these may be made consistent.

key-chain vs. keychain vs. key chain

Dhruv: key chain

Agreed. This is consistent with RFC 8177.

Thanks,
Acee



key-chain name vs. Key Chain Name vs. keychain name

Dhruv: key chain name (and capitalize based on context)

Also in section 3.3.1, the field name "Key Name" should be "Key Chain Name" to align with 3.3.2


Note we see both Key Chain Name sub-TLV and KEY-CHAIN-NAME sub-TLV as well.

Dhruv: Use KEY-CHAIN-NAME sub-TLV


b) We see the following mixed use of KeyID and Key ID (spacing).  May
these be made uniform?  If so, how may we update?

...[RFC5925] (referred to as KeyID).
vs.
KeyID: The one octet Key ID as per [RFC5925]
(Note: we assume KEY-ID sub-TLV should remain as is).
-->

Dhruv: My preference is for KeyID and yes when referring to sub-TLV it should be KEY-ID sub-TLV.



18) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed. For example, please consider whether
the term "Master Key Tuple (MKT)" should be updated.

Original:
KeyID: The one octet Key ID as per [RFC5925] to uniquely identify
the Master Key Tuple (MKT). -->


Dhruv: No change is needed.

Thanks!
Dhruv


Thank you.

RFC Editor/mc/mf

*****IMPORTANT*****

Updated 2022/12/23

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/).

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/).

*  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>.

*  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

     *  The archive itself:
        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/rfc9353.xml
   https://www.rfc-editor.org/authors/rfc9353.html
   https://www.rfc-editor.org/authors/rfc9353.pdf
   https://www.rfc-editor.org/authors/rfc9353.txt

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

Diff of the XML:
   https://www.rfc-editor.org/authors/rfc9353-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/rfc9353.original.v2v3.xml

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


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

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

Please let us know if you have any questions.

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9353 (draft-ietf-lsr-pce-discovery-security-support-13)

Title            : IGP extension for PCEP security capability support in PCE discovery
Author(s)        : D. Lopez, Q. Wu, D. Dhody, Q. Ma, D. King
WG Chair(s)      : Acee Lindem, Christian Hopps
Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston