I'll go for B, or perhaps A.9 (i.e. a version of B in which we avoid recursive normative references between the two documents).
I don't think we help anyone by delaying the deprecation until a new solution is "in operational practice." Deprecation doesn't mean switching off; it just means a strong statement about future switching off. So there is no reason to wait as in C. Personally I would happily accept A, but it isn't worth a fight. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK Bob Hinden wrote: > > [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] --------------------------------------------------------------------
