[Pce] Re: Mike Bishop's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

["Samuel Sidor (ssidor)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, 13 October 2025 at 22:38
To: Samuel Sidor (ssidor) <ssidor=[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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) <ssidor=[e-mail]>
Sent: Thursday, October 9, 2025 6:30 AM
To: Mike Bishop <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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) <[e-mail]>
Date: Wednesday, 8 October 2025 at 20:34
To: Mike Bishop <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Date: Monday, 6 October 2025 at 20:47
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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?