Alain, Thanks. It's clear that the wording in this draft has to be tuned to intercept the WG's consensus, when there is a clear consensus. I think the present wording is what the authors thought they heard in Vienna. Obviously, the next version needs to be tuned to where the discussion has gone since then. But let's not wordsmith until there is some clarity in the WG.
As for the "replacement" sentence, I can agree that it is not yet a WG consensus, although it is certainly the view of a substantial number of people. Again, this can certainly be tuned. What *really* matters is whether people are happy with section 4, the actual deprecation text. That is the standards action proposed by the draft. Brian Alain Durand wrote: > > I was first happy to see this document coming. However, I'm a bit > disappointed. > The section on the ambiguity of SL is good, still I'm not sure those > are the only problems with SL... > But, what is more worrisome is the notion that the ipng wg > has to find a replacement for SL: > > "In its meeting in March 2003, the group reached a measure of agreement > that these > issues were serious enough to warrant a replacement of site local > addresses in their original form" > > From the current discussion, this is not at all clear that this is waht > we have to do. > As Margaret articulated very clearly: > > > There are a number of situations (disconnected sites, > > intermittently connected sites, etc.) where provider-allocated > > addressing is not a good method for address assignment. > > > > We need to figure out how these networks should be addressed. > > Our solution(s) may (or may not) require various properties of > > "local addressing": a provider-independent address prefix, > > addresses that are defined to have limited routability, > > addresses with special autoconfiguration properties, etc. > > > > Margaret > > Also worrisome is the implicit endorsement of the Hain/Templin and > Hinden/Haberman drafts as 'the' replacement solution: > > "Obviously, site locals also have some benefits, without > which they would have been removed from the specification long ago. > The perceived benefits of site local are that they are simple, > stable, and private [Hain/Templin]. However, it appears that these > benefits can be also obtained with an alternative architecture, for > example [Hinden/Haberman], in which addresses are not ambiguous and > do not have a simple explicit scope." > > Hinting that there is work currently underway to provide solutions > where SL was useful and PA does not work is ok. > Taking side in the current raging debate over those two drafts in not ok. > > - Alain. > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- 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] --------------------------------------------------------------------
