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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Mon, 29 May 2023 19:13 UTC

Return-Path: <rgandhi.ietf@gmail.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 23C3DC14F74A; Mon, 29 May 2023 12:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bv4uF66AZQba; Mon, 29 May 2023 12:13:20 -0700 (PDT)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id D5CEAC151B0E; Mon, 29 May 2023 12:13:07 -0700 (PDT)
Received: by mail-qv1-xf2e.google.com 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; d=gmail.com; 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; d=1e100.net; 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: <168358934963.50945.16961031813004080676@ietfa.amsl.com>
In-Reply-To: <168358934963.50945.16961031813004080676@ietfa.amsl.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Mon, 29 May 2023 15:12:55 -0400
Message-ID: <CAMZsk6f_vEybxVnPKWhTzeSr5TQ+gckXpaE9Y4hguQAx2P0dXg@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: gen-art@ietf.org, draft-ietf-ippm-stamp-srpm.all@ietf.org, ippm@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006bd8a905fcd9e05f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/YRPQMkl_wKgOZuG23Z34Cki2tcE>
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 19:13:24 -0000

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
>