>>>>> On Wed, 02 Apr 2003 14:36:19 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> What was the consensus, if any, on alternatives to site-locals when SL
> is deprecated? In particular, which prefixes will we use for
> disconnected or intermittently connected "site"s? I've checked the
> chair's presentation slides and the draft minutes, and (roughly)
> followed the very recent discussion in the ML, but I cannot be sure
> about it.
Thanks, everyone. Since my goal was to clarify a background of this
vote (for myself), I won't make a response to each follow-up. I
believe I now understand the background. A rough summary is:
If we say "YES -- Deprecate site-local unicast addressing", this
means we agree on removing site-local assuming something fantastic
that can solve issues when we really remove it.
Hmm..., then it is natural that the group of 'YES' will be in a
majority. And, in fact, the "something" seems to vary among people.
It even contains, if I understand the discussion correctly,
"nearly-unique site-local" that consists of fec0 + some_random_bits.
I agree even "nearly-unique SL" is better than the current fec0::/10,
and, in that sense, I can vote for YES (Note: I don't stick to this
one. I'm picking it up as an example). However, can we really agree
on using this particular solution? Some people is against SL due to
its "false sense of security", which also applies to the
"nearly-unique" one. So they will also be against this.
So..., I'm afraid we'll just end up having a discussion loop again or
even re-inventing yet another site-local addresses (which will then
cause another loop), due to the very large notion of 'YES'. For this
reason, I cannot agree on just "clearing the desktop first". I cannot
believe this approach stops the circle.
As I have repeatedly said, I'm not a site-local lover, so I'd rather
vote for 'YES'. But, in this current form, I cannot do that.
At this moment, I don't have a good idea to overcome this dilemma.
I'll try to think more about it (of course, I'll be very happy if
someone can enlighten me on this, without repeating points already
stated in this thread).
Thanks,
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]
--------------------------------------------------------------------
