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

Lars Eggert <> Fri, 04 August 2023 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 142E5C1522AF; Fri, 4 Aug 2023 03:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a31xmO9Lz2Ic; Fri, 4 Aug 2023 03:28:15 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 0B863C1522AB; Fri, 4 Aug 2023 03:28:15 -0700 (PDT)
Received: from [] (localhost []) by localhost (Mailerdaemon) with ESMTPSA id B168080617; Fri, 4 Aug 2023 13:28:11 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1691144892; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=bb82S+uTi+dfdvtxenZaG0/gYWACRxag79BWUC6eApc=; b=E5295uXej2U77jvdVZYV9dITVzSbO6Gn46g3Meo4qG2O3p09DVyPnkVW4vN9H9z+JyYs25 BZzn2nU4wDnKweQfNCFq+o9fSiFFEEtBrwn/qDkMtjR0APB0eso08S9F54YjCK4WxQaaLc GLsbyoE0ncM583/ahrrFCK7LxXx+E66aLGyquis1Q4jom+8UKmWwAoeJhrMDTQ4hNz1MSd LC7yFWWV0my2mx447rn67kjOmUmxG0N75mHgF+f4IgllIMS/I5PnnoDd7ic1QC5WoWTKHC 0UdnTWHatx+ueaiE//jhCY3BFnjnwfVKjlTM4qqka+BdMJEWCMLIYQbJXwJHWw==
Content-Type: multipart/signed; boundary="Apple-Mail=_4F5FF01C-9DC6-4679-8624-730B20941A9D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Lars Eggert <>
In-Reply-To: <>
Date: Fri, 04 Aug 2023 13:28:11 +0300
Cc: General Area Review Team <>,,,
Message-Id: <>
References: <>
To: Joel Halpern <>
X-Last-TLS-Session-Version: TLSv1.2
Archived-At: <>
Subject: Re: [ippm] [Last-Call] Genart last call review of draft-ietf-ippm-stamp-srpm-11
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Aug 2023 10:28:19 -0000

Joel, thank you for your review. I have entered a Discuss ballot for this document based on my own review.


> On May 9, 2023, at 02:42, Joel Halpern via Datatracker <> 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
> <>.
> 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.
> 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.
>    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?
>    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?
> Nits/editorial comments:
> --
> last-call mailing list