[ippm] Murray Kucherawy's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 30 June 2022 07:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F20C14F74D; Thu, 30 Jun 2022 00:11:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-ioam-direct-export@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.5.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <165657306062.26144.16837954623699588649@ietfa.amsl.com>
Date: Thu, 30 Jun 2022 00:11:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/3K1h4uJW5rAUIXVDo4iE1UFY48E>
Subject: [ippm] Murray Kucherawy's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 30 Jun 2022 07:11:00 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-ioam-direct-export-09: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


In Section 3.2, there's this field definition:

   Reserved        This field SHOULD be ignored by the receiver.

I'm worried about interoperability here.  "SHOULD" allows a choice.  As
written, I would be within the protocol if I decided to interpret this field,
even if the other participants put junk here.  Wouldn't it be better to say
this is a "MUST", or require that it be all zero bits (at least in this
version)?  If you really think this needs to be a "SHOULD", I suggest
explaining the choice that's being made available to an implementer here.


Thank you to the Working Group for tackling the issue of the author count.  I
know those conversations can be quite un-fun.

I concur with John that the references to RFCs 7014 and 5475 should be

Section 4.1 needs a bit of work.  It claims that Section 7.2 of RFC9197 created
to the "IOAM Type Registry", but it's actually the "IOAM Trace-Type Registry",
yet you appear to want to register stuff in the "IOAM Option-Type Registry"
which would be Section 7.1 of RFC 9197.  Please clarify.  Also, both of those
registries require that the "Reference" column be specified explicitly, even
though it's fairly obvious what it's going to be.