Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

[Barney Wolff <barney@databus.com>]

On Wed, Oct 04, 2006 at 01:00:10PM -0400, Avi Lior wrote:
> 
> Do you think that allowing 62 NAS Filter rules per message is limiting?

Yes, definitely.

> If yes then I suggest that even with the existing text we have an
> unreasonable limitation since I can only support 61 NAS Filter Rules per
> message that overflow.

Well, no.  4096/255 is about 16.

> > Why would we want to hide from the receiver whether a rule is 
> > going to be segmented?
> 
> We are not.  The receiver can easily detect that a rule is a
> continuation.

Only when it sees the continuation, if every rule needs a unique tag.
It would be useful, potentially, to know when seeing the first part of
the rule that there is more to come.

> Note that both approaches (or all approaches) presented so far have a
> flaw in that they will prevent us from grouping NAS-Filter-Rules into
> groups of rules.  This could be harmful in the future.  We arleady see
> evidence that a filter-rule can be used for several purposes.  We wont
> be able to express these in RADIUS.

There was an attempt to provide such power for RADIUS, by adopting the
Diameter attribute header.  It did not meet with group approval.  Of
course I would prefer to see a general mechanism for handling both
grouping and segmentation, rather than have to debate it over again
for every attribute that might need such facilities.

-- 
Barney Wolff         I never met a computer I didn't like.

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