Re: [IPFIX] [Editorial Errata Reported] RFC7012 (6564)

"Aitken, Paul" <paul.aitken@intl.att.com> Thu, 29 April 2021 08:59 UTC

Return-Path: <paul.aitken@intl.att.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31733A369B for <ipfix@ietfa.amsl.com>; Thu, 29 Apr 2021 01:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 e2WpQTr_wRR8 for <ipfix@ietfa.amsl.com>; Thu, 29 Apr 2021 01:59:20 -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 BC27D3A3699 for <ipfix@ietf.org>; Thu, 29 Apr 2021 01:59:20 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 13T8sTKT039066; Thu, 29 Apr 2021 04:59:14 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 3878ta256d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Apr 2021 04:59:13 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 13T8xDO9008996; Thu, 29 Apr 2021 04:59:13 -0400
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 13T8x89B008962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Apr 2021 04:59:08 -0400
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 14FAB400AF73; Thu, 29 Apr 2021 08:59:08 +0000 (GMT)
Received: from BEBRXMBX21.intl.att.com (unknown [135.76.184.21]) by zlp27128.vci.att.com (Service) with ESMTP id BC004400041E; Thu, 29 Apr 2021 08:59:07 +0000 (GMT)
Received: from bebrxmbx27.intl.att.com (135.76.184.27) by BEBRXMBX21.intl.att.com (135.76.184.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 29 Apr 2021 10:59:07 +0200
Received: from bebrxmbx27.intl.att.com ([135.76.184.27]) by bebrxmbx27.intl.att.com ([135.76.184.27]) with mapi id 15.01.2242.008; Thu, 29 Apr 2021 10:59:07 +0200
From: "Aitken, Paul" <paul.aitken@intl.att.com>
To: Benoit Claise <benoit.claise@huawei.com>, "ipfix@ietf.org" <ipfix@ietf.org>
Thread-Topic: [IPFIX] [Editorial Errata Reported] RFC7012 (6564)
Thread-Index: AQHXPGti1owiX73vu02EGjssEcNWP6rLGFlY///5GgA=
Date: Thu, 29 Apr 2021 08:59:06 +0000
Message-ID: <78816f55-e796-0332-b1ae-9e13800a0955@intl.att.com>
References: <20210428201609.5BB3EF4075E@rfc-editor.org> <57c9182181ec49688eacdef45006bb7b@claise.be> <8470fe7c-9079-69d4-90b3-0e02b53e0f63@huawei.com>
In-Reply-To: <8470fe7c-9079-69d4-90b3-0e02b53e0f63@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
x-originating-ip: [135.76.168.250]
Content-Type: multipart/alternative; boundary="_000_78816f55e7960332b1ae9e13800a0955intlattcom_"
MIME-Version: 1.0
X-Proofpoint-GUID: uGomG8npy1Uk12pQWHK49NlB1PUvyCgX
X-Proofpoint-ORIG-GUID: uGomG8npy1Uk12pQWHK49NlB1PUvyCgX
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-29_05:2021-04-28, 2021-04-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 adultscore=0 phishscore=0 impostorscore=0 suspectscore=0 spamscore=0 mlxscore=0 clxscore=1011 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104290063
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/cJ7oY-WLESWsymP2irBL9Qkj1PU>
Subject: Re: [IPFIX] [Editorial Errata Reported] RFC7012 (6564)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2021 08:59:26 -0000

Thanks Benoit.

This seems strange, because an approved request would result in an update to the IANA registry anyway.

This line seems to be imposing the "Specification Required" policy per section 4.6 of RFC 8126.

This is inconsistent with the other IPFIX sub registries, which do not specify this requirement.

IANA asked IE-doctors:
1) Should we add a note to the top of the IPFIX MPLS label type (Value 46) registry that says, "The specification of new MPLS label types MUST be published using a well-established and persistent publication medium," which is a quote from Section 7.2 of RFC 7012?

2) Should there be an errata report that would change the registration procedure for this registry to Specification Required, as described in Section 4.6 of RFC 8126?

I believe that a single registration policy should be applied consistently to all the IPFIX sub-registries. RFCs 7012 and 7013 both mention "Expert Review" in several places. However neither of them mentions "Specification Required", nor repeats the "MUST be published using a well-established and persistent publication medium." requirement for any other IE.

Therefore I propose that the requirement be removed from the MPLS label types sub-registry.

P.


On 29/04/2021 08:23, Benoit Claise wrote:
Hi Paul,

IIRC, when we wrote:
   "The specification of new MPLS label types MUST be published using a well-established and persistent publication medium."
... we carefully crafted this sentence not to mention "publication requested" as RFC, with in idea in mind that an IANA registry would fall under the "well-established  and persistent publication medium" category.

Regards, Benoit
________________________________
De : IPFIX <ipfix-bounces@ietf.org><mailto:ipfix-bounces@ietf.org> de la part de RFC Errata System <rfc-editor@rfc-editor.org><mailto:rfc-editor@rfc-editor.org>
Envoyé : mercredi 28 avril 2021 22:16:09
À : bclaise@cisco.com<mailto:bclaise@cisco.com>; trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch>; warren@kumari.net<mailto:warren@kumari.net>; rwilton@cisco.com<mailto:rwilton@cisco.com>; n.brownlee@auckland.ac.nz<mailto:n.brownlee@auckland.ac.nz>; quittek@neclab.eu<mailto:quittek@neclab.eu>
Cc : ipfix@ietf.org<mailto:ipfix@ietf.org>; rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>
Objet : [IPFIX] [Editorial Errata Reported] RFC7012 (6564)

The following errata report has been submitted for RFC7012,
"Information Model for IP Flow Information Export (IPFIX)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6564<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6564__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFF_tdEK3E$>

--------------------------------------
Type: Editorial
Reported by: Paul Aitken <paul.aitken@att.com><mailto:paul.aitken@att.com>

Section: 7.2

Original Text
-------------
   The specification
   of new MPLS label types MUST be published using a well-established
   and persistent publication medium.

Corrected Text
--------------
(Deleted)

Notes
-----
This paragraph envisaged that a new RFC be written to specify new label types in the mplsTopLabelType sub-registry.

Since the publication of RFC7012, IANA has added 16 other IPFIX IE sub-registries, none of which have the same requirement. See https://www.iana.org/assignments/ipfix/ipfix.xhtml<https://urldefense.com/v3/__https://www.iana.org/assignments/ipfix/ipfix.xhtml__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFF2WgH9yo$>

Publication in IANA's IPFIX registry should provide a clear and persistent definition. New IPFIX MPLS label type specifications should not be singled out to require persistent publication of an additional document.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
--------------------------------------
Title               : Information Model for IP Flow Information Export (IPFIX)
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed.
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org<mailto:IPFIX@ietf.org>
https://www.ietf.org/mailman/listinfo/ipfix<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$>




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org<mailto:IPFIX@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$