[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Strawman RADIUSEXT WG charter
> -----Original Message-----
> From: Bernard Aboba [mailto:firstname.lastname@example.org]
> Sent: Thursday, August 21, 2003 4:50 PM
> To: Avi Lior
> Cc: 'Greg Weber'; 'email@example.com'
> 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
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.