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

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

We seem to have two main positions on the list on the purpose
of RADIUSEXT. Correct me if I misunderstood the discussion.

a) Only allow new attributes that can be introduced by just
adding them to the dictionary and the user database. No
recompilation of the RADIUS server is allowed.

b) Add new attributes, even if they require some special server
behaviour. The RADIUS protocol itself remains untouched. RADIUS server
may need additional code to handle the new attributes.

My suspicion is that our discussion is more about a) vs. b) than
about attribute syntax.

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

I'd prefer a charter that allows b) and so do some other draft authors.
To those who support a), would your vote be the same if we were discussing
a AAAEXT charter and were talking about DIAMETER AVPs?

Dave Nelson wrote:
> My further opinion is that much of the argument in favor of sub-types is
> seeking to protect existing implementations from IETF WG change control.
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?



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