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 . 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: