Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852)

[Andrew Feren <[e-mail]>]

The encoding for the time data types is specified RFC 7011 Sections
6.1.7 through 6.1.10.

-Andrew

On 12/30/2013 10:13 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC7012,
> "Information Model for IP Flow Information Export (IPFIX)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852
>
> --------------------------------------
> Type: Technical
> Reported by: Stewart Bryant <[e-mail]>
>
> Section: 3.1.15-17
>
> Original Text
> -------------
> 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.
>
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
>
> --------------------------------------
> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10)
> --------------------------------------
> Title               : Information Model for IP Flow Information Export (IPFIX)
> Publication Date    : September 2013
> Author(s)           : B. Claise, Ed., B. Trammell, Ed.
> Category            : PROPOSED STANDARD
> Source              : IP Flow Information Export
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix