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

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

Alan DeKok <mailto:aland@deployingradius.com> scribbled on Tuesday,
April 15, 2008 3:46 PM:

> Glen Zorn wrote:
>> OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not
>> be the authoritative reference for "RADIUS *at all*".  What is? I'd
>> like to read it...
> 
>  The authoritative reference for RADIUS is this WG.  If the
> consensus is to add bells, whistles, or flying monkeys to
> RADIUS, then that is our perogative.
> 
>  The alternative is to worship at the holy shrine of the
> existing RFC's, which were handed down from on high by the
> holy priests of RADIUS.  As mere mortals, we are incapable of
> changing holy writ, and must confess that the RFC's are perfect.
> 
>  I shall therefore submit a request to the RFC editor
> admitting that RFC 5080 is blasphemy, as it points out
> *errors* in the original RFC's.
> It should therefore be withdrawn immediately, before the holy
> priests of RADIUS burn me at the stake.

Could we just try to stay on topic, please?  My assertion was that to
claim "backward compatibility" between 2 protocols which can only
communicate through a translating gateway is essentially meaningless.
That has nothing to do with "priests" or "holy writ", even less with the
ludicrous claim that this WG is some kind of global help desk for RADIUS
developers.  Back to the subject at hand, you managed to define
"backward compatibility" in a slightly different context a couple of
months ago (see https://ops.ietf.org/lists/radiusext/2008/msg00000.html
for the complete message): "Everyone accepts that implementations have
to be updated to handle new standards.  One of the major efforts in
RADIUS has been to maintain backwards compatibility with existing
deployments.  i.e. if a product doesn't implement the new standard, it
can still communicate with products that do implement that standard."  A
RadSec implementation doesn't also listen on UDP 1812 pretty obviously
flunks that test (not that I think it's a particularly good one, but
it's yours).  If there is to be _any_ interoperability between RADIUS
and RadSec, then the definition of the protocol gateway behavior is at
least as, if not more, important than the standardization of RadSec.
Unfortunately, this doesn't seem to be reflected in the charter that
everyone seems in such a hurry to rubberstamp; maybe because RadSec is
by definition "backward compatible"?  

> 
>  Alan DeKok.



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