[auth48] [IANA #1263592] Re: [IANA] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review
Amanda Baber via RT <iana-matrix@iana.org> Thu, 05 January 2023 19:25 UTC
Return-Path: <iana-shared@icann.org>
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 4B9BDC14CE52; Thu, 5 Jan 2023 11:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.647
X-Spam-Level:
X-Spam-Status: No, score=-6.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 ZCdLkvehbMlP; Thu, 5 Jan 2023 11:24:56 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0243C14CE3F; Thu, 5 Jan 2023 11:24:55 -0800 (PST)
Received: from request6.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 9307BE3AB5; Thu, 5 Jan 2023 19:24:55 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id 7FA924B06F; Thu, 5 Jan 2023 19:24:55 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-matrix@iana.org>
Reply-To: iana-matrix@iana.org
In-Reply-To: <A7E5B9A7-B1F2-41F0-B514-5A01D0168624@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>
Message-ID: <rt-5.0.3-836373-1672946695-1292.1263592-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1263592
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
To: mferguson@amsl.com
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-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 05 Jan 2023 19:24:55 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/Ltysc7Z8LJYY8UHeGui3UW85OF0>
Subject: [auth48] [IANA #1263592] Re: [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
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: Thu, 05 Jan 2023 19:25:00 -0000
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