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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 04 December 2019 16:51 UTC

Return-Path: <ietf@kuehlewind.net>
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 233451208A9; Wed, 4 Dec 2019 08:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 2qQ4C0E4gPM4; Wed, 4 Dec 2019 08:51:43 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 75DAE1208AB; Wed, 4 Dec 2019 08:51:43 -0800 (PST)
Received: from 200116b82c1ec200ed608c078ba0c639.dip.versatel-1u1.de ([2001:16b8:2c1e:c200:ed60:8c07:8ba0:c639]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icXsK-0005Un-FH; Wed, 04 Dec 2019 17:51:40 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com>
Date: Wed, 04 Dec 2019 17:51:39 +0100
Cc: "MORTON, ALFRED C (AL)" <acm@research.att.com>, The IESG <iesg@ietf.org>, "ietf@wjcerveny.com" <ietf@wjcerveny.com>, "draft-ietf-ippm-metric-registry@ietf.org" <draft-ietf-ippm-metric-registry@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <248D5A0E-3471-4C1D-8D31-7BF7244AFC7E@kuehlewind.net>
References: <157541264931.4734.14501743204777647352.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA6F05456@njmtexg5.research.att.com> <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575478303;a12c1f56;
X-HE-SMSGID: 1icXsK-0005Un-FH
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/EJrK8F2csVQKhbj5XOzPWI3TOXg>
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:51:45 -0000

Hi Alvaro,

I just added this afternoon a management item to approve the experts for this registry and both experts are authors of draft-ietf-ippm-metric-registry, so I assume we can be sure that they did a review :-) I would think we don’t need any additional process/separate management item here. But we can also do that if that’s better for you…?

@Al: We changed the registration policy recently but didn’t we also talk about making it “Specification required or IETF Review”? Can you remind me of the outcome of that discussion? I guess the goal was to also have the experts to look at the details of the registry even when we publish an RFC, however, it should probably not be the case that the experts can block the registration of an assignment in an RFC, no? Or is this exactly covering the case discussed below where an RFC is published but the metric is not widely deployed yet?

Mirja





> On 4. Dec 2019, at 17:43, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> 
> 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.
> 
>