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

Joel Halpern <jmh.direct@joelhalpern.com> Mon, 29 May 2023 20:29 UTC

Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3955C151B07; Mon, 29 May 2023 13:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aun4UIjIUcOW; Mon, 29 May 2023 13:29:13 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAEAC151985; Mon, 29 May 2023 13:29:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 4QVRvR2vY9z5bb6J; Mon, 29 May 2023 13:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1685392147; bh=ryWMIWzN/ysdjeD0U+WIwERDj9wGqTiD9KfPt/1Vqcw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=b1dN4obaXHb3Z3TljyEa6BvEEjnbci2gMwllK9L1aghJlT9KQ0nF2M0MNTcu26xui M0haxzjM//66Efad/Ya2UESLjUCtsDQ10bzbuQmesDYqpejt3M5xakH2clDnk2EYiA 32aqYW8tnWmwXbOP1EE0Q/kyprPBx/30L5WPb/vA=
X-Quarantine-ID: <sfG4aa25TwaT>
X-Virus-Scanned: Debian amavisd-new at b1.tigertech.net
Received: from [192.168.22.80] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 4QVRvQ4FZqz5bb5J; Mon, 29 May 2023 13:29:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------hj0q3d0CVn1dB0LgvAiT0vza"
Message-ID: <9b7b2ad9-538b-6721-2b12-946f093e99a1@joelhalpern.com>
Date: Mon, 29 May 2023 16:29:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2
Content-Language: en-US
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Cc: gen-art@ietf.org, draft-ietf-ippm-stamp-srpm.all@ietf.org, ippm@ietf.org, last-call@ietf.org
References: <168358934963.50945.16961031813004080676@ietfa.amsl.com> <CAMZsk6f_vEybxVnPKWhTzeSr5TQ+gckXpaE9Y4hguQAx2P0dXg@mail.gmail.com>
From: Joel Halpern <jmh.direct@joelhalpern.com>
In-Reply-To: <CAMZsk6f_vEybxVnPKWhTzeSr5TQ+gckXpaE9Y4hguQAx2P0dXg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/62_Vh5OOKN9I34OvgDIaTtC3tVY>
Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-stamp-srpm-11
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2023 20:29:17 -0000

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 
> <noreply@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
>     ippm@ietf.org
>     https://www.ietf.org/mailman/listinfo/ippm
>