Re: Questions on modified Extended Attribute format?

[Alan DeKok <[e-mail]>]

Glen Zorn wrote:

> As I said, put that way or any other way you like, ANY change is
> incompatible with existing deployments.  If one were to add a new "standard"
> attribute (in the old format or the proposed VSA-like format or any other)
> it would be incompatible with existing deployments.

  That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.

  i.e. if a product doesn't implement the new standard, it can still
communicate with products that do implement that standard.

  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.

  i.e. your proposal creates a new protocol that is incompatible with
legacy RADIUS.

> Actually, while the timeframe was long, the discussion wasn't: I've only
> received a couple of comments on it in the last months.  It _did_ take an
> inordinate amount of time to reject the 'Diameterization' of RADIUS,
> though...

  This proposal is no better.  It's worse in many respects.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>