Re: [auth48] [AD] 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 03:19 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 98E58C151533; Thu, 5 Jan 2023 19:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_DNSWL_NONE=-0.0001, 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
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 dD5wskyLaR4a; Thu, 5 Jan 2023 19:19:13 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 3DA16C151527; Thu, 5 Jan 2023 19:19:13 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id p30so380590vsr.1; Thu, 05 Jan 2023 19:19:13 -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=lIqpjuptVMHehsRt5trXPy0UEyxVvFvxhuvlOlSHHdY=; b=HgB8Z9M2E3OFHl02GMOs6PzWJn8NCW4zVReOOXcujnV5q3xk8w6ZDehjoJlkB95OxF tXfD+ssKODEEgEMP47I9r4nJblwt2+JeVeUhWGM3MPuzRd7xJIuxZogLgV6wG9Yt8zDu JxxTHpMtYk0LrzgFcB01ElJ5LFEPB64ZGW1AG5gWwvttH8lmfrgAS0tdT2iWHI9UYwP+ J04eX42ezVVlwbpccoKzIYIIkjj5gyTkJS4WIGlrLqndISFWuTmYK78bcFsyfxexasjs eRlXHbFfDHCs9BU/pR9ltrKMZv51NNnsEgwc0ebjjoseO9zH/n2j2fYQz7yKCl3qhVXQ c2Gg==
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=lIqpjuptVMHehsRt5trXPy0UEyxVvFvxhuvlOlSHHdY=; b=Db+TyZiBaXkXYabhS3yk8SAvpcCPdjCpohpSXLfWU0a5v8wAlm+cf4UVfL/YNZgW0H jk1a2ohb3LFBnwTS1rO2FDmvRqhn4XJX/7HZw2MLq5Y6HFkwICcABWb5rFqetoWctX3B xXtaGdywUrmepYkK4uJnTAjmpD1tgi87m/oNLfeSQCegtmetHsc5tgPo5szePoY2CFuP gqYFYmsyH0TcGyC7w2TGQ4JXf1RXSdjiIBVK14T9bDwYgZ3PEpFx/hcYzwy1MpHDlfvL 6J2nyoXjvLWsduo70r0MX3uxw9dwLxDgEpiRZUGCqBigosGpOGbdCI7Ul09tOzJEFX8E FKjQ==
X-Gm-Message-State: AFqh2kqN2Zko0dGvGgKUJdwi4Ryzxq1H4TASZTQfZKPh7+FTPwVTjImC 5a3zqT0xlm0uEnvPfp2MNXc1/nT110drIr+QuOQ=
X-Google-Smtp-Source: AMrXdXtiyO1ev8Oxn+9x0JdcGpCUMTuNQEKnc9WL7esfG3diW2dCExA7iAC0oz5DLEpEa8H9QGBJbYyOellVI+yDUsQ=
X-Received: by 2002:a05:6102:238d:b0:3b1:2b1d:cace with SMTP id v13-20020a056102238d00b003b12b1dcacemr5962143vsr.26.1672975151973; Thu, 05 Jan 2023 19:19:11 -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>
In-Reply-To: <02468E11-70D7-427C-BEEF-80C9AD4FCE06@gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 06 Jan 2023 08:48:35 +0530
Message-ID: <CAB75xn7VA-bFr_4EAyhd6hZjiX7LHKk=di_7hUodRcNU=h1Dnw@mail.gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: Megan Ferguson <mferguson@amsl.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "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>, "jgs@juniper.net" <jgs@juniper.net>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000a6cbe505f18fe132"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/hG0Q9haIihfO1B8jaGkcVzWqWyU>
Subject: Re: [auth48] [AD] 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 03:19:18 -0000
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