RE: RADEXT charter, Take 8

["Nelson, David" <dnelson@enterasys.com>]

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.

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

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