>If you want to discuss this calmly, thats fine, but frankly, if you
>want to have Stanford use FreeBSD, it would probably be easier to let
>you do that than to deal with people making threats as a way of trying
>to trump in a technical discussion.

Perry,

I am trying to make a legitimate techmical point.

In_maxmtu will cause problems for people who want to use NetBSD on
mobile multihomed hosts with heterogenous media.  

Like, for example, laptops with Ethernet and Metricom radios.  those
are very widespread on the Stanford campus.  The data in Stuart
Cheshire's Hot Interconnects 96 paper explains why fragmentation will
cause severre performance problems here-- immediately halving
thorughput and increasing congestion which may in turn further reduce
throughput.

I made the point that this change violates existing practice.  

Kevin Lahey points out that there's a consensus on tcp-impl about
what the conservative (i.e., right) thing to do is. the consensus
is to not do in_maxmtu but to stick with the conservative approach.


We have a point where one of the NetBSD Core Group is flaming that
they intend to violate ``be conservative in what you send'', and they
dont CARE what it breaks.

I think that's a dumb technical decision, and if we stick with it,
then I will have to stop recommending NetBSD to people at Stanford
altogether.

Perry, that is not a threat.  It's just a fact.