Thanks a lot, Mike, Submitted version 28 which is expanding those abbreviations as well and also added xref into section 6.2.
Regards, Samuel From: Mike Bishop <[email protected]> Date: Monday, 13 October 2025 at 22:38 To: Samuel Sidor (ssidor) <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Mike Bishop's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT) These all look fine. For the abbreviations, I agree the current format is an improvement. What I was suggesting was something like the following.... CURRENT: This document uses the following terms defined in [RFC8664<https://www.rfc-editor.org/info/rfc8664>]: NAI and SR-DB. CONSIDER: This document uses the following terms defined in [RFC8664<https://www.rfc-editor.org/info/rfc8664>]: Node or Adjacency Identifier (NAI) and Segment Routing Database (SR-DB). In Section 6.2, I was suggesting that they be marked with xref elements, not for update reasons since obviously they won't change, but for ease of readers clicking through to the spot you're referencing. Neither suggestion is blocking, however, and you're welcome to handle these style questions however you like. Thanks for your work on this! ________________________________ From: Samuel Sidor (ssidor) <[email protected]> Sent: Thursday, October 9, 2025 6:30 AM To: Mike Bishop <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mike Bishop's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT) Hi Mike, Please find inline responses <S>. Thanks a lot, Samuel From: Samuel Sidor (ssidor) <[email protected]> Date: Wednesday, 8 October 2025 at 20:34 To: Mike Bishop <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Mike Bishop's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT) Thanks a lot, Mike for comments provided. I’m working on those and I’ll submit another version with changes included (those are not included yet in version 26). Regards, Samuel From: Mike Bishop via Datatracker <[email protected]> Date: Monday, 6 October 2025 at 20:47 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Mike Bishop's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT) Mike Bishop has entered the following ballot position for draft-ietf-pce-sid-algo-25: No Objection 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-pce-sid-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a well-sourced terminology section. Many of these terms are abbreviations, and I would encourage you to include the expanded term here (with the abbreviation in parentheses) alongside the reference to the RFC that defines them. Also consider moving FAD and the RFC9050 reference to the top with the same format as the other RFCs where terms are imported. I also noted the terms "headend router" and "RRO" used in the document without definitions here. <S> Added RRO, moved FAD references. For “headend” - replaced it with PCC. For expanding abbreviations - I can do that, but we changed format of those based on comments to current format, see original version: https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-16.html There appear to be too many words here: 415 * If no SEBF (including A flag defined in this document) is set, the 416 Length value MUST match the requirements as defined in 417 Section 5.2.1 of [RFC8664] applies. I think this should be either "MUST follow the requirements defined in Section 5.2.1 of [RFC8664]." or "If no SEBF (...) is set, the requirements in Section 5.2.1 of [RFC8664] apply.” <S> Updated to “MUST follow the requirements defined" Throughout the document, the following sets of terms are used inconsistently. Please pick one for each and use it throughout. - 'A flag', 'the A flag', 'the A-flag', 'the A bit', '"A" flag' - "Subobject Extension Block", "the Subobject Extension Block" - "IEEE floating-point format", "floating point format" "IEEE floating point" - "Flexible Algorithm", "Flex-algo", "Flex-Algorithm” <S> Should be more consistent now. Hopefully I updated all of them In 4.2.1 and 4.2.2, normative requirements are placed on future extensions. That doesn't really affect implementers of this specification, and they can't be enforced on those future drafts. Instead, reframe this as guidance to those future draft authors and/or as affirmative statements about what can be done in the future. If there is behavior required now to enable those future extensions (e.g. "if an SEBF is set that you don't understand, fail"), normative requirements for those would be appropriate here. <S> Ack, updated. In Sections 4.5.2 and 4.5.3, please include the appropriate reference to the definition of the floating point format (as you did in 4.5.1) or consider making this a definition used in the Terminology section. <S> Added to remaining 2 sections. The reference to "Section 5.1, Section 5.1.2, and Section 5.2" is awkward, especially as 5.1.2 is within 5.1. Consider making this "Sections 5.1 and 5.2" or simply "defined in this document" / "defined in this section". Are there multiple extensions here, or a single extension that involves multiple new elements? <S> Updated to "Sections 5.1 and 5.2”. We are trying to make sure that for example new metric types introduced are not covered. In Section 5.2.2, should "The PCE must optimize" be "The PCE MUST optimize" or "The PCE optimizes”? <S> Updated to “The PCE MUST optimize ===NITS FOLLOW=== Section 3, "the mechanisms" => "mechanisms" Section 5.2, "different SR-Algorithm constraint" => "different SR-Algorithm constraints" or "a different SR-Algorithm constraint"; "use empty ERO" => "use an empty ERO"? Section 5.2.2, "introduced IANA registry" => "created an IANA registry" Section 5.3, "new metric types defined in this document." => "the new metric types defined in this document." or simply "the metric types defined in this document." Section 6, "to PCEP extensions defined in this document" => "to the PCEP extensions defined in this document" and similar throughout the section Section 6.2, "for PCEP peer" => "for the PCEP peer" Section 6.2, several of these section references would ideally be cross-references rather than bare section numbers <S> Updated for nits. For references - do you mean references to existing RFCs (is there a risk that those will change?) or references for sections inside of the document?
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
