RFC Errata
Found 5 records.
Status: Verified (2)
RFC 7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", September 2013
Source of RFC: ipfix (ops)
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
Status: Held for Document Update (3)
RFC 7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", September 2013
Source of RFC: ipfix (ops)
Errata ID: 7413
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Duggan
Date Reported: 2023-04-02
Held for Document Update by: Wa
Date Held: 2023-04-26
Section 3.4.1 says:
Field Count
Number of fields in this Template Record.
It should say:
Field Count Number of fields in this Template Record. The Field Count MUST NOT be zero, unless used in a Template Withdrawal.
Notes:
If the size of data record corresponding to a template can ever be zero, then the only valid size for such a data set is the size of the set header. For normal cases any size greater than that of the set header is a valid size, since records are read from a set until the number of octets remaining is less than the smallest possible record size for that set. If a record size can be zero, then any number of bytes past the header cannot be padding (is not smaller than the smallest record), and a conforming implementation might return an infinite number of zero-sized records. As this could cause a denial of service situation, rejecting templates that define zero-sized records seems to be the simplest solution.
Similar text may be necessary for Option Template records, though the fact that the scope count MUST be non-zero may negate the necessity.
---
WK: See thread https://mailarchive.ietf.org/arch/msg/ipfix/AkCZr1jObLt_x9cyQ73qXBlKC2w/ for more info.
WK - 2023-04-26: Update from the original reporter (Michael) and confirmations from authors (Brian and Benoit) that Field Count can be zero in the case of Template Withdrawal. Changing the state from Verified to HFDU, so that this can be better clarified in any future updates.
Errata ID: 3732
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2013-09-21
Held for Document Update by: Benoit Claise
Date Held: 2013-10-26
Section 1.1 says:
A new Section 5.2 has been added to address wraparound of these
timestamp data types after they overflow in the years 2032-2038.
It should say:
A new Section 5.2 has been added to address wraparound of these
timestamp data types after they overflow.
Notes:
Since dateTimeSeconds is encoded in an _unsigned_ integer, it will wraparound in 2106 (as written correctly in section 5.2), not 2038.
Errata ID: 4216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2014-12-31
Held for Document Update by: Benoit Claise
Date Held: 2015-01-04
Section 3.4.2.2 says:
Scope Field Count
Number of scope fields in this Options Template Record. The Scope
Fields are normal Fields, except that they are interpreted as
scope at the Collector. A scope field count of N specifies that
the first N Field Specifiers in the Template Record are Scope
Fields. The Scope Field Count MUST NOT be zero.
It should say:
Scope Field
Scope Fields are normal Fields, except that they are interpreted
as scope at the Collector.
Scope Field Count
Number of scope fields in this Options Template Record.
A scope field count of N specifies that
the first N Field Specifiers in the Template Record are Scope
Fields. The Scope Field Count MUST NOT be zero.
Notes:
Separate out the "Scope Field" definition from "Scope Field Count", since "Scope Field" is used as a defined term throughout the document without a formal definition.