Subject: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-03.txt

From: Nevil Brownlee <[email-masked]>
Date: Fri, 23 Nov 2012 16:47:29 +1300

Hi all:

Following up on Brian's email dated 20 November ...

The WG Last Call for this I-D starts now, and will run until Monday,
10 December.

Do please read the draft, and post your comments to the list.  It's
important that we can show it has been well-considered/reviewed within
the WG, so short comments like "yes, this does clearly describe the
IPFIX Information Model as we want it to be" are important and useful!

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Nov 2012 09:54:34 +0100

Dear all, Nevil,

Trying to avoid any potential confusing, correcting the subject to the 
correct draft name: draft-ietf-ipfix-protocol-rfc5101bis-03

Regards, Benoit

---

From: Andrew Johnson <[email-masked]>
Date: Wed, 28 Nov 2012 18:16:14 +0000

Hi folks

I have started looking through the changes and so far see the value in the various clarifications.  I'm a little concerned about the additional scope field being added to the Metering Process Statistics Options Template.  I see why that's been done, but what about existing implementations?

One minor point, in section 5:

   Certain time-related Information Elements may be expressed as an
   offset from this Export Time. For example, Data Records requiring a
   microsecond precision can export the flow start and end times with
   the flowStartMicroseconds and flowEndMicroseconds Information
   Elements [RFC5102bis], which encode the absolute time in microseconds
   in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit
   field. An alternate solution is to export the
   flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information
   Elements [RFC5102bis] in the Data Record, which respectively report
   the flow start and end time as negative offsets from the Export Time,
   as an unsigned 32-bit integer. This latter solution lowers the export
   bandwidth requirement, saving two bytes per timestamp, while
                                 ^^^^^^^^^^^^^^^^^^^^^^^
   increasing the load on the Exporter, as the Exporting Process must
   calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
   of every single Data Record before exporting the IPFIX Message.

Isn't it saving 4 bytes per timestamp?

Regards, Andrew

On 23 Nov 2012, at 03:47, Nevil Brownlee <[email-masked]> wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix