Re: [IPFIX] RFC 5101bis

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