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

From: RFC Errata System <[email-masked]>
Date: Mon, 30 Dec 2013 07:13:31 -0800 (PST)

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 <[email-masked]>

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

---

From: Andrew Feren <[email-masked]>
Date: Mon, 30 Dec 2013 11:23:19 -0500

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:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 30 Dec 2013 19:58:51 -0700

+1

If anyone was going to raise an errata on this, it would have been me ;-)

I've pointed this issue out before, probably more than once - and have 
been encouraged to read RFC 3444.

P.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 Dec 2013 09:50:11 +0100

hi Paul, all,

+n.

The separation between ADTs and ADT encoding between 7012 and 7011 was explicit and purposeful. Specifically, we do _not_ want to exclude other representations of the IPFIX Information Model from being based upon other encodings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day based counting, etc, etc, etc…

If there is confusion on this point, I’d suggest adding more explanatory text on this point to Paragraph 2 of the front matter to section 3.1. But as is, I emphatically recommend rejection of this reported erratum.

Best regards,

Brian

On 31 Dec 2013, at 03:58, Paul Aitken <[email-masked]> wrote:

> I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444.
> 
> P.
> 
>

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Tue, 31 Dec 2013 09:36:54 +0000

Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete. I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.

You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.

Stewart

Sent from my iPad

> On 31 Dec 2013, at 08:50, "Brian Trammell" <[email-masked]> wrote:
> 
> hi Paul, all,
> 
> +n.
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 Dec 2013 13:44:02 +0100

hi Stewart,

Stewart Bryant (stbryant) wrote:
> Certainly something is needed. I was thinking of using IPFIX as an information gathering method in a radio context, and went to look at the definition of the types and could not find the epoch, or even a reference to the epoch. Now part of the problem (which was my fault) was that I did not notice at the time that the elements were defined by the obsolete RFC5102 and went straight to the new RFC. However having the definitions in an obsolete RFC also seems problematic, since it puts the IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the definitions you would expect the definition in RFC7012 to replace the definition in RFC5102, but those definitions are, as I explained incomplete.

This is intentional. See below.

> I need to look at this some more when I get back to work, but I am now also concerned that if the epoch can change, the definition of the existing IEs is now unreliable.

The definition of the existing IEs is based upon the definition of the
ADT itself in 7012 as well as the definition of the ADT representation
within the IPFIX protocol in 7011. It is not the intention that reading
7012 tells you how to encode IEs for use with IPFIX; that's what section
6.1 of 7011 is for.

> You will notice in the errata that I did suggest that an alternative resolution would be to include a reference to the epoch text.

The point is that the ADT _explicitly_ does not have a binding to an
epoch, as epochs are only necessary when using integral representations
of timestamps. IPFIX's representations for these ADTs are integral, but
bindings to other representations need not be (see, for example,
draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps
for textual representations of IE values).

I'd suggest instead somehow expanding the present text in 7012 to
reiterate that if you're using IPFIX, the representations of the ADTs
are in 7011:

OLD para 2 sec 3.1 7012:

   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.

NEW para 2 sec 3.1 7012:

   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.

Best regards,

Brian