Re: [IPFIX] Review of draft-boucla-opsawg-ipfix-fixes Tue, 24 January 2023 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88FCBC14CE32; Tue, 24 Jan 2023 04:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TOPdcsFjOkoE; Tue, 24 Jan 2023 04:57:18 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7E217C14CE25; Tue, 24 Jan 2023 04:57:17 -0800 (PST)
Received: from (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4P1Rnl3JwWz1yGx; Tue, 24 Jan 2023 13:57:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1674565035; bh=mdznYdfRjOXVMU0K1a+JLKzC6D05ckU10mGGeenFl1I=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=b5apDXCNc4m/XBLmyr9zTgkO9itTsqJWuuFnjU9IJadD7uLHEmJtUEcdgSwbZiq11 cUG3VXQhz4Z6hhGAg2qi4/0DolE2ILIUPCo7Jr2thA2iY3OSxvvfbr0Q3iNffJFwvD 5IMBgH4l+AKN1JL7V7e9a6++kWKthw4wR1b2O+QSiH8WADQZkkSB/KxzXq1aiyUMh2 PESpCNBwU2dpEhdUdOLrKiu4SLTs6s4XUX0GTzbzAZ6BnLULt6SKML7PXAMobE8zGx 7lpobrcF1Tjo1ZLb6MAPX+SRMD2z2ac/1ej9AXqrZ1At4E8CKkv0bd2rFRAn3qmVRl UllSBXXoGnSkQ==
To: "Aitken, Paul" <>, opsawg <>
CC: "" <>
Thread-Topic: [IPFIX] Review of draft-boucla-opsawg-ipfix-fixes
Thread-Index: AQHZLRzjSCaHbtQJGUmm9cWKu+/Ijq6r9C6AgAB0PACAALmcUA==
Date: Tue, 24 Jan 2023 12:57:15 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2023-01-24T06:36:08Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=3fc5fb74-b28e-489c-809f-70748dcd1b02; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_37efc1c5f7924265b815094f31df282eorangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [IPFIX] Review of draft-boucla-opsawg-ipfix-fixes
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jan 2023 12:57:22 -0000

Hi Paul,

Thanks for the follow-up. Good catches. These should be now fixed in the candidate -04:

The diff can be tracked here:

As you can see, Section 3 includes now a proposal to address the issues with tcpOptions and ipv6ExtensionHeaders. As these changes are not “simple fixes”, we may move this part into a separate draft.


De : Aitken, Paul <>
Envoyé : lundi 23 janvier 2023 20:32
À : BOUCADAIR Mohamed INNOV/NET <>; opsawg <>; Benoit Claise <>
Cc :
Objet : Re: [IPFIX] Review of draft-boucla-opsawg-ipfix-fixes

Thanks Med, this looks great. Thanks for updating so quickly. Some further feedback:

Parenthesise "Section 6" for consistency with the previous paragraphs:

1.  Introduction

         *  Miscellaneous updates that fix broken pointers, orphan section
                      references, etc.  Section 6.

This does not make sense:

4. Point to An Existing IANA Registry

  IANA is requested to update the following entries by adding the
  indicated "Additional Information" of [IANA-IPFIX]:


  IANA is requested to update the following entries by adding the
  indicated "Additional Information" to the [IANA-IPFIX] registry:

Section 4 says, "IANA is requested to update the following entries". Section 5 says, "IANA is requested to update [IANA-IPFIX]". Sections 3 and 6 should say something similar so they're clearly requests for IANA to update the entries.

6.3 anonymizationFlags

This is the table that needs fixed, right?

6.6. externalAddressRealm

    The detailed definition is similar to the one provided for the internalAddressRealm IE.

"similar" allows for some ambiguity. Perhaps, "See the internalAddressRealm IE for the detailed definition".

Also, at one time Benoit was strict about not using "IE", but always using "Information Element" - possibly because "IE" is not defined in the IPFIX terminology.

8. IANA Considerations

                   This document also requests IANA to update the reference clause of
                   the "IPFIX Information Elements" subregistry with teh reference to
                   this document.

Typo, "teh".


On 23/01/2023 12:35,<> wrote:
Re-,  Paul,

Many thanks for the comments. All good points.

An updated version to address almost all these points is online:






(There is a formatting issue with a table; this will be fixed in the next iteration)

For the comment about references, I prefer to leave those to make idnits happy.


De : Aitken, Paul <><>
Envoyé : vendredi 20 janvier 2023 23:17
À : opsawg <><>; BOUCADAIR Mohamed INNOV/NET <><>; Benoit Claise <><>
Cc :<>
Objet : Review of draft-boucla-opsawg-ipfix-fixes

This cleanup seems good and useful. Thanks for the draft. Please find some feedback below, with quoted text in black and my comments in blue.

1. Introduction

This document intends to update the IANA registry and bringing some consistency.

Consistency with ... ?

3. Update the Description

This section should propose/request updates just as section 4 does.

3.1. tcpOptions

Only options having a kind =< 56 can be included in a tcpOptions IE.

The tcpOptions IE supports options 0 through 63.

4. Point to An Existing IANA Registry

I found this line difficult to parse:

    IANA is requested to update the following entries by adding the indicated pointer to an IANA registry under "Additional Information" of [IANA-IPFIX]:

I suggest:

    IANA is requested to update the following entries by adding the indicated "Additional Information".

5. Consistent Citation of Registries

Many of these changes move the relevant registry from the Description to the Additional Information, so it's presented as "See <url>" without any explanation. The general form of the Addition Information column is "See [url] for the definition...", so these updates should follow the same format. ie, say why to see that URL.

Some of the existing Additional Information entries simply cite an RFC without explanation. These should also be improved.

5.1 mplsTopLabelType / NEW

Additional Information: See [RFC3031<>] for the MPLS label structure. See

Please put the IANA registry first and explain why to see it, eg:

Additional Information: See the MPLS label type registry at []. See [RFC3031<>] for the MPLS label structure.

5.3. classificationEngineId / NEW

Additional Information: See the Classification Engine IDs registry [].

5.22. dataLinkFrameType

Additional Information: See [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994]

Please add some explanatory text to the IEEE + ISO/IEC links, eg:

Additional Information: See the dataLinkFrameType registry at []. See [IEEE802.3] for the definition of something, and [IEEE802.11] for the definition of something else. See [ISO/IEC.7498-1:1994] for further specifications."

Should "The data link layer is defined in [ISO/IEC.7498-1:1994]." also be moved into the Additional Information?

Similar comments apply for sections 5.4 through 5.25.

5.15. informationElementUnits / NEW

This field may take the values in Table 3 below

There is no Table 3.

The registry would benefit from cleanup of "below" as used in collectionTimeMilliseconds, messageMD5Checksum, selectorAlgorithm, informationElementUnits, distinctCountOfDestinationIPAddress, and "above" as used in externalAddressRealm, since these have no meaning when the element's definition is read stand-alone.

Also cleanup of "section N" without any reference which seem to refer to sections of the defining RFC and have no context in the registry:


        "Stability Class: see the Stability Class table below, and section Section 5.1."

        "see Section 7.2.2 for details."

    Classification Engine IDs (Value 101) value 6:

        "based on the methods described in section 2."


        "as defined in the Scope (Section 1)."

8.2. Informative References

It doesn't seem necessary or useful to list each RFC which was quoted from the registry. Only cite those which pertain to the draft itself.


On 19/01/2023 16:53, Joe Clarke (jclarke) wrote:
Forwarding to ipfix@ for more eyes on this.  Please reply to opsawg@ with any comments or questions.


From: OPSAWG <><> on behalf of Joe Clarke (jclarke) <><>
Date: Tuesday, January 17, 2023 at 11:24
To:<> <><>
Subject: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Happy new year, all.  One of the AIs that slipped through the cracks coming out of 115 was a call for adoption for draft-boucadair-opsawg-rfc7125-update.   One of the asks of Med at 115 was to look at what else might need to be done from an IE registry standpoint.  He replied on-list to that a while ago:

“Yes, I had a discussion with Benoît during the IETF meeting to see how to handle this. We agreed to proceed with at least two documents:

1.       draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX RFC.

2.       Edit a second draft to “clean” other entries in registry. This document is intended to include only simple fixes and which do not require updating existing RFCs. The candidate list of these proposed fixes can be seen at []<;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI6J3rDFp$>. New IEs, if needed, will be moved to a separate document. simple-ipfix-fixes may or may not be published as an RFC.”

So, let this serve as a two-week call for adoption for the existing draft-boucadair-opsawg-rfc7125-update document.  Please reply on-list with your comments, support, or dissent by January 31, 2023.




IPFIX mailing list<>;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$<;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$> [ietf[.]org]


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.