RE: HTTP digest and RADIUS; new version of the Sterman draft

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

Wolfgang Beck writes...

> A charter only allowing a) is not really worth the effort, but seems
> to be preferred by people who want DIAMETER to be deployed.

[DBN] In my case, I have no vested interest in the deployment of
Diameter, so your inference here is debatable. 

> I will remove structured strings immediately from
draft-sterman-aaa-sip
> if somebody can show me a concrete real world example why they are so
> horrible. The debate on "tunneling" and secondary issues like
attribute
> syntax is somewhat philosophical and leads nowhere. Every protocol
tunnels
> higher layer protocols. Jari's 'user@realm' tunnels request-routing
> information in a User-Name attribute. The Digest-Attributes attribute
> of draft-sterman-aaa-sip tunnels HTTP digest information, using a TLV
> syntax instead of '@' for separating optional components. Where do you
> draw the line and why?

[DBN] I would turn your challenge around.  You have challenged us to
convince you that sub-types are "bad" for RADIUS.  I would challenge you
to demonstrate that sub-types do not alter the architectural intent of
standard RADIUS as it is documented.  A question of who bears the
"burden of proof".

As to how to distinguish a sub-type from a compound, but
opaque-to-RADIUS, data type, I think we have delineated that as closely
as one can in general terms.  If a RADIUS client, proxy or server needs
to parse the individual sub-fields of sub-types, then the sub-types
ought to be flattened to the status of full attributes (or potentially
flattened to the status of single-layer attributes under a VSA or SSA).
The one counter-example is NAI parsing in proxies to determine the next
hop server.

I would argue that QoS attributes, SIP attributes, pre-paid attributes,
and the like are simply attributes.  The desire to "group" them can
likely be handled by existing tagging methods.  Location attributes, if
defined in some well-known format such as X.500 syntax, probably qualify
as a single attribute, with multiple parts, similar to NAI in User-Names
or FQDN in NAS-Identifiers.

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