That would be good for me as well. Given the discussion that is going on regarding YANG string lengths in NETMOD, it might also be good to limit the key-chain name to 255 characters as we did for the dynamic hostname in RFC 5301 and RFC 5642.
Thanks, Acee On 10/5/22, 4:13 AM, "Adrian Farrel" <[email protected]> wrote: Yeah, I like that suggestion. A -----Original Message----- From: Les Ginsberg (ginsberg) <[email protected]> Sent: 04 October 2022 20:43 To: John Scudder <[email protected]> Cc: Acee Lindem (acee) <[email protected]>; Lars Eggert <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; lsr <[email protected]>; [email protected]; Hannes Gredler <[email protected]>; JP Vasseur (jvasseur) <[email protected]>; [email protected]; Adrian Farrel <[email protected]> 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 <[email protected]> > Sent: Tuesday, October 4, 2022 12:31 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem (acee) <[email protected]>; Lars Eggert <[email protected]>; > The IESG <[email protected]>; draft-ietf-lsr-pce-discovery-security- > [email protected]; [email protected]; lsr <[email protected]>; [email protected]; > Hannes Gredler <[email protected]>; JP Vasseur (jvasseur) > <[email protected]>; [email protected]; Adrian Farrel > <[email protected]> > 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) <[email protected]> > 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 <[email protected]> > >> Sent: Tuesday, October 4, 2022 11:16 AM > >> To: Acee Lindem (acee) <[email protected]> > >> Cc: Lars Eggert <[email protected]>; The IESG <[email protected]>; draft-ietf- > lsr- > >> [email protected]; [email protected]; lsr > >> <[email protected]>; [email protected]; Hannes Gredler <[email protected]>; Les > >> Ginsberg (ginsberg) <[email protected]>; JP Vasseur (jvasseur) > >> <[email protected]>; [email protected]; Adrian Farrel > >> <[email protected]> > >> 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) <[email protected]> > 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" <[email protected]> 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 > >> <[email protected]> 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$ > >>>> > >>> > >>> > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
