subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft)

[<john.loughney@nokia.com>]

Hi Wolfgang,

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

My two cents are that I hope extensions to RADIUS to not break current
implementations of RADIUS and/or Diameter.  My company has implemented
both, including some VSAs & we're concerned about extensions that
would cause us to implement more stuff without a clear benefit
for doing so.

Talking to other vendors, I haven't heard a lot of vendors saying that
they would move from VSAs to standard extensions if available.  On top
of that, several folks on this list have stated that other SDOs need
some extentions - if that is so, I think it would be good if those
SDOs would make it known to the IESG / this list via the liasons that
already exist.

I think we are between a rock & a hard place on this topic.  A few years
ago, the IETF undertook a process to define the AAA infrastructure.  At
the time, extending RADIUS seemed to be a messier job (and not guarenteed
for success) than to standardize Diameter.  I think that the IETF did
a poor job in getting Diameter completed in a timely manner (which
is another source of the current mess we find ourselves in).   I think
the IESG is looking for clear proof that RADIUS extensions are needed,
so I'd be interested in seeing some reasoning (perhaps even in draft
format) for this. Otherwise, I doubt the IESG will be really excited about
chartering this WG.  In otherwords, the burden of proof is upon those
who want to extend RADIUS.

I'm not adverse to some extensions, I think some of the roaming
situations would be good places to create standards. However, my sense
of the room is that folks are saying we should extend RADIUS because
we can, which doesn't seem like a good argument.

John


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