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 22:35 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 63D86120046; Wed, 4 Dec 2019 14:35:02 -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 J5jDI9PXwgDE; Wed, 4 Dec 2019 14:35:00 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 95D8712002F; Wed, 4 Dec 2019 14:35:00 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id g206so1498914wme.1; Wed, 04 Dec 2019 14:35:00 -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=KjaeRBQZAewd5PnLfJ2Ly0R+ZxlEklbwQfqlt709xbc=; b=VU9TAZ/LAmUGrq2xYCq++u5UsLr4T0J79baIkMexHM07E3oc36VWPtdf2kPRPFwc5I CdGjPN2MFrUb1sXJAuhAkoAzdSLf88A/oweLXoGTXWSzgeRklO95ZS1Dbd12CoOGofgw 7xsbOYpSwRjWupuRRg4m78xEH/DtuGcLQYj2I5RMjW7oz7oDA3QYB/225cX578KWj+eb T6GxU4H1W+wf5ZC29BEHH7OjBbhMqbfnTmkU0B2C4e3jXsMdS63TJJkUBLkX50KuFvb9 XEm6NM6mt2562REZL8SWBWv8KK/UZd9bMTltMSAsr6rUrk0vc/ldJpkLkiTurZq/YD3s 3ibw==
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=KjaeRBQZAewd5PnLfJ2Ly0R+ZxlEklbwQfqlt709xbc=; b=G2TvNstU+4BYUIvSEUyvHAZAE5rT4evUlahLgULjNmNdCGwCdBtAABKAU3MQLwwRjk AyZnq1S2nBIIkWB+4sNDFrZCAbn8wvCf5b0rHjigYzcvUptJ11sCPlRF35ZPZX6rE/uf RV02MvRWu4tzrMSjVNuC95hMfD3w+7htRV+PvRBNNBdzcPdlZkHOSzvlMjhx3C7B3aRD gkgNLjIN981CZqFCR92spp7rQ82jMUtOjO8GUP14B6Qx0td82sgBBb+mu+Osjrb0J9Ll U5GGepZNdm5jLliJ+nBoA9PGzWGb8uRz3j2uZ34G3TgNbpVPTstjBLCYKxSj/qJjDkFM DlEw==
X-Gm-Message-State: APjAAAVpPQ5XEPJlIIBuwN9iOGelR7uUd3PmD7ulCJR5MNwy0S+AeNcS CGpF2yArE62/AlmtvYc1sXfGjxee5rjPQ05kZY9S5W2l
X-Google-Smtp-Source: APXvYqw+ZyMIpKIAl5xB63e8T57fzE8Lq6+L92MdwNPSGeITEtlVnBrGk7mDfqy3x4OcmPkmbSeKEJYgnQ6LHpY5v+8=
X-Received: by 2002:a05:600c:2150:: with SMTP id v16mr1733489wml.156.1575498899120; Wed, 04 Dec 2019 14:34:59 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Dec 2019 14:34:58 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6F05F66@njmtexg5.research.att.com>
References: <157541264931.4734.14501743204777647352.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA6F05456@njmtexg5.research.att.com> <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA6F05F66@njmtexg5.research.att.com>
MIME-Version: 1.0
Date: Wed, 04 Dec 2019 14:34:58 -0800
Message-ID: <CAMMESsxMUe6zG2svzoLmo3=z54j8nQpWypCx8xaRspb39aWWoQ@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/ng-w5os7TWEeTKnsJ28hvzoU3TQ>
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 22:35:02 -0000

On December 4, 2019 at 1:38:07 PM, MORTON, ALFRED C (AL) wrote:

Al:

> If an RFC-to-be includes a Performance Metric and a proposed Performance
> Metrics Registry entry, but the IANA and Performance Metric Expert review
> determines that one or more of the Section 5 criteria have not been met,
> then the IESG approval process MUST proceed with the proposed Performance
> Metrics Registry entry removed from the text. When the RFC-to-be authors
> are ready to show evidence of meeting the criteria in section 5, they
> SHOULD re-submit the proposed Performance Metrics Registry entry to IANA
> to be evaluated in consultation with the Performance Metric Experts for
> registration at that time.

This text basically says that if the criteria in §5 is not met, then
the specific entry must not be in the RFC.  At some point in the
future (when the §5 criteria is met), publication of the entry can
proceed -- presumably in a different RFC.

As Alissa mentioned in her DISCUSS, the text needs to be generalized
to cover specifications from other SDOs.  I'm not sure how preventing
publication would work there.

The criteria in §5 talks about "industry interest, or has seen
deployment", which makes me think about how early allocation would
work.  If interest/deployment is part of the criteria to be in the
registry, then early allocation "to facilitate desired or required
implementation and deployment experience" [rfc7120] would seem to not
meet the requirement.  Wouldn't it?

Do you (authors/WG) see value in documenting private/experimental
metrics?  I imagine that one way to prove interest/deployment is to
experiment (vs early allocation).  These would not pass the §5 hurdle,
but may need to be documented somehow.  In the IETF the WG could limit
publication to a draft (for example), but in other SDOs an actual
specification could end up being published...

Sorry to add more questions; I just want to make sure all the bases are covered.

Thanks!

Alvaro.