My understanding is that the workgroup has voted to deprecate site-locals unconditionally (having no dependency on the development and acceptance of alternatives). Thus, I vote for A.
Apart from the above reason, I feel that deprecating site-locals ASAP will lead to a rapid development of alternate solutions, as the WG will have an urgency to fill the holes left by site-locals. CP > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED] On Behalf Of Bob Hinden > Sent: Monday, August 04, 2003 11:37 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Moving forward on Site-Local and Local Addressing > > [IPv6 working group chair hat on] > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
