RE: DISCUSS: draft-ietf-radext-fixes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

David B. Nelson <mailto:dnelson@elbrysnetworks.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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>