Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 21 Oct 2005 15:03:51 -0400

p.s.  There are no carriers in Skype, correct?

Mike 

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Friday, October 21, 2005 1:57 PM
> To: Michael Hammer (mhammer); 'David Meyer'; 'Pfautz, Penn L, NEO'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt
> 
> > a service provider authorized to offer telephony services 
> to the public.
> 
> Does this include Skype? It's the biggest anyway.
> 
> :-) Thanks, Henry
> 
> 
>  
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Hammer
> (mhammer)
> Sent: Friday, October 21, 2005 12:30 PM
> To: David Meyer; Pfautz, Penn L, NEO
> Cc: [email-masked]; [email-masked]
> Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt
> 
> David,
> 
> A slight modification suggestion below. 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of David Meyer
> > Sent: Friday, October 21, 2005 11:12 AM
> > To: Pfautz, Penn L, NEO
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt
> > 
> > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote:
> > > Dave:
> > > This is a nice start (indeed more than a start). I just have two 
> > > comments at this point:
> > > 
> > > 1. The definition of carrier in 3.6 is probably too 
> restrictive.  I 
> > > would not make it contingent on issuance of E.164 numbers
> > but rather
> > > just the provision of PSTN service. I appreciate your use our 
> > > carrier-of-record definition in 4.1.
> > 
> > 
> > 	How about:
> > 
> > 3.6.  Carrier
> > 
> >    A carrier is defined to be a service provider authorized 
> >    to provision PSTN
> 
> The term PSTN is often used to mean the TDM networks offering 
> publicly available telephony services.  In order to get away 
> from the TDM aspects, which some day might go away, how about:
> 
> a service provider authorized to offer telephony services to 
> the public.
> 
> That should cover both cases and gets away from unintended 
> baggage.  I am assuming that the enterprises are not 
> considered pseudo-carriers and intended to be covered here.
> 
> Mike
> 
> >    services.  Note that the provision of such services is usually
> >    coupled with the authority to issue E.164 numbers [ITU.E164.1991]
> >    under the authority of a National Regulatory Authority (NRA).
> > 
> > 	
> > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would
> > like to see
> > > included the concepts that a) peering involves delivery 
> of packets 
> > > that terminate on the peer's network and b) peering is 
> done without 
> > > traffic settlement charges.
> > 
> > 	I'm ok with a) termination of traffic, but I'd like to
> > 	avoid discussing SFI more than I have (see section
> > 	3.7). So how about:
> > 
> > 3.7.1.  Layer 3 Peering
> > 
> >    Layer 3 peering refers to interconnection of two service 
> providers
> >    for the purposes of exchanging IP packets which destined for one 
> > (or
> >    both) of the peer's networks.  Layer 3 peering is generally 
> > agnostic
> >    to the IP payload, and is frequently achieved using a routing
> >    protocol such as BGP [RFC1771] to exchange the required routing
> >    information.
> > 
> >    An alternate, perhaps more operational definition of layer
> > 3 peering
> >    is that two peers exchange their customer routers 
> (only), and hence
> >    any traffic between peers terminates on on the peer's network.
> > 
> > 	
> > 	Dave
> > 
> > ---
> > 
> > 
> > 
> > 
> > Network Working Group                                         
> >   D. Meyer
> > Internet-Draft                                          
> > October 21, 2005
> > Expires: April 24, 2006
> > 
> > 
> >         Terminology for Describing VoIP Peering and Interconnect
> >                  draft-meyer-voipeer-terminology-04.txt
> > 
> > Status of this Memo
> > 
> >    By submitting this Internet-Draft, each author 
> represents that any
> >    applicable patent or other IPR claims of which he or she is aware
> >    have been or will be disclosed, and any of which he or 
> she becomes
> >    aware will be disclosed, in accordance with Section 6 of BCP 79.
> > 
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF), its areas, and its working groups.  Note that
> >    other groups may also distribute working documents as Internet-
> >    Drafts.
> > 
> >    Internet-Drafts are draft documents valid for a maximum of six 
> > months
> >    and may be updated, replaced, or obsoleted by other documents at 
> > any
> >    time.  It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as "work in progress."
> > 
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt.
> > 
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> > 
> >    This Internet-Draft will expire on April 24, 2006.
> > 
> > Copyright Notice
> > 
> >    Copyright (C) The Internet Society (2005).
> > 
> > Abstract
> > 
> >    This document defines the terminology that is to be used by the 
> > Voice
> >    Over IP Peering and Interconnect Working Group 
> (voipeer), and has 
> > as
> >    its primary objective to focus the VOIPEER Working Group 
> during its
> >    discussions, and when writing requirements, gap analysis 
> and other
> >    solutions oriented documents.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 1]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> > Table of Contents
> > 
> >    1.  Introduction . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  3
> >    2.  Context  . . . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  3
> >    3.  General Definitions  . . . . . . . . . . . . . . . . . 
> > . . . .  4
> >      3.1.  Call Routing Data  . . . . . . . . . . . . . . . . 
> > . . . .  4
> >      3.2.  Call Routing . . . . . . . . . . . . . . . . . . . 
> > . . . .  4
> >      3.3.  PSTN . . . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  5
> >      3.4.  Network  . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  5
> >      3.5.  VoIP Service Provider  . . . . . . . . . . . . . . 
> > . . . .  5
> >      3.6.  Carrier  . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  5
> >      3.7.  Peering  . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  5
> >        3.7.1.  Layer 3 Peering  . . . . . . . . . . . . . . . 
> > . . . .  6
> >        3.7.2.  Layer 5 Peering  . . . . . . . . . . . . . . . 
> > . . . .  6
> >      3.8.  VoIP Peering . . . . . . . . . . . . . . . . . . . 
> > . . . .  6
> >    4.  ENUM . . . . . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  6
> >      4.1.  Carrier of Record  . . . . . . . . . . . . . . . . 
> > . . . .  6
> >      4.2.  Public ENUM  . . . . . . . . . . . . . . . . . . . 
> > . . . .  6
> >      4.3.  Private ENUM . . . . . . . . . . . . . . . . . . . 
> > . . . .  7
> >      4.4.  Carrier ENUM . . . . . . . . . . . . . . . . . . . 
> > . . . .  7
> >    5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  7
> >    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 
> > . . . .  7
> >    7.  Security Considerations  . . . . . . . . . . . . . . . 
> > . . . .  8
> >    8.  IANA Considerations  . . . . . . . . . . . . . . . . . 
> > . . . .  8
> >    9.  References . . . . . . . . . . . . . . . . . . . . . . 
> > . . . .  8
> >      9.1.  Normative References . . . . . . . . . . . . . . . 
> > . . . .  8
> >      9.2.  Informative References . . . . . . . . . . . . . . 
> > . . . .  8
> >    Author's Address . . . . . . . . . . . . . . . . . . . . . 
> > . . . . 10
> >    Intellectual Property and Copyright Statements . . . . . . 
> > . . . . 11
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 2]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> > 1.  Introduction
> > 
> >    The term "VoIP Peering" has historically been used to describe a 
> > wide
> >    variety of aspects pertaining to the interconnection of service
> >    provider networks and to the delivery of SIP call 
> termination over
> >    those interconnections.  The discussion of these 
> interconnections 
> > has
> >    at times been confused by the fact that the term "peering" 
> > is used in
> >    various contexts to relate to interconnection at 
> different levels 
> > in
> >    a protocol stack.  VoIP peering focuses on how to identify and 
> > route
> >    calls at the application layer, and it does not
> > (necessarily) involve
> >    the exchange of packet routing data or media sessions.  In
> >    particular, "layer 5 network" is used here to refer to the
> >    interconnection between SIP servers, as opposed to 
> interconnection 
> > at
> >    the IP layer ("layer 3").  Finally, the terms "peering" and
> >    "interconnect" are used interchangeably throughout this document.
> > 
> >    This document introduces standard terminology for use in
> >    characterizing VoIP interconnection.  Note however, that 
> while this
> >    document is primarily targeted at the VoIP interconnect case, the
> >    terminology described here is applicable to those cases in which
> >    service providers interconnect using SIP signaling for 
> real-time or
> >    quasi-real-time communications.
> > 
> >    The remainder of this document is organized as follows: Section 2
> >    provides the general context for the VOIPEER Working Group, and
> >    Section 3 provides the general definitions for real-time 
> SIP based
> >    communication, with focus on the VoIP interconnect case. 
>  Section 4
> >    briefly touches on terms from the ENUM Working Group.  Finally,
> >    Section 5 provides comments on usage.
> > 
> > 
> > 2.  Context
> > 
> >    Figure 1 depicts the general VoIP interconnect context.  In this
> >    case, the caller uses an E.164 number [ITU.E164.1991] as 
> the "name"
> >    of the called user.  Note that this E.164 number is not 
> an address,
> >    since at this point we do not have information about where the 
> > named
> >    endpoint is located.  In the case shown here, an E.164 number is 
> > used
> >    as a key to retrieve a NAPTR recored [RFC3404] from the 
> DNS, which 
> > in
> >    turn resolved into a SIP URI.  Call routing is based on this SIP 
> > URI.
> >    The call routing step does not depend on the presence of an E.164
> >    number; the SIP URI can be advertised in various other 
> ways, such 
> > as
> >    on a web page.  Finally, note that the subsequent lookup steps,
> >    namely, lookup of SRV, A, and AAAA records (as well as 
> any routing
> >    steps below that) are outside the scope of VOIPEER.
> > 
> > 
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 3]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >            E.164 number <--- Peer Discovery
> >                 |
> >                 | <--- ENUM lookup of NAPTR in DNS
> >                 |
> >                 |
> >                 | ENUM Working Group Scope
> >            =====+=======================================
> >                 | VOIPEER Working Group Scope
> >                 |
> >                 |
> >            SIP URI <--- Call Routing Data (CRD)
> >                 |
> >                 | <--- Service Location (Lookup of SRV in DNS)
> >                 |
> >                 |
> >            Hostname <--- VoIP addressing and session establishment
> >                 |
> >                 | <---- Lookup of A and AAAA in DNS
> >                 |
> >            Ip address
> >                 |
> >                 | <---- Routing protocols, ARP etc
> >                 |
> >            Mac-address
> > 
> >    Figure 1: VoIP Interconnect Context
> > 
> >    The ENUM Working Group is primarily concerned with the 
> acquisition 
> > of
> >    Call Routing Data, or CRD (i.e., above the double line in Figure 
> > 1),
> >    while the VOIPEER Working Group is focused on the use of 
> such CRD.
> >    Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS
> >    entry), or via any other mechanism available to the user.
> > 
> > 
> > 3.  General Definitions
> > 
> > 3.1.  Call Routing Data
> > 
> >    Call Routing Data, or CRD, is a SIP URI used to route a 
> call (real-
> >    time, voice or other type) to the called domain's 
> ingress point.  A
> >    domain's ingress point can be thought of as the location 
> pointed to
> >    by the SRV record that resulted from the resolution of the CRD 
> > (i.e.,
> >    a SIP URI).
> > 
> > 3.2.  Call Routing
> > 
> >    Call routing is the set of processes, rules, and CRD 
> used to route 
> > a
> >    VoIP call to its proper (SIP) destination.  More generally, call
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 4]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >    routing can be thought of as the set of processes, rules and CRD
> >    which are used to route a real-time session to its termination
> >    (ingress) point.
> > 
> > 3.3.  PSTN
> > 
> >    The term "PSTN" refers to the Public Switched Telephone 
> Network.  
> > In
> >    particular, the PSTN refers to the collection of interconnected
> >    circuit-switched voice-oriented public telephone networks, both
> >    commercial and government-owned.  In general, PSTN terminals are
> >    addressed using E.164 numbers, noting that various 
> dial-plans (such
> >    as emergency services dial-plans) may not directly use
> > E.164 numbers.
> > 
> > 3.4.  Network
> > 
> >    For purposes of this document and the VOIPEER and ENUM Working
> >    Groups, a network is defined to be the set of SIP 
> servers and end-
> >    users (customers) that are controlled by a single administrative
> >    domain.  The network may also contain end-users who are 
> located on
> >    the PSTN.
> > 
> > 3.5.  VoIP Service Provider
> > 
> >    A VoIP service provider is an entity that provides 
> transport of SIP
> >    signaling (and possibly media streams) to its customers.  Such a
> >    service provider may additionally be interconnected with other
> >    service providers; that is, it may "peer" with other service
> >    providers.  A VoIP service provider may also 
> interconnect with the
> >    PSTN.
> > 
> >    Note that as soon as a ingress point is advertised via a SRV 
> > record,
> >    anyone can find that ingress point and hence can send 
> calls there.
> >    This is very similar to sending mail to a SMTP server 
> based on the
> >    existence of a MX record.
> > 
> > 3.6.  Carrier
> > 
> >    A carrier is defined to be a service provider authorized to 
> > provision
> >    PSTN services.  Note that the provision of such services 
> is usually
> >    coupled with the authority to issue E.164 numbers [ITU.E164.1991]
> >    under the authority of a National Regulatory Authority (NRA).
> > 
> > 3.7.  Peering
> > 
> >    While the precise definition of the term "peering" is 
> the subject 
> > of
> >    some debate, peering in general refers to the negotiation of
> >    reciprocal interconnection arrangements, settlement-free or
> >    otherwise, between operationally independent service providers.
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 5]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >    This document distinguishes two types of peering, Layer 
> 3 Peering 
> > and
> >    Layer 5 peering, which are described below.
> > 
> > 3.7.1.  Layer 3 Peering
> > 
> >    Layer 3 peering refers to interconnection of two service 
> providers
> >    for the purposes of exchanging IP packets which destined for one 
> > (or
> >    both) of the peer's networks.  Layer 3 peering is generally 
> > agnostic
> >    to the IP payload, and is frequently achieved using a routing
> >    protocol such as BGP [RFC1771] to exchange the required routing
> >    information.
> > 
> >    An alternate, perhaps more operational definition of layer
> > 3 peering
> >    is that two peers exchange their customer routers 
> (only), and hence
> >    any traffic between peers terminates on on the peer's network.
> > 
> > 3.7.2.  Layer 5 Peering
> > 
> >    Layer 5 peering refers to interconnection of two service 
> providers
> >    for the purposes of SIP signaling.  Note that in the layer
> > 5 peering
> >    case, there is no intervening network.  That is, for purposes of 
> > this
> >    discussion, there is no such thing as a "Layer 5 Transit 
> Network".
> > 
> > 3.8.  VoIP Peering
> > 
> >    VoIP peering is defined to be a layer 5 peering between two VoIP
> >    providers for purposes of routing real-time (or quasi-real
> > time) call
> >    signaling between their respective customers.  Media streams
> >    associated with this signaling (if any) are not constrained to 
> > follow
> >    the same set of paths.
> > 
> > 
> > 4.  ENUM
> > 
> >    ENUM [RFC3761] defines how the Domain Name System (DNS) 
> can be used
> >    for identifying available services connected to one E.164 number.
> > 
> > 4.1.  Carrier of Record
> > 
> >    For purposes of this document, "Carrier of Record", or 
> COR, refers 
> > to
> >    the entity that provides PSTN service for an E.164 number
> > [I-D.lind-
> >    infrastructure-enum-reqs].  The exact definition of who 
> and what is 
> > a
> >    COR is ultimately the responsibility of the relevant NRA.
> > 
> > 4.2.  Public ENUM
> > 
> >    Public ENUM is generally defined as the set 
> administrative policies
> >    and procedures surrounding the use of the e164.arpa domain for
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 6]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >    Telephone Number to URI resolution [RFC3761].  Policies and
> >    procedures for the registration of telephone numbers within all
> >    branches of the e164.arpa tree are Nation State issues 
> by agreement
> >    with the IAB and ITU.  National Regulatory Authorities have 
> > generally
> >    defined Public ENUM Registrants as the E.164 number holder as 
> > opposed
> >    to the COR that issued the phone number.
> > 
> > 4.3.  Private ENUM
> > 
> >    Private ENUM is generally regarded as one or more technologies
> >    (including DNS and SIP Redirect) that service providers or
> >    enterprises may use to exchange phone number to URI mappings in a
> >    private secure manner.  Private ENUM may be used in any mutually
> >    agreed upon domain.  Records in Private ENUM may be globally 
> > visible
> >    but in most cases are not visible to the global Internet and are
> >    protected using a variety of security technologies such as 
> > split-DNS,
> >    VPN's or various forms or authentication and authorization.
> >    Technical comments on issues surrounding split-DNS can 
> be found in
> >    [RFC2826].
> > 
> > 4.4.  Carrier ENUM
> > 
> >    Carrier ENUM is generally regarded as the use of a 
> separate branch
> >    the e164.arpa tree, such as 4.4.c.e164.arpa to permit service
> >    providers to exchange phone number to URI data in order to find
> >    points of interconnection.  The current theory of Carrier ENUM is
> >    that only the COR for a particular E.164 number is permitted to
> >    provision data for that E.164 within that portion of the 
> e164.arpa
> >    tree.
> > 
> >    In carrier ENUM case, only the COR may enter data in the
> >    corresponding domain.  The COR may also enter CRD (i.e., 
> a SIP URI)
> >    to allow other VoIP Service Providers to route calls to its 
> > network.
> > 
> >    Finally, note that ENUM is not constrained to carry only 
> data (CDR)
> >    as defined by VOIPEER.  In particular, an an important class of 
> > CRD,
> >    the tel URIs [RFC3966] may be carried in ENUM.  Such tel URIs are
> >    most frequently used to interconnect with the PSTN directly, and 
> > are
> >    out of scope for VOIPEER.  On the other hand, PSTN 
> endpoints served
> >    by a COR and reachable via CDR and networks as defined 
> in Section 
> > 3.1
> >    and Section 3.4 are in scope for VOIPEER.
> > 
> > 
> > 5.  Conclusions
> > 
> > 
> > 6.  Acknowledgments
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 7]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >    Many of the definitions were gleaned from detailed 
> discussions on 
> > the
> >    VOIPEER, ENUM, and SIPPING mailing lists.  Scott Brim, 
> Mike Hammer,
> >    Jean-Francois Mule, Richard Shocky, and Richard Stastny made 
> > valuable
> >    contributions to early revisions of this document.  Patrik 
> > Faltstrom
> >    also made many insightful comments to early versions of 
> this draft,
> >    and contributed the basis of Figure 1.
> > 
> > 
> > 7.  Security Considerations
> > 
> >    This document itself introduces no new security considerations.
> >    However, it is important to note that VoIP interconnect 
> has a wide
> >    variety of security issues that should be considered in documents
> >    addressing both protocol and use case analyzes.
> > 
> > 
> > 8.  IANA Considerations
> > 
> >    This document creates no new requirements on IANA namespaces
> >    [RFC2434].
> > 
> > 
> > 9.  References
> > 
> > 9.1.  Normative References
> > 
> >    [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System 
> > (DDDS)
> >               Part Four: The Uniform Resource Identifiers (URI)",
> >               RFC 3404, October 2002.
> > 
> >    [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
> >               Resource Identifiers (URI) Dynamic Delegation 
> Discovery
> >               System (DDDS) Application (ENUM)", RFC 3761, 
> April 2004.
> > 
> >    [ITU.E164.1991]
> >               International Telecommunications Union, "The 
> > International
> >               Public Telecommunication Numbering Plan", ITU-
> >               T Recommendation E.164, 1991.
> > 
> >    [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
> >               RFC 3966, December 2004.
> > 
> > 9.2.  Informative References
> > 
> >    [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
> >               (BGP-4)", RFC 1771, March 1995.
> > 
> >    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for 
> Writing an
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 8]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> >               IANA Considerations Section in RFCs", BCP 26, 
> RFC 2434,
> >               October 1998.
> > 
> >    [RFC2826]  Internet Architecture Board, "IAB Technical 
> Comment on 
> > the
> >               Unique DNS Root", RFC 2826, May 2000.
> > 
> >    [I-D.lind-infrastructure-enum-reqs]
> >               Lind, S., "Infrastructure ENUM Requirements",
> >               draft-lind-infrastructure-enum-reqs-00 (work in 
> > progress),
> >               July 2005.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >   [Page 9]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> > Author's Address
> > 
> >    David Meyer
> > 
> >    Email: [email-masked]
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >  [Page 10]
> > 
> > 
> > Internet-Draft   Terminology for Describing VoIP Peering    
> > October 2005
> > 
> > 
> > Intellectual Property Statement
> > 
> >    The IETF takes no position regarding the validity or scope of any
> >    Intellectual Property Rights or other rights that might 
> be claimed 
> > to
> >    pertain to the implementation or use of the technology 
> described in
> >    this document or the extent to which any license under 
> such rights
> >    might or might not be available; nor does it represent 
> that it has
> >    made any independent effort to identify any such rights.  
> > Information
> >    on the procedures with respect to rights in RFC documents can be
> >    found in BCP 78 and BCP 79.
> > 
> >    Copies of IPR disclosures made to the IETF Secretariat and any
> >    assurances of licenses to be made available, or the result of an
> >    attempt made to obtain a general license or permission 
> for the use 
> > of
> >    such proprietary rights by implementers or users of this
> >    specification can be obtained from the IETF on-line IPR 
> repository 
> > at
> >    http://www.ietf.org/ipr.
> > 
> >    The IETF invites any interested party to bring to its 
> attention any
> >    copyrights, patents or patent applications, or other proprietary
> >    rights that may cover technology that may be required to 
> implement
> >    this standard.  Please address the information to the IETF at
> >    [email-masked].
> > 
> > 
> > Disclaimer of Validity
> > 
> >    This document and the information contained herein are 
> provided on 
> > an
> >    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
> > REPRESENTS
> >    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
> THE INTERNET
> >    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
> OR IMPLIED,
> >    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
> >    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> >    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
> PARTICULAR PURPOSE.
> > 
> > 
> > Copyright Statement
> > 
> >    Copyright (C) The Internet Society (2005).  This document is 
> > subject
> >    to the rights, licenses and restrictions contained in BCP 78, and
> >    except as set forth therein, the authors retain all their rights.
> > 
> > 
> > Acknowledgment
> > 
> >    Funding for the RFC Editor function is currently provided by the
> >    Internet Society.
> > 
> > 
> > 
> > 
> > Meyer                    Expires April 24, 2006               
> >  [Page 11]
> > 
> > 
> > 
> 
> ______________________________________________________________
> ______________
> _
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> 

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

---

From: David Meyer <[email-masked]>
Date: Fri, 21 Oct 2005 13:36:31 -0700

On Fri, Oct 21, 2005 at 02:49:36PM -0500, Henry Sinnreich wrote:
> > There are no carriers in Skype, correct?
> 
> Skype is reselling E.164 phone numbers in an increasing number of countries.
> 
> It makes sense therefore to _test the definitions_ here on the Skype case
> and there are other VoIP and IM services in similar situation. Some are
> really far too big to be overlooked.
> 
> Unless the definition is refined in terms of facilities based and non
> facilities based. But there are VMNO's in the wireless world...
> 
> Hint: The carrier definition is hopeless. "The Internet Is The Service" (Jon
> Peterson) and voice is an application IMHO. Let's go back to the layers in
> the I-D.

	Yep. There's no real value add in defining carrier
	IMO. Best solution: remove the definition of carrier. 

	Dave

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 21 Oct 2005 14:49:36 -0500

Thanks, Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Hammer
(mhammer)
Sent: Friday, October 21, 2005 2:04 PM
To: [email-masked]; David Meyer; Pfautz, Penn L, NEO
Cc: [email-masked]; [email-masked]
Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt

Mike 

> > Meyer                    Expires April 24, 2006               

____________________________________________________________________________
_
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html