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

["Avi Lior" <avi@bridgewatersystems.com>]

Okay Barney.

So at one hand having 61 rules is definitely limiting -- that is you see
an application that would require more then 61 rules.  Therefore
regardless of how we handle fragmentation, by the same token 16 rules
will not sufficie either and we need another solution whereby we can
send on the order of 60 rules whether they fragment or not.

But realistically, perhaps we need in the order of 10 rules where some
may overflow - or something like that.

With respect to apriori knowledge of RADIUS client knowing about
fragementation, I agree that it is an advantage but only marginally.

The current scheme has issues as I pointed out in the first email.

BTW you can have grouping and fragmentation if you use the approach
whereby you use the most significant bit of the TAG as fragmentation
bit.  The rest of the bits of the tag are used for grouping.

If you don't have fragmentation the the MSB is clear.  If you have
fragmentation the MSB is set.

If you don't have grouping the 7 LSBs are zero, if you do have grouping
then the 7LSBs indicate the group id.

So we can have our cake an eat it too!!!
 

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Wednesday, October 04, 2006 1:35 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: Proposed Resolution to Issue 198: Attribute 
> Concatenation/Splitting
> 
> 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/>