Re: [IPFIX] On Encodings in RFC5102bis

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

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix