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 <noreply@xxxxxxxx> 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 > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
