[ippm] Alissa Cooper's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and COMMENT)

Alissa Cooper via Datatracker <noreply@ietf.org> Wed, 04 December 2019 16:12 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 CFC13120019; Wed, 4 Dec 2019 08:12:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-metric-registry@ietf.org, ippm-chairs@ietf.org, ietf@wjcerveny.com, ippm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <157547593284.11031.16357043489918915873.idtracker@ietfa.amsl.com>
Date: Wed, 04 Dec 2019 08:12:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Q8eep8yF98ifckvtv6-MCCMMDu0>
Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-metric-registry-22: (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: Wed, 04 Dec 2019 16:12:13 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-ippm-metric-registry-22: 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:
https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Alvaro's DISCUSS point #2. I'm confused about what the registration
policy is for metrics in the new registry. If it is Specification Required,
then the places in the document that assume new metrics are defined in an RFC
need to be generalized, because Specification Required need not involve any RFC
at all.

I have an additional concern about this text:

"If the proposed registry entry is defined in an RFC but is not yet
   widely deployed, there SHOULD be a statement in the RFC that says the
   proposed registry entry is not ready for registration, and use SHOULD
   employ a private/experimental ID.  It is the responsibility of the
   document authors to submit the request to IANA when the proposed
   registry entry is ready for official registration."

This appears to put a requirement on RFCs to include language that is not
timeless and may later become out of date. That is, if this guidance is
followed but a metric is later widely deployed, the RFC would have to be
updated just to remove the text about the metric not being ready for
registration. It seems better to just give guidance about which identifier
range registration requests should target, and to give guidance to the
designated experts about how to evaluate requests in different ranges.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1:

"any other organization that wishes to create a Performance Metrics Registry"

It seems like performance metrics registry should not be capitalized here since
the next section defines the capitalized version as the one maintained by IANA.

Section 6:

I would strongly recommend that this section be moved to an appendix. Some
readers may find it useful, but it doesn't seem like it belongs in the body of
the document.

Also, I would caution against a section heading entitled "Why this Attempt Will
Succeed." I certainly hope it will, but the future is hard to predict and the
IETF has a long history of being wrong about what will and will not succeed.