RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 3881
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Brian Trammell
Date Reported: 2014-02-05
Verifier Name: Benoit Claise
Date Verified: 2014-03-02

Section 3.1 says:

The current encodings of these data types for use with the IPFIX 
protocol are defined in [RFC7011]; encodings allowing the use of 
the IPFIX Information Elements [IANA-IPFIX] with other protocols 
may be defined in the future by referencing this document.

It should say:

The abstract data type definitions in this section are intended 
only to define the values which can be taken by Information 
Elements of each type. The encodings of these data types for 
use with the IPFIX protocol are defined in Section 6.1 of 
[RFC7011]; encodings allowing the use of the IPFIX Information 
Elements [IANA-IPFIX] with other protocols may be defined in 
the future by referencing this document. Note that for timestamp 
encodings (sections 3.1.15 - 3.1.18), it is the responsibility of 
the encoding to ensure that each representation has an 
unambiguous mapping to a moment in time (e.g. relative to a 
defined epoch).

Notes:

The separation of epoch selection between ADT and encoding in 7011 and 7012 (as compared to 5101 and 5102, which they obsolete, respectively) led to it being unclear that timestamp ADTs require a fixed reference epoch for interpretation. This change clarifies the point, replacing Errata ID 3852.

Status: Held for Document Update (1)

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 6564
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Paul Aitken
Date Reported: 2021-04-28
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15

Section 7.2 says:

   The specification
   of new MPLS label types MUST be published using a well-established
   and persistent publication medium.

It should say:

(Deleted)

Notes:

This paragraph envisaged that a new RFC be written to specify new label types in the mplsTopLabelType sub-registry.

Since the publication of RFC7012, IANA has added 16 other IPFIX IE sub-registries, none of which have the same requirement. See https://www.iana.org/assignments/ipfix/ipfix.xhtml

Publication in IANA's IPFIX registry should provide a clear and persistent definition. New IPFIX MPLS label type specifications should not be singled out to require persistent publication of an additional document.

Status: Rejected (1)

RFC 7012, "Information Model for IP Flow Information Export (IPFIX)", September 2013

Source of RFC: ipfix (ops)

Errata ID: 3852
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Stewart Bryant
Date Reported: 2013-12-30
Rejected by: Benoit Claise
Date Rejected: 2014-03-02

Section 3.1.15-17 says:

3.1.15. dateTimeSeconds

   The type "dateTimeSeconds" represents a time value expressed with
   second-level precision.

3.1.16. dateTimeMilliseconds

   The type "dateTimeMilliseconds" represents a time value expressed
   with millisecond-level precision.

3.1.17. dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value expressed
   with microsecond-level precision.

3.1.18. dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value expressed with
   nanosecond-level precision.

It should say:

3.1.15. dateTimeSeconds

   The type "dateTimeSeconds" represents a time value in units of
   seconds based on coordinated universal time (UTC).  The choice of an
   epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

   The type "dateTimeMilliseconds" represents a time value in units of
   milliseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value in units of
   microseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value in units of
   nanoseconds based on coordinated universal time (UTC).  The choice of
   an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

Notes:

Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC.

Without a specified epoch, there is no unique definition of the timestamps.

My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102.
--VERIFIER NOTES--
Reject reason: issue addressed in errata 3881

Report New Errata



Advanced Search