Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and COMMENT)

"MORTON, ALFRED C (AL)" <acm@research.att.com> Wed, 04 December 2019 18:38 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 160D4120944; Wed, 4 Dec 2019 10:38:10 -0800 (PST)
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 3c6Q7Dxd0FtQ; Wed, 4 Dec 2019 10:38:08 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0429812087D; Wed, 4 Dec 2019 10:38:08 -0800 (PST)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xB4IZL0s022918; Wed, 4 Dec 2019 13:38:06 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 2wpc16t4gx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Dec 2019 13:38:06 -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 xB4Ic4D1070646; Wed, 4 Dec 2019 12:38:05 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xB4Ic1CG070610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Dec 2019 12:38:01 -0600
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id DFACB400073C; Wed, 4 Dec 2019 18:38:01 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id BA727400073B; Wed, 4 Dec 2019 18:38:01 +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 xB4Ic1G6010610; Wed, 4 Dec 2019 12:38:01 -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 xB4IbrXl010111; Wed, 4 Dec 2019 12:37:53 -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 88B90E268C; Wed, 4 Dec 2019 13:33:58 -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; Wed, 4 Dec 2019 13:37:52 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "ippm@ietf.org" <ippm@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ietf@wjcerveny.com" <ietf@wjcerveny.com>, "draft-ietf-ippm-metric-registry@ietf.org" <draft-ietf-ippm-metric-registry@ietf.org>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and COMMENT)
Thread-Index: AQHVqipHrxgugKZKPkmFW2IOU/MO86ep5yjAgACcRAD//8jcEA==
Date: Wed, 04 Dec 2019 18:37:52 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F05F66@njmtexg5.research.att.com>
References: <157541264931.4734.14501743204777647352.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CFA6F05456@njmtexg5.research.att.com> <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com>
In-Reply-To: <CAMMESsxeQJGwPW4TjXzQ_bzQKfAmv2taVorpJh2DE4QfRj9ZGQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [156.106.224.110]
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-04_03:2019-12-04,2019-12-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 impostorscore=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912040150
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/6PT_tsHdlmOIoKIjN-3OAjRRhfM>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and COMMENT)
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: Wed, 04 Dec 2019 18:38:10 -0000

Hi Alvaro and Alissa,

I'll give this paragraph one more try, taking your comments
into account...  please see below, and feel free to edit!

Al

> -----Original Message-----
> From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
> Sent: Wednesday, December 4, 2019 11:44 AM
> To: MORTON, ALFRED C (AL) <acm@research.att.com>; The IESG <iesg@ietf.org>
> Cc: ippm@ietf.org; ippm-chairs@ietf.org; ietf@wjcerveny.com; draft-ietf-
> ippm-metric-registry@ietf.org
> Subject: RE: Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-
> 22: (with DISCUSS and COMMENT)
> 
> On December 4, 2019 at 10:31:42 AM, MORTON, ALFRED C (AL) wrote:
> 
> Al:
> 
> Hi!
> 
> For the approval of the initial registry point, I think we'll need
> Mirja to comment.
> 
> > > -----Original Message-----
> > > From: Alvaro Retana via Datatracker [mailto:noreply@ietf.org]
> ...
> > > (2)
> > >
> > > §8.1 (Adding new Performance Metrics to the Performance Metrics
> Registry)
> > > defines the following process for entries that are "not yet widely
> > > deployed":
> > >
> > > If the proposed registry entry is defined in an RFC but is not yet
> > > widely deployed, there SHOULD be a statement in the RFC that says the
> > > proposed registry entry is not ready for registration, and use SHOULD
> > > employ a private/experimental ID. It is the responsibility of the
> > > document authors to submit the request to IANA when the proposed
> > > registry entry is ready for official registration.
> > >
> > > Considering the Specification Required policy and the fact that the
> RFC has
> > > already gone through all the reviews required for publication
> (including
> > > expert review, as mentioned in the same section), how will it work for
> the
> > > "authors to submit the request to IANA when the proposed registry
> entry is
> > > ready for official registration"? What specification will be presented
> to
> > > IANA to satisfy the registration requirement? It seems to me that the
> > > statement mentioned above would prevent the official registration in
> the
> > > first place, and that same statement (still present in the RFC) should
> > > prevent a second review of the same document from resulting in an
> official
> > > registration.
> > >
> > > This process needs more discussion and clarity for it to work.
> > [acm]
> > Yes, I see your point. This a paragraph we added at the IANA desk
> > during IETF-106, to resolve a question raised, and it seems we didn't
> > read it critically. Let me suggest several revisions as a paragraph
> > below:
> >
> > If the proposed registry entry is defined in an RFC but is not yet
> > widely deployed, there SHOULD be a statement in the RFC that says the
> > proposed registry entry is not ready for registration because it lacks
> > deployment (in the IANA Considerations Section), and SHOULD employ a
> > private/experimental ID when used in practice. The IANA and Expert
> > reviews of the proposed registry entry take place as normally required,
> > and registration SHALL be held. When the authors are ready to show
> > evidence of widespread deployment, they SHOULD submit the evidence
> > to IANA to be evaluated in consultation with the Performance Metric
> > Experts for registration at that time.
> 
> This new text is not explicit on what "evidence of widespread
> deployment", nor whether that would be considered a specification in
> line with the registration policy.  It also suffers from the point
> that Alissa mentioned in her DISCUSS of leaving the published RFC with
> the "old" text saying that the metric is not ready.
> 
[acm] 

If an RFC-to-be includes a Performance Metric and a proposed Performance 
Metrics Registry entry, but the IANA and Performance Metric Expert review 
determines that one or more of the Section 5 criteria have not been met, 
then the IESG approval process MUST proceed with the proposed Performance 
Metrics Registry entry removed from the text. When the RFC-to-be authors 
are ready to show evidence of meeting the criteria in section 5, they 
SHOULD re-submit the proposed Performance Metrics Registry entry to IANA 
to be evaluated in consultation with the Performance Metric Experts for 
registration at that time.


> 
> 
> Thanks for addressing my other comments.
[acm] 
you're welcome!

> 
> Alvaro.