Subject: RE: Limiting the Use of Site-Local

From: "Michel Py" <[email-masked]>
Date: Mon, 28 Oct 2002 10:35:28 -0800

Keith,

In a nutshell, the point you are trying to make is that RFC1918
addresses are bad because NAT exists. I agree! (It's not like we had
much of a choice anyway).

Now, let's *not* generalize and say
1. site-local = RFC1918
2. site-local is bad because RFC1918 is bad.

RFC1918 is not that bad without NAT, and lots of people use it without
NAT as well. If I had any hint that IPv6 NAT will one day be invented
and used like IPv4 NAT, I would not have this position, but this is not
the case.

>> I think this is a terrible idea. I can envision many
>> situations where a host would need both a site-local
>> and a global address.

> please, elaborate.  I haven't seen a good one yet.

A somehow isolated subnet, where most hosts would have site-local only
addresses, except for a gateway or proxy that would have both.

> you're missing the burden that having a mixture of SLs
> and globals puts on apps.

You are missing the point, IMHO. This is not your call nor mine.
Site-local addresses do exist, been there for long, some people will
purposedly choose to use them in combination with global addresses. As
of today, the address selection draft addresses use of site-local and
global addresses simultaneously and I do not see a reason to change it.

Michel.

--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Mon, 28 Oct 2002 10:58:49 -0800

> and used like IPv4 NAT, I would not have this position, but this is not

People start with an unconnected network, used RFC1918 style addresses,
no NAT. Then, one day, they decide to connect to the Internet...
... and they realize it's "easier" (for some definition of easier)
to use NAT than getting real address space and renumber their network.
Now substitute IPv4 by IPv6 and you'll see IPv6 NAT.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 13:58:18 -0500

> addresses are bad because NAT exists. 

no, that's missing the point.  use of RFC 1918 addresses in a network
that can also use global Internet addresses is harmful regardless of
whether that connection to the global Internet uses NAT or whether it 
is merely via a router that filters traffic to/from the 1918 addresses.

NAT is irrelevant to this particular problem. The problem is that 
in the presence of either 1918 or SLs applications have to deal with 
a mixture of scoped and global addresses without any good way of knowing 
whether such an address is valid (and whether it means the same thing) 
in the context of a particular node.

> 2. site-local is bad because RFC1918 is bad.

sorry - the two are quite similar, and they cause similar problems for apps.

> addresses, except for a gateway or proxy that would have both.

that's what 1918 was intended for.  again, I don't have a huge problem
with it as long as the apps don't have to deal with multiple scopes -
but experience with 1918 predicts that that's exactly what will happen.

> global addresses simultaneously and I do not see a reason to change it.

IETF's job is to try to explain what will make the network work well.  
Imposing constraints on the use of SLs will help the network work better.
If SLs are encouraged as in the current draft it will degrade the ability 
of the network to support applications.  

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 28 Oct 2002 11:47:18 -0800

I have a basic problem with this thread. We have a few people discussing
fundamental changes in close to a vacuum. At best the result of this
discussion should be a separate BCP, but before that happens operators
of networks that actually use 1918 space need to be engaged to find out
their requirements. 

The whole idea that SL should be revoked if a global is available is
bogus. It is certainly reasonable for the manufacturer of light switches
to only support SL/LL rather than potentially multiple global prefixes.
There is no reason for those devices to interact across a scope
boundary, so the peer nodes that may also need global access MUST keep
their SL to interact in the limited scope. 

Tony

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Oct 2002 22:04:29 +0200 (EET)

On Mon, 28 Oct 2002, Tony Hain wrote:
[...]

> their SL to interact in the limited scope. 

This seems to be just primarily solving the "security and simple 
out-of-the-box configuration through site-locals" problem..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Roy Brabson <[email-masked]>
Date: Mon, 28 Oct 2002 16:58:29 -0400

> their SL to interact in the limited scope. 

I thought global addresses could be used to communicate with peers using 
addresses of any scope as long as the interface over which the packet is 
sent is in the same scope zone as that peer.  As such, a node with a 
global address does not require a site-local address to communicate with a 
node which has a site-local address but lacks a global address, as long as 
the two nodes reside within the same site.

Roy

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 16:32:11 -0500

Hi Tony,

At 02:47 PM 10/28/02, Tony Hain wrote:
>fundamental changes in close to a vacuum.

Obviously, a few people can't make a fundamental change to IPv6.
But, we can propose a change, and discuss it on the WG (which
should not resemble a vacuum).

>to only support SL/LL rather than potentially multiple global prefixes.

What would a light switch do differently to support site-local as
opposed to global?  It still needs to get a prefix from a router and
combine it with an IID using address autoconf.  So, I don't understand
what system requirements could be eliminated by refusing to support
global prefixes.

I've spent much of the last 7+ years working on IPv6 stacks for
embedded systems, and they have all supported global addressing.

Margaret

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 28 Oct 2002 17:02:12 -0500

>It is certainly reasonable for the manufacturer of light switches

So, my existing duct-tape-and-string home automation setup lets me
turn on my porch light from work if I'm coming home late.  Why would I
upgrade it to an IPv6-based system with less functionality?

					- Bill

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 28 Oct 2002 14:03:50 -0800

Margaret Wasserman wrote:
> >I have a basic problem with this thread. We have a few people 
> >discussing fundamental changes in close to a vacuum.
> 
> Obviously, a few people can't make a fundamental change to 
> IPv6. But, we can propose a change, and discuss it on the WG 
> (which should not resemble a vacuum).
> 
> >bogus. It is certainly reasonable for the manufacturer of light 
> >switches to only support SL/LL rather than potentially 
> multiple global 
> >prefixes.
> 
> What would a light switch do differently to support 
> site-local as opposed to global?  It still needs to get a 
> prefix from a router and combine it with an IID using address 
> autoconf.  So, I don't understand what system requirements 
> could be eliminated by refusing to support global prefixes.

There is no difference in a SL vs. global prefix in the process of
address creation in the stack. The real difference is that the simple
device frequently is concerned about memory consumption, and that is
minimized when it only has to support one SL & LL. The light switch
could have a simple policy that the only prefix in the RA that it looks
for is SL, which would minimize the management and make it more
plug-n-play.  

I am not claiming I know of devices that look like this, but the
opportunity exists the way things are currently defined. If there are
multi-party applications that can't deal with scope boundaries, they are
aware of that limitation and should be provided a mechanism to tell the
stack SL is not an option for this socket. 

My real problem is that the thread is about preventing or restricting
any use of the address format, simply because there is one valid case
where it is not a good choice. The fact that there are other cases which
are valid is being ignored. If someone wants to write a BCP that says SL
should not be used for multi-party apps, fine, but this doc should not
go further because other uses do not share the problem.

Tony

> 
> I've spent much of the last 7+ years working on IPv6 stacks 
> for embedded systems, and they have all supported global addressing.
> 
> Margaret
> 
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 17:48:17 -0500

> upgrade it to an IPv6-based system with less functionality?

yeah, that was essentially going to be my question - why would I
want to network my light switches, thermostat, dehumidifier, etc. 
unless doing so would allow me to access them from anywhere on the net?  
--------------------------------------------------------------------
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: Mon, 28 Oct 2002 17:59:54 -0500

> for is SL, which would minimize the management and make it more

such a policy would also make it dysfunctional.  it's completely bogus
for such devices to impose constraints on how a network is designed.

if a device is only going to recognize one RA prefix, it should 
probably be the shortest prefix that it sees.

> stack SL is not an option for this socket.

oh right, so we need to configure each application to be aware of network
topology to know when to use and when not to use SL.

> where it is not a good choice. 

so far there is at most one case where it is a good choice -  
providing a way for local connections to survive renumbering.
and there are almost certainly better ways to solve that problem -
defining explicit values for minimum time between renumberings
and maximum time that a connection should be expected to stay
up would be a good start, and they wouldn't be specific to local
connections.

> The fact that there are other cases which are valid is being ignored. 

we're still waiting to hear about them.

> If someone wants to write a BCP that says SL

no, it's the other way around.  if someone wants to impose the constraint
that large portions of the network should only support client-server apps
then they need to bear the burden of convincing the rest of us as to why
it's in the best interests of the Internet to have such a constraint.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 18:08:43 -0500

>probably be the shortest prefix that it sees.

Or, since all prefixes are 64-bits long, it should recognize
the first prefix it sees.

>up would be a good start, and they wouldn't be specific to local

I have never understood the emphasis on helping local long-lived
connections survive renumbering.  There are a plethora of other
events that can cause a long-lived connection to drop, so applications
already have to be written to re-establish their long-lived connections
if they go away.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 18:21:19 -0500

> already have to be written to re-establish their long-lived connections

it depends on how often you think renumbering will be necessary 
relative to those other events.  with backup power and reasonable
operating systems, there's no reason to not expect connections
to stay up (on average) for several weeks or even months.

at present few applications are capable of recovering from
address changes.  the ones that are tend to be those that don't
expect to connect for a long time anyway and those that interact 
directly with a human user who can initiate recovery. 

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 28 Oct 2002 15:27:21 -0800

[email-masked] wrote:
> ...
> such a policy would also make it dysfunctional.  it's 
> completely bogus for such devices to impose constraints on 
> how a network is designed.

I am talking about default. If you want to change the policy to allow
global access you should be able to do so, but there is no reason we
should create an open dos problem when we don't have to.

> probably be the shortest prefix that it sees.

Since they are all /64, that doesn't cut it. 

> 
> ...
> oh right, so we need to configure each application to be 
> aware of network topology to know when to use and when not to use SL.

Your input channel was shut down long ago. I was not arguing that the
app know about network topology, just that it is aware of its own
ability to deal with scope boundaries or not. If an app knows there are
failure modes when crossing scope boundaries, it should have an option
that prevents it from getting into that state. This is nothing more than
a flag that says 'this socket must be considered global scope'. 

> ...
> and there are almost certainly better ways to solve that 
> problem - defining explicit values for minimum time between 
> renumberings and maximum time that a connection should be 
> expected to stay up would be a good start, and they wouldn't 
> be specific to local connections.
> 

Your input channel is off. Despite the validity of the assumption,
network managers want the ability to have some devices addressed in a
space that can't be globally routed. The kinds of apps you are worried
about don't apply.

> no, it's the other way around.  if someone wants to impose 
> the constraint that large portions of the network should only 
> support client-server apps then they need to bear the burden 
> of convincing the rest of us as to why it's in the best 
> interests of the Internet to have such a constraint.

Peer-to-peer apps can use SL, as long as they are 2 party. When an app
is willing to deal with more than 2 parties, it knows that and should
have a means to refuse SL addresses if there is an alternative.

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 19:13:43 -0500

> > ...
> > such a policy would also make it dysfunctional.  it's=20
> > completely bogus for such devices to impose constraints on=20

so what you are saying is that IETF should legitimize the idea that 
security scopes and network topology coincide.  we *know* this is unwise.

> a flag that says 'this socket must be considered global scope'.

just saying "apps that can't deal with SLs shouldn't use SLs" doesn't 
work because sites that use SLs will expect that apps work with SLs,
and that global addressess aren't needed.  there's no way that an 
"option" will keep the app from failing in that scenario - at best 
the app can try to detect the reason for the failure.   even then, an 
explanation of the form "this app failed because it couldn't communicate
between node Z1 and node Q3 because Q3 seems to only have site local
addresses" isn't likely to cut it - the customer will demand that the
app support communication with SLs only to later find out that this 
still doesn't help because Z1 and Q3 (or perhaps a different pair of
nodes) don't share a common scope - meanwhile the app has acquired 10k 
more lines of code and its behavior has become less predictable.
and the customer will then demand that the app support internal addressing
and routing, because for some reason the network addresing plan is deemed 
to be carved in stone - even though it was based on a flawed design -
and the app isn't.  

SLs are a lot like A6 records - they will work fine *if* you understand
the constraints.  but the constraints are even hard for IETF people to
grasp.  we're better off without both.

as for *my* input channel... how many distributed applications have *you* 
tried to patch to deal with scoped addresses?    

> Despite the validity of the assumption,
> space that can't be globally routed. 

just because newtork managers want something doesn't mean that IETF
should complicate everyone's lives by giving it to them.  large numbers
of network managers have been deluded by snake oil salesmen.

if IETF starts catering to salesmen-induced delusions we may as well 
go back to using carrier pigeons - since it will work better than the
Internet.

> The kinds of apps you are worried about don't apply.

and who are you to say that (just to take one example) SIP doesn't 
need to be able to complete calls across scope boundaries?

> have a means to refuse SL addresses if there is an alternative.

easily done, *if* there is an alternative.  but if the alternatives
exist, why bother with SL at all?  it's easier to implement a
sane filtering policy with globals.

Keith

---

From: [email-masked]
Date: Tue, 29 Oct 2002 11:19:59 +1100

> in the context of a particular node.

	Which just means that we need to provide a way for the application /
	library to return appropriate addresses.  Make SL work rather than
	saying "kill them" or "don't put them in the DNS".

	I've already said how to put them in the DNS.  It requires a new
	record but it will work and it will remove the need for two faced
	DNS unless the sites *wants* to use two faced DNS to hide the records.

	Site locals provide a solution for a certian problem space.  They
	do create additional problems but they are not insolvable problems
	and are no different to the problems causes by LLs.

	You need a function that looks up names and returns addresses along
	with the scope_id.  We have that in getaddrinfo().  You need a
	function that takes a address and a scope_id and returns the name.
	We don't have that but it is very easy to do that in the DNS if you
	want to privided you have a scope-id to scope-name function which
	is need.

	e.g.
		<reverse-nibble>.<scope-name>  PTR <name>
	
	It's not zero-conf but sites will most probably never be zero-conf.

	e.g.

foo.example.net.  SA6 1080:0:0:0:8:800:200C:417A .
foo.example.net.  SA6 FE80:0:0:0:8:800:200C:417A my-site.example.net.
foo.example.net.  SA6 FEC0:0:0:0:8:800:200C:417A my-link.example.net.
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.1.ip6.arpa. (
	PTR foo.example.net. )
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.my-site.example.net. (
	PTR foo.example.net. )
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.my-link.example.net. (
	PTR foo.example.net. )

	and you have a local table that maps
	my-site.example.net and my-link.example.net to appropiate scope-id
	values.

	Now if you want to send address between applications in binary format
	just send SA6 rdata instead of AAAA rdata.

	Applications / libraries can filter out the addresses that are
	not useful to them if they want.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 29 Oct 2002 11:26:30 +1100

> Now substitute IPv4 by IPv6 and you'll see IPv6 NAT.

	Except with SL you don't re-number.  You just provide a additional
	global address.  All your nodes continue to use there existing SL
	addresses.  The routers advertise a new prefix.  The nodes configure
	a new address and register it in the DNS and are done.

	This is a lot less painful that what is required to go from using
	RFC 1918 address to using global IPv4 addresses.

	Mark

---

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

> 	library to return appropriate addresses.  

no, it doesn't solve the real problem.  putting SLs in a separate space
will keep existing apps from being confused by them, but it won't supply
global addresses when they are needed, it won't provide a way for appst
to recognize and deal with scope boundaries, and it won't stop sites from
requiring apps to recogize the new addresses and use them even though 
they're a tremendous pain in the wazoo.

and as I keep saying, DNS is just one example of an application that 
provides address referrals - are we going to impose the same amount of
additional complexity on every app that does this?

> Make SL work rather than

the best way to make them "work" is to make them global.

> 	Site locals provide a solution for a certian problem space.  

pray tell, what is that problem space?  especially if you eliminate
the bogus argument that they somehow provide security or relieve 
devices of the need to provide security.  long-lived connections,
perhaps.  that's all I've seen so far.

>       They

LLs do cause similar problems.  but at least LLs have a use case -
bootstrapping, autoconfiguration, router and neighbor discovery, 
ad hoc networks.  those are compelling enough that it makes sense 
to say "keep LLs but don't use LLs except for those specific cases".  
I'm still looking for a compelling case for SLs.

> 	function that takes a address and a scope_id and returns the name.

and you need for apps to know which addresses work in which scopes,
and to know which scopes each node can access, and to keep track of 
each node's scopes so that they'll know how to do referrals, and how
to route messages across that maze of scopes.  and to do that you need
a global scope space.  suddenly 128 bits isn't enough for an address 
any longer, because we also need a scope id to disambiguate scoped 
addresses.  why don't we just make IPv7 with 256 bits of address,
and assign 128 bits for a global scope id?  are we having fun yet?

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 20:02:05 -0500

addresses. 

and your applications break when they talk to external nodes and they find
that using SLs for referrals no longer works.
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 21:23:50 -0500

Hi Mark,

>         DNS unless the sites *wants* to use two faced DNS to hide the 

I don't have enough DNS expertise to fully evaluate your idea, but it
looks like an interesting possibility to resolve several problems with
putting IPv6 site-local addresses in the DNS.

Have you made this suggestion on any DNS-related groups, like dnsext,
perhaps?  It would be interesting to see if other DNS folks think that
this makes sense.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 22:21:47 -0500

>         I've bounced the idea of other DNS folks in the past and
>         they have been happy enough with it.  It was more a problem
>         of getting it heard here.
>
>         Mark

Well, I've certainly heard it, and it looks much better, to me,
than the "two-faced" DNS hack I've heard described in the past.

I'd love to hear what the other DNS folks think, because maybe
this would be a promising approach to address one of the serious
problems with private addressing.

If you decide to write it up in a draft and/or post it to the
dnsext mailing list, please let me know so that I can follow the
discussion.

Margaret

---

From: [email-masked]
Date: Tue, 29 Oct 2002 14:17:30 +1100

Mark

---

From: [email-masked]
Date: Tue, 29 Oct 2002 16:09:05 +1100

> that using SLs for referrals no longer works.

	And application break when you use non-globally-routed GA's.

	People want permanent private address space be that multiply
	allocated (SL/1918) or non-globally-routed global address
	space (NGRGAS).  Passing addresses in either is not
	guaranteed to work with every node.  NGRGAS removes one
	address maps to multiple nodes but it does not help identify
	if two nodes share a common site though you can identify
	if a node shares your site.

	NGRGAS also requires a registry to allocate the address space.
	
	However if you look at my SA6 solution you can reliably
	detect if two nodes share a common site.  You can pass around
	references without ambiguity.  You don't need a seperate
	registry.

	Mark

---

From: Rob Austein <[email-masked]>
Date: Tue, 29 Oct 2002 00:38:20 -0500

> problems with private addressing.

From a strictly DNS technical point of view, Mark's proposal is fine.
That is, the DNS protocol mechanics are not a problem (nor would I
expect them to be, coming from Mark).

There is, however, the issue of the local mapping table between scope
id and DNS equivilent (my-site.example.net and my-link.example.net in
Mark's example).  As Mark mentioned, this is not zeroconf.

Also note that this mechanism uses a new RR type.  This is certainly
doable, but it's a bit painful for address types due to the DNS
additional section processing rules and the number of other pieces of
deployed code that would need to be updated.  Of course, one could
back translate SA6 to AAAA, but that breaks end-to-end DNSSEC....
Dunno if this is starting to sound familiar to anybody else, but my
ears are still ringing from the AAAA vs A6 debate, and I don't
particularly want to relive that experience anytime soon.

The above comments are only intended to discuss the DNS sub-thread,
and should not be construed as a change from my previously stated
support for Margaret's proposal to forbid use of site-local addresses
on globally-connected networks.

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Oct 2002 09:10:46 -0500

>         guaranteed to work with every node.  

no.  but if you use globals for all addresses then you can get a
reasonable separation of function between apps/hosts and the network -
if you can't communicate between two nodes it's either because part of
the network is down or because the network doesn't let you.  either
way, it's not something that the application can be expected to solve.
so with globals the application no longer has to be responsible for 
trying to work around deficiencies in the addressing scheme.   

> 	  NGRGAS removes one
>         address maps to multiple nodes 

yes.

> but it does not help identify

the node shouldn't need to do this.  the app sends to an address.  
if it gets there, it gets there.  if not, it's not the app's problem.
the app can try to fail-over to other addresses if they exist, but
the first address should work with high probability.  in other words,
we need to abandon this idea that a host can have an arbitrary number
of addresses with varying scopes and lifetimes and connectivity, 
and it's up to hosts/apps to sort out which one is best to use.
instead hosts should have a small number of addresses (most of the time
just 1, 2 during renumbering periods) each of which is valid from 
anywhere, and the network should decide how best to get the traffic 
there.  (no I'm not suggesting to deprecate LLs but normal apps should 
use them only as a last resort or when explicitly configured to do so.) 
 
>         NGRGAS also requires a registry to allocate the address space.

if we tried I'm sure we could come up with a way to allocate non-routable
globals without a registry.   I'm convinced that this is vital for the
long-term success of IPv6.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 29 Oct 2002 12:11:24 -0800

Keith Moore wrote:
> ...  in other words, we need to abandon this idea 
> that a host can have an arbitrary number of addresses with 
> varying scopes and lifetimes and connectivity, 
> and it's up to hosts/apps to sort out which one is best to 
> use. ...

We have heard you say this many times over, but you are refusing to hear
that other people have figured out how to use them for their specific
app or topology. Since you have identified the case that a multi-party
app can't do the right thing when the name/address resolution is only
capable of a single scope, you should write a BCP to that effect.
Otherwise your argument ammounts to a demand that we not allow doing
more than what we always have done, simply because it is easier.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Oct 2002 15:24:31 -0500

> app or topology. 

Just because some apps happen to work with SLs or are easily modified
to work with SLs does not mean that SLs are either harmless or justified.

> Since you have identified the case that a multi-party

I have no interest in describing how to impair apps to deal with an 
impaired network.  I find it far saner, and hopefully more productive,
to keep the network from being impaired in the first place.

> more than what we always have done, simply because it is easier.

No, I'm arguing for a more flexible Internet, one that can support
a wider range of applications with less complexity.  more warts does 
not equate to more flexibility,  and SL is a good example of a wart 
that decreases flexibility.

Keith