Subject: [IPFIX] On Encodings in RFC5102bis

From: Brian Trammell <[email-masked]>
Date: Fri, 14 Dec 2012 11:54:40 +0100

Greetings, all,

In reviewing WGLC comments on 5101bis, specifically with respect to timestamp wraparound (on which I'm still working on a response), I had a look at RFC5102bis to see if the text there would be compatible with such a thing. The sections describing the POSIX-based abstract data types which include, unlike the others, encoding details; I would suggest removing the encoding details, leaving them for RFC5101bis (and alternate encodings, as in draft-trammell-ipfix-text-adt), to be consistent with the rest of RFC5102bis.

OLD:

3.1.15.  dateTimeSeconds

   The data type dateTimeSeconds is an unsigned 32-bit integer
   representing the number of seconds since the UNIX epoch, 1 January
   1970 at 00:00 UTC, as defined in [POSIX.1].

3.1.16.  dateTimeMilliseconds

   The data type dateTimeMilliseconds is an unsigned 64-bit integer
   containing the number of milliseconds since the UNIX epoch, 1 January
   1970 at 00:00 UTC, as defined in [POSIX.1].

NEW:

3.1.15.  dateTimeSeconds

   The data type dateTimeSeconds represents
   the number of seconds since the UNIX epoch, 1 January
   1970 at 00:00 UTC, as defined in [POSIX.1].

3.1.16.  dateTimeMilliseconds

   The data type dateTimeMilliseconds represents
   the number of milliseconds since the UNIX epoch, 1 January
   1970 at 00:00 UTC, as defined in [POSIX.1].

(The reference to [POSIX.1] remains necessary to clarify leap second issues; i.e., this value is can be directly derived from the system clock on a UNIX-like machine).

While reviewing this, I noticed that there's one other encoding-specific as opposed to data-specific ADT: macAddress. I'd suggest the following change as well:

OLD:

3.1.12.  macAddress

   The type "macAddress" represents a string of 6 octets.

NEW:

3.1.12.  macAddress

   The type "macAddress" represents a MAC-48 address.

I'd specify MAC-48 as opposed to EUI-48, because it's not clear that require global uniqueness. On this point, does anyone know of the correct reference to use here? I've been looking at various 802 cross-references in RFCs but can't find anything that fits yet...

Comments? Even a "looks good" would be helpful. I'd like to make this last change soon, so an -08 revision can be written up and sent up to the IESG.

Thanks, cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Fri, 14 Dec 2012 11:39:23 +0000

Brian,

This seems good to me.

MAC-48 seems correct. I don't have a good reference; IANA's IPFIX 
registry cites "IEEE.802-3.2002"; googling this just produces lots of 
IPFIX hits :-)

BTW:

1. I've just asked IANA to convert links in the IPFIX registry from 
plain text into active links.

2. It'd be handy if we had active links to all the IEEE docs xref'd in 
the registry. However, some of them seem to be superseded or expired and 
no longer available to download.

P.

On 14/12/12 10:54, Brian Trammell wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Fri, 14 Dec 2012 09:44:48 -0500

Hi Brian,

That all looks good.

-Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Mon, 17 Dec 2012 11:04:02 +0000

+1

Andrew

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 20 Dec 2012 15:24:02 +0000

Hi Brian and all,

Does this mean we should delay the write-up until you have posted an
updated version?

Thanks,
    juergen

On 17.12.12 12:04, "Andrew Johnson" <[email-masked]> wrote:

>>> In reviewing WGLC comments on 5101bis, specifically with respect to
>>>timestamp wraparound (on which I'm still working on a response), I had
>>>a look at RFC5102bis to see if the text there would be compatible with
>>>such a thing. The sections describing the POSIX-based abstract data
>>>types which include, unlike the others, encoding details; I would
>>>suggest removing the encoding details, leaving them for RFC5101bis (and
>>>alternate encodings, as in draft-trammell-ipfix-text-adt), to be
>>>consistent with the rest of RFC5102bis.
>>> 
>>> 
>>> OLD:
>>> 
>>> 3.1.15.  dateTimeSeconds
>>> 
>>> (The reference to [POSIX.1] remains necessary to clarify leap second
>>>issues; i.e., this value is can be directly derived from the system
>>>clock on a UNIX-like machine).
>>> 
>>> 
>>> While reviewing this, I noticed that there's one other
>>>encoding-specific as opposed to data-specific ADT: macAddress. I'd
>>>suggest the following change as well:
>>> 
>>> 
>>> OLD:
>>> 
>>> 3.1.12.  macAddress
>>> 
>>> I'd specify MAC-48 as opposed to EUI-48, because it's not clear that
>>>require global uniqueness. On this point, does anyone know of the
>>>correct reference to use here? I've been looking at various 802
>>>cross-references in RFCs but can't find anything that fits yet...
>>> 
>>> Comments? Even a "looks good" would be helpful. I'd like to make this
>>>last change soon, so an -08 revision can be written up and sent up to
>>>the IESG.
>>> 
>>> Thanks, cheers,
>>> 
>>> Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Dec 2012 16:30:38 +0100

hi Juergen,

The current revision has these changes in it; it's ready for write-up.

Thanks, cheers,

Brian

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 21 Dec 2012 09:53:57 +0000

Hi Brian,

OK. Thanks.  
I'll do the write-up.
    Juergen