Re: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt

["Alan DeKok" <aland@ox.org>]

gwz@cisco.com wrote:
> I don't think that it's necessary: you could just define the real
> value of Large-Attribute as the concatenation of the String fields
> of all the Large-Attribute Attributes in the message, since
> Attributes are guaranteed now to maintain relative order; that
> wasn't true when RFC 2868 was undertaken.

  Sure.  My thought originally was backwards compatibility with
servers that *don't* maintain relative order, but that's neither here nor there.


  What of the discussion of packing Diameter attributes inside of
RADIUS attributes?  I haven't seen your draft (reference?), but as an
implementor, I'm leery of yet another packing format for attributes.
It makes implementation harder, interoperability becomes more
difficult, and code re-use goes down.

  My preference would be to define "Diameter-Attributes", which would
pack one or more Diameter attributes, in the Diameter format.  There
should be additional requirements on those attributes (e.g. non-VSA's,
Mandatory bit must be set), which limit the attributes to a known
subset of Diameter that is compatible with RADIUS.

  Alan DeKok.

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