[Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-pce-segment-routing-ipv6-24: 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-segment-routing-ipv6/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up
including the WG consensus and the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/
(Bob found no issue)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

The title is rather long, should it rather use "IPv6 Segment Routing"

## Abstract

Like other IESG members, I find the abstract convoluted, i.e., please be
straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP
in the abstract.

## Section 1

The second paragraph is rather useless, with another mention of SR-MPLS in a
SRv6 document. The 3rd paragraph is not that useful either.

4th and 5th paragraphs could be used during the WG call for adoption, but have
little to do in a SRv6-related document. Please really consider to change this
section.

## Section 2

Consider adding a reference to the SRH RFC.

## Section 3

Is `subobject` term well-defined ? Honestly, I never read this term before and
even if I can *guess* the meaning, it may be worth adding it to the terminology
section.

## Section 3.1

I have *very hard* time to understand what is meant by `When SR-MPLS is used
with an IPv6 network` to be honest. I was about to ballot a blocking DISCUSS on
this point, but I assume that I simply lack the PCEP context. May I
***REQUEST*** some explanations here ?

## Section 4.1.1

Is there a reason why the only defined bit in the flag field it not the
rightmost one ?

Please mention the position of the N bit (bit 30 from picture but let's be
crystal clear).

Is it common for PCEP communication to use the term TLV where the Length is not
actually the field length ? How can a non SRv6 capable PCEP speakers will
parse/skip this TLV without prior knowledge of the 4-octet alignment ?

## Section 4.3.1

No need to reply, but the encoding of TLV object is really weird again as it
starts with an important flag and the length is now only 1 octet.

Isn't it weird that S&V flags indicate an absence and T flag a presence ?

Should there be a reference to the IANA registry already here ?

## Section 4.3.1.2

`The presence of each of them ` should probably be "presence or absence" cfr my
comment above.