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

Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 25 March 2021 07:15 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 55C6F3A135E; Thu, 25 Mar 2021 00:15:13 -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-data@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, Al Morton <acm@research.att.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <161665651291.10579.6980620171501754139@ietfa.amsl.com>
Date: Thu, 25 Mar 2021 00:15:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Q1Avafy-w7sZvtg-IBzWEK_DCfM>
Subject: [ippm] Murray Kucherawy's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Mar 2021 07:15:13 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-ioam-data-12: 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/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:


I'd also like to discuss what's going on in Section 8.

Section 8.1, for instance, says that the registry covers 128 code points.  The
first seven entries are given, but it's not explicit that a registration
comprises a code point and (apparently) a name.  It's more typical to include a
template that a new registration needs to include.  You might require a
requested code point number and a name at minimum, but also commonly included
in such a template is a reference to the registering RFC.  If I were to
register a code point here in some later RFC, it would be awfully convenient to
have the registry include a reference to that defining document.  As it stands,
the registry will only ever point to this one.


I support Francesca's DISCUSS position on both points.  In particular on the
second, I wonder why this registry isn't being created following the
provisional/permanent model that has been successful elsewhere, such as with
URI schemes.

"SFC" appears in the glossary in Section 3, but nowhere else in the document.

In Section 8:

   New registries in this group can be created via RFC Required process
   as per [RFC8126].

Is there any other way to get IANA to create a sub-registry?