> > => Why is it gone ? Not everyone wants NATs and for those who > > do, deprecating SL addresses will not help. It will just make > > their (Network admins) behaviour less predictable. > > it's not the case that NATs only affect networks that use them. > widespread use of NATs makes the market for some kinds of apps > so small, and the circumstances under which they can be used > so difficult to recognize, that those apps essentially cannot > be made commercially viable - at least not without adding > a huge amount of overhead and complexity in the form of > proxies and/or centralized servers, an doing addressing and > routing internal to the app. > > similarly, it's not the case that SLs only affect networks that > use them if SLs are widely used.
=> Yes, but my point is, this will happen independently of deprecating a bitstring. The /16 itself is meaningless; what we're arguing about is the use. So removing a /16 will not change anyone's mindset, it will just make things more unpredictable. > > => Obviously, if you choose to use SL for a disconnected > > network you're not interested in P2P on a global level. > > If you choose to use SL with globally routable addresses > > in the same network, you can get P2P. > > presuming of course that the globally routable addresses > are usable by any node that needs them. => Yes. > > => i don't know why some people try to resist existing > > facts. If you can't change it accept it and try to make > > the best out of it, i.e. write a BCP to tell people > > about the consequences of certain actions. Any attempt > > to change the world by deprecating SLs is an exercise > > in futility. Much better to educate people and hope that > > in time we will reduce the number of myths on the net. > > SLs were not carved in stone by the hand of God and brought > down from the mountain. > They can indeed be deprecated, though I don't see much > support for doing that. => Exactly, there is clearly no concensus on that. > They can also be discouraged. A BCP that discourages > uses of SLs except > in certain narrow cases and explains why is probably more > useful than a > BCP that tries to explain exactly when SLs cause problems > and when they don't. > Of course, it's quite possible to have both. => So let's have a shot at a BCP. It seems like a more productive step than the infinite loop that we're in right now. Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
