Subject: Re: [Ecrit] terminology

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 22:41:20 +0200

This discussion on terminology is very instructive,
but I am feeling a bit uncomfortable, because it
my not be very helpful for the real problem at hand.
 
We should consider: why do we need this definitions
for the requirements?
 
We are not defining business models here.
 
The real reason why we need these definitions is
the discussion we had in the other threat on L2, L3, VPNs
and what box is providing finally the location information to
the device, and where does this box get its location information
and so on. 

There exist many different scenarios, e.g. home users behind a NAT
connected via DSL, Cable, etc.Users in WiFi hotspots, small
enterprises, large enterprises, etc.

The problem I have is that I do not have a solution either
 
regards
Richard

________________________________

Von: [email-masked] im Auftrag von James M. Polk
Gesendet: Mi 14.09.2005 21:53
An: Andrew Newton; Tschofenig, Hannes
Cc: [email-masked]
Betreff: Re: AW: [Ecrit] terminology

At 08:05 AM 9/14/2005 -0400, Andrew Newton wrote:

>On Sep 14, 2005, at 4:50 AM, Tschofenig, Hannes wrote:
>
>>we should make sure that the requirements document contains the
>>terms we plan to use in the future.
>>as such, we should not introduce terms with a different meaning in
>>another document.
>>furthermore, if we think that new terms are needed then we should
>>add them to the requirements document.
>
>Understood.  I'll talk to James about it.

I believe we all need to agree on terminology, and use the same in each doc.

The recent confusion (multiple opinions) on ISP vs. IAP and ISP vs. ASP
tell me we don't agree yet on something fairly fundamental wrt
architectures - definition of a network.

John used a word that seemed totally clear to me, yet it is not used
anywhere I know of in this context: "attachment".

Barbara made the point that we need to maintain separate of the L2 provider
and the L3 provider - and I agree. This used to be legally separated, at
least in the US due to the L2 provider being regulated - and I'd like
someone to tell me if this is still true.

My opinion is that the acronym ISP is the one that is most out of place.
Here's why:

my ISP only gives me IP access the the wide open internet to any IP
application I have the software to do. This enables Application specific
(like only voice) SPs to become reachable.

So, perhaps we need to move the traditional term "ISP" to just "Internet
Provider", as that is all they need to do to qualify - provide Internet
connectivity.

I like John's "attachment" word to describe physical connectivity, we can
use the word "link" too.

Thus, the Attachment (or "Link") (radio or wireline) provider is at layer 2

The Internet Provider (no acronym!) is at Layer 3 providing IP addressing
and a default gateway out to the world via the Internet Protocol, with no
specific application access or communication.

And the ASP provides application control and enablement of services like
voice, video, IM, etc

Each of these 3 SHOULD be considered separate organizations UNLESS the user
is within the bounds of an Enterprise. This latter occurance necessitates
L2 and L3 to be merged into a single organization, but DOES NOT mean L7
necessarily is within the Enterprise. As through my VPN to my corporate
network I have access to an ASP such as Vonage for voice communications.

Thus

Link Provider
Internet Provider
Application (Service) Provider

I think this makes none of the above a subset of any other

How does this sound/read?

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

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

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Sep 2005 16:48:01 -0400

> We should consider: why do we need this definitions

Perhaps we just need:

Internet Attachment Provider - the entity that provides attachment to  
the Internet (layer 3) from a layer 2 network (i.e. this type of  
attachment is not considered of the same type as layer 3 tunneling).

Voice Service Provider - the entity that provides Voice over IP service.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Sep 2005 17:16:57 -0400

I think 3GPP and others get into trouble when they specify "boxes" where 
the interfaces are less-than-well-defined. In this particular case, our 
interfaces (protocols) are reasonably well defined:

(1) photons or electrons or radio waves
(2) cells or frames such as Ethernet or DSL (or other layer-2 mechanisms)
(3) IP packets
(4) DHCP
(5) RTP packets
(6) SIP signaling
(7) location mapping

In theory, we could have 7 different actors. For this particular 
discussion, we don't care about #7, but the question is whether we can 
reduce the number to something below 6 and whether a single user would 
simultaneously have multiple providers for each.

With dark fiber and things like split coax cables, (1) and (2) do not 
have to be the same entity.

For residential providers, (3) and (4) don't have to be same entity, but 
this depends a bit on the precise definition. As far as my 802.11 phone 
is concerned, is the coffee shop the provider of IP packets, even though 
it obviously buys that service from somebody else? If the coffee shop 
gets a fixed IP address (no DHCP) from its provider, the two are clearly 
not the same entities unless we also consider the coffee shop the 
Internet access/service provider as far as the phone is concerned.

With separate IM and voice providers, (5) and (6) may not be unique.

One way out of these philosophical discussions is to simply label this 
by protocol or layer. Thus, we'd have an "IP provider" or a "L1 provider".

As was mentioned, we don't really care about the business relationships, 
but rather trust and management relationships, for example. My concern 
is that the term "X service provider" will be understood by most outside 
parties to refer to a commercial entity providing X for a fee, even 
though that entity may have no direct protocol relationship with the 
emergency caller. Example: Technically, most definitions would make 
universities ISP/IAPs, but if somebody were to ask "Is Columbia an 
ISP?", people would be somewhat surprised if you answered yes. Defining 
terms in contradiction to commonly understood usage is not a recipe for 
clarity.

(And, yes, I've tried in the past to define various I*P terms, but am 
starting to doubt the payoff-to-effort ratio of such efforts.)

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 16:57:34 -0500

At 05:16 PM 9/14/2005 -0400, Henning Schulzrinne wrote:
>One way out of these philosophical discussions is to simply label this by 
>protocol or layer. Thus, we'd have an "IP provider" or a "L1 provider".

I think I suggested this 3 hours ago, in which I said

Link Provider (at Layer 2)
Internet Provider (at Layer 3/4/5)
Application (Service) Provider (at Layer 7)

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

>My concern is that the term "X service provider" will be understood by 
>most outside parties to refer to a commercial entity providing X for a 
>fee, even though that entity may have no direct protocol relationship with 
>the emergency caller. Example: Technically, most definitions would make 
>universities ISP/IAPs, but if somebody were to ask "Is Columbia an ISP?", 
>people would be somewhat surprised if you answered yes. Defining terms in 
>contradiction to commonly understood usage is not a recipe for clarity.
>

I'm getting equally frustrated in attempting this series of definitions

cheers,
James

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Sep 2005 18:07:39 -0400

> I think I suggested this 3 hours ago, in which I said

I'm sorry I missed this in the flood of messages today.

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

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

> 
> 
>> As was mentioned, we don't really care about the business 
>> relationships, but rather trust and management relationships, for 
>> example.
> 
> 
> 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.

In other words: not all ASPs are subject to emergency services mandates 
today in the US, 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). We might hope that crisp, unambiguous, protocol-based definitions 
will eventually make it into regulations, but that's probably naive to 
hope for.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 17:48:24 -0500

At 06:07 PM 9/14/2005 -0400, Henning Schulzrinne wrote:
>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.

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

>discussions we've had and I assume would an ASP in your estimation.

agreed

>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

cheers,
James

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