Re: [Pce] [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

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" <[e-mail]> wrote:

    Yeah, I like that suggestion.
    A

    -----Original Message-----
    From: Les Ginsberg (ginsberg) <[e-mail]> 
    Sent: 04 October 2022 20:43
    To: John Scudder <[e-mail]>
    Cc: Acee Lindem (acee) <[e-mail]>; Lars Eggert <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; lsr <[e-mail]>; [e-mail]; Hannes Gredler <[e-mail]>; JP Vasseur (jvasseur) <[e-mail]>; [e-mail]; Adrian Farrel <[e-mail]>
    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 <[e-mail]>
    > Sent: Tuesday, October 4, 2022 12:31 PM
    > To: Les Ginsberg (ginsberg) <[e-mail]>
    > Cc: Acee Lindem (acee) <[e-mail]>; Lars Eggert <[e-mail]>;
    > The IESG <[e-mail]>; draft-ietf-lsr-pce-discovery-security-
    > [e-mail]; [e-mail]; lsr <[e-mail]>; [e-mail];
    > Hannes Gredler <[e-mail]>; JP Vasseur (jvasseur)
    > <[e-mail]>; [e-mail]; Adrian Farrel
    > <[e-mail]>
    > 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) <[e-mail]>
    > 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 <[e-mail]>
    > >> Sent: Tuesday, October 4, 2022 11:16 AM
    > >> To: Acee Lindem (acee) <[e-mail]>
    > >> Cc: Lars Eggert <[e-mail]>; The IESG <[e-mail]>; draft-ietf-
    > lsr-
    > >> [e-mail]; [e-mail]; lsr
    > >> <[e-mail]>; [e-mail]; Hannes Gredler <[e-mail]>; Les
    > >> Ginsberg (ginsberg) <[e-mail]>; JP Vasseur (jvasseur)
    > >> <[e-mail]>; [e-mail]; Adrian Farrel
    > >> <[e-mail]>
    > >> 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) <[e-mail]>
    > 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" <[e-mail]> 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
    > >> <[e-mail]> 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$
    > >>>>
    > >>>
    > >>>
    > >