FW: DISCUSS: draft-ietf-radext-fixes

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

Forwarding to the list...

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: Wednesday, August 29, 2007 10:06 PM
> To: draft-ietf-radext-fixes@tools.ietf.org
> Cc: IESG IESG; radext-chairs@tools.ietf.org
> Subject: Re: DISCUSS: draft-ietf-radext-fixes
> 
> Hi,
> 
> I checked the -06 update against my original DISCUSS, and except for
> the few remaining issues detailed below, all my concerns have been
> addressed - thank you!
> 
> On 2007-7-2, at 20:48, ext Lars Eggert wrote:
> > 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.
> ...
> >   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.
> 
> -06 specifies such a mechanism, which was the important part of my
> concern. A minor remaining nit is that the "within the limits of
> [RFC2865] Section 2.4" part should be removed, because that section
> in RFC2865 does not actually discuss any such limits.
> 
> > 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.
> 
> This section has significantly changed in -06. My one remaining
> concern is with the new text that says:
> 
>     RADIUS clients do not have to perform duplicate detection.  When a
>     client sends a request, it processes the first response that has a
>     valid Response Authenticator as defined in [RFC2865] Section 3.  Any
>     later responses MUST be silently discarded.
> 
> If clients need not perform duplicate detection, how are they
> supposed to silently discard later responses? No duplicate detection
> = no state about packets received in the past, right?
> 
> > 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.
> 
> This has remained unchanged in -06 AFAICT.
> 
> Lars



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