INTERNET DRAFT Jari Arkko
Category: Standards Track Oy LM Ericsson Ab
Title: draft-calhoun-diameter-accounting-04.txt Pat R. Calhoun
Date: March 2000 Sun Microsystems, Inc.
Pankaj Patel
Convergys Corporation
Glen Zorn
Cisco Systems, Inc.
DIAMETER Accounting Extension
Status of this Memo
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
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.
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
The DIAMETER protocol provides Authentication and Authorization for
dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has
Arkko et al. expires September 2000 [Page 1]
INTERNET DRAFT March 2000
been working on an accounting data format, called Accounting Data
Interchange Format (ADIF) [10], as a method to transfer accounting
information over a wide variety of transports.
This extension describes how accounting records can be securely
transmitted over the DIAMETER protocol. When combined with the
Strong Security [9] extension, accounting records MAY traverse
intermediate proxies in a secure fashion and is compatible with
the referral broker model. This extension allows for both
real-time and batched accounting transfers.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Authorization-Server Directed Model
1.3 Protocol Messages
1.4 Fault Resilience
1.5 Session Records
1.6 Accounting in brokering environments
2.0 Command-Codes AVP Values
2.1 Accounting-Request (ACR) Command
2.2 Accounting-Answer (ACA) Command
2.3 Accounting-Poll-Ind (ACP) Command
3.0 Mandatory AVPs
3.1 Accounting-Record-Type AVP
3.2 ADIF-Record AVP
3.3 Accounting-Interim-Interval AVP
3.4 Accounting-Delivery-Max-Batch AVP
3.5 Accounting-Delivery-Max-Delay AVP
3.6 Accounting-Record-Number AVP
4.0 IANA Considerations
5.0 Security Considerations
6.0 Acknowledgments
7.0 References
8.0 Authors' Addresses
9.0 Full Copyright Statement
1.0 Introduction
This accounting protocol is based on an authorization-server directed
model with capabilities for both efficient batch and fast real-time
delivery of accounting information. Several fault resilience methods
[11] have been built in to the protocol in order minimize loss of
accounting data in various fault situations and under different
assumptions about the capabilities of the used devices.
Arkko et al. expires September 2000 [Page 2]
INTERNET DRAFT March 2000
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [6].
1.2 Authorization-Server Directed Model
The authorization-server directed model means that at authorization
time, the device generating the accounting data gets information from
the authorization server regarding the way accounting data shall be
forwarded. This information includes accounting record timeliness
requirements.
As discussed in [11], batch transfer of accounting data is more CPU-
and bandwidth efficient than real-time transfer. However, there are
many applications where real-time transfer is a requirement for at
least some of the accounting records. These applications include
roaming, where most (local) accounting records can be transferred in
batch mode, but roaming (visiting) accounting records should be
transferred fast due to the needs of credit limit checks and fraud
detection. For these reasons this accounting protocol defines both
batch and real-time transfer modes, and allows their use
simultaneously. The authorization server (chain) directs the
selection of proper transfer strategy, based on its knowledge of the
user and relationships of roaming partnerships. The server (or
proxies in between) use the Accounting-Delivery-Max-Batch,
Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs
to control the operation of the DIAMETER peer operating as a client.
The first two attributes set the requirements in terms of number of
records and maximum delay before accounting data transfer for this
session SHOULD begin. The DIAMETER peer acting as a client MAY
deliver the data earlier due to a full batch of records, device
reboot, lack of memory, or explicit configuration. The DIAMETER
client MUST begin the transfer in the given limits unless prevented
from doing so by network partitions, failures of peers, network
congestion, or client overload.
The Accounting-Interim-Interval AVP, when present, instructs the
DIAMETER node acting as a client to produce accounting records
continuously even during a session.
Typically, the authorization server uses a few batching/real-time
classes, such as the local users whose data might be transferred once
in an hour and the roaming users whose data would be transferred
immediately. Each Accounting-Delivery-Max-Batch / Accounting-
Delivery-Max-Delay AVP pair with different values forms one pool of
Arkko et al. expires September 2000 [Page 3]
INTERNET DRAFT March 2000
accounting data in the DIAMETER node acting as a client. That is, a
new record is placed to same pool as the previous one if the
authorization server returned same values for both AVPs and the pool
has not been emptied in between.
The Extension number for this draft is five (5). This value is used
in the Extension-Id Attribute value Pair (AVP) as defined in [7].
1.3 Protocol Messages
The DIAMETER peer, acting as a client, generating the accounting data
will use the Accounting-Request message to send one or more
accounting records to its peer. The receiver (server) MUST reply with
the Accounting-Answer message with appropriate confirmations.
It is possible that a DIAMETER Proxy breaks up a batch of accounting
records and sends them towards different DIAMETER Home servers. In
this case, it is possible that a separate Accounting-Answer message
contain the response for each block. Therefore, a DIAMETER node MUST
be prepared to handle this scenario.
Upon receipt of an Accounting-Request, a home DIAMETER server MUST
generate a response. A home server is the node that "owns" the realm
portion of the user's NAI. The response includes the Result-Code,
which MAY contain an error if the ADIF-Record, or some other AVP, is
not acceptable.
Each DIAMETER Accounting protocol message MAY be compressed using
IPComp [12] in order to reduce the used network bandwidth. DIAMETER
peers MUST use a negotiation mechanisms such as IKE [13] in order to
ensure that both peers are able to handle IPComp.
1.4 Fault Resilience
DIAMETER Base protocol [11] mechanisms are used to overcome small
message loss and network faults of temporary nature.
DIAMETER peers acting as clients MUST implement the use of alternate
servers to guard against server failures and certain network
failures. DIAMETER peers acting as servers or related off-line
processing systems MUST detect duplicate accounting records caused by
the sending of same record to several servers and duplication of
messages in transit. This detection MUST be based on the inspection
of the Session-Id [1] and Accounting-Record-Number AVP pairs.
DIAMETER clients MAY have non-volatile memory for the safe storage of
accounting records over reboots or extended network failures, network
Arkko et al. expires September 2000 [Page 4]
INTERNET DRAFT March 2000
partitions, and server failures. If such memory is available the
client SHOULD store new accounting records there as soon as the
records are created and until a positive acknowledgement of their
reception from the DIAMETER Server has been received. Upon a reboot,
the client MUST starting sending the records in the non-volatile
memory to the accounting server with appropriate modifications in
termination cause, session length, and other relevant information in
the records.
A further extension of this protocol may include AVPs to control how
many accounting records may at most be stored in the DIAMETER client
without committing them to the non-volatile memory or transferring
them to the DIAMETER server.
The client SHOULD NOT remove the accounting data from any of its
memory areas before the correct Accounting-Answer has been received.
The client MAY remove oldest, undelivered or yet unacknowledged
accounting data if it runs out of resources such as memory. It is an
implementation dependent matter for the client to accept new sessions
under this condition.
1.5 Session Records
In all accounting records the Session-Id AVP, ADIF-Record AVP, and
User-Name AVPs MUST be present. If strong authentication is required,
as described in [9], the CMS-Data AVP may be used to authenticate the
ADIF-Record AVP. It is not typically necessary, nor recommended, that
the strong authentication cover any additional AVPs since the ADIF-
Record, and associated CMS-Data, MAY need to be submitted to a third
party (see section 1.6 below).
However, if the accounting records are being in sent in batch mode,
the sender can create several "blocks" of accounting records by
making use of the AVP Tag field (bit 'T' [1]). Each block has a
unique tag value, and an optional CMS-Data AVP. If it is known that
multiple ADIF-Records are being sent to the same home DIAMETER
server, it is possible to have one CMS-Data AVP cover multiple the
ADIF-Records. This optimization reduces the crypto computation that
would otherwise be necessary.
Different types of session records are sent depending on the actual
type of accounted service and the authorization server's directions
for interim accounting. If the accounted service is a one-time event,
meaning that the start and stop of the event are simultaneous, then
the Accounting-Record-Type AVP MUST be present and set to the value
EVENT_RECORD.
Arkko et al. expires September 2000 [Page 5]
INTERNET DRAFT March 2000
If the accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly,
INTERIM_RECORD. If the authorization server has directed interim
accounting to be enabled for the session, but no interim interval was
specified, two accounting records MUST be generated for each service
of type session. When the initial Accounting-Request is sent for a
given session is sent, the Accounting-Record-Type AVP MUST be set to
the value START_RECORD. When the last Accounting-Request is sent, the
value MUST be STOP_RECORD.
If a specified interim interval exists, the DIAMETER client MUST
produce additional records between the START_RECORD and STOP_RECORD,
marked INTERIM_RECORD. The production of these records is directed
both by Accounting-Interim-Interval as well as any re-authentication
or re-authorization of the session. If a batch size of greater than
1 has been specified by the authorization server, then the DIAMETER
client MUST ensure that new interim records overwrite previous
interim records for the same session and batch as this reduces the
amount of memory required to store the records. In effect, this means
that interim records are delivered at least as often as dictated by
Accounting-Delivery-Max-Delay.
1.6 Accounting in brokering environments
The DIAMETER base protocol [1] describes brokers that provide
redirect services, by allowing AAA servers within a roaming
consortium to directly communicate. Referral services can be secured
using the strong security extension defined in [9]. Since brokers can
also provide settlement services, they typically need to be aware of
the accounting information exchange, and since they are no longer
part of the message exchange, the DIAMETER protocol MUST allow the
broker to receive the accounting record. The strong security [9]
provides the broker with the assurances it needs that both parties
agreed with the accounting information submitted.
When the local AAA server issues an Accounting-Request to the home
AAA server, it includes an ADIF-Record AVP as well as a CMS-Data AVP
[9], which contains the signature of the local AAA server. The home
server MUST add it's own signature to the CMS-Data AVP, that covers
both the ADIF-Record and the local AAA's signature. The whole is
submitted to the local AAA server in the Accounting-Answer. The local
AAA server MUST submit the ADIF-Record, and associated CMS-Data AVP
to the broker. The broker can verify that both parties participated
and accepted the accounting record, by validating the signatures.
2.0 Command-Codes AVP Values
Arkko et al. expires September 2000 [Page 6]
INTERNET DRAFT March 2000
This section defines new Command-Code [1] values that MUST be
supported by all DIAMETER implementations that conform to this
specification. The following Command Codes are currently defined in
this document:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Accounting-Request ACR 271 2.1
Accounting-Answer ACA 272 2.2
Accounting-Poll-Ind ACP 273 2.3
2.1 Accounting-Request (ACR) Command
The Accounting-Request command, indicated by the Command-Code AVP set
to 271, is sent by a DIAMETER node, acting as a client, in order to
exchange accounting information with a peer. The Accounting
information is contained within an ADIF record, as described in [10].
The Accounting-Request command MAY contain accounting information for
more than a single session, which allows it to send batched
accounting information. When the batch mode is used, the session-Id
AVP [1] MUST be present and the CMS-Data AVP [9] MAY be present, and
MUST have a tag of the same value as the ADIF-Record AVP. When the
Accounting-Request is being submitted to a broker, and includes the
CMS-Data AVP [9], the CMS-Data AVP MUST be signed by both the local
and home DIAMETER server using the countersignature procedures
described in [9].
Message Format
<Accounting-Request> ::= <DIAMETER Header>
<Command-Code AVP = 271>
<Host-Name AVP>
(<Session-Id AVP> &&
<Accounting-Record-Type> &&
<Accounting-Record-Number> &&
<User-Name AVP> &&
<ADIF-Record AVP> &&
<CMS-Data AVP>)
[<Timestamp AVP>
<Nonce AVP>
<Integrity-Check-Value AVP>]
2.2 Accounting-Answer (ACA) Command
Arkko et al. expires September 2000 [Page 7]
INTERNET DRAFT March 2000
The Accounting-Answer command, indicated by the Command-Code AVP set
to 272, is used to acknowledge an Accounting-Request command. The
Accounting-Answer command contains the same Session-Id and ADIF-
Record AVPs that were sent in the Accounting-Request command. This
can be signed using the CMS-Data AVP for strong AVP authentication,
which MAY be used for the purposes of repudiation.
Only the target DIAMETER Server, known as the home DIAMETER Server,
SHOULD respond with the Accounting-Answer command.
If the Accounting-Request command contained more than one ADIF-Record
AVP, the Accounting-Answer SHOULD contain the same number of ADIF-
Record AVPs. However, it is possible for the DIAMETER Server to
acknowledge each ADIF-Record in a separate response. This allows the
sender of the ADIF-Records to send a batch of records, whose final
destination are different.
Message Format
<Accounting-Answer> ::= <DIAMETER Header>
<Command-Code AVP = 272>
<Result-Code AVP>
<Host-Name AVP>
<Destination-NAI AVP>
(<Session-Id AVP> &&
<Accounting-Record-Number> &&
<ADIF-Record AVP> &&
<CMS-Data AVP>)
[<Timestamp AVP>
<Nonce AVP>
<Integrity-Check-Value AVP>]
2.3 Accounting-Poll-Ind (ACP) Command
The Accounting-Poll-Ind command, indicated by the Command-Code AVP
set to 273, is sent by a DIAMETER Server in order to force the peer
to send current accounting data. This data MUST include not yet sent
accounting records from completed sessions, as well as INTERIM_RECORD
records from all ongoing sessions.
The receiver MUST use the Accounting-Request command to send the
accounting data.
The use of Accounting-Poll-Ind is useful in situations where a
DIAMETER server comes up after an unscheduled downtime, and wishes to
synchronize with the client(s) sooner than at the end of the next
INTERIM_RECORD or at the end of a session.
Arkko et al. expires September 2000 [Page 8]
INTERNET DRAFT March 2000
Warning: The use of the Accounting-Poll-Ind message is discouraged in
roaming networks, since it is unfeasible for a server to attempt to
poll all of it's roaming partner's DIAMETER peers.
Message Format
<Accounting-Poll-Ind> ::= <DIAMETER Header>
<Command-Code AVP = 273>
<Host-Name AVP>
<Destination-NAI AVP>
[<Timestamp AVP>
<Nonce AVP>
<Integrity-Check-Value AVP>]
3.0 Mandatory AVPs
The following table describes the DIAMETER AVPs defined in the Mobie
IP extension, their AVP Code values, types, possible flag values and
whether the AVP MAY be encrypted.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section Value | | |SHLD| MUST|MAY |
Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Accounting- 480 3.1 Integer32| M | T,P | | V | Y |
Record-Type | | | | | |
ADIF-Record 481 3.2 Data | M | T,P | | V | Y |
Accounting- 482 3.3 Integer32| M | P | | T,V | Y |
Interim-Interval | | | | | |
Accounting- 483 3.4 Integer32| M | P | | T,V | Y |
Delivery-Max-Batch | | | | | |
Accounting- 484 3.5 Integer32| M | P | | T,V | Y |
Delivery-Max-Delay | | | | | |
Accounting- 485 3.6 Integer32| M | P | | T,V | Y |
Record-Number | | | | | |
3.1 Accounting-Record-Type AVP
The Accounting-Record-Type AVP (AVP Code 480) is of type Interger32
and contains the type of accounting record that can be found in the
corresponding ADIF-Record AVP. The following values are currently
defined for the Accounting-Record-Type AVP:
Arkko et al. expires September 2000 [Page 9]
INTERNET DRAFT March 2000
EVENT_RECORD 1
An Accounting Event Record is used to indicate a service of
indivisible nature has occurred. This record contains all
information relevant to the service, and is the only record of
the service.
START_RECORD 2
An Accounting Start, Interim, and Stop Records are used to
indicate that a service of a measurable length has been given.
An Accounting Start Record is used to initiate an accounting
session, and contains accounting information that is relevant
to the initiation of the session.
INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting
information for an existing accounting session. Interim
Accounting Records SHOULD be sent every time a re-
authentication or re-authorization occurs. The selection of
whether to use INTERIM_RECORD records is directed by the
Accounting-Interim-Interval AVP.
STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting
session and contains cumulative accounting information relevant
to the existing session.
3.2 ADIF-Record AVP
The ADIF-Record AVP (AVP Code 481) is of type Data and contains the
ADIF payload, as defined in [10].
3.3 Accounting-Interim-Interval AVP
The Accounting-Interim-Interval AVP (AVP Code 482) is of type
Integer32 and is sent from the DIAMETER authenticating/authorizing
server to the DIAMETER client. The client uses information in this
AVP to decide how and when to produce accounting records. With
different values in this AVP, service sessions can result in one,
two, or two+N accounting records, based on the needs of the home-
organization. The following accounting record production behaviour is
directed by the inclusion of this AVP:
1. The omission of the Accounting-Interim-Interval AVP or its
inclusion with Value field set to 0 means that EVENT_RECORD,
START_RECORD, and STOP_RECORD are produced, as appropriate for
the service.
Arkko et al. expires September 2000 [Page 10]
INTERNET DRAFT March 2000
2. The inclusion of the AVP with Value field set to a non-zero
value means that INTERIM_RECORD records MUST be produced
between the START_RECORD and STOP_RECORD records. The Value
field of this AVP is the nominal interval between these records
in seconds. The DIAMETER node that originates the accounting
information, known as the client, MUST produce the first
INTERIM_RECORD record roughly at the time when this nominal
interval has elapsed from the START_RECORD, the next one again
as the interval has elapsed once more, and so on until the
session ends and a STOP_RECORD record is produced.
The client MUST ensure that the interim record production times
are randomized so that large accounting message storms are not
created either among records or around a common service start
time.
3.4 Accounting-Delivery-Max-Batch AVP
The Accounting-Delivery-Max-Batch AVP (AVP Code 483) is of type
Integer32 and is included in an Accounting-Answer. This AVP controls
how accounting data is transferred to the accounting server. The AVP
sets the requirements in terms of number of locally collected records
before accounting data transfer SHOULD begin. The DIAMETER node that
receives this AVP MAY deliver the data earlier due to satisfying
requirements set by Accounting-Delivery-Max-Delay, device reboot,
lack of memory, or explicit configuration. The DIAMETER node MUST
begin the transfer in the given limits unless prevented from doing so
by network partitions, client or server failures, network congestion,
or client overload.
3.5 Accounting-Delivery-Max-Delay AVP
The Accounting-Delivery-Max-Delay AVP (AVP Code 484) is of type
Integer32 and is included in an Accounting-Answer. This AVP controls
how accounting data is transferred to the authorization request. The
AVP sets the requirements in terms of maximum delay before accounting
data transfer SHOULD begin. The DIAMETER node that receives this AVP
MAY deliver the data earlier due to satisfying requirements set by
Accounting-Delivery-Max-Batch, device reboot, lack of memory, or
explicit configuration. The DIAMETER node MUST begin the transfer in
the given limits unless prevented from doing so by network
partitions, client or server failures, network congestion, or client
overload.
3.6 Accounting-Record-Number AVP
Arkko et al. expires September 2000 [Page 11]
INTERNET DRAFT March 2000
The Accounting-Record-Number AVP (AVP Code 485) is of type Integer32
and identifies this record within one session. As Session-Id AVPs are
globally unique, the combination of Session-Id and Accounting-
Record-Number AVPs is also globally unique, and can be used in
matching accounting records with confirmations. An easy way to
produce unique numbers is to set the value to 0 for records of type
EVENT_RECORD and START_RECORD, and set the value to 1 for the first
INTERIM_RECORD, 2 for the second, and so on until the value for
STOP_RECORD is one more than for the last INTERIM_RECORD.
4.0 IANA Considerations
The command codes defined in Section 2.0 are values taken from the
Command-Code AVP [1] address space and extended in [2], [3] and [9].
IANA should record the values as defined in Section 2.0.
The AVPs defined in section 3.0 and 5.0 were alllocated from from the
AVP numbering space defined in [1], and extended in [2], [3] and [9].
IANA should record the values as defined in Section 3.0.
This document introduces the Accounting-Record-Type AVP, which
contains pre-defined values. This document defines the values 1-3.
All remaining values are available for assignment via a Designated
Expert [8].
5.0 Security Considerations
This DIAMETER extension assumes that the accounting data is secured
either through a hop-by-hop authentication mechanism, as described in
[1], or using a strong authentication mechanism as defined in [9].
6.0 Acknowledgments
The authors would like to thank Nenad Trifunovic, Tony Johansson and
Pankaj Patel for their participation in the Document Reading Party.
Thanks to the various people that have contributed to accounting
related requirements at the IETF's AAA Working Group and other
related WGs.
7.0 References
[1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base
Protocol", draft-calhoun-diameter-13.txt, IETF work in progress,
March 2000.
Arkko et al. expires September 2000 [Page 12]
INTERNET DRAFT March 2000
[2] P. Calhoun, W. Bulley, A. Rubens, J. Haag. "DIAMETER NASREQ
Extension", draft-calhoun-diameter-nasreq-02.txt, IETF work in
progress, March 2000.
[3] P. Calhoun, C. Perkins. "DIAMETER Mobile IP Extension", draft-
calhoun-diameter-mobileip-06.txt, IETF work in progress, March
2000.
[4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)." RFC 2138, April
1997.
[5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] G. Zorn, P. Calhoun. "Limiting Fraud in Roaming", draft-ietf-
roamops-fraud-limit-00.txt, IETF work in progress, May 1999.
[8] Narten, Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998
[9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
Extension", draft-calhoun-diameter-strong-security-02.txt, IETF
work in progress, March 2000.
[10] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
(ADIF)", draft-ietf-roamops-actng-06.txt, IETF work in progress,
August 1999.
[11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting
Management", draft-ietf-aaa-acct-00.txt, IETF work in progress,
January 2000.
[12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.
[13] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998.
8.0 Authors' Addresses
Questions about this memo can be directed to:
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256
E-Mail: Jari.Arkko@ericsson.com
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Arkko et al. expires September 2000 [Page 13]
INTERNET DRAFT March 2000
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Pankaj Patel
Convergys Corporation
4600 Montgomery Road
Cincinnati, OH 45212
USA
Phone: 1-513-723-2018
E-Mail: pankaj.patel@convergys.com
Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
USA
Phone: +1 425 468 0955
E-Mail: gwz@acm.org
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
Arkko et al. expires September 2000 [Page 14]
INTERNET DRAFT March 2000
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.
Arkko et al. expires September 2000 [Page 15]