RFC Errata
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