[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: DISCUSS: draft-ietf-radext-fixes
Forwarding to the list...
> -----Original Message-----
> From: Lars Eggert [mailto:email@example.com]
> Sent: Wednesday, August 29, 2007 10:06 PM
> To: firstname.lastname@example.org
> Cc: IESG IESG; email@example.com
> Subject: Re: DISCUSS: draft-ietf-radext-fixes
> 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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.