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

"MORTON, ALFRED C (AL)" <> Sat, 07 September 2019 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B996E1201C6; Sat, 7 Sep 2019 15:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EK7Smnq8GGqg; Sat, 7 Sep 2019 15:10:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A5B112018D; Sat, 7 Sep 2019 15:10:02 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x87M5Ogb041775; Sat, 7 Sep 2019 18:09:37 -0400
Received: from ( []) by with ESMTP id 2uvdr40reu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Sep 2019 18:09:37 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id x87M9amF125320; Sat, 7 Sep 2019 17:09:36 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id x87M9Xps125261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Sep 2019 17:09:33 -0500
Received: from ( []) by (Service) with ESMTP id B0DA84005C39; Sat, 7 Sep 2019 22:09:33 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTP id 8EAF94005C2C; Sat, 7 Sep 2019 22:09:33 +0000 (GMT)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id x87M9XIC030449; Sat, 7 Sep 2019 17:09:33 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id x87M9SvR030163; Sat, 7 Sep 2019 17:09:29 -0500
Received: from ( []) by (Postfix) with ESMTP id 3504FE590E; Sat, 7 Sep 2019 18:08:41 -0400 (EDT)
Received: from ([fe80::b09c:ff13:4487:78b6]) by ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sat, 7 Sep 2019 18:09:24 -0400
From: "MORTON, ALFRED C (AL)" <>
To: Mirja Kuehlewind <>, "" <>
CC: IETF IPPM WG <>, Michelle Cotton <>
Thread-Topic: AD review of draft-ietf-ippm-metric-registry-19
Thread-Index: AQHVXN15AQy7FexigUuWlNjVu81huacgxm0A
Date: Sat, 7 Sep 2019 22:09:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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_11:, , 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-1909070240
Archived-At: <>
Subject: Re: [ippm] AD review of draft-ietf-ippm-metric-registry-19
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Sep 2019 22:10:05 -0000

Hi Mirja,
Catching-up with your comments on the registry draft.
Please see replies below, and thanks again for your review.

> -----Original Message-----
> From: Mirja Kuehlewind []
> Sent: Tuesday, August 27, 2019 9:44 AM
> To:
> Cc: IETF IPPM WG <>rg>; Michelle Cotton
> <>
> 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.
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?
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/
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.

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.


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? 
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?
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?
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!).