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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 04 December 2019 16:43 UTC

Return-Path: <aretana.ietf@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 5F31D120073; Wed, 4 Dec 2019 08:43:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Bm4XVAHzQjhp; Wed, 4 Dec 2019 08:43:37 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 BF892120043; Wed, 4 Dec 2019 08:43:36 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id f4so5254839wmj.1; Wed, 04 Dec 2019 08:43:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=sXgIgFt2GakDC1OhWYdzz+cV4BenOLh+CEZxlPsDWWo=; b=mwtqWXiIW7C1jPAGLYL5zPtN+wnH1m3oVbNGxi8/gnsFh48ugIogr5i9etg5Vl9Wrs AdysvYNzlvX1cLotaj/tmSOW7TvajSZEnjIDMt2euTAqR7qCAed+q4asAghFEl45Uf14 8I7WnCkGerxQPHxboWCZLxmsde1rbU0DyrdFW9Gk8kF/1xFk69GVTjoPdSnjQOVaCEWd cIgLMDMXNCivEAPR93VjubFYCyjWE85Dpwfk8OQqyr8+x0e5LfymNhONSLre7e5x9Pnl wbqBU8GTvcve9NhtCyr7BcRVPdfKhCR4WUetWwmy6IzU5/dpeoRjHYzS8yMUkCrFNEx9 Fh7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=sXgIgFt2GakDC1OhWYdzz+cV4BenOLh+CEZxlPsDWWo=; b=Xk1/L29q/AOT58MoNUyg0juXHWolx2NsdN8XJL/QtOZbSdtXUU6pM7G0q2W5OkMv+Q IPwHxhD4ces3Vff6tiZRiQg4F36sXRODcUZnwnpGqp1dgWPKixWpcuDRQlIr/Od0JTRf 3/+p5fc4HczaxUT7HQB5cutQUr//DLjVeJ17ElNKq8YbDSlEYoypgE6U0aUlnjUC3EdZ jDGLCA3IXLJTSvezpga7ckJGwog86eF789smTUx2pN+pICY3xR7kU3B20GT7NZ69RBGF F9VAoFaQwNNgzfA83ZX9y3hwy/ALHE0Ln6ca8hXyj60O+A3LOjMQFq7QsMqy3HiFOPtF +EGA==
X-Gm-Message-State: APjAAAV44ObeACf4QELNyeHgZ1HxDfqFB4/Wrc1sPBeOLQH0lCwpyczK x4uWtp373bKoKk5dorqIQiKr2D6/rd3TIZd1/UI=
X-Google-Smtp-Source: APXvYqxdzQyiIPVQmHF+LawpDtBHRFQWZuZmOpWw8Vt1GjWIGPvWHErjsXNXFvodwz0YJWWd7agui1s04/77c5HE9yE=
X-Received: by 2002:a1c:7914:: with SMTP id l20mr537163wme.38.1575477815200; Wed, 04 Dec 2019 08:43:35 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Dec 2019 08:43:34 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6F05456@njmtexg5.research.att.com>
References: <157541264931.4734.14501743204777647352.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA6F05456@njmtexg5.research.att.com>
MIME-Version: 1.0
Date: Wed, 04 Dec 2019 08:43:34 -0800
Message-ID: <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, The IESG <iesg@ietf.org>
Cc: "ippm@ietf.org" <ippm@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ietf@wjcerveny.com" <ietf@wjcerveny.com>, "draft-ietf-ippm-metric-registry@ietf.org" <draft-ietf-ippm-metric-registry@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/O31JG-9Va9TOg6_Wuf1ehb3qg1g>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and 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: Wed, 04 Dec 2019 16:43:38 -0000

On December 4, 2019 at 10:31:42 AM, MORTON, ALFRED C (AL) wrote:

Al:

Hi!

For the approval of the initial registry point, I think we'll need
Mirja to comment.

> > -----Original Message-----
> > From: Alvaro Retana via Datatracker [mailto:noreply@ietf.org]
...
> > (2)
> >
> > §8.1 (Adding new Performance Metrics to the Performance Metrics Registry)
> > defines the following process for entries that are "not yet widely
> > deployed":
> >
> > 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.
> >
> > Considering the Specification Required policy and the fact that the RFC has
> > already gone through all the reviews required for publication (including
> > expert review, as mentioned in the same section), how will it work for the
> > "authors to submit the request to IANA when the proposed registry entry is
> > ready for official registration"? What specification will be presented to
> > IANA to satisfy the registration requirement? It seems to me that the
> > statement mentioned above would prevent the official registration in the
> > first place, and that same statement (still present in the RFC) should
> > prevent a second review of the same document from resulting in an official
> > registration.
> >
> > This process needs more discussion and clarity for it to work.
> [acm]
> Yes, I see your point. This a paragraph we added at the IANA desk
> during IETF-106, to resolve a question raised, and it seems we didn't
> read it critically. Let me suggest several revisions as a paragraph
> below:
>
> 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 because it lacks
> deployment (in the IANA Considerations Section), and SHOULD employ a
> private/experimental ID when used in practice. The IANA and Expert
> reviews of the proposed registry entry take place as normally required,
> and registration SHALL be held. When the authors are ready to show
> evidence of widespread deployment, they SHOULD submit the evidence
> to IANA to be evaluated in consultation with the Performance Metric
> Experts for registration at that time.

This new text is not explicit on what "evidence of widespread
deployment", nor whether that would be considered a specification in
line with the registration policy.  It also suffers from the point
that Alissa mentioned in her DISCUSS of leaving the published RFC with
the "old" text saying that the metric is not ready.



Thanks for addressing my other comments.

Alvaro.