[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RADEXT charter, Take 8

Hello, David,

Comments inline ...

At 08:10 AM 3/25/2004 -0500, Nelson, David wrote:
Avi Lior writes...

> Point 1:
> An attribute of type string containing multiple elements of data is
> already in common use in RADIUS and DIAMTER.  We already gave you
> lots of examples of that.

Lots?  Hmmm.  I agree that there are a few uses of string attributes, in
which RADIUS or Diameter client/proxy/server implementations are
expected to parse a string according to some syntax rules.  Most notably
for routing decisions (e.g. NAI).  My point is that we ought not to open
up the usage of string attributes that require parsing by RADIUS (or
Diameter), in such a fashion that we've effectively abandoned the
current TLV/AVP approach to structuring information.

I'm not sure that continuing debate on this point in the abstract will
shed any further light. It may be better to pick certain examples from
the proposed drafts.

Good idea. Let's do that.


> Point 2:
> Seems to me that you are the only one having issues with this.
Looking at
> past emails the consensus seems to be that Attribute falling into my
point
> 1 (above) are okay.

I'm not sure I agree with your assessment, without reviewing the
archive.  However, I think the key issues with consensus acceptance of
strings is whether they fall into one of two cases: (a) limited parsing
is absolutely required, as in the case of NAI, or (b) RADIUS doesn't
*ever* parse the strings, it passes them as opaque "binary blobs" to
some other protocol, as in the case of EAP-Message.  In order to qualify
as "some other protocol", the elements, syntax and semantics of that
protocol can't be defined in a RADIUS or Diameter RFC.

To the extent that there is consensus against the usage of sub-types, in
a non backward compatible fashion, I think there is also consensus
against encoding the same sub-attributes in string values, as a way to
"get around" the limitation.

Why do you think that there is consensus against encoding multiple data elements
in a string attribute? I agree with Wolfgang and others that someone must show that
structured string attributes would break existing (standard-compliant) Radius
implementations.

To me, a sub-attribute is a sub-attribute, regardless of whether it is encoded in
a binary protocol fields or it is encoded in ASCII protocol fields. If RADIUS
implementations need to change their data dictionary to decode the sub-attributes,
they will also need code changes to decode the same sub-attributes within the
string format. That is my only point here.

I still don't understand why this would break Radius. Didn't you say/agree earlier that
there are a few uses of string attributes, in which RADIUS or Diameter client/proxy/server
implementations are expected to parse a string according to some syntax rules? Does any
of these string attributes break Radius or Diameter?

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?

-Parviz


Once again, we may have taken this debate as far as it can go in the
abstract.  Further discussion should probably be couched in terms of
comments on the drafts.

I guess it should be obvious that the reason we are raising these
meta-comments, in discussing the proposed charter, is that these issues
will ultimately regulate the content of drafts that are eligible to
become WG work items.

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



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