Re: [ippm] AD review of draft-ietf-ippm-initial-registry-11

"MORTON, ALFRED C (AL)" <acm@research.att.com> Fri, 30 August 2019 20:20 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 59FC71201E4; Fri, 30 Aug 2019 13:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 0yCGR-SiTP5g; Fri, 30 Aug 2019 13:20:35 -0700 (PDT)
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 7CEDD120108; Fri, 30 Aug 2019 13:20:35 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7UKA4S7032102; Fri, 30 Aug 2019 16:20:30 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049462.ppops.net-00191d01. with ESMTP id 2uqa39s684-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 16:20:30 -0400
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 x7UKKTc6117253; Fri, 30 Aug 2019 15:20:29 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x7UKKN2c117100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 15:20:23 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 167F84068F61; Fri, 30 Aug 2019 20:20:23 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30496.vci.att.com (Service) with ESMTP id E69D44068F60; Fri, 30 Aug 2019 20:20:22 +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 x7UKKM0K008835; Fri, 30 Aug 2019 15:20:22 -0500
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 x7UKKEPl008001; Fri, 30 Aug 2019 15:20:16 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 1C8F6E41F1; Fri, 30 Aug 2019 16:17:55 -0400 (EDT)
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; Fri, 30 Aug 2019 16:20:12 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>, "draft-ietf-ippm-initial-registry.all@ietf.org" <draft-ietf-ippm-initial-registry.all@ietf.org>
CC: IETF IPPM WG <ippm@ietf.org>, Michelle Cotton <michelle.cotton@iana.org>
Thread-Topic: AD review of draft-ietf-ippm-initial-registry-11
Thread-Index: AQHVXO7t1Dc8eia/wEeItN2FmjYM8qcUJFvg
Date: Fri, 30 Aug 2019 20:20:12 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0AF30B4@njmtexg5.research.att.com>
References: <40A0B71C-4857-46F0-9096-6EE289E7404B@kuehlewind.net>
In-Reply-To: <40A0B71C-4857-46F0-9096-6EE289E7404B@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
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:, , definitions=2019-08-30_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908300190
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/vgMp8sABoS1uoV5kGKoG-VeMGck>
Subject: Re: [ippm] AD review of draft-ietf-ippm-initial-registry-11
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: Fri, 30 Aug 2019 20:20:39 -0000

Hi Mirja,

Thanks for reviewing these two memos, 
registry and initial contents. They added a lot
of pages to your review load.

I don't recollect a list discussion on 
whether PS or Info, but years ago we decided
that all metric RFCs would go on the Standards Track,
and devised ways to evaluate whether they should 
advance based on testing and ultimately 
revised text. So, it seemed natural to make these
"tighter specifications of the original metrics"
PS, and that's been the status since 00.

With this background, I'm interested to learn why
Informational seems the right choice to you,
and we should all think about the implications 
of Info or PS for the metrics in this 
draft-*-initial-registry.

regards,
Al

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Sent: Tuesday, August 27, 2019 11:47 AM
> To: draft-ietf-ippm-initial-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-initial-registry-11
> 
> Hi authors, hi all,
> 
> We need to discuss at least one bigger question on the intended status
> before we  can move ahead. However, as you can seen I have more
> questions/comments below.
> 
> The bigger status question first:
> The intended status is PS. The shepherd write-up does not provide any
> additional information about why this status is appropriate. I would
> assume that informational is actually more appropriate. I don’t recall out
> of my head if/when this was discussed and I thought I rather ask than
> searching the list archive and minutes… Is this the right status and why?
> And if so, please reflect in the write-up!
> 
> 
> And then a couple more (hopefully) quicker comments/questions:
> 
> - I know this was already reviewed by IANA (Michelle is also cc’ed),
> however, as far as I can see all Administrative Information (Status,
> Requestor, Revision, and Revision Date) and maybe even the ID don’t need
> to be part of the template because IANA will anyway assign them based on
> the instructions given in draft-ietf-ippm-metric-registry. Or did IANA
> explicitly request to also include these parts?
> 
> - Then for the Change Controller that should usually be the IESG rather
> than the IETF. Did IANA comment on that?
> 
> - And one minor point: I guess the secY part of the name could already be
> filled out, no? However, I should probably have asked that on review of
> draft-ietf-ippm-metric-registry already but I was actually wondering if
> the decision to include the RFC number and section in the metric name is
> appropriate. Can you maybe lay out what the reasons for this are (and
> maybe also explain in the draft as his might come up again during IESG
> review otherwise)…?
> 
> 
> Then then on references again:
> 
> - This draft references two obsoleted RFCs (RFC2679 and RFC2680). I assume
> this is an oversight and the references need to be updated?
> 
> - Also given you rely heavily on [Trammell-14], I think this needs to be a
> normative reference (and maybe [Strowes] as well?). The more stable
> pointer for [Trammell-14] is actually here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__link.springer.com_chapter_10.1007_978-2D3-2D642-2D54999-2D1-
> 5F2&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=hwJZg-
> IdxQ9507aw2mjEKKOSWIEVnc8nwr7B_QiOyCU&s=HSEAeC_uI-vofX5ZWPSCH-R4Ph8Gu618-
> YtZJ4pTAgE&e=
> But to be honest the split between normative and informational isn’t
> actually very clear to me here…?
> 
> 
> And on the shepherd write-up:
> 
> It’s indicated that not all authors have replied to the IPR question. This
> need to be checked and respectively reflected in the shepherd write-up
> before we can move ahead!
> 
> 
> And some smaller technical questions/nits:
> 
> - Is it correct that T0 in section 4 is defined in both subsections 4.3.5
> and 4.4.2?
> 
> - Why is an URI given (only) in section 6.1.3?
>   Also section 7.1.3 and 8.1.3.: http:\\www.iana.org\ ... <name> -> I
> think this should be: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.iana.org_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=hwJZg-
> IdxQ9507aw2mjEKKOSWIEVnc8nwr7B_QiOyCU&s=9PuQd07oTFlEt8tWIDYz4c-
> qFUd4zpyT_7QeckyeAsc&e=<name>/
> 
> 
> Some more editorial comments/nits:
> 
> - I find it actually unnecessary or rather confusing that most (not all)
> sections start with a sentence/paragraph explaining what the section is
> about (e.g. "Additional (Informational) details for this entry”). I would
> think this is sufficiently explained in draft-ietf-ippm-metric-registry
> and does not need to be repeated here (in this already long document).
> Also note that section 8.6 inconsistently doesn’t have any content while
> 10.6. says “None.”.
> 
> - Also these comments in section 7 and 8 are probably supposed to be
> removed:
> " <insert name of the output type, raw or a selected summary statistic>”
> …?
> 
> - I found this in section 10.2.2: "@@@@@ others??”. I guess there is
> something missing? Also in this part, I don’t think SYN and FIN should be
> set at the same time, no? And rather than providing the Kind and Length of
> the TSopt, I would recommend to provide a pointer to the respective RFC.
> 
> 
> 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? And what is expected to be on the URL page then?
> Wouldn’t it be necessary to also define a format for that page in order to
> be of any use?
> 
> 
> Mirja
> 
> 
> 
>