Re: [ippm] AD review of draft-ietf-ippm-metric-registry-19

Mirja Kuehlewind <ietf@kuehlewind.net> Tue, 27 August 2019 14:02 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 ED68B12011B; Tue, 27 Aug 2019 07:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 D14TCRbYLkzx; Tue, 27 Aug 2019 07:02:07 -0700 (PDT)
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 96CF9120047; Tue, 27 Aug 2019 07:02:07 -0700 (PDT)
Received: from [129.192.10.3] (helo=[10.149.1.52]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1i2c2u-000389-K7; Tue, 27 Aug 2019 16:02:04 +0200
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: <ACCC5C70-ECA1-47E3-9DBB-22E6F40DE3A7@kuehlewind.net>
Date: Tue, 27 Aug 2019 16:02:03 +0200
Cc: IETF IPPM WG <ippm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A249CFE9-1F5C-4423-95AE-048D9DC01104@kuehlewind.net>
References: <ACCC5C70-ECA1-47E3-9DBB-22E6F40DE3A7@kuehlewind.net>
To: draft-ietf-ippm-metric-registry.all@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566914527;88349336;
X-HE-SMSGID: 1i2c2u-000389-K7
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/dS-leEnzqpH4TslFXgsiP0zCBuY>
Subject: Re: [ippm] AD review of draft-ietf-ippm-metric-registry-19
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: Tue, 27 Aug 2019 14:02:10 -0000

Hi again,

Sorry one more thing on references: There are two normative reference to obsoleted RFC (RFC2141 and RFC4148). I think it would be more appropriate to make these references informational instead. Also there is a new Downref to RFC6248, however, I think that could also be an informational reference instead.

@Bill: as the document shepherd it would be could to point out these things in the shepherd write-up. If the authors/group decides to move these references to informational, there is no additional action require from you. However, if not, the write-up should be updated accordingly.

Thanks!
Mirja


> On 27. Aug 2019, at 15:43, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Hi all,
> 
> I just reviewed draft-ietf-ippm-metric-registry-19. Thanks for the well-written document! I have one process question on the following part before we can move ahead:
> 
> Sec 8.1:
>  "Submission to IANA MAY be the result of IETF Standards Action, where
>   an approved Internet Draft proposes one or more Registered
>   Performance Metrics to be added to the Performance Metrics Registry,
>   including the text of the proposed Registered Performance Metric(s).”
> 
> Maybe I’m confused but I would think that as soon as a document is approved by the IESG, it’s too late for an Expert review because an approved RFC that contains instruction for IANA will usually be implemented by IANA as approved. I believe what we usually do is to request the new entry before IESG evaluation and simply document in the RFC that an registration was performed, or in case of e.g. the port registry (where however the policy is IETF Review for system ports) we ask the experts for review during the IESG evaluation process and take this as input for the IESG to make a decision on approval (rather than as input for IANA). I’m cc’ing Michelle, as I understood that she was already involved in reviewing this document, and she might have further insights/considerations.
> 
> Also on experts: Did the group/chairs/authors already consider possible candidates? If not, is anybody of the author team willing to serve? I assume having 2 experts should be sufficient, right?
> 
> Thanks!
> Mirja
> 
> P.S.: Two nits:
> - sec 7.3.2: "The packet generation stream may require parameters such as the the average packet rate …” -> two “the”
> - sec 8.2: "why the existing entry shuold be revised” -> s/shuold/should/