--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 24, 2005 at 12:53:01AM -0700, Jonathan Stone wrote:
> In message <20050424063240.GC18134@netbsd.org>,
> Bill Studenmund writes:
>=20
>=20
> >I think one problem is that you have lost sight of the forest for the
> >trees. It probably didn't help that you've had discussions like this
> >before that we don't know about, and many folks here may have mistaken t=
he
> >forest for one tree... :-)
>=20
> Bill,
>=20
>=20
> Perhaps one big difference is: I don't use IPv6.  I have an IP-centric
> (IPv4-centric if you wish) view of how IP(v4)  should work.
>=20
> If you start from that perspective, then any attempts to force IPv6
> semantics onto IPv4, in ways that break existing IPv4 usage, needs a
> very strong justification.  No such justificaiton has even been
> attempted here.   Attempts that boil down to saying:
>=20
>     ```I don't know what IPv4 says here, but I know IPv6,
>        and so I'm going to make IPv4 work as I understand IPv6
>        to work''

Would you please stop this line of thought? Yes, David said, "IPv6," but=20
as best I can understand his desires and most of the other desires I've=20
heard mentioned, the initial, core, key thought wasn't that "what IPv6=20
does is right," it's "I hate what IPv4 is doing." By continuing to harp on=
=20
it, you seem to be missing the point of what he wanted and why just as=20
badly as he didn't understand Strong ES.

> are, as technical discussion, perhaps worse than nothing at all, when
> the proposed changes will, by what mathematicians call ``by
> inspection'', cause huge trouble for fairly common existing deployment
> scenarios.
>=20
> Re: your point about embedding policy in code being a bad choice,
> compared to letting admins decide it and encode it: for pity's sake,
> yes of course.  Does that point even need to be _said_?  If points
> that basic really need to be made, , what does that tell you about the
> technical skills of the people making the proposals???

Yes, it seems it does need to be said. You've posted over ten messages on
this thread in which you have blasted this proposal. You could have simply
made the point about policy, suggested David make his solution be
policy-based (or configurable or whatever other words we choose), and he
take his original porposal as one instance of it, and what we have now as
another. With that kind of framework, David gets what you want, I get what
I want, and you get what you want. And since it's policy, we'd ship with a
default policy that behaves as we used to behave.

> Re: not seeing forest for trees: yes, I've been working with policy
> issues, and an SO_BINDTODEV-like implementation for some years
> now. Personally, I find that to be a *much* better solution for what
> you say (in a subsequent message) you want.

I disagree. What I want is something that works well for a client. A new=20
call, of any sort, means each client has to be changed to support it. I=20
want something where I configure the stack to do what I want, and then all=
=20
clients do the right thing.

We have one netinet and tens to hundreds (to thousands) of clients. Making=
=20
each client have to change for this doesn't scale well. I'd rather we=20
change one thing to get it right rather than thousands of things.

I admit I still don't feel confident about what I want a server to do.=20
The SO_BINDTODEV call may well be the right thing for a server.

[nfs example deleted]

> Or another example: take the scenario you and I both want, whereby an
> app can choose which of two local addresses it wants to use to talk to
> some remote server. Suppose the client is multihomed (one interface or
> two, it doesnt matter).  Suppose further that one of the client's
> addresess is on the same subnet as the server and the other isn't;
> it has to be routed.
>=20
> Do you see already what is going to break here?  Or not?

As above, I do not want the app to choose. :-)

I understand your description of problems with Linux NFS. However I don't=
=20
see how any change to how addresses are picked will break WORSE than we=20
have now. :-)

Take care,

Bill

--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCbTJ3Wz+3JHUci9cRAvB0AJ496d+INl0GrxepJ0E+cKXnQ79AWwCfdaMX
D73lyusOUJmJmEC6AzAqerw=
=WMdf
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--