errata logo graphic

Found 3 records.

Status: Verified (1)

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

Source of RFC: ipfix (ops)

Errata ID: 4396

Status: Verified
Type: Editorial

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 (2)

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

Source of RFC: ipfix (ops)

Errata ID: 3732

Status: Held for Document Update
Type: Editorial

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

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.


Report New Errata