Re: [auth48] [IANA #1263592] [IANA] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review
Megan Ferguson <mferguson@amsl.com> Fri, 06 January 2023 16:06 UTC
Return-Path: <mferguson@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE06C1522C6; Fri, 6 Jan 2023 08:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm7vf_nvA2Sc; Fri, 6 Jan 2023 08:06:47 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995F4C15170D; Fri, 6 Jan 2023 08:06:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8B0364243E6D; Fri, 6 Jan 2023 08:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QrNoZ-hbKNj; Fri, 6 Jan 2023 08:06:47 -0800 (PST)
Received: from [192.168.68.143] (pool-98-110-191-83.bstnma.fios.verizon.net [98.110.191.83]) by c8a.amsl.com (Postfix) with ESMTPSA id 331ED4243E46; Fri, 6 Jan 2023 08:06:46 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Megan Ferguson <mferguson@amsl.com>
In-Reply-To: <rt-5.0.3-836373-1672946695-1292.1263592-37-0@icann.org>
Date: Fri, 06 Jan 2023 11:06:45 -0500
Cc: rfc-editor@rfc-editor.org, maqiufang1@huawei.com, lsr-chairs@ietf.org, lsr-ads@ietf.org, jgs@juniper.net, iana@iana.org, diego.r.lopez@telefonica.com, dhruv.ietf@gmail.com, daniel@olddog.co.uk, bill.wu@huawei.com, auth48archive@rfc-editor.org, acee=40cisco.com@dmarc.ietf.org, acee.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <4700399D-6C89-4E01-8938-9C4BD0CE0A0D@amsl.com>
References: <RT-Ticket-1263592@icann.org> <20221223201319.9E5A6C8AE2@rfcpa.amsl.com> <CAB75xn7-_=h0Vo81gSt5dHKnZzGHP_dtaw02QcpNJm42Mo5aTw@mail.gmail.com> <BYAPR11MB2757904738A9DC7FE33DEAD4C2F79@BYAPR11MB2757.namprd11.prod.outlook.com> <A7E5B9A7-B1F2-41F0-B514-5A01D0168624@amsl.com> <rt-5.0.3-836373-1672946695-1292.1263592-37-0@icann.org>
To: iana-matrix@iana.org
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/3NLy7eVS7J2ok5s7FRma2IpQzAE>
Subject: Re: [auth48] [IANA #1263592] [IANA] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 16:06:51 -0000
Thanks for the quick action, Amanda! RFC Editor/mf > On Jan 5, 2023, at 2:24 PM, Amanda Baber via RT <iana-matrix@iana.org> wrote: > > Hi all, > > We've changed "PCED sub-TLV Type Indicators" to "PCE Discovery (PCED) Sub-TLV Type Indicators": > > https://www.iana.org/assignments/igp-parameters > > Best regards, > > Amanda Baber > IANA Operations Manager > > On Thu Jan 05 18:14:43 2023, mferguson@amsl.com wrote: >> IANA, >> >> We would like to request a title change to a registry as described in >> the following communication with the authors: >> >>> 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! >> >> We will await confirmation of this change prior to moving this >> document forward in the publication process. >> >> Authors - Completion of this change by IANA will be recorded at >> http://www.rfc-editor.org/auth48/rfc9353. >> >> Thank you. >> >> RFC Editor/mf >> >>> On Jan 2, 2023, at 11:05 AM, Acee Lindem (acee) >>> <acee=40cisco.com@dmarc.ietf.org> 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 <dhruv.ietf@gmail.com> >>> Date: Sunday, January 1, 2023 at 11:28 PM >>> To: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> >>> Cc: diego.r.lopez@telefonica.com <diego.r.lopez@telefonica.com>, >>> bill.wu@huawei.com<bill.wu@huawei.com>, maqiufang1@huawei.com >>> <maqiufang1@huawei.com>, daniel@olddog.co.uk <daniel@olddog.co.uk>, >>> lsr-ads@ietf.org <lsr-ads@ietf.org>, lsr-chairs@ietf.org <lsr- >>> chairs@ietf.org>, Acee Lindem (acee) <acee@cisco.com>, >>> jgs@juniper.net <jgs@juniper.net>, auth48archive@rfc-editor.org >>> <auth48archive@rfc-editor.org> >>> 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 <rfc-editor@rfc-editor.org> 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 >>> >>> * rfc-editor@rfc-editor.org (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). >>> >>> * auth48archive@rfc-editor.org, 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, >>> auth48archive@rfc-editor.org 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 >>> >
- [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-p… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Acee Lindem (acee)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9353 <draft-i… Megan Ferguson
- Re: [auth48] [IANA] AUTH48: RFC-to-be 9353 <draft… Megan Ferguson
- [auth48] [IANA #1263592] Re: [IANA] AUTH48: RFC-t… Amanda Baber via RT
- Re: [auth48] [AD] AUTH48: RFC-to-be 9353 <draft-i… Acee Lindem
- Re: [auth48] [AD] AUTH48: RFC-to-be 9353 <draft-i… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Megan Ferguson
- Re: [auth48] [IANA #1263592] [IANA] AUTH48: RFC-t… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Dhruv Dhody
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Diego R. Lopez
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… daniel
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… maqiufang (A)
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-l… Qin Wu