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

[[e-mail]]

Hi All, 

 

Thanks for the hard work to finalise the document. 

 

No objections from me. 

 

BR, Dan. 

 

 

On 6/1/23, 17:08, <[e-mail] <mailto:[e-mail]> > wrote:

 

Authors,

Please note that the necessary IANA and AD approvals/guidance have been
received.  Once we have approvals from each author, this document will be
ready to move forward in the publication process.

 The files have been posted here (please refresh):
  https://www.rfc-editor.org/authors/rfc9353.txt
  https://www.rfc-editor.org/authors/rfc9353.pdf
  https://www.rfc-editor.org/authors/rfc9353.html
  https://www.rfc-editor.org/authors/rfc9353.xml

The relevant diff files have been posted here (please refresh):
  https://www.rfc-editor.org/authors/rfc9353-diff.html (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9353-rfcdiff.html (comprehensive
rfcdiff)
  https://www.rfc-editor.org/authors/rfc9353-auth48diff.html (AUTH48 changes
only)

The AUTH48 status page is viewable here:
  http://www.rfc-editor.org/auth48/rfc9353

Thank you.

RFC Editor/mf


> On Jan 5, 2023, at 10:18 PM, Dhruv Dhody <[e-mail]
<mailto:[e-mail]> > wrote:
> 
> Hi Acee,
> 
> On Fri, Jan 6, 2023 at 3:02 AM Acee Lindem <[e-mail]
<mailto:[e-mail]> > wrote:
> Hi Megan, 
> 
> > On Jan 5, 2023, at 1:14 PM, Megan Ferguson <[e-mail]
<mailto:[e-mail]> > wrote:
> > 
> > Acee and Dhruv and *ADs,
> > 
> > *ADs - We would appreciate further guidance on the following question:
> 
> I think it is fine as it is in the current RFC9353.txt since it says that
MD5 is obsoleted in the very next sentence. 
> 
>     As described in Section 10.2 of [RFC5440], a PCEP speaker MUST
>     support TCP MD5 [RFC2385], so no capability advertisement is needed
>     to indicate support. However, as noted in [RFC6952], TCP MD5 has
>     been obsoleted by TCP-AO [RFC5925] because of security concerns.
> 
> 
> Dhruv: I agree with Acee and take back my suggested options. The current
text is fine! 
> 
> It was the title of RFC 2385 [Protection of BGP Sessions via the TCP MD5
Signature Option] that threw me off, and I assumed it to be a document
specific to BGP only! RFC 5440 PCEP references RFC 2385 in Section 10.2 and
thus it is the correct reference to use! I apologize for the noise and
wasting everyone's precious time! 
> Thanks! 
> Dhruv
> 
> Thanks,
> Acee
> 
> 
> 
> > 
> >> 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! 
> > 
> > [rfced] *ADs - any suggestions for the authors on how to proceed with
the above issue?
> > 
> > Acee and Dhruv, 
> > 
> > Thank you for your replies and guidance.  We have updated as suggested.
Please review the updated document carefully as we do not make changes once
the document is published.  Note that the addition of “RFC Publisher” to
reference entries is due to a current tools issue and will be removed prior
to publication.
> > 
> > FYI - You will see our submitted change to the IANA registry title go by
in a separate message.
> > 
> >  The files have been posted here (please refresh):
> >   https://www.rfc-editor.org/authors/rfc9353.txt
> >   https://www.rfc-editor.org/authors/rfc9353.pdf
> >   https://www.rfc-editor.org/authors/rfc9353.html
> >   https://www.rfc-editor.org/authors/rfc9353.xml
> > 
> > The relevant diff files have been posted here (please refresh):
> >   https://www.rfc-editor.org/authors/rfc9353-diff.html (comprehensive
diff)
> >   https://www.rfc-editor.org/authors/rfc9353-rfcdiff.html (comprehensive
rfcdiff)
> >   https://www.rfc-editor.org/authors/rfc9353-auth48diff.html (AUTH48
changes only)
> > 
> > The AUTH48 status page for this document is available here:
> >   http://www.rfc-editor.org/auth48/rfc9353
> > 
> > Thank you.
> > 
> > RFC Editor/mf
> > 
> >> On Jan 2, 2023, at 11:05 AM, Acee Lindem (acee)
<acee=[e-mail] <mailto:acee=[e-mail]> >
wrote:
> >> 
> >> 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] <mailto:[e-mail]> >
> >> Date: Sunday, January 1, 2023 at 11:28 PM
> >> To: [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >
> >> Cc: [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >,
[e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >, [e-mail]
<mailto:[e-mail][e-mail]>
<[e-mail]>, [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >, [e-mail]
<mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >,
[e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >, Acee Lindem (acee) <[e-mail]
<mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >, [e-mail]
<mailto:[e-mail]>  <[e-mail]
<mailto:[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/>.
> >> 
> >> 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-4Q9l2USxIAe6P8O
4Zc
> >> 
> >>     *  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
> >> 
> > 
> 

 

  _____  


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
puede contener información privilegiada o confidencial y es para uso
exclusivo de la persona o entidad de destino. Si no es usted. el
destinatario indicado, queda notificado de que la lectura, utilización,
divulgación y/o copia sin autorización puede estar prohibida en virtud de la
legislación vigente. Si ha recibido este mensaje por error, le rogamos que
nos lo comunique inmediatamente por esta misma vía y proceda a su
destrucción.

The information contained in this transmission is confidential and
privileged information intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
transmission in error, do not read it. Please immediately reply to the
sender that you have received this communication in error and then delete
it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
pode conter informação privilegiada ou confidencial e é para uso exclusivo
da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
indicado, fica notificado de que a leitura, utilização, divulgação e/ou
cópia sem autorização pode estar proibida em virtude da legislação vigente.
Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
imediatamente por esta mesma via e proceda a sua destruição