Re: [ippm] [Last-Call] Genart last call review of draft-ietf-ippm-stamp-srpm-11

[Lars Eggert <[e-mail]>]

Joel, thank you for your review. I have entered a Discuss ballot for this document based on my own review.

Lars


> On May 9, 2023, at 02:42, Joel Halpern via Datatracker <[e-mail]> wrote:
> 
> 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:
> 
> 
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call