RE: RADEXT charter, Take 8

[Parviz Yegani <pyegani@cisco.com>]

David,

You said you wanted to look at specific issues:
 
Specifically looking at ARAP-Password and the
attributes in Sterman or Prepaid
 
All these uses seem to gather related
information together.
 
The only difference is the way the encoded the
various Sub-Attributes that they contain.
ARAP uses fixed length encoding, while Prepaid and Sterman use TLV
encoding.  
 
ARAP doesn't break dictionaries.
 
Given the above I don't see what the problem
is?

-Parviz

At 10:22 AM 3/25/2004 -0500, Nelson, David wrote:
> Parviz Yegani writes...
>
> > Why do you think that there is consensus against encoding 
> > multiple data elements in a string attribute?
>
> Why?  Because RADIUS has always had a very simple,
> straightforward
> encoding of data elements in AVPs, in TLV format.  One data element;
> one
> attribute.
>
> > I agree with Wolfgang and others that someone must
> > show that structured string attributes would break existing 
> > (standard-compliant) Radius implementations.
>
> Hmmm...  I guess if the evidence presented to date does not
> convince
> you, then it entirely possible that you will never be convinced. 
> Maybe
> it has to do with how one defines "break".  I define it as
> (a) deviation
> from the established protocol model, and (b) requiring changes to
> the
> protocol parsing engine of RADIUS implementations (as opposed the
> changes in the semantics enforcement engine, which is obviously
> required
> each time a new data element is introduced).
>
> > I agree with Avi's comment above that a string attribute
> containing
> > multiple elements of data
> > is already in common use in RADIUS and DIAMTER, no?
>
> For what definition of "common"?  Do you mean within RFCs
> approved by
> IETF Standards Action?
>
> -- Dave
>
>
>
> --
> 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/>