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

[Barney Wolff <barney@databus.com>]

On Wed, Oct 04, 2006 at 10:15:01AM -0700, Bernard Aboba wrote:
> >Why would we want to limit the number of possible rules?
> 
> I don't think we want to do that.  As a Glen has pointed out, there are 
> deployments in which a very large number of rules are being used.
> 
> >Why would we want to hide from the receiver whether a rule is going
> >to be segmented?
> 
> It's probably best not to hide that from the receiver.
> 
> >	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.
> 
> So if a continued filter is followed by a non-continued one, then we have 
> two attributes with zero (0) tag fields?

Yes.  What's wrong with that?

> Why not just say that the tag field needs to be different between adjacent 
> filter rules, with the exception of a zero tag that represents a 
> non-continued filter rule?

A rule may potentially need more than two segments.  The receiver might
like to be able to predict whether a rule is 504 octets or >=505 before
seeing the next attribute.

Once we're using the Tag only for continuation, and not for grouping,
it really is a 1-bit field, and different nonzero values convey no
meaning.  If we want grouping as well, Avi's idea of using the hi-bit
of the Tag for continuation is a good one, at the cost of making it 
harder to enter the value by typing ASCII.  Perhaps we should use the
low-bit for continuation, leaving the high 7 for grouping.

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