Given the requirements from edge network managers I have talked to, I would prefer C, but could live with B.
Tony > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bob Hinden > Sent: Monday, August 04, 2003 11:07 AM > 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] --------------------------------------------------------------------
