Network Working Group                                      K. Cartwright
Internet-Draft                                                  VeriSign
Intended status: Standards Track                                S. Dimig
Expires: August 28, 2008                                         Tekelec
                                                              M. Teodoro
                                                                 NeuStar
                                                               J-F. Mule
                                                               CableLabs
                                                       February 25, 2008


        A Provisioning Protocol for ENUM-SIP Addressing Servers
                 draft-mule-peppermint-espp-protocol-01

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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).









Cartwright, et al.       Expires August 28, 2008                [Page 1]


Internet-Draft                ESPP Protocol                February 2008


Abstract

   This document defines a provisioning protocol for ENUM-SIP addressing
   servers.  This protocol has been recently published as part of
   CableLabs(r) PacketCable(tm) specifications.  It allows SIP service
   providers to provision and manage session establishment data used by
   SIP network elements to route SIP sessions to the target destinations
   which may be served by the SIP service provider's own internal
   network or by a session peering partner.  The data provisioned into
   an ENUM-SIP addressing server is queried by SIP entities using ENUM
   or SIP.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   5
   4.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Logical Structure - Data Model  . . . . . . . . . . . . .   9
     4.2.  Technical Structure - SOAP/XML Type Hierarchy . . . . . .  14
     4.3.  Overview of Protocol Operations . . . . . . . . . . . . .  15
       4.3.1.  Deployment Scenario and ESPP Provisioning . . . . . .  15
       4.3.2.  Deployment Scenario and Resolution  . . . . . . . . .  32
       4.3.3.  Generic Examples  . . . . . . . . . . . . . . . . . .  34
     4.4.  Protocol Specification  . . . . . . . . . . . . . . . . .  34
       4.4.1.  General Protocol Concepts . . . . . . . . . . . . . .  35
       4.4.2.  Protocol Operation Descriptions . . . . . . . . . . .  40
   5.  File-based ESPP provisioning protocol . . . . . . . . . . . .  82
     5.1.  Overview of the File-based Provisioning Operations  . . .  82
     5.2.  File Structure  . . . . . . . . . . . . . . . . . . . . .  82
   6.  Response Codes and Messages . . . . . . . . . . . . . . . . .  85
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  87
   8.  Formal API Definition . . . . . . . . . . . . . . . . . . . .  88
     8.1.  WSDL Specification  . . . . . . . . . . . . . . . . . . .  88
     8.2.  XSD Types Specification . . . . . . . . . . . . . . . . .  99
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 112
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 113
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 114
     11.1. Normative References  . . . . . . . . . . . . . . . . . . 114
     11.2. Informative References  . . . . . . . . . . . . . . . . . 114
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 116
   Intellectual Property and Copyright Statements  . . . . . . . . . 117








Cartwright, et al.       Expires August 28, 2008                [Page 2]


Internet-Draft                ESPP Protocol                February 2008


1.  Introduction

   This document defines a provisioning protocol for ENUM-SIP addressing
   servers.  It allows SIP service providers to provision data that is
   used by ENUM-SIP addressing servers to return part of the session
   establishment data to SIP network elements so that they can route SIP
   sessions to the target destinations.

   An ENUM-SIP addressing server is a session routing server which
   resolves telephone numbers or any type of public user addresses into
   routable Uniform Resource Identifiers (URIs) based on various rules
   and routing logic.  The data provisioned into an ENUM-SIP addressing
   server is queried by SIP entities using ENUM [RFC3761] or Session
   Establishment Protocol (SIP) [RFC3261].  It is intended to provide
   the necessary information for a querying SIP entity to route a call
   to the target destination.

   The use cases and protocol requirements for the ENUM-SIP Server
   Provisioning Protocol (ESPP) are described in
   [I-D.espp-requirements].  For reference, this protocol is also
   published as a CableLabs specification, the PacketCable ENUM Server
   Provisioning Specification ([CableLabs-ESPP]).  A number of vendors
   have client and server implementations of this protocol and two
   interoperability testing events have been conducted to date.

   This document is organized as follows:

   o    Section 3 describes the protocol's functional entities and
        provides a pointer to the use cases and protocol requirements
        maintained in a separate document,

   o    Section 4 and Section 5 define the real-time and filed-based
        operations of the ESPP provisioning protocol including the data
        model (Section 4.1), the SOAP/XML Type Hierarchy (Section 4.2),
        and an overview of the protocol operations by walking through a
        real-life deployment scenario showing examples of ESPP
        operations and how the provisioned data can be used to resolve
        ENUM or SIP queries,(Section 4.3),

   o    Section 8 provides the complete normative WSDL and XSD
        definitions of the protocol.










Cartwright, et al.       Expires August 28, 2008                [Page 3]


Internet-Draft                ESPP Protocol                February 2008


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document also reuses the SIP terminology defined in [RFC3261]
   and [I-D.ietf-speermint-terminology].











































Cartwright, et al.       Expires August 28, 2008                [Page 4]


Internet-Draft                ESPP Protocol                February 2008


3.  Protocol Requirements

   The ENUM Server Provisioning Protocol (ESPP) allows a SIP Service
   Provider (SSP) to receive session establishment-related data from
   various sources: its internal back-office systems for intra-domain
   routes, a session peer or a federation registry.  A source of
   provisioning data is logically represented by an ESPP provisioning
   client (ESPP Client).  The SIP Service Provider's addressing server
   receives this provisioning data via a functional entity called an
   ESPP Server.

   The data sent by an ESPP Client to an ESPP Server follows a formal
   data structure based on the data model (Section 4.1) and includes
   parameters such as a peer's telephone numbers grouped by service area
   and the Signaling path Border Elements to reach those telephone
   numbers.

   This specification defines the protocol interfaces between a
   provisioning client (ESPP Client) and a provisioning server function
   of an ENUM-SIP addressing server (ESPP Server), as shown on Figure 1.































Cartwright, et al.       Expires August 28, 2008                [Page 5]


Internet-Draft                ESPP Protocol                February 2008


   SIP SSP      +-------------+
   Intra-Domain |             |
   Network      | Back Office |
        |       |   Server    |
        +-------|+-----------+|-+
                ||ESPP Client|| |
                |+-----------+| |
                +-------------+ |
                                |      +-------------+
    Peer        +-------------+ |      |  ENUM-SIP   |
    Bi-lateral  |             | |      | Addressing  |
    Agreement   | Resolution  | |      |   Server    |
        |       |   Server    | |      |             |
        +-------|+-----------+| | ESPP |+-----------+|
                ||ESPP Client|+-+------+|ESPP Server||
                |+-----------+| |      |+-----------+|
                +-------------+ |      |+-----------+|
                                |      ||   Data    ||
    Peer        +-------------+ |      ||Repository ||
    Federation  | Other Data  | |      |+-----------+|
    Network     |   Sources   | |      |+-----------+|  *  +-----------+
        |       |+-----------+|-+      || ENUM-SIP  |+-----+ SIP Entity|
        +-------||ESPP Client||        |+-----------+|     +-----------+
                |+-----------+|        +-------------+
                +-------------+


         ENUM Server Provisioning Protocol Reference Architecture

                                 Figure 1

   To claim compliance with this specification, an ESPP Client and an
   ESPP Server MUST conform to the real-time and file-based provisioning
   protocol requirements defined in Section 4, Section 5 and Section 8
   of this document.  The protocols used by SIP entities and various
   network elements to query the addressing server are typically ENUM or
   SIP; they are out of scope of this specification and are denoted with
   an asterisk (*) in Figure 1.

   The guiding design principal behind ESPP is the ability to support a
   large session addressing space whose size is of the same order of
   magnitude as the Public Switched Telephone Network (PSTN).
   Optimizing bandwidth and storage usage is a key characteristic.

   The logical data structure implemented by ESPP allows for a more
   natural modeling of relationships between the entities that comprise
   the logical topology.  Telephone numbers and other types of public
   user identities are grouped in logical or geographical areas and



Cartwright, et al.       Expires August 28, 2008                [Page 6]


Internet-Draft                ESPP Protocol                February 2008


   associated with routes that describe how traffic traverses the nodes
   of the topology.  The process begins by arranging a plurality of
   telephone numbers and nodes connected by a plurality of routes.  Each
   telephone number, number range or public user identity is assigned to
   a service area.  Through a route assignment each node is associated
   with one or more service areas.  For example, a SIP Service Provider
   could first create service areas for the New York metropolitan area,
   assigning the telephone numbers of New York subscribers into that
   service area.  The SIP Service Provider then defines the call servers
   that provide digital voice services for New Yorkers and the border
   elements that connect the New York metropolitan area to peering
   networks.  Finally, through the definition of intra-SSP and inter-SSP
   routes, that SIP Service Provider completes the establishment of
   session peering data by associating nodes with service areas.

      Figure 2 illustrates the link between logical service areas and
               telephone numbers and the associated routes.

    Service Areas:
   +------------------------------------+
   |Service Area Name| TN or TN Ranges  |
   +-----------------+------------------+
   |Manhattan        |212-203-0000 ->   |
   |                 |212-203-9999      |                   ,---.
   |Bronx            |347-876-1000 ->   |                  /     \
   |                 |347-876-1999      |                 /       \
   |Queens           |347-354-6000 ->   |                (  Bronx  )
   |                 |347-354-6999      |                 \       /
   +------------------------------------+          ,-----. \     /
       Routes:                                    /       \ `---'
       +------------------------------------+    /         \
       |Route Name|Nodes    |Service Areas  |   ( Manhattan )   ,---.
       +----------+---------+---------------+    ,-.       /   /     \
       |118th Ave |NYC-SBE-1|Manhattan/Bronx|-->(SBE)     /   /       \
       |60 Hudson |NYC-SBE-2|Queens         |-+  `-'-----'   ( Queens  )
       +----------+--------++---------------+ |              ,+.      /
                                              +------------>(SBE)    /
           Nodes:                                            `-''---'
           +-------------------------------+
           |Node Name|   Host/Domain Name  |
           +---------+---------------------+
           |NYC-SBE-1|sbe-1.nyc.example.com|
           |NYC-SBE-2|sbe-2.nyc.example.com|
           +---------+---------------------+

                 Example of ESPP Service Areas and Routes

                                 Figure 2



Cartwright, et al.       Expires August 28, 2008                [Page 7]


Internet-Draft                ESPP Protocol                February 2008


   A number of design considerations and requirements (transport, data
   model, security, etc.) can be found in [I-D.espp-requirements].

















































Cartwright, et al.       Expires August 28, 2008                [Page 8]


Internet-Draft                ESPP Protocol                February 2008


4.  Protocol Definition

   This section first introduces the structure of the data model and the
   overall technical structure that provide the information framework to
   which ESPP adheres.  An overview of the protocol operations is then
   provided with a typical deployment scenario.  This section concludes
   with the definition of the operations and data elements that comprise
   ESPP.

4.1.  Logical Structure - Data Model

   The data model illustrated and described in Figure 3 defines the
   logical objects and the relationships between these objects that the
   ESPP protocol supports.  ESPP defines the protocol operations through
   which an ESPP Client populates an ENUM-SIP addressing server with
   these logical objects.  The protocol may be used by various clients
   for populating the server.  ESPP Clients may include, for example, a
   back-office system, a federation registry or another ENUM-SIP
   addressing server.

   A key requirement of ESPP is the ability to support an addressing
   space of the same magnitude as the PSTN.  To achieve the above, the
   data model needs to be designed such that it optimizes bandwidth and
   storage.  The data model needs to support distribution of addressing
   information in a manner that affords the implementations the
   opportunity to maximize storage and minimize transport overhead.  One
   way to achieve this is not relying exclusively on distribution of
   redundant NAPTR records.  The use of a direct association between
   NAPTRs and telephone numbers should be restricted to service
   scenarios where there is a need to communicate subscriber-specific
   service attributes.  This is because the NAPTRs carry a large amount
   of redundant data when many telephone numbers resolve into a URI
   where the host part is the same Internet address.

   As illustrated in the figure below, the logical structure that
   underlies ESPP is designed around a simplified version of the logical
   entities that comprise session peering data.  This logical structure
   provides a consistent terminology and design to the constructs that
   make up the protocol.












Cartwright, et al.       Expires August 28, 2008                [Page 9]


Internet-Draft                ESPP Protocol                February 2008


                                                      +----------------+
                           A Route is associated with |NAPTR:          |
        +----------------+ zero or more SBE NAPTRs.   |id,enterpriseId,|
        |                |--------------------------->|order,pref,     |
        |Route:          | NAPTRs associated with     |flags,svcs,regx,|
        |id,enterpriseId,| Routes are not User or TN  |repl,extension  |
        |routeName,      | specific. The user portion +----------------+
        |isLnService,    | of the regex will be "\\1".
        |sbeNAPTRs,      |                            +----------------+
        |extension       |                            |Egress Route:   |
        |                |<---------------------------|id,enterpriseId,|
        +----------------+ An EgressRoute is          |routeIds,pref,  |
                        ^  associated with zero or    |svcs,           |
         A Service Area |  more Routes.               |regxRewriteRule,|
         is associated  |                             |extension       |
         with 1 or more |                             +----------------+
         Routes         |
                    +----------------+
                    |Service Area:   |
                    |id,enterpriseId,|
               +--->|ServiceAreaName,|<---+
               |    |routeIds,       |    |
               |    |extension       |    |
               |    +----------------+    |
               |An LRN is   |A TNRange is |A Public
               |associated  |associated   |Identify is
               |with only 1 |with only 1  |associated
               |Service     |Service      |with zero or
               |Area.       |Area.        |1 Service Area.
               |            |             |
   +--------------++--------------++--------------+   +--------------+
   |LRN:          ||TNRange:      ||Public        |   |NAPTR:        |
   |id,           ||id,           ||Identity:     |   |id,           |
   |enterpriseId, ||enterpriseId, ||id,           |   |enterpriseId, |
   |lrn,          ||tnRangeStart, ||enterpriseId, |-->|order,pref,   |
   |serviceAreaId,||tnRangeEnd,   ||lrn,          |   |flags,svcs,   |
   |extension     ||serviceAreaId,||serviceAreaId,|   |regx,repl,    |
   |              ||extension     ||extension     |   |extension     |
   +--------------++--------------++--------------+   +--------------+
                                              |
                           A Public Identity  | Multiple Public
                           is associated with | Identities can
                           zero or 1 Private  | be associated
                           Identity           | with 1 Private
                                              | Identity
                                              |
                                              |
                                              |



Cartwright, et al.       Expires August 28, 2008               [Page 10]


Internet-Draft                ESPP Protocol                February 2008


                                              |
                                              |
                                              V
                                      +----------------+
                                      |Private         |
                                      |Identity:       |
                                      |id,             |
                                      |enterpriseId,   |
                                      |privateIdentity,|
                                      |extension       |
                                      +----------------+

                     Logical Structure of ESPP Objects

                                 Figure 3

   The objects that comprise the logical domain model can be described
   as follows:

      Public Identity (PubId):
      A string of numbers or characters that serves as a public
      identity.  A Public Identity may be a telephone number, an email
      address, or other identity as deemed appropriate.  The Public
      Identity object may be associated with a Service Area which serves
      as a logical grouping of public identities and indirectly defines
      the signaling path used to Route to that Public Identity.  A
      Public Identity may optionally be associated with zero or more
      individual NAPTRs.  This ability for a Public Identity to be
      directly associated with a set of NAPTRs, as opposed to being
      associated with a Service Area, supports the use cases where the
      NAPTR may contain data specifically tailored to an individual
      Public Identity.  A Public Identity may, optionally, be associated
      with zero or one Private Identity.

      Private Identity (PvtId):
      A string of numbers or characters that serves to associate, or
      group together, a set of related Public Identities.  A Private
      Identity may, for example, represent a user who has more than one
      Public Identity instances.  When a resolution request for a public
      identity arrives at an addressing server, the addressing server
      may locate the Public Identity that matches the queried public
      identity, discover the Private Identityassociated with that Public
      Identity, and then gather and return all the NAPTRs directly or
      indirectly (via a Service Area) associated with the Public
      Identities that are associated with that Private Identity.






Cartwright, et al.       Expires August 28, 2008               [Page 11]


Internet-Draft                ESPP Protocol                February 2008


      Route:
      A set of related Signaling path Border Elements (SBEs).  SBEs are
      generally ingress or egress points within, or at the edge of, a
      SIP service provider's network.  A Route object is associated with
      zero or more SBEs.  An SBE's properties are housed within the
      constructs of a NAPTR object modeled after a DNS NAPTR Record.  At
      runtime (i.e., during the resolution of a SIP or ENUM query to an
      addressing server), the SBEs associated with the route to the
      Service Area of a public identity will be returned as part of the
      NAPTR response.  In case of multiple SBEs, the ENUM response will
      have multiple NAPTR records, each referring to a particular SBE.
      This indirection between a Public Identity and its ENUM NAPTRs
      allows the modification of signaling path border elements without
      having to modify a large number of NAPTRs.

      Egress Route:
      Optional rules for re-writing (modifying) the regular expressions
      housed in the NAPTRs associated with a Route.  This is primarily
      used by the addressing server to dynamically add a SIP Route
      header as part of a SIP resolution, and to dynamically indicate
      into a NAPTR's regular expression what SIP Route to use.  This
      allows a NAPTR to define the local egress SBE or the remote
      ingress SBE of a signaling path.

      Service Area:
      A collection of zero or more Public Identities, Telephone Number
      ranges (TNRanges), and Location Routing Numbers (LRNs) that are
      related by virtue of their common signaling path and a set of zero
      or more Route relationships.  The grouping of Public Identities,
      TNRanges, and LRNs into related groups and the indirect
      association of these groups to their signaling path elements
      significantly enhances the manageability of routing data for a
      large number of Public Identities.  This allows the addressing
      server to apply routing changes to a set of Public Identities,
      TNRanges, and LRNs without having to make changes to each
      individual Public Identities, TNRange, or LRN.

      Location Routing Number (LRN):
      A 10-digit number that identifies the switching port for a local
      telephone exchange.  LRN is used to support Local Number
      Portability in North America.  An LRN is associated with a Service
      Area.

      TNRange:
      An object that represents a range of telephone numbers.  The
      TNRange object must be associated with a Service Area which
      indirectly defines the signaling path to reach the TNs in that
      range.



Cartwright, et al.       Expires August 28, 2008               [Page 12]


Internet-Draft                ESPP Protocol                February 2008


      Enterprise ID:
      The enterprise ID data element that resides within each object
      type and uniquely identifies an operational entity within an ESPP
      Server.  The operational entity is responsible for, or owns, that
      object from a business perspective.  This does not identify the
      software entity that provisioned the object, which is the purpose
      of the client ID.  The globally unique name space for the
      assignment of an Enterprise ID is the open IANA Private Enterprise
      Number registry,
      <http://www.iana.org/assignments/enterprise-numbers>.

      ID:
      Each object is uniquely identifiable using its object ID.  An
      object ID is guaranteed to be unique within an ESPP Server and
      ESPP Client, regardless of the number of ESPP Clients populating
      objects into a given ESPP Server.ESPP Client MUST create and
      assign the Object IDs it provisions.  This approach has
      significant performance advantages.  The determination of a
      globally unique name space for object IDs and approach for the
      creation and assignment of object IDs is defined as follows.  The
      8 most significant digits of the object ID (which is a 64 bit
      unsigned long) MUST contain a client ID that is guaranteed to be
      globally unique within an ESPP Server.  This client ID MUST be
      right justified in this 8 digit field.  The remaining 12 digits of
      the object ID MUST contain an object ID that is guaranteed to be
      unique within the client identified by the client ID.  The
      globally unique client ID MUST be the combination of an enterprise
      ID value and a right justified 2 digit suffix that MUST be used to
      further uniquely identify an ESPP Client within that enterprise
      ID.  Note that a candidate space for the enterprise ID is the IANA
      Private Enterprise Number registry and we assume that the ID is
      between 1 and 6 digits in length in this version of this
      specification.  The 2 digit suffix is necessary in cases where
      more than one ESPP Client, within the same ESPP federation, are
      from the same organization and therefore would have the same the
      IANA Private Enterprise Number.  The 2 digit client ID suffix MUST
      be within the range of 00 and 99, inclusive.  As an example, a
      valid object ID would be 123401000012345678.  In this example,
      1234 is the enterprise ID, 01 is the enterprise ID suffix, and
      000012345678 is the object ID.  Notice that the two most
      significant digit fields are not used and are not necessary in
      this example.

      NAPTR:
      The data structure used to house the properties of signaling path
      border elements, and any other information appropriately held
      within the data structures offered by a NAPTR.




Cartwright, et al.       Expires August 28, 2008               [Page 13]


Internet-Draft                ESPP Protocol                February 2008


4.2.  Technical Structure - SOAP/XML Type Hierarchy

   In addition to employing the logical structure described in the
   previous section, ESPP also employs a consistent overall technical
   structure.  This technical structure is typically referred to as the
   "Document Literal Wrapped" style of designing SOAP based APIs.  This
   style is generally regarded as an optimal approach that enhances
   maintainability, comprehension, portability, and, to a certain
   extent, performance.  Figure 4 illustrates this high level technical
   structure.

                              +-----------+
                       +------|   SOAP    |------+
                       |      | Operation |      |
              Contains |      +-----------+      | Contains
                       |                         |
                       V                         V
                 +------------+           +-------------+
                 |SOAP Request|           |SOAP Response|
         Example:|   Message  |           |   Message   |Example:
   addRtesRqstMsg| (Operation |           | (Operation  |cmnRspnsMsg
                 |   Input)   |           |   Output)   |
                 +------------+           +-------------+
                       |                         |
              Contains |                         | Contains
                       |                         |
                       V                         V
                +--------------+         +---------------+
        Example:|   Wrapped    |         |    Wrapped    |Example:
     addRtesRqst|Request Object|         |Response Object|cmnRspns
                +--------------+         +---------------+
                       |                         |
                       |                         |
                       |                         |
                       V                         V
                +--------------+         +---------------+
        Example:|     ESPP     |         |      ESPP     |Example:
         RteType| Object Types |         |  Object Types |BasicRspnsType
                +--------------+         +---------------+

                 Technical Structure of the ESPP Protocol

                                 Figure 4

   The SOAP operations supported by ESPP (e.g., addRtes) are normatively
   defined in Section 8.  Each SOAP operation defines a request/input
   message and a response/output message.  Each request and response
   message then contains a single object that wraps the data elements



Cartwright, et al.       Expires August 28, 2008               [Page 14]


Internet-Draft                ESPP Protocol                February 2008


   that comprise the inputs and the outputs, respectively, of the
   operation.

   Section 4.4.2 of this document defines how each operation utilizes
   this technical structure and the logical structure defined in the
   previous section.

4.3.  Overview of Protocol Operations

   This section provides an overview of ESPP and its protocol operations
   by describing a usage scenario and examples.  It is divided into two
   sub-sections.  The first sub-section defines a usage scenario and
   provides a set of example ESPP request messages that apply to the
   scenario.  The second sub-section provides examples of a generic set
   of ESPP request/response pairs, one for each protocol operation.

4.3.1.  Deployment Scenario and ESPP Provisioning

   A typical deployment scenario for ESPP involves multiple SIP Service
   Providers wanting to exchange multimedia traffic including Voice over
   IP (VoIP) calls and Instant Messaging (IM) sessions.  Each service
   provider first advertises the public user identities (e.g., telephone
   numbers and instant messaging addresses) it serves on its network
   along with the routes to its peers.  Note that the process by which a
   SIP service provider exchanges data such as an instant messaging
   address may be subject to end-user privacy and a subscriber-triggered
   authorization step may be required.

   Various models can be chosen by SSPs to determine if a target address
   is served by a peer.  In one model, for each session initiation, an
   out-of-network query could be made to each peer individually, or to a
   federation entity representing the peers.  In another model, an SSP
   who has deployed ENUM-SIP addressing servers for session routing may
   prefer in-network queries to its addressing servers to resolve target
   addresses.  In this second case, the service provider's addressing
   server could be provisioned with peer data: this is the purpose of
   the ESPP protocol.  Both models can also co-exist: in some cases and
   depending on the SSP policy, the resolution of certain types of
   addresses may require an out-of-network query.

   The remaining of this section assumes that SSPs have deployed ENUM-
   SIP addressing servers and prefer in-network queries.  A deployment
   scenario is described in details covering both the provisioning
   activities using ESPP and the query resolutions to resolve target
   addresses using ENUM or SIP.  We first introduce the actors of the
   scenario (SIP Service Providers or enterprises participating in
   multimedia session exchanges), and then expand on the ESPP operations
   for the provisioning of peers, Session Establishment Data (SED), and



Cartwright, et al.       Expires August 28, 2008               [Page 15]


Internet-Draft                ESPP Protocol                February 2008


   the public identities or Address of Records to which session may be
   established.

4.3.1.1.  Actors

4.3.1.1.1.  Enterprises Description

   Three SIP service Providers have agreed to exchange Voice over IP
   traffic and Instant Messages via their IP networks:

   o    GlobalSSP:

   GlobalSSP is a large SIP service provider with service footprints in
   Boston and Arizona and several SIP servers capable of processing VoIP
   traffic.  The SIP servers are logically linked to several Signaling
   path Border Elements (SBEs) that hide the topology of the SIP service
   provider's network while providing specific access points for other
   peers.  GlobalSSP does also control its egress routes by choosing the
   SBE that egress calls to a particular peer.

   Each Call Management Server (CMS) is also associated with one or more
   Location Routing Number(s) (LRN) due to local number portability
   support.  The telephone numbers served by GlobalSSP are distributed
   among the CMS servers as well as the PSTN switches.

   o  MidwestSSP:

   MidwestSSP operates a network similar to GlobalSSP with services in
   the Chicago area (subscriber base only located in one state).  Two
   Call Management Servers and only one SBE are deployed.

   o  NewYorkSSP:

   NewYorkSSP offers services in the region of New York City including
   voice and IM.  Four SBEs have been deployed for voice, one SBE for
   IM.  IM subscribers are known by a public identity.



   SIP service providers take advantage of ESPP to provision session
   establishment data.  They agreed to use a common Registry function
   with a Registrar component that implements the client-side of the
   ESPP protocol.  Note that ESPP also supports a deployment model where
   each SIP service provider has bilateral relationships with a number
   of peers and use ESPP directly with each peer.

   Each SIP service provider is connected to the Registrar and
   implements an instance of the ENUM SIP addressing server (ESPP



Cartwright, et al.       Expires August 28, 2008               [Page 16]


Internet-Draft                ESPP Protocol                February 2008


   Server) for the server-side of the protocol.  Note that GlobalSSP is
   connected to the Registrar from one of their Service Area that
   distributes data to the Boston Service Area.

   Each SIP service provider is allocated an identifier or Enterprise
   ID:

               +---------------+---------------------------+
               | SSP           | Enterprise ID             |
               +---------------+---------------------------+
               | GlobalSSP     | 76543                     |
               |               |                           |
               | NewYorkSSP    | 76544                     |
               |               |                           |
               | MidwestSSP    | 76545                     |
               +---------------+---------------------------+

                  Table 1: Example SSP and Enterprise ID

   After these three SSPs have successfully exchanged session
   establishment data (SED) for some time, a new SSP called NewSSP wants
   to exchange calls and IM with the other three.  To facilitate the
   process of getting the data from all three SIP service providers in a
   limited amount of time, the NewSSP server will receive a complete
   copy of the data the SSPs wish to share with NewSSP using a bulk
   file.

               +---------------+---------------------------+
               | SSP           | Enterprise ID             |
               +---------------+---------------------------+
               | NewSSP        | 76546                     |
               +---------------+---------------------------+

                 Table 2: Example NewSSP and Enterprise ID

   In this scenario, each SIP Service Provider operates an ESPP Server
   that houses the ESPP Server's SED and end point data from an ESPP
   Client (a Registrar or a Registry).  The ESPP Client initiates
   connections and, using the supported ESPP operations, pushes data
   down to the ESPP Servers.  SED and end point objects are stored in
   the ESPP Server.

   Each ESPP Server receives the data its SSP is allowed to access and
   each addressing server has a "unique" view of its peer's data.  Note
   that a SIP Service Provider may also choose to store internal or
   private routes using ESPP.  For example, the data for routing
   sessions out of the SSP's network is different from the data used to
   route sessions within the SPP's own Service Areas.



Cartwright, et al.       Expires August 28, 2008               [Page 17]


Internet-Draft                ESPP Protocol                February 2008


4.3.1.1.2.  Enterprises: ESPP Provisioning Operations

   As these partner relationships are established, each SSP sends SED
   data to its peers via the ESPP Client(s).  In order to identify the
   peer the SED data belong to, an Enterprise ID is provided along with
   the list of Service Areas, SBEs, etc.

   ESPP is an XML SOAP protocol.  An ESPP Client uses the ESPP
   protocol's addEntr operation to create these enterprises in the ESPP
   Server for each participating SSP.  To do so, it sends a request to
   create three enterprise identifiers (eId) at an ESPP Server.  This
   operation is sent to the ESPP Server operated by the three SIP
   Service Providers, MidwestSSP, GlobalSSP, and NewYorkSSP.

   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <addEntrRqst>
       <basicRqst>
        <clientId>7845601</transId>
        <transId>1000000</transId>
        <minorVer>1</minorVer>
       </basicRqst>
       <eId>76543</eId>
       <eId>76544</eId>
       <eId>76545</eId>
      </addEntrRqst>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>


                                 Figure 5

   For brevity and to improve the readability of examples, the basicRqst
   element of the SOAP message will be omitted from the remaining
   examples.  With the exception of the transId element incrementing
   upward, the content of the basicRqst element is identical for all
   examples in this section.

   The enterprise ID for NewSSP is added later.  At that time, the
   central registry via its ESPP Client uses the addEntr operation to
   add the NewSSP's enterprise ID to the ESPP Servers of the peers
   NewSSP wishes to exchange traffic with.








Cartwright, et al.       Expires August 28, 2008               [Page 18]


Internet-Draft                ESPP Protocol                February 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <addEntrRqst>
       <basicRqst> [snip] </basicRqst>
       <eId>76546</eId>
      </addEntrRqst>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>


                                 Figure 6

   The addEntr operation is an infrequent occurrence; it is used when
   new enterprises agree to exchange traffic.

4.3.1.2.  Session Establishment Data

4.3.1.2.1.  Description of Session Establishment Data

   As part of establishing their traffic exchange policies, each SSP
   defines its points of session interconnect for their service areas,
   which may or may not vary for each peering partner.  This information
   is part of the data required to establish a session and is called
   session establishment data (SED).  As described in the introductory
   sections of this document, SED in ESPP includes Routes, SBEs, and
   Service Areas.  SED is usually provisioned once for each SIP Service
   Provider with occasional subsequent updates as interconnect points
   are added or changed.  It is provisioned independently from the
   provisioning of the elements contained in Service Areas (TNs, TN
   Ranges, LRN, IM IDs).  This allows the rare process of provisioning
   SED to be distinctly separate from the continuous process of adding
   subscribers.  The service areas supported by each SIP Service
   Provider are illustrated in Figure 7 below.

















Cartwright, et al.       Expires August 28, 2008               [Page 19]


Internet-Draft                ESPP Protocol                February 2008


           +----------------+                 +----------------+
           |    Chicago     |_________________|    Boston      |
           |Service Area (1)|                 |Service Area (3)|
           +----------------+_                +----------------+
                   |          `-.          .-'        |
                   |             `.     .-'           |
                   |               `-..'              |
                   |               .-'`-.             |
                   |            .-'      `.           |
           +----------------+.-'           `-.+----------------+
           |   Flagstaff    |_________________|   New York     |
           |Service Area (2)|                 |Service Area (4)|
           +----------------+                 +----------------+

                     Sample Scenario and Service Areas

                                 Figure 7

   The three initial SIP Service Providers offer voice and IM services.
   GlobalSSP has defined two Service Areas and MidwestSSP and NewYorkSSP
   have each defined one Service Area.  Each Service Area is reachable
   via a Route associated with a set of SBEs.

   Figure 8 below further illustrates the details of the relationship
   between the Flagstaff and New York service areas operated by the
   GlobalSSP and NewYorkSSP respectively.  The examples in this section
   focus on the relationship between GlobalSSP's Flagstaff service area
   and the NewYorkSSP's New York service area.























Cartwright, et al.       Expires August 28, 2008               [Page 20]


Internet-Draft                ESPP Protocol                February 2008


     FlagStaff
     Service Area
                     SBE-10                     SBE-40
              ,-----. ,-.      Route 3 -->       ,-.   ,-----.
           ,-'       (SBE)______________________(SBE)-'       `-.
          /           `-'                        `-'             \
         /               \      <-- Route 300     /               \
        ;                 :                      ;                 :
        |                 |                      |                 |
        :                 ;                      :                 ;
         \             ,-.     Route 4 -->       ,+.              /
          \           (SBE)_____________________(SBE)            /
           `-.       ,-'-'                       `-'`-.       ,-'
              `-----' SBE-11    <-- Route 304   SBE-41 `-----'
                                                           New York
                                                           Service Area

                 Sample Scenario - Service Areas and SBEs

                                 Figure 8

   Each Route illustrated above is further defined in the Route table
   (Table 3 below) to contain one or more SBEs that serve as the ingress
   points for that Route.

   +-------------+-----------------------------------------------------+
   | Routes      | SBE NAPTRs                                          |
   +-------------+-----------------------------------------------------+
   | RTFlag-NYC1 | Order = 10, Pref=10, Svcs=E2U+SIP, Regx =           |
   | Ingress     | "!^.*$!sip:\\1@sbe40-newyork.newyorkssp.example1.co |
   | route to    | m!"                                                 |
   | reach the   |                                                     |
   | New York    |                                                     |
   | Service     |                                                     |
   | Area from   |                                                     |
   | Flagstaff.  |                                                     |
   |             |                                                     |
   |             |                                                     |
   |             |                                                     |
   | RTFlag-NYC2 | Order= 10, Pref=10, Svcs= E2U+IM, Regx =            |
   | Ingress     | "!^.*$!im:\\1@sbe41-newyork.newyorkssp.example1.com |
   | route to    | !"                                                  |
   | reach the   |                                                     |
   | New York    |                                                     |
   | Service     |                                                     |
   | Area from   |                                                     |
   | Flagstaff.  |                                                     |
   |             |                                                     |



Cartwright, et al.       Expires August 28, 2008               [Page 21]


Internet-Draft                ESPP Protocol                February 2008


   |             |                                                     |
   |             |                                                     |
   | RTNYC-Flag1 | Order= 10, Pref=10, Svcs= E2U+SIP, Regx =           |
   | Ingress     | "!^.*$!sip:\\1@sbe10-globalssp.example2.com!"       |
   | route to    |                                                     |
   | reach the   |                                                     |
   | Flagstaff   |                                                     |
   | Service     |                                                     |
   | Area from   |                                                     |
   | New York.   |                                                     |
   |             |                                                     |
   |             |                                                     |
   |             |                                                     |
   | RTNYC-Flag2 | Order = 10, Pref=10, Svcs= E2U+IM, Regx =           |
   | Ingress     | "!^.*$!im:\\1@sbe11-globalssp.example2.com!"        |
   | route to    |                                                     |
   | reach the   |                                                     |
   | Flagstaff   |                                                     |
   | Service     |                                                     |
   | Area from   |                                                     |
   | New York.   |                                                     |
   +-------------+-----------------------------------------------------+

             Table 3: Examples of Routes to SBEs Associations

   The Routes defined above can then be associated with the service
   areas that they support.  This allocation is laid out in the Table 4
   below.























Cartwright, et al.       Expires August 28, 2008               [Page 22]


Internet-Draft                ESPP Protocol                February 2008


   +------------+-------------+------------+-------------+-------------+
   | Service    | GlobalSSP   | GlobalSSP  | MidwestSSP  | NewYorkSSP  |
   | Areas      | Flagstaff   | Boston     | Chicago     | New York    |
   +------------+-------------+------------+-------------+-------------+
   | GlobalSSP  |             | RTFlag-Bos | RTFlag-Chi  | RTFlag-NYC1 |
   | Flagstaff  |             |            |             | RTFlag-NYC2 |
   |            |             |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   | GlobalSSP  | RTBos-Flag  |            | RTFlag-Chi  | RTBos-NYC   |
   | Boston     |             |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   | MidwestSSP | RTChi-Flag  | RTChic-Bos |             | RTChi-NYC   |
   | Chicago    |             |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   | NewYorkSSP | RTNYC-Flag1 | RTNYC-Bos  | RTNYC-Chi   |             |
   | NewYork    | RTNYC-Flag2 |            |             |             |
   |            |             |            |             |             |
   |            |             |            |             |             |
   +------------+-------------+------------+-------------+-------------+

         Table 4: Example of Service Areas to Routes Associations

4.3.1.2.2.  ESPP Provisioning of Session Establishment Data

   The Route, SBE, and Service Area data is provisioned in the
   appropriate ESPP Server of each participating SIP Service Provider
   using the addRtes, addSvcAreas, and addNAPTRs operations supported by
   the ESPP protocol.  An optional approach is to combine some of the
   operations into a single ESPP request using the batchUpdate
   operation.  The following example SOAP/XML messages provision the
   Routes, SBE NAPTRs, and Service Areas for the example above.

   Using the batchUpdate operation, the ESPP Client provisions the
   Global SSPs Flagstaff SBE NAPTRs, Routes, and Service Areas in the
   NewYorkSSP's ESPP Server.

   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <batchUpdateRqst>
       <basicRqst> [snip] </basicRqst>
       <batchUpdate>
        <op>



Cartwright, et al.       Expires August 28, 2008               [Page 23]


Internet-Draft                ESPP Protocol                February 2008


         <naptrAdd>
          <oid>7845601000012345610</id>
          <eId>76543</eId>
          <order>10</order>
          <pref>10</pref>
          <flags>u</flags>
          <svcs>E2U+SIP</svcs>
          <regx>!^.*$!sip:\\1@sbe10-globalssp.example2.com!</regx>
         </naptrAdd>
         <naptrAdd>
          <oid>7845601000012345611</id>
          <eId>76543</eId>
          <order>10</order>
          <pref>10</pref>
          <flags>u</flags>
          <svcs>E2U+IM</svcs>
          <regx>!^.*$!im:\\1@sbe11-globalssp.example2.com!</regx>
        </naptrAdd>
        <rteAdd>
         <oId>7845601000012345620</oId>
         <eId>76543</eId>
         <rteName>RTNYC-Flag1</rteName>
         <sbeNAPTRId>7845601000012345610</sbeNAPTRId>
         <isInSvc>true</isInSvc>
        </rteAdd>
        <rteAdd>
         <oId>7845601000012345621</oId>
         <eId>76543</eId>
         <rteName>RTNYC-Flag2</rteName>
         <sbeNAPTRId>7845601000012345611</sbeNAPTRId>
         <isInSvc>true</isInSvc>
        </rteAdd>
        <svcAreaAdd>
         <oId>7845601000012345630</oId>
         <eId>76543</eId>
         <saName>FlagstaffSA</saName>
         <rteId>7845601000012345620</rteId>
         <rteId>7845601000012345621</rteId>
        </svcAreaAdd>
       <op>
     </batchUpdateRqst>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

                                 Figure 9

   Using the alternative approach of a single ESPP operation for each
   object type (as opposed to the batchUpdate operation), the ESPP



Cartwright, et al.       Expires August 28, 2008               [Page 24]


Internet-Draft                ESPP Protocol                February 2008


   Client provisions the NewYorkSSP's NAPTRs, Routes, and Service Areas
   in the GlobalSSP's ESPP Server.

   Provision the New York SSP's New York NAPTRs in the Global SSPs
   Flagstaff SBEs ESPP Server.

  <?xml version="1.0" encoding="UTF-8"?>
  <SOAP-ENV:Envelope [snip] >
   <SOAP-ENV:Body>
     <addNAPTRsRqst>
      <basicRqst> [snip] </basicRqst>
      <naptr>
       <oid>7845601000012345612</id>
       <eId>76544</eId>
       <order>10</order>
       <pref>10</pref>
       <flags>u</flags>
       <svcs>E2U+SIP</svcs>
       <regx>!^.*$!sip:\\1@sbe40-newyork.newyorkssp.example1.com!</regx>
      </naptr>
      <naptr>
       <oid>7845601000012345613</id>
       <eId>76544</eId>
       <order>10</order>
       <pref>10</pref>
       <flags>u</flags>
       <svcs>E2U+IM</svcs>
       <regx>!^.*$!im:\\1@sbe41-newyork.newyorkssp.example1.com!</regx>
     </naptr>
    </addNAPTRsRqst>
   </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

                                 Figure 10

   The ESPP Client provisions the New York SSP's New York Routes in the
   Global SSP's ESPP Server.














Cartwright, et al.       Expires August 28, 2008               [Page 25]


Internet-Draft                ESPP Protocol                February 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <addRtesRqst>
       <basicRqst> [snip] </basicRqst>
       <rte>
        <oId>7845601000012345622</oId>
        <eId>76544</eId>
        <rteName>RTFlag-NYC1</rteName>
        <sbeNAPTRId>7845601000012345612</sbeNAPTRId>
        <isInSvc>true</isInSvc>
       </rte>
       <rte>
        <oId>7845601000012345623</oId>
        <eId>76544</eId>
        <rteName>RTFlag-NYC2</rteName>
        <sbeNAPTRId>7845601000012345613</sbeNAPTRId>
        <isInSvc>true</isInSvc>
       </rte>
      </addRtesRqst>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

                                 Figure 11

   The ESPP Client provisions the New York SSP's New York Service Areas
   in the Global SSP's ESPP Server.

   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <addSvcAreasRqst>
       <basicRqst> [snip] </basicRqst>
       <svcArea>
        <oId>7845601000012345631</oId>
        <eId>76544</eId>
        <saName>NewYorkSA</saName>
        <rteId>7845601000012345622</rteId>
        <rteId>7845601000012345623</rteId>
       </svcArea>
      </addSvcAreasRqst>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

                                 Figure 12






Cartwright, et al.       Expires August 28, 2008               [Page 26]


Internet-Draft                ESPP Protocol                February 2008


4.3.1.3.  Public Identities, TN Ranges, and LRNs

4.3.1.3.1.  Description of Identities, TN Ranges, and LRNs

   With the enterprises and SED data in place, SSPs have established the
   Service Areas they wish to exchange traffic to.  Public identities
   such as telephone numbers (TN), ranges of TNs, LRNs, IM identifiers
   can now be provisioned into Service Areas.  This scenario illustrates
   the provisioning of TNs, TN Ranges and LRNs for voice traffic
   exchanges, as well as the provisioning of TNs and IM identifiers for
   IM service.

   A group of friends wishes to take advantage of their voice and IM
   services by having their calls within the group always use the most
   efficient technology.  These friends are spread out between Boston,
   New York, Chicago and Phoenix and across three SSPs.  Their public
   identities (TNs and IM IDs) are defined below.  To simplify the
   scenario, the delivery of Instant Messages uses the same SBEs as the
   voice traffic.  As messaging grows, there may be a need to separate
   the SBEs into voice and data portals which would create new SBE NAPTR
   records and, optionally, new Routes.  Note that this is a technical
   example for the purpose of illustrating a protocol specification;
   end-user privacy considerations must apply.

   +--------+-------------+-------------+------------+-----------------+
   | Subscr | Number      | Service     | SSP        | IM Identity     |
   | iber   |             | Area        |            |                 |
   +--------+-------------+-------------+------------+-----------------+
   | Pat    | 928-774-555 | FlagstaffSA | GlobalSSP  | imPat@globalssp |
   |        | 5           |             |            | .example2.com   |
   |        |             |             |            |                 |
   | Ashley | 312-746-555 | ChicagoSA   | MidwestSSP | imAshley@midwes |
   |        | 5           |             |            | tssp.example3.c |
   |        |             |             |            | om              |
   |        |             |             |            |                 |
   | Vince  | 718-330-555 | NewYorkSA   | NewYorkSSP | imVince@newyork |
   |        | 5           |             |            | ssp.example1.co |
   |        |             |             |            | m               |
   |        |             |             |            |                 |
   | Carl   | 617-414-555 | BostonSA    | GlobalSSP  | imCarl@globalss |
   |        | 5           |             |            | p.example2.com  |
   +--------+-------------+-------------+------------+-----------------+

                                  Table 5

   These four subscribers have authorized their friends to see their
   public identities.  The SSPs have also defined TN Ranges associated
   with the new VoIP services as shown below.



Cartwright, et al.       Expires August 28, 2008               [Page 27]


Internet-Draft                ESPP Protocol                February 2008


   +-------------------------+--------------------+--------------------+
   | Service Area Name/ID    | TN Range           |                    |
   +-------------------------+--------------------+--------------------+
   | FlagstaffSA             | 928-774-5000       | 928-774-5999       |
   |                         |                    |                    |
   | ChicagoSA               | 312-746-5500       | 312-746-5600       |
   |                         |                    |                    |
   | NewYorkSA               | 718-330-5250       | 718-330-5590       |
   |                         |                    |                    |
   |                         | 718-330-4000       | 718-330-4999       |
   |                         |                    |                    |
   | BostonSA                | 617-414-5555       | 617-414-5560       |
   +-------------------------+--------------------+--------------------+

                                  Table 6

   To support number portability, Location Routing Numbers (LRNs) have
   identified each of the CMSes within the network.  Although there may
   be an LRN associated with each CMS, we show only the relevant sub-set
   applicable to this example:

   +---------------------+---------------------+-----------------------+
   | Proxy               | Service Area        | LRN                   |
   +---------------------+---------------------+-----------------------+
   | Proxy-center        | FlagstaffSA         | 928-774-1000          |
   |                     |                     |                       |
   | Proxy-lakestreet    | ChicagoSA           | 312-746-1000          |
   |                     |                     |                       |
   | Proxy-bronx         | NewYorkSA           | 718-330-1000          |
   |                     |                     |                       |
   | Proxy-fenway        | BostonSA            | 617-414-1000          |
   +---------------------+---------------------+-----------------------+

                                  Table 7

4.3.1.3.2.  ESPP Provisioning of TNs, LRNs, and identities

   The Public Identity, TN Range and LRN data can then be provisioned in
   the appropriate ESPP Server of each SSP using the addPvtIds,
   addPubIds, addTNRs, and addLRNs operations supported by the ESPP
   protocol.  An optional approach is to combine some of the operations
   into a single request using the batchUpdate operation.  The following
   example SOAP/XML messages provision the data described above.

   Using the batchUpdate operation, the ESPP Client provisions four
   GlobalSSP elements in the Flagstaff service area.  This command is
   sent to the NewYorkSSP's ESPP Server and to any other applicable peer
   servers.



Cartwright, et al.       Expires August 28, 2008               [Page 28]


Internet-Draft                ESPP Protocol                February 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <batchUpdateRqst>
       <basicRqst> [snip] </basicRqst>
       <batchUpdate>
        <op>
         <pviAdd>
           <oId>7845601000012345650</oId>
           <eId>76544</eId>
           <pvtId>patsPrivateIdentifier</pvtId>
         </pviAdd>
         <piAdd>
           <oId>7845601000012345640</oId>
           <eId>76543</eId>
           <pubId>9287745555</pubId>
           <saId>7845601000012345630</saId>
           <pvtId>7845601000012345650</pvtId>
         </piAdd>
         <piAdd>
           <oId>7845601000012345641</oId>
           <eId>76543</eId>
           <pubId>imPat@globalssp.example2.com</pubId>
           <svcs>E2U+IM</svcs>
           <saId>7845601000012345630</saId>
           <pvtId>7845601000012345650</pvtId>
         </piAdd>
         <tnRAdd>
           <oId>7845601000012345642</oId>
           <eId>76543</eId>
           <tnRStrt>9287745000</tnRStrt>
           <tnREnd>9287745999</tnREnd>
           <saId>7845601000012345630</saId>
         </tnRAdd>
         <lrnAdd>
           <oId>7845601000012345643</oId>
           <eId>76543</eId>
           <rn>9287741000</rn>
           <saId>7845601000012345630</saId>
         </lrnAdd>
       </op>
      </batchUpdate>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

                                 Figure 13

   Using the batchUpdate operation, the ESPP Client provisions four



Cartwright, et al.       Expires August 28, 2008               [Page 29]


Internet-Draft                ESPP Protocol                February 2008


   NewYorkSSP elements in the New York service area.  This command is
   sent to the GlobalSSP's ESPP Server (and to any other applicable
   servers).
















































Cartwright, et al.       Expires August 28, 2008               [Page 30]


Internet-Draft                ESPP Protocol                February 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <SOAP-ENV:Envelope [snip] >
    <SOAP-ENV:Body>
      <batchUpdateRqst>
       <basicRqst> [snip] </basicRqst>
       <batchUpdate>
        <op>
         <pviAdd>
           <oId>7845601000012345651</oId>
           <eId>76544</eId>
           <pvtId>vincesPrivateIdentifier</pubId>
         </pviAdd>
         <piAdd>
           <oId>7845601000012345644</oId>
           <eId>76544</eId>
           <pubId>7183305555</pubId>
           <saId>7845601000012345631</saId>
           <pvtId>7845601000012345651</pvtId>
         </piAdd>
         <piAdd>
           <oId>7845601000012345645</oId>
           <eId>76544</eId>
           <pubId>imVince@newyorkssp.example1.com</pubId>
           <svcs>E2U+IM</svcs>
           <saId>7845601000012345631</saId>
           <pvtId>7845601000012345651</pvtId>

         </piAdd>
         <tnRAdd>
           <oId>7845601000012345646</oId>
           <eId>76544</eId>
           <tnRStrt>7183305250</tnRStrt>
           <tnREnd>7183305590</tnREnd>
           <saId>7845601000012345631</saId>
         </tnRAdd>
         <lrnAdd>
           <oId>7845601000012345647</oId>
           <eId>76544</eId>
           <rn>7183301000</rn>
           <saId>7845601000012345631</saId>
         </lrnAdd>
       </op>
      </batchUpdate>
    </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

                                 Figure 14




Cartwright, et al.       Expires August 28, 2008               [Page 31]


Internet-Draft                ESPP Protocol                February 2008


4.3.2.  Deployment Scenario and Resolution

4.3.2.1.  Initiating an Outgoing Call

   Initiating a call from Pat to Vince, the CMS hosting Pat launches an
   ENUM query to the GlobalSSP addressing server.  The addressing server
   takes the E.164 address and examines the Public Identities to see if
   the specific number is set in the server.

   Vince's number is found in the New York Service Area.  This Service
   Area is associated with the Routes RTFlag-NYC1 and RTFlag-NYC2 that
   link Flagstaff with New York City.  Each of these Routes has a single
   SBE NAPTR record.  The addressing server would respond to the CMS
   with both NAPTR records.  The CMS then attempts to complete the call
   to the NewYorkSSP by sending the call setup to the address(es) found
   in the NAPTR record.  The detailed steps involved in this process
   are:

   1.  The CMS normalizes the TN to an e.164 format and queries the
   GlobalSSP ESPP Server, which results in the following response:

   $ORIGIN 5.5.5.5.0.3.3.8.1.7.1.ssp-example.
   NAPTR 10 100 "u" "E2U+SIP" "!^.*$
             !sip:\\1@sbe40-newyorkssp.newyorkssp.example1.com!".
   NAPTR 10 101 "u" "E2U+IM" "!^.*$
             !im:imvince@sbe41-newyorkssp.newyorkssp.example1.com!".

                                 Figure 15

   2.  Assuming that the CMS is interested in the SIP service, as it is
   initiating a telephone call, the CMS now executes a NAPTR query to
   the DNS server for "sbe40-newyorkssp.example1.com" resulting in:

   sbe40-newyorkssp.example1.com.
      order pref flgs service  regx    replacement
   IN NAPTR 100  50   "s"   "SIP+D2U" "" _sip._udp.sbe40-newyorkssp
                                  .newyorkssp.example1.com

                                 Figure 16

   3.  The CMS now sends a DNS SRV query for _sip._udp.sbe40-newyorkssp.
   newyorkssp.example1.com which results in:









Cartwright, et al.       Expires August 28, 2008               [Page 32]


Internet-Draft                ESPP Protocol                February 2008


   $ORIGIN _sip._udp.sbe40-newyorkssp.newyorkssp.example1.com.
    (Some content not included for clarity purposes.)
   IN SRV  0  1   5060   sbe40-newyorkssp.example1.com

   ;; ANSWER SECTION
   sbe40-newyorkssp.newyorkssp.example1.com   A   192.0.2.17
   sbe40-newyorkssp.newyorkssp.example1.com   A   192.0.2.18

                                 Figure 17

   4.  Now the CMS applies the regular expression rules to the NAPTR
   obtained in step 1 and places the result into the SIP Request URI:

   INVITE sip:17183305555@sbe40-newyorkssp.newyorkssp.example1.com
        SIP/2.0
   (Other SIP INVITE content not included for clarity purposes.)

                                 Figure 18

   5.  CMS sends the SIP INVITE to Vince via the SBE with associated
   IPv4 address 192.0.2.17 to port 5060 using UDP as the transport
   protocol.

4.3.2.2.  Receiving an Incoming Call

   Taking the call scenario described above, once the call request
   arrives in NewYorkSSP's network the SBE within NewYorkSSP queries its
   own ESPP Server and finds a match for Mary's number in the TN Range
   records (718-330-5250 to 718-330-5590).  The NewYorkSSP ESPP Server
   has been provisioned with intra-domain routes so that the SBE can
   locate the proper CMS.  The NewYorkSSP ESPP Server contains the New
   York Service Area that is associated with a intra-domain Route that
   is not shared with the other SSPs.  This allows the internal routing
   topology of an SSP to remain private to the SSP.  There is only one
   route for this range of phone numbers with only one NAPTR record.
   The data used to resolve the query looks like:

   TN Range:     718-330-5250 to 718-330-5590
        Service Area: New York
            Route: RTNYC-Private
        NAPTR 10 101 "u" "E2U+SIP" "!^.*$
                      !sip:\\1@cms-bronx.newyorkssp.example1.com!" .


                                 Figure 19






Cartwright, et al.       Expires August 28, 2008               [Page 33]


Internet-Draft                ESPP Protocol                February 2008


4.3.2.2.1.  Query using the Location Routing Number

   If the number has been ported, there are a number of cases where the
   query may also contain an Location Routing Number.  The Location
   Routing Number is a reference number for one or more telephone
   switches where previously the first 6 digits of the phone number
   clearly identified the switch.

   Once the call request arrives in NewYorkSSP's network the SBE within
   NewYorkSSP queries its own ESPP Server and finds a match for the LRN
   (718-330-1000) in the New York Service Area.  The rest of the routing
   lookup is similar to what is described for the telephone number
   above.

   LRN:     718-330-1000
        Service Area: New York
            Route: RTNYC-Private
        NAPTR 10 101 "u" "E2U+SIP" "!^.*$
                     !sip:\\1@cms-bronx.newyorkssp.example1.com!" .


                                 Figure 20

4.3.2.2.2.  Growth of the SIP Service Provider Group

   When NewSSP is ready to exchange traffic, their ESPP Server receives
   a batch download the latest data from all its peers via the
   Registrar.  The Registrar takes an image of the current data that
   each peer has allowed NewSSP to view and performs a secure file
   transfer to the NewSSP addressing server.  Following the download,
   the NewSSP ESPP Server connects to the Registrar and begin processing
   real-time updates to ensure that any changes made since creating the
   batch download files are made in the addressing server.

4.3.3.  Generic Examples

   Additional examples are available in Appendix I of [CableLabs-ESPP].

4.4.  Protocol Specification

   This section describes the general concepts that apply to the
   protocol's operations.  It also describes each individual protocol
   operation, its input and output objects, and its functional
   characteristics.  The complete normative specification of the
   protocol (the WSDL and XSD definitions) can be found in Section 8,
   Formal API Definition, in this document.  Note that if any
   specification conflicts exist between this section and Section 8, the
   normative definitions contained in Section 8 take precedence.



Cartwright, et al.       Expires August 28, 2008               [Page 34]


Internet-Draft                ESPP Protocol                February 2008


   The protocol utilizes SOAP 1.1 [SOAP], WSDL1.1 [WSDL], and XML 1.0
   [XML].

4.4.1.  General Protocol Concepts

   The following sub-sections describe the object structures and
   concepts that are applicable to many of the protocol operations

4.4.1.1.  Basic Request Object

   All ESPP operations that may potentially modify persistent protocol
   objects require a BasicRqst object to be passed in, in addition to
   other object types that are specific to each operation.  The basic
   request object contains a client ID, a transaction ID, the minor
   version of the protocol, and an optional extension element.  Each of
   the values is described in the subsequent sub-sections.


       <complexType name="BasicRqstType">
         <sequence>
            <element name="clientId" type="est:ClientIdType"/>
            <element name="transId" type="est:TransIdType"/>
            <element name="minorVer" type="est:VerType"/>
            <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
         </sequence>
      <complexType>

      <simpleType name="ClientIdType">
         <restriction base="int"/>
      </simpleType>

      <simpleType name="VerType">
         <restriction base="unsignedLong"/>
      </simpleType>



4.4.1.2.  Basic Query Object

   All ESPP "get" operations require a BasicQueryRqst object to be
   passed in, in addition to other object types that are specific to
   each get operation.  The basic query object contains a client ID, the
   minor version of the protocol, and an optional extension element.
   Each of the values is described in the subsequent sub-sections.
   Notice that no transaction ID is necessary for query operations.






Cartwright, et al.       Expires August 28, 2008               [Page 35]


Internet-Draft                ESPP Protocol                February 2008


      <complexType name="BasicQueryType">
         <sequence>
            <element name="clientId" type="est:ClientIdType"/>
            <element name="minorVer" type="est:VerType"/>
            <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
            </sequence>
      </complexType>



4.4.1.3.  Authentication

   For each ESPP connection, the ESPP Client and ESPP Server MUST use
   HTTP Digest based authentication as defined in [RFC2617].  The HTTP
   Digest authentication SHOULD be performed once per connection.  To
   further support authentication and operational activities, such as
   auditing, each ESPP operation requires a client ID as input.

4.4.1.4.  Transaction ID

   Each ESPP Client maintains a transaction ID counter for each ESPP
   Server that it is configured to update.  Similarly, each ESPP Server
   maintains the transaction ID for each ESPP Client from which it
   receives updates.  These transaction IDs are maintained in persistent
   storage on both client and server.  The protocol data element that
   contains the transaction ID for each operation is declared as
   follows:


      <element name="transId" type="est:TransIdType"/>
      <simpleType name="TransIdType">
         <restriction base="unsignedLong"/>
      </simpleType>



   A transaction ID is sent with each update request to an ESPP Server.
   The transaction ID MUST be present in a protocol request operation
   whose purpose is to modify data within an ESPP Server.  The ESPP
   Client and ESPP Server must implement the transaction ID as a 64-bit
   value.  The initial value for the transaction ID on the ESPP Client
   MUST either be chosen randomly, start at zero, or be configured by
   the SIP Service Provider before protocol processing or bootstrap file
   generation begins.

   When generating an API based update request or a file based
   batchFileUpdateRqst request destined for an ESPP Server, the ESPP
   Client MUST use the current transaction ID for the target server,



Cartwright, et al.       Expires August 28, 2008               [Page 36]


Internet-Draft                ESPP Protocol                February 2008


   whose value one increment greater than the previous successfully
   transaction ID (or the first transaction ID in the counter if this is
   the first request generated for the given ESPP Client/server pair).
   After successfully generating a batchFileUpdateRqst structure or
   after receiving a successful response from an API base request, the
   client increments the transaction ID for that server by one.

   When receiving a transaction ID in a request, the ESPP Server
   compares it to its current transaction ID value.  If the transaction
   ID from the client is one greater than the transaction ID from the
   server, the request is processed normally.  If the request succeeds
   on the server, the ESPP Server MUST update its transaction ID to be
   the one received from the client.  Once all database changes have
   been synchronized to persistent storage, the server MUST respond with
   a successful result code.  When the client receives the response from
   the server indicating that the request has succeeded, the client MUST
   increment its transaction ID by one.

   If the server receives a request from a client with a transaction ID
   that is the same as server's current transaction ID for that client,
   the server compares the content of the request received from the
   client to the content of the request most recently received from that
   client.  If the content is identical, this indicates that the client
   failed to receive the response to the previous transaction.  The
   client is assumed to be retrying that transaction that the server has
   already successfully processed.  In this event the server SHOULD NOT
   modify its database.  The ESPP Server MUST simply return the
   identical response that it returned in response to the clients first
   attempt to process the request/response.

   In the case that the transaction ID is the same but the request
   content is different, or the transaction ID from the client is
   different but is not one greater than the transaction ID for that
   client on the server, the server and client are out of sync.  In this
   event, the ESPP Server SHOULD return the appropriate error code
   (Transaction ID out of sequence).  The ESPP Client MUST automatically
   suspend protocol updates to that server and raise a critical alarm.
   Manual intervention is likely required at this point to analyze and
   clear the error, perhaps by initiating a full re-synchronization of
   the client's data store, and then re-enabling real-time protocol
   communication to that ESPP Server.

   In cases where the server determines the transaction ID to be
   correct, there are two general categories of errors: system errors
   and business errors.  In the event a system error occurs (e.g., disk
   space has been exhausted) the ESPP Server MUST return the appropriate
   error message (System Unavailable Error or Authentication Error) and
   the ESPP Client SHOULD suspend real-time updates to the server for



Cartwright, et al.       Expires August 28, 2008               [Page 37]


Internet-Draft                ESPP Protocol                February 2008


   some period of time configured by the SIP Service Provider, and then
   resume after that time has elapsed.  In this case the ESPP Client
   MUST not update the transaction ID as transaction IDs are only
   consumed/updated by the client on successful responses to a given API
   request or when a file based update is successfully generated by the
   client.  In the event a business error occurs (e.g., a data element
   fails the regular expression validation), the ESPP Server MUST return
   the appropriate error code for the given error and operation.  In
   response to this type of error response the client MUST, again, not
   consume that transaction ID, because the transaction did not complete
   successfully.  The client MUST suspend real-time protocol
   communication with that ESPP Server and generate an internal alarm.
   Manual intervention is required to analyze and rectify the erroneous
   data that caused the error and then re-enable real-time protocol
   communication with the ESPP Server.

4.4.1.5.  Version Identification

   The version of the ESPP protocol in use is defined by the combination
   of the major version ID embedded in the namespace of the XSD and the
   minor version ID that is passed in with each request as an element of
   the BasicRqstType object.

   A major version ID will change when a change is made to the protocol
   that is not backward compatible.  The minor version ID may change
   when a change is made to the protocol that is backward compatible.
   The version ID passed in by the ESPP Client MUST indicate the version
   that the client supports; it SHOULD be the version that the client
   believes that the ESPP Server supports.  When a message arrives at
   the server, the server MUST evaluate the version indicator passed in
   by the ESPP Client and it MUST return the appropriate error code and
   message if the version is not one that is supported by the server.
   Refer to the list of response codes for the appropriate code to
   return in this circumstance.

4.4.1.6.  Basic Response Object

   The request/input object type is distinct for each operation.
   However, most operations of the ESPP protocol return the same
   response/output object type, CmnRspnsMsg.  In keeping with the
   Document Literal Wrapped design approach described in the
   introductory sections, the WSDL declaration of this response message
   is declared as follows:








Cartwright, et al.       Expires August 28, 2008               [Page 38]


Internet-Draft                ESPP Protocol                February 2008


      <wsdl:message name="cmnRspnsMsg">
         <wsdl:part name="rspns" element="est:cmnRspns"/>
      </wsdl:message>

      <complexType name="BasicRspnsType">
         <sequence>
            <element name="resCode" type="int"/>
            <element name="resMsg" type="string"/>
            <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
         </sequence>
      </complexType>



   The resCode element is a response code and the resMsg is the
   corresponding response message.  The BasicRspnsType may also be
   extended using the ext element.  Each of these elements is further
   described in subsequent sections.

4.4.1.7.  Object ID and Enterprise ID

   As described in the Logical Structure section of this document, each
   object instance in ESPP has an identifier that uniquely identifies
   that object instance within an ESPP Server, its oId, and an
   identifier that uniquely identifies an operational entity within a
   call routing community, its eId.  These two data elements are defined
   as follows:


      <simpleType name="OIdType">
         <restriction base="unsignedLong"/>
      </simpleType>

      <simpleType name="EIdType">
         <restriction base="string"/>
      </simpleType>



   The ESPP Client and ESPP Server MUST implement the oId attribute as
   an unsigned 64-bit value.

4.4.1.8.  Response Codes and Messages

   The response to each protocol operation includes exactly one response
   code and response message.  The response codes that each operation is
   permitted to return are listed in each sub-section that describes
   each operation.  And the consolidated list of response codes and



Cartwright, et al.       Expires August 28, 2008               [Page 39]


Internet-Draft                ESPP Protocol                February 2008


   messages are listed in the "Response Codes and Messages" section of
   this document.

   All real-time API operations of the ESPP protocols MUST be atomic,
   all aspects of the operation will fail or all will succeed.  An
   operation should never result in a "partial success".  As a result,
   the response code returned by any given operation call indicates
   whether the operation succeeded or failed.  Each failure reason has a
   unique failure response code and message, and only one may be
   returned in response to any given operation call.  The protocol
   object that houses the response code and message is called
   BasicRspnsType.

4.4.1.9.  Extensibility

   Extensibility allows a given ESPP Client or ESPP Server to supplement
   ESPP messages with additional object or data elements that may be
   appropriate for a given ESPP deployment or operational scenario.
   ESPP is implicitly and explicitly extensible.  Implicit extensibility
   is supported by the fact that XSD and WSDL definitions may be
   extended without breaking backward compatibility.  New WSDL
   operations can be added and new XSD data types can be added without
   breaking backward compatibility.  Explicit extensibility is supported
   through the use of the XSD "any" type.  Each object type definition
   in ESPP contains an additional attribute called "ext", which is of
   type ExtAnyType, which contains one or more an XSD "any" elements.
   Furthermore, the BasicRqstType and BasicRspnsType also contain an
   "ext" element to allow the addition of objects of any type to be
   added to the request and response objects that are used for each ESPP
   operation.  And ESPP Server may dynamically evaluate the version ID
   of any given request and choose to accept or return these optional
   attributes from or to an ESPP Client.


      <complexType name="ExtAnyType">
         <sequence>
            <any namespace="##other" maxOccurs="unbounded"/>
         </sequence>
      </complexType>



4.4.2.  Protocol Operation Descriptions

   The following sub-sections describe each individual protocol
   operation in detail, its input and output objects, and its functional
   characteristics.




Cartwright, et al.       Expires August 28, 2008               [Page 40]


Internet-Draft                ESPP Protocol                February 2008


4.4.2.1.  Operation Name: addRtes

   As described in the introductory sections, a Route represents a
   collection of session-level peering points named Signaling path
   Border Elements (SBEs).  Routes are linked to Service Areas to
   establish the link between a set of public identities and their SBEs.
   It is this indirect linking of public identities to SBEs that
   significantly improves the scalability and manageability of the
   peering data.  Additions and changes to session-level peering points
   are reduced to a single data distribution operation of a Route or
   Service Area in an addressing server, rather than millions of data
   distribution updates to public identity records that individually
   contain their peering point data.

   The addRtes operation creates or overwrites one or more Routes in the
   addressing server.  If a Route with the given Route ID does not
   exist, then the ESPP Server MUST create the route.  If a Route with
   the given Route ID does exist, then the ESPP Server MUST replace the
   current properties of the Route with the properties passed into the
   addRtes operation.  If a Route with the given ID does exist, but was
   created by a client other than the one calling the addRtes operation
   then the ESPP Server SHOULD reject the request with the appropriate
   error code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:



   <wsdl:operation name="addRtes">
      <wsdl:input message="addRtesRqstMsg"/>
      <wsdl:output message="cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="addRtesRqstMsg">
      <wsdl:part name="rqst" element="est:addRtesRqst"/>
   </wsdl:message>

   <wsdl:message name="cmnRspnsMsg">
      <wsdl:part name="rspns" element="est:cmnRspns"/>
   </wsdl:message>



   Inputs to the operation are wrapped in the addRtesRqst object, which
   is declared as follows:




Cartwright, et al.       Expires August 28, 2008               [Page 41]


Internet-Draft                ESPP Protocol                February 2008


  <element name="addRtesRqst">
     <complexType>
        <sequence>
          <element name="basicRqst" type="est:BasicRqstType"/>
          <element name="rte" type="est:RteType" maxOccurs="unbounded"/>
        </sequence>
     </complexType>
  </element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to Section 4.4.1, General Protocol Concepts,
   for a detailed description of this data element.  One or more RteType
   objects are also required.  Any limitation on the maximum number of
   routes that may be passed into a call to the addRtes operation is a
   policy decision and is not limited by the protocol.

   The RteType object structure is declared as follows:


   <complexType name="RteType">
      <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="rteName" type="string"/>
         <element name="sbeNaptrId" type="est:OIdType" minOccurs="0"
            maxOccurs="unbounded"/>
         <element name="isInSvc" type="boolean"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
      </sequence>
   </complexType>


   The RteType object is comprised of the following data elements:

   o    oId: Exactly one object ID to uniquely identify the object
        instance.  This identifier is also an input to the delRtes,
        getRtes, and addSvcAreas operations to identify a given route.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for, or "owns" this object.

   o    RteName: Exactly one human readable name of the Route.

   o    SBENaptrId: Zero or more NAPTR IDs.  NAPTR objects are further
        described below.




Cartwright, et al.       Expires August 28, 2008               [Page 42]


Internet-Draft                ESPP Protocol                February 2008


   o    IsInSvc: Toggle-able boolean value that sets the Route in
        service or out of service.  The ESPP Server MUST NOT include the
        NAPTR record(s) associated with an out-of-service route in the
        response to a resolution request for a telephone number that is
        associated with the Route that contains that border element.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   Table 8 defines the result codes and messages that the addRtes
   operation SHOULD return.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

           Table 8: addRtes Operation Result Codes and Messages

4.4.2.2.  Operation Name: addSvcAreas

   As described in the introductory sections, a Service Area represents
   a collection of public identities that are linked to a set of Routes.
   Routes are linked to Service Areas to establish the link between a
   set of public identities and their session-level peering points.  The
   addSvcAreas operation creates or overwrites one or more Service Areas
   in the addressing server.  If a service area with the given service
   area ID does not exist, then the ESPP Server MUST create the service
   area.  If a service area with the given identity does exist, then the



Cartwright, et al.       Expires August 28, 2008               [Page 43]


Internet-Draft                ESPP Protocol                February 2008


   ESPP Server MUST replace the current properties of that service area
   with the properties passed into the addSvcAreas operation.  If a
   service area with the given ID does exist, but was created by a
   client other than the one calling the addSvcAreas operation then the
   ESPP Server SHOULD reject the request with the appropriate error
   code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="addSvcAreas">
      <wsdl:input message="addSvcAreasRqstMsg"/>
      <wsdl:output message="cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="addSvcAreasRqstMsg">
      <wsdl:part name="rqst" element="est:addSvcAreasRqst"/>
   </wsdl:message>

   <wsdl:message name="cmnRspnsMsg">
      <wsdl:part name="rspns" element="est:cmnRspns"/>
   </wsdl:message>


   Inputs to the operation are wrapped in the addSvcAreasRqst object,
   which is declared as follows:


   <element name="addSvcAreasRqst">
      <complexType>
         <sequence>
            <element name="basicRqst" type="est:BasicRqstType"/>
            <element name="svcArea" type="est:SvcAreaType"
               maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to Section 4.4.1, General Protocol Concepts,
   for a detailed description of this data element.  Also required is
   one or more SvcAreaType objects.  Any limitation on the maximum
   number of service areas that may be passed into a call to the
   addSvcAreas operation is a policy decision and is not limited by the
   protocol.



Cartwright, et al.       Expires August 28, 2008               [Page 44]


Internet-Draft                ESPP Protocol                February 2008


   The SvcArea object structure is declared as follows:


   <complexType name="SvcAreaType">
      <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="saName" type="string"/>
         <element name="rteId" type="est:OIdType"
            minOccurs="0" maxOccurs="unbounded"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
      </sequence>
   </complexType>


   The data elements of the SvcAreaType are described as follows:

   o    oId: Exactly one object ID that provides the identity of the
        object.  This identifier is also an input to other operations
        that must refer to a Service area, such as delSvcAreas,
        getSvcAreas, and addPubIds operations to identify a given
        service area.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for, or "owns" this object.

   o    SAName: Exactly one human readable name of the service area.

   o    RteID: The identity of zero or more routes that the Public
        Identities, LRNs, and TN Ranges in this service area can be
        routed through.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   The ESPP Server MUST reject any addServiceAreas operation call that
   attempts to create a service area with a route ID that does not exist
   within the context of the addressing server.

   Table 9 defines the result codes and messages that the addSvcAreas
   operation SHOULD return.









Cartwright, et al.       Expires August 28, 2008               [Page 45]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

         Table 9: addSvcAreas Operation Result Codes and Messages

4.4.2.3.  Operation Name: addPubIds

   As described in the introductory sections, a Public Identity object
   represents a public addressable identity (such as a telephone number,
   email address, or some other addressable string).  It is linked to
   SBEs and NAPTRs (indirectly via a Service Area ID), and,
   alternatively, to directly associated NAPTRs.  The ESPP protocol
   allows a Public Identity to have a relationship to a Service Area
   and/or a set of NAPTRs.

   A Public Identity may also be associated with a Private Identity
   object.  The addPubIds operation creates or overwrites one or more
   PubId objects in the addressing server.  If a PubId object with the
   same object ID does not exist within the context of the addressing
   server, then the ESPP Server MUST create the PubId object.  If such
   an object does exist within the context of the addressing server,
   then the ESPP Server MUST replace the current properties of that
   object with the values passed into the addPubIds operation.  If a
   Public Identity with the given ID does exist, but was created by a



Cartwright, et al.       Expires August 28, 2008               [Page 46]


Internet-Draft                ESPP Protocol                February 2008


   client other than the one calling the addPubIds operation then the
   ESPP Server SHOULD reject the request with the appropriate error
   code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="addPubIds">
      <wsdl:input message="esp:addPubIdsRqstMsg"/>
      <wsdl:output message="esp:cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="addPubIdsRqstMsg">
      <wsdl:part name="rqst" element="est:addPubIdsRqst"/>
   </wsdl:message>

   <wsdl:message name="cmnRspnsMsg">
      <wsdl:part name="rspns" element="est:cmnRspns"/>
   </wsdl:message>


   Inputs to the operation are wrapped in the addPubIdsRqst object,
   which is declared as follows:


<element name="addPubIdsRqst">
   <complexType>
      <sequence>
         <element name="basicRqst" type="est:BasicRqstType"/>
         <element name="pi" type="est:PubIdType" maxOccurs="unbounded"/>
      </sequence>
   </complexType>
</element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1, General Protocol
   Concepts, for a detailed description of this data element.  Also
   required is one or more PubIdType objects.  Any limitation on the
   maximum number of Public Identities that may be passed into a call to
   the addPubIds operation is a policy decision and is not limited by
   the protocol.

   The PubIdType object structure is declared as follows:





Cartwright, et al.       Expires August 28, 2008               [Page 47]


Internet-Draft                ESPP Protocol                February 2008


   <complexType name="PubIdType">
      <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="pubId" type="string"/>
         <element name="svcs" type="string"/>
         <element name="saId" type="est:OIdType" minOccurs="0"/>
         <element name="naptrId" type="est:OIdType" minOccurs="0"
            maxOccurs="unbounded"/>
         <element name="pvtId" type="est:OIdType" minOccurs="0"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
      </sequence>
   </complexType>


   The PubIdType is comprised of the following data elements:

   o    oId: Exactly one object ID that provides the identity of the
        object.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "owns" this object.

   o    PubId: Exactly one public identity that is a resolvable identity
        within the context of the addressing server.  This identity may,
        for example, be a TN, an email address, or some other resolvable
        identity.

   o    Svcs: Exactly one ENUM service type associated with the public
        identity.  This field's value must be of the form specified in
        [RFC 3761] (e.g., E2U+pstn:sip+sip).  The allowable values are a
        matter of policy and not limited by this protocol.

   o    SAId: Zero or one object ID that identifies the Service Area
        this public identity object instance resides within.  The
        Service Area's relationship to one or more Routes can then
        define the peering points of Public Identities.  The ESPP Server
        MUST reject, with the appropriate error response code, an
        attempt to create a public identity object containing a Service
        Area ID that does not exist within the appropriate context of
        the addressing server.

   o    NAPTR: Zero or more NAPTRs.  NAPTR objects directly associated
        with a public identity can be a lower level, more data
        distribution intensive approach to associating a telephone
        number with its peering points.




Cartwright, et al.       Expires August 28, 2008               [Page 48]


Internet-Draft                ESPP Protocol                February 2008


   o    PvtId: Zero or one object ID that optionally identified a
        private identity to which this public identity is associated.
        This provides the ability to create a "related" set of public
        identities.  The ESPP Server MUST return an error response if
        the Private Identity object identified by this PvtId does not
        exist within the context of the addressing server.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   The ESPP protocol does not specifically disallow the creation of
   Public Identities that have no associated NAPTRs and no associated
   Service Area.

   Table 10 defines the result codes and messages that the addPubIds
   operation SHOULD return.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

          Table 10: addPubIds Operation Result Codes and Messages






Cartwright, et al.       Expires August 28, 2008               [Page 49]


Internet-Draft                ESPP Protocol                February 2008


4.4.2.4.  Operation Name: addPvtIds

   As described in the introductory sections, a Private Identity object
   represents a string of numbers or characters that serves to
   associate, or group together, a set of related Public Identities.
   The addPvtIds operation creates or overwrites one or more PvtId
   objects in the addressing server.  If a PvtId object with the same
   object ID does not exist within the context of the addressing server,
   then the ESPP Server MUST create the PvtId object.  If such an object
   does exist within the context of the addressing server, then the ESPP
   Server MUST replace the current properties of that object with the
   values passed into the operation.  If a Private Identity with the
   given ID does exist, but was created by a client other than the one
   calling the addPvtIds operation then the ESPP Server SHOULD reject
   the request with the appropriate error code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="addPvtIds">
      <wsdl:input message="esp:addPvtIdsRqstMsg"/>
      <wsdl:output message="esp:cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="addPvtIdsRqstMsg">
      <wsdl:part name="rqst" element="est:addPvtIdsRqst"/>
   </wsdl:message>

   <wsdl:message name="cmnRspnsMsg">
      <wsdl:part name="rspns" element="est:cmnRspns"/>
   </wsdl:message>




   Inputs to the operation are wrapped in the addPvtIdsRqst object,
   which is declared as follows:


<element name="addPvtIdsRqst">
   <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="pvi" type="est:PvtIdType" maxOccurs="unbounded"/>
      </sequence>
   </complexType>



Cartwright, et al.       Expires August 28, 2008               [Page 50]


Internet-Draft                ESPP Protocol                February 2008


</element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1, General Protocol
   Concepts, for a detailed description of this data element.  Also
   required is one or more PubIdType objects.  Any limitation on the
   maximum number of Public Identities that may be passed into a call to
   the addPubIds operation is a policy decision and is not limited by
   the protocol.

   The PvtIdType object structure is declared as follows:


   <complexType name="PvtIdType">
      <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="pvtId" type="string"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
      </sequence>
   </complexType>


   The PvtIdType is comprised of the following data elements:

   o    oId: Exactly one object ID that provides the identity of the
        object.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "owns" this object.

   o    PvtId: Exactly one private identity that serves to associate, or
        group together, a set of related Public Identities.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   Table 11 defines the result codes and messages that the addPvtIds
   operation SHOULD return.










Cartwright, et al.       Expires August 28, 2008               [Page 51]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

          Table 11: addPvtIds Operation Result Codes and Messages

4.4.2.5.  Operation Name: addLRNs

   As described in the introductory sections, an LRN object represents a
   routing number and its indirect relationship to one or more SBEs (via
   a Service Area ID)

   The addLRNs operation creates or overwrites one or more LRN objects
   in the addressing server.  If a LRN object with the same object ID
   does not exist within the context of the addressing server, then the
   ESPP Server MUST create the LRN object.  If an LRN object with the
   same object ID does exist within the context of the addressing
   server, then the ESPP Server MUST replace the current properties of
   that LRN with the properties passed into the addLRNs operation.  If
   an LRN with the given ID does exist, but was created by a client
   other than the one calling the addLRN operation then the ESPP Server
   SHOULD reject the request with the appropriate error code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the



Cartwright, et al.       Expires August 28, 2008               [Page 52]


Internet-Draft                ESPP Protocol                February 2008


   operation is as follows:


       <wsdl:operation name="addLRNs">
           <wsdl:input message="addLRNsRqstMsg"/>
           <wsdl:output message="cmnRspnsMsg"/>
       </wsdl:operation>

       <wsdl:message name="addLRNsRqstMsg">
           <wsdl:part name="rqst" element="est:addLRNsRqst"/>
       </wsdl:message>

       <wsdl:message name="cmnRspnsMsg">
           <wsdl:part name="rspns" element="est:cmnRspns"/>
       </wsdl:message>



   Inputs to the operation are wrapped in the addLRNsRqst object, which
   is declared as follows:


     <element name="addLRNsRqst">
       <complexType>
         <sequence>
          <element name="basicRqst" type="est:BasicRqstType"/>
          <element name="lrn" type="est:LRNType" maxOccurs="unbounded"/>
         </sequence>
       </complexType>
     </element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1 General Protocol Concepts
   for a detailed description of this data element.  Also required is
   one or more LRNType objects.  Any limitation on the maximum number of
   LRNs that may be passed into a call to the addLRNs operation is a
   policy decision and is not limited by the protocol.

   The LRN object structure is declared as follows:











Cartwright, et al.       Expires August 28, 2008               [Page 53]


Internet-Draft                ESPP Protocol                February 2008


       <complexType name="LRNType">
           <sequence>
               <element name="oid" type="est:OIdType"/>
               <element name="eid" type="est:EIdType"/>
               <element name="rn" type="string"/>
               <element name="saId" type="est:OIdType"/>
               <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
           </sequence>
       </complexType>



   LRNType is comprised of the following data elements:

   o    oId: Exactly one object ID that provides the identity of the
        object.  This identifier is also an input to the delLRNs,
        getLRNs operations to identify a given LRN

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "owns" this object

   o    RN: One local routing number

   o    SAId: Exactly one object ID that identifies the Service Area in
        which this LRN resides.  The Service Area's relationship to one
        or more Routes can then define the LRNs peering points.  The
        ESPP Server MUST reject, with the appropriate error response
        code, an attempt to create an LRN object containing a Service
        Area ID that does not exist within the appropriate context of
        the addressing server

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document

   Table 12 defines the result codes and messages that the addLRNs
   operation SHOULD return.














Cartwright, et al.       Expires August 28, 2008               [Page 54]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

           Table 12: addLRNs Operation Result Codes and Messages

4.4.2.6.  Operation Name: addTNRs

   As described in the introductory sections, a TNRType is a range of
   telephone numbers which are provisioned as a group, reducing the
   number of objects that must be independently provisioned and managed.
   This object contains the indirect relationship to a set of peering
   point NAPTRs (via a Service Area ID).  The addTNRs operation creates
   or overwrites one or more TNR objects in the addressing server.  If a
   TNR object with the same object ID does not exist within the context
   of the addressing server, then the ESPP Server MUST create the TNR
   object.  If such an object does exist within the context of the
   addressing server, then the ESPP Server MUST replace the current
   properties of that object with the values passed into the addTNRanges
   operation.  If a TNRange with the given ID does exist, but was
   created by a client other than the one calling the addTNRs operation
   then the ESPP Server SHOULD reject the request with the appropriate
   error code, 2106.

   In keeping with the Document Literal Wrapped design approach



Cartwright, et al.       Expires August 28, 2008               [Page 55]


Internet-Draft                ESPP Protocol                February 2008


   described in the introductory sections, the WSDL declaration of the
   operation is as follows:



     <wsdl:operation name="addTNRs">
       <wsdl:input message="esp:addTNRsRqstMsg"/>
       <wsdl:output message="esp:cmnRspnsMsg"/>
     </wsdl:operation>

     <wsdl:message name="addTNRsRqstMsg">
       <wsdl:part name="rqst" element="est:addTNRsRqst"/>
     </wsdl:message>

     <wsdl:message name="cmnRspnsMsg">
       <wsdl:part name="rspns" element="est:cmnRspns"/>
     </wsdl:message>



   Inputs to the operation are wrapped in the addTNRsRqst object, which
   is declared as follows:


     <element name="addTNRsRqst">
       <complexType>
        <sequence>
         <element name="basicRqst" type="est:BasicRqstType"/>
         <element name="tnR" type="est:TNRType" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
     </element>



   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1, General Protocol
   Concepts, for a detailed description of this data element.  Also
   required is one or more TNRType objects.  Any limitation on the
   maximum number of TNRs that may be passed into a call to the
   operation is a policy decision and is not limited by the protocol.

   The TNRType object structure is declared as follows:








Cartwright, et al.       Expires August 28, 2008               [Page 56]


Internet-Draft                ESPP Protocol                February 2008


     <complexType name="TNRType">
       <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="tnRStrt" type="string"/>
         <element name="tnREnd" type="string"/>
         <element name="saId" type="est:OIdType"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
       </sequence>
     </complexType>


   TNRType is comprised of the following data elements:

   o    oId: Exactly one object ID that provides the identity of the
        object.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "owns" this object.

   o    TNRStrt: A required element that represents either the telephone
        number being added or the first telephone number in a continuous
        range of telephone numbers being added.

   o    TNREnd: An optional element that represents the last telephone
        number in a continuous range of telephone numbers being added.
        The ESPP Server MUST validate that the range is a valid range of
        continuous numbers (e.g., that the tnREnd is greater than the
        tnRStrt).  If not, then the ESPP Server MUST return the
        appropriate error code to the ESPP Client.

   o    SAId: Exactly one object ID that identifies the Service Area
        this TN Range object instance resides within.  The Service
        Area's relationship to one or more Routes can then define the
        telephone numbers' peering points.  The ESPP Server MUST reject,
        with the appropriate error response code, an attempt to create a
        TNR object containing a Service Area ID that does not exist
        within the appropriate context of the addressing server.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   Table 13 defines the result codes and messages that the addTNRs
   operation SHOULD return






Cartwright, et al.       Expires August 28, 2008               [Page 57]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

           Table 13: addTNRs Operation Result Codes and Messages

4.4.2.7.  Operation Name: addNAPTRs

   As described in the introductory sections, a NAPTR object represents
   a peering point for routing and/or other data.  NAPTRs are associated
   to Routes and TNs.  The addNAPTRs operation creates or overwrites one
   or more NAPTR objects in the addressing server.  If a NAPTR object
   with the same object ID does not exist within the context of the
   addressing server, then the ESPP Server MUST create the NAPTR object.
   If a NAPTR object with the same object ID does exist within the
   context of the addressing server, then the ESPP Server MUST replace
   the current properties of that NAPTR with the properties passed into
   the addNAPTRs operation.  If a NAPTR with the given ID does exist,
   but was created by a client other than the one calling the addNAPTRs
   operation then the ESPP Server SHOULD reject the request with the
   appropriate error code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:



Cartwright, et al.       Expires August 28, 2008               [Page 58]


Internet-Draft                ESPP Protocol                February 2008


     <wsdl:operation name="addNAPTRs">
       <wsdl:input message="addNAPTRsRqstMsg"/>
       <wsdl:output message="cmnRspnsMsg"/>
     </wsdl:operation>

     <wsdl:message name="addNAPTRsRqstMsg">
       <wsdl:part name="rqst" element="est:addNAPTRsRqst"/>
     </wsdl:message>

     <wsdl:message name="cmnRspnsMsg">
       <wsdl:part name="rspns" element="est:cmnRspns"/>
     </wsdl:message>

   Inputs to the operation are wrapped in the addNAPTRsRqst object,
   which is declared as follows:


   <element name="addNAPTRsRqst">
    <complexType>
     <sequence>
      <element name="basicRqst" type="est:BasicRqstType"/>
      <element name="naptr" type="est:NAPTRType" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
   </element>

   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1 General Protocol Concepts
   for a detailed description of this data element.  Also required is
   one or more NAPTRType objects.  Any limitation on the maximum number
   of NAPTRs that may be passed into a call to the addNAPTRs operation
   is a policy decision and is not limited by the protocol.

   A NAPTR object is declared as follows:


     <complexType name="NAPTRType">
       <sequence>
         <element name="oid" type="est:OIdType"/>
         <element name="eid" type="est:EIdType"/>
         <element name="order" type="unsignedShort"/>
         <element name="pref" type="unsignedShort"/>
         <element name="flags" type="string" minOccurs="0"/>
         <element name="svcs" type="string"/>
         <element name="regx" type="string" minOccurs="0"/>
         <element name="repl" type="string" minOccurs="0"/>
         <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
       </sequence>



Cartwright, et al.       Expires August 28, 2008               [Page 59]


Internet-Draft                ESPP Protocol                February 2008


     </complexType>

   The NAPTRType object is comprised of the data elements that are
   necessary for a NAPTR that represents a peering port within the
   Route.  Each data element is described as follows:

   o    oId: Exactly one object ID to uniquely identify the object
        instance.  This identifier is also an input to the delNAPTRs,
        getNAPTRs, and addRtes operations to identify a given NAPTR.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "owns" this object.

   o    Order: Relative order value in an ENUM NAPTR.

   o    Pref: Relative preference value in an ENUM NAPTR.

   o    Svcs: ENUM service(s) that are served by the SBE.  This field's
        value must be of the form specified in RFC 3761 (e.g., E2U+
        pstn:sip+sip).  The allowable values are a matter of policy and
        not limited by this protocol.

   o    Regex: NAPTR's regular expression field.  If this is not
        included then the Repl field must be included.

   o    Repl: NAPTR replacement field, should only be provided if the
        Regex field is not provided, otherwise it will be ignored by the
        addressing server.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.

   Table 14 defines the result codes and messages that the addNAPTRs
   operation SHOULD return.
















Cartwright, et al.       Expires August 28, 2008               [Page 60]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

          Table 14: addNAPTRs Operation Result Codes and Messages

4.4.2.8.  Operation Name:  addEgrRtes

   As described in the introductory sections, an Egress Route houses a
   rule that can be used for re-writing (modifying) the regular
   expressions housed in the NAPTRs associated with a Route object.  The
   addEgrRtes operation creates or overwrites one or more Egress Route
   objects in the addressing server.  If an Egress Route object with the
   same object ID does not exist within the context of the addressing
   server, then the ESPP Server MUST create the Egress route object.  If
   an Egress Route object with the same object ID does exist within the
   context of the addressing server, then the ESPP Server MUST replace
   the current properties of that Egress Route with the properties
   passed into the addEgrRtes operation.  If an Egress Routes with the
   given ID does exist, but was created by a client other than the one
   calling the addEgrRtes operation then the ESPP Server SHOULD reject
   the request with the appropriate error code, 2106.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:





Cartwright, et al.       Expires August 28, 2008               [Page 61]


Internet-Draft                ESPP Protocol                February 2008


     <wsdl:operation name="addEgrRtes">
       <wsdl:input message="addEgrRtesRqstMsg"/>
       <wsdl:output message="cmnRspnsMsg"/>
     </wsdl:operation>

     <wsdl:message name="addEgrRtesRqstMsg">
       <wsdl:part name="rqst" element="est:addEgrRtesRqst"/>
     </wsdl:message>

     <wsdl:message name="cmnRspnsMsg">
       <wsdl:part name="rspns" element="est:cmnRspns"/>
     </wsdl:message>


   Inputs to the operation are wrapped in the addEgrRtesRqst object,
   which is declared as follows:


   <element name="addEgrRtesRqst">
     <complexType>
       <sequence>
         <element name="basicRqst" type="est:BasicRqstType"/>
         <element name="egrRte" type="est:EgrRteType"
                                      maxOccurs="unbounded"/>
       </sequence>
     </complexType>
   </element>


   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1 General Protocol Concepts
   for a detailed description of this data element.  Also required is
   one or more EgrRteType objects.  Any limitation on the maximum number
   of Egress Routes that may be passed into a call to the addEgrRtes
   operation is a policy decision and is not limited by the protocol.

   An Egress Route object is declared as follows:














Cartwright, et al.       Expires August 28, 2008               [Page 62]


Internet-Draft                ESPP Protocol                February 2008


   <complexType name="EgrRteType">
      <sequence>
        <element name="oid" type="est:OIdType"/>
        <element name="eid" type="est:EIdType"/>
        <element name="rteId" type="est:OIdType" minOccurs="0"
                 maxOccurs="unbounded"/>
        <element name="pref" type="unsignedShort"/>
        <element name="svcs" type="string" minOccurs="0"/>
        <element name="regxRewriteRule" type="string"/>
        <element name="ext" type="est:ExtAnyType"
                 minOccurs="0"/>
      </sequence>
   </complexType>


   The EgrRteType object is comprised of the data elements that are
   necessary to for a an Egress Route.  Each data element is described
   as follows:

   o    oId: Exactly one object ID to uniquely identify the object
        instance.  This identifier is also an input to the delEgrRtes
        and getEgrRtes operations to identify a given Egress Route.

   o    Eid: Exactly one enterprise ID that uniquely identifies the
        operational entity within the call routing community that is
        responsible for or "own" this object.

   o    Order: Relative order value in an ENUM NAPTR.

   o    RteId: Zero or more Routes to which this Egress Route applies.
        The ESPP Server MUST reject, with the appropriate error response
        code, an attempt to create an Egress Route object containing a
        Route ID that does not exist within the appropriate context of
        the addressing server.

   o    Pref: Relative preference value of the Egress Route with respect
        to other Egress Routes associated with the same Route object.

   o    Svcs: ENUM service(s) to which this Egress Route's
        regxRewriteRule should be applied.  This field's value must be
        of the form specified in RFC 3761 (e.g., E2U+pstn:sip+sip).

   o    RegexRewriteRule: A regular expression that is applied to the
        Regx field of a NAPTR.

   o    Ext: Point of extensibility described in Section 4.4.1.9 of this
        document.




Cartwright, et al.       Expires August 28, 2008               [Page 63]


Internet-Draft                ESPP Protocol                February 2008


   Table 15 defines the result codes and messages that the addEgrRtes
   operation SHOULD return.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

         Table 15: addEgrRtes Operation Result Codes and Messages

4.4.2.9.  Delete Operations

   This sub-section defines the delete operations (i.e. delRtes,
   delSvcAreas, delPubIds, delPvtIds, delTNRs, delLRNs, delNAPTRs,
   delEgrRtes).  All delete operations are of the same design and the
   delRtes operation is used here for illustration.  The delete
   operations delete one or more existing objects from the addressing
   server.  If an object of the indicated type with the given ID exists,
   then the operation must delete that object.  If such an object does
   not exist, then the ESPP Server MUST return the appropriate error
   response code.  If an object with the given ID does exist, but was
   created by a client other than the one calling the delete operation
   then the ESPP Server SHOULD reject the request with the appropriate
   error code, 2106.

   In keeping with the Document Literal Wrapped design approach



Cartwright, et al.       Expires August 28, 2008               [Page 64]


Internet-Draft                ESPP Protocol                February 2008


   described in the introductory sections, the WSDL declaration of the
   operation is as:


   <wsdl:operation name="delRtes">
        <wsdl:input message="delRtesRqstMsg"/>
        <wsdl:output message="cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="delRtesRqstMsg">
        <wsdl:part name="rqst" element="est:delRtesRqst"/>
   </wsdl:message>



   Inputs to the operation are wrapped in the delRtesRqst object, which
   is declared as follows:


   <element name="delRtesRqst">
        <complexType>
          <sequence>
             <element name="basicRqst" type="est:
                  BasicRqstType"/>
             <element name="oid" type="est:OIdType"
                  maxOccurs="unbounded"/>
          </sequence>
        </complexType>
   </element>



   As with all update operations, the basicRqst data element is a
   required input.  Refer to the Section 4.4.1 General Protocol Concepts
   for a detailed description of this data element.  Also required is
   one or more object IDs that identify the objects that the addressing
   server is to delete.  Any limitation on the maximum number object IDs
   that may be passed into this operation is a policy decision and not
   limited by the protocol.  It is the responsibility of the ESPP Server
   to maintain referential integrity when an object is deleted.  The
   following rules apply to the delete operations:

   It is the responsibility of the ESPP Server to maintain referential
   integrity when an object is deleted.  The following rules apply to
   the delete operations:

   o  The ESPP Server SHOULD NOT allow an object created by a client
      having a given client ID to be deleted by a client having a



Cartwright, et al.       Expires August 28, 2008               [Page 65]


Internet-Draft                ESPP Protocol                February 2008


      different client ID.

   o  The ESPP Server MUST delete all LRNs and TNRanges within a Service
      Area that is being deleted, but only if those objects also belong
      to the client ID performing the deletion.  The ESPP Server MUST
      delete all Public Identity instances linked with a Service Area,
      but only if a Public Identity instance is not directly associated
      with one or more NAPTR objects or if the Public Identity was
      created by the client ID that created that object.

   o  When an object is deleted within an ESPP Server, the ESPP Server
      must automatically remove any references to that object that may
      exist within objects created by any client IDs within that ESPP
      Server.  For example, if a Route object "ABC" that was created by
      Client ID "123" is referred to by Egress Route "GHI" that was
      created by client ID "678", then when Route "ABC" is deleted by
      client "123" the ESPP Server MUST also automatically remove the
      reference to Route "ABC" from Egress Route "GHI", or any other
      Egress Routes.  This rule applies to the relationships between
      Routes and Service Areas, Egress Routes and Routes, Routes and
      NAPTRs, Public Identities and Private Identities, and Public
      Identities and NAPTRs.

   Table 16 defines the result codes and messages that these delete
   operations SHOULD return.


























Cartwright, et al.       Expires August 28, 2008               [Page 66]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

      Table 16: delRtes, delSvcAreas, delPubIds, delPvtIds, delTNRs,
    delLRNs, delNAPTRs, delEgrRtes Operation Result Codes and Messages

4.4.2.10.  Get Operations

   This sub-section defines the get, or query, operations (i.e. getRtes,
   getSvcAreas, getPubIds, getPvtIds, getTNRs, getLRNs, getNAPTRs,
   getEgrRtes).  All get operations are of the same design and the
   getRtes operation is used here for illustration.  If an object of the
   indicated type with the given ID exists, then the ESPP Server MUST
   return that object.  If such an object does not exist, the ESPP
   Server MUST NOT return an object.  An empty result set MUST NOT
   result in an error code response.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   getRtes operation is as follows:







Cartwright, et al.       Expires August 28, 2008               [Page 67]


Internet-Draft                ESPP Protocol                February 2008


   <wsdl:operation name="getRtes">
        <wsdl:input message="getRtesRqstMsg"/>
        <wsdl:output message="getRtesRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="getRtesRqstMsg">
        <wsdl:part name="rqst" element="est:getRtesRqst"/>
   </wsdl:message>

   <wsdl:message name="getRtesRspnsMsg">
        <wsdl:part name="rspns" element="est:getRtesRspns"/>
   </wsdl:message>




   Inputs to the operation are wrapped in the getRtesRqst object, which
   is declared as follows:


   <element name="getRtesRqst">
      <complexType>
        <sequence>
          <element name="basicRqst"
                  type="est:BasicQueryType"/>
          <element name="oid" type="est:OIdType"
                  minOccurs="0" maxOccurs="unbounded"/>
          <element name="eid" type="est:EIdType"
                  minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </complexType>
   </element>

   <complexType name="BasicQueryType">
        <sequence>
            <element name="clientId" type="est:ClientIdType"/>
            <element name="minorVer" type="est:VerType"/>
            <element name="ext" type="est:ExtAnyType"
              minOccurs="0"/>
        </sequence>
   </complexType>




   The required input is one BasicQueryType object and one or more
   object IDs that the addressing server is to return and/or one or more
   enterprise IDs for which the addressing server should return all



Cartwright, et al.       Expires August 28, 2008               [Page 68]


Internet-Draft                ESPP Protocol                February 2008


   objects of the given type.  The list of object IDs and enterprise IDs
   MUST be considered "or" criteria, find objects of the given type that
   have these object IDs or that belong to the given enterprise IDs.
   Stated another way, the addressing server is to return the objects
   that have any of the given object IDs and return the objects that
   have any of the given enterprise IDs.  Any limitation on the maximum
   number of objects that may be passed into or returned by this
   operation is a policy decision and not limited by the protocol.
   Notice that the get operations are the only operations that do not
   accept a BasicRqstType object as input.  Rather, a BasicQueryType
   object is required.  This results from the fact that passing a
   transaction ID into a get operation is not necessary and would be
   inefficient.  The BasicQueryType object only contains the mandatory
   version identifier and the optional extensibility element.

   Results of the operation are wrapped in the getRtesRspns object,
   which is declared as follows:


   <element name="getRtesRspns">
       <complexType>
        <sequence>
            <element name="rte" type="est:RteType"
                minOccurs="0" maxOccurs="unbounded"/>
            <element name="basicResult" type="est:
                BasicRspnsType"/>
        </sequence>
       </complexType>
   </element>



   The response includes the standard BasicRspnsType object and zero or
   more RteType objects, one for each object ID that matches a Route in
   the addressing server.

   Table 17 defines the result codes and messages that these get
   operations SHOULD return.













Cartwright, et al.       Expires August 28, 2008               [Page 69]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   +--------+----------------------------------------------------------+

      Table 17:  getRtes, getSvcAreas, getPubIds, getPvtIds, getTNRs,
    getLRNs, getNAPTRs, getEgrRtes Operation Result Codes and Messages

4.4.2.11.  Operation Name: addEntr

   Prior to attempting to add an object under a given an enterprise ID
   to an ESPP Server, the ESPP Client must create that enterprise ID in
   that ESPP Server using the addEntr operation.

   The addEntr operation creates an enterprise ID in the addressing
   server.  If an enterprise ID value of an addEntr operation does not
   exist, the ESPP Server MUST create the enterprise ID.  If an
   enterprise ID value of an addEntr operation already exists, the ESPP
   Server MUST return a success response.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="addEntr">
        <wsdl:input message="esp:addEntrRqstMsg"/>
        <wsdl:output message="esp:cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="addEntrRqstMsg">
        <wsdl:part name="rqst" element="est:addEntrRqst"/>
   </wsdl:message>





Cartwright, et al.       Expires August 28, 2008               [Page 70]


Internet-Draft                ESPP Protocol                February 2008


   Inputs to the operation are wrapped in the addEntrRqst object, which
   is declared as follows:


   <element name="addEntrRqst">
        <complexType>
           <sequence>
             <element name="basicRqst" type="est:
                       BasicRqstType"/>
             <element name="eId" type="est:EIdType"/>
           </sequence>
        </complexType>
   </element>



   As with all update operations, the basicRqst data element is a
   required input.  Refer to Section 4.4.1, for a detailed description
   of this data element.  Also required is one enterprise ID.

   Table 18 defines the result codes and messages that the addEntr
   operation SHOULD return.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   +--------+----------------------------------------------------------+

           Table 18: addEntr Operation Result Codes and Messages






Cartwright, et al.       Expires August 28, 2008               [Page 71]


Internet-Draft                ESPP Protocol                February 2008


4.4.2.12.  Operation Name: modEntr

   Modification of an enterprise ID by one ESPP Client must not impact
   objects created by another ESPP Client.  In other words only objects
   created by the client modifying the enterprise ID MUST be moved to
   the new enterprise ID as part of processing the modEntr operation.
   Any objects created by a different ESPP Client must remain in their
   existing enterprise ID.

   The modEntr operation modifies an existing enterprise ID in the
   addressing server.  If the "old" enterprise ID being modified does
   exist then the ESPP Server MUST replace the current enterprise ID
   with the "new" enterprise ID.  If the "old" enterprise ID does not
   exist then the ESPP Server MUST return the appropriate error code.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="modEntr">
        <wsdl:input message="esp:modEntrRqstMsg"/>
        <wsdl:output message="esp:cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="modEntrRqstMsg">
        <wsdl:part name="rqst" element="est:modEntrRqst"/>
   </wsdl:message>



   Inputs to the operation are wrapped in the modEntrRqst object, which
   is declared as follows:


   <element name="modEntrRqst">
       <complexType>
        <sequence>
          <element name="basicRqst" type="est:
                       BasicRqstType"/>
          <element name="newEId" type="est:EIdType"/>
          <element name="oldEId" type="est:EIdType"/>
        </sequence>
       </complexType>
   </element>






Cartwright, et al.       Expires August 28, 2008               [Page 72]


Internet-Draft                ESPP Protocol                February 2008


   As with all update operations, the basicRqst data element is a
   required input.  Refer to Section 4.4.1, for a detailed description
   of this data element.  Also required is one "new" enterprise ID and
   one "old" enterprise ID.

   Table 19 defines the result codes and messages that the modEntr
   operation SHOULD return.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   +--------+----------------------------------------------------------+

          Table 19:  modEntr Operation Result Codes and Messages

4.4.2.13.  Operation Name: delEntr

   The delEntr operation deletes the enterprise ID and all objects from
   an addressing server that have the given enterprise ID and that were
   created by the client that is deleting the enterprise ID.  If the
   enterprise ID does not exist in the addressing server, then the ESPP
   Server MUST return a success response (an error message MUST NOT be
   returned).

   Deletion of an enterprise ID by one ESPP Client MUST NOT impact
   objects created by another ESPP Client.  In other words only objects
   created by the client deleting the enterprise ID MUST be deleted.
   Any objects created by a different ESPP Client MUST NOT be deleted
   and MUST remain in their existing enterprise ID.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the



Cartwright, et al.       Expires August 28, 2008               [Page 73]


Internet-Draft                ESPP Protocol                February 2008


   operation is as follows:


   <wsdl:operation name="delEntr">
        <wsdl:input message="delEntrRqstMsg"/>
        <wsdl:output message="cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="delEntrRqstMsg">
        <wsdl:part name="rqst" element="est:delEntrRqst"/>
   </wsdl:message>



   Inputs to the operation are wrapped in the delEntrRqst object, which
   is declared as follows:


   <element name="delEntrRqst">
       <complexType>
        <sequence>
           <element name="basicRqst" type="est:
                  BasicRqstType"/>
           <element name="eId" type="est:EIdType"/>
        </sequence>
       </complexType>
   </element>




   As with all update operations, the basicRqst data element is a
   required input.  Refer to Section 4.4.1, for a detailed description
   of this data element.  Also required is one enterprise ID.

   Table 20 defines the result codes and messages that the delEntr
   operation SHOULD return.














Cartwright, et al.       Expires August 28, 2008               [Page 74]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   +--------+----------------------------------------------------------+

           Table 20: delEntr Operation Result Codes and Messages

4.4.2.14.  Operation Name: batchUpdate

   The batchUpdate operation is a single operation, with a single
   transaction ID that may contain one or more of any of the previously
   defined operation request objects.  This approach can significantly
   speed processing time under some circumstances by allowing multiple
   operations to be transmitted and performed under a single transaction
   ID, and a single connection.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:


   <wsdl:operation name="batchUpdate">
        <wsdl:input message="batchUpdateRqstMsg"/>
        <wsdl:output message="cmnRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="batchUpdateRqstMsg">
        <wsdl:part name="rqst" element="est:batchUpdateRqst"/>
   </wsdl:message>

   <wsdl:message name="cmnRspnsMsg">
        <wsdl:part name="rspns" element="est:cmnRspns"/>



Cartwright, et al.       Expires August 28, 2008               [Page 75]


Internet-Draft                ESPP Protocol                February 2008


   </wsdl:message>


   Inputs to the operation are wrapped in the batchUpdateRqst object,
   which is declared as follows:


   <element name="batchUpdateRqst">
      <complexType>
        <sequence>
           <element name="basicRqst" type="est:
                  BasicRqstType"/>
           <element name="batchUpdate" type="est:
                  BatchUpdateType"/>
        </sequence>
      </complexType>
   </element>

   <complexType name="BatchUpdateType">
        <sequence>
         <element name="op" type="est:BatchOpType"
                  maxOccurs="unbounded"/>
        </sequence>
   </complexType>

   <complexType name="BatchOpType">
       <sequence>
        <element name="naptrDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="naptrAdd" type="est:NAPTRType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="egrRteDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="egrRteAdd" type="est:EgrRteType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="rteDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="rteAdd" type="est:RteType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="saDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="saAdd" type="est:SvcAreaType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="pviDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="pviAdd" type="est:PvtIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="piDel" type="est:OIdType"



Cartwright, et al.       Expires August 28, 2008               [Page 76]


Internet-Draft                ESPP Protocol                February 2008


             minOccurs="0" maxOccurs="unbounded"/>
        <element name="piAdd" type="est:PubIdType"
             minOccurs="0" maxOccurs="unbounded"/>
       <element name="tnRDel" type="est:OIdType"
           minOccurs="0" maxOccurs="unbounded"/>
       <element name="tnRAdd" type="est:TNRType"
             minOccurs="0" maxOccurs="unbounded"/>
       <element name="lrnDel" type="est:OIdType"
             minOccurs="0" maxOccurs="unbounded"/>
       <element name="lrnAdd" type="est:LRNType"
             minOccurs="0" maxOccurs="unbounded"/>
       <element name="entrDel" type="est:EIdType"
             minOccurs="0" maxOccurs="unbounded"/>
       <element name="entrAdd" type=" est:EIdType"
             minOccurs="0" maxOccurs="unbounded"/>
        <element name="entrMod" minOccurs="0"
             maxOccurs="unbounded">
             <complexType>
                 <sequence>
                  <element name="newEId"
                       type="est:EIdType"/>
                  <element name="oldEId"
                       type="est:EIdType"/>
                      </sequence>
                  </complexType>
             </element>
        </sequence>
   </complexType>


   The BatchUpdateType object can contain one or more BatchOpType
   objects.  The structure is nested here to allow multiple
   BatchUpdateType objects to be included in any order that is
   appropriate to achieve the desired end goal of the batch operation.
   More specifically, this structure works around the strict ordering
   rules imposed on the XSD "sequence" data structure, allowing adds and
   dels to occur in any order.  The ESPP Server MUST process the sub-
   elements of the batchUpdate and the op elements in the order in which
   they appear in the batchUpdateRqst element.  As with all update
   operations, the basicRqst data element is a required input.  Refer to
   Section 4.4.1, for a detailed description of this data element.  Each
   of the remaining elements are simply zero or more instances of the
   top level data structures that are wrapped in each of the other
   update operations described in previous sections.

   Table 21 defines the result codes and messages that the batchUpdate
   operation SHOULD return.




Cartwright, et al.       Expires August 28, 2008               [Page 77]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+

         Table 21: batchUpdate Operation Result Codes and Messages

4.4.2.15.  Operation Name: getSvcMenu

   The getSvcMenu operation returns a list of operations supported by
   the ESPP Server and the protocol versions supported by the ESPP
   Server.  The list of operations is comprised of a list or URNs, one
   for each supported operation.  This feature can be used by ESPP
   Clients to dynamically discover which operations and versions are
   supported by the ESPP Servers.

   In keeping with the Document Literal Wrapped design approach
   described in the introductory sections, the WSDL declaration of the
   operation is as follows:










Cartwright, et al.       Expires August 28, 2008               [Page 78]


Internet-Draft                ESPP Protocol                February 2008


   <wsdl:operation name="getSvcMenu">
     <wsdl:input message="esp:getSvcMenuRqstMsg"/>
     <wsdl:output message="esp:getSvcMenuRspnsMsg"/>
   </wsdl:operation>

   <wsdl:message name="getSvcMenuRqstMsg">
     <wsdl:part name="rqst" element="est:getSvcMenuRqst"/>
   </wsdl:message>

   <wsdl:message name="getSvcMenuRspnsMsg">
     <wsdl:part name="rspns" element="est:getSvcMenuRspns"/>
   </wsdl:message>



   Inputs to the operation are wrapped in the getSvcMenuRqst object,
   which is declared as follows:


   <element name="getSvcMenuRqst">
       <complexType>
        <sequence>
           <element name="basicRqst" type="est:
                   BasicQueryType"/>
        </sequence>
       </complexType>
   </element>



   The required input is one BasicQueryType and the results of the
   operation are wrapped in the getRtesRspns object, which is declared
   as follows:


















Cartwright, et al.       Expires August 28, 2008               [Page 79]


Internet-Draft                ESPP Protocol                February 2008


   <element name="getSvcMenuRspns">
      <complexType>
        <sequence>
        <element name="svcMenu" type="est:
                  SvcMenuType"/>
        <element name="basicResult" type="
             est:BasicRspnsType"/>
        </sequence>
      </complexType>
   </element>

   <complexType name="SvcMenuType">
       <sequence>
          <element name="majMinVersion" type="string"
                maxOccurs="unbounded"/>
          <element name="objURI" type="anyURI"
             maxOccurs="unbounded"/>
          <element name="extURI" type="anyURI"
                minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
   </complexType>




   The response includes the standard BasicRspnsType object and one
   SvcMenyType objects.  The SvcMenuType contains the following
   elements:

   o  MajMinVersion: One or more version identifiers in dotted notation,
      where each version identifier represents a fully qualified version
      identifier that is supported by the ESPP Server.

   o  ObjUri: One or more URI(s) where each URI identifies one ESPP
      operation that is supported by the ESPP Server.  URIs take the
      following form: urn:packetcable:espp:api-1.0:est:addRtesRqst

   o  ExtUri: One or more URI(s) where each URI identifies an operation
      that is not part of the formal ESPP specification but is supported
      by the ESPP Server.  This may arise where an ESPP Server has added
      non-standard operations to its ESPP implementation.

   Table 22 defines the result codes and messages that the getSvcMenu
   operation SHOULD return.







Cartwright, et al.       Expires August 28, 2008               [Page 80]


Internet-Draft                ESPP Protocol                February 2008


   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   +--------+----------------------------------------------------------+

         Table 22: getSvcMenu Operation Result Codes and Messages




































Cartwright, et al.       Expires August 28, 2008               [Page 81]


Internet-Draft                ESPP Protocol                February 2008


5.  File-based ESPP provisioning protocol

   To further support the high data distribution requirements of the
   target reference architecture, the ESPP specification defines a file
   based operational scheme.  Some aspects of this scheme are policy
   driven and are, therefore, outside the scope of this document.  The
   file-based provisioning protocol requirements defined in this section
   MUST be supported by an ESPP Client and an ESPP Server to claim
   compliance with this specification.  They must be used in the
   following manner to support file base data distribution.

5.1.  Overview of the File-based Provisioning Operations

   Under certain circumstances, such as bootstrapping a new ENUM-SIP
   addressing server with its initial data set, or establishing a new
   session peering relationship between two peers, it may be advisable
   to distribute peering data in the form of a file.  To accomplish
   this, the ESPP Client MUST have the ability to, on command, generate
   a set of files containing all the session establishment data residing
   within the ESPP Client view for a given session peering partner.
   Similarly, the ESPP Server MUST support the ability to read, parse,
   and load the content of that file into the appropriate context of the
   ENUM-SIP addressing server.  The process of retrieving that file from
   the ESPP Client (acting as a file server) and then delivering the
   file to the proper location on the ENUM-SIP addressing server is a
   matter of policy and procedure and it is not specified in this
   document.  The process of suspending real-time provisioning
   operations (non-file-based) during this file-based provisioning
   process is also a matter of policy and procedure.

5.2.  File Structure

   An ESPP compliant distribution file MUST be comprised of exactly one
   batchUpdateFileRqst element which contains one
   BatchUpdateFilePropsType object and one or more BatchUpdateType
   objects, which is described in a previous section of this document.
   This approach is taken to simplify the implementation effort for this
   feature as the ESPP Client and the ESPP Server have the ability to
   process the data structures that comprise the batchUpdateFileRqst.
   To ensure data consistency, the ESPP Client must generate batch files
   using the same transaction identifier sequence as the real time
   protocol.  It is therefore necessary to disable real-time propagation
   while the file-based provisioning process is active.








Cartwright, et al.       Expires August 28, 2008               [Page 82]


Internet-Draft                ESPP Protocol                February 2008


   <element name="batchUpdateFileRqst">
     <complexType>
       <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="batchUpdateFileProps"
           type="est:BatchUpdateFilePropsType"/>
        <element name="batchUpdate" type="est:BatchUpdateType"
           maxOccurs="unbounded"/>
       </sequence>
     </complexType>
   </element>


   The BatchUpdateFilePropsType is the file header that specifies some
   basic information about where and when the batch update file(s) were
   generated.  A given batch update may span multiple files, with the
   BatchUpdateFilePropsType object in each file.


   <complexType name="BatchUpdateFilePropsType">
       <sequence>
        <element name="clientId" type="est:ClientIdType"/>
        <element name="serverId" type="string"/>
        <element name="isFullResync" type="boolean"/>
        <element name="creationTimestamp" type="dateTime"/>
        <element name="sequenceNumber" type="string"/>
        <element name="isEndOfSequence" type="boolean"/>
      </sequence>
   </complexType>


   o    clientId - The integer that identifies the ESPP Client that
        generated the batch file(s).

   o    serverId - A string that identifies the ESPP Server for which
        the batch file(s) were generated.

   o    isFullResync - Indicates if this sequence of files is a full
        refresh of all the data that should reside within an addressing
        server.  If not, then the file sequence represents an
        incremental update.  The addressing server MUST properly apply
        the data based on the value of this attribute.  This may entail
        dropping the current data in the addressing server.

   o    creationTimestamp - The creation timestamp for the batch load
        file sequence MUST follow the format defined by the dateTime
        datatype of XML Schema Part 2 and MUST contain the time zone
        information.  For example, a valid format can be represented as



Cartwright, et al.       Expires August 28, 2008               [Page 83]


Internet-Draft                ESPP Protocol                February 2008


        YYYY-MM-DDTHH:MM:SS('+'|'-')hh':'mm).

   o    sequenceNumber - The sequence number for this batch file within
        the batch update.  An ESPP Client may generate multiple batch
        files that, as a set, represent the entire batch update.  The
        sequenceNumber is a sequential number, starting with 1 and
        incremented by 1 for each subsequent file.

   o    isEndOfSequence - A boolean value indicating whether or not this
        is that last file in the sequence of files that comprise the
        batch update.


   The ESPP Server SHOULD log error codes that correspond to the codes
   used in the real time protocol as defined in Section 4.4.1.8.




































Cartwright, et al.       Expires August 28, 2008               [Page 84]


Internet-Draft                ESPP Protocol                February 2008


6.  Response Codes and Messages

   This section contains the consolidated listing of the response codes
   and their corresponding messages.

   The response code numbering scheme generally adheres to the theory
   formalized in section 4.2.1 of [RFC2821]:

   o    The first digit of the response code can only be 1 or 2: 1 = a
        positive result, 2 = a negative result.

   o    The second digit of the response code indicates the category: 0
        = Protocol Syntax, 1 = Implementation Specific Business Rule, 2
        = Security, 3 = Server System.

   o    The third and fourth digits of the response code indicate the
        individual message event within the category defines by the
        first two digits.

   +--------+----------------------------------------------------------+
   | Result | Text                                                     |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | Request Succeeded.                                       |
   |        |                                                          |
   | 2001   | Request syntax invalid.                                  |
   |        |                                                          |
   | 2002   | Request too large.                                       |
   |        |                                                          |
   | 2003   | Version not supported.                                   |
   |        |                                                          |
   |        |                                                          |
   |        |                                                          |
   | 2301   | System temporarily unavailable.                          |
   |        |                                                          |
   | 2103   | Transaction ID out of sequence: [transaction ID          |
   |        | received]:[ transaction ID expected].                    |
   |        |                                                          |
   | 2104   | Attribute value invalid: [attribute name]:[attribute     |
   |        | value]:[objectType-objectId].                            |
   |        |                                                          |
   | 2105   | Object does not exist: [attribute name]:[                |
   |        | objectType-objectId].                                    |
   |        |                                                          |
   | 2106   | Object status or ownership does not allow for request:   |
   |        | [request name]:[ attributeName]:[objectType-objectId].   |
   +--------+----------------------------------------------------------+




Cartwright, et al.       Expires August 28, 2008               [Page 85]


Internet-Draft                ESPP Protocol                February 2008


          Table 23: Response Codes Numbering Scheme and Messages

   Some response messages are "parameterized" with one or more of the
   following parameters: "attribute name", "attribute value",
   "objectType-objectId", and "operation name".

   The use of these parameters MUST adhere to the following rules:

   o    All parameters within a response message are mandatory and MUST
        be present.  Parameters within a response message MUST NOT be
        left empty.

   o    Any value provided for the "attribute name" parameter MUST be an
        exact element name of the protocol data element that the
        response message is referring to.  For example, allowable values
        for "attribute name" are "tnRStrt", "rteName", etc.

   o    Any value provided for the "request name" parameter MUST be an
        exact request object name that the response message is referring
        to.  For example, an allowable value for "request object name"
        is "delRtesRqst".

   o    The value for "attribute value" MUST be the value of the data
        element to which the preceding "attribute name" refers.

   o    Result codes 2104 and 2105 MUST NOT be used interchangeably.
        Response code 2105 SHOULD be returned when the data element(s)
        used to uniquely identify a pre-existing object do not exist.
        If the data elements used to uniquely identify an object are
        malformed, then response code 2104 SHOULD be returned.

   o    Result code 2104 SHOULD be used whenever an element value does
        not adhere to data validation rules.  It MUST be used for
        circumstances where an optional data element was expected but
        not received.
















Cartwright, et al.       Expires August 28, 2008               [Page 86]


Internet-Draft                ESPP Protocol                February 2008


7.  IANA Considerations

   Should there be interest in working on a protocol like ESPP in IETF,
   a formal IANA consideration section should be drafted with proper
   registrations for the protocol namespace(s), versions, etc.














































Cartwright, et al.       Expires August 28, 2008               [Page 87]


Internet-Draft                ESPP Protocol                February 2008


8.  Formal API Definition

   Note that the formal API definition is currently provided as defined
   in the PacketCable specifications for the XML namespace and protocol
   versioning conventions.

8.1.  WSDL Specification


   <wsdl:definitions xmlns:esp="urn:packetcable:espp:api-1.0"
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:est="urn:packetcable:espp:types-1.0"
   targetNamespace="urn:packetcable:espp:api-1.0">
     <wsdl:types>
       <xsd:schema targetNamespace="urn:packetcable:espp:api-1.0"
   xmlns:esp="urn:packetcable:espp:api-1.0"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
         <xsd:import namespace="urn:packetcable:espp:types-1.0"
   schemaLocation="espptypes.xsd"/>
       </xsd:schema>
     </wsdl:types>
     <wsdl:message name="addRtesRqstMsg">
       <wsdl:part name="rqst" element="est:addRtesRqst"/>
     </wsdl:message>
     <wsdl:message name="addSvcAreasRqstMsg">
       <wsdl:part name="rqst" element="est:addSvcAreasRqst"/>
     </wsdl:message>
     <wsdl:message name="addPubIdsRqstMsg">
       <wsdl:part name="rqst" element="est:addPubIdsRqst"/>
     </wsdl:message>
     <wsdl:message name="addTNRsRqstMsg">
       <wsdl:part name="rqst" element="est:addTNRsRqst"/>
     </wsdl:message>
     <wsdl:message name="addPvtIdsRqstMsg">
       <wsdl:part name="rqst" element="est:addPvtIdsRqst"/>
     </wsdl:message>
     <wsdl:message name="addLRNsRqstMsg">
       <wsdl:part name="rqst" element="est:addLRNsRqst"/>
     </wsdl:message>
     <wsdl:message name="addNAPTRsRqstMsg">
       <wsdl:part name="rqst" element="est:addNAPTRsRqst"/>
     </wsdl:message>
     <wsdl:message name="addEgrRtesRqstMsg">
       <wsdl:part name="rqst" element="est:addEgrRtesRqst"/>



Cartwright, et al.       Expires August 28, 2008               [Page 88]


Internet-Draft                ESPP Protocol                February 2008


     </wsdl:message>
     <wsdl:message name="addEntrRqstMsg">
       <wsdl:part name="rqst" element="est:addEntrRqst"/>
     </wsdl:message>
     <wsdl:message name="batchUpdateRqstMsg">
       <wsdl:part name="rqst" element="est:batchUpdateRqst"/>
     </wsdl:message>
     <wsdl:message name="getRtesRqstMsg">
       <wsdl:part name="rqst" element="est:getRtesRqst"/>
     </wsdl:message>
     <wsdl:message name="getSvcAreasRqstMsg">
       <wsdl:part name="rqst" element="est:getSvcAreasRqst"/>
     </wsdl:message>
     <wsdl:message name="getPubIdsRqstMsg">
       <wsdl:part name="rqst" element="est:getPubIdsRqst"/>
     </wsdl:message>
     <wsdl:message name="getTNRsRqstMsg">
       <wsdl:part name="rqst" element="est:getTNRsRqst"/>
     </wsdl:message>
     <wsdl:message name="getPvtIdsRqstMsg">
       <wsdl:part name="rqst" element="est:getPvtIdsRqst"/>
     </wsdl:message>
     <wsdl:message name="getLRNsRqstMsg">
       <wsdl:part name="rqst" element="est:getLRNsRqst"/>
     </wsdl:message>
     <wsdl:message name="getNAPTRsRqstMsg">
       <wsdl:part name="rqst" element="est:getNAPTRsRqst"/>
     </wsdl:message>
     <wsdl:message name="getEgrRtesRqstMsg">
       <wsdl:part name="rqst" element="est:getEgrRtesRqst"/>
     </wsdl:message>
     <wsdl:message name="getSvcMenuRqstMsg">
       <wsdl:part name="rqst" element="est:getSvcMenuRqst"/>
     </wsdl:message>
     <wsdl:message name="delRtesRqstMsg">
       <wsdl:part name="rqst" element="est:delRtesRqst"/>
     </wsdl:message>
     <wsdl:message name="delSvcAreasRqstMsg">
       <wsdl:part name="rqst" element="est:delSvcAreasRqst"/>
     </wsdl:message>
     <wsdl:message name="delPubIdsRqstMsg">
       <wsdl:part name="rqst" element="est:delPubIdsRqst"/>
     </wsdl:message>
     <wsdl:message name="delTNRsRqstMsg">
       <wsdl:part name="rqst" element="est:delTNRsRqst"/>
     </wsdl:message>
     <wsdl:message name="delPvtIdsRqstMsg">
       <wsdl:part name="rqst" element="est:delPvtIdsRqst"/>



Cartwright, et al.       Expires August 28, 2008               [Page 89]


Internet-Draft                ESPP Protocol                February 2008


     </wsdl:message>
     <wsdl:message name="delLRNsRqstMsg">
       <wsdl:part name="rqst" element="est:delLRNsRqst"/>
     </wsdl:message>
     <wsdl:message name="delNAPTRsRqstMsg">
       <wsdl:part name="rqst" element="est:delNAPTRsRqst"/>
     </wsdl:message>
     <wsdl:message name="delEgrRtesRqstMsg">
       <wsdl:part name="rqst" element="est:delEgrRtesRqst"/>
     </wsdl:message>
     <wsdl:message name="delEntrRqstMsg">
       <wsdl:part name="rqst" element="est:delEntrRqst"/>
     </wsdl:message>
     <wsdl:message name="modEntrRqstMsg">
       <wsdl:part name="rqst" element="est:modEntrRqst"/>
     </wsdl:message>
     <wsdl:message name="cmnRspnsMsg">
       <wsdl:part name="rspns" element="est:cmnRspns"/>
     </wsdl:message>
     <wsdl:message name="getRtesRspnsMsg">
       <wsdl:part name="rspns" element="est:getRtesRspns"/>
     </wsdl:message>
     <wsdl:message name="getSvcAreasRspnsMsg">
       <wsdl:part name="rspns" element="est:getSvcAreasRspns"/>
     </wsdl:message>
     <wsdl:message name="getPubIdsRspnsMsg">
       <wsdl:part name="rspns" element="est:getPubIdsRspns"/>
     </wsdl:message>
     <wsdl:message name="getTNRsRspnsMsg">
       <wsdl:part name="rspns" element="est:getTNRsRspns"/>
     </wsdl:message>
     <wsdl:message name="getPvtIdsRspnsMsg">
       <wsdl:part name="rspns" element="est:getPvtIdsRspns"/>
     </wsdl:message>
     <wsdl:message name="getLRNsRspnsMsg">
       <wsdl:part name="rspns" element="est:getLRNsRspns"/>
     </wsdl:message>
     <wsdl:message name="getNAPTRsRspnsMsg">
       <wsdl:part name="rspns" element="est:getNAPTRsRspns"/>
     </wsdl:message>
     <wsdl:message name="getEgrRtesRspnsMsg">
       <wsdl:part name="rspns" element="est:getEgrRtesRspns"/>
     </wsdl:message>
     <wsdl:message name="getSvcMenuRspnsMsg">
       <wsdl:part name="rspns" element="est:getSvcMenuRspns"/>
     </wsdl:message>
     <wsdl:portType name="ESPPPortType">
       <wsdl:operation name="addRtes">



Cartwright, et al.       Expires August 28, 2008               [Page 90]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:input message="esp:addRtesRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delRtes">
         <wsdl:input message="esp:delRtesRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getRtes">
         <wsdl:input message="esp:getRtesRqstMsg"/>
         <wsdl:output message="esp:getRtesRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addSvcAreas">
         <wsdl:input message="esp:addSvcAreasRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delSvcAreas">
         <wsdl:input message="esp:delSvcAreasRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getSvcAreas">
         <wsdl:input message="esp:getSvcAreasRqstMsg"/>
         <wsdl:output message="esp:getSvcAreasRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addPubIds">
         <wsdl:input message="esp:addPubIdsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delPubIds">
         <wsdl:input message="esp:delPubIdsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getPubIds">
         <wsdl:input message="esp:getPubIdsRqstMsg"/>
         <wsdl:output message="esp:getPubIdsRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addTNRs">
         <wsdl:input message="esp:addTNRsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delTNRs">
         <wsdl:input message="esp:delTNRsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getTNRs">
         <wsdl:input message="esp:getTNRsRqstMsg"/>
         <wsdl:output message="esp:getTNRsRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addPvtIds">



Cartwright, et al.       Expires August 28, 2008               [Page 91]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:input message="esp:addPvtIdsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delPvtIds">
         <wsdl:input message="esp:delPvtIdsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getPvtIds">
         <wsdl:input message="esp:getPvtIdsRqstMsg"/>
         <wsdl:output message="esp:getPvtIdsRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addLRNs">
         <wsdl:input message="esp:addLRNsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delLRNs">
         <wsdl:input message="esp:delLRNsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getLRNs">
         <wsdl:input message="esp:getLRNsRqstMsg"/>
         <wsdl:output message="esp:getLRNsRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addNAPTRs">
         <wsdl:input message="esp:addNAPTRsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delNAPTRs">
         <wsdl:input message="esp:delNAPTRsRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getNAPTRs">
         <wsdl:input message="esp:getNAPTRsRqstMsg"/>
         <wsdl:output message="esp:getNAPTRsRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addEgrRtes">
         <wsdl:input message="esp:addEgrRtesRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delEgrRtes">
         <wsdl:input message="esp:delEgrRtesRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getEgrRtes">
         <wsdl:input message="esp:getEgrRtesRqstMsg"/>
         <wsdl:output message="esp:getEgrRtesRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="batchUpdate">



Cartwright, et al.       Expires August 28, 2008               [Page 92]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:input message="esp:batchUpdateRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="addEntr">
         <wsdl:input message="esp:addEntrRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="modEntr">
         <wsdl:input message="esp:modEntrRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="delEntr">
         <wsdl:input message="esp:delEntrRqstMsg"/>
         <wsdl:output message="esp:cmnRspnsMsg"/>
       </wsdl:operation>
       <wsdl:operation name="getSvcMenu">
         <wsdl:input message="esp:getSvcMenuRqstMsg"/>
         <wsdl:output message="esp:getSvcMenuRspnsMsg"/>
       </wsdl:operation>
     </wsdl:portType>
     <wsdl:binding name="ESPPSoapBinding" type="esp:ESPPPortType">

     <soap:binding style="document"
       transport="http://schemas.xmlsoap.org/soap/http"/>

       <wsdl:operation name="addRtes">
         <soap:operation soapAction="addRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delRtes">
         <soap:operation soapAction="delRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getRtes">
         <soap:operation soapAction="getRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>



Cartwright, et al.       Expires August 28, 2008               [Page 93]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addSvcAreas">
         <soap:operation soapAction="addSvcAreas" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delSvcAreas">
         <soap:operation soapAction="delSvcAreas" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getSvcAreas">
         <soap:operation soapAction="getSvcAreas" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addPubIds">
         <soap:operation soapAction="addPubIds" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delPubIds">
         <soap:operation soapAction="delPubIds" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>



Cartwright, et al.       Expires August 28, 2008               [Page 94]


Internet-Draft                ESPP Protocol                February 2008


       </wsdl:operation>
       <wsdl:operation name="getPubIds">
         <soap:operation soapAction="getPubIds" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addTNRs">
         <soap:operation soapAction="addTNRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delTNRs">
         <soap:operation soapAction="delTNRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getTNRs">
         <soap:operation soapAction="getTNRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addPvtIds">
         <soap:operation soapAction="addPvtIds" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delPvtIds">
         <soap:operation soapAction="delPvtIds" style="document"/>



Cartwright, et al.       Expires August 28, 2008               [Page 95]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getPvtIds">
         <soap:operation soapAction="getPvtIds" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addLRNs">
         <soap:operation soapAction="addLRNs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delLRNs">
         <soap:operation soapAction="delLRNs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getLRNs">
         <soap:operation soapAction="getLRNs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addNAPTRs">
         <soap:operation soapAction="addNAPTRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>



Cartwright, et al.       Expires August 28, 2008               [Page 96]


Internet-Draft                ESPP Protocol                February 2008


         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delNAPTRs">
         <soap:operation soapAction="delNAPTRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getNAPTRs">
         <soap:operation soapAction="getNAPTRs" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addEgrRtes">
         <soap:operation soapAction="addEgrRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delEgrRtes">
         <soap:operation soapAction="delEgrRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getEgrRtes">
         <soap:operation soapAction="getEgrRtes" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>



Cartwright, et al.       Expires August 28, 2008               [Page 97]


Internet-Draft                ESPP Protocol                February 2008


       </wsdl:operation>
       <wsdl:operation name="batchUpdate">
         <soap:operation soapAction="batchUpdate" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="addEntr">
         <soap:operation soapAction="addEntr" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="modEntr">
         <soap:operation soapAction="modEntr" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="delEntr">
         <soap:operation soapAction="delEntr" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
       <wsdl:operation name="getSvcMenu">
         <soap:operation soapAction="getSvcMenu" style="document"/>
         <wsdl:input>
           <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal"/>
         </wsdl:output>
       </wsdl:operation>
     </wsdl:binding>
     <wsdl:service name="ESPPService">



Cartwright, et al.       Expires August 28, 2008               [Page 98]


Internet-Draft                ESPP Protocol                February 2008


       <wsdl:port name="ESPPPort" binding="esp:ESPPSoapBinding">
         <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
       </wsdl:port>
     </wsdl:service>
   </wsdl:definitions>


8.2.  XSD Types Specification


<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:est="urn:packetcable:espp:types-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:packetcable:espp:types-1.0"
       elementFormDefault="qualified" xml:lang="EN">
  <annotation>
    <documentation>
    -------- Object Type Definitions  ----------------
    </documentation>
  </annotation>
  <complexType name="RteType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="rteName" type="string"/>
      <element name="sbeNaptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="isInSvc" type="boolean"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="SvcAreaType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="saName" type="string"/>
      <element name="rteId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="PubIdType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="pubId" type="string"/>
      <element name="svcs" type="string"/>
      <element name="saId" type="est:OIdType" minOccurs="0"/>



Cartwright, et al.       Expires August 28, 2008               [Page 99]


Internet-Draft                ESPP Protocol                February 2008


      <element name="naptrId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="pvtId" type="est:OIdType" minOccurs="0"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="PvtIdType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="pvtId" type="string"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="TNRType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="tnRStrt" type="string"/>
      <element name="tnREnd" type="string"/>
      <element name="saId" type="est:OIdType"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="LRNType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="rn" type="string"/>
      <element name="saId" type="est:OIdType"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="NAPTRType">
    <sequence>
      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="order" type="unsignedShort"/>
      <element name="pref" type="unsignedShort"/>
      <element name="flags" type="string" minOccurs="0"/>
      <element name="svcs" type="string"/>
      <element name="regx" type="string" minOccurs="0"/>
      <element name="repl" type="string" minOccurs="0"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="EgrRteType">
    <sequence>



Cartwright, et al.       Expires August 28, 2008              [Page 100]


Internet-Draft                ESPP Protocol                February 2008


      <element name="oid" type="est:OIdType"/>
      <element name="eid" type="est:EIdType"/>
      <element name="rteId" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="pref" type="unsignedShort"/>
      <element name="svcs" type="string" minOccurs="0"/>
      <element name="regxRewriteRule" type="string"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <simpleType name="OIdType">
    <restriction base="unsignedLong"/>
  </simpleType>
  <simpleType name="EIdType">
    <restriction base="string"/>
  </simpleType>
  <simpleType name="ClientIdType">
    <restriction base="int"/>
  </simpleType>
  <simpleType name="TransIdType">
    <restriction base="unsignedLong"/>
  </simpleType>
  <simpleType name="VerType">
    <restriction base="unsignedLong"/>
  </simpleType>
  <complexType name="BasicRspnsType">
    <sequence>
      <element name="resCode" type="int"/>
      <element name="resMsg" type="string"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="BasicRqstType">
    <sequence>
      <element name="clientId" type="est:ClientIdType"/>
      <element name="transId" type="est:TransIdType"/>
      <element name="minorVer" type="est:VerType"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="BasicQueryType">
    <sequence>
      <element name="clientId" type="est:ClientIdType"/>
      <element name="minorVer" type="est:VerType"/>
      <element name="ext" type="est:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>
  <complexType name="BatchUpdateType">



Cartwright, et al.       Expires August 28, 2008              [Page 101]


Internet-Draft                ESPP Protocol                February 2008


    <sequence>
      <element name="op" type="est:BatchOpType" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <complexType name="BatchOpType">
    <sequence>
      <element name="naptrDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="naptrAdd" type="est:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="egrRteDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="egrRteAdd" type="est:EgrRteType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="rteDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="rteAdd" type="est:RteType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="saDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="saAdd" type="est:SvcAreaType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="pviDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="pviAdd" type="est:PvtIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="piDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="piAdd" type="est:PubIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="tnRDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="tnRAdd" type="est:TNRType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="lrnToDel" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="lrnAdd" type="est:LRNType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="entrDel" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="entrAdd" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
      <element name="entrMod" minOccurs="0" maxOccurs="unbounded">
        <complexType>
          <sequence>
            <element name="newEId" type="est:EIdType"/>
            <element name="oldEId" type="est:EIdType"/>
          </sequence>



Cartwright, et al.       Expires August 28, 2008              [Page 102]


Internet-Draft                ESPP Protocol                February 2008


        </complexType>
      </element>
    </sequence>
  </complexType>
  <complexType name="BatchUpdateFilePropsType">
    <sequence>
      <element name="clientId" type="est:ClientIdType"/>
      <element name="serverId" type="string"/>
      <element name="isFullResync" type="boolean"/>
      <element name="creationTimestamp" type="dateTime"/>
      <element name="sequenceNumber" type="unsignedLong"/>
      <element name="isEndOfSequence" type="boolean"/>
    </sequence>
  </complexType>
  <complexType name="SvcMenuType">
    <sequence>
      <element name="majMinVersion"
               type="string"
               maxOccurs="unbounded"/>
      <element name="objURI"
               type="anyURI"
               maxOccurs="unbounded"/>
      <element name="extURI"
               type="anyURI"
               minOccurs="0"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <complexType name="ExtAnyType">
    <sequence>
      <any namespace="##other" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <annotation>
    <documentation>
    ----------- Wrapped Rqst Message Definitions -----
    </documentation>
  </annotation>
  <element name="addRtesRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="rte" type="est:RteType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delRtesRqst">
    <complexType>



Cartwright, et al.       Expires August 28, 2008              [Page 103]


Internet-Draft                ESPP Protocol                February 2008


      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getRtesRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addSvcAreasRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="svcArea" type="est:SvcAreaType"
maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delSvcAreasRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getSvcAreasRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addPubIdsRqst">
    <complexType>
      <sequence>



Cartwright, et al.       Expires August 28, 2008              [Page 104]


Internet-Draft                ESPP Protocol                February 2008


        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="pi" type="est:PubIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delPubIdsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getPubIdsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addPvtIdsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="pvi" type="est:PvtIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delPvtIdsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getPvtIdsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addTNRsRqst">
    <complexType>
      <sequence>



Cartwright, et al.       Expires August 28, 2008              [Page 105]


Internet-Draft                ESPP Protocol                February 2008


        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="tnR" type="est:TNRType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delTNRsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getTNRsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addLRNsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="lrn" type="est:LRNType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delLRNsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getLRNsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addNAPTRsRqst">
    <complexType>
      <sequence>



Cartwright, et al.       Expires August 28, 2008              [Page 106]


Internet-Draft                ESPP Protocol                February 2008


        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="naptr"
                 type="est:NAPTRType"
                 maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delNAPTRsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getNAPTRsRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addEgrRtesRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="egrRte" type="est:EgrRteType"
maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="delEgrRtesRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="oid" type="est:OIdType" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="getEgrRtesRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
        <element name="oid" type="est:OIdType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="eid" type="est:EIdType" minOccurs="0"
maxOccurs="unbounded"/>



Cartwright, et al.       Expires August 28, 2008              [Page 107]


Internet-Draft                ESPP Protocol                February 2008


      </sequence>
    </complexType>
  </element>
  <element name="batchUpdateRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="batchUpdate" type="est:BatchUpdateType"/>
      </sequence>
    </complexType>
  </element>
  <element name="batchUpdateFileRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="batchUpdateFileProps"
type="est:BatchUpdateFilePropsType"/>
        <element name="batchUpdate" type="est:BatchUpdateType"
maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <element name="addEntrRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="eId" type="est:EIdType"/>
      </sequence>
    </complexType>
  </element>
  <element name="modEntrRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="newEId" type=" est:EIdType"/>
        <element name="oldEId" type=" est:EIdType"/>
      </sequence>
    </complexType>
  </element>
  <element name="delEntrRqst">
    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicRqstType"/>
        <element name="eId" type=" est:EIdType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getSvcMenuRqst">



Cartwright, et al.       Expires August 28, 2008              [Page 108]


Internet-Draft                ESPP Protocol                February 2008


    <complexType>
      <sequence>
        <element name="basicRqst" type="est:BasicQueryType"/>
      </sequence>
    </complexType>
  </element>
  <annotation>
    <documentation>
    ----- Wrapped Rspns Message Definitions  ----------------
    </documentation>
  </annotation>
  <element name="getRtesRspns">
    <complexType>
      <sequence>
        <element name="rte" type="est:RteType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getSvcAreasRspns">
    <complexType>
      <sequence>
        <element name="svcArea" type="est:SvcAreaType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getPubIdsRspns">
    <complexType>
      <sequence>
        <element name="pi" type="est:PubIdType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getPvtIdsRspns">
    <complexType>
      <sequence>
        <element name="pvi" type="est:PvtIdType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getTNRsRspns">



Cartwright, et al.       Expires August 28, 2008              [Page 109]


Internet-Draft                ESPP Protocol                February 2008


    <complexType>
      <sequence>
        <element name="tnR" type="est:TNRType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getLRNsRspns">
    <complexType>
      <sequence>
        <element name="lrn" type="est:LRNType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getNAPTRsRspns">
    <complexType>
      <sequence>
        <element name="naptr" type="est:NAPTRType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getEgrRtesRspns">
    <complexType>
      <sequence>
        <element name="egrRte" type="est:EgrRteType" minOccurs="0"
maxOccurs="unbounded"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="getSvcMenuRspns">
    <complexType>
      <sequence>
        <element name="svcMenu" type="est:SvcMenuType"/>
        <element name="basicResult" type="est:BasicRspnsType"/>
      </sequence>
    </complexType>
  </element>
  <element name="cmnRspns">
    <complexType>
      <sequence>
        <element name="rspns"
                 type="est:BasicRspnsType"



Cartwright, et al.       Expires August 28, 2008              [Page 110]


Internet-Draft                ESPP Protocol                February 2008


                 nillable="false"/>
      </sequence>
    </complexType>
  </element>
</schema>














































Cartwright, et al.       Expires August 28, 2008              [Page 111]


Internet-Draft                ESPP Protocol                February 2008


9.  Security Considerations

   This document specifies a new provisioning protocol.

   Provisioning data and other configuration information in scope of
   ESPP include public identities, telephone number ranges, LRNs,
   signaling path border elements, NAPTRs and Egress Routes.  This
   information is sensitive and its transmission in the clear and
   without integrity checking leaves servers exposed to eavesdropping
   attacks.  Compliant implementations must therefore satisfy the
   requirements defined in Section 4.4.1.3.

   If the object values for the Public Identity, Route, Service Area,
   LRN, SBE, MAPTRs are set maliciously, it may result in sessions being
   misrouted and service disruption.  It may also result in an over-
   allocation of signaling resources in an attempt to create denial of
   service attacks (all routes of all areas directed towards a
   particular SBE).

   Additional security considerations must also apply given the
   provisioning data exchanged within and between Trust Domains as
   defined in [RFC3325].

   An initial set of security requirements that must be met by compliant
   ESPP Clients and ESPP Servers is defined in [I-D.espp-requirements].


























Cartwright, et al.       Expires August 28, 2008              [Page 112]


Internet-Draft                ESPP Protocol                February 2008


10.  Acknowledgments

   This document is based on the work of participants in the CableLabs
   PacketCable ENUM Server vendor focus team.

   The authors wish to thank the following participants for their
   contributions and efforts:
   Jack Burton, Paul Natale, Costas Gavrilidis, Matt Cannon, Ken
   Cartwright, Kevin Johns, James Brister, Ted Lemon, Vivian Neou, Mark
   McBride, Tim Cody, Sean Leach, Gene Lew, Rich Shockey, Mark Teodoro,
   Robby Benedyk, Steve Dimig, , Ajay Gupta, Sean Kent, Tom Kershaw,
   Manjul Maharishi, Yasir Saleem, Sanjeev Chauhan, Gaurav Sharma, Vikas
   Sarawat, Daryl Malas and Sumanth Channabasappa.






































Cartwright, et al.       Expires August 28, 2008              [Page 113]


Internet-Draft                ESPP Protocol                February 2008


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

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

   [SOAP]     W3C, "W3C Recommendation, SOAP Version 1.1", May 2000.

   [WSDL]     W3C, "W3C Recommendation, Web Services Description
              Language (WSDL) Version 1.1", March 2001.

   [XML]      W3C, "W3C Recommendation, Extensible Markup Language (XML)
              1.0", August 2006.

11.2.  Informative References

   [CableLabs-ESPP]
              CableLabs, "PacketCable ENUM Server Provisioning
              Specification, PKT-SP-ENUM-PROV-I01-080215", CableLabs Spe
              cification http://www.cablelabs.com/specifications/
              PKT-SP-ENUM-PROV-I01-080215.pdf, February 2008.

   [I-D.espp-requirements]
              Creighton, T. and J-F. Mule, "ENUM-SIP Server Provisioning
              Protocol (ESPP)",
              draft-mule-peppermint-espp-requirements-00.txt (work in
              progress), February 2008.

   [I-D.ietf-speermint-terminology]
              Meyer, R. and D. Malas, "SPEERMINT Terminology",
              draft-ietf-speermint-terminology-16.txt (work in
              progress), February 2008.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.



Cartwright, et al.       Expires August 28, 2008              [Page 114]


Internet-Draft                ESPP Protocol                February 2008


              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.












































Cartwright, et al.       Expires August 28, 2008              [Page 115]


Internet-Draft                ESPP Protocol                February 2008


Authors' Addresses

   Kenneth Cartwright
   VeriSign
   21355 Ridgetop Circle
   Dulles, VA  20166
   USA

   Email: kcartwright@verisign.com


   Stephen M. Dimig
   Tekelec
   5200 Paramount Parkway
   Morrisville, NC  27560
   USA

   Email: stephen.dimig@tekelec.com


   Mark Teodoro
   NeuStar
   46000 Center Oak Plaza
   Sterling, VA  20166
   USA

   Email: mark.teodoro@neustar.com


   Jean-Francois Mule
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: jfm@cablelabs.com















Cartwright, et al.       Expires August 28, 2008              [Page 116]


Internet-Draft                ESPP Protocol                February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Cartwright, et al.       Expires August 28, 2008              [Page 117]