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

Benoit Claise <benoit.claise@huawei.com> Fri, 30 April 2021 08:06 UTC

Return-Path: <benoit.claise@huawei.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 7EEF03A1967 for <ipfix@ietfa.amsl.com>; 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 <ipfix@ietfa.amsl.com>; 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 <ipfix@ietf.org>; 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 <ipfix@ietf.org>; 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" <paul.aitken@intl.att.com>, "ipfix@ietf.org" <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 <benoit.claise@huawei.com>
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: <https://mailarchive.ietf.org/arch/msg/ipfix/5q5l-kbIMdHldbM8k1B65IMo1uM>
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: Fri, 30 Apr 2021 08:06:20 -0000

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  <https://tools.ietf.org/html/rfc7012#section-7.2>)
    must have those subregistries added simultaneously with the new
    assignment; additions to these subregistries must be subject to
    Expert Review [RFC5226  <https://tools.ietf.org/html/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 
>>> <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>
>>>
>>> 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
>>> 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
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!BhdT!zCko7jEO5SyXRUEvtrBEOI6gAx4qax1jFUKesfcnL-TzQW9Y4CgLonFFmNspjZQ$  
>