Internet DRAFT - draft-bodin-dime-auditing-reqs
draft-bodin-dime-auditing-reqs
Network Working Group U. Bodin
Internet-Draft Operax
Intended status: Standards Track A. Doria (ed.)
Expires: March 2, 2008 Lulea University of Technology
B. Chatras
France Telecom
S. Norreys
BT
August 30, 2007
Auditing Functionality in Diameter
draft-bodin-dime-auditing-reqs-03.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 March 2, 2008.
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 March 2, 2008 [Page 1]
Internet-Draft Auditing Functionality in Diameter August 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. Diameter Resource Management Extensions . . . . . . . . . . . 6
3.1. Extension Overview . . . . . . . . . . . . . . . . . . . . 6
3.1.1. State synchronization . . . . . . . . . . . . . . . . 7
3.2. Command-Code Values . . . . . . . . . . . . . . . . . . . 8
3.2.1. Session-Resource-Query (SRQ) . . . . . . . . . . . . . 8
3.2.2. Session-Resource-Reply (SRR) . . . . . . . . . . . . . 9
3.3. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Query-Index AVP . . . . . . . . . . . . . . . . . . . 10
3.3.2. Resource-Token AVP . . . . . . . . . . . . . . . . . . 10
3.3.3. Resource-Bag AVP . . . . . . . . . . . . . . . . . . . 10
3.4. Original IANA Considerations . . . . . . . . . . . . . . . 11
3.5. Original Security Considerations . . . . . . . . . . . . . 11
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Normative References . . . . . . . . . . . . . . . . . . . 11
4.2. Informational References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 13
A.3. changes in -01 . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. IANA considerations . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
C.1. Original Acknowledgements . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Bodin, et al. Expires March 2, 2008 [Page 2]
Internet-Draft Auditing Functionality in Diameter August 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 March 2, 2008 [Page 3]
Internet-Draft Auditing Functionality in Diameter August 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 March 2, 2008 [Page 4]
Internet-Draft Auditing Functionality in Diameter August 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 March 2, 2008 [Page 5]
Internet-Draft Auditing Functionality in Diameter August 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. Diameter Resource Management Extensions
The contents of this section are based on
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.
3.1. Extension Overview
Diameter [RFC3588] is an authentication, authorization and accounting
(AAA) protocol used for network access services, such as dial-up
(NASREQ) [RFC4005] and Mobile IP [id-framework] .
The NASREQ AAA requirements [RFC3169] 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 [RFC2989] require that an AAA
protocol be able to query for session state information, in the event
that this information is lost.
Bodin, et al. Expires March 2, 2008 [Page 6]
Internet-Draft Auditing Functionality in Diameter August 2007
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 [RFC4005] and [id-framework] , MUST
define what resources are to be managed, by specifying what AVPs MUST
be present in the Resource-Token AVP.
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 [RFC3588] .
3.1.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
Bodin, et al. Expires March 2, 2008 [Page 7]
Internet-Draft Auditing Functionality in Diameter August 2007
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.
3.2. Command-Code Values
This section defines Command-Code [RFC3588] 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 3.2.1 |
| Session-Resource-Reply | SRR | 278 | Section 3.2.2 |
+------------------------+---------+------+---------------+
3.2.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).
Bodin, et al. Expires March 2, 2008 [Page 8]
Internet-Draft Auditing Functionality in Diameter August 2007
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 >
3.2.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.
<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 >
3.3. 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.
Bodin, et al. Expires March 2, 2008 [Page 9]
Internet-Draft Auditing Functionality in Diameter August 2007
+---------------------+
| 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 |
3.3.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.
3.3.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
present, as defined in the appropriate service extension document.
resource-token = sid host user timestamp extension-id optional
sid = Session-Id AVP ; See [RFC3588] , Section 3.1.
host = Host-Name AVP ; See [RFC3588] , Section 2.3.1.
user = User-Name AVP ; See [RFC3588] , Section 3.3.
timestamp = Timestamp AVP ; See [RFC3588] , Section 7.3.
extension-id = Extension-Id AVP ; See [RFC3588] , 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.
3.3.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
Bodin, et al. Expires March 2, 2008 [Page 10]
Internet-Draft Auditing Functionality in Diameter August 2007
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.
3.4. Original IANA Considerations
The command codes defined in Section 2.0 are values taken from the
Command-Code [RFC3588] address space and extended in [RFC4005] ,
[RFC4004] and [id-acct-ext] . IANA should record the values as
defined in Section 3.2
The AVPs defined in section 3.0 were alllocated from from the AVP
numbering space defined in [RFC3588] , and extended in [RFC4005] ,
[RFC4004] and [id-acct-ext] . IANA should record the values as
defined in Section 3.3.
3.5. 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 [RFC3588] , or using a strong authentication mechanism
as defined in [id-crypto-ext].
4. References
4.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
Bodin, et al. Expires March 2, 2008 [Page 11]
Internet-Draft Auditing Functionality in Diameter August 2007
4.2. Informational References
[ETSI06] ETSI TISPAN, "Telecommunications and Internet converged
Services and Protocols for Advanced Networking", 2006.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
"Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[RFC3169] Beadles, M. and D. Mitton, "Criteria for Evaluating
Network Access Server Protocols", RFC 3169,
September 2001.
[id-acct-ext]
Arkko, J., Calhoun, P., Patel, P., and G. Zorn, "Diameter
Accounting Extensions",
draft-calhoun-diameter-accounting-08.txt (work in
progress), 2000.
[id-crypto-ext]
Calhoun, P., Bulley, W., and S. Farrell, "Diameter Strong
Security Extension",
draft-calhoun-diameter-strong-crypto-05.txt (work in
progress), 2000.
[id-framework]
Calhoun, P., Zorn, G., Pan, and Akhtar, "Diameter
Framework", draft-calhoun-diameter-framework-07.txt (work
in progress), 2000.
[id-res-mgmt]
"Diameter - Resource Management Extensions",
draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
2001.
Appendix A. Changes
This section to be removed if and when this I-D is approved for
publication as an RFC.
Bodin, et al. Expires March 2, 2008 [Page 12]
Internet-Draft Auditing Functionality in Diameter August 2007
A.1. Changes in -03
1. Integrated draft-calhoun-diameter-res-mgmt-08.txt into the
document
2. Updated references
A.2. Changes in -02
1. Added contents of draft-calhoun-diameter-res-mgmt-08.txt
2. Added TOC
A.3. 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 B. IANA considerations
TBD
Appendix C. 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.
C.1. Original Acknowledgements
The authors wish to thank Erik Guttman for providing some very useful
proposed text to handle the change in data types.
Authors' Addresses
Ulf Bodin
Operax
Lulea S-977 75
Sweden
Email: Ulf.Bodin@operax.com
URI: www.operax.com
Bodin, et al. Expires March 2, 2008 [Page 13]
Internet-Draft Auditing Functionality in Diameter August 2007
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 March 2, 2008 [Page 14]
Internet-Draft Auditing Functionality in Diameter August 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 March 2, 2008 [Page 15]
