Re: [ippm] Genart last call review of draft-ietf-ippm-stamp-srpm-11

[Joel Halpern <[e-mail]>]

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 
> <[e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ippm
>