>>>>> On Mon, 04 Aug 2003 11:06:55 -0700,
>>>>> Bob Hinden <[EMAIL PROTECTED]> said:
> I would like to hear from the working group on how we should proceed. I
> think the choices are:
I prefer this one:
> A) Deprecate Site-Local addresses independently from having an alternative
> solution available.
I know my vote is not consistent with what I said in the previous vote
after the San Francisco meeting (attached below). Though I still have
the same concern (in fact, we've already seen a "confusion"), I think
it is most productive to support option A and (at least try to) move
forward anyway.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Tue, 01 Apr 2003 14:37:56 -0500,
>>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
> Should we deprecate IPv6 site-local unicast addressing?
"NO -- Do not deprecate site-local unicast addressing".
- because I'm not convinced that there is a clear consensus on an
alternative to site-local or that we do not need such a consensus.
I'm sad I must vote for NO...I've tried to convince myself by
the meeting minutes, presentation slides, discussion in this list, and
some private discussion, but I failed.
I've seen many candidate alternatives that at least include:
- arbitrary (random) global prefix
- fec0:: + random bits
- free prefix allocation service
I've even seen a wording nit like:
- leave site-local in the spec, but make a recommendation to avoid
using it.
(but can't this also be interpreted as a sort of 'not deprecate
site-local'?)
I could not be sure if we'll be able to make a consensus on any of
them (or others) quickly, if we choose "deprecating" site-local. If
not, the result will just be a confusion. If we can, then I don't see
why we cannot first make a consensus quickly and then deprecate
site-local.
I (of course) don't know the final result of this vote at this
moment. But regardless of the result, I'm willing to follow it
without making a further objection, and will try to make a productive
contribution based on the result.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--- End Message ---
