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

From: "Stastny Richard" <[email-masked]>
Date: Mon, 24 Oct 2005 10:37:44 +0200

Correct,

That is what I was trying to get at in a previous post:

Voipeer is dealing with routing between VoIP service providers using
SIP URIs. So the definition of a VoIP Service provider is needed
to be clear about is role in voipeer. Skype is a VoIP service provider
if Skype is peering with other via SIP. Currently it is not.

This means that E.164 numbers are out of scope in voipeer. They
are in scope in enum WG. Within scope of enum WG is the mapping from
E.164 numbers to SIP URIs.

This separation is now clearly stated in
draft-meyer-voipeer-terminology-03

Since the definition of a carrier and especially a Carrier-of-Record
(see draft-lind-infrastucture-enmum-reqs-01) is tightly linked
to E.164 numbers and PSTN connectivity), it is out of scope in voipeer.

Cheers
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> James McEachern
> Sent: Monday, October 24, 2005 9:10 AM
> To: Pfautz, Penn L, NEO; David Meyer
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Enum] RE: [voipeer]
draft-meyer-voipeer-terminology-03.txt
> 
> The discussion about the definition of a carrier makes me wonder what
is
> the important aspect of being a carrier (or not) that we are trying to
get
> at here.
> 
> Usually, when we develop a technical (or legal/regulatory) definition
for
> a term (say "foo") it is because some action will be required, or
> precluded, based on whether or not an entity satisfies the definition
of
> "foo".  Because of this, the definition of "foo" is often tuned to
ensure
> we achieve the desired discrimination between entities that are a
member
> of "foo" and those that are not.
> 
> Unfortunately, in this context, I do not understand what subsequent
> decision will depend on whether or not an entity qualifies as a
carrier.
> (If no subsequent decisions depend on being a carrier, then any
definition
> will do.)
> 
> Can anyone explain what will be allowed, or precluded if an entity is
> deemed to be a carrier by this group?  Once we all agree on that, the
> correct definition may be clearer.
> 
> Concerning Henry's comment about Skype, as I read the definitions, it
> would appear that Skype may well be a carrier - at least for Skype
In/Out.
> I also suspect Skype could be the carrier of record for Skype In
numbers.
> Interestingly, I believe the current definitions suggest that Skype is
> *not* a VoIP Service provider, since (as I understand) it does not
> generally use SIP for its service (or application).  This does seem
> somewhat counter intuitive.
> 
> Jim
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Pfautz, Penn L, NEO
> Sent: Friday, October 21, 2005 11:16 AM
> To: David Meyer
> Cc: [email-masked]; [email-masked]
> Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt
> 
> OK with just a couple typos below
> 
> Penn
> 
> -----Original Message-----
> From: David Meyer [mailto:[email-masked]]
> 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 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 router (only), and hence
>                                                    ^
>    any traffic between peers terminates on one of 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]
> 
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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