Date: Wed, 14 Aug 2002 09:16:47 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| I might not have been clear, but the reason I support keeping the 'u'
| bit is *not* because I want to use it as an excuse to keep the /64
| boundary, but because it makes little sense removing it as long as the
| /64 boundary is there.
You were clear enough, I understood that.
Maybe I wasn't clear enough that the 'u' but is the worst part of the
draft. It (or the part of it which pretends to be visible externally)
is the thing which most needs to be deleted. I don't just want it
gone in order that the 64 bit boundary can go, I want it gone because
it is unimplementable nonsense, which doesn't belong in the doc.
It just happens that after this goes, the sole motivation for keeping
fixed /64 also goes, so it may as well be removed at the same time.
| It appears to me that you are trying to modify the Addressing
| Architecture doc in order to allow very minor optimizations.
Forget the optimisations. What I want is for it to actually describe
the addressing architecture. And not something which someone believes
it would be nice if it was like, but without any reasoning.
I think it was Thomas who said that we don't have to adjust our docs to
allow for other people ignoring them, and doing broken things. And that's
certainly right. An example was the "just send 8" SMTP argument, lots
of people did that, and argued for adopting it - but it is easy to show
how that is technically wrong.
On the other hand, if lots of people are doing things one way, and there's
no technical argument to show that it should be done a different way,
then it really starts to look as if the only reason for not changing is
stubbornness.
| In weighing the pros and cons of removing the /64 hard boundary, my
| opinion is that the savings that it would bring are not significant
| enough compared to the potential operational annoyances.
Name one operational annoyance? That is one that my use of /112
(or someone else's use of /126 or /127) inflicts upon you, assuming
that you're not the other end of the link (if you are, it is your
choice to participate, no-one is compelling you to use > /64).
Just one.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
