Hi Alain,
>There has been a very long discussion on the fate of Site Local addresses >in the wg. There are still two opposite views of what to do about them: Most of that discussion focused on whether or not to remove site-local addresses from the architecture, not on this draft. And, we have already determined that there was no consensus to remove them from the architecture. So, I don't know why it would make sense to remove them from this draft. >a) Do not require apps to support multi-sited nodes now, but > keep the address selection rules in place. > This means that in the future, if SL are available, > they will be used by ALL applications by default. An application will only use a site-local destination addresses if it is returned in the DNS and/or typed locally. So, it can't happen without the administrator or user doing something to make it happen. >b) Do not require apps to support multi-sited nodes now, and > remove the address selection rule that deal with scoped addresses. > This means that in the future, if SL are available, > they will not be used by default, but only by applications that request them. I don't understand how this is achieved by removing the default selection rules. If an application receives a site-local address from the DNS, how will removing scoped addressing rules from the default address selection draft prevent the app from using the site-local address? The assumption is that we are dealing with old apps that don't know anything about IPv6 scoped addressing, so we can't expect the app to recognize a site-local address and refuse to use it... > Keith has promised a draft to explain the trade-off between those two approaches, >I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt >until there is a clear resolution on this question. Unfortunately, Keith did not submit a draft by the deadline, so there will not be a draft before Yokohama. The Default Address Selection document has been out for months, has been reviewed several times by the WG, has undergone a WG last call and has been reviewed by the IESG. It doesn't seem right to delay this draft indefinitely waiting for another draft, especially when we haven't been told about any specific problems that this draft will cause. If there are specific, technical objections to this draft, please state them clearly on the mailing list. It would also be helpful to suggest specific text changes to the draft. This will give others and opportunity to agree or disagree about whether the issues should block the publication of this draft. Margaret -------------------------------------------------------------------- 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] --------------------------------------------------------------------
