Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
Adrian Farrel <adrian@olddog.co.uk> Wed, 05 October 2022 08:13 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD7C1524C0; Wed, 5 Oct 2022 01:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 J4bwM38gWYG3; Wed, 5 Oct 2022 01:13:35 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 EFE8CC1524BC; Wed, 5 Oct 2022 01:13:31 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 2958DING018109; Wed, 5 Oct 2022 09:13:18 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 767EE4604E; Wed, 5 Oct 2022 09:13:18 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 646B84604C; Wed, 5 Oct 2022 09:13:18 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 5 Oct 2022 09:13:18 +0100 (BST)
Received: from LAPTOPK7AS653V (host-92-27-96-157.static.as13285.net [92.27.96.157]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 2958DFfs031388 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Oct 2022 09:13:17 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>, 'John Scudder' <jgs@juniper.net>
Cc: "'Acee Lindem (acee)'" <acee@cisco.com>, 'Lars Eggert' <lars@eggert.org>, 'The IESG' <iesg@ietf.org>, draft-ietf-lsr-pce-discovery-security-support@ietf.org, lsr-chairs@ietf.org, 'lsr' <lsr@ietf.org>, pce@ietf.org, 'Hannes Gredler' <hannes@gredler.at>, "'JP Vasseur (jvasseur)'" <jvasseur@cisco.com>, meral.shirazipour@polymtl.ca
References: <166454083729.58860.322901814330533722@ietfa.amsl.com> <FE562068-8588-4998-965F-84B931CC3224@juniper.net> <5967FEDA-7517-45CF-89E7-C3B900CEEBB0@cisco.com> <7900217A-26D1-482D-B627-ED5FA96E13A5@juniper.net> <BY5PR11MB4337B4495047B64BFA90F733C15A9@BY5PR11MB4337.namprd11.prod.outlook.com> <59FE16A0-EBCA-4FED-8332-1231802894B8@juniper.net> <BY5PR11MB4337F631CA0E344CA0681009C15A9@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337F631CA0E344CA0681009C15A9@BY5PR11MB4337.namprd11.prod.outlook.com>
Date: Wed, 05 Oct 2022 09:13:15 +0100
Organization: Old Dog Consulting
Message-ID: <00f601d8d892$5309b6c0$f91d2440$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIOYiYPt8ckQdr8t5mfTqF8M9hfIgJpF4X1AXjzBj4BdQsT8QGqS3kdARcpQvEBt9eWd61F2uUw
Content-Language: en-gb
X-Originating-IP: 92.27.96.157
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27182.006
X-TM-AS-Result: No--41.398-10.0-31-10
X-imss-scan-details: No--41.398-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27182.006
X-TMASE-Result: 10--41.398000-10.000000
X-TMASE-MatchedRID: hFbMlnd2lLNU3CmLKwY9bD/131G1xzRDaYlGtTPiSiBR3sGN+j7mNO8d s1VIBbmgWAax4ULOHQCtowQ82DOPl0upwg9HCFVARpsoDCmkF1Li3aa5wOREEeWzJnTmLPxvTmg 3Ze6YIL1fjqIZlM+knosTP7O1ajq8ujQhWj33evEAzT8btdR142zBijri5+RVC/ExpXrHizyZ6U 7QhkqRnhXQ2WdX8wDlTGXWkP5ReZvM+N1efw7w35ysXQ64xiCbF+qQpCWTUjlaY5+vdounCNVtk V1dqmwpJ1IkFmDy0T2qhKuGD9RL/Ic0M9PECBOvbwiLg6tAv8Wo20LZhq1IiaTzJo0CZl8hY43C 6gs5uR/AMq2LarJybIV1qjMlHelR5Nc8GW1Swusuf8XRo3MpRx1kSRHxj+Z5Xs5nqGvDCfMOabE rRKSRvRRcqLOELivDraEve7ovySYcZnnuucTSb+8y3XaR3eL345vEiL6k1dg2ugGkJu34ZtbZhg eyVPQjyOdP7MtY6xmyaJXoZYzXD4eieUG1ENTloGx3AJ5tkZMvun/+8u/hswMUEnxBaOs1EDnWZ T9yUvMXE98y6xdDlhKewGlQsdnLzZohIHnhPVC/JxRBHWTApjllFsU0CXSPOhJ9m53n4aAvfU/r iSJXkXzGfWdtXBUc7jUA7Y9PwrTs0O7ms5ITYJa3SiQKe1CZCKFDk1kJexK/yN2q8U674lRbZF5 gj5w3+H3623+iWcYXUL74V1mm1aLmEazJewhR7BUa3y2vca7O4IB3sFRqtqfV6VlwBmU0f8+w9m 9l8BP0ZysF7DYRKx330dXSOnPPRW64xoGuxIoYB2fOueQzj4MbH85DUZXyIhbI4bdUUeMc4WL5J jd88P306Q4zhC4D3QfwsVk0Ubv+efAnnZBiL6nKAIYoU8L4F5iXm5LZACA=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7DZtcTOdozDTmDgqfxadyAzw_YU>
Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2022 08:13:40 -0000
Yeah, I like that suggestion. A -----Original Message----- From: Les Ginsberg (ginsberg) <ginsberg@cisco.com> Sent: 04 October 2022 20:43 To: John Scudder <jgs@juniper.net> Cc: Acee Lindem (acee) <acee@cisco.com>; Lars Eggert <lars@eggert.org>; The IESG <iesg@ietf.org>; draft-ietf-lsr-pce-discovery-security-support@ietf.org; lsr-chairs@ietf.org; lsr <lsr@ietf.org>; pce@ietf.org; Hannes Gredler <hannes@gredler.at>; JP Vasseur (jvasseur) <jvasseur@cisco.com>; meral.shirazipour@polymtl.ca; Adrian Farrel <adrian@olddog.co.uk> Subject: RE: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT) John - So you are suggesting that Section 4 of the draft be modified to say: "This introduction of additional sub-TLVs should be viewed as an exception to the [RFC5088][RFC5089] policy, justified by the requirement to discover the PCEP security support prior to establishing a PCEP session. The restrictions defined in [RFC5089][RFC5089] should still be considered to be in place. If in the future new advertisements are required, alternative mechanisms such as using [RFC6823] or https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ should be considered." (or similar...) I am fine with that. Les > -----Original Message----- > From: John Scudder <jgs@juniper.net> > Sent: Tuesday, October 4, 2022 12:31 PM > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> > Cc: Acee Lindem (acee) <acee@cisco.com>; Lars Eggert <lars@eggert.org>; > The IESG <iesg@ietf.org>; draft-ietf-lsr-pce-discovery-security- > support@ietf.org; lsr-chairs@ietf.org; lsr <lsr@ietf.org>; pce@ietf.org; > Hannes Gredler <hannes@gredler.at>; JP Vasseur (jvasseur) > <jvasseur@cisco.com>; meral.shirazipour@polymtl.ca; Adrian Farrel > <adrian@olddog.co.uk> > Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery- > security-support-11: (with DISCUSS and COMMENT) > > Hi Les, > > Thanks, that’s helpful. One comment, regarding > > > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to > GENINFO/OSPF-GT even if such an addition might be relevant. > > what I was actually suggesting was that the paragraph in draft-ietf-lsr-pce- > discovery-security-support could be updated to add the pointer. Since draft- > ietf-lsr-pce-discovery-security-support formally updates RFCs 5088/5089, > that would establish at least some mechanism less unreliable than trolling > through old mailing lists, to help a new implementor find this old history, > while still not requiring us to do the heavy lift of bis’ing 5088/5089 (which I > agree would be crazy to do just for this). > > —John > > > On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> > wrote: > > > > John - > > > > Thanx for finding the old email thread. > > Folks also might want to look at this thread: > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/Nhe > zQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R- > 5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$ > > > > In summary, I raised these points when the draft was adopted - but > eventually agreed to allow the draft to go forward. > > > > The intent of the restrictions in RFC5088/5089 is to discourage carrying > additional "non-routing" information in the IGPs. > > The practical matter in this case is that trying to advertise the additional > information using some other mechanism is quite costly and awkward. The > fact that the additional information are sub-sub-TLVs of the PCED sub-TLV > speaks to the coupling of the new information with the existing information. > > > > I think we want to keep restrictions in place so as to discourage new > advertisements, but recognize that we compromise when it seems practical. > This isn’t ideal - and I understand why Lars would want to discuss this - but I > don't have a cleaner solution. > > The fact that we introduced PCE advertisements into the IGPs in the first > place makes it difficult to adhere to the restrictions for PCE related > advertisements. > > > > Section 4 of the draft states: > > > > "This introduction of additional sub-TLVs should be viewed as an exception > to the [RFC5088][RFC5089] policy, justified by the requirement to discover > the PCEP security support prior to establishing a PCEP session. The > restrictions defined in [RFC5089][RFC5089] should still be considered to be in > place." > > > > which is an accurate summary. > > > > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to > GENINFO/OSPF-GT even if such an addition might be relevant. > > > > Les > > > >> -----Original Message----- > >> From: John Scudder <jgs@juniper.net> > >> Sent: Tuesday, October 4, 2022 11:16 AM > >> To: Acee Lindem (acee) <acee@cisco.com> > >> Cc: Lars Eggert <lars@eggert.org>; The IESG <iesg@ietf.org>; draft-ietf- > lsr- > >> pce-discovery-security-support@ietf.org; lsr-chairs@ietf.org; lsr > >> <lsr@ietf.org>; pce@ietf.org; Hannes Gredler <hannes@gredler.at>; Les > >> Ginsberg (ginsberg) <ginsberg@cisco.com>; JP Vasseur (jvasseur) > >> <jvasseur@cisco.com>; meral.shirazipour@polymtl.ca; Adrian Farrel > >> <adrian@olddog.co.uk> > >> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery- > >> security-support-11: (with DISCUSS and COMMENT) > >> > >> Hi Acee, > >> > >> Thanks. I have a few followups (addressed to the WG at large, not just > you). > >> > >> First, your point relates to OSPF. In the mail thread I cited, Les is talking > about > >> IS-IS. Are the concerns there similar? > >> > >> Second, you say "For non-routing information or advertising more > >> information without impacting unicast routing, I'd recommend OSPF-GT”. > >> That seems similar to Les’s advice (in > >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis- > wg/-__;!!NEt6yMaO-gk!BsexV0igrfCC6797R- > 5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3NUtSlhyQ$ > >> YjCC5vzHkBY4aVWLJGP2w5OJHM/) to use IS-IS GENINFO (RFC 6823). I can > >> see that extending the PCED (sub-)TLV was the most obvious and > expedient > >> thing to do, but was it the right thing? I’m thinking about your advice and > >> Les’s, to use the generalized/generic transport options instead — was > that > >> option considered/discussed, or had everyone forgotten about the > “please > >> use GENINFO” suggestion by the time work on this draft began (after all, > >> more than ten years after the base document was developed)? (I don’t > see > >> evidence in a review of the mailing list archives that this was ever > considered, > >> but I might have missed something.) > >> > >> Third, if indeed the restriction in question is no longer relevant, is this > >> paragraph in the new spec really needed or even appropriate? > >> > >> This introduction of additional sub-TLVs should be viewed as an > >> exception to the [RFC5088][RFC5089] policy, justified by the > >> requirement to discover the PCEP security support prior to > >> establishing a PCEP session. The restrictions defined in > >> [RFC5089][RFC5089] should still be considered to be in place. > >> > >> Maybe it should just get rid of the restriction completely! On the other > hand, > >> if it *is* appropriate to leave that paragraph in, maybe it should be a little > >> more helpful, by mentioning IS-IS GENINFO and OSPF-GT as being the > >> preferred options for any future work, so that next time we are less likely > to > >> have the same oversight? > >> > >> Thanks, > >> > >> —John > >> > >>> On Oct 4, 2022, at 1:52 PM, Acee Lindem (acee) <acee@cisco.com> > wrote: > >>> > >>> Speaking as long-time LSR/OSPF WG Member and Co-author of RFC 4970 > >> and RFC 7770: > >>> > >>> When RFC 5088 was being standardized, there was concern over both > >> advertising non-routing information in OSPF and exceeding the maximum > >> size of an OSPF Router Information LSA which was limited to a single LSA > >> instance per OSPF router (RFC 4970). The controversial statement below > was > >> added to assuage these concerns. With the publication of RFC 7770, an > OSPF > >> router can advertise multiple Router Instance LSAs with different instance > >> IDs. At the same time, we have evolved to using Router Instance LSAs for > >> limited capability information associated with routing applications (e.g., > PCE). > >> For non-routing information or advertising more information without > >> impacting unicast routing, I'd recommend OSPF-GT > >> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > ietf- > >> lsr-ospf-transport-instance/__;!!NEt6yMaO- > >> > gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 > >> PUMF_yYzechg$ ). > >>> > >>> Thanks, > >>> Acee > >>> > >>> On 10/4/22, 1:29 PM, "John Scudder" <jgs@juniper.net> wrote: > >>> > >>> Hi Everyone, > >>> > >>> +Adrian since he appears to have been the shepherd for RFC 5088, > which > >> is the root of Lars’ DISCUSS. > >>> +Hannes, Les, JP, Meral as people who may have more context on the > >> question > >>> > >>> Since I haven’t seen any replies to this DISCUSS yet I did a little digging. > >> The text in question: > >>> > >>> No additional sub-TLVs will be added to the PCED TLV in the future. > >>> If a future application requires the advertisement of additional PCE > >>> information in OSPF, this will not be carried in the Router > >>> Information LSA. > >>> > >>> Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. > >> Checking in the archives, I see one relevant mail thread: > >> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/pce/UE > >> Rk8vF5e7cFQoblkDAVA74Ojh0/__;!!NEt6yMaO- > >> > gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 > >> PUMF_994CNrH$ is the beginning, but then it seems to have been > indexed > >> wrong so you should continue from here: > >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis- > >> wg/BpUVKsjr46ha9kbF3jwgKyymEBo/__;!!NEt6yMaO- > >> > gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 > >> PUMF_4C7YoXF$ to pick up Les’s reply as well. There are four relevant > >> messages in total, from Meral Shirazipour, JP Vasseur, Hannes Gredler, > and > >> Les Ginsberg. > >>> > >>> Rather than try to summarize I’m going to ask people to go look at the > >> short mail thread for themselves. Perhaps this will jog people’s memories > >> enough to allow a discussion on why we’re opening a registry for new > code > >> points that was explicitly defined as being closed. > >>> > >>> Thanks, > >>> > >>> —John > >>> > >>>> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker > >> <noreply@ietf.org> wrote: > >>>> > >>>> > >>>> Lars Eggert has entered the following ballot position for > >>>> draft-ietf-lsr-pce-discovery-security-support-11: Discuss > >>>> > >>>> When responding, please keep the subject line intact and reply to all > >>>> email addresses included in the To and CC lines. (Feel free to cut this > >>>> introductory paragraph, however.) > >>>> > >>>> > >>>> Please refer to > >> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/stat > >> ements/handling-ballot-positions/__;!!NEt6yMaO- > >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$ > >>>> for more information about how to handle DISCUSS and COMMENT > >> positions. > >>>> > >>>> > >>>> The document, along with other ballot positions, can be found here: > >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > ietf- > >> lsr-pce-discovery-security-support/__;!!NEt6yMaO- > >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$ > >>>> > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> DISCUSS: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11 > >>>> > >>>> CC @larseggert > >>>> > >>>> ## Discuss > >>>> > >>>> ### Section 4, paragraph 3 > >>>> ``` > >>>> Section 4 of [RFC5088] states that no new sub-TLVs will be added to > >>>> the PCED TLV, and no new PCE information will be carried in the > >>>> Router Information LSA. This document updates [RFC5088] by > allowing > >>>> the two sub-TLVs defined in this document to be carried in the PCED > >>>> TLV advertised in the Router Information LSA. > >>>> > >>>> Section 4 of [RFC5089] states that no new sub-TLVs will be added to > >>>> the PCED TLV, and no new PCE information will be carried in the > >>>> Router CAPABLITY TLV. This document updates [RFC5089] by allowing > >>>> the two sub-TLVs defined in this document to be carried in the PCED > >>>> TLV advertised in the Router CAPABILITY TLV. > >>>> > >>>> This introduction of additional sub-TLVs should be viewed as an > >>>> exception to the [RFC5088][RFC5089] policy, justified by the > >>>> requirement to discover the PCEP security support prior to > >>>> establishing a PCEP session. The restrictions defined in > >>>> [RFC5089][RFC5089] should still be considered to be in place. > >>>> ``` > >>>> (This is mostly for discussion on the telechat, and I expect to clear > >>>> during the call.) > >>>> > >>>> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems > >>>> quite unusual for IETF specs. I'm not arguing that this document > >>>> can't update those earlier RFCs to allow these new sub-TLVs, but it > >>>> seems odd to do so and in the same sentence say "the restrictions > >>>> should still be considered in place." > >>>> > >>>> ### Section 8.2, paragraph 1 > >>>> ``` > >>>> The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they > >>>> did not create a registry for it. This document requests IANA to > >>>> create a new registry called "PCED sub-TLV type indicators" under the > >>>> "Interior Gateway Protocol (IGP) Parameters" grouping. The > >>>> registration policy for this registry is "IETF Review" [RFC8126]. > >>>> Values in this registry come from the range 0-65535. > >>>> ``` > >>>> Should the registration policy not be stricter (e.g., Standards > >>>> Action?) given that 5088/89 didn't even allow any new values? > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> COMMENT: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> ## Comments > >>>> > >>>> ### Inclusive language > >>>> > >>>> Found terminology that should be reviewed for inclusivity; see > >>>> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO- > >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt1fwrlFS$ for > >> background and more > >>>> guidance: > >>>> > >>>> * Term `master`; alternatives might be `active`, `central`, `initiator`, > >>>> `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` > >>>> * Term `man`; alternatives might be `individual`, `people`, `person` > >>>> > >>>> ## Nits > >>>> > >>>> All comments below are about very minor potential issues that you > may > >> choose to > >>>> address in some way - or ignore - as you see fit. Some were flagged by > >>>> automated tools (via > >> https://urldefense.com/v3/__https://github.com/larseggert/ietf- > >> reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ ), so there > >>>> will likely be some false positives. There is no need to let me know > what > >> you > >>>> did with these suggestions. > >>>> > >>>> ### URLs > >>>> > >>>> These URLs in the document can probably be converted to HTTPS: > >>>> > >>>> * > >> > https://urldefense.com/v3/__http://www.unicode.org/unicode/reports/tr3 > >> 6/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt9o1UwDk$ > >>>> > >>>> ### Grammar/style > >>>> > >>>> #### "Abstract", paragraph 1 > >>>> ``` > >>>> for OSPF and IS-IS respectively. However these specifications lack a > >> method > >>>> ^^^^^^^ > >>>> ``` > >>>> A comma may be missing after the conjunctive/linking adverb > "However". > >>>> (Also elsewhere.) > >>>> > >>>> #### Section 1, paragraph 5 > >>>> ``` > >>>> ry" instead of the "IGP registry" where as [RFC8623] and [RFC9168] > uses > >> the > >>>> ^^^^^^^^ > >>>> ``` > >>>> Did you mean "whereas"? > >>>> > >>>> #### Section 3.2.2, paragraph 3 > >>>> ``` > >>>> string to be used to identify the key chain. It MUST be encoded using > UTF- > >> 8. > >>>> ^^^^^^^^^ > >>>> ``` > >>>> This word is normally spelled as one. (Also elsewhere.) > >>>> > >>>> #### Section 5, paragraph 4 > >>>> ``` > >>>> enable a man-in-the-middle attack. Thus before advertising the PCEP > >> security > >>>> ^^^^ > >>>> ``` > >>>> A comma may be missing after the conjunctive/linking adverb "Thus". > >>>> > >>>> ## Notes > >>>> > >>>> This review is in the ["IETF Comments" Markdown format][ICMF], You > can > >> use the > >>>> [`ietf-comments` tool][ICT] to automatically convert this review into > >>>> individual GitHub issues. Review generated by the [`ietf- > reviewtool`][IRT]. > >>>> > >>>> [ICMF]: https://urldefense.com/v3/__https://github.com/mnot/ietf- > >> comments/blob/main/format.md__;!!NEt6yMaO- > >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8uPawyE$ > >>>> [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf- > >> comments__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxU9hxDt$ > >>>> [IRT]: > https://urldefense.com/v3/__https://github.com/larseggert/ietf- > >> reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- > >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ > >>>> > >>> > >>> > >
- [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce… Lars Eggert via Datatracker
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Acee Lindem (acee)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Les Ginsberg (ginsberg)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Les Ginsberg (ginsberg)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Adrian Farrel
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Adrian Farrel
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Acee Lindem (acee)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Dhruv Dhody
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Acee Lindem (acee)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ie… Dhruv Dhody
- Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ie… John Scudder
- Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ie… John Scudder
- Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ie… Dhruv Dhody
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Lars Eggert