Hi Lars, There has been considerable discussion about the WG’s reason for structuring the document this way, and helpful updates made to the current document. I think we can conclude, or at least I conclude, that this was done with considered intent and for good reasons.
Do you feel your DISCUSS has been addressed? Thanks, —John > On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker <nore...@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/statements/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/tr36/__;!!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 mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt7LQMKLA$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
