RE: WG Review: Recharter of RADIUS Extensions Working Group (radext)

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

>Romascanu, Dan (Dan) wrote:
>> I suggest to consider the comments from Magnus during the IESG/IAB
>> internal review as IETF review comments and address them.
>...
>> > - All documents produced MUST specify means of interoperation
>with
>> > legacy RADIUS implementations and, if possible, be backward
>> > compatible with existing RADIUS RFCs, ...
>
>> I kind of find this formulation interesting. So implementations
>are
>> actually more important then any of the specifications? So if I
>claim
>> that I have a implementation which doesn't follow the specs for
>that
>> they still can be used as an argument to affect the new
>extensions?

Interestingly, one of your IESG colleagues recently used precisely that
argument to halt the progress of a draft from the hokey WG: that
non-standard EAP implementations would be unable to handle ERX &
therefore all sorts of limitations needed to be placed on the new
protocol.  I did ask why a purported SDO would care about broken
implementations of a standard protocol, but w/o AFAIK getting any
answer.  So, yes, there seems to be an (unfortunate IMHO) precedent for
this...

>
>  Maybe just "... interoperation with legacy RADIUS and, if
>possible..."
>
>  i.e. delete "implementations".
>
>> I made a quick scan at RFC 2865. Are there any real definition of
>how
>> the UDP retransmission timers should look?
>
>  RFC 5080 Section 2.2.1 defines these timers.
>
>> In addition, is it congestion problems or the message size that
>makes
>> one go towards TCP?
>
>  I think that the main one is message size.  While there may not be
>a
>need to increase the 4k maximum packet size for RADIUS, there are
>many
>broken firewalls and routers out there.  UDP packets that are 4k in
>size
>may be fragmented at the IP layer, and may not make it intact across
>the
>network.  Using TCP for transport means that the RADIUS packets are
>fragmented across multiple TCP packets, but that the IP packets are
>not
>fragmented.
>
>  In addition, TCP can have faster feedback than UDP when a
>connection
>goes down.  This can help minimize delays on failover.
>
>> I wonder if  you need to have some clean up of the UDP based
>> transport rules for radius when you anyway are in the process?
>
>  Many transport rules for RADIUS were updated in RFC 5080.  I'm not
>sure any more changes are required.
>
>  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/>