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

["Aitken, Paul" <[e-mail]>]

Paolo,

When the E bit is set, the corresponding IDs are allocated by the 
Enterprise and not by IANA, so it's incorrect to say "using e-bit in 
conjunction with IANA-allocated fields".

An Enterprise could decide to re-use the same IDs which IANA uses. It 
could be a useful local convention: when an IANA IE needs to be modified 
then make an enterprise-specific IE by re-using the IANA ID with the 
E-bit set.

But nobody can rely on the IDs alone to know whether there is any 
similarity between an IANA element and an Enterprise-Specific element 
which happen to use the same ID. Nor can we assume any similarity 
between Enterprise-Specific elements from different enterprises which 
use the same element ID.


 > the purpose is the same but the encoding differs

It's equally possible that the purpose differs but the encoding is the 
same, or that both the purpose and encoding differ.

We cannot make any assumptions from the IDs alone, but only by comparing 
the published specification of each IE.


P.


On 27/02/25 21:43, Paolo Lucente wrote:
>
> 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8313__;!!OSsGDw!KFY0ELV2ZFf2VS5YuvFMA3KihdP8vLRjGQNhnaswosNOCuNNegpx7jWHFRPpw10RTCTg3Jc1$ 
>>> [rfc-editor[.]org]
>>>
>>> --------------------------------------
>>> Type: Editorial
>>> Reported by: Mohamed Boucadair <[e-mail]>
>>>
>>> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> IPFIX mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> IPFIX mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]