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

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sat, 07 September 2019 21:37 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 191B7120164; Sat, 7 Sep 2019 14:37:28 -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 b513gihmghJe; Sat, 7 Sep 2019 14:37:25 -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 336AE120145; Sat, 7 Sep 2019 14:37:25 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x87LZYlk027284; Sat, 7 Sep 2019 17:37:03 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0083689.ppops.net-00191d01. with ESMTP id 2uvf20xe1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Sep 2019 17:37:02 -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 x87Lb0nB080562; Sat, 7 Sep 2019 16:37:01 -0500
Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x87LaqiY080467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Sep 2019 16:36:52 -0500
Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id B82D84119BB6; Sat, 7 Sep 2019 21:36:52 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id 91EC540002D8; Sat, 7 Sep 2019 21:36:52 +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 x87LaqqV005699; Sat, 7 Sep 2019 16:36:52 -0500
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x87Lamju005439; Sat, 7 Sep 2019 16:36:48 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id D8140E5900; Sat, 7 Sep 2019 17:36:00 -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; Sat, 7 Sep 2019 17:36:44 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Mirja Kuehlewind <ietf@kuehlewind.net>
CC: Michelle Cotton <michelle.cotton@iana.org>, "draft-ietf-ippm-initial-registry.all@ietf.org" <draft-ietf-ippm-initial-registry.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] AD review of draft-ietf-ippm-initial-registry-11
Thread-Index: AQHVXO7t1Dc8eia/wEeItN2FmjYM8qcUJFvggARoOoCAAEL6AIAH/iGA
Date: Sat, 7 Sep 2019 21:36:43 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0AF4E49@njmtexg5.research.att.com>
References: <40A0B71C-4857-46F0-9096-6EE289E7404B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CFA0AF30B4@njmtexg5.research.att.com> <EE050F4D-61C8-4BE6-8116-BD4A2E208067@kuehlewind.net> <2292EEC5-9924-496C-82C2-85D896620807@trammell.ch>
In-Reply-To: <2292EEC5-9924-496C-82C2-85D896620807@trammell.ch>
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-09-07_09:, , 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-1909070234
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/KdiYYoSCQhLkkrmmyp_8fZy4pRA>
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: Sat, 07 Sep 2019 21:37:28 -0000

Let me add that there are ~two "private" implementations of the 
registry, BBF's and another in Brazil. Also, BEREC uses
LMAP requirements for their selected system.

Al

> -----Original Message-----
> From: Brian Trammell (IETF) [mailto:ietf@trammell.ch]
> Sent: Monday, September 2, 2019 11:29 AM
> To: Mirja Kuehlewind <ietf@kuehlewind.net>
> Cc: MORTON, ALFRED C (AL) <acm@research.att.com>om>; Michelle Cotton
> <michelle.cotton@iana.org>rg>; draft-ietf-ippm-initial-registry.all@ietf.org;
> IETF IPPM WG <ippm@ietf.org>
> Subject: Re: [ippm] AD review of draft-ietf-ippm-initial-registry-11
> 
> hi Mirja,
> 
> IIRC there was also an intent to have initial-registry on the standards
> track as it was initially intended (in part) as input to the LMAP WG
> before they changed direction (and closed), and initial-registry was to
> form the basis of the (standard) metrics LMAP would select among.
> 
> Cheers,
> 
> Brian
> 
> > On 2 Sep 2019, at 13:29, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> >
> > Hi Al,
> >
> > Thanks for the background info. Sorry, I should have explained myself
> better. However, I don’t have a strong opinion on which status we end up
> with but I would really like to make sure that the intended status is well
> explained in the shepherd write-up in order to provided the other ADs the
> needed background information during IESG review.
> >
> > My think was that this document does actually not specify any new metric
> and as the registry only requires “Expert Review”, informational felt more
> natural for me. However, this is for the working group to decide!
> >
> > Mirja
> >
> >
> >
> >> On 30. Aug 2019, at 22:20, MORTON, ALFRED C (AL) <acm@research.att.com>
> wrote:
> >>
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=zRoRqOY3c3gTB3VWWod8whONKOcJ4
> s5Ms5K83keHX44&s=5gzZa0AU5NM5neW3qFk2YA63T7Bq5mGppDa-qvqEIpI&e=
> >