[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Drinks Working Group                                        T. Creighton
Internet-Draft                              Comcast Cable Communications
Intended status: Informational                                 J-F. Mule
Expires: January 15, 2009                                      CableLabs
                                                           July 14, 2008


   Provisioning Protocol Requirements for ENUM-SIP Addressing Servers
               draft-mule-peppermint-espp-requirements-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 January 15, 2009.

















Creighton & Mule        Expires January 15, 2009                [Page 1]


Internet-Draft              espp-requirements                  July 2008


Abstract

   This document presents use cases and protocol requirements for
   provisioning ENUM-SIP addressing servers.  The provisioned data is
   used by the addressing server to return session establishment data
   for SIP entities to route SIP requests to the target destinations.
   An ENUM-SIP addressing server acts as a Lookup Function in session
   peering to determine the target domain of a given SIP request.  It
   may also act as a Location Routing Function to develop the location
   of the SIP signaling entity in the target domain.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivations and Use Cases Examples . . . . . . . . . . . . . .  5
     3.1.  Separation of Responsibility . . . . . . . . . . . . . . .  5
     3.2.  File-based Distribution and Bootstrapping  . . . . . . . .  7
     3.3.  Backward Compatibility to Legacy Switch Translations . . .  8
   4.  Protocol Requirements  . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Connection-Oriented Operation  . . . . . . . . . . . . . .  9
     4.2.  File Oriented Operation  . . . . . . . . . . . . . . . . .  9
     4.3.  Security Requirements: Authentication, Integrity and
           Confidentiality  . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Data Model Requirements  . . . . . . . . . . . . . . . . . 10
     4.5.  Data Presentation Requirements . . . . . . . . . . . . . . 11
     4.6.  Protocol Operations  . . . . . . . . . . . . . . . . . . . 11
     4.7.  Versioning, Capability Exchange, and Extensibility
           Requirements . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18













Creighton & Mule        Expires January 15, 2009                [Page 2]


Internet-Draft              espp-requirements                  July 2008


1.  Introduction

   This document presents a set of use cases and protocol requirements
   for an ENUM-SIP addressing Server Provisioning Protocol (ESPP).  An
   ENUM-SIP addressing server is a session routing server which resolves
   telephone numbers or any type of public user addresses into 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 session request to the target
   destination.

   An ENUM-SIP addressing server is a host that acts as a Lookup
   Function in session peering to determine the target domain of a given
   SIP request.  It may also act as a Location Routing Function to
   develop the target domain into the location of the SIP signaling
   entity servicing the target user.

   In order to perform address resolution, the addressing server often
   receives configuration data from various data sources.  These data
   sources may reside in a service provider or enterprise network
   (intra-office or intra-company back-office systems), or in a peer's
   network in the case of bilateral session peering agreements, or in a
   session peering registry shared by a group of SIP Service Providers
   (SSPs).  These data sources advertise the public user identities they
   serve (SIP user addresses, telephone numbers, and other types of
   Uniform Resource Identifiers) along with other data elements like the
   Signaling path Border Elements (SBEs) to use to reach those user
   identities.

   The ENUM-SIP addressing server Provisioning Protocol (ESPP) is an
   example of provisioning protocol based on the requirements in this
   document ([I-D.espp-protocol]).  It can be viewed as a provisioning
   protocol for the lookup and location routing functions defined in
   session peering.

   This document is organized as follows: Section 3 presents some
   motivations and use cases, and Section 4 defines protocol
   requirements for a provisioning protocol for the lookup and location
   routing functions.

   This document is provided as input for protocol requirement
   discussion in the drinks working group.







Creighton & Mule        Expires January 15, 2009                [Page 3]


Internet-Draft              espp-requirements                  July 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].
   The Lookup Function (LUF), Location Routing Functions (LRF) and other
   session peering terms are defined [I-D.ietf-speermint-terminology].










































Creighton & Mule        Expires January 15, 2009                [Page 4]


Internet-Draft              espp-requirements                  July 2008


3.  Motivations and Use Cases Examples

   The main motivation for defining an open provisioning protocol for
   ENUM-SIP addressing servers is to allow multiple server vendors to
   accept provisioning data from multiple data sources (some internal to
   a SIP service provider, some controlled by one or more session peers)
   using a common and flexible data model for the data elements that may
   need to be provisioned.

   The remaining of this section provides a couple of use cases.

3.1.  Separation of Responsibility

   A SIP Service Provider's business practices may impose a separation
   of roles and responsibilities such that:

   (a)  network engineering and planning personnel are responsible for
        establishing points-of-interconnect (at layer 3 for IP
        internetworking and layer 5 for SBEs),

   (b)  for telephony services, telephony personnel are responsible for
        provisioning telephone numbers, and telephone number prefixes,

   (c)  other personnel or back-office application systems are
        responsible for provisioning other forms of resolvable user
        addresses (e.g., email addresses, instant messaging addresses
        via self-provisioned web applications, etc.).

   The above separation of roles and responsibilities imply that
   multiple data sources may concurrently add, modify or delete data
   elements that often must be "combined" for an ENUM-SIP addressing
   server to return session establishment data.

   For example, two SIP service providers agree to exchange SIP traffic
   by establishing a session peering relationship for voice services
   first, and they decide to first exchange traffic for a sub-set of
   their customer base; two destination groups, the New York-Manhattan
   and New York-Queens groups are peered.  Note that the destination
   groups used in this example are geographical to facilitate the
   understanding of destination groups but in many cases, peers will
   establish peering relationships independent of any gepgraphical
   considerations (user groups, im groups, etc.).
   In unison, the network engineering personnel of each company
   establish physical inter-connect in the New York City 60 Hudson
   Street facility.  Each SIP service provider commissions redundant
   Signaling path Border Elements that are used to secure the
   interconnect located at 60 Hudson Street.  Then through the use of
   the ESPP protocol, the network engineering departments publish IP and



Creighton & Mule        Expires January 15, 2009                [Page 5]


Internet-Draft              espp-requirements                  July 2008


   SIP addressing information to each other's ENUM-SIP addressing
   servers - provisioning NAPTRs for each Ingress SBE and through Route
   objects associating them with the logical Destination Groups of each
   metropolitan area.
   Once the Destination Groups and Routes are established, the telephony
   personnel manage the telephony addressing by adding telephone
   numbers, routing numbers or prefixes to the respective Destination
   Groups.
   Some of the data (SBEs, Destination Groups, Routes and their
   respective priorities) 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 Destination Groups
   (TNs, TN Ranges, LRNs, or public identities such as IM identifiers).
   This allows the rare process of provisioning SBEs, destination
   groups, etc. to be distinctly separate from the continuous process of
   adding subscribers.  This also applies to non-voice applications
   where subscribers are added independently of the underlying Layer-5
   entities that service those users.
   Note that the exchange of this information may be done directly
   between peers or via an entity representing a group of SIP service
   providers.  Today, in some VoIP networks, this information is often
   exchanged in a static manner using email and spreadsheets.

   Figure 1 illustrates how telephone numbers may be grouped logically
   into destination groups (which may not necessarily be based on
   geographical boundaries).  It also shows how each destination group
   may be reachable via a domain or a list of signaling path border
   elements.






















Creighton & Mule        Expires January 15, 2009                [Page 6]


Internet-Draft              espp-requirements                  July 2008


 Destination Groups:
 +------------------------------------+
 |Destination Group| 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    |Destination Group|   ( 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-sp1.example.com|
         |NYC-SBE-2|sbe-2.nyc-sp2.example.com|
         +---------+-------------------------+


                     Figure 1: Protocol Data Elements

3.2.  File-based Distribution and Bootstrapping

   The process of downloading large quantities of data to an ENUM-SIP
   addressing server should be carried out as quickly as possible with
   minimum resources.  It involves the generation and transfer of a bulk
   file between the client and server.  It may be used in cases where
   the loading a newly commissioned ENUM-SIP addressing server or
   reloading an existing server data due to a complete shutdown or loss
   of memory has occurred.

   For example, a SIP service provider has decided to opt into a
   federation of service providers that collectively service over one
   hundred million (100M) subscribers, choosing to establish session
   peering with every member of the federation.  Once commissioned, the
   SIP service provider's addressing server needs to immediately receive
   all 100M registered user addresses (SIP addresses, TNs, etc.).
   Rather than stream the 100M TNs over a network connection in real-
   time, the administrator of the federation registry and SIP service



Creighton & Mule        Expires January 15, 2009                [Page 7]


Internet-Draft              espp-requirements                  July 2008


   provider choose to utilize the file-based distribution mechanism (as
   described in [I-D.espp-protocol]).

3.3.  Backward Compatibility to Legacy Switch Translations

   The underlying data schema used to provision ENUM-SIP addressing
   servers should be backward compatible with today's legacy VoIP server
   translations and PSTN.  This requirement arises from the fact that
   some SIP service providers may wish to utilize the same number
   translation data employed by their SIP servers handling subscribers.

   For example, a SIP service provider's switch translation personnel,
   who are responsible for managing SIP to telephone number address
   translations, are given responsibility for managing the ENUM data.
   Rather than provisioning complete numbers to a peer's addressing
   server some may choose to provision telephone number prefixes or
   routing numbers.  For example, an enterprise's branch office may wish
   to provision the first n number of digits it can serve.  As another
   example, in North America, some may not wish to provision the
   complete 10-digit numbers but opt for the provisioning Routing
   Numbers (RNs) as prefixes.  This decision is, in large part, due to
   the fact that, in some enterprise and SIP service provider networks
   today, the trunk selection algorithm are based on prefix (e.g.  NPA-
   NXX in North America).  The translation personnel choose to reuse
   prefixes rather than taking responsibility for keeping a complete set
   of the service provider's numbers up to date.

























Creighton & Mule        Expires January 15, 2009                [Page 8]


Internet-Draft              espp-requirements                  July 2008


4.  Protocol Requirements

   This section describes the high-level requirements for the ENUM-SIP
   server provisioning protocol.

4.1.  Connection-Oriented Operation

   o    The protocol MUST support a file-based, bulk delivery mechanism
        where the Client writes one or more update requests to one or
        more files and the file(s) are delivered to and consumed by the
        Server.

   o    The protocol MUST also support real-time, transaction-based
        operations where the Client requests one operation over a
        reliable transport and the ESPP server processes the request
        upon receipt and then responds to the Client with an indication
        of the transaction' status (success, warning or error).

   o    All Clients and Servers MUST use HTTP 1.1 as defined in
        [RFC2616] for the transport mechanism of real-time operations.

   o    All Clients and Servers SHOULD support HTTP Keep-Alive to allow
        long lived connections, where multiple request and response
        pairs are exchanged across a single network connection.

4.2.  File Oriented Operation

   o    The protocol MUST support a file-based mechanism (bulk load)
        where the Client writes one or more requests to a file and the
        file is delivered to and consumed by the Server.

   o    The delivery or transmission of bulk files MAY be triggered by a
        manual process out-of-band of the protocol.

   o    During bulk loading the Server SHOULD NOT accept new records
        through the real-time, connection-oriented interface.

   o    The maximum size of a bulk load file SHOULD NOT exceed 500 MB.

   o    The name of a bulk file SHOULD identify the Client, Server, file
        sequence number, and transaction ID(s) for which the bulk file
        was generated.

   o    The bulk load interface MUST be capable of supporting the
        download of an entire address space of the order of the PSTN.

   o    The format of the bulk load file MUST be compatible with the XML
        definitions of the real-time interface.



Creighton & Mule        Expires January 15, 2009                [Page 9]


Internet-Draft              espp-requirements                  July 2008


   o    The Server MUST maintain an error log that identifies
        transactions that resulted in an error when being applied to the
        database of the Server.  The errors codes of the bulk load
        interface SHOULD comply with the error codes of the real-time
        interface.

4.3.  Security Requirements: Authentication, Integrity and
      Confidentiality

   o    All Clients and Servers MUST support Transport Layer Security
        (TLS) as defined in [RFC4346] as the secure transport mechanism.

   o    All Clients and Servers MUST use HTTP Digest Authentication as
        defined in [RFC2617] as the secure authentication mechanism.

   o    Transfer of bulk files MUST use Secure Copy (SCP), which relies
        on Secure Shell (SSH) for security, as the secure file transport
        mechanism.

4.4.  Data Model Requirements

   o    The provisioning protocol MUST be capable of supporting the
        following data elements as part of user addresses: any type of
        user addresses or Uniform Resource Identifiers that can be used
        to establish SIP sessions, and telephone number related elements
        (TNs, TN prefixes, TN ranges, and Routing Numbers).

   o    The protocol data model MUST provide means to logically group
        public user addresses into Destination Groups.

   o    The protocol data model MUST allow the data separation between
        public user addresses (and their logical groupings) and the
        domain or routes that can be used to reach those user addresses.

   o    The protocol data model MUST support the data elements required
        for the SPEERMINT Lookup Function and allow the Location Routing
        Function to dynamically determine the target's SIP server
        outside the provisioning framework.  This is the case of dynamic
        SIP location determination based on a domain name of the SSP and
        mechanisms like [RFC3263].

   o    The protocol data model MUST also allow the data elements
        required for the Location Routing Function to be provisioned
        within this provisioning framework.

   o    Because of the above requirement, the protocol MUST be capable
        of supporting the following data elements as part of Routes
        associated with Destination Groups: ingress and egress Signaling



Creighton & Mule        Expires January 15, 2009               [Page 10]


Internet-Draft              espp-requirements                  July 2008


        path border elements (SBE FQDNs, SIP transport protocol and
        ports), priority of routes, etc.

4.5.  Data Presentation Requirements

   o    The protocol MUST utilize SOAP 1.1 [SOAP], WSDL 1.1 [WSDL], and
        XML 1.0 [XML].

   o    The protocol MUST support efficient transportation of a large
        number of data model objects from the client to the server.

4.6.  Protocol Operations

   o    The protocol MUST support the ability to add, modify, and delete
        the objects defined in the protocol data model.

   o    The protocol MUST support the ability to query for a specific
        instance of each type of object defined in the data model by
        using the object identifier.

   o    The protocol MUST support the ability for multiple Clients to
        provision objects into the same Server.

   o    The protocol MUST support the ability for objects created by one
        Client to refer to objects created by another Client.

4.7.  Versioning, Capability Exchange, and Extensibility Requirements

   o    The protocol MUST support schema versioning such that major
        version changes are defined as any change that breaks backward
        compatibility and minor version changes are defined as any
        change that does not break backward compatibility.

   o    The protocol MUST allow, but not require, a server to expose
        multiple concurrent major versions and/or minor versions of the
        protocol concurrently.

   o    The protocol MUST make the major version identification of a
        request message detectable by schema validation and the minor
        version identification of a request message detectable by the
        application.

   o    The protocol MUST be extensible such that new operations and
        objects can be added to the protocol in a systematic manner.







Creighton & Mule        Expires January 15, 2009               [Page 11]


Internet-Draft              espp-requirements                  July 2008


5.  Security Considerations

   Provisioning data and other configuration information in scope of
   this ENUM-SIP Server Provisioning protocol include public identities,
   telephone number ranges, signaling path border elements and NAPTRs.
   This information is sensitive and its transmission in the clear and
   without integrity checking leaves servers exposed to eavesdropping
   attacks.

   If the object values such as TNs, Routes, or Destination Groups are
   set maliciously, it may result in sessions being misrouted or an
   over-allocation of signaling resources in an attempt to create denial
   of service attacks.

   An initial set of security requirements for such a provisioning
   protocol are defined in Section 4.3.



































Creighton & Mule        Expires January 15, 2009               [Page 12]


Internet-Draft              espp-requirements                  July 2008


6.  IANA Considerations

   This document does not register any values in IANA registries.
















































Creighton & Mule        Expires January 15, 2009               [Page 13]


Internet-Draft              espp-requirements                  July 2008


7.  Acknowledgments

   This document is based on the work of participants in the CableLabs
   PacketCable ENUM Server vendor focus team and initial feedback from
   the Peppermint/Drinks working groups.

   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, Sumanth Channabasappa, Penn Pfautz, and Otmar
   Lendl.




































Creighton & Mule        Expires January 15, 2009               [Page 14]


Internet-Draft              espp-requirements                  July 2008


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.espp-protocol]
              Cartwright, K., Dimig, S., Teodoro, M., and J-F. Mule,
              "ENUM-SIP Server Provisioning Protocol (ESPP)",
              draft-mule-peppermint-espp-protocol-02.txt (work in
              progress), July 2008.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

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

   [WSDL]     W3C, "W3C Recommendation, Web Services Description



Creighton & Mule        Expires January 15, 2009               [Page 15]


Internet-Draft              espp-requirements                  July 2008


              Language (WSDL) Version 1.1", March 2001.

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















































Creighton & Mule        Expires January 15, 2009               [Page 16]


Internet-Draft              espp-requirements                  July 2008


Authors' Addresses

   Tom Creighton
   Comcast Cable Communications
   One Comcast Center
   Philadelphia, PA  19103
   USA

   Email: tom_creighton@cable.comcast.com


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

   Email: jfm@cablelabs.com

































Creighton & Mule        Expires January 15, 2009               [Page 17]


Internet-Draft              espp-requirements                  July 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.











Creighton & Mule        Expires January 15, 2009               [Page 18]