Hi Bob, I think option B is a balanced alternative, unless someone can open my eyes about any cons on this one.
Regards, Jordi ----- Original Message ----- From: "Bob Hinden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 8:06 PM 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] > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com -------------------------------------------------------------------- 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] --------------------------------------------------------------------
