Re: [IPFIX] On Encodings in RFC5102bis

Hi Brian,

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

On 20.12.12 16:30, "Brian Trammell" <[email protected]> wrote:

>hi Juergen,
>
>The current revision has these changes in it; it's ready for write-up.
>
>Thanks, cheers,
>
>Brian
>
>On 20 Dec 2012, at 16:24 , Juergen Quittek wrote:
>
>> 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
>

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