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

[[e-mail]]

Re-, 

Fully agree, Paul.

The discussion we are having further confirms me that we need this errata.

BTW, the reason I initially filled the erratum is that I see some specs leveraging IPFIX E-bit design (draft-ietf-grow-bmp-bgp-rib-stats) to make assumptions on the enterprise-specific elements, e.g.,

==
   *  Type = 32: (64-bit Gauge) Number of routes in per-AFI/SAFI left
      until reaching a license-customized route threshold.  This value
      is affected by whether a customized license exists for the
      relevant address family, and when the customized license is
      installed.  The value is structured as: 2-byte AFI, 1-byte SAFI,
      followed by a 64-bit Gauge.

      Also if the license-customized route threshold is vendor specific,
      this type value (32) SHOULD also use enterprise-specific TLV
      encoding as described in Section 3.3 of
      [I-D.ietf-grow-bmp-tlv-ebit].
==

Let's fix this.

Cheers,
Med

> -----Message d'origine-----
> De : Aitken, Paul <[e-mail]>
> Envoyé : vendredi 28 février 2025 11:24
> À : Paolo Lucente <[e-mail]>
> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; RFC Errata System <[e-mail]>; Benoit
> Claise <benoit.claise=[e-mail]>
> Objet : Re: [IPFIX]Re: [Editorial Errata Reported] RFC7011 (8313)
> 
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid8313__%3B!!OSsGDw!KFY0ELV2ZFf2VS5YuvFMA3KihdP
> 8vLRjGQNhnaswosNOCuNNegpx7jWHFRPpw10RTCTg3Jc1%24&data=05%7C02%7Cmohame
> d.boucadair%40orange.com%7Cfccd935d15a6450962ea08dd57e21cb2%7C90c7a20a
> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638763350829738991%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ACtyRHGSiopUODz3kZdh
> 9VuZbs7uJM8bYoWRnPLEesw%3D&reserved=0
> >>> [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]
____________________________________________________________________________________________________________
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.