Thank you Rakesh. Your changes address my concerns.
Yours,
Joel
On 5/29/2023 3:12 PM, Rakesh Gandhi wrote:
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
<nore...@ietf.org> 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
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
