Subject: Re: [Ecrit] terminology

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 15:51:07 -0500

At 10:41 PM 9/14/2005 +0200, Stastny Richard wrote:
>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.

well, I'm tired of us talking past each other from different definitions to 
the same terms. Hannes pointed out that the Arch doc uses slightly 
different definitions than the requirements doc - and this ought to be made 
consistent so we can all communicate more effectively and get to the 
problems you articulate below.

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

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