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