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

[wolfgang.beck01@t-online.de (Wolfgang Beck)]

Dave Nelosn wrote:
> Wolfgang wrote:
>> 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.
Sorry.

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

OK, I'll try: RADIUS already uses already structured string
attributes. Some attributes (like CHAP-Password) simply group components
without delimiters. Some attributes use delimiters (like NAI). Some
attributes use a TLV syntax, like Vendor-Specific or EAP. draft-lior
and draft-sterman just followed existing examples. Nobody had the
intent to violate RADIUS principles. 

Many principles of RADIUS have been questioned and replaced, though.

> 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.
So, why don't you ask Jari to define a new Request-Destination
attribute?

> 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.
The question is, whether an attribute can be used individually.  User-Name
makes sense in more than on combination. An HTTP digest nonce attribute
is useless if there aren't Method-, URI- etc attributes available.
HTTP groups them, why shouldn't RADIUS do the same?

And for your tunneling argument: how does flattening out attributes change
that? Would it be ok for you if we defined IP-Version, IP-Header-Length,
IP-Type-Of-Service etc attributes? I guess not.


Wolfgang

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