RE: Issue: Attribute concatenation/splitting

[<Pasi.Eronen@nokia.com>]

Avi Lior wrote:

> I think we should not allow to pack more then one Filter Rule in a
> single attribute.
> 
> A Filter Rule should be allowed to overflow (span) more then one
> attribute.
> 
> If you have more then one filter rules in a packet with some filter
> rules overflowing, how can you tell when a new one begins?
> 
> A filter rule always starts with an action: permit or deny.  These
> words do not appear anywhere else in the rule.  Therefore a Filter
> Atribute that starts with a permit or deny must be a new filter
> rule.
> 
> What is wrong with that?

It requires code specific to this attribute in RADIUS clients,
servers, and RADIUS<->Diameter translation agents. And that code 
cannot be reused for other attributes: e.g. in the current 
NAS-Traffic-Rule draft, the words "permit"/"deny" can appear in 
the  middle of a rule.

Yes, this would work for NAS-Filter-Rule -- but so would any of the
other proposals so far (e.g. rules end with LF; rule ends if 
attribute length <253; attributes begin with a tag octet; etc.)  
I don't think any of these proposals is a really good one, but at 
least the same approach could be reused for NAS-Traffic-Rule (and 
maybe other attributes in the future as well).

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