Re: [IPFIX] On Encodings in RFC5102bis

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 protected]> wrote:

>+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

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