RE: Issue: Attribute concatenation/splitting

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> I guess this means that a single long rule can be split into multiple
> NAS-Filter-Rule attributes?

Yes.

> And a single NAS-Filter-Rule attribute could contain pieces of multiple 
> rules?

Yes.

BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in RFC 
4005?

> If so, I'd recommend separating the individual rules somehow.

Question:  Does introducing a separator into NAS-Filter-Rule attribute 
complicate the translation to and from NAS-Filter-Rule AVP?

For example, can we have multiple filter rules in a NAS-Filter-Rule AVP, and 
if so, how do we tell when one rule ends and another begins?

> In the current version of
> NAS-Traffic-Rule each individual rule ends with LF, making it easy to
> determine where one rule ends and another one begins. I'd suggest
> adopting this same convention for RADIUS NAS-Filter-Rule.

NAS-Traffic-Rule gets to define both the RADIUS attribute and Diameter AVP, 
so as to ensure easy translation between them.   Whereas NAS-Filter-Rule 
attribute definition has to deal with the definition of NAS-FilterRule AVP 
in 4005.   So the Diameter considerations for the two attributes may be 
different even though they are similar.


> This concatenation/splitting has also implications for Diameter
> translation (Section 4): AVPs coming from Diameter side may have to be
> split to several RADIUS attributes (and rule delimiters added), and
> attributes coming from RADIUS side have to be concatenated/split to
> Diameter AVPs (and rule delimiter removed).
>
> 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/>



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