[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue: Attribute concatenation/splitting
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
> 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
> 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).
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.