Re: [auth48] AUTH48: RFC-to-be 9353 <draft-ietf-lsr-pce-discovery-security-support-13> for your review
Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 06 January 2023 16:34 UTC
Return-Path: <dhruv.ietf@gmail.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 C3CE7C14F747; Fri, 6 Jan 2023 08:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GxQtZkLDfKpP; Fri, 6 Jan 2023 08:34:31 -0800 (PST)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 62BBDC14F723; Fri, 6 Jan 2023 08:34:31 -0800 (PST)
Received: by mail-vs1-xe31.google.com with SMTP id l184so2004407vsc.0; Fri, 06 Jan 2023 08:34:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K9kWmVLHB8qm6Jf7ok5+PdLUMoHG+0Autz3TiOsiUhw=; b=j6d1SVHw6X6EVXrfejdQBeXjJFkuEstacI5k9C9tDBg4DNO7sXxXEH/91aM93NO5Io P5BK9cQ0S+Zvb21nNLYyH+QwTXpzkWUsKjK86zXGIyWHCtHksCJx1WH9N9qyz5MoP9mP JTdIoIQ0nQYc7HQtH2BEv1z+DM5m9W2V9lcsuq9Rs7dh3mQ93kFLYXNEvXVHgs1zd7wk w/vRV30x51DYaVVxBPT2826q9stxYGVp+iCsGCigy4Evfaz6OrHxX539KuczmMsx5DHZ Y8ajaBU7COI3EKAMorw7e4wtkoX1zX0xHNJVZSYUWR/Yqg0KzLExLUB9KH7UuDNksFMz nNCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K9kWmVLHB8qm6Jf7ok5+PdLUMoHG+0Autz3TiOsiUhw=; b=4c4A/nplGr3kO07FJoPODfN8geKXHfhI9A6R/Cjh87tFQZDAEVY7cAXDQbok13eWtD 9jNTZlECpRr1S0Zc1H/kcqjrsW9z6DO/PqliMiBBhy/dTCnffg+TO2YJaebzO3KRxkzk 37O5ohynu/j2kieWMt66yo3HbZTNbKzSUoVu/z7otAXsNQt37Gb3wAKlnXe4a70rMFyD MzXBPLPfbv55Bzbr9gs0gJdN4+hqQwTVZtIHXmi1Zp9dTvN0Kt5WYPkMFS+WFv5lBhmr lvVmMj4Z6MZDE0a/Bz+AzYiAyl+UNJzGGMzmWhhCE3edCrOzh8T2PVb20+sPhnkhV5R3 MbrA==
X-Gm-Message-State: AFqh2kpswOaPcnUwaNL9kEarO/rRc0fI1dzOCxIv0J+2pgxRovmFpS68 hV9FjOypbAThmbMFe2WoHA1bAvdq0/8BEiWBfvc=
X-Google-Smtp-Source: AMrXdXt0Op4gY2jn0DOAgaDfKy7YLkQwdGdPIz17QeoYqAvN9wWGWUqZ0KKdmrXR/F1fMfPjI7YoNA1hlJy2L2ilj7o=
X-Received: by 2002:a67:d605:0:b0:3c8:bc19:2ffa with SMTP id n5-20020a67d605000000b003c8bc192ffamr4777361vsj.51.1673022870062; Fri, 06 Jan 2023 08:34:30 -0800 (PST)
MIME-Version: 1.0
References: <20221223201319.9E5A6C8AE2@rfcpa.amsl.com> <CAB75xn7-_=h0Vo81gSt5dHKnZzGHP_dtaw02QcpNJm42Mo5aTw@mail.gmail.com> <BYAPR11MB2757904738A9DC7FE33DEAD4C2F79@BYAPR11MB2757.namprd11.prod.outlook.com> <C2862067-9321-464A-8D2A-9E6574403A4C@amsl.com> <02468E11-70D7-427C-BEEF-80C9AD4FCE06@gmail.com> <CAB75xn7VA-bFr_4EAyhd6hZjiX7LHKk=di_7hUodRcNU=h1Dnw@mail.gmail.com> <A7AA997E-2E81-4E35-8F52-639B7D64AC34@amsl.com>
In-Reply-To: <A7AA997E-2E81-4E35-8F52-639B7D64AC34@amsl.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 06 Jan 2023 22:03:53 +0530
Message-ID: <CAB75xn6eXS8yvkAsGh-F8q7nD2ZMLfCb7AUp2ncuxmjruCUuwQ@mail.gmail.com>
To: Megan Ferguson <mferguson@amsl.com>
Cc: "lsr-ads@ietf.org" <lsr-ads@ietf.org>, "daniel@olddog.co.uk" <daniel@olddog.co.uk>, "diego.r.lopez@telefonica.com" <diego.r.lopez@telefonica.com>, "maqiufang1@huawei.com" <maqiufang1@huawei.com>, "jgs@juniper.net" <jgs@juniper.net>, "bill.wu@huawei.com" <bill.wu@huawei.com>, Acee Lindem <acee.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000df0b7f05f19afd36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/hUUWuTU0mmvmgKvJgBVH-elFOt0>
Subject: Re: [auth48] 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:34:35 -0000
Hi Megan, I have reviewed the changes, please note my approval. Thanks! Dhruv On Fri, Jan 6, 2023 at 9:36 PM Megan Ferguson <mferguson@amsl.com> 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 <dhruv.ietf@gmail.com> wrote: > > > > Hi Acee, > > > > On Fri, Jan 6, 2023 at 3:02 AM Acee Lindem <acee.ietf@gmail.com> wrote: > > Hi Megan, > > > > > On Jan 5, 2023, at 1:14 PM, Megan Ferguson <mferguson@amsl.com> 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= > 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