cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h

[Wes Peters]

On Saturday 08 May 2004 11:25, Sam Leffler wrote:
> On Saturday 08 May 2004 08:25 am, Darren Reed wrote:
>
> > If there were a core@ for freebsd that was active, this is the kind of
> > thing I'd be writing to them about, asking for it to be backed out.
>
> Technical disputes of this sort are supposed to be passed to the TRB.  I
> personally don't see the change as important enough to argue about--I
> haven't heard Andre weigh in, but I figured he'd just back it out.

There is a core@ for freebsd, it is active, and it is watching this 
conversation.  So far the summary seems to be "experts disagree."  I 
understand and agree with Darren's concerns about duplicating code, but I 
think Sam's position here is the correct way for FreeBSD to proceed.  
Eliding options processing is desirable for a wide range of endpoint 
systems, including those I work on at ${DAYJOB}.

I will point out that the Internet is a changing environment in ways the 
RFCs have not kept up with.  Many TCP/IP implementations, including ours, 
are (no longer) in accordance with all of the relevant RFCs, including the 
Host Requirements, Router Requirements, and the basic TCP and IP 
specifications.  This is at least partly because many of the RFCs are quite 
old and nobody has bothered to update them with implementation details that 
have proven to be inadequately specified or just wrong.

So long as this feature is optional, regardless of the default setting, and 
not used as an excuse to fail to maintain the options processing in working 
state, I *still* have no objection to it.  I welcome further review by the 
TRB or by the FreeBSD-net contributors.

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes at softweyr.com