I think the working group has been making good progress on replacing site-local addresses and wanted to get feed back from the working group on how we should move forward. This is not intended to directly relate to the ongoing appeal of the working groups decision to deprecate the usage site-local addresses, but to get feedback on how to proceed. I think it is very important that we move forward on this issue and not rehash what has happened in the past.
We now have a combined local addressing requirements document <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative to site-local addresses draft <draft-hinden-ipv6-global-local-addr-02.txt> (accepted as a working group item at the Vienna IETF), and will soon have a draft describing why site-local addresses are being deprecated and doing the formal deprecation (authors identified and outline discussed at the Vienna IETF). Note that all of these documents will proceed through the normal working group and IETF processes of last calls and review.
I think legitimate questions have been raised about how the working group should go about deprecating site-local addresses given their maturity in the current specifications and use in deployed products. Specifically should they be deprecated independently from having an alternative solution available, at the same time an alternative is available, or sometime after an alternative is available. A forth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative.
I would like to hear from the working group on how we should proceed. I think the choices are:
A) Deprecate Site-Local addresses independently from having an alternative solution available. This would mean that the working group should treat the deprecation, and requirements and solution documents outlined above independently from each other. If there was no consensus on an alternative a replacement would not happen.
B) Deprecate Site-Local addresses at the same time as a alternative solution is agreed to. This would mean advancing both documents at the same time and making them include normative references to each other to insure that they were published at the same time. This would result in the deprecation only happening if a consensus was reached on an alternative.
C) Deprecate Site-Local addresses after an alternative is defined, standardized, and in operational practice. This would mean not advancing a deprecation document until there was operational evidence that the alternative was working and shown to be an improvement over Site-Local addresses.
Note: In the above choices "Deprecate Site-Local addresses" means publishing an RFC that does the formal deprecation.
Please respond to the list with your preference, or if there is an alternative approach that is an improvement from the ones I outlined. I hope that many of you will respond.
Thanks, Bob
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
