[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-spirits-reqs

Network Working Group                                    I. Faynberg, Ed.
Internet Draft                                       Lucent Technologies
draft-faynberg-spirits-reqs-00.txt>                              J. Gato
Expires August 2001                                          Airtel Movil
                                                                    H. Lu
                                                      Lucent Technologies
                                                             L. Slutsman
                                                                    AT&T


      SPIRITS Protocol Requirements


Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.

   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.


1. Abstract

   This Internet-Draft is written in response to the SPIRITS WG chairs'
   call for contributions to the future RFC on the SPIRITS protocol
   requirements. As such, it documents to consensus of the SPIRITS WG on
   the choice of SPIRITS transport protocol and lists general requirements
   as well as those pertinent to Intelligent Network (IN), Wireless IN, and
   the PSTN/Internet iNTernetworking (PINT) building blocks.

2. Conventions used in this document

   In examples, "C:", "P", and "S:" indicate lines sent by the client,
   gateway, and server respectively.

   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 RFC 2119.

   Unless otherwise qualified, the term PINT is used here not to refer to
   the present PINT services and protocol, but in reference to the scope



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 2]


   of the generic PINT (vs. SPIRITS) service characteristic--being invoked
   from an IP network (vs. PSTN).

3. Introduction


   This Internet-Draft is written in response to the SPIRITS WG chairs'
   call for contributions to the future RFC on the SPIRITS protocol
   requirements. As such, it documents to consensus of the SPIRITS WG on
   the choice of SPIRITS transport protocol and lists general requirements
   as well as those pertinent to Intelligent Network (IN), Wireless IN, and
   the PSTN/Internet iNTernetworking (PINT) building blocks.
   The joint PINT/SPIRITS architecture (described in [1]) is depicted in
   Figure 1.

   It is assumed that the Spirits Client is either co-located with the IN
   Service Control Function (SCF) or communicates with it (over the
   PSTN-specific interface D) in such a way so as to act on behalf of the
   PSTN/IN. (This assumption is confirmed by current implementations, as
   reported in [2].)

   The SPIRITS services are invoked (and, subsequently, the SPIRITS
   protocol is initiated) when a message from a SPIRITS Client (located in
   the IN Service Control Point [SCP] or Service Node [SN]) arrives on
   interface C to the SPIRITS gateway. The Spirits gateway processes the
   message and, in turn, passes it on over the Interface B to the SPIRITS
   server.  In most practically important cases, the request from a
   SPIRITS client is ultimately caused by a request from a Central Office
   (i.e., a telephone switch) sent to either the SCP or SN, although the
   Internet-based service initiation by these elements that had not been
   triggered by the Central Office is theoretically possible. (Definitely,
   none of the SPIRITS benchmark services are initiated in such a way, so
   for the purposes of the SPIRITS protocol development, it should be
   assumed that the service invocation was a direct result of an earlier
   action by the Central Office.)






















SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 3]


                                            ......................
            +----------------+              .                    .
            | +------------+ |              .   +------------+   .
            | |            | |       A      .   |            |   .
            | | PINT Client|********************|PINT Server/|********
            | |            | |              .      Gateway   |       *
            | +------------+ |              .   +------------+   .   *
            |                |              .                    .   *
            |  Subscriber's  |              .                    .   *
            |                |              .                    .   *
            |  IP Host       |              .                    .   *
            |                |              .   +------------+   .   *
            | +------------+ |              .   | SPIRITS    |   .   *
            | | SPIRITS    | |       B      .   | Gateway    |   .   *
            | | Server     |********************|            |   .   * E
            | |            | |              .   +------------+   .   *
            | +------------+ |              .          *         .   *
            +----------------+              .          *         .   *
                                            ...........*..........   *
                 //-------\\                           *             *
              ///           \\\                        *             *
             |   Subscriber's  |                       *  C          *
             |   Telephone     |                       *             *
              \\\           ///                        *             *
                \\ -------//                           *             *
                     *                                 *             *
                     *                                 *             *
           ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
                     *                                 *             *
                     *                                 *             *
                     *                          +------------------+ *
                     * Line                     | SPIRITS Client   | *
                     *                          |                  | *
            +--------------------+          +---+----- D  ---------+-*+
            |                    | INAP/SS7 |                         |
            |Service Switching   ************Service Control Function |
            |    Function        |          |                         |
            |                    |          +-------------------------+
            |                    |
            |                    |
            +--------------------+

              Figure 1. Joint PINT/SPIRITS Architecture



   With PINT (and that also applies to the present PINT architecture and
   protocol as described in [3]), the service request to the PINT Server
   is always initiated by the PINT Client over the interface A. The PINT
   Server can either be co-located with the IN Service Control or a
   similar entity (referred to as "Executive System" by [3]) or
   communicate with it over the PSTN-specific interface E.



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 4]


   As Figure 1 shows, the PINT Client and SPIRITS Server are co-located
   in Subscriber's IP Host. In fact, both can be implemented to run as
   one process. No provision is made for interactions between the PINT
   Client and Spirits Server. Similarly, the PINT Server/PINT Gateway
   and SPIRITS gateway are assumed to be co-located, too. This
   assumption is convenient but not essential; the PINT Server could
   also be co-located with the SPIRITS Client. In either case, no
   specific provision is made to define interworking between either the
   PINT Server and Spirits Proxy or PINT Server and SPIRITS Client other
   then by listing the overall PINT-related requirements.

   Since the wireless networks currently deployed worldwide are based on
   circuit switching, they are considered PSTN networks for the SPIRITS
   purposes. Adding SPIRITS type of services to wireless networks can
   allow new services to be developed (for example location information
   can be handled in the IP network).

   Nevertheless, there are certain peculiarities of Wireless networks,
   which that force considerations to be made in the in the protocol
   requirements and in the SPIRITS architecture.

   The particular Wireless IN standard development being considered here
   is CAMEL phase 3, standardised by the Third Generation Partnertship
   group (3GPP). The relevant service and architectural considerations
   and protocol requirements are presented later in this document. As
   far as the architecture is concerned, certain wireless events are
   generated by Home Location Register (HLR), which may but does not
   have to be part of the SSP. These events are communicated to Service
   Control, at which point they use the same mechanism for envoking
   SPIRITS services that the IN would.

   The rest of this Internet-Draft addresses the general requirements,
   IN Requirements, specific Wireless IN requirements, PINT
   Requirements, the protocol development methodology, and security
   issues, in that order.


   Based on the success of extending SIP for PINT ([2]) and, especially,
   the results of pre-SPIRITS implementations reported in [2], the
   Session Initiation Protocol (SIP) [7] has been chosen as the
   transport protocol for SPIRITS.

   Thus, it is a requirement that specific SPIRITS-related parameters be
   carried in a manner consistent with SIP practices. In particular,
   Either Session Description Protocol (SDP) [8] or Multi-purpose
   Internet Mail Extensions MIME [5-6] is to be used for this purpose.
   Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and
   extensions already defined in PINT, no SIP extensions to SIP are
   foreseen; instead the SPIRITS protocol is to rely on the above
   extension mechanisms.

   It is by no means a requirement that any SPIRITS implementation
   automatically support PINT services. The SPIRITS protocol must be
   defined in a manner where, as the minimum, it can support only the



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 5]


   basic notification mechanism without relying on PINT services or
   otherwise relying on persistent interactions with PSTN.
   Nevertheless, it has been demonstrated [2] that combining PINT
   building blocks with those of SPIRITS is beneficial to buidling
   reach, enhanced PSTN/Internet services, so the SPIRITS protocol must
   meet the PINT-related requirements listed in section 6 of this
   document.

   One specific example demonstrating the application of the latter
   requirement, which is elaborated on further in this document, is as
   follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far
   as the minimum SPIRITS protocol is concerned.  Thus, the initial PSTN
   (Detection Point) notification will always arrive via the SIP INVITE
   method; however, to implement persistent interactions with the PSTN,
   the SUBSCRIBE method may be used to obtain further notifications to
   the PSTN events. Subsequently, these events will be reported on by
   means of the NOTIFY method.

5. IN Requirements

   The interface immediately relevant to IN is that between the SPIRITS
   Client and SPIRITS Proxy (interface C). A typical message (which
   starts a SPIRITS service) looks like that:

   C -> P: <Event Notification>, <Parameter-List (DP)>

   The relevant events correspond to the detection points (DPs) of the
   IN Basic Call State Model (BCSM). The <Parameter-List> is a function
   of a specific DP; it contains the parameters relevant to it. The
   following requirements apply:

   1) The list of the DPs to be covered encompasses those defined in the
   IN Capability Set 3 BCSM as well as those that relate to the Wireless
   IN (WIN) specified by the IMT 2000 project in ITU-T.

   2) Not all parameters associated with such DPs are needed by the
   SPIRITS benchmark services, nor may all the parameters be needed in
   SPIRITS. The selection of the relevant parameters is part of the
   SPIRITS protocol definition.

   3) It is desirable to avoid semantic overload of protocol messages.
   (One way to achieve that is to match each type of an event with a
   message that corresponds to it.) In case the SPIRITS protocol is
   designed as a set of extensions to another (existing) protocol with
   the defined message set, the syntax and semantics of the extensions
   should be defined with this requirement in mind.

   4) The ITU-T Recommendations use the abstract syntax notation (ASN.1)
   to specify the semantics of the IN Application Protocol (INAP)
   parameters, which are expected to be binary-encoded Neither the use
   of the ASN.1, nor the requirement for binary encoding are the typical
   requirements for the IETF application protocols. Recognizing that,
   provisions must be made for careful specification of the conversion
   of the INAP parameters to text, which must preserve their original



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 6]


   semantics. The actual conversion of the parameters is the function of
   the SPIRITS Client.

   In order to issue an initial query (or a notification) to service
   control, a switch must have such a DP set. This can be done
   statically via service management (this particular action should be
   left to implementation and thus is considered outside of the scope of
   SPIRITS Protocol) or dynamically--but only for the purpose of a
   particular call--from the service control. In the latter case, it is
   part of the SPIRITS (or PINT) protocol to request the event
   notification from the service control. A work-in-progress SIP
   proposal [4] should be specifically considered.  This function can be
   performed by either the Spirits Client or PINT Server, the
   distinction being further discussed in the next section. Assuming
   that it is performed by the SPIRITS Client, the relevant message
   should look like

   C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,

   where <Event> refers to a particular DP; <Mode> determines whether
   the Event Detection Point (EDP) is to be armed as EDP Request (EDP-
   R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not
   foreseen); and the <DP-specific parameters> is the list of the values
   of the parameters associated with the EDP (for example, if the DP in
   question is O_No_Answer, then the value of the appropriate timer
   should be included in the list). Note that such a subscription may
   also originate at a) PINT Client or b) SPIRITS Proxy, either of which
   may (but does not have to) have a locally significant definition of
   the <Event>. In either case, it is the function of the SPIRITS Client
   to translate the definition of the Event into a particular DP (or set
   of DPs) when passing the message to Service Control. To summarize,
   for the case when PINT and SPIRITS events are defined in a way where
   they do not refer to the BCSM DPs, it is the function of the SPIRITS
   Client to define a mapping:

   Event -> DP List,

   for each event for which the PSTN notification is needed.

   The list of CS-2 DPs envisioned in SPIRITS is

           - origination_attempt_authorized (the SPIRITS
             service can control call attempts, (for example, to
             limit calls during specific time periods)

           - collected_information and analyzed_information (for
             SPIRITS outgoing call screening)

           - o_answer, o_term_seized, and t-answer (to release
             SPIRITS resources after the call is complete and
             perform relevant OA&M actions such as creating a record of
             attempts to reach a party via various means like land-line
   phone,
             cell phone, SMS, paging.)



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 7]


           - o_no_answer, route_select_failure,  and t_no_answer
             (to re-route a call)

           - o_busy (to re-route a call and for Internet Call Waiting)

           - o_mid_call and t_mid_call (to assist a midcall action)

           - o_abandon, o_disconnect, t_abandon, and t_disconnect  (to
             terminate a SPIRITS service and release the resources and
             perform relevant OA&M actions such as creating a record of
             attempts to reach a party via various means like land-line
   phone,
             cell phone, SMS, paging.)



   With that, the only DPs needed to implement the present SPIRITS
   milestone services are

           - termination_attempt_authorized (needed for SPIRITS
             "milestone" services)

           - facility_selected_and_available (could be used in SPIRITS
             Internet Caller-ID)

           - t_busy (for Internet Call Waiting and Call Forwarding).


6. Wireless-IN-related Requirements

   Wireless IN covers several types of "calls," which are neither
   circuit switched nor have an effect on circuit swicthed calls.  For
   this reason, those are not considered in SPIRITS requirements. To
   further clarify this point, the types of "calls" not considered are


           - USSD (Unstructured Supplementary Service Data)         -
   GPRS (General Packet Radio System)         - SMS (Short Message
   System)

   The types of calls relevant to SPIRITS are as follows:

           a) Voice Calls. In this case no new DP is needed since CAMEL
           DPs are included in CS2. The only  special case is "Not
   Reachable"         (when it is detected that the mobile user is out
   of coverage or
           has switched off), which is mapped as a special cause
           in the Busy DP. Since the Busy DP parameters would be
   received
           (if a SPIRITS service has subscribed to Busy), it would be
   possible
           to distinguish a "busy" from a "not reachable" situation.

           This translates into the requirement that one of the



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 8]


   parameters in
           the Event Notification message (from SPIRITS Client to
   SPIRITS Proxy,
           over the interface C) denotes the "cause" for the Busy
   Detection
           Point.

           Another aspect of difference, when compared to PSTN, is
   setting
           of static DPs. in CAMEL networks, this is done
           in the Home Location Register (HLR) (and copied to the VLR
   during
           location update). It is important to note this difference,
   even
           though it has no effect on  SPIRITS protocol.

           b) Mobility Management events.  This allows a SPIRITS server
   to be
           notified of changes of location of a mobile user. The events
   would
           only be applicable to mobile users reachable through a
   Circuit
           Switched network.  To provide for this function, the
           subscription marks must be set in the subscriber's HLR. This
   is
           equivalent to setting TDPs in the SSP. In this case the marks
           in the HLR (which are copied to the Visitor Location Register
   [VLR]
           on location update) are not mapped into Trigger Detection
   Points.
           As with TDP setting, this is outside of the scope of SPIRITS
           protocol.

           In order to support this function in SPIRITS, the SPIRITS
   protocol
           should be able to map the CAMEL specific operations into
           events notification to the SPIRITS client. Since the SCP
   receives
           the information about the mobility state, this involves
           the C interface. (This is just an extension of the DP
   notification
           mechanism from the SPIRITS client to the SPIRITS gateway).

      The events (which are not DP-related) which need notifications are

           - Location Update in the same VLR service area.
           - Location Update in another VLR service area.
           - IMSI attach.
           - MS initiated IMSI detach.
           - Network initiated IMSI detach.

      With this mechanism, the SPIRITS services can use the location
   information.
      For example, the Internet Call Waiting service can re-direct the



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                            [Page 9]


   call
      to a mobile phone.

           c) Supplementary Services Notification.

           This mechanism makes a SPIRITS server aware of a subscriber
   having         invoked one of the following supplementary services:
           Explicit Call Transfer, Call Deflection, Call Completion on
   Busy
           Subscriber, or Multi-Party.


7. PINT-related Requirements

   Before a SPIRITS service can be invoked, the relevant IP Host must be
   registered. Thus, Registration is an essential service (not yet
   addressed by PINT), which is initiated from the IP side. The
   registration information is ultimately used by the PSTN to
   authenticate the subscriber.

   Depending on the model, this can be done in two ways with the present
   architecture:

   1) The PINT Client issues the appropriate Register message over the
   interface A, which is then passed to by PINT server to the SPIRITS
   Proxy and SPIRITS Client:

   PINT C.: -- REGISTER --> PINT S. [--> SPIRITS Proxy --> SPIRITS C.].
   In this case the SPIRITS Client (co-located with the service control)
   is responsible for record keeping and the authentication.

   2) The PINT Client issues the appropriate Register message to the
   PINT Server, which then passes this information to the PSTN service
   control "by magic".

   The second model is much easier to handle, because it involves only
   one relevant interface ("A"); however it assumes no interworking
   between PINT and SPIRITS except that the SPIRITS Client finds "by
   magic" that a friendly and expecting IP Host is alive and well.

   Finally, in the event PINT is not implemented, the SIP SUBSCRIBE
   mechanism can be used.

   As noted in previous section, the existing SUBSCRIBE/NOTIFY PINT
   building blocks [3] must be extended for their use in SPIRITS for the
   purposes of setting DPs/getting DP event notifications. (A more
   general SIP mechanism for the same PINT-introduced block is described
   in [4]; it provides the necessary mechanism for specifying relevant
   events.)  Conversely, the same building blocks for this functional
   capabilities can be used in both PINT and SPIRITS protocols. Note,
   however, that in SPIRITS the PSTN notification may arrive without a
   particular subscription to an event (in the case of a statically set
   DP).




SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                           [Page 10]


8. Follow-up on Event Notifications

   The requirements of this section are neither PINT-specific, nor IN-
   specific; their role is to outline the remaining element necessary
   for the delivery of the SPIRITS service, which is the reaction to the
   notification received.

   In a particular scenario where

   a) The IP subscriber registers a SPIRITS service;

   b) A call triggering the SPIRITS service is received (and
   notification is sent); and

   c) The call disposition is performed by the end user,

   the signalling flow is demonstrated in Figure 2.


                   |---->  REGISTER  ----->|
           SPIRITS |<----   EVENT    <-----|SPIRITS
            Proxy  |----> DISPOSITION ---->| Client
                   |                   |
                                       |
                                       |
                                       |
                                       V
                                 Service Control
                                       |
                                       |
                                       V
                                      SSP

           Figure 2: Sequence of SPIRITS actions




   One of the following actions is required by benchmark services:

   a) Accept the incoming call.

   b) Reject the incoming call.

   c) Redirect the incoming call.

   d) Accept the call via VoIP (this particular item is outside
      of the scope of SPIRITS WG).

   Accordingly, the SPIRITS protocol should define the following message
   types:

   a) S->P: <Accept Call>




SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                           [Page 11]


   b) S->P: <[Reject Call],[Cause]>

   c) S->P: <[Redirect Call],[Redirection Destination]>


   8. Methodology

   To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set
   of messages), the PSTN events associated with each detection point of
   the Basic Call State Model should be examined. To date, the CS-2 BSCM
   has the richest set of DPs, although not all switching exchanges have
   implemented it.

   To determine the MINIMUM information available to the SPIRITS client
   (this information is to be carried by the SPIRITS protocol from
   SPIRITS client to SPIRITS server), each DP-specific information
   elements needs to be examined.

   Parameters should be event-specific, the folowing generic types of
   parameters are expected to be mandatory:

           - timer (for no answer)

           - midcall control info (for mid_call)

           - number of digits (for collected_information)


10. Security Considerations

   It is assumed that the interface C is between trusted entities. Thus,
   there are no particular IN-related or  requirements to the protocol
   pertinent to this interface. The assumption that the PINT Client and
   SPIRITS Server are co-located dictates that the security
   considerations for the A and B interfaces are exactly same.



11. Acknowledgements

   The authors are grateful to all participants in the SPIRITS group for
   the discussion that has been shaping this work. Many thanks go to
   Jorgen Bjorkner, Jim Buller, Lawrence Conroy, Soren  Nyckelgard, and
   John Voelker for his incisive comments.

12. References

   [1] Slutsman, L (Ed.) et al, The Spirits Architecture, <draft-ietf-
   spirits-architecture.01.txt>, Work in Progress. February 2001.

   [2] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang,
   S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard,
   J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-
   Initiated Services." RFC 2995, November 2000.



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                           [Page 12]


   [3] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions
   to SIP and SDP for IP Access to Telephone Call Services, Proposed
   Standard. RFC 2848, June 2000.

   [4] A. Roach, Event Notification in SIP, <draft-roach-sip-subscribe-
   notify-01.txt>, Work in Progress. October 2000.

   [5]  Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
   2045, November 1996.

   [6]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

   [7]  Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
   "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [8]  Handley, M. and  V. Jacobsen, "SDP: Session Description
   Protocol", RFC 2327, April 1998.





   13. Authors' Addresses

   Lev Slutsman
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, New Jersey, 07748
   Phone: (732) 420-3752
   Email: lslutsman@att.com

   Igor Faynberg
   Bell Labs/Lucent Technologies
   Room 4C-611A, 101 Crawfords Corner Road
   Holmdel, New Jersey, 07733
   Phone: (732) 949-0137
   Email: faynberg@lucent.com

   Jorge Gato
   Airtel Movil, S.A.
   Avda de Europa, 1.
   28108 Alcobendas (Madrid). Spain
   Tel: +34 607 13 31 10
   Fax. +34 607 13 30 57
   Email: jgato@airtel.es


   Hui-Lan Lu
   Bell Labs/Lucent Technologies
   Room 4C-607A, 101 Crawfords Corner Road
   Holmdel, New Jersey, 07733
   Phone: (732) 949-0321



SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001





<draft-faynberg-spirits-reqs-00.txt>                           [Page 13]

   Email: huilanlu@lucent.com


   Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved. This
   document and translations of it may be copied and furnished to others,
   and derivative works that comment on or otherwise explain it or assist
   in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.




























SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman             February 2001


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/