Thomas Narten wrote: > ... > I've seen it now (somewhat independently) in the zeroconf WG > too, where similar issues have been discussed with LL > addressing for IPv4. There are plenty of people there that > don't see what is hard about scoping and that it's not a big > deal to make applications handle them. But over time, more > people have also come around to understanding that there are > issues, and there are problems with scoping. > > And if you go to applications people (that is, those folk > that spend their lives doing applications rather than stack > work) they seem much more concerned on average that scoped > addresses have significant (bad) implications for applications.
This should not be surprising. Given that the applications community blindly assumes there is a single addressing scope, when they bump into the reality of the deployed network there will be problems. Proclaiming that scopes are bad for applications does not make the filtering that causes scopes go away. > > > Second, by your own account we do need to prepare documents > about what > > to do next. Call it deprecation if you want what I call it > is that we > > have more work to do on site-locals and on the scoped architecture. > > Clearly, that needs to be done. But there is a basic > chicken-and-egg problem. If the the WG isn't going to > deprecate SLs, why would anyone bother writing the document > calling for their deprecation? The purpose of the current > discussion is to figure out whether we should go to the next > steps of making changes in various documents. The discussion that should have happened first is 'what alternatives do we have to deal with the requirements that network managers are using SL to deal with?' Without a clear replacement, and with comments that some real problems are 'uninteresting', the network manager will insist on keeping the current tool. Once we provide alternatives that meet all of the requirements, nobody will care about keeping SL as currently defined. If we fail to meet all the requirements, there will still be a need for the current SL in those environments. There is no point in getting rid of SL now, only to reintroduce it later when we have failed to meet a set of requirements with viable alternatives. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
