Hi all, I vote for B.
On Wed, 27 Aug 2003, Bob Hinden wrote: > The current results of the poll (appended below) started early in August are: > > Preference A 21 > Preference B 13 > Preference C 7 > ------ > Total 41 > > If you missed this and want to express a preference, please do so. 41 > isn't a large number given the size of the working group. The chairs > wanted to give folks who might have missed this due to being on vacation or > who were overwhelmed by the amount of email a chance to respond. You can > send your responses directly to the chairs or to the list. We plan to send > a final summary (including the actual results to make sure we got them > correctly) in a few weeks. > > Thanks, > Bob > > >Date: Mon, 04 Aug 2003 11:06:55 -0700 > >To: [EMAIL PROTECTED] > >From: Bob Hinden <[EMAIL PROTECTED]> > >Subject: Moving forward on Site-Local and Local Addressing > >Cc: [EMAIL PROTECTED] > > > >[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] > -------------------------------------------------------------------- > -- Raul Rivero | Mundinteractivos - El Mundo | Director Tecnico | Pradillo, 42 | [EMAIL PROTECTED] | 28002 - Madrid (SPAIN, EU) | www.elmundo.es | Tel: (+34) 915856018 | -------------------------------------------------------------------- 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] --------------------------------------------------------------------
