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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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?



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