Hi. I vote B with C as a second preference.
Ending up with no site locals for any period of time will just result in people inventing them in an ad-hoc fashion. Regards, Elwyn Davies > -----Original Message----- > From: Bob Hinden [mailto:[EMAIL PROTECTED] > Sent: 27 August 2003 23:27 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; Margaret Wasserman > Subject: Current Results from Poll > > > 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] --------------------------------------------------------------------
