Subject: RE: Node Requirements Issue 3

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 1 Nov 2002 01:16:06 +0100

> > => 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-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 19:23:39 -0500

> things more unpredictable.

well, there's no way to make a range of bit patterns cease to exist -
that's even less feasible than willing the tide to go away.

nor, as I've said several times, do I advocate re-allocating that
range of bit patterns for any other purpose, or even declaring
that they must not be used.

it seems to me that the real question is whether we should continue 
to promote the idea that SLs are good for any kind of general-purpose 
use by applications (say for security), or whether we should discourage 
such use.  if we can discourage use of SLs except in isolated networks 
or other rare corner cases, we'll avoid most of the potential harm that 
can come from them.

>   > 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.
> 

indeed.  I actually think we might be getting somewhere.

Keith