Re: RADIUS Design Guidelines

[Barney Wolff <barney@databus.com>]

On Mon, Aug 28, 2006 at 10:02:33AM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <> scribbled on Monday, August 28, 2006 9:30 AM:
> 
> > On Mon, Aug 28, 2006 at 11:54:21AM -0400, Nelson, David wrote:
> >> 
> >> The currently evolving proposals for Extended Attributes, solve some
> >> of the issues that have been identified in the Design Guidelines
> >> draft: shortage of attribute IDs, grouping of attributes, and an
> >> explicit method of fragmentation and reassembly.
> > 
> > I'm confused.  I thought the tag was being used for fragmentation and
> > reassembly, which would seem to preclude its use for grouping.  
> > Can somebody clarify?  
> > 
> 
> We already know how to send & receive XL attributes, via in-order
> fragmentation, transmission & concatenation.  There is no need to use
> tags for this.  The limitation of using tags to group attributes in
> conjunction w/this traditional method is that only one XL attribute of a
> given (extended) type can belong to a group.  If this is a serious
> problem, then some method of distinguishing the beginning of a new
> attribute from the middle of the previous one would be required.

We do?  I know that's been specified for EAP-Message, but if it's been
said anywhere as applying to attributes in general I must have missed it.

> > My own preference would be to use an extended-type of 0 to indicate
> > continuation, rather than the tag field.  
> 
> If we use anything like the customary method of dealing w/XL attributes,
> there doesn't seem to be any need for continuation indicator: an
> attribute starts & continues until a) another attribute starts or b) the
> end of the message is reached.

Again, I'm just confused.  I thought that multiple instances of a given
attribute were taken as multiple instances, not fragmented pieces of a
single longer attribute.  I'd appreciate a pointer to an RFC stating
otherwise in the general case.  Certainly there's been discussion of
how, if the instances are just glommed together, to parse that into
multiple filter rules, for example (and again, I'd really hate to see
such parsing have to be type-specific).  I apologize to all if I've
really missed a decision taken and documented.

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