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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <> supposedly scribbled:

> 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 

It's not mine, it belongs to Paul Congdon, Chuck Black & Bernard --
that's why I addressed my initial question to them instead of the
WG.

> (reference?), 

http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-02.
txt

> 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), 

Don't forget the length limit!

> which limit the attributes to
> a known subset of Diameter that is compatible with RADIUS.    
> 
>   Alan DeKok.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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