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

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 09 September 2019 08:24 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 84CB01200CC; Mon, 9 Sep 2019 01:24:41 -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 tPvkwX7KAVvX; Mon, 9 Sep 2019 01:24:39 -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 410FA120046; Mon, 9 Sep 2019 01:24:39 -0700 (PDT)
Received: from 200116b82c80fa001919bc0c110520fa.dip.versatel-1u1.de ([2001:16b8:2c80:fa00:1919:bc0c:1105:20fa]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1i7EyR-0001hg-3M; Mon, 09 Sep 2019 10:24:35 +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: <4D7F4AD313D3FC43A053B309F97543CFA0AF4E6B@njmtexg5.research.att.com>
Date: Mon, 9 Sep 2019 10:24:34 +0200
Cc: "draft-ietf-ippm-metric-registry.all@ietf.org" <draft-ietf-ippm-metric-registry.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Michelle Cotton <michelle.cotton@iana.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <045CC4BE-33B3-4485-892C-16CD4141C110@kuehlewind.net>
References: <ACCC5C70-ECA1-47E3-9DBB-22E6F40DE3A7@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CFA0AF4E6B@njmtexg5.research.att.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1568017479;3ab03c00;
X-HE-SMSGID: 1i7EyR-0001hg-3M
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-qn78Nc_gEoUAr9tEzqqHuVYOS0>
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: Mon, 09 Sep 2019 08:24:41 -0000

Hi Al,

Okay to all! About the experts. How should we figure out other experts? Do have people in mind? Should I approach them, do you want too speak to them directly? 

Mirja



> On 8. Sep 2019, at 00:09, MORTON, ALFRED C (AL) <acm@research.att.com> wrote:
> 
> Hi Mirja,
> Catching-up with your comments on the registry draft.
> Please see replies below, and thanks again for your review.
> Al
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
>> Sent: Tuesday, August 27, 2019 9:44 AM
>> To: draft-ietf-ippm-metric-registry.all@ietf.org
>> Cc: IETF IPPM WG <ippm@ietf.org>rg>; Michelle Cotton
>> <michelle.cotton@iana.org>
>> Subject: AD review of draft-ietf-ippm-metric-registry-19
>> 
>> 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.
> [acm] 
> I agree, here's what I changed the working text to read:
> 
> Submission to IANA MAY be during IESG review (leading to IETF 
> Standards Action), where an Internet Draft proposes one or ...
> 
>> 
>> 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?
> [acm] 
> Yes, I assume I'll act as one of the experts, and we'll need a few more 
> who can share the load, especially if a quick response is required.
> 
>> 
>> 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/
> [acm] 
> thanks, fixed.
> 
> Other Questions arose:
> 
> 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.
> 
> [acm]
> I agree, I moved 4148 and 6248 to Info, can't find 2141 in the working text, 
> assume I deleted it with unused references. 
> 
> @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
> 
> 
> Here are your questions for the registry
> that came-up during review of initial contents draft:
> 
>> 
>> And finally one/two/three more general question(s) at the end, that I
>> probably should also have asked already on my review for draft-ietf-ippm-
>> metric-registry:
>> 
>> Is it actually intended that basically all the text in this RFC gets
>> copied into the registry? 
> [acm]
> Sort of. All the text for each metric (section) is a file that the registry
> entry points to. Registry draft section 10.3 says:
> 
> The "URIs" column will have a URL to the full template of each registry entry. The Registry Entry text SHALL be HTML-ized to aid the reader, with links to reference RFCs (similar to the way that Internet Drafts are HTML-ized, the same tool can perform the function).
> 
>> And what is expected to be on the URL page then?
> [acm]
> The URL points to a page = one section of the -ippm-initial-registry draft.
> Future URLs might point to text from a section of an RFC for a new metric.
> 
>> Wouldn’t it be necessary to also define a format for that page in order to
>> be of any use?
> [acm]
> It's the "full template", filled-out for each registered metric.
> 
> It really helps to have the mock-up we worked-out with IANA
> available to see the "running code". I'll send you the mock-up
> in separate mail. We looked at this in several IPPM sessions 
> over the years, and on this one the header is fairly up to date,
> but the URLs point to "old" sections of the initial contents draft.
> Also, the column widths are not ideal in the mock-up.
> 
> It might help to have a live URL to the mocked-up registry
> that we can share with others (when this question comes up again,
> and it will during IESG review, I assure you!).
> 
> Al