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

"MORTON, ALFRED C (AL)" <acm@research.att.com> Thu, 05 December 2019 14:04 UTC

Return-Path: <acm@research.att.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 886CE12004A; Thu, 5 Dec 2019 06:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 VK4V61HdQY-H; Thu, 5 Dec 2019 06:04:49 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB0B1200C4; Thu, 5 Dec 2019 06:04:49 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xB5DuYQg035533; Thu, 5 Dec 2019 09:04:39 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 2wq21s9r3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Dec 2019 09:04:39 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xB5E4a6d067411; Thu, 5 Dec 2019 08:04:37 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xB5E4WqQ067263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2019 08:04:32 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 12D7D4009E89; Thu, 5 Dec 2019 14:04:32 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id E00B54009E86; Thu, 5 Dec 2019 14:04:31 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xB5E4Vg0026515; Thu, 5 Dec 2019 08:04:31 -0600
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xB5E4Qsh026169; Thu, 5 Dec 2019 08:04:26 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 0A25AE375D; Thu, 5 Dec 2019 09:00:31 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:04:26 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "Roni Even (A)" <roni.even@huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
CC: "ippm@ietf.org" <ippm@ietf.org>, "draft-ietf-ippm-metric-registry.all@ietf.org" <draft-ietf-ippm-metric-registry.all@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [ippm] Genart last call review of draft-ietf-ippm-metric-registry-20
Thread-Index: AQHVjjJgXeYSPBPTtkuJ+V4uG/Gmf6d1PmYAgAE9RpCANDfXgIAABXQAgAAX24CAAO8tgIAADGWQ
Date: Thu, 05 Dec 2019 14:04:25 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F0673A@njmtexg5.research.att.com>
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> <CB75F33F-0DFF-4330-A7E0-F38603FCF866@cooperw.in> <6E58094ECC8D8344914996DAD28F1CCD27D24DB5@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD27D24DB5@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [156.106.224.128]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-05_03:2019-12-04,2019-12-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912050116
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Zv3KmJLFG4HS61BaeH4oH6zfVlg>
Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-metric-registry-20
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 14:04:52 -0000

Hi Roni,

Please keep in mind that this is not a global replacement
for RFC -> Specification.

Some steps in the process apply only to IESG review
with IANA review. Others apply more broadly and we 
only need to change those.

Please help by making your recommendation for 
changes keeping in mind those two categories.

thanks,
Al

> -----Original Message-----
> From: Roni Even (A) [mailto:roni.even@huawei.com]
> Sent: Thursday, December 5, 2019 3:16 AM
> To: gen-art@ietf.org; last-call@ietf.org; MORTON, ALFRED C (AL)
> <acm@research.att.com>
> Cc: ippm@ietf.org; draft-ietf-ippm-metric-registry.all@ietf.org; Mirja
> Kuehlewind <ietf@kuehlewind.net>; Alissa Cooper <alissa@cooperw.in>
> Subject: RE: [ippm] Genart last call review of draft-ietf-ippm-metric-
> registry-20
> 
> Hi,
> I think that Al addressed most of them, noted the following are still not
> clear
> 
> Section 3 bullet 1 has RFC
> Section 7.1.2  for "spec:" talks about RFC, should be more general say if
> the specification is RFC then ...
> Section 7.1.2 talks only about RFC
> Section 7.1.3
> Section 7.1.7
> Section 7.2 (In 7.2.1 talks about immutable document)
> Section 7.3.1 end of the first paragraph
> Section 8.1 first paragraph and third paragraph
> Section 11.2
> Section 11.3
> Section 11.5.2  what is the requestor is it a document or person?
> 
> 
> New comment:
> 
> In section 10.3 can the reference be a contact person since the policy is
> specification required
> 
> Roni Even
> 
> 
> 
> 
> > -----Original Message-----
> > From: Alissa Cooper [mailto:alissa@cooperw.in]
> > Sent: Wednesday, December 04, 2019 8:00 PM
> > To: Mirja Kuehlewind
> > Cc: Roni Even (A); MORTON, ALFRED C (AL); Roni Even; gen-art@ietf.org;
> last-
> > call@ietf.org; ippm@ietf.org; draft-ietf-ippm-metric-
> registry.all@ietf.org
> > Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-metric-
> registry-
> > 20
> >
> > 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_ld2AFv2
> > msgpz
> > >>>> OV5 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_gen-2Dart&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=gzuad-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=vQLx27IlYqGWfgVPigggpoWFfBJX5TJxz8oU
> Pu2NQp0&e=
> > >>>
> > >>> _______________________________________________
> > >>> ippm mailing list
> > >>> ippm@ietf.org
> > >>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=gzuad-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=HKT1QAvRtO4211JXIR5edFGw5AS6H94f4tFm
> saAwWRQ&e=
> > >>
> > >>
> > >