> I can only conclude that you did not adequately review the code you
> committed, because it does not mention fragmentation attacks; But it
> *does* explicitly mention "the resolver/named problem".

	what is "it" in "it does not mention"?  i don't understand what you are
	trying to mean.

> Can I ask just why you are committing code to the NetBSD tree without
> adequate review, and in the face of a prior consensus *against*
> forcing 15-bit linear-congruential randomized IP_IDs?

	when is the "prior consensus"?  maybe that's before i joined.

> As for preventing fragmmentation attacks: this change is neither
> necessary nor sufficient.  I've mentioned a better approach (for which
> I have a working, shipped implementation) here tha said, on this list.

	reference please?  where can i see the code?

> [nessus]
> Itujun, that's really reaching. I'm looking for a responsive,
> well-reasoned, technical argument to support making randomized IDs the
> default. If this is the best you can offer, you're not helping your case.

	http://www.insecure.org/nmap/idlescan.html

	i don't understand why you don't know about this very commonly-known
	issue, and i don't understand why do i have to prove it is a problem
	to make it into netbsd tree.  i can't leave netbsd in an insecure
	state (predictable ip_id).  my mission as a developer is to make it
	better protected against potential attacks.  is it enough?

	or, if you would like your system be insecure, make a local change 
	to use predictable ip_id and use the system.  don't forbid me from
	making netbsd general distribution more secure.

itojun