Date: Fri, 9 Aug 2002 21:18:01 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| What you are calling for (quoted below) is lots of changes. With that
| many deletions, one might say that it could be wiser to re-write
| [addrarch] entirely.
No, I don't think that's true, I think it is actually just moving it
back to an earlier version - just from reading it it is obvious that the
magic "64" has been grafted in later (we have diagrams that use m, n, etc,
and then some text says "m + n = 64" - and it isn't as if that's a just
a style issue, when the value is "128" (which is a fixed constant of course)
the diagrams say "128 - n").
The changes are relatively minor, and affect nothing at all about the
way that v6 works, or is used, or is currently deployed, or ...
Note: to go to DS we have to provide evidence of at least two independent
implementations of every feature of the doc. Any that aren't actually
implemented are required to be removed (perhaps to another doc to recycle
at PS, but more often to experimental or just the vast emptiness of space).
Where are the implementations of the 'u' bit implying global uniqueness?
Where are the implementations requiring /64 everywhere, everytime?
If they don't exist, the IETF's rules require this stuff to be removed.
| Note that I don't oppose the idea and I acknowledge that you do have
| very good points, but WRT what Margaret mentioned earlier about
| consensus, do you think you can rally the WG behind these proposed
| changes?
I have no idea. That's not easy to judge, especially when most of what
I assume to be the part of the WG that doesn't want these changes is just
saying nothing.
What I'd like to see if for someone who actually believes the doc should
remain as it is, could actually explain the reasons why. Part of the
problem that this is so frustrating, is that no-one seems willing to
actually explain what we're getting from these requirements.
Even a pointer to an older thread on the list where this was discussed and
the reasons given would do (Subject headers and approx date would be great).
Without that, the impression is that everyone is just silently agreeing
(other than those who say that the draft can't change because it already
exists) with the points being made, but I am pretty sure that's not the
case. But I have no idea at all why. Maybe someone can convince me that
there's actually some benefit that I just can't see.
As I recall, the only argument I've ever heard, is that the 'u' bit is
important, because sometime in the future someone might come up with some
scheme that will allow these "globally unique" IIDs to be treated specially
for some purpose or other. And even though that's just wild speculation,
I could almost buy that (I'm one of the people who doesn't mind making
allowances for things that might happen in the future in general, even if
we don't know what they are) - except that no-one has been able to tell me
how we would ever cope with devices that simply have no idea if their
MAC address is globally unique or not (and so really, in this interpretation
would have to always leave the 'u' bit clear in all addresses - I can
easily show that KAME would be broken according to this interpretation for
example - that is, I can have it autoconfigure addresses with the 'u' bit
set where the IID isn't globally unique - and I certainly can't imagine
a way the KAME people could fix it, other than by never setting 'u'), and
perhaps more importantly, as that one can always be hand waved away as a
"configuration error" (though the imaginary protocol using this would have
to deal with it, somehow) how we deal with address stability when a MAC
address changes, so the IPv6 address is no longer based upon an EUI-64,
though it used to be.
So, let me turn the question around. Is there anyone out there who believes
the draft should stay as it is (in this area) and who is willing to attempt
to explain why?
If there's no-one, then to me that looks like consensus for a change...
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]
--------------------------------------------------------------------
