Re: [IPFIX] On Encodings in RFC5102bis
Andrew Johnson <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
+1 Andrew On 14 Dec 2012, at 14:44, Andrew Feren <[email protected]> wrote: > Hi Brian, > > That all looks good. > > -Andrew > > On 12/14/2012 05:54 AM, 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 _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix