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

Alvaro Retana <aretana.ietf@gmail.com> Thu, 05 December 2019 17:59 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 962DA120837; Thu, 5 Dec 2019 09:59:57 -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 orLc5bwBduXv; Thu, 5 Dec 2019 09:59:55 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 C1AAB12082F; Thu, 5 Dec 2019 09:59:48 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id e10so3450269edv.9; Thu, 05 Dec 2019 09:59:48 -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=qvh52aCLEpf30/Mf2qCxQyTSGogyPfKfLy6DB4sNqK4=; b=d/FlnOy3hPsl0sLTIDK/r2n4iEdn3Uzlm6wozP68xT5WYOrB8w5pe6WEp7C4GV+pBM KD9fhsbWC1Z/uWELPfI7N6iozUzmOrxtvFbEyeWIGOvgPWCayTJCmsISNgQQDuAfmV1+ F1OaoL4hS6r0NEeljvRLRqZ+y/w2yTfoBOevGqbj21RY+mlywaenRDvr/yKp9Xlsg8Vv /KOvCqWTZGlMNCMge3JAwnqVNOVRx2OnQzGElFD+R4SKplNqR1SQ6Ts4GyMT2wCEYYi6 sHPm4GjhaFZOzAHTrVSD8RWa7yKHzL3Q1uxIb0yjn5bLZtAlncy+Qlemt1s0r4vNd/aG iXww==
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=qvh52aCLEpf30/Mf2qCxQyTSGogyPfKfLy6DB4sNqK4=; b=ht0IH8ihcMjRTB20sK/WF1p8h/0LSq5trejBoKCxGMuBov9zlscumrHy/rfF/v8s3C YnAPm66GQmj1bRVQdnb+Xz/NxY+cGvUleGj+t0OpEw/plM5V3VMTNGCWn7qxBYL3aelh yfbVZvXntygP0NjjXaDNtMPvnsDHkBeGqmyH2KC2lIghxF2h7V004iMXIxufzmpBfqmW TH9lOCauW9MA0X0INi61y1B6WkYK1h5AovUGVFGoACOCUHfUdvQUjclQ1M+iDR4jH8CL uQ1ISprxPjR+A6QzG9e+52ikhMnz2nkuqdBq+p/yUYItGxhBLdpcfdSjz6yoJbQJrwCX YWwg==
X-Gm-Message-State: APjAAAUzK+ICSihspG3MURmR2awmZ4SyEk3gC6jteABC8uVe67ejx0gq VAqBaQ6Dv+CcgXjDJq7tlXBIaLPS78Ej+KGimIX+zZ9/
X-Google-Smtp-Source: APXvYqyC9wnmmtzYjYUjCMk7jYD7jdYq7Ikb7tC9f2XyxYctTeY95wz58UYWNqoxDtPkHeeTJoeJtyHz2nrDGtzznck=
X-Received: by 2002:a05:6402:298:: with SMTP id l24mr11923798edv.70.1575568787335; Thu, 05 Dec 2019 09:59:47 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2019 09:59:46 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6F0657C@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> <CAMMESsxMUe6zG2svzoLmo3=z54j8nQpWypCx8xaRspb39aWWoQ@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA6F0657C@njmtexg5.research.att.com>
MIME-Version: 1.0
Date: Thu, 05 Dec 2019 09:59:46 -0800
Message-ID: <CAMMESszoaP5ojm30ukfbKw-2-eKJmbijB5EjSLSGW15UNTsctw@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/RSkC4XO5fsr4iy0x9hSHMc9RDZg>
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: Thu, 05 Dec 2019 17:59:58 -0000

On December 5, 2019 at 7:30:22 AM, MORTON, ALFRED C (AL) wrote:

Al:

Hi!


> > -----Original Message-----
> > From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
...
> > On December 4, 2019 at 1:38:07 PM, MORTON, ALFRED C (AL) wrote:
...
> > > 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.
> [acm]
> Yes.
> >
> > 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.
> [acm]
> It doesn't apply to other SDOs.
> There are process points that only apply to IETF and RFCs-to-be,
> such as the one we are discussing.
> IANA can receive a request from other SDOs directly, and
> we cover those cases separately. IWO, we do not generalize
> every instance of RFC to "spec", because IANA review
> coincides with IIESG review.

Your answer made go look at §8.1 again and the paragraph we're
discussing in context.  Just one suggestion: s/then the IESG approval
process MUST proceed with the proposed Performance Metrics Registry
entry removed from the text./then the proposed Performance Metrics
Registry entry MUST be removed from the text.

I trust that this text will make it into your next update, so I'm
clearing my DISCUSS.

Thanks!

Alvaro.