RE: Consensus Call on RADEXT WG re-charter

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

owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008
11:50 AM:

> Glen Zorn wrote:
> ...
>>> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP
>>> proxy isn't doing HTTP.
>> 
>> Hmm.  By that standard, it would seem that Diameter is RADIUS, too...
> 
>  No.  I didn't mention an HTTPS to FTP proxy as being HTTP.

This is what you said: "...a RadSec to RADIUS gateway involves
terminating TCP, TLS, and forwarding the contents to RADIUS.  If this
isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't
doing HTTP."  A Diameter to RADIUS gateway involves terminating TCP (or
SCTP), TLS, and forwarding the contents to RADIUS.  If you really think
that this is different from your HTTPS->HTTP example, perhaps it's
because you are conveniently ignoring the fact that HTTP is only defined
over TCP.  However, one could just as easily argue that HTTP != HTTPS,
given the need for different port numbers...

> 
>> I don't think that I said anything about good or evil :-), but you
>> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 &
>> that's not a problem.  The problem would arise if someone claimed
>> that it was because, 'Well, you can build a gateway'.
> 
>  The protocols being transported on IPv4 can also be
> transported on IPv6.  

I really don't know how that is relevant.  Dropping down a layer or 2,
the same protocols can be carried by both Ethernet & ATM.  Are you going
to claim that they are somehow compatible (backward, forward or
upside-down)?

> Similarly, UDP transport + RADIUS application
> protocol is... RADIUS.  TCP transport + RADIUS application protocol
> is... RADIUS. 

I know that you have read RFC 2865 (probably more often than I), so you
know that there is no such thing as a standard "RADIUS application
protocol", defined w/o regard for the underlying transport.  

> 
>  The only way to call RadSec something other than RADIUS is
> if you say that FTP over IPv6 is not FTP.  After all, FTP was
> for IPv4, 

I can't find any mention of IPv4 in RFC 959; it does mention TCP,
however.  Would FTPoUDP also be FTP?  How would FTP & FTPoUDP
interoperate?  These questions seem much more to the point, I think.


> and IPv6 is a new-fangled transport... so FTP over
> IPv6 is not FTP... it's "magic".

One more time: the version of IP being used is transparent & therefore
irrelevant to FTP.  UDP transport is forever enshrined in RFC 2865,
however; maybe that's a bad thing, but it's true nonetheless.

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