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

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

Barney,

Do you think that allowing 62 NAS Filter rules per message is limiting?

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.

I just think that allowing for 62 per packet is more then enough.

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

If you want we can use the MSB to indicate whether an attribute is
continuation or not.  This is what I am proposing for Extended RADIUS.

> The "TAG thing" is very complex because we're using an 8-bit 
> field to convey 1 bit of meaning.  We could just as well say:
> 
> 	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
> 	continuation of this one.  If TAG is zero, this attribute is
> 	the last or only segment of this rule.
> 
> The attempt to reuse the existing tag mechanism has failed.  
> It's time to move on.

So I agree with that as well.

This is another issue.

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.



> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Wednesday, October 04, 2006 12:38 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 12:22:41PM -0400, Avi Lior wrote:
> > 
> > This TAG thing is very complex. We can get rid of the '0' tag 
> > requirement by saying that every NAS Filter Rule MUST have a unique 
> > non-zero TAG value in the range of 0x01 to 0x3F.
> > If an NAS filter rule attribute needs to be fragmeneted (length is 
> > greater then 252) then the fragments is placed in a subsequent 
> > NAS-Filter-Rule attribute and the same TAG value is used.
> 
> Why would we want to limit the number of possible rules?
> Why would we want to hide from the receiver whether a rule is 
> going to be segmented?
> 
> The "TAG thing" is very complex because we're using an 8-bit 
> field to convey 1 bit of meaning.  We could just as well say:
> 
> 	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
> 	continuation of this one.  If TAG is zero, this attribute is
> 	the last or only segment of this rule.
> 
> The attempt to reuse the existing tag mechanism has failed.  
> It's time to move on.
> 
> -- 
> 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/>