Movatterモバイル変換


[0]ホーム

URL:


Search RFCs

Advanced Search

RFC Editor

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



IABIANAIETFIRTFISEISOCIETF Trust
ReportsPrivacy StatementSite MapContact Us

Advanced Search

[8]ページ先頭

©2009-2026 Movatter.jp