Found 2 records.

Status: Verified (2)

RFC 7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", September 2013

Errata ID: 7875
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Katherine Prevost
Date Reported: 2024-03-28
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2024-04-04

Section 6.2 says:

   Reduced-size encoding MAY be applied to the following integer types:
   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
   The signed versus unsigned property of the reported value MUST be
   preserved.  The reduction in size can be to any number of octets
   smaller than the original type if the data value still fits, i.e., so
   that only leading zeroes are dropped.  For example, an unsigned64 can
   be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

It should say:

   Reduced-size encoding MAY be applied to the following integer types:
   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
   The signed versus unsigned property of the reported value MUST be
   preserved. The reduction in size can be to any number of octets
   smaller than the original type if the data value still fits, i.e., so
   that only leading zeroes are dropped (Or, in the case of negative
   signed values, so that only leading ones are dropped). For example,
   an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

Notes:

As written, the specification suggests that integer values may only be encoded using a reduced-size encoding if they have a run of zeroes at the beginning. However, the specification also describes being able to use reduced-size encoding for signed integer values—and only non-negative values of signed integers have a representation that begins with zeroes.

Either the text should clarify that negative values may never be expressed using a reduced-size encoding (which is what the strictest reading of the current text would suggest), or it should specify that leading ones may also be dropped for signed values, which makes it clear that they should be interpreted via sign extension of the high bit.

A quick survey of existing IPFIX implementations suggests that those which decode reduced-size encoding of integers at all produce the semantic equivalent of sign extension when they encounter a reduced-size encoding of a signed integer value.

--
WK: Thread (for posterity): https://mailarchive.ietf.org/arch/msg/ipfix/sBsLy-XYH8sQCEjnPSGoEKsRL9Y/

Errata ID: 4396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rick Hofstede
Date Reported: 2015-06-19
Verifier Name: Benoit Claise
Date Verified: 2015-07-17

Section 3.1 says:

Incremental sequence counter modulo 2^32 of all IPFIX Data Records
sent in the current stream from the current Observation Domain by
the Exporting Process.

It should say:

Incremental sequence counter modulo 2^32 of all IPFIX Data Records
sent in the current stream from the current Observation Domain by
the Exporting Process, prior to the receipt of this IPFIX Message.

Notes:

The original specification can be interpreted in two ways:

(1) Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process *up to* this Message.
(2) Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process *up to and including* this Message.

It seems that only Section 10.3.2 — Reliability explains which of the two interpretations is right: In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Transport Session *prior* to the receipt of this IPFIX Message, modulo 2^32.

In my opinion, it would be good to clarify the use of sequence numbers in Message headers already in the definition of sequence numbers in RFC 7011, namely in Section 3.1.

Discussed here: https://mailarchive.ietf.org/arch/msg/ipfix/AQKObQ2WA_zIXgRzdxRsDrIWjx0

Report New Errata