[Gen-art] Genart last call review of draft-ietf-ippm-stamp-srpm-11

[Joel Halpern via Datatracker <[e-mail]>]

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-ippm-stamp-srpm-11
Reviewer: Joel Halpern
Review Date: 2023-05-08
IETF LC End Date: 2023-05-17
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as a Proposed Standard.

Major issues:
    The document has six authors.  The shepherd writeup simply says "that is
    what the authors want".  That does not seem sufficient justification.

    The Structured SRv6 Segment List Sub-TLV in section 4.1.3 seems
    problematic.  It complicates using the TLV to build the reply message, and
    adds no value to the responding node.  The only node which could make sue
    of this information is the control node which provided the information.  As
    such, including it in the message does not seem helpful.  If it really
    meets a need, a better explanation is required.

Minor issues:
    In my experience the practice of using the length of an address field to
    distinguish IPv4 and IPv6 often leads to problems.  It would seem much
    better to use two TLV type codes, one for IPv4 addresses and one for IPv6
    addresses. (Section 3)  This also applies to the Return Address sub-tly in
    section 4.1.2.

    In the description in section 4.1.3 of the return segment list sub-tlv, the
    text reads "An SR-MPLS Label Stack Sub-TLV may carry only Binding SID Label
    [I-D.ietf-pce-binding-label-sid] or Path Segment Identifier of the Return
    SR-MPLS Policy." and similar for SRv6 in the next paragraph.  This seems
    ambiguous.  Clearly, the TLV can carry a set of label or SRv6 SIDs.  If it
    carries a binding SID, whose binding SID is it?  I presume it is a binding
    SID known to the receiver, and provided to the sender via control
    mechanisms?  How can the receiver tell the difference between a valid SID
    in the LIST and a Path Segment Identifier?

    It is unclear at the end of section 3, if a responder is sending a reply
    with the U bit set to indicate that it received the STAMP request
    apparently in error, should it still use the Destination Node Address (that
    is not itself) as the source address?

Nits/editorial comments: