Thanks Joel for the Gen-ART review and the suggestions. We have posted a new revision that addresses your comments:
- https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-12.txt Please see replies inline with <RG>.... On Mon, May 8, 2023 at 7:42 PM Joel Halpern via Datatracker < [email protected]> 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. > <RG> Removed this sub-TLV from the draft. > > 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. > <RG> Separated them. > > 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? > <RG> Made the text changes to clarify. > > 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? > <RG> Added a sentence to clarify Thanks, Rakesh > > Nits/editorial comments: > > > _______________________________________________ > ippm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ippm >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
