Thanks Joel for the Gen-ART review and the suggestions.
We have posted a new revision that addresses your comments:
Please see replies inline with <RG>....
On Mon, May 8, 2023 at 7:42 PM 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.
<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
ippm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ippm
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
