RE: Issue 38 - Ordering of filter attributes

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior Writes...

> What I am trying to say is that: when a NAS receives multiple
> NAS-Filter-Rule attributes it has to reconstruct the list.  In doing
that
> task it has to be mindfull that some of the Filter-Rules may span more
> then one NAS-Filter-Rule attribute.

Why is that a requirement?  Wouldn't it be simpler to specify that a
single rule does not span more than one attribute?  In that scenario,
the software that packs the attributes would keep track of the remaining
space, and would start a new attribute instance if the next rule to be
packed was longer than the remaining space.  This avoids the need for
any form of fragmentation bit or continuation flag.

Yes, it may result in slightly lower efficiency in packing rules into an
Access-Accept packet.  I've heard the discussion about "huge sets of
rules".  I guess I'm not overly sympathetic.  That's one reason that the
original RADIUS WG devised the named rule scheme for Filter-ID, so that
arbitrarily complex sets of rules could be provisioned by out of band
means (FTP, TFTP, SNMP, HTTP, etc.).

I think the simplicity obtained in forcing individual (atomic) rules to
fit in their entirety within a single attribute (no fragmentation) is
worth the tradeoff of having a larger number of rules, or a larger
number of attributes, in the Access-Accept packet. 



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