HI, Apologies for introducing nits in the update. I am using a new editor that seems to behave differently. I have updated my working copy!
https://github.com/dhruvdhody/ietf/commit/00dd5aa38ca139fba8d6dcbe3ed06b2e89fcae25 On Wed, Oct 5, 2022 at 9:23 PM John Scudder <jgs= [email protected]> wrote: > There’s also a spurious quotation mark in > > such as using [RFC6823]" > > I was also wondering why the pre-2008 disclaimer got added? None of the > changes in -12 require it. > > Yes, none of the changes require it! But this existing idnits warning made sense to me and thus I added the disclaimer. Let me know if that is a mistake, I can revert! Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC5088, updated by this document, for RFC5378 checks: 2006-09-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) Thanks! Dhruv > Thanks, > > —John > > > On Oct 5, 2022, at 11:46 AM, Acee Lindem (acee) <[email protected]> wrote: > > > > > > > > Hi Dhruv, > > Thanks for the quick turnaround. It looks good to me. One nit, I believe > a period was added to “However, as noted in [RFC6952].,” by mistake. > > Thanks, > > Acee > > > > From: Lsr <[email protected]> on behalf of Dhruv Dhody < > [email protected]> > > Date: Wednesday, October 5, 2022 at 9:06 AM > > To: Lars Eggert <[email protected]> > > Cc: The IESG <[email protected]>, " > [email protected]" < > [email protected]>, " > [email protected]" <[email protected]>, "[email protected]" <[email protected]>, > Acee Lindem <[email protected]>, "[email protected]" <[email protected]>, "Les > Ginsberg (ginsberg)" <[email protected]>, Adrian Farrel < > [email protected]>, John Scudder <[email protected]>, Roman Danyliw < > [email protected]> > > Subject: Re: [Lsr] Lars Eggert's Discuss on > draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT) > > > > Hi all, > > > > I have incorporated changes suggested by Les and Acee in the working > copy maintained at - > > > > TXT - > https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt > > DIFF - > https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt > > > > Also, see inline... > > > > > > On Fri, Sep 30, 2022 at 5:57 PM 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > >> for more information about how to handle DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> 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? > >> > > > > Dhruv: Updated to Standards Action. > > > > > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> ## Comments > >> > >> ### Inclusive language > >> > >> Found terminology that should be reviewed for inclusivity; see > >> https://www.rfc-editor.org/part2/#inclusive_language for background > and more > >> guidance: > >> > >> * Term `master`; alternatives might be `active`, `central`, > `initiator`, > >> `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` > > > > Dhruv: The term appears in reference to an existing term defined in > another RFC. > > > > KeyID: The one octet Key ID as per [RFC5925] to uniquely identify > > the Master Key Tuple (MKT). > > > > Not sure how I can avoid using the term. > > > > > >> * Term `man`; alternatives might be `individual`, `people`, `person` > >> > > > > Dhruv: Updated (as also suggested by Roman) > > > > > >> ## 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://github.com/larseggert/ietf-reviewtool), > 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: > >> > >> * http://www.unicode.org/unicode/reports/tr36/ > >> > > > > Dhruv: Updated. > > > > > >> ### 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.) > > > > Dhruv: The "key chain" is quite common. 'Greping' in existing RFCs I > found many instances! > > > > > >> > >> #### 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". > >> > > > > Dhruv: All other nits are incorporated. > > > > Thanks! > > Dhruv > > > > > >> ## 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://github.com/mnot/ietf-comments/blob/main/format.md > >> [ICT]: https://github.com/mnot/ietf-comments > >> [IRT]: https://github.com/larseggert/ietf-reviewtool > >> > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
