Pasi,
Understood.
Tagging should not be used. Tagging is for grouping not for fragmentation.
If I use tagging for fragmentation then what will I use for grouping when I want to group things together?
I have to read the draft. Is permit/deny allowed inside the attribute because we are allowed to include more then one rule inside the packet? If that is the case IMO we should not do that. One rule per attribute.
If we want to solve fragmentation in general then inserting a value inside the attribute will not work. I think we have to invent something in the header of the attribute.
For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.
Why don't we hold this work until we can agree on the Diameter AVP?
-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Sat 7/8/2006 11:08 AM
To: Avi Lior; radiusext@ops.ietf.org
Subject: 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
> 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