[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSS: draft-ietf-radext-fixes
David B. Nelson <mailto:dnelson@elbrysnetworks.com> allegedly scribbled
on Monday, July 02, 2007 10:12 AM:
> Glen Zorn writes...
>
>> This paragraph sound self-contradictory to me: how can a client
>> silently discard duplicate responses if it doesn't detect that they
>> _are_ duplicate responses?
>
> It merely needs to determine that the response is related to a
> request that is no longer pending. That's a form of duplicate
> detection, I suppose, but it does not require that the response is
> literally a duplicate, only that it is not expected or needed.
I don't know why we're dancing around this; why not just say that the
client must discard responses with unrecognized values in the Identifier
field?
>
>> This doesn't see to address the issue of the Identifier being
>> essentially useless for duplicate detection if not monotonically
>> increasing...
>
> Monotonically increasing Identifiers would be nice, as it makes the
> detection algorithm much more efficient. As above, all that is
> _required_ is that the client can tell that the response is related
> to a request that is no longer pending.
I was referring to server-side duplicate detection, as was the original
comment, I believe.
> Adding a new normative
> requirement for monotonically increasing Identifiers would seem to me
> to be a non-backward compatible change to RADIUS, and thus likely out
> of scope.
--
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/>