Back last November[*], Greg Troxel made a change (for i386, the
same probably should have been, and by now, might have been,
made for other architectures as well) along the lines of ...

  | Add (empty) INSTALL.local, parallel to GENERIC.local.
  | Change INSTALL kernels to include INSTALL.local instead of GENERIC.local.

  | With this change, one can add IPSEC in GENERIC.local and still build a
  | release, rather than having install kernels not fit on floppies.

This message isn't about that change, which is fine - not even really
asking why that change was needed (I understand that).

What I'm asking is why that change happened to be needed?

Or in other words, WTF isn't IPSEC enabled in GENERIC already???

GENERIC kernels have all kinds of other much less useful cruft
enabled in them (exactly what varies from arch to arch), but ISO
is pretty common, as is NETATALK, and NS and CCITT (X.25) are there in
more than just a couple or ports.   What is it about IPSEC that would cause
it to get left disabled?  It has to be more useful than any of that
other stuff these days (even NETATALK which is probably the most used
of the obscure protocols).

Note: I am not suggesting disabling any of those others for the ports
that have them enabled, so no-one needs to reply and defend their
favourite toy.

But I would suggest that on all ports for which they work, IPSEC,
IPSEC_ESP, and (if it works, without side effects -- I've never needed
to use it) IPSEC_NAT_T, be enabled, and certainly that this be done for
those ports (which includes i386) which have all of NS, ISO, CCITT and
NETATALK enabled in GENERIC.

If there is some good reason why this should not be done (ie: a good reason
why NetBSD doesn't believe that IPSEC should be enabled in normal kernels)
then it should be documented (most probably in ipsec(4)) so others can
take that reason into account before enabling it for themselves.

If the patent issue is enough to exclude NAT_T, that's fine, but that
should not affect any of the others.   The reasoning can't be related to
excluding encryption, or anything like that - there's tons of that in
other parts of NetBSD already.   So, why not?

kre

[*] Last November's e-mail is where I'm up to in my NetBSD mailing list
reading - I had been meaning to ask this question for some time, Greg's
change (which most likely might never have happened had IPSEC been in
GENERIC all the time) just provided the inspiration to actually ask it.