FW: DISCUSS: draft-ietf-radext-fixes

["David B. Nelson" <d.b.nelson@comcast.net>]

IESG review comment:

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: Monday, July 02, 2007 7:49 AM
> To: iesg@ietf.org
> Cc: draft-ietf-radext-fixes@tools.ietf.org; radext-chairs@tools.ietf.org
> Subject: DISCUSS: draft-ietf-radext-fixes
> 
> Discuss:
> Section 2.2.1., paragraph 6:
> > [a]  Jitter.  To avoid synchronization, a RADIUS client SHOULD
> >      incorporate jitter within its retransmission algorithm.
> 
>   DISCUSS: "Jitter" is not the correct term. What is suggested here is
>   to incorporate a random factor into the retransmission timer
>   calculation. This will prevent synchronization, but won't help against
>   congestion collapse, because it doesn't reduce the number of
>   retransmissions over time. Only [b] will address that. Also, please
>   specify how a random factor is to be incorporated into the computation
>   - see Section 9 of draft-ietf-pana-pana for an example.
> 
> 
> Section 2.2.1., paragraph 7:
> > [b]  Congestive backoff.  While it is not necessary for RADIUS client
> >      implementations to implement complex retransmission algorithms,
> >      implementations SHOULD support congestive backoff within the limits
> >      suggested by [RFC2865] Section 2.4.  For example, an implementation
> >      SHOULD double the initial retransmission timer until a maximum
> >      retransmission time is reached, after which the client will
> >      failover to another RADIUS server.  For example, if the initial
> >      retransmission timer is one second, a maximum retransmission timer
> >      of 16 seconds might be used.
> 
>   DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
>   scheme or timer limits, and I couldn't find this anywhere else in
>   RFC2865, either. Consequently, this document needs to specify the
>   desired mechanism. See RFC2988 for an example of such a mechanism.
> 
> 
> Section 2.2.2., paragraph 0:
> > 2.2.2.  Duplicate detection and orderly delivery.
> 
>   DISCUSS: This section is all about duplicate detection at the server
>   due to client retransmissions. But any UDP packet can be duplicated in
>   the network. This section should hence also discuss detection of
>   duplicate responses at the client.
> 
> 
> Section 2.2.2., paragraph 2:
> >       The RADIUS server can detect a duplicate request if it has the
> >       same client source IP address and source UDP port and Identifier
> >       within a short span of time.
> 
>   DISCUSS: I could not find a discussion in RFC2865 on how the
>   Identifier field is to be managed. For duplicate detection, it should
>   be monotonically increasing or similar. If RFC2865 doesn't specify how
>   the Identifier fields is to be used, this document needs to do so if
>   it wants to base duplicate detection  on it.
> 
> 
> Section 2.2.2., paragraph 8:
> >    Each cache entry SHOULD be purged after a period of time.  This time
> >    SHOULD be no less than 5 seconds, and no more than 30 seconds.
> 
>   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
>   bound will prevent late duplicates from remaining undetected.
> 




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