The use of a separate fragment-data attribute raises more ordering dependency questions. From a design POV I prefer the attributes to be self-contained within the same type. What happens when there are multiple ext frag attributes in the same request with different attribute id's (245,246) ?
My message describes how they're treated. Ordering *is* important.
There is no RFC anywhere preventing reorder and as you mention how do you know which fragment is which or when one stops and the other starts?
My message describes how to detect when a fragment starts and stops.
Yes, think we agree on the constraints. Packet wide ordering would need to be preserved.
My suggestion is to keep the draft as is but add an explicit fragment counter next to the more flag using some or all of the remaining 7-bits. Since max RADIUS packet size is 4096 there are more than enough bits.
One issue is having a "fragment id" field means there's another opportunity for implementations to get the encoding wrong. And there's been talk of extending the maximum RADIUS packet size.
I believe practically if this type of encoding were wrong the situation would be detected quickly in any reasonable interop test. It is the not so obvious interactions between systems and extension attributes I'm most concerned about.
I also prefer fragmentation occur on the same level of the attribute like WiMax VSAs where the attributes inner type is fully defined before the fragmentation payload so there can never be any ambiguity regarding at least the attribute type the fragment belongs.
The difficulty with that is that the fragmentation method *cannot* modify how the VSA space is encoded. That space is completely under control of the vendors.
Don't think this applies to extensions VSAs. In 4.6 Vendor Type is explicitly defined as a single byte.
"The Vendor-Type field is one octet. Values are assigned at the sole discretion of the Vendor."
This type has a more flag so thinking we would expect the same encoding rules for all extensions VSAs where it came to fragmentation.
The counter makes it easier to detect re-ordered attributes, that's true.With the above Counter fields in the picture this preference does not matter as much and perhaps saving the extra byte(s) is the better tradeoff.
Changing the "more" flag to an 8-bit fragment counter would solve a number of issues. You would have an explicit ordering of fragments, and it would mean that attributes could be 251*255, or 64005 octets long. That *should* be enough for most RADIUS purposes...
If I had to choose between a more flag and the counter I would pick the counter.
Prefer combination of more and counter since it gives you the end marker to detect truncation.
regards, Peter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>