Re: [Gen-art] [ippm] Genart last call review of draft-ietf-ippm-metric-registry-20

Alissa Cooper <alissa@cooperw.in> Wed, 04 December 2019 18:01 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ECA12085B; Wed, 4 Dec 2019 10:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level:
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=q0+5PdQs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gCWvFuEi
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 quy2V3IDQ-dy; Wed, 4 Dec 2019 10:00:57 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4B31208DD; Wed, 4 Dec 2019 10:00:26 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 903ECBA9; Wed, 4 Dec 2019 13:00:25 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 04 Dec 2019 13:00:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=W 6x17mR0bHeF4OYmUTr9U1efqjm30nXbQBereTGcivc=; b=q0+5PdQsfv1L4QXOV rgXq8coYzllOwdgxT2iVVVinHygaBp6j3R8e2uSBtYh6uLiSWTIwdUMKodo1y0vt 4ppLRivu/Be6MA4/xSiYg9xh10VDFxR5BQ6KnTwXOBgu89M69Ajew6Qon3cSckDm VkY/1RXs3WFY19/R7Sq68/DHi0pa/JiGJYOLIb2Ef/SMYXT5v/Kin4BJVdiRn3Xv ONb1S1xUGrcFbnlBws8Z6A5Wzl5gM/quPMrvK0ki97hphqKLwF7G4dtFvnwaB06X lpBUf9tJZBUUGRUJ/lklPwqWa9muMG1+ymVyi2sRPzt2qPANb15x0IeBM1DUZi58 S/GiA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=W6x17mR0bHeF4OYmUTr9U1efqjm30nXbQBereTGci vc=; b=gCWvFuEioHevVRDGvrfZPp/XVRF0Kp+tuwLWi89kgVwdPk2viRjuhlVNn pGD3IzhqXUCBBqS8pgpm1RBrKwsiH+VbdriZAUv+3zb4ph3+5ws+DaZWdE6okTMv MRsLcUALmUwtrx8kY4VncadDLEWNq2L3is7koySS6+lU8FLSXjFCyKNmreET/jdA 3HmsNQmziTxk3eLMjxOXO5P4MJ6AvE7M0X/0ma6OL79sjulVD9zgqGnGi+NFjUBY 9L+WoMSk9BGX3dOr0kuIFVax20MSAxEXC7rwE1cOqM3cM18TOcFAex2OiblvinHb miMZMyYb1Jgy6JW6wxz/rK+jgCeRw==
X-ME-Sender: <xms:OPTnXTVjDfqQzKPxmGbz3OFAHpAatKIQ6QwIHEHOz2cEjWK6qaOuoQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejledguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghdpphhrohhofhhpohhinhhtrdgtohhmnecukfhppedutdek rdehuddruddtuddrleeknecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestg hoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:OPTnXXZa0_gzKlJJk1xDSfGNLOCkD2DhKCPeaXzAs-dEIpmrJyIicw> <xmx:OPTnXWu26MjH1XyXV6Iog38fsybFLHBfhr_CEZMLWKmFOfOfRJxTbA> <xmx:OPTnXRmxKJF9SRc-4R8L_TnskTd4iCWMfifPv97smZ7Q9cRvbcuevw> <xmx:OfTnXRc6zPQlX9n-qEC5Jn7-16xkY0FglOYMSEnwzy8Av_CYprDTxg>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E717306010D; Wed, 4 Dec 2019 13:00:24 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <49AA5775-24F1-4BC1-AA5B-DB1EA9B863E1@kuehlewind.net>
Date: Wed, 4 Dec 2019 13:00:23 -0500
Cc: "Roni Even (A)" <roni.even@huawei.com>, "MORTON, ALFRED C (AL)" <acm@research.att.com>, Roni Even <ron.even.tlv@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "draft-ietf-ippm-metric-registry.all@ietf.org" <draft-ietf-ippm-metric-registry.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB75F33F-0DFF-4330-A7E0-F38603FCF866@cooperw.in>
References: <157233748615.6543.10822415025321392095@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA0B694BE@njmtexg5.research.att.com> <6E58094ECC8D8344914996DAD28F1CCD23D9EA85@dggemm526-mbx.china.huawei.com> <0FFC4378-9B11-4641-9544-4F960DDC624E@cooperw.in> <49AA5775-24F1-4BC1-AA5B-DB1EA9B863E1@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/h26x91F-y8zbVnkOpoDQM2op6Wk>
Subject: Re: [Gen-art] [ippm] Genart last call review of draft-ietf-ippm-metric-registry-20
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 18:01:00 -0000

Hi Mirja,

> On Dec 4, 2019, at 11:35 AM, Mirja Kuehlewind <ietf@kuehlewind.net>; wrote:
> 
> Hi Alissa,
> 
> Section 10.1 say:
> 
> Registration Procedure: Specification Required
> 
> What else do you think is needed?

What I put in my ballot:

"I'm confused about what the registration policy is for metrics in the new registry. If it is Specification Required, then the places in the document that assume new metrics are defined in an RFC need to be generalized, because Specification Required need not involve any RFC at all.”

Best,
Alissa

> 
> Mirja
> 
> 
> 
>> On 4. Dec 2019, at 17:15, Alissa Cooper <alissa@cooperw.in>; wrote:
>> 
>> Roni, thanks for your review. Al, thanks for your response. I entered a DISCUSS ballot to get the registration policy clarified.
>> 
>> Alissa
>> 
>> 
>>> On Nov 1, 2019, at 11:54 AM, Roni Even (A) <roni.even@huawei.com>; wrote:
>>> 
>>> Hi Al,
>>> I saw that IANA was consulted during the work.
>>> I was wondering what will be the actual text that will be written in the IANA registry, I expected section 10 to describe it.
>>> 
>>> Registration Procedure(s)
>>> Reference
>>> Note
>>> 
>>> I am not sure yet what is the Registration Procedure and what will be written in the Note
>>> 
>>> Thanks
>>> Roni
>>> 
>>> -----Original Message-----
>>> From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
>>> Sent: Thursday, October 31, 2019 11:52 PM
>>> To: Roni Even; gen-art@ietf.org
>>> Cc: last-call@ietf.org; draft-ietf-ippm-metric-registry.all@ietf.org; ippm@ietf.org
>>> Subject: Re: [Gen-art] Genart last call review of draft-ietf-ippm-metric-registry-20
>>> 
>>> Hi Roni,
>>> thanks for your comments, please see replies below.
>>> Al
>>> 
>>>> -----Original Message-----
>>>> From: Roni Even via Datatracker [mailto:noreply@ietf.org]
>>>> Sent: Tuesday, October 29, 2019 4:25 AM
>>>> To: gen-art@ietf.org
>>>> Cc: last-call@ietf.org; ippm@ietf.org; draft-ietf-ippm-metric- 
>>>> registry.all@ietf.org
>>>> Subject: Genart last call review of draft-ietf-ippm-metric-registry-20
>>>> 
>>>> Reviewer: Roni Even
>>>> Review result: Almost Ready
>>>> 
>>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>>>> the IESG for the IETF Chair.  Please treat these comments just like 
>>>> any other last call comments.
>>>> 
>>>> For more information, please see the FAQ at
>>>> 
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-
>>>> 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=LFYZ-
>>>> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=mLefZkw5Y_ld2AFv2msgpzOV5
>>>> Z7lZ JkKTdUQf48X15g&s=uUg9ktSDILsslqK-rG4YIc3gMW0n6oCa-7Dk0xtFZRo&e=>.
>>>> 
>>>> Document: draft-ietf-ippm-metric-registry-??
>>>> Reviewer: Roni Even
>>>> Review Date: 2019-10-29
>>>> IETF LC End Date: 2019-11-06
>>>> IESG Telechat date: Not scheduled for a telechat
>>>> 
>>>> Summary:
>>>> The document is almost ready for publication as a BCP document
>>>> 
>>>> Major issues:
>>>> 
>>>> Minor issues:
>>>> 1. From reading the document it looks to me that the registration 
>>>> policy should be specification required which also requires expert review.
>>> [acm]
>>> I understand that perspective. In early review with IANA we decided on Expert Review partly because two elements of registry entries require references to immutable documents, such as standards specifications.
>>> So the requirement for specifications could be seen as built-in.
>>> But we may change to Specification Required now, the last IANA review is in-progress. 
>>> 
>>>> 2. My understanding is that for registration a document is required , 
>>>> not necessarily and RFC, but in multiple places in the document ( 7.3, 
>>>> 7.3.1, 8.2 ,...) the text talks about RFC and not document.
>>> [acm]
>>> Yes, a few of those slipped through, thanks.
>>> 
>>>> 3. I am not sure if section 6 is needed in the published document based on its content. 
>>> [acm]
>>> it's fairly easy for new implementers to pick-up an IPPM RFC (even a STD) and choose parameters that meet their needs. But for the additional advantage of measurement comparisons, more context is needed. Some may even ask why this registry requires the many details. Answer: See section 6.
>>> A little history is good. Very few have been joining IPPM sessions long enough to know this history.
>>> 
>>>> If it will remain then in 6.1
>>>> first paragraph the reference should be to section 5 and not to section 6.
>>> [acm] ok
>>> 
>>>> 4.
>>>> In sections 10.2 and 10.3 there are guidance taken from this document. 
>>>> I think that the for IANA it should say in the registry note that the 
>>>> registration must comply with RFCXXX (this document), I assume that 
>>>> there is no need to repeat all this text in these sections in the registry note.
>>> [acm]
>>> I have said on a few occasions that almost the entire memo contains IANA Considerations. Nevertheless, we wrote and reviewed the memo and (then wrote) the separate IANA section with IANA's help.
>>> 
>>> I have implemented the agreed changes above in the working version.
>>> Thanks again!
>>> 
>>>> 
>>>> Nits/editorial comments:
>>>> 
>>> 
>>> _______________________________________________
>>> Gen-art mailing list
>>> Gen-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art
>>> 
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ippm
>> 
>> 
>