[IPFIX]Re: [Editorial Errata Reported] RFC7011 (8313)

Paolo Lucente <paolo@ntt.net> Thu, 27 February 2025 21:43 UTC

Return-Path: <paolo@ntt.net>
X-Original-To: ipfix@mail2.ietf.org
Delivered-To: ipfix@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7270432E3B0 for <ipfix@mail2.ietf.org>; Thu, 27 Feb 2025 13:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htM3jrVNQmlL for <ipfix@mail2.ietf.org>; Thu, 27 Feb 2025 13:43:19 -0800 (PST)
Received: from mx1.vm.gin.ntt.net (mail.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3EFD432E39E for <ipfix@ietf.org>; Thu, 27 Feb 2025 13:43:19 -0800 (PST)
Received: from [IPV6:2001:418:1401:10::100a] (unknown [IPv6:2001:418:1401:10::100a]) by mx1.vm.gin.ntt.net (Postfix) with ESMTPSA id 9592940EE3; Thu, 27 Feb 2025 21:43:16 +0000 (UTC)
Message-ID: <1c3a4ee8-3a38-4318-83ce-562f92bfd59d@ntt.net>
Date: Thu, 27 Feb 2025 22:43:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Benoit Claise <benoit.claise=40huawei.com@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
References: <20250225131302.8667125D912@rfcpa.rfc-editor.org> <d36ae3ee-7017-479f-82d9-64c3e6d9d561@huawei.com>
Content-Language: en-US
From: Paolo Lucente <paolo@ntt.net>
In-Reply-To: <d36ae3ee-7017-479f-82d9-64c3e6d9d561@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: 74WS7XEGOL7DSOMLCIAMBQZFV2RHAED3
X-Message-ID-Hash: 74WS7XEGOL7DSOMLCIAMBQZFV2RHAED3
X-MailFrom: paolo@ntt.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipfix.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mohamed.boucadair@orange.com, bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com, ipfix@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPFIX]Re: [Editorial Errata Reported] RFC7011 (8313)
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/F6_Emzn55D41J3J3KDA0SU99bJQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Owner: <mailto:ipfix-owner@ietf.org>
List-Post: <mailto:ipfix@ietf.org>
List-Subscribe: <mailto:ipfix-join@ietf.org>
List-Unsubscribe: <mailto:ipfix-leave@ietf.org>

Hi Benoit, Med,

Looking forward to your thoughts, please let me share some field 
experience from the collector stand point: i have total seen exporters 
using e-bit in conjunction with IANA-allocated fields, they are out 
there (especially in the non-routing business, ie. firewalls, CGNs, etc.).

The meaning for this (i derived myself from field experience) is: the 
exporter is using a IANA-allocated field but "in a special way", 
typically, the purpose is the same but the encoding differs. pmacct, the 
open-source (IPFIX, among the other things) collector i maintain, also 
to tackle these scenarios, does allow users to change the semantics / 
decoder basing (also) on IE/PEN combos.

This leads me to think this errata will contraddict a practice among 
implementors of some IPFIX exporters. My personal take is that the 
current non-restrictive wording of the RFC is added-value.

Paolo


On 25/2/25 14:33, Benoit Claise wrote:
> Dear all,
> 
> Med is right in his thinking. We could have more precise with the 
> specifications.
> 
> Whether this errata is Verified or Hold for Document Update, I 
> personally don't believe it's important as IMO this was never an issue 
> in collector implementations.
> 
> Regards, Benoit
> 
> 
> On 2/25/2025 2:13 PM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC7011,
>> "Specification of the IP Flow Information Export (IPFIX) Protocol for 
>> the Exchange of Flow Information".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid8313
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
>>
>> Section: 3.2
>>
>> Original Text
>> -------------
>>     E
>>
>>        Enterprise bit.  This is the first bit of the Field Specifier.  If
>>        this bit is zero, the Information Element identifier identifies an
>>        Information Element in [IANA-IPFIX], and the four-octet Enterprise
>>        Number field MUST NOT be present.  If this bit is one, the
>>        Information Element identifier identifies an enterprise-specific
>>        Information Element, and the Enterprise Number field MUST be
>>        present.
>>
>>     Information Element identifier
>>
>>        A numeric value that represents the Information Element.  Refer to
>>        [IANA-IPFIX].
>>
>> Corrected Text
>> --------------
>>     E
>>
>>        Enterprise bit.  This is the first bit of the Field Specifier.  If
>>        this bit is zero, the Information Element identifier identifies an
>>        Information Element in [IANA-IPFIX], and the four-octet Enterprise
>>        Number field MUST NOT be present.  If this bit is one, the
>>        Information Element identifier identifies an enterprise-specific
>>        Information Element, and the Enterprise Number field MUST be
>>        present.
>>
>>     Information Element identifier
>>
>>        A numeric value that represents the Information Element. This 
>> field
>>        takes a value in [IANA-IPFIX] when the E bit is set to zero.
>>
>> Notes
>> -----
>> Makes it explicit that the values in [IANA-IPFIX] only applies when 
>> the is E-bit is unset.
>>
>> An alternative would be to simply delete "Refer to [IANA-IPFIX]." as 
>> the exact behavior is already mentioned under the E bit description.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". (If it is spam, it
>> will be removed shortly by the RFC Production Center.) Please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> will log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10)
>> --------------------------------------
>> Title               : Specification of the IP Flow Information Export 
>> (IPFIX) Protocol for the Exchange of Flow Information
>> Publication Date    : September 2013
>> Author(s)           : B. Claise, Ed., B. Trammell, Ed., P. Aitken
>> Category            : INTERNET STANDARD
>> Source              : IP Flow Information Export
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>> _______________________________________________
>> IPFIX mailing list -- ipfix@ietf.org
>> To unsubscribe send an email to ipfix-leave@ietf.org
> 
> _______________________________________________
> IPFIX mailing list -- ipfix@ietf.org
> To unsubscribe send an email to ipfix-leave@ietf.org