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

Rakesh Gandhi <> Mon, 29 May 2023 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23C3DC14F74A; Mon, 29 May 2023 12:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 bv4uF66AZQba; Mon, 29 May 2023 12:13:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2e]) (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 (Postfix) with ESMTPS id D5CEAC151B0E; Mon, 29 May 2023 12:13:07 -0700 (PDT)
Received: by with SMTP id 6a1803df08f44-61cd6191a62so18515846d6.3; Mon, 29 May 2023 12:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685387587; x=1687979587; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=o4GG8+RBqxL7BbSJJ6M+0STYWRE1g8coR51wKmYrmtU=; b=HwUfLSW8VweEU7eez98y2jBT36S9M9Kcqv0cQxahGNOdh0kdC8zdVZ+wu7CaT3ukJE OYtVcG7kGbQ0xzN6BQgzuwHjGqZVzmqC7gU4ZWqqZiUD/3oYv9r3mw8Urp36Su7yuvWn iOSuiQQjEXk/yecBiH6N9f/37a56Mzue5qCcV8bojIzuiN4mUxF9pO80Ww4sPb3i8lzW 5/CNFXj5XXRN/bUG1ZFfubDHeJTQtTiaHMb6W1+5m2LgFzt0YxYZthBxN6TDJayqM0uq 97/oMGoF3NnSaWxw+vFYJfIwVoEMElMHNtHu0OM0vqLY2hiRlnl92+qzyfQi/AqylQM2 VQRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685387587; x=1687979587; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o4GG8+RBqxL7BbSJJ6M+0STYWRE1g8coR51wKmYrmtU=; b=JmDj7WLaMEcSBbCjQ8v2q6EeNpOWi74DqQyodmQad4qbtAyBlWIczGoUVXSN61vCVa emfelsgQz+4S0DLNZw6ySFkEaRG/Crgilpq1Up2bP1Baen9NcTNthAolN8TE5s6laLev T9elauABRR7RK1RvY0OiueeBGdMcGPSWGpOaLlQbUVQ0TLMW1VO7yVvd6nSCBLZSh49u wcCaCUcAsmJsTneUv73cYv2SvN8fM8ISTte1E2LAMttV4C9/oA1y+xSI0n0BhEnZCIYb mNic6vDghXnZroD6VZGpkZGpSUWKhY1CbZI0LP9cxAbUSb6N2IMIS+DYkajBe7WFpAhU soug==
X-Gm-Message-State: AC+VfDwRJlaepcKO6G7FfY3mMsRKtKNLVHgJyPljS2SSvVdZ6eVKUIsS oHsa5YUaE4PsHzUH85ZvO4ejnu8P3bDxVH0WAsYPaHLK4nl6L64=
X-Google-Smtp-Source: ACHHUZ7fMM1sFF6X3rNSblTb2mKooPsDu0uhG7wkTVU3f/JzedU2JGXMvhrgmHTaERL2UrI4N+3WcAyEHLvct56zghY=
X-Received: by 2002:a05:6214:2608:b0:5e6:1bf5:1ae0 with SMTP id gu8-20020a056214260800b005e61bf51ae0mr16016498qvb.18.1685387586819; Mon, 29 May 2023 12:13:06 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Rakesh Gandhi <>
Date: Mon, 29 May 2023 15:12:55 -0400
Message-ID: <>
To: Joel Halpern <>
Content-Type: multipart/alternative; boundary="0000000000006bd8a905fcd9e05f"
Archived-At: <>
Subject: Re: [ippm] 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: Mon, 29 May 2023 19:13:24 -0000

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 <> 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.

<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
>     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


> Nits/editorial comments:
> _______________________________________________
> ippm mailing list