RE: Issue: Attribute concatenation/splitting

[<Pasi.Eronen@nokia.com>]

rajithr@huawei.com wrote:

> AFAIK, splitting & concatenation are necessitated by the 255 byte
> limit for RADIUS attributes. So it would be better to split at 253
> byte (for the attribute payload) boundary rather than LF or some
> other attribute specific delimiter, I think this would have the
> advantage of
> * same & simple logic for concatenation/splitting of any 
> suitable RADIUS attribute of length > 255
> * packing efficiency in the message, though not a principal concern

This simple concatenation/splitting works when you need to include a
single, potentially long data item (e.g. EAP-Message) in a RADIUS
message. But it gets complex if you need to include multiple,
potentially long data items of the same type (in this case, individual
filter rules) and you need to maintain the boundaries between the
individual data items somehow.

In particular, if we decide to support individual filter rules longer
than 253 characters, it looks like a RADIUS-to-Diameter translation
agent will need code specific to NAS-Filter-Rule no matter how we
choose to do the concatenation/splitting on the RADIUS side. The
difference is just how complex that code needs to be (e.g., is it
sufficient just to recognize "LF", or understand the full filter
rule syntax).

Best regards,
Pasi

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