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$
- [IPFIX] [Editorial Errata Reported] RFC7012 (6564) RFC Errata System
- Re: [IPFIX] [Editorial Errata Reported] RFC7012 (… Benoit Claise
- Re: [IPFIX] [Editorial Errata Reported] RFC7012 (… Aitken, Paul
- Re: [IPFIX] [Editorial Errata Reported] RFC7012 (… Benoit Claise