[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of David B. Nelson
Sent: Friday, April 18, 2008 12:14 AM
Glen Zorn writes...

> I AM REALLY OPPOSED TO BS, however ...

If I thought that slam was targeted at me, I might be offended.  :-)

> ... I don't really understand this manic grasping at straws to 
> claim RadSec's "backward compatibility", to the point that now we
> have 'if you used this interface when you wrote your code (as opposed
> to the easy, obvious one)' then it's really almost the same but not
> quite'.

We need a reasonable definition of "backward compatible" to scope this
work.
It needs to be unambiguous, so that we can tell when it has or has not
been
met.  It has to be simple enough that we can understand it.

Whether or not you agree that RADIUS *has* an application layer
specification that can be divorced from a specific transport binding, it
is
important that the RADSEC specification (or any other alternate
transport
specifications for RADIUS) make it clear that all we want to tinker with
in
this work item is the *transport* layer.  We want the RADIUS PDUs to
remain
otherwise unchanged.

What's wrong with that?

----------------------------------------------------------------

If you go by the assumption, as reality pretty much dictates, that
RADIUS is not divorced from specific transport binding, then you should
be very cautious to avoid creating a heck of a lot of confusion
downstream from where we sit. For the last umpteen years RADIUS has been
RADIUS. True we have caused all sorts of havoc with attributes, but that
hasn't killed basic interoperability between RADIUS clients and servers.
This new effort would kill that basic interoperability. Therefore you
need to make very clear that the result of this work will NOT be
interoperable with the massive world-wide deployment of RADIUS clients.

-Matt


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