RE: DISCUSS: draft-ietf-radext-fixes

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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