Re: [ippm] Erik Kline's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Sun, 23 May 2021 06:34 UTC

Return-Path: <tal.mizrahi.phd@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 8D0953A2FF2; Sat, 22 May 2021 23:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS_IbC2dBvtS; Sat, 22 May 2021 23:34:04 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11383A3007; Sat, 22 May 2021 23:34:03 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id x7so5473326wrt.12; Sat, 22 May 2021 23:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CWtMOPZZIFwUcOt6vxwOdqBuVsjiKdoFetHXg0c7s8Y=; b=aURQOH8cdzOb6iD4beYD5cs7ieG0coxZCXE1TyEfhaogzRLHYttjLTzVEbn5cNG1Fr zyWbnDCHJB15E0int8uoLFimebWD9IzIloHqvIv+QE49yR06PtcAw0OMpURuIej2Q/Y+ j3tF8lv0sg2lkDo5aGF3jyO3ZpkacbsjgGJ94K5GGR90Cod2OdA/xctANUPDYGeTV+sY CvmkmIy2rdXCJbI3+Z9Bp9qO1bC2NOlNXyF71q5WWM4e94pvsbVBIqS3gWPIMFdJUooi q+8Pfx+tdHM0eFfvBzAjM7NlSDpc6zwYJ0CSpKQybA5DLz1kCfpDVJg5BlT6D0wnga4n uyHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CWtMOPZZIFwUcOt6vxwOdqBuVsjiKdoFetHXg0c7s8Y=; b=PR4ko399deDn7W/k+1b86B82ciG4y4Rr++v3y+l5j+qvI72T9E8wooFJ00kZ+5CHqP QddCioK07Z/ly8jHb+L9El26djYenswN4FsdzqXcgQlpUdWYO1AFVKkuVhF8Fbiq42W4 HNtNKCggoVGEW+/lz79R3vCrjKO29DF36HY9NG/zSR3v1i9khKxfvF8VOLa3QDpN3J+A 7AGYDTrkWKaQ4z4efZrPsOFe00YrtyJVsX4FGp8TRUI3TsyjDuE0+vHResbBjXSFp7d1 U76uZxfC7Q5TiME/S8Ub3sRtHiHScoU8JGZV8jWEPgkmBaUIkBWb8UyyCigKsyUbrXPi eCgw==
X-Gm-Message-State: AOAM531IJg8f1eOqYQTKjlABu+Ugfl7IOSQ1Si2VEz4zi2bKlyrVdOth wjgyXhMZOwdhM/IJR6Ah/AandD+z032IJECvgVM=
X-Google-Smtp-Source: ABdhPJyvxBafIzub/eov84Wpa7WMJxswyi4KzPfMuxcaidLn7xBJ3SJUIdrmRW0cttEV9C5L8X88wR3WvkLmtEfyPuQ=
X-Received: by 2002:adf:d20a:: with SMTP id j10mr16051418wrh.188.1621751640919; Sat, 22 May 2021 23:34:00 -0700 (PDT)
MIME-Version: 1.0
References: <161654925329.29254.3776182308241345045@ietfa.amsl.com>
In-Reply-To: <161654925329.29254.3776182308241345045@ietfa.amsl.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Sun, 23 May 2021 09:33:47 +0300
Message-ID: <CABUE3Xk9jizouSzSW7gqm3B4-hT0q8=9RMemohdVSZk2jPSzBw@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-ioam-data@ietf.org, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Al Morton <acm@research.att.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/qMVodOmNRrR-yZMLDrSXDNpv-XE>
Subject: Re: [ippm] Erik Kline's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 23 May 2021 06:34:09 -0000

Hi Erik,

Thanks for the comments.
We are currently working on an  updated version of the draft.
We propose the following changes based on your comments - please see inline.
Please let us know if there are further comments.



On Wed, Mar 24, 2021 at 3:27 AM Erik Kline via Datatracker
<noreply@ietf.org> wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-ippm-ioam-data-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [ section 5.4 ]
>
> * "deployed in a particular IOAM," -> "deployed in a particular IOAM-Domain,"
>   perhaps
>

Suggested text update:
OLD:
Given that the operator knows which equipment is deployed in
a particular IOAM
NEW:
Given that the operator knows which equipment is deployed in
a particular IOAM domain


> * I think perhaps it should be made clear, especially for the Incremental
>   Trace Option, that dynamic insertion of data might need to be moderated
>   "subject to any protocol constraints of the encapsulating layer", as it
>   were.
>
>
>

Suggested text update:
OLD:
IOAM transit nodes push their node
data to the node data list, decrease the remaining length
available to subsequent nodes and adjust the lengths and possibly
checksums in outer headers.
NEW:
IOAM transit nodes push their node
data to the node data list subject to any protocol constraints of the
encapsulating layer.
They then decrease the remaining length
available to subsequent nodes and adjust the lengths and possibly
checksums in outer headers.


Cheers,
Tal.