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

["Glen Zorn" <glenzorn@comcast.net>]

owner-radiusext@ops.ietf.org <> scribbled on Friday, April 18, 2008 5:14
AM:

...

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

I agree completely.  What is amazing is that, given the fact that
"backward compatibility" has been in the charter since the WG was formed
(& has been used as a stick to beat to death several useful proposals),
this definition doesn't already exist.  In fact, its utility as an ad
hoc bludgeon is such that I doubt that such a clear, unambiguous
definition will be forthcoming (let alone written into the charter).  I
sincerely hope that I'm proven wrong...

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

One thing that's wrong is that it ignores the limitations on the RADIUS
PDU that exist primarily (or solely) because of the UDP transport.  One
example: the maximum length of 4096 octets for a Radius packet was
chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be
reliably transmitted w/o fragmentation _in the access networks of the
day_.  It doesn't seem to be very smart to go to all the trouble of
defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific
limitation in place.

...



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