Date:        Sat, 14 Nov 1998 10:49:36 +0100
    From:        Stefan Grefen <grefen@hprc.tandem.com>
    Message-ID:  <12303.911036976@hrriss.hprc.tandem.com>

I was going to avoid getting involved in this before I saw this
comment...

  | the way the patch was implemented routing needs to be turned of too.

There has been a basic mis-understanding of the terminology here (by
some at least).   This illustrates it.

The relevant expression is "strong end system model", the implementation of
which (as an option) is being discussed.

In that expression, the grouping is "strong (end system) model", not
"(strong end) system model".    Even the Subject of this message is
wrong (the hyphen is in the wrong place).

In reference model language, an "end system" is what any of the rest of
us call a "host", the phrase translates as "strong host model".

What we call a "router" is in other-speak an "intermediate system".
There is no "strong intermediate system model", such a thing makes no
sense at all, a router would simply route the packet from the "incorrect"
interface it arrived on, to the correct interface, and then deliver it.
That's what routers do, after all.

Hence, that it is necessary to disable routing in order to make the
strong host model work should come as no surprise at all - that is the
way it ought to be, and no-one should waste any time attempting to fix that.

Beyond this, and perhaps going to far toward pedantry, it really makes
no sense to be talking about "strong endedness" or similar, there is no
ending being done here, "strong host" would be a better brief description,
or just "strong model", that it is for end systems is simply implied,
or use the common ES abbreviation of "End System", and talk of "strong ES".


To the topic, I suspect that adding the simple sysctl interface that
was described makes sense, it certainly shouldn't unduly harm anyone,
and while I personally have no use for setting up strong model hosts,
occasionally I hear of others who do (including Perry, for whatever reason),
and there's no really good reason to stop them.

I assume that there will be a kernel config option to set the default value
for the sysctl variable to on, rather than off, for people who really want
their systems to run that way always, unless inhibited.  If not, there ought
be.


Lastly, I quite like apb's "per address" suggestions, which are pretty simple 
to deal with (and the per interface ones as well, perhaps, though they may be
too complex to deal with, and better implemented via ipf when needed).
If that's ever done, and an interface specific ioctl added, the sysctl
interface should stay, and should set the "default state" for interfaces
(interface addresses) not explicitly configured one way or the other.
That is, if you prefer the strong model, for everything, simply setting the
sysctl variable ought accomplish that.

For that reason, when this is done, it should also be added to netstart
(and rc.conf of course), so the sysctl variable is correctly set before
any interfaces are configured - just so that later, if any interface specific
code is added, things will be being done in the correct order for best
effect (it will also allow a new kernel with this per address or interface
support to work correctly with an old ifconfig that doesn't yet know how to
enable the option - and from all I have read, that's the order things are
supposed to be done, upgrade kernel first, then usefland second).

kre