Network Working Group U. Bodin
Internet-Draft Operax
Expires: September 2, 2007 A. Doria
Lulea University of Technology
B. Chatras
France Telecom
S. Norreys
BT
March 1, 2007
Auditing Functionality in Diameter
draft-bodin-dime-auditing-reqs-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Diameter is being increasingly included in the work of other
standards organizations and has become a key protocol in many
architectures. One of the uses of Diameter includes setting and
Bodin, et al. Expires September 2, 2007 [Page 1]
Internet-Draft Auditing Functionality in Diameter March 2007
maintaining hard-state and soft-state during failover and in the
event of delayed refresh messages respectively. Often there is a
need to query for information on active sessions for backup or
synchronization purposes.
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of hard and soft state reservations . . . . . 3
2.2. Replication . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Diameter used for hard-state reservations . . . . . . . . 4
2.3.1. In the case of failover without replication . . . . . 4
2.3.2. In the case of failover with replication . . . . . . . 5
2.4. Diameter used for soft-state reservations . . . . . . . . 5
2.5. Required Mechanisms . . . . . . . . . . . . . . . . . . . 6
3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Diameter Resource Management Extensions . . . . . . . . . . . 6
4.1. Original Abstract . . . . . . . . . . . . . . . . . . . . 7
4.2. Original Introduction . . . . . . . . . . . . . . . . . . 7
4.2.1. State synchronization . . . . . . . . . . . . . . . . 8
4.3. Command-Code Values . . . . . . . . . . . . . . . . . . . 9
4.3.1. Session-Resource-Query (SRQ) . . . . . . . . . . . . . 9
4.3.2. Session-Resource-Reply (SRR) . . . . . . . . . . . . . 9
4.4. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Query-Index AVP . . . . . . . . . . . . . . . . . . . 10
4.4.2. Resource-Token AVP . . . . . . . . . . . . . . . . . . 10
4.4.3. Resource-Bag AVP . . . . . . . . . . . . . . . . . . . 11
4.5. Original IANA Considerations . . . . . . . . . . . . . . . 11
4.6. Original Security Considerations . . . . . . . . . . . . . 11
4.7. Original Acknowledgements . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . . 12
5.2. Informational References . . . . . . . . . . . . . . . . . 12
Appendix A. Original References from
draft-calhoun-diameter-res-mgmt-08.txt . . . . . . . 12
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 13
B.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 13
B.2. changes in -01 . . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. IANA considerations . . . . . . . . . . . . . . . . . 13
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Bodin, et al. Expires September 2, 2007 [Page 2]
Internet-Draft Auditing Functionality in Diameter March 2007
1. Terminology and Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [RFC2119].
2. Introduction
Diameter has been widely adopted as a base protocol for different
interfaces of next generation network (NGN) architectures developed
by 3GPP, ETSI TISPAN and the ITU-T. Some of these interfaces are
used to support hard state as well as to support soft state. For
example, in the ETSI TISPAN NGN architecture the service policy
decision function (SPDF) offers a Diameter based interface facing
application functions over which they can issue resource reservation
requests for various media flows. Such an application function can,
e.g., be a SIP based soft-switch or a portal for media streaming.
The interface between the SPDF and applications functions must
support both hard and soft state.
This contribution offers three failover use cases, two for hard-state
and one for soft-state, that would benefit from the addition of an
auditing function to Diameter. The primary requirement being set out
in this draft is the requirement for retrieving state for failover
and synchornization purposes.
2.1. Definitions of hard and soft state reservations
In this draft, hard-state reservations and soft-state reservation
will be used in the meanings documented by ETSI TISPAN[ETSI06].
o Hard-state reservation: type of reservation whereby the requested
resources are reserved without time limit. Hard-state
reservations are terminated if the DIAMETER session is terminated.
o Soft-state reservation: type of reservation whereby the requested
resources are reserved for a finite amount of time. Soft-state
reservations are terminated when the DIAMETER session is
terminated.
2.2. Replication
The replication of session data can be performed regularly to
facilitate instantiation of fresh server platform using replicated
data. This approach is herein referred to as replication for warm
standby. Another approach is to replicate session data in real-time
to a parallel server platform, which immediately can take over the
primary server's tasks in case it fails or becomes unavailable. This
Bodin, et al. Expires September 2, 2007 [Page 3]
Internet-Draft Auditing Functionality in Diameter March 2007
approach is referred to as replication for hot standby. The case
when no session data is replicated, a fresh server platform taking
over the primary server's tasks is referred to as a cold standby.
It should be noted that refresh messages may be desirable not only
for soft-state reservations. By having clients refreshing their
active sessions before a timeout in the server it can be ensured that
the clients remain in sync with the server. When a timeout occurs at
the absence of an expected refresh message the server would, in this
scenario, keep the session and issue a callback to the client
informing it that a session exists that has not been refreshed
accordingly. The client may then either provide a refresh or
explicitly terminate the session by replying to this callback.
The behavior of issuing a callback to the client when a session
timeout occurs can clearly be useful also for soft-state sessions.
For example, clients failing in refreshing sessions would with such
callbacks not need to re-establish sessions that should not have been
allowed to expire and handle possible consequences of session data
being wrongly removed. Refresh failures may for example occur if a
delayed refresh arrives after a session has already been deleted.
However, in contrst to when hard-state is maintained, a soft-state
server needs to eventually terminate a session which is not being
refreshed in time (e.g. after a short period following a callback).
Issuing a callback to ask whether a session is still active is
generally a useful mechanism to assure that clients and their server
remain syncronized. That is, a client or a server can benefit from
the ability to issue such a question triggered by any internal or
external event to make sure a particular session (or set of sessions)
is still active in the peer node. For example, in case refresh
messages are not used for a hard-state server, the Diameter server
could issue a callback for sessions that have been active for a
longer period to make sure they are still active in the corresponding
client.
2.3. Diameter used for hard-state reservations
There are at least two common use cases when Diameter is used for
hard-state reservations:
o without replication
o with replication
2.3.1. In the case of failover without replication
In cases where hard state is used over a Diameter interface in an
environment where nodes have backups in case of failure, client nodes
Bodin, et al. Expires September 2, 2007 [Page 4]
Internet-Draft Auditing Functionality in Diameter March 2007
need a mechanism to audit their server for active sessions. That is,
in case a Diameter client node crashes, its backup needs to audit the
server node for active sessions. Otherwise the backup node cannot
know which states are active and can't terminate them when they are
no longer needed.
These cases show that an auditing mechanism is needed to support
hard-state whenever session information is replicated for resilience
purposes. It is also clear that the auditing mechanisms needs to be
symmetrical in order to support both the client auditing for session
information in the server and the server auditing the client.
2.3.2. In the case of failover with replication
A Diameter client, server, or both may replicate session state
information over several database instances at different nodes to
facilitate seamless node failovers. Replication of data over several
database instances are often done asynchronously to keep response
times low. That is, with asynchronous replication (i.e.,
unacknowledged database writes) a Diameter server can answer
immediately to a client request instead of waiting for data to be
properly replicated before answering. When using hard-state Diameter
clients and their server face the risk of getting out of sync after a
failover.
As a consequence of asynchronous replication, session state requested
and established in a Diameter server node may not have been properly
replicated before the server crashes and is seamlessly replaced by
its backup (e.g., through IP takeover or SCTP multi-homing). The
server may, however, have responded to the request before crashing.
The Diameter client could, therefore, record that lost (hard) session
state is still active in the server when it is not. On the other
hand, in case the client is terminating an active session and the
server fails in replicating the state removal before crashing the
backup server node will maintain a hard session state of which the
client is unaware and which is invalid.
2.4. Diameter used for soft-state reservations
In the case of soft-state reservations, an auditing mechanism can
still be beneficial at failover between servers and between clients.
At failover between servers the backup server taking over can request
clients to re-establish their sessions. Instead waiting for refresh
messages to arrive is likely to increase the time needed to get in
sync. This is particularly true when long timeout periods are used.
At failover between clients that do not replicate data (i.e., cold
standby), an auditing mechanism would may allow a backup client to
Bodin, et al. Expires September 2, 2007 [Page 5]
Internet-Draft Auditing Functionality in Diameter March 2007
re-establish at least part of the original session data. In case all
or part of the data possible to obtain from the server is useless to
the backup client, it can choose to explicitly terminate the
corresponding sessions. This would shorten the period at which
clients and their server are out of sync after a failover.
2.5. Required Mechanisms
The cases outlined above require that auditing mechanisms support
both queries for a list of active sessions and support specific
queries for detailed session information kept by the queried node
(i.e., either the client or the server node).
A further requirement for an auditing mechanism is that it must be
able to work in parallel with the basic runtime operation of the
Diameter signaling and interrupt that signaling. For example, in
case a large number of audit messages is needed to synchronize, the
rate of those messages must be possible to limit leaving enough
capacity to the basic runtime signaling to handle ordinary session
setup and teardown.
Support for queries to check if a particular session or a set (list)
of sessions are still active in the peer node is also required (i.e.
either the server or a client node).
3. Proposal
In keeping with the charter goal of updating Diameter in support with
its current uses, the DIME WG is requested to add support of a two
step approach to its list of work items. After the requirements have
been discussed, updated and verified as being of interest to enough
of the participants, the DIME WG is then requested to make the
necessary changes to the base protocol to support auditing
functionality. It is also suggested the DIME WG coordinate with
other SDOs, especially those who have integrated Diameter into their
architectures, in establishing the auditing functionality
requirements.
4. Diameter Resource Management Extensions
The contents of this section are a verbatim copy of
draft-calhoun-diameter-res-mgmt-08.txt [id-res-mgmt] which was
submitted in March 2001 by Pat R. Calhoun. The recommendation of the
authors of this draft is that we use this solution as the starting
point for meeting the requirements listed above.
Bodin, et al. Expires September 2, 2007 [Page 6]
Internet-Draft Auditing Functionality in Diameter March 2007
The text of the original draft is included as is in this version of
the draft but may be edited in later versions to reflect the
requirements and discussions in the Dime WG.
Note: All of the references in this section are the original
references and have not yet been updated to reflect changes in the
document since the draft was published in 2001. This will be updated
in the next version of the draft.
4.1. Original Abstract
Diameter is an authentication, authorization and accounting (AAA)
protocol used for network access services, such as dial-up (NASREQ)
and Mobile IP. Some Diameter servers maintain state information of
active sessions on the access servers, which is used mostly to
enforce some local policy decisions. This extension describes an
extension to the Diameter protocol that allows the server to query
for active session state information from access servers in order to
rebuild state information should it be lost for any reason.
4.2. Original Introduction
Diameter [1] is an authentication, authorization and accounting (AAA)
protocol used for network access services, such as dial-up (NASREQ)
[2] and Mobile IP [3].
The NASREQ AAA requirements [6] require that AAA servers maintain
session state information. This is typically used to enfore a local
policy decision, such as limiting the number of simultaneous sessions
for a specific user, maintaining IP address pools, etc. The AAA WG's
network access requirements [5] require that an AAA protocol be able
to query for session state information, in the event that this
information is lost.
This extension describes an extension to the Diameter protocol that
allows a Diameter node to query for active session state information
from its peers in order to rebuild state information. Although it is
envisioned that this would be used when state information was lost,
and needed to be rebuilt, it is possible for a node to periodically
query for state information in order to ensure that its state is
current.
This document only concerns itself with the ability to query for
session state information. Resources are actually reserved when a
user is successfully authorized. Therefore, relevant application-
specific extensions, such as [2] and [3], MUST define what resources
are to be managed, by specifying what AVPs MUST be present in the
Resource-Token AVP.
Bodin, et al. Expires September 2, 2007 [Page 7]
Internet-Draft Auditing Functionality in Diameter March 2007
The Extension number for this draft is three (3). Diameter nodes
conforming to this specification MUST include an Extension-Id AVP
with a value of three in the Device-Reboot-Ind Command [1].
4.2.1. State synchronization
When a Diameter node determines that it is has lost all state
information it had for a specific peer, it SHOULD issue a Session-
Resource-Query message to the peer. The node in question MAY
postpone all authorization messages from the peer until state has
been restored.
Upon receipt of the Session-Resource-Query, all Resource-Token AVPs
for the requested sessions, indicated via one or more Session-Id AVP,
MUST be returned in a Session-Resource-Reply. The absence of any
Session-Id AVP is an indication that all active sessions are to be
returned.
If the node is unable to send all of the information within a single
message, it MUST include the Query-Index AVP, with a value that has
local significance. A node that receives a Session-Resource-Reply
with a Query-Index AVP SHOULD issue another Session-Resource-Query
message with the Query-Index AVP intact, requesting the rest of the
state information.
+----------+ SRQ (no Query-Index AVP) ---> +----------+
| | <--- SRR (Query-Index AVP = x) | |
| Diameter | SRQ (Query-Index AVP = x) ---> | Diameter |
| Node A | <--- SRR (Query-Index AVP = y) | Node B |
| | SRQ (Query-Index AVP = y) ---> | |
+----------+ <--- SRR (no Query-Index AVP) +----------+
Session State Exchange
The above example depicts Diameter Node a issuing an SRQ to Node B.
Upon replying with an SRR, node B determines that it is unable to
include all of the Resource-Token AVPs in a single reply, and
therefore includes the Query-Index AVP with a value of x.
Upon receipt of the response, node A processes all Resource-Token
AVPs and issues a subsequent SRQ with the Query-Index AVP set to x.
Node B receives the SRQ, and using the Query-Index AVP determines
which sessions need to be included in the corresponding SRR.
This exchange continues until node B returns an SRR that does not
include the Query-Index AVP, indicating that there is no further
session state information to be returned.
Bodin, et al. Expires September 2, 2007 [Page 8]
Internet-Draft Auditing Functionality in Diameter March 2007
4.3. Command-Code Values
This section defines Command-Code [1] values that MUST be supported
by all Diameter implementations conforming to this specification.
The following Command Codes are defined in this specification:
+------------------------+---------+------+---------------+
| Command Name | Abbrev. | Code | Reference |
+------------------------+---------+------+---------------+
| Session-Resource-Query | SRQ | 277 | Section 4.3.1 |
| Session-Resource-Reply | SRR | 278 | Section 4.3.2 |
+------------------------+---------+------+---------------+
4.3.1. Session-Resource-Query (SRQ)
The Session-Resource-Query (SRQ), indicated by the Command-Code field
set to 277, MAY be sent by a Diameter node to any of its peer to
request a state update. The presence of one or more Session-Id AVPs
in the Session-Resource-Query message indicates that the server only
wants to receive the Resource-Token for the specified session(s).
Message Format
<Session-Resource-Query> ::= < Diameter Header: 277 >
{ Extension-Id }
{ Origin-FQDN }
{ Origin-Realm }
{ Destination-Realm }
* [ Session-Id ]
* [ Destination-FQDN ]
0*1[ Query-Index ]
* [ AVP ]
* [ Proxy-State ]
* [ Route-Record ]
* [ Routing-Realm ]
0*1< Integrity-Check-Value >
4.3.2. Session-Resource-Reply (SRR)
The Session-Resource-Reply (SRR), indicated by the Command-Code field
set to 278, is sent in response to a SRQ message. The SRR message
contains a Resource-Token for each active session that was requested
via the Session-Id AVP. The absence of any Session-Id AVP in the SRQ
implies that Resource-Tokens for all active sessions MUST be
returned.
In the event that all of the state information cannot be sent at
once, the SRR message MUST include the Query-Index AVP.
Bodin, et al. Expires September 2, 2007 [Page 9]
Internet-Draft Auditing Functionality in Diameter March 2007
<Session-Resource-Reply> ::= < Diameter Header: 278 >
{ Extension-Id }
{ Origin-FQDN }
{ Origin-Realm }
{ Result-Code }
[ Destination-FQDN ]
0*1[ Query-Index ]
* [ Resource-Token ]
* [ AVP ]
* [ Proxy-State ]
* [ Route-Record ]
* [ Routing-Realm ]
0*1< Integrity-Check-Value >
4.4. Mandatory AVPs
The following table describes the Diameter AVPs defined in the
Resource Management extension, their AVP Code values, types, possible
flag values and whether the AVP MAY be encrypted.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Query-Index 500 4.4.1 Unsigned32 | M | P | | V | Y |
Resource-Bag 502 4.4.3 OctetString| M | P | | V | Y |
Resource-Token 501 4.4.2 Grouped | M | P | | V | Y |
4.4.1. Query-Index AVP
The Query-Index AVP (AVP Code 500) is of type Unsigned32 and MUST
only be present in the Session-Resource-Query and the Session-
Resource-Reply messages. The Query-Index AVP has local significance
to the issuer of the Session-Resource-Reply message, and is used to
identify the state information that remains to be sent in a
subsequent SRR message.
4.4.2. Resource-Token AVP
The Resource-Token AVP (AVP Code 501) is of type Grouped. The value
is a set of AVPs used to track state information that is pertinent to
an active session. The issuer of the SRR message is responsible for
creating a Resource-Token AVP for all active sessions requested.
The following describes the minimum number of AVPs that MUST be
present in a Resource-Token AVP. Service-specific AVPs MAY also be
Bodin, et al. Expires September 2, 2007 [Page 10]
Internet-Draft Auditing Functionality in Diameter March 2007
present, as defined in the appropriate service extension document.
resource-token = sid host user timestamp extension-id optional
sid = Session-Id AVP ; See [1], Section 3.1.
host = Host-Name AVP ; See [1], Section 2.3.1.
user = User-Name AVP ; See [1], Section 3.3.
timestamp = Timestamp AVP ; See [1], Section 7.3.
extension-id = Extension-Id AVP ; See [1], Section 2.6.3.
optional = Resource-Bag AVP ; See Section 3.3
The Host-Name AVP contains the NAI of the access router that is
servicing the user, while the timestamp AVP contains the time at
which the successful Diameter authorization response was received,
and the service was initiated.
4.4.3. Resource-Bag AVP
This AVP allows encapsulation of arbitrarily many AVPs to be included
in a Resource-Token. These AVPs are defined in service specific
extensions to Diameter. The only restrictions to the AVPs is that
they MUST NOT be interpreted so as to conflict with the other fields
of the Resource-Token Group value, namely, the Session-Id, Host-Name,
User-Name, Timestamp or Extension-Id AVPs.
The Resource-Bag AVP (AVP Code = 502) is of type OctetString. The
AVP encapsulates an arbitrary of AVPs, each with its own header and
value.
4.5. Original IANA Considerations
The command codes defined in Section 2.0 are values taken from the
Command-Code [1] address space and extended in [2], [4] and [8].
IANA should record the values as defined in Section 4.3
The AVPs defined in section 3.0 were alllocated from from the AVP
numbering space defined in [1], and extended in [2], [4] and [8].
IANA should record the values as defined in Section 4.4.
4.6. Original Security Considerations
This Diameter extension assumes that the Resource Management 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].
Bodin, et al. Expires September 2, 2007 [Page 11]
Internet-Draft Auditing Functionality in Diameter March 2007
4.7. Original Acknowledgements
The authors wish to thank Erik Guttman for providing some very useful
proposed text to handle the change in data types.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informational References
[ETSI06] ETSI TISPAN, "Telecommunications and Internet converged
Services and Protocols for Advanced Networking", 2006.
[id-res-mgmt]
Pat, P., "Diameter - Resource Management Extensions",
2001.
Appendix A. Original References from
draft-calhoun-diameter-res-mgmt-08.txt
Note: In future versions of this draft, the references that are kept
need to be researched to refer to current versions of the documents
wherever possible.
[1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base
Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
September 2000.
[2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ
Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
progress, September 2000.
[3] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-calhoun-
diameter-framework-07.txt, IETF work in progress, April 2000.
[4] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft-
calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember
2000.
[5] Aboba et al, "Network Access AAA Evaluation Criteria", draft-
ietf-aaa-na-reqts-07.txt, IETF work in progress, August 2000.
Bodin, et al. Expires September 2, 2007 [Page 12]
Internet-Draft Auditing Functionality in Diameter March 2007
[6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in
progress, June 2000.
[8] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting
Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in
progress, September 2000.
[9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security
Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF work in
progress, September 2000.
Appendix B. Changes
This section to be removed if and when this I-D is approved for
publication as an RFC.
B.1. Changes in -02
1. Added contents of draft-calhoun-diameter-res-mgmt-08.txt
2. Added TOC
B.2. changes in -01
1. Add some specificity on the purpose of the requirements
2. Added a soft state use case for synchronization.
3. Added a section on replication
4. Added informational reference to ETSI ES 283 026 with definitions
of soft and hard state
Appendix C. IANA considerations
TBD
Appendix D. Acknowledgements
The authors and editors of this specification thank Pat Calhoun for
allowing us to use, include and buld on his proposed Diameter
Resource Mnagement Extension draft.
Bodin, et al. Expires September 2, 2007 [Page 13]
Internet-Draft Auditing Functionality in Diameter March 2007
Authors' Addresses
Ulf Bodin
Operax
Lulea S-977 75
Sweden
Email: Ulf.Bodin@operax.com
URI: www.operax.com
Avri Doria
Lulea University of Technology
Lulea
Sweden
Email: avri@ltu.se
URI: psg.com/~avri
Bruno Chatras
France Telecom
Email: bruno.chatras@orange-ft.com
URI:
Steve Norreys
BT
Email: steve.norreys@bt.com
URI:
Bodin, et al. Expires September 2, 2007 [Page 14]
Internet-Draft Auditing Functionality in Diameter March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bodin, et al. Expires September 2, 2007 [Page 15]