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

[[e-mail]]

Hi Paolo,

The use you described is really local to the vendors. They are free to set their own conventions about which id to pick. What is key is that we should not expect interoperability between two enterprise-specific IEs having the same id part.

The erratum does not introduce any new restriction on that matters.

Cheers,
Med

> -----Message d'origine-----
> De : Paolo Lucente <[e-mail]>
> Envoyé : jeudi 27 février 2025 22:43
> À : Benoit Claise <benoit.claise=[e-mail]>; RFC
> Errata System <[e-mail]>
> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: [IPFIX]Re: [Editorial Errata Reported] RFC7011 (8313)
> 
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >> .rfc-
> editor.org%2Ferrata%2Feid8313&data=05%7C02%7Cmohamed.boucadair%4
> >>
> 0orange.com%7Cb305460d0d48420131c208dd5777c2d0%7C90c7a20af34b40bfbc48
> >>
> b9253b6f5d20%7C0%7C0%7C638762894125811314%7CUnknown%7CTWFpbGZsb3d8eyJ
> >>
> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> >>
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MZ1NkvtJFgOzQiDwQJzJegubNtP6V
> >> vlAV%2B9dl5sV9%2Fw%3D&reserved=0
> >>
> >> --------------------------------------
> >> 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]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.