Re: [ippm] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

Joel Halpern <> Sun, 25 September 2022 04:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6D6AC1522D8; Sat, 24 Sep 2022 21:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Status: No, score=-2.806 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z0o6I2DTgRC0; Sat, 24 Sep 2022 21:26:13 -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 A7DA7C14CF02; Sat, 24 Sep 2022 21:26:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4MZt9x3s9nz1pZ4R; Sat, 24 Sep 2022 21:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1664079973; bh=clklW5G+MEMOTSJvUYlTSLk4yb3XNhhjXocZEIrxwYk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RBCAEhjx8UKJsnY6vaaN6nOPeM5jN9bNwluk9Mh7QFGfHkKOZgEinqEXoWXCCE+G4 ME/ndf7q0lXTvgOXHunE4FlN/BHVHscS0SiE5BKWnKkHrdyTj/7OVgUKlh7rxyBCmc UPF5nU0sz5PX7vd2w5AiZ4l1cNbg0ObnvJOogBm0=
X-Quarantine-ID: <PGZTB053mJIR>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (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 ESMTPSA id 4MZt9w51Dlz1nsDW; Sat, 24 Sep 2022 21:26:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------SIdhxAhAa03sv6oQQ7rAaEN7"
Message-ID: <>
Date: Sun, 25 Sep 2022 00:26:09 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: Shwetha Bhandari <>
References: <> <>
From: Joel Halpern <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08
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: Sun, 25 Sep 2022 04:26:17 -0000

Thank you for addressing my comments.  trimmed, responses where needed 
in line.



On 9/24/2022 10:01 PM, Shwetha Bhandari wrote:
> Thank you for the detailed review and sorry for a very late response. 
> I am creating a revision of the draft based on this feedback.
> Responses and clarifications inline @SB
> On Wed, Jun 29, 2022 at 1:39 AM Joel Halpern via Datatracker 
> <> wrote:
>     Reviewer: Joel Halpern
>     Review result: Ready with Issues
>     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
>     <;!!MZ3Fw45to5uY!NoSxZQbYffG7SJV0yDCTEy7dKRhLkASqrXTvmSZYhuyCrik6ftQvulTvbfT6xyFBWdoxk_7S4nD87nOYMkJnckbF$
>     >.
>     Document: draft-ietf-ippm-ioam-ipv6-options-08
>     Reviewer: Joel Halpern
>     Review Date: 2022-06-28
>     IETF LC End Date: 2022-07-01
>     IESG Telechat date: Not scheduled for a telechat
>     Minor issues:
>         Section 5.1 (Considerations for IOAM deployment in IPv6 networks)
>         requirement C1 seems to be an implementation requirement not a
>     deployment
>         requirement.  The text even ends with "Implementations of IOAM
>     SHOULD..."
>         Why is this in a deployment considerations section?
> [SB] This was an important consideration for implementation and 
> deployment that came
> up during the workgroup discussions. Would renaming the sesion to 
> deployment and implementation
> considerations work?
<jmh>Yes, renaming the section to "deployment and implementation 
considerations" would resolve this concern. </jmh>
>         Requirement C5 in 5.1 says that leaks need to be easily
>     identified and
>         attributed.  That's nice.  It doesn't seem to say HOW that is
>     to be done.
>         So how does an implementor or deployer comply with the
>     requirement?
> [SB] This is not addressed in the current draft. A future draft could add
> IOAM field to indicate the AS that added the IOAM data.
<jmh>I marked this as minor, so if you really can't say anything else, I 
guess I can live with it.  But it seems more than a little odd to have a 
requirement in a draft with no way to meet it.</jmh>
>     Nits/editorial comments:
>         It would be helpful if section 5.3 (IOAM domains bounded by
>     network
>         devices) restated that such ingress edge devices will
>     encapsulate the user
>         packet, and put the IOAM option in the resulting encapsulating
>     header.  And
>         decapsulate at the egress.
> [SB] The deployment options elaborates this option, it is difficult to 
> summarize that and add it as part of the requirement.
> I would prefer to keep this context in the deployment options section.
> Thanks,
> Shwetha