From nobody Wed Apr 28 13:16:34 2021 Return-Path: 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 A31433A1E94 for ; Wed, 28 Apr 2021 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TZZ_uc9Z9je8 for ; Wed, 28 Apr 2021 13:16:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590953A1EA8 for ; Wed, 28 Apr 2021 13:16:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5BB3EF4075E; Wed, 28 Apr 2021 13:16:09 -0700 (PDT) To: bclaise@cisco.com, trammell@tik.ee.ethz.ch, warren@kumari.net, rwilton@cisco.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: paul.aitken@att.com, ipfix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210428201609.5BB3EF4075E@rfc-editor.org> Date: Wed, 28 Apr 2021 13:16:09 -0700 (PDT) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 20:16:33 -0000 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 -------------------------------------- Type: Editorial Reported by: Paul Aitken 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 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 From nobody Thu Apr 29 00:23:26 2021 Return-Path: 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 962163A33B7 for ; Thu, 29 Apr 2021 00:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 xX9x2LQMQpy2 for ; Thu, 29 Apr 2021 00:23:19 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6D73A33B6 for ; Thu, 29 Apr 2021 00:23:19 -0700 (PDT) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FW6C62mJDz70gQ2 for ; Thu, 29 Apr 2021 15:12:34 +0800 (CST) Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 29 Apr 2021 09:23:12 +0200 Received: from fraeml795-chm.china.huawei.com (10.206.15.16) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 29 Apr 2021 09:23:12 +0200 Received: from DGGEMS411-HUB.china.huawei.com (10.3.19.211) by fraeml795-chm.china.huawei.com (10.206.15.16) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2176.2 via Frontend Transport; Thu, 29 Apr 2021 09:23:11 +0200 Received: from [10.47.73.169] (10.47.73.169) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.498.0; Thu, 29 Apr 2021 15:22:59 +0800 To: References: <20210428201609.5BB3EF4075E@rfc-editor.org> <57c9182181ec49688eacdef45006bb7b@claise.be> From: Benoit Claise Message-ID: <8470fe7c-9079-69d4-90b3-0e02b53e0f63@huawei.com> Date: Thu, 29 Apr 2021 09:23:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <57c9182181ec49688eacdef45006bb7b@claise.be> Content-Type: multipart/alternative; boundary="------------13765614F2ED2EB0C958F635" Content-Language: en-GB X-Originating-IP: [10.47.73.169] X-CFilter-Loop: Reflected Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 07:23:25 -0000 --------------13765614F2ED2EB0C958F635 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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 de la part de RFC Errata System > > *Envoyé :* mercredi 28 avril 2021 22:16:09 > *À :* bclaise@cisco.com; trammell@tik.ee.ethz.ch; warren@kumari.net; > rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu > *Cc :* ipfix@ietf.org; 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 > > > -------------------------------------- > Type: Editorial > Reported by: Paul Aitken > > 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 > > > 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 > https://www.ietf.org/mailman/listinfo/ipfix > --------------13765614F2ED2EB0C958F635 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit 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> de la part de RFC Errata System <rfc-editor@rfc-editor.org>
Envoyé : mercredi 28 avril 2021 22:16:09
À : bclaise@cisco.com; trammell@tik.ee.ethz.ch; warren@kumari.net; rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu
Cc : ipfix@ietf.org; 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

--------------------------------------
Type: Editorial
Reported by: Paul Aitken <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

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
https://www.ietf.org/mailman/listinfo/ipfix

--------------13765614F2ED2EB0C958F635-- From nobody Thu Apr 29 01:59:27 2021 Return-Path: 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 ; 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 ; 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 ; 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" To: Benoit Claise , "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 08:59:26 -0000 --_000_78816f55e7960332b1ae9e13800a0955intlattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Benoit. This seems strange, because an approved request would result in an update t= o the IANA registry anyway. This line seems to be imposing the "Specification Required" policy per sect= ion 4.6 of RFC 8126. This is inconsistent with the other IPFIX sub registries, which do not spec= ify 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 publ= ished 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 proc= edure 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 Re= view" in several places. However neither of them mentions "Specification Re= quired", nor repeats the "MUST be published using a well-established and pe= rsistent publication medium." requirement for any other IE. Therefore I propose that the requirement be removed from the MPLS label typ= es 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 wel= l-established and persistent publication medium." ... we carefully crafted this sentence not to mention "publication requeste= d" 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 de la pa= rt de RFC Errata System Envoy=E9 : mercredi 28 avril 2021 22:16:09 =C0 : bclaise@cisco.com; trammell@tik.ee.ethz.ch<= mailto:trammell@tik.ee.ethz.ch>; warren@kumari.net; rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu Cc : ipfix@ietf.org; 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 -------------------------------------- Type: Editorial Reported by: Paul Aitken 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 typ= es in the mplsTopLabelType sub-registry. Since the publication of RFC7012, IANA has added 16 other IPFIX IE sub-regi= stries, none of which have the same requirement. See https://www.iana.org/a= ssignments/ipfix/ipfix.xhtml 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 (IPF= IX) 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 https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!= !BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$ --_000_78816f55e7960332b1ae9e13800a0955intlattcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks Benoit.

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

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

This is inconsistent with the other IPFIX sub registries, which do not spec= ify 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 t= ypes 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 proc= edure 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 "Expe= rt Review" in several places. However neither of them mentions "S= pecification 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 typ= es 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 req= uested" as RFC, with in idea in mind that an IANA registry would fall = under the "well-established  and persistent publicat= ion medium" category.

Regards, Benoit
De : IPFIX <ipfix-bounces@ietf.org> de la part de RFC Errata System <rfc-editor@rfc-editor.org>
Envoy=E9 : mercredi 28 avril 2021 22:16:09
=C0 : bclaise@cisco.com; trammell@tik.ee.ethz.ch; warren@kumari.net; rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu
Cc : ipfix@ietf.org; 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

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

Section: 7.2

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

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

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

Since the publication of RFC7012, IANA has added 16 other IPFIX IE sub-regi= stries, none of which have the same requirement. See https://www.iana.org/assignments/ipfix/ipfix.xhtml

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, ple= ase
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           &nbs= p;   : Information Model for IP Flow Information Export (IPFIX) Publication Date    : September 2013
Author(s)           : B. = Claise, Ed., B. Trammell, Ed.
Category            = : PROPOSED STANDARD
Source           &nb= sp;  : IP Flow Information Export
Area            = ;    : Operations and Management
Stream           &nb= sp;  : IETF
Verifying Party     : IESG

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfi= x


____________________________________=
___________
IPFIX mailing list
IPFIX@=
ietf.org
https://urldefense.com/v3/__https:/=
/www.ietf.org/mailman/listinfo/ipfix__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qa=
x1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$=20

--_000_78816f55e7960332b1ae9e13800a0955intlattcom_-- From nobody Fri Apr 30 01:06:22 2021 Return-Path: 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 7EEF03A1967 for ; Fri, 30 Apr 2021 01:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 g3XeWSv8YYrL for ; Fri, 30 Apr 2021 01:06:15 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286FA3A1969 for ; Fri, 30 Apr 2021 01:06:15 -0700 (PDT) Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FWl9Q5fQZz6slYs for ; Fri, 30 Apr 2021 15:58:18 +0800 (CST) Received: from fraeml744-chm.china.huawei.com (10.206.15.225) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 30 Apr 2021 10:06:09 +0200 Received: from DGGEMS413-HUB.china.huawei.com (10.3.19.213) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2176.2 via Frontend Transport; Fri, 30 Apr 2021 10:06:08 +0200 Received: from [10.47.75.82] (10.47.75.82) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.498.0; Fri, 30 Apr 2021 16:06:02 +0800 To: "Aitken, Paul" , "ipfix@ietf.org" References: <20210428201609.5BB3EF4075E@rfc-editor.org> <57c9182181ec49688eacdef45006bb7b@claise.be> <8470fe7c-9079-69d4-90b3-0e02b53e0f63@huawei.com> <78816f55-e796-0332-b1ae-9e13800a0955@intl.att.com> From: Benoit Claise Message-ID: <470d0a56-2811-7072-3a52-cab93c6c3c17@huawei.com> Date: Fri, 30 Apr 2021 10:06:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <78816f55-e796-0332-b1ae-9e13800a0955@intl.att.com> Content-Type: multipart/alternative; boundary="------------1D511FC06717B494FD294BEB" Content-Language: en-GB X-Originating-IP: [10.47.75.82] X-CFilter-Loop: Reflected Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 08:06:20 -0000 --------------1D511FC06717B494FD294BEB Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Paul, On 4/29/2021 10:59 AM, Aitken, Paul wrote: > 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 not my conclusion and this was certainly not the intention, as I mentioned below. > > This is inconsistent with the other IPFIX sub registries, which do not > specify this requirement. Fair point (*) Some sub registries were created after RFC5102/7012. Hence not documented in 7012 > > 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? > I don't think this is necessary, as the "well-established and persistent publication medium" is the IANA registry you look at. > > > 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? > This one would be a mistake and would clearly change RFC7012. > > > 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. In practice, I don't believe we have a  problem here: the IANA process, in connection with the IE doctors review, works fine. I mean, everybody could just set up a new IPFIX subregistry with expert review, which is the right procedure. Ex:https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event The process behind it is: 7012, section 7.4 Future assignments added to the "IPFIX Information Elements" registry that require subregistries for enumerated values (e.g.,Section 7.2 ) must have those subregistries added simultaneously with the new assignment; additions to these subregistries must be subject to Expert Review [RFC5226 ]. This rule above also takes care of the "MPLS Label Type Identifier". So maybe it was not necessary to specifically mention section 7.2 "MPLS Label Type Identifier" in 7012. Historical reasons coming from RFC5102 I guess... (*) coming back to "This is inconsistent with the other IPFIX sub registries, which do not specify this requirement.", I don't believe it's true in practice based on the previous text. Note: The fact that most of the IPFIX subregistries have a supporting RFC is a plus for documentation purposes, but is not necessary. In conclusion, we can go whatever way with that errata (accept it, decline it, or even remove the entire section 7.2) as I don't believe we have the problem in practice. So maybe the way out of this is:     change the errata to "remove section 7.2",     AD change this errata to "Held for Document Update" (https://www.rfc-editor.org/errata-definitions/) in case we ever update RFC 7012* * Regards, Benoit > 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 de la part de RFC Errata >>> System >>> *Envoyé :* mercredi 28 avril 2021 22:16:09 >>> *À :* bclaise@cisco.com; trammell@tik.ee.ethz.ch; warren@kumari.net; >>> rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu >>> *Cc :* ipfix@ietf.org; 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 >>> >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Paul Aitken >>> >>> 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 >>> >>> >>> 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 >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$ > --------------1D511FC06717B494FD294BEB Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Paul,

On 4/29/2021 10:59 AM, Aitken, Paul wrote:
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 not my conclusion and this was certainly not the intention, as I mentioned below.

This is inconsistent with the other IPFIX sub registries, which do not specify this requirement.
Fair point (*)
Some sub registries were created after RFC5102/7012. Hence not documented in 7012

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?
I don't think this is necessary, as the "well-established and persistent publication medium" is the IANA registry you look at.

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?
This one would be a mistake and would clearly change RFC7012.

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.
In practice, I don't believe we have a  problem here: the IANA process, in connection with the IE doctors review, works fine.
I mean, everybody could just set up a new IPFIX subregistry with expert review, which is the right procedure. Ex:https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event
The process behind it is: 7012, section 7.4   
    
   Future assignments added to the "IPFIX Information Elements" registry
   that require subregistries for enumerated values (e.g., Section 7.2)
   must have those subregistries added simultaneously with the new
   assignment; additions to these subregistries must be subject to
   Expert Review [RFC5226].

This rule above also takes care of the "MPLS Label Type Identifier". So maybe it was not necessary to specifically mention section 7.2 "MPLS Label Type Identifier" in 7012. Historical reasons coming from RFC5102 I guess...

(*) coming back to "This is inconsistent with the other IPFIX sub registries, which do not specify this requirement.", I don't believe it's true in practice based on the previous text.

Note: The fact that most of the IPFIX subregistries have a supporting RFC is a plus for documentation purposes, but is not necessary.

In conclusion, we can go whatever way with that errata (accept it, decline it, or even remove the entire section 7.2) as I don't believe we have the problem in practice.
So maybe the way out of this is:
    change the errata to "remove section 7.2",
    AD change this errata to "Held for Document Update" (https://www.rfc-editor.org/errata-definitions/) in case we ever update RFC 7012

Regards, Benoit
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> de la part de RFC Errata System <rfc-editor@rfc-editor.org>
Envoyé : mercredi 28 avril 2021 22:16:09
À : bclaise@cisco.com; trammell@tik.ee.ethz.ch; warren@kumari.net; rwilton@cisco.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu
Cc : ipfix@ietf.org; 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

--------------------------------------
Type: Editorial
Reported by: Paul Aitken <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

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
https://www.ietf.org/mailman/listinfo/ipfix


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


--------------1D511FC06717B494FD294BEB--