RE: Strawman RADIUSEXT WG charter

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, August 21, 2003 4:50 PM
> To: Avi Lior
> Cc: 'Greg Weber'; 'radiusext@ops.ietf.org'
> Subject: RE: Strawman RADIUSEXT WG charter
> 
> 
> > Hi Greg,
> > I am readying an individual submission for AVP extension 
> which could 
> > address your length extension issue.  Take a look at 
> > 
> http://www.lior.org/standards/ietf/radiusext/d> raft-lior-radius-attribu
> > te-typ
> > e-extension-00-1.rtf
> >
> > In my proposal if we make the extended attribute length 2 
> octets then 
> > if Extended Attribute is longer then its container (the 
> specail RADIUS 
> > VSAs) then the attribute would span multiple consecutive VSAs.
> >
> > Will that work for you?  I would apperciate any comments on this 
> > document.
> >
> > I will be sumitting it shortly.
> 
> The existing RADIUS VSA mechanism enables merging of 
> attributes without an additional length field, so it's not 
> clear to me why this would be necessary.

I don't follow your point.  Can you explain?

> Also, Diameter already has a 32-bit attribute field so 
> allowing that many RADIUS attributes would seem to create 
> Diameter incompatibilities -- how would you map RADIUS 
> attributes to Diameter?

We are not introducing 32bit RADIUS attribute types.  We are introducing a
mechanism for encoding 32bit RADIUS attributes within a VSA not at a top
level.  Therefore there should not be any Diameter incompatiblity.

Diameter will simply encode these RADIUS attributes the way it will encode
any VSA.

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