[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSS: draft-ietf-radext-fixes
David B. Nelson <mailto:email@example.com> allegedly scribbled
on Monday, July 02, 2007 10:52 AM:
>> I was referring to server-side duplicate detection, as was the
>> original comment, I believe.
> Ah, so it was.
> Yes, it would be nice if Identifiers were monotonically increasing
> (within the scope of a NAS IP address and NAS source UDP port). It
> is likely that many implementations behave that way -- it's the most
> straightforward thing to do.
> Not enforcing the monotonic requirement means that servers would need
> to keep a cache of recently used Identifiers for each NAS IP/UDP.
> What do you propose to do about implementations that don't implement
> monotonically increasing Identifiers? For the server to rely on
> monotonically increasing Identifiers in it's supplicate detection,
> this would have to be a MUST for the clients, effectively deprecating
> any implementation that uses a different scheme.
Only if we assume that a) there is no capabilities exchange between
clients & servers or b) that RADIUS servers have virtually no
intelligence. If a server noticed that every single identifier coming
from a given client was 1 greater than the last over an hour or so,
couldn't it reasonably assume that the client was behaving in the
recommended fashion & process that client's requests in the more
efficient manner? For that matter, it could be a flag in the clients
file. I don't really see anything here that spells "mandatory".
> It would seem that
> this would at least require a protocol version field, to make it
> work, ignoring for the moment the fact that non-backwards compatible
> changes are prohibited in our charter.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.