Re: [IPFIX] RFC 5101bis

Hi Brian,

I don't see much point in a reduced encoding for dateTimeSeconds since 
we clarified it in 5101bis to be an unsigned 32 bit integer having a 
start epoch of 1 January 1970.  3 bytes only allows dates into July of 
1970 which doesn't seem particularly useful.

As for dateTimeMilliseconds and dateTimeMicroseconds I am currently 
ambivalent on whether these MUST NOT be exported with reduced length 
encoding.  I haven't tried, but I believe that if I was sent a reduced 
encoding of one of these that everything would just work.  Different 
implementations may be less forgiving.

-Andrew


On 04/17/2012 08:07 AM, Brian Trammell wrote:
> Hi, Paul, Andrew,
>
> Well, that's unfortunate.
>
> One open question that came up as I was clarifying this section... We definitely support reduced length encoding for the following types:
>
> unsigned16, unsigned32, unsigned64
> signed16, signed32, signed64
> float64 (reduce only to 4-byte float32)
>
> The following types have no length inherent to the type (though may represent IEs with their own length restrictions, a note that should be added to section 6.2):
>
> octetArray, string
>
> The following types have internal structure and therefore cannot be reduced:
>
> ipv4Address, ipv6Address, macAddress
> dateTimeMicroseconds, dateTimeNanoseconds
>
> Which leaves us with dateTimeSeconds, dateTimeMilliseconds, and dateTimeMicroseconds. 5101 is silent on whether these can be reduced or not, which implies that they MUST NOT be exported with reduced length encoding; I think we want to clarify that directly in 5101bis, though I don't have a good justification therefor. Certainly there are range limitations (dateTimeMicroseconds can cover a 2300 year span with 7 bytes, and dateTimeMilliseconds can cover a 9000 year span with 6, though these seem like a whole lot of work for very little optimization), which are probably good enough...
>
> Thoughts?
>
> Thanks,
>
> Brian
>
> On Apr 11, 2012, at 6:50 PM, Paul Aitken wrote:
>
>> Brian,
>>
>>> there is a question as to what of this is reduced-length encoding and what is just "using templates".
>> If 5102 and IANA's IPFIX registry didn't list field sizes, then this would just be "using templates".
>>
>> However, since they do specify sizes, this is reduced-length encoding in most cases (ie, excepting strings / arrays).
>>
>> There's at least one tool which expects the 5102/IANA sizes, regardless of what the template says :-(
>>
>> P.


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