Subject: [IPFIX] RFC 5101bis

From: Andrew Feren <[email-masked]>
Date: Tue, 10 Apr 2012 16:12:32 -0400

I noticed today that section 6.2 is named "Reduced Size Encoding of 
Integer and Float Types", but then in the first sentence  also lists 
"string" and "octetArray" types.

"Information Elements containing integer, string, float, and
    octetArray types in the information model MAY be encoded using fewer
    octets than those implied by their type in the information model"

I'm not sure how a type of string or octetArray implies a length.

It seems that the section should be renamed to be more generic (remove 
"Integer and Float Types")

In which case I assume rather than a size "implied by their type" the 
first paragraph should read something like.

"Information Elements containing integer, string, float, and
    octetArray types in the information model MAY be encoded using fewer
    octets than the specified maximum encoding size"

Or is reduced encoding intended only for integer types?

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Wed, 11 Apr 2012 17:24:22 +0200

Hi, Andrew,

Good points...

On Apr 10, 2012, at 10:12 PM, Andrew Feren wrote:

> I noticed today that section 6.2 is named "Reduced Size Encoding of Integer and Float Types", but then in the first sentence  also lists "string" and "octetArray" types.
> 

This is a terminology question, I think; strings and octetArrays can be any length, so it's not really "reduced length encoding".

> It seems that the section should be renamed to be more generic (remove "Integer and Float Types") 

Agreed.

> In which case I assume rather than a size "implied by their type" the first paragraph should read something like.
> 

This would be one good way to handle it.

> Or is reduced encoding intended only for integer types?

The fact that an Information Element inherently has a type which inherently has a length (except for strings and octetArrays), which may be different than the length for the IE specifier in a given template record (subject to certain restrictions: you can have a 3-byte unsigned64 but not a 3-byte float64, for instance) means no; however, there is a question as to what of this is reduced-length encoding and what is just "using templates".

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 11 Apr 2012 17:50:21 +0100

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.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Apr 2012 14:07:39 +0200

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:

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

---

From: Andrew Feren <[email-masked]>
Date: Tue, 17 Apr 2012 10:00:00 -0400

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