[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
Can you guys try to agree on a paragraph which explains what 'backward
compatibility' means in the context of this charter?
It seems to me that this is the principal item of disagreement in this
debate.
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn
> Sent: Wednesday, April 16, 2008 9:37 AM
> To: 'Alan DeKok'
> Cc: radiusext@ops.ietf.org
> Subject: Meaning of "backward compatible" WAS RE: Consensus
> Call on RADEXT WG re-charter
>
> 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/>
>
--
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/>