Authentication, Authorization and Accounting Frank M. Alfano
Internet Draft Peter J. McCann
Document: draft-alfano-aaa-qosreq-00.txt Tom Towle
Expires: December 2003 Richard Ejzak
Lucent Technologies
June 2003
Requirements for a QoS AAA Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. 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.
Abstract
This document describes requirements for a protocol that would
perform Authentication, Authorization, and Accounting for Quality-of-
Service reservations. This protocol would be used by elements along
the path of a given application flow to authenticate a reservation
request, ensure that the reservation is authorized, and to account
for resources used during the life of the application flow. A QoS
AAA protocol should also support dynamic authorization of QoS as a
function of application and account state. While we assume the
existence of some QoS reservation protocol to allow endpoints to
request QoS from network elements, complete requirements for such a
protocol are outside the scope of this document and a QoS AAA
protocol could be used to support more than one kind of reservation
protocol. A QoS AAA protocol could be used between any bearer-level
network element that lies along the path of an application flow and
an application server that lies anywhere in the network, allowing for
a wide variety of flexible service deployment models.
Alfano, McCann Expires - December 2003 [Page 1]
Requirements for QoS-AAA June 2003
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................6
3. Term Definitions...............................................6
4. Generic Requirements on a QoS Reservation Signaling Protocol...7
4.1 Identity Information.......................................7
4.2 Flow Information...........................................7
4.3 Authentication Information.................................8
5. Generic Requirements on a QoS AAA Protocol.....................8
5.1 Inter-domain Support.......................................8
5.2 Identity-based Routing.....................................8
6. Requirements for QoS Authentication............................8
6.1 Authentication Check.......................................8
7. Requirements for QoS Authorization.............................9
7.1 Flow Information...........................................9
7.2 Application State Pointer..................................9
7.3 Dynamic Authorization......................................9
7.4 Bearer Gating..............................................9
8. Requirements for QoS Accounting...............................10
8.1 Accounting Records........................................10
8.2 Accounting Rules..........................................10
8.3 Sending Accounting Records................................10
8.4 Loss of Bearer Notification Requirements..................10
8.5 Accounting Correlation....................................11
9. Interaction with other AAA Applications.......................11
10. Use Scenario.................................................12
10.1 Bearer Gating............................................12
10.2 Loss of Bearer...........................................13
11. Security Considerations......................................13
12. Reference....................................................13
13. Author's Addresses...........................................14
1. Introduction
To meet the quality-of-service needs of applications such as voice-
over-IP, it will often be necessary to explicitly request resources
from the network. This will allow the network to identify packets
belonging to such application flows and ensure that bandwidth, delay,
and error rate requirements are met. By performing admission control
on individual flows, the network can avoid congestion and the
resulting high packet drop rates.
Not every network deployment requires explicit reservation: for
example, if the network resources are provisioned far in excess of
demand, there will never be any contention for those resources and
Alfano et al. Expires - December 2003 [Page 2]
Requirements for QoS-AAA June 2003
there will be no need to manage them with a reservation protocol.
Also, if the transport or application layers can provide self-
correcting congestion control, it may be possible to operate the
network even with high utilization and still meet the QoS
requirements of the various applications. However, when bandwidth is
expensive and must be carefully managed, such as in wide-area
cellular networks, and/or when applications and transport protocols
lack the capability or cannot be trusted to perform congestion
control, explicit reservation techniques are required. Note that a
reservation protocol might be used regardless of the mechanisms used
to enforce QoS, e.g., IntSrv or DiffSrv.
A variety of protocols could be used to make a reservation request,
such as:
1. RSVP.
2. NSIS.
3. Link-specific means.
4. SIP/SDP.
The most obvious choice, RSVP [2], is the existing IETF-defined
reservation protocol. For a variety of reasons, RSVP has not seen
widespread deployment as an end-to-end reservation protocol. The new
Next Steps in Signaling (NSIS) work [3] currently being undertaken
may address some of these issues. In the meantime, deployments such
as 3rd generation cellular networks are defining their own
reservation procedures: these include link-specific means, such as
the PDP Context Activation procedures of 3GPP [4,5] or the service
instance establishment procedures of 3GPP2 [6]. Also, these
procedures are often tightly coupled to the application, and in the
3GPP/3GPP2 IP Multimedia Core Network subsystems, one could even say
that the Session Initiation Protocol (SIP) [7] and Session
Description Protocol (SDP) [8] are being used to request resource
reservations from the network. This tight coupling is in the form of
private interfaces between the bearer elements (GGSN, PDSN) and the
SIP application servers. For example, when a first-hop wireless
router receives a request for radio-link QoS, it might interact with
the nearest SIP proxy to see if the request should be authorized.
There are several inter-related reasons that are often cited for the
tight coupling. First, application knowledge is sometimes needed to
authorize the use of bearer resources; for example, a SIP-layer
application might authorize (and later, account for and charge) the
use of the bearer on behalf of a party other than the one requesting
it. Also, the application server might enable/disable ("gate") the
bearer flow according to the high-level state of the call. Second,
applications can often be enhanced if knowledge about the bearer is
available. For instance, when a mobile node is suddenly disconnected
from the network, application servers can generate BYE messages to
Alfano et al. Expires - December 2003 [Page 3]
Requirements for QoS-AAA June 2003
terminate the call with the other party. Also, application servers
implementing an emergency call might provide higher priority access
and might also require the bearer elements to provide location
information about the device being used to place the call. Finally,
the operator may wish to correlate accounting records from the bearer
path with those from the application layer. Such correlation might
be used to provide alternative billing or settlement with 3rd
parties.
Despite the advantages of closer coupling between application and
bearer, the use of private, local interfaces between SIP servers and
the bearer path leads to several disadvantages:
* Use of SIP servers other than the ones provided by the operator
becomes more difficult.
* Deployment of some new applications requires close coordination
with the network operator.
* It becomes impossible to handle mobility at the network layer
when a change in the bearer element point of attachment to the
Internet requires a change in the associated SIP server.
* Use of protocols other than SIP to establish sessions becomes
impossible.
All of these drawbacks can be viewed as a result of the conflict
between the SIP-based reservation architecture and the end-to-end
service model espoused by most Internet architects, which emphasizes
a narrow interface between application, transport, and network. Any
widening of these interfaces must be done in a carefully controlled
way that preserves the openness, robustness, and flexibility of the
Internet. Such interfaces must support inter-domain operation,
imposing no limitations on where application servers can be placed,
and allowing for a clean layering so as not to interfere with
network-layer functionality.
To meet the requirements of network operators while at the same time
preserving the best of the end-to-end Internet service model, we
propose that a AAA protocol be developed that can be used by bearer
elements to authenticate, authorize, and account for individual
application flows that require QoS. A high-level picture of the
resulting architecture is shown in Figure 1.
Alfano et al. Expires - December 2003 [Page 4]
Requirements for QoS-AAA June 2003
+------+ +------+
| Subs | | |
| DB | | AS |
| | | |
+---\--+ +---/--+
\ /
\ /
/-\----------/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+---+--+
Application | |
Flow ===============+ BE +==========>>
| |
+------+
Figure 1. An architecture supporting QoS-AAA
Figure 1 depicts a bearer element through which application flows
need to pass, a cloud of AAA servers, a database containing
subscriber records, and an application server. Here the term "AAA
Cloud" is used to refer to the network of AAA proxy/broker
arrangements that may be in place. Also, note that there may be more
than one bearer element that needs to interact with the AAA cloud
along the path of a given application flow, although the figure only
depicts one for clarity. Similarly, a given user may have subscriber
records stored in more than one place and might make use of multiple
application servers. In the simplest case, bearer elements will
request authentication and authorization for QoS from the AAA cloud,
which will route the request to the home network and consult a static
subscriber record of the endpoint making the request and return a
grant/deny decision. In more complex deployment models, the
authorization will be based on dynamic application state, so the
request must be authenticated and authorized based on information
from one or more application servers. If defined properly, the
interface between the bearer element and AAA cloud would be identical
in both cases. Bearer elements are therefore insulated from the
details of particular applications and need not know that application
servers are involved at all. Also, the AAA cloud would naturally
encompass business relationships such as those between network
operators and third-party application providers, enabling flexible
intra- or inter-domain authorization, accounting, and settlement.
Alfano et al. Expires - December 2003 [Page 5]
Requirements for QoS-AAA June 2003
The remainder of this document outlines high-level requirements for
the QoS AAA protocol. Section 3 defines some terms that are used in
subsequent discussion. Section 4 describes a small number of generic
requirements on a QoS reservation protocol. Section 5 gives generic
requirements for a QoS AAA protocol. Section 6 gives requirements
specific to Authentication. Section 7 gives requirements specific to
Authorization. Section 8 gives requirements specific to Accounting.
Section 9 discusses the relationship of a QoS AAA protocol to other
AAA applications. Section 10 gives an example use scenario.
Finally, Section 11 outlines some security considerations.
2. Conventions used in this document
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 [9].
3. Term Definitions
Accounting Rules
An accounting rule is a collection of data that identifies one
or more IP flows and provides related information. An accounting
rule defines the accounting treatment such as on-line or off-
line accounting. The data may also identify, for example, volume
or time based accounting, rating information, termination
actions for on-line accounting (e.g., drop or re-route packets),
record correlation identifiers, etc.
Application Server
An application server is a network entity that exchanges
signaling messages with an application endpoint. It may be a
source of authorization for QoS-enhanced application flows. For
example, a SIP server is one kind of application server.
Application Endpoint
An application endpoint is an entity in an end user device that
exchanges signaling messages with application servers or
directly with other application endpoints. Based on the result
of this signaling, the endpoint will make a request for QoS from
the network. For example, a SIP User Agent is one kind of
application endpoint.
Authorizing Entity
The authorizing entity is that entity responsible for
authorizing QoS for a particular application flow. This may be
a home subscriber database or an application server.
Alfano et al. Expires - December 2003 [Page 6]
Requirements for QoS-AAA June 2003
Bearer Element
A bearer element is a network entity such as an IP router on the
path between two endpoints, through which IP packets belonging
to application flows pass. Note that only a subset of the bearer
elements along a path are required to process and authorize QoS
requests. In a typical service provider scenario, the first-hop
router (NAS) will be required to play this role.
Subscriber Database
A Subscriber Database holds information related to network users
such as what services they have signed up for. In particular, a
user may subscribe to QoS independent of any application, which
would enable authorization for QoS without consultation of an
application server.
Termination Actions
On-line accounting allows for the on-line accounting
authorization entity to terminate flows in real time. A
termination action defines the action to be taken by the bearer
element for the case where a flow has been terminated. For
example flow packets might be dropped, might be redirected, or
might be allowed to continue but not be counted.
4. Generic Requirements on a QoS Reservation Signaling Protocol
While the details of a particular QoS signaling protocol are outside
the scope of this document, we do list here some generic requirements
that any QoS signaling protocol must meet in order to act as a front
end for a QoS AAA protocol.
4.1 Identity Information
The QoS signaling protocol MUST carry information sufficient to
identify an authorizing entity for a QoS request.
For instance, the identity may be represented as the NAI of a user or
FQDN of an application server.
4.2 Flow Information
The QoS signaling protocol MUST carry information sufficient to
identify the application flow(s). However, the protocol MUST allow
flow information to be under-specified ("wild carded") in the case
when specific endpoints are not known at the time of resource
reservation.
Alfano et al. Expires - December 2003 [Page 7]
Requirements for QoS-AAA June 2003
Flow information would include elements such as IP addresses and port
numbers, so that intervening bearer elements can classify packets and
give them proper QoS treatment. Also, the flow information would be
used when consulting the subscriber profile or application servers
for authorization decisions.
4.3 Authentication Information
The QoS signaling protocol MUST be integrity protected.
For example, each message could carry a cryptographic message
authentication code to ensure that only valid requests are granted by
the network. This is especially important when a user is being held
responsible for charges associated with a QoS session. The
authentication information would be verified by the AAA
infrastructure before authorization is granted.
5. Generic Requirements on a QoS AAA Protocol
In this section we list some high-level requirements that must be met
by any QoS AAA protocol
5.1 Inter-domain Support
The QoS AAA protocol MUST support inter-domain operation where the
bearer elements, subscriber databases, and application servers can
each belong to different administrative domains.
5.2 Identity-based Routing
The QoS AAA protocol MUST route AAA requests to the authorizing
entity based on the identity information given in the QoS signaling
protocol.
6. Requirements for QoS Authentication
In this section we list some QoS AAA requirements specific to
authentication.
6.1 Authentication Check
The QoS AAA protocol MUST support verification of authentication
information present in QoS signaling messages.
Alfano et al. Expires - December 2003 [Page 8]
Requirements for QoS-AAA June 2003
7. Requirements for QoS Authorization
In this section we list some QoS AAA requirements specific to
authorization.
7.1 Flow Information
The QoS AAA protocol MUST carry flow information to and from the
authorizing entity. However, the protocol MUST allow flow information
to be under-specified ("wild carded") in the case when specific
endpoints are not known at the time of initial resource
authorization.
7.2 Application State Pointer
The QoS AAA protocol MUST carry information sufficient for an
application server to identify the appropriate application session.
Note that this requirement might be met by the same mechanism as for
requirement 7.1, if flow information alone is sufficient to identify
an application session.
7.3 Dynamic Authorization
The QoS AAA protocol MUST support dynamic authorization; that is, it
MUST be possible to push updates towards the bearer element(s) from
authorizing entities.
This requirement would support runtime changes to a subscriber
profile or application state transitions that would authorize/de-
authorize application flows.
7.4 Bearer Gating
Even though a given flow may be authorized, some applications may
want to toggle the flow on or off based on application state
transitions. This control is called bearer gating. In this case, a
capability separate from basic authorization must be provided,
because a negative authorization indication might lead to a failure
indication being passed during QoS signaling. Such a failure
indication would mislead the endpoint into thinking that its request
had been denied when in reality the bearer flow was merely
temporarily disabled.
Alfano et al. Expires - December 2003 [Page 9]
Requirements for QoS-AAA June 2003
The QoS AAA protocol MUST allow the authorizing entity to gate
authorized application flows.
8. Requirements for QoS Accounting
In this section we list some QoS AAA requirements specific to
accounting.
8.1 Accounting Records
The QoS AAA protocol MUST define QoS accounting records containing
duration or volume (bytecount) usage information, or both duration
and Volume usage information. The records MUST also contain a
description of the QoS attributes (e.g., bandwidth, delay, loss rate)
that were supported for the flow.
8.2 Accounting Rules
The QoS AAA protocol MUST allow the authorizing entity to transfer
accounting rules that are applicable to specific flows. These rules
would define the on-line ("pre-paid") versus off-line ("post-paid")
nature of the accounting as well as convey other associated
parameters such as record identifiers, rating information, usage
quota, on-line termination actions, etc.
The QoS AAA protocol MUST allow for accounting rules to be provided
at authorization time as well as to be pushed later as dynamic
updates.
8.3 Sending Accounting Records
The bearer element MUST send accounting records for a particular
application flow to the authorizing entity for that flow or to
another entity identified by the authorizing entity.
8.4 Loss of Bearer Notification Requirements
The QoS AAA protocol MUST allow the bearer element to report loss of
bearer to the authorizing entity.
Alfano et al. Expires - December 2003 [Page 10]
Requirements for QoS-AAA June 2003
8.5 Accounting Correlation
The QoS AAA protocol MUST support the exchange of sufficient
information to allow for correlation between bearer accounting
records and application accounting records.
For example, an application server might create and pass an
accounting correlation identifier to the bearer element. This
correlation identifier would be stored by the bearer element for
inclusion in subsequent accounting records. This would allow the
home network to link the bearer accounting information with
application layer accounting records emitted by an application
server.
9. Interaction with other AAA Applications
It is likely that an endpoint attached to a first-hop bearer element
was authenticated and authorized for basic, best-effort Internet
access prior to requesting any special QoS from the network. If the
subscriber database for basic network access is the same as the one
containing a QoS subscription, it may be expeditious to define some
interactions between the AAA protocol used for basic access (e.g.,
NASREQ [10]) and the one outlined here for QoS. For example, it may
be useful to return some QoS-related attributes to the first-hop
bearer element at the time the endpoint is granted basic, best-effort
access. This would allow for some future QoS requests to be granted
based on the cached profile, rather than requiring a round-trip to
the home subscriber database. This gives rise to the following
requirement:
The QoS AAA protocol MUST define a QoS profile that can be re-used in
other AAA applications.
Also, it may be useful to allow application servers to push QoS
authorization information to a bearer element prior to any explicit
request from the endpoint. This could support application endpoints
that do not support an explicit QoS signaling mechanism. In this
case, the authorization may be pushed via the home AAA server, which
presumably knows to which NAS the endpoint is currently attached.
Alternatively, the QoS AAA protocol may define some sort of
redirection facility that would allow application servers to send AAA
messages directly to selected bearer elements such as a NAS. This
operation could be considered a special case of dynamic authorization
where no explicit request for QoS was made prior to the
authorization:
Alfano et al. Expires - December 2003 [Page 11]
Requirements for QoS-AAA June 2003
The QoS AAA protocol MUST support dynamic authorization initiated by
the authorizing entity.
10. Use Scenario
This section provides an example use case for the proposed
application.
An application in a host computer (application endpoint) wants to
open a video session with a video server. The application endpoint
and the video server negotiate the resources to be used for the
session and for which the application will be financially
responsible. When negotiation of resources has completed, the video
server stores the resource information and assigns a session
identifier to the information that can be used as the primary key for
later information queries. This identifier is passed to the
application endpoint.
The application endpoint makes a request for resources from the
bearer element. The video server and the bearer element will verify
that the application endpoint has not requested more resources than
what were negotiated and for which the application has agreed to be
financially responsible. To enable the authorization of the bearer
requested resources, the application endpoint passes the session
identifier received from the video server to the bearer element via
the QoS signaling protocol. The bearer element makes a request to
the video server identified in the session identifier. The video
server passes the relevant QoS state information to the bearer
element in an answer message, associating the origin host information
from the request with the state information stored by the video
server. (This can then be used later for pushing information to the
bearer element.) Included in the answer message is an accounting
correlation id to be included in all accounting messages from the
bearer entity.
10.1 Bearer Gating
The video server can control the flow of packets on the bearer
element by sending packet flow gating information in the answer
message delivered for resource authorization. If the flow of packets
is not immediately enabled, some event at the video server will
trigger the server to enable the flow. The video server sends a
request containing flow gating information to the bearer element to
allow the flow of packets. The bearer element returns the state of
the packet flow in the response message to the video server.
Alfano et al. Expires - December 2003 [Page 12]
Requirements for QoS-AAA June 2003
10.2 Loss of Bearer
The bearer element determines that bearer connectivity of the
application flow has been lost. The video server needs this
information in order to take corrective action, charge appropriately,
and/or release resources associated with the session. The bearer
element informs the video server of the loss of bearer in a request
message containing bearer state information. The video server
acknowledges the request in an answer message. The video server may
then issue a session abort request message to other network
functional entities.
11. Security Considerations
The QoS AAA protocol whose requirements are given in this draft
assumes that a security relationship exists between the authorizing
entity (the home AAA server or application server) and the bearer
element (AAA client). This relationship implies that the bearer
element should grant service based on the say-so of the authorizing
entity, presumably because the used resources will be paid for in
some later settlement phase. The relationship may be direct or it
may be indirect via a AAA cloud consisting of brokers and proxies.
Each link in this chain of relationships MUST be secured to prevent
spoofed authorizations.
The authentication outlined in Section 6 MUST be cryptographically
strong and protected against replay and other attacks.
Once QoS resources have been authorized, it may be possible for an
unauthorized party to subvert them for its own use. Steps MUST be
taken to bind the authorization to the actual flow of packets using
the QoS bearer in the bearer element. Actual mechanisms applied to
the bearer traffic for this purpose might include, e.g., ingress
filtering and/or IPSec, but in general are beyond the scope of a QoS
AAA protocol.
12. Reference
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
Alfano et al. Expires - December 2003 [Page 13]
Requirements for QoS-AAA June 2003
[3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and
Van den Bosch, S., "Next Steps in Signaling: Framework", draft-
ietf-nsis-fw-02.txt, March 2003. Work In Progress.
[4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling
Flows", April 2003.
[5] 3GPP TS 29.207, "Policy control over Go interface", March 2003.
[6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for
Spread Spectrum Systems."
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-13.txt, May
2003. Work In Progress.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
Network Access Server Application", draft-ietf-aaa-diameter-
nasreq-11.txt, February, 2003. Work In Progress.
13. Author's Addresses
Frank M. Alfano
Lucent Technologies
Rm 9C-226L
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7209
Email: falfano@lucent.com
Peter J. McCann
Lucent Technologies
Rm 9C-226R
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 713 9359
Email: mccap@lucent.com
Alfano et al. Expires - December 2003 [Page 14]
Requirements for QoS-AAA June 2003
Thomas T. Towle
Lucent Technologies
Rm 9C-229
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7303
Email: ttowle@lucent.com
Richard Ejzak
Lucent Technologies
Rm 7H-245
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7036
Email: ejzak@lucent.com
Intellectual Property Statement
At the time of submission the authors are not aware of any
intellectual property rights that pertain to the implementation or
use of the technology described in this document. However, this does
not preclude the possibility that Lucent Technologies, Inc. or other
entities may have such rights. The patent licensing policy of Lucent
Technologies, Inc. is on file with the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
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 practice
this standard. Please address the information to the IETF Executive
Director.
Alfano et al. Expires - December 2003 [Page 15]
Requirements for QoS-AAA June 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 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.
Alfano et al. Expires - December 2003 [Page 16]