AW: subtypes (was: HTTP digest and RADIUS; new version of the Ste rman draft)

["Beck01, Wolfgang" <BeckW@t-systems.com>]

> 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.
Agreed. Can you give an example where the extension drafts would break
your product?

> 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.
Providers (your customers) like standardized extensions better than
vendor-specific ones. Else we have the choice between maintenance nightmare
or vendors handcuffing us.

> 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).
True. During that period we paid vendors to mitigate RADIUS deficiencies
using proprietary extensions. Which makes now DIAMETER migration even harder to
justify (not technically, but commercially).

> 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.
Like IPV6 migration, replacing RADIUS means replacing a platform, not just
updating some systems.  Many providers can't afford to replace their AAA
platform, just because it handles some error conditions nicer and is more
extensible. The margins are pretty low in this business (not to mention the
cash drain for buying Finnish 3G equipment).

We still develop IPV4 protocols within the IETF.

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