Subject: RE: [Ecrit] terminology

From: "Stastny Richard" <[email-masked]>
Date: Thu, 15 Sep 2005 09:35:54 +0200

James Polk proposed:

> Link Layer Provider (LLP)
> Internet Layer Provider (ILP)
> Application Layer Provider (ALP)

I could live with these definitions, especially if
we give the other terms as examples: ALP e.g. a VSP
This also includes self-provision. And it would
also save some discussions later if the example terms
are not matching exactly.

Now I cam move on to my next question: on which of these
layers is the mapping database (LCMS) or the DNS in general? ;-)

It may seem to some that I am picky here, but I consider
this discussion as a trial run for the parallel discussions
going on the exact same issues in voipeer and Carrier ENUM ;-)

And the arguments and solutions found here will be very useful
over there ;-)

And over there there ARE business models involved.

Cheers 
Richard

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, September 15, 2005 12:48 AM
> To: Henning Schulzrinne
> Cc: Andrew Newton; Stastny Richard; [email-masked]
> Subject: Re: [Ecrit] terminology
> 
> At 06:07 PM 9/14/2005 -0400, Henning Schulzrinne wrote:
> >>I think I suggested this 3 hours ago, in which I said
> >
> >I'm sorry I missed this in the flood of messages today.
> >
> >>Link Provider (at Layer 2)
> >>Internet Provider (at Layer 3/4/5)
> >
> >As far as I can tell, TCP (layer 4) is not provided by anyone except
the
> >two TCP end hosts. I don't think you'd want to call Microsoft an
Internet
> >Provider. I'm not sure what layer 5 is.
> 
> 3/4/5 is getting into the backbone nature of an IP transport function
of
> an
> Internet Provider, like where RTP is (as was mentioned specifically in
a
> message within the last 24 hours) - perhaps I shouldn't use numbers
other
> than 3 for the Internet Provider.
> 
> 
> 
> >>Application (Service) Provider (at Layer 7)
> >
> >This division is fairly similar to the one that had been in many of
the
> >early requirements documents I had a hand in drafting. However, I
tend to
> >believe now that there are a sufficient number of corner cases where
such
> >terms will yield more confusion than insight.
> 
> we talk of a VSP without hesitation now, and that orgnaization is the
> provider of a specific application.
> 
> If we agreed on the use of "Application" here to mean Layer 7
Provider, we
> can get past the confusion - I hope. This is one reason why I think we
> need
> to get rid of the word "service" in ISP and ASP. That is the word I
> believe
> is the most confusing, because voice is a service, but in the context
of
> an
> Internet Service Provider, the ISP might not be the one to provide
that
> service - hense there is confusion.
> 
> 
> 
> 
> >>>As was mentioned, we don't really care about the business
> relationships,
> >>>but rather trust and management relationships, for example.
> >>
> >>I disagree with this statement because of the politics and
regulation
> >>(that's going to be) involved. Specifically with respect to the
FCC's
> >>ruling that Vonage-type companies MUST produce the 911 call at the
> >>appropriate PSAP. This has little to do with trust, the way you're
> >>meaning it (I believe).
> >
> >Unfortunately, these terms are not even clear within the regulatory
> >community. Unless you want to say "A voice service provider is
whatever
> >the FCC believes today it happens to be (until some federal court
tells
> >them otherwise)", this doesn't help much. The only term they define,
by
> >the way, is "connected voice provider", which is yet another beast
and
> >clearly does not, for example, include (say) Yahoo! or FWD or (say)
> >Jabber, although they would be considered an ASP according to most
> >discussions we've had and I assume would an ASP in your estimation.
> 
> agreed
> 
> 
> >In other words: not all ASPs are subject to emergency services
mandates
> >today in the US,
> 
> I absolutely agree with this, as we're focusing on voice first, with
IM
> and
> video later; but for now, IM providers are not in this emergency
services
> mix.
> 
> >but some might be today or in other countries.
> >
> >In short: I think trying to follow the regulatory definitions gets us
> into
> >national regulations we have no way of tracking (nor should we try
to).
> 
> I'm not saying "get into regulatory definitions" per se, unless there
is
> one staring us in the face like the recent one is (US FCC 05-116).
Flying
> in the face of this seems equally foolish IMO.
> 
> >We might hope that crisp, unambiguous, protocol-based definitions
will
> >eventually make it into regulations, but that's probably naive to
hope
> for.
> 
> I wish you had your way, I would prefer that too.
> 
> Perhaps we go with longer terms:
> 
> Link Layer Provider (LLP)
> Internet Layer Provider (ILP)
> Application Layer Provider (ALP)
> 
> I'm not trying to just come up with terms for the sake of terms, I'm
> trying
> to get to the point where everyone can agree on a set of meanings and
have
> discussions without having to define what is being discussed each time
a
> discussion comes up
> 
> 
> >Henning
> 
> 
> cheers,
> James
> 
>                                  *******************
>                  Truth is not to be argued... it is to be presented.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Sep 2005 00:49:00 -0400

One easy-to-remember version is to call them

L1P
L3P
L7P

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Sep 2005 09:31:06 -0400

in-line....

> I could live with these definitions, especially if we give 
> the other terms as examples: ALP e.g. a VSP This also 
> includes self-provision. And it would also save some 
> discussions later if the example terms are not matching exactly.
> 

I'll bite.....the mapping database (all pieces) and DNS (resolver, recursive
server, authoritative server) are all layer 7 (applications).

(I missed the meaning of LCMS - too much email!)

-Marc-

> 
> It may seem to some that I am picky here, but I consider this 
> discussion as a trial run for the parallel discussions going 
> on the exact same issues in voipeer and Carrier ENUM ;-)
> 
> And the arguments and solutions found here will be very 
> useful over there ;-)
> 
> > need to get rid of the word "service" in ISP and ASP. That 
> is the word 
> > I believe is the most confusing, because voice is a service, but in 
> > the context
> of
> > an
> > trying to get to the point where everyone can agree on a set of 
> > meanings and
> have

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Sep 2005 09:45:34 -0400

I would rather not have any reference to layer 1.....please replace with
layer 2.

1) I doubt if dry copper or dark fiber is marketed any longer....at least in
use cases we are concerned with.

2) Although I agree that knowledge of layer 1 is where the actual
information is derived for 'network-based location mechanisms for physical
media' discussed here, we are only concerned with a mechanism that attempts
to 'automate' gathering this location information.  Since dry copper and
dark fiber can't 'talk', it is much easier to deal with the media access
control protocols that can/do 'talk'.  (Plus the fact we would bring
wikipedia to it's knees attempting to understand layer 1 wrt to wireless.)

So, I don't care about labels as long as they have reference to 2, 3, and
7....

Just another opinion,

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: Friday, September 16, 2005 12:49 AM
> To: Stastny Richard
> Cc: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Sep 2005 20:33:15 -0400

> I would rather not have any reference to layer 1.....please replace  

Typo on my part. Definitely should have been L2.

> use cases we are concerned with.

Not particularly relevant, but it is becoming extremely popular for  
large universities. All NYC and beyond research universities are  
converting to getting dark fiber and ditching their traditional SONET  
or similar provider. Google is apparently doing something similar,  
for ends unknown (to me).

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 15:56:26 -0500

All

I've heard and read the statements and requirements from folks that the 
routing of a call to a PSAP needs to be as fresh as possible because a 
particular PSAP might have moved, or more accurately, that a location might 
be served "on a moment's notice" by a different PSAP.

I'd like to ask how often this happens today. Does anyone know how often a 
location needs to contact a different PSAP than its normal/standard one?

It seems to me that a lot of us might be imagining a worse-case scenario 
that we need to design protocols for, and that this worse-case scenario 
happens often. If this is, say only 0.01% of the time - or even under 5% of 
all emergency calls (2 standard deviations, or SDs), I'm thinking we're 
focusing too much energy on solving something that is a statistical "outlier".

Today's emergency systems aren't build for 2 SDs, and especially not for 4 SDs.

cheers,
James

                                 *******************

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Sep 2005 17:23:12 -0400

Is this a trick question?

Its pretty hard to decide what happens in a disaster, but you sure want 
emergency calling to work.  How often do disasters occur?  Do you wish 
to be in the position of defending the decision to have catagory 3 
levees because there hasn't been a catagory 4 hurricane in 200 years?  
How many standard deviations is that?

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 16:51:09 -0500

At 05:23 PM 9/20/2005 -0400, Brian Rosen wrote:
>emergency calling to work.

The phone infrastructure has to work for 911 to work. Just look at Katrina 
for evidence of how 911 didn't work on multiple levels - either the phone 
switches didn't work, or the call centers weren't there, or they were there 
and told the people that help WAS NOT on the way. Listen to the MSNBC tapes 
of the 911 calls for proof of that last one.

ECRIT shouldn't solve for this because the infrastructure wasn't there.

If the infrastructure was there, shouldn't SIP proxies reroute the INVITEs? 
Pushing the "take this URI and send any message to it to this <new> IP 
address" to affected Proxies seems to me to be the best of all worlds.

>How often do disasters occur?

911 isn't about disasters, although folks use it in times of disasters - 
and I can ask the question about how effective it is during disasters next 
if you want. 911 is about individuals calling for local emergencies.

         There was a car accident.
         There is a person having a heart attack.
         Someone is breaking into my house.
         etc

This is what 911 is for at its roots.

Lets not plan this to solve for Katrina type disasters and build in all 
this complexity and cost that will make it less capable and less deployed.

>Do you wish to be in the position of defending the decision to have 
>catagory 3 levees because there hasn't been a catagory 4 hurricane in 200 
>years?

Dude, like I said, you can listen to the 911 recordings yourself to 
determine IF THE 911 SYSTEM TODAY worked. If was because the infrastructure 
- that we are not changing - didn't work.

>How many standard deviations is that?

listen to the recordings and hear the operators tell people they should 
have left the city already, and that help was not coming. Would it matter 
which protocol was used in that case?

Who expected the operators that did receive the calls to turn people away 
like that?

cheers,
James

                                 *******************