ECRIT Working Group James Polk
Internet-Draft Cisco Systems
Expires: March 6th, 2006 Andrew Newton
VeriSign
September 6th, 2005
Emergency Context Routing of Internet Technologies
Architecture Considerations
draft-polk-newton-ecrit-arch-considerations-00
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 6th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses architectural considerations for emergency
context routing of Internet technologies. The purpose of this
document is to provide a systemic view of emergency context routing,
discuss unresolved issues, and explain the relationship of some of
the proposals to these issues, while discussing potential directions
that might be still be necessary for the working group to
investigate.
Polk & Newton Expires March 6th, 2006 [Page 1]
Internet-Draft ECRIT Arch Considerations Sept 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Division of Labor . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology, Acronyms and Definitions . . . . . . . . . . 4
2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. LCMS Mapping . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conveyance . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Universal Emergency Identifiers . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1 Security of the LCMS . . . . . . . . . . . . . . . . . . 8
7.2 Security of Location Conveyance . . . . . . . . . . . . . 9
7.3 Security of Bootstrapping . . . . . . . . . . . . . . . . 10
7.4 Security of Conversion . . . . . . . . . . . . . . . . . 10
8. Data distribution . . . . . . . . . . . . . . . . . . . . . . 11
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Conflation . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Rerouting/Transfer . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1 Normative References . . . . . . . . . . . . . . . . . . 13
13.2 Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
A. Appendix A. Additional stuff . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 14
1. Introduction
The solution to proper emergency call identification, management and
routing over the Internet involves many components and coordination
between them. This document describes the necessary interaction
between these components. The information given in this document
may not be complete, and some of the issues presented in this
document may not be resolved by the community. The intent of this
document is to describe a "big picture" view of the process,
describe prevailing thoughts on this subject and describe unresolved
issues in hopes of bringing about consensus on these topics.
The current architecture of ECRIT is composed of the following:
Bootstrapping: delivery of configuration and location information to
the client.
Conversion: conversion of location information into forms usable in
mapping and conveyance, if necessary.
LCMS Mapping: conversion of endsystem location information into
addresses usable to initiate or progress communication to an
emergency call center (a PSAP).
Polk & Newton Expires March 6th, 2006 [Page 2]
Internet-Draft ECRIT Arch Considerations Sept 2005
Conveyance: delivery of endsystem location information to an
emergency call center during the emergency call (used for
dispatch).
There are many unresolved issues regarding these steps and related
matters. The following list is not exhaustive, but includes most of
the issues brought before the working group (and a few new ones).
Universal emergency identifier: there needs to be a universal
emergency identifier to prevent highly localized usage and
confusion by users and systems.
Security: the security properties necessary for the proper
protection of LCMS data are not well understood.
Data distribution: the distribution of LCMS data closer to the
points of queries within the Internet.
Extensibility: the methods for extensibility in all components of
the system must be well understood.
Conflation: many of the components proposed for use in the routing
of emergency calls have other uses and most have not been
primarily designed for the emergency call routing case.
1.1 Division of Labor
As stated above, not all of the components used in the process of
routing an emergency call to the correct emergency call center over
the Internet have been defined for the exclusive use of this case,
and therefore not all of the specification work is being conducted
within the scope of the charter of the ECRIT working group.
Bootstrapping of location information, both geospatial and civic,
via DHCP is work in progress in the GEOPRIV working group.
Bootstrapping of URI references via DHCP is work in progress in the
DHC working group.
The definition of location objects and the use of schemas to
describe location is work in progress in the GEOPRIV working group.
The specification of conveyance of location objects via SIP is work
in progress in the SIP working group.
The mapping of location information to URIs is the primary function
of the ECRIT working group. The set of mechanisms and services
working in conjunction with each other to conduct this mapping is
referred to as the Location Context Mapping System or LCMS by this
document for the purposes of clarity.
Polk & Newton Expires March 6th, 2006 [Page 3]
Internet-Draft ECRIT Arch Considerations Sept 2005
1.2 Terminology, Acronyms and Definitions
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].
The following terms and definitions will be used throughout this
document:
Application Service Provider (ASP) - provider of application level
services such as a voice over IP service that is completely
divorced from the access provider, and may be divorced from the
local ISP of an endsystem
ASP - Application Service Provider
Emergency Services Gateway (ESGW) - The special IP to circuit-
switched gateway that front-ends an emergency services Selective
Router (which directs all TDM based 911/112 type calls to the
appropriate PSAP)
Emergency Services Routing Proxy (ESRP) - a special instance of a
SIP Proxy that understands emergency routing to a PSAP based on
the location of the caller
ESGW - Emergency Services Gateway
ESRP - Emergency Services Routing Proxy
IAP - Internet Access Provider
Internet Access Provider (IAP) - typically the organization that
provides Internet or IP access to the client, and could be the
same as the ISP in certain circumstances
Internet Service Provider (ISP) - Provider of advanced services,
such as application layer message processing, filtering and
routing, and services such as voice/video/instant messaging over
IP, and could be the same as the IAP in certain circumstances
ISP - Internet Service Provider
Location Context Mapping System û A set of coordinated mechanisms
and services that map a physical location (geospatial or civic)
to a network address.
LCMS û Location Context Mapping System
LIS - Location Information Server
PSAP - Public Safety Answering Point
Polk & Newton Expires March 6th, 2006 [Page 4]
Internet-Draft ECRIT Arch Considerations Sept 2005
Location Information Server (LIS) û
Public Safety Answering Point (PSAP) - the emergency response call
center talking the local emergency calls from people in distress.
This facility can be logical, and can transfer (reroute) any
request sent to it to another facility deemed more appropriate to
receive the request.
2. Bootstrapping
Bootstrapping delivers configuration and location information to the
client. This is typically done at device or individual application
boot times. Unlike other parts of the architecture, bootstrapping
is the only phase of the emergency call routing process that does
not have a single solution. This is due to the many network
configuration techniques used by access networks.
There are three well-known methods of bootstrapping:
1. Using the DHCP protocol
2. Using the PPP protocol
3. Using IEEE 802.1 LLDP-MED
For location information, there are two types: location information
regarding a civic address (e.g. 123 Main St ) and geospatial
information (e.g. x, y, z coordinates).
The set of configuration data types has not been discussed or
resolved. But the following types of configuration information have
been noted: 1) references to LCMS servers, 2) references to PSAPs,
and 3) references to location information servers.
References to LCMS servers obviate the need for global hierarchies
of LCMS data directories (which have proven politically difficult in
other voice over IP matters) and reduce the coordination to only the
necessary jurisdictional boundaries.
References to PSAPs obviate the need for the mapping steps in cases
where location is not likely to be a determining factor in emergency
call routing (e.g. location is fixed and the emergency call center
is known).
References to location information servers enable better separation
for knowledge of location from the access network.
3. Conversion
Conversion of location information from one format to the other
format is conducted for the benefit of the LCMS servers and
conveyance of the location information. There are two aspects to
Polk & Newton Expires March 6th, 2006 [Page 5]
Internet-Draft ECRIT Arch Considerations Sept 2005
this conversion: syntactic conversion of the location information
from the binary formats used in bootstrapping to the XML format used
in PIDF-LO, and conversion of the civic location information to
geospatial location information or vice versa.
Syntactic conversion is a necessary function, and it can take two
different forms: conversion to the PIDF-LO conveyance format and
conversion to a LCMS format if the LCMS interface does not use PIDF-
LO.
Conversion of location information from a civic address to
geospatial coordinates or from geospatial coordinates to a civic
address is much more controversial. There is no doubt that civic
addresses are much easier to consume by humans than geospatial
coordinates, however conversion from geospatial coordinates to a
civic address can be error prone and in cases involving large areas
(e.g. a farm, an outdoor park, etcà) the resulting civic address can
be of limited utility. Further, civic coordinates do not address
even most of the land of this planet, as civic addresses are to a
great degree tied to the existence of a nearby street, which are
prevalent in cities, but are scarce to non-existent in rural areas.
Therefore, a combination of the two formats will be required
regardless of mankind's consumption preference.
4. LCMS Mapping
The creation of an LCMS, which will convert location information
into references (i.e. URIs) to emergency call centers, is the
primary area of work for the ECRIT working group. There are two
times in which this LCMS function can occur successfully:
1. before the device attempts contact with a PSAP, and
2. after the device initiates contact with the PSAP, but before the
correct PSAP is determined by the ESRP making the LCMS query.
Accomplishing mapping of a device's location with the proper PSAP
can be done statically or dynamically.
Statically - If a site is small enough, for example residential or
small business scale, all devices in either of these types of
locations can be configured to download, or have downloaded to
them, their location information and the SIP or SIPS URI for
contacting the appropriate PSAP for that location.
Dynamically - for the above types of locations, or for larger
locations, the client's location can be used to "look up" the
appropriate PSAP SIP or SIPS URI, and have this configuration
information downloaded to each client requesting it. This can
also be pushed to all clients regardless of whether they asked
for the information or not. This pushing of the PSAP URI(s) can
be at some interval to maintain freshness of the URI(s), as stale
Polk & Newton Expires March 6th, 2006 [Page 6]
Internet-Draft ECRIT Arch Considerations Sept 2005
URI(s) are a concern to some.
For the static configuration, for each given endpoint or section of
a network, a known PSAP SIP or SIPS URI is downloaded to the
client(s) without the clients providing their individual location to
perform the LCMS function. In the case of dynamic configuration of
a URI, the client provides their location to an LCMS server to do
this look-up, with the answer sent to the client for future use.
A combined approach can be attained in the following scenario: if
the endsystem knows of an authoritative LCMS server regardless of
which network or domain the client is connected to, the endsystem
can contact this server to get its PSAP SIP/SIPS URI based on its
location provided by the local access network. In this scenario, an
endsystem can have a trust association established with a particular
server (or server service) that it contacts as soon as it either
learns its location from a local network/domain or somehow
determines it has moved while remaining "connected" to that
network/domain.
For the device configuration of a PSAP SIP or SIPS URI, currently
only DHCP is being proposed as a solution [ID-DHCP-URI].
To date there are three protocol proposals for LCMS: LUMP, ECON, and
DNS SOS. LUMP is an XML-based, SOAP solution with emphasis on data
distribution. ECON is an XML-based, IRIS solution with emphasis on
lightweight data exchange, and DNS SOS is a DNS-based solution with
emphasis on re-using DNS semantics.
5. Conveyance
Once the address of the PSAP is known, either through bootstrapping
or through LCMS mapping, a call can be initiated with the PSAP.
Location information is sent to the PSAP as meta-data of the call
using PIDF-LO. This facet is not part of the ECRIT WG, but cannot
be overlooked. Even if the caller contacts the appropriate PSAP,
that PSAP will still require knowledge of where the caller is in
order to dispatch emergency responders (i.e. help). Issues
regarding the acquisition of this knowledge are discussed in Section
7.2.
6. Universal Emergency Identifiers
Throughout the world, there are many different numbers in use to
signal emergency phone calls. Some counts have this number as high
as 60 unique number sequences worldwide. This lack of uniformity
also leads to collision. For example, in some areas of the world,
the number 0 is used for calling for help, whereas in other parts of
the world, this would not accomplish its intended emergency meaning.
Polk & Newton Expires March 6th, 2006 [Page 7]
Internet-Draft ECRIT Arch Considerations Sept 2005
Therefore, one of the ECRIT requirements is for a universal
emergency identifier to signal an emergency. The need for it to be
universal (or well-known) is threefold: so that all the components
in the emergency call routing process may properly operate upon it,
to avoid collision with other purposes (as stated above), and so
that clients may localize it's meaning to end users. The issue is
that there is not just one single identifier related to emergency
calls, but that there are many identifiers related to emergency
calls for various specific types of emergencies.
Multiple identifiers lead to confusion and many have overlapping
meaning. For example, the separate identifiers "mountain" and
"rescue" could mean the same thing to a user needing to be rescued
from a mountainous area. Additionally, some jurisdictions have
custom identifiers that are either unused globally or have a limited
applicability.
Each LCMS proposal takes a different approach to solving this
problem. DNS SOS has the simplest approach, specifying a simple list
of six identifiers. LUMP specifies a hierarchy of identifiers. And
ECON utilizes a tuple approach consisting of function, area, and
target.
What is not clear, or has not been well defined, is the need for
even the simplest of these approaches. It is not even well
understood if end users, in an emergency situation, will be able to
rationalize the difference between "emergency" and a simple list of
"police", "fire", and "medical". While some have suggested this is
in practice in some parts of the world today, that doesn't
necessarily mean this will become universal in usage. If appears
that if there is a single master identifier with more than one sub-
identifier, that this arrangement should be used where it is
understood, and perhaps adopted elsewhere as jurisdictions decide to
segment this capability based on education within that area.
What appears obvious to avoid is to have different identifiers for
help in different parts of the world moving forward. If only
'sos.police@...' reaches the police in a country where Alice does
not live when she sends a SIP INVITE to 'sos@...', ECRIT as a WG has
not likely accomplished its goal.
Locales that choose to have sub-identifiers for granularity must
have an architected solution for the higher level identifier as
well.
7. Security Considerations
7.1 Security of the LCMS
It is the goal of the working group to develop a dynamic LCMS
protocol that is both secure and responsive, two features that tend
Polk & Newton Expires March 6th, 2006 [Page 8]
Internet-Draft ECRIT Arch Considerations Sept 2005
to conflict with each other. Security for this mapping solution has
fallen into two broad categories: object signing and channel
security.
Object signing has three benefits: integrity of data during
distribution, the potential for utilization in UDP packets, and pre-
calculation of cryptographic data. However, in cases where partial
matching of the query are to be allowed (i.e. parts of a civic
address are to be ignored in the query) or the query cannot be known
ahead of time (i.e. the whole set of geospatial coordinates is
known but not in practical terms), object signing will require "on-
line" signing which negates advantages in data distribution and
cryptographic pre-calculations.
In addition, the use case regarding the invalidity of a signed
object may be no different from that of a validly signed object.
Users confronted with an emergency may not be able to appreciate the
difference in validity, and even if they did, may not alter their
course of action (i.e. they continue with the emergency call
anyway).
Channel security requires expensive cryptographic calculations that
cannot be computed ahead of time and requires multiple packet
exchanges (i.e. roundtrips) to establish. However, this approach
has the benefit of securing all parts of the transaction, and unlike
object signing, is well used and well understood on the Internet.
The security properties of each of the three LCMS proposals is as
follows:
LUMP uses both channel security (TLS connections to the query
server) and object signing (signed entries in the database).
DNS SOS uses both channel security (TLS in connections to fetching
polygons and other information) and object signing (in DNSSEC
for the protection of NAPTR records).
ECON uses channel security (TLS connections to the query server) as
an option setup by the operator of the service and a lightweight
UDP transfer protocol for scenarios where security is not
needed.
7.2 Security of Location Conveyance
There is a general desire to protect PSAPs from malicious calls.
Yet, how this is to be accomplished is not clear or well defined.
Complicating this issue is the simple fact that many PSAPs will
accept a call without location information related to the caller.
Additionally, many PSAPs give priority or parity to location
information collected by a human operator from a human caller. Due
Polk & Newton Expires March 6th, 2006 [Page 9]
Internet-Draft ECRIT Arch Considerations Sept 2005
to this fact, it has been observed that any security mechanism put
into place by ECRIT can simply be routed around by directly
contacting a PSAP.
In cases where a PSAP would wish to disregard calls of unknown
provenance, no guidelines have clearly been stated as to how such
trust relationships would be erected.
7.3 Security of Bootstrapping
Where critical decisions might be based on the value(s) of the
bootstrapping process, such as a URI option from [ID-DHC-URI], DHCP
authentication in [RFC3118] SHOULD be used to protect the integrity
of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the client and
destination DHCP server to capture any URIs in transit.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
All that said, if DNS is not secure, and bootstrapping is difficult
to secure based on what it takes to accomplish [RFC3118], is
securing the mapping service worth the effort and pain to achieve?
7.4 Security of Conversion
Location is a vital part of emergency messaging. As discussed
earlier, an endsystem will not likely be in control of which format
of location it receives from a roamed to network. For more fixed
endsystems, this should not be the case. If an endsystem does
receive location in a format it knows an application on that
endsystem does not prefer, the endsystem can contact a server or
service, if one is known, to convert this format to the other
format.
As a non-emergency example, most humans understand street addresses
much better than GPS coordinates. If a roaming device, say using
802.11 at a hotspot, acquires its location via DHCP Option 123 [RFC
3825], it can determine if an application used by that device
prefers the civic format to use instant messaging. Before the IM
application is launched, or as the app is launched, the device can
seek a conversion server to perform this format conversion
operation. How does a client learn of a server that can do this?
[ID-DHC-URI] provides one means for a device to learn the URL of a
server that can do this function, or this can be preconfigured in
the device as a trusted source for this conversion.
In the emergency case, perhaps the device knows it needs to convert
Polk & Newton Expires March 6th, 2006 [Page 10]
Internet-Draft ECRIT Arch Considerations Sept 2005
to the civic format to have an ESRP perform an LCMS query, but the
local network gave it a geospatial location only. If the conversion
server is preconfigured, this provides the ability to have the two
devices, say the phone and the conversion server, establish a trust
relationship, perhaps with pre-shared keys. This reduces the round
trip times, making it more efficient. This also provides a more
secure means of communication since both entities 'know' each other.
8. Data distribution
There is a desire to locate LCMS data in the LCMS close to the
points of query in the Internet for performance reasons. In
addition, some jurisdictions distribute authority for this data upon
hierarchical lines. However, the needs for data distribution beyond
these high-level requirements are not well known. For instance, the
known life expectancy of data distributed to caches is not well
known, nor are update procedures in the distribution of this data.
Each of the three LCMS proposals addresses this problem in a
different way:
DNS SOS relies upon the cache machinery of DNS. The population of
DNS caches with location information is accomplished through
validation of caller locations (a process during provisioning of
a callers location and before any emergency call). This proposal
does not address early cache expiration due to limited cache
memory, by accepted practices of DNS operations, or by routine
maintenance of DNS servers.
LUMP defines a caching mechanism that identifies objects by hash
value in order to accomplish a mesh of caches between nodes. The
population of the caches with location information is
accomplished through validation of caller locations (a process
conducted during provisioning of a callers location and before
any emergency call).
ECON defines no preference for data distribution due to the limited
requirements available. However, it does describe two methods
that could be employed: the serialization of data to files for
distribution via standard transfer protocols and an on-line,
incremental approach capable of distributing entries before their
activation date.
9. Extensibility
Within the ECRIT working group, there appears to be rough consensus
on the need for extensible mechanisms, and hence an extensible LCMS
protocol capable of extensions in its query interface and resulting
output. This desire for extensibility is born from a general sense
that not all the problems of emergency call routing over the
Polk & Newton Expires March 6th, 2006 [Page 11]
Internet-Draft ECRIT Arch Considerations Sept 2005
Internet will be fully exposed until deployment of a first
generation solution and from a more specific sense of the
incompleteness of the civic address schema in PIDF-LO.
As an example of the more general case, the document [ID-ECRIT-
JAPAN] describes a numeric address code equivalent to the civic
elements <A1> through <A5> in PIDF-LO used in conjunction with
geospatial coordinates to conduct emergency call handling in Japan.
As an example of the more specific case, PIDF-LO does not contain an
element to describe street section numbers as used in Taiwan.
10. Conflation
As mentioned in the introduction, many of the components used in the
process of routing emergency calls were not designed primarily for
this task and are being developed in working groups that do not have
emergency call routing explicitly defined in their chartered scope.
As a general example, conveyance of location information within a
call also has applicability to delivery businesses, such as pizza
restaurants that need to know the location of the caller for
delivery purposes. In a more technical sense, much of what is known
about civic addresses worldwide is a result of the study of postal
delivery, and therefore schemas used as location input for emergency
call routing may not be tuned properly.
Within the ECRIT working group, there are no requirements regarding
the resilience of the emergency call routing process as it relates
to inputs that have not been designed for this specific purpose.
11. Rerouting/Transfer
Another facet of the ECRIT WG that has not been addressed is what to
do if a PSAP receives an emergency call and the call should not have
been sent to that PSAP. What does the PSAP do next, and can this
action be automated? Does the PSAP have an additional screening
capability in some ESRP at the PSAP interior edge to do a final
check that the call set-up is to the appropriate PSAP, taking steps
not yet defined if this PSAP is not the appropriate one for this
particular call set-up?
This is more a rerouting function of the call set-up, or of a call
transfer function if the call is answered before determining this is
an inappropriate PSAP. For example, VPNs will likely cause some
emergency calls to go erroneously to the city that that caller's
corporate offices are, rather than to where the call is. This has
not been considered to date, yet likely should be - as message
reroute should be possible anytime an ESRP misdirects a message
towards the wrong PSAP.
Polk & Newton Expires March 6th, 2006 [Page 12]
Internet-Draft ECRIT Arch Considerations Sept 2005
12. Acknowledgements
Your name here....
13. References
13.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
13.2 Informative References
[ID-DHC-URI] J. Polk, "DHCP URI Option", draft-polk-dhc-uri-00.txt,
"work-in-progress", Sept 05
[ID-ECRIT-JAPAN] H. Arai, M. Kawanishi, draft-arai-ecrit-japan-req-
01.txt, "work-in-progress", May 2005
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Andrew Newton
21345 Ridgetop Circle
Dulles, VA 20166
Phone: +17039483382
Email: andy@hxr.us
Polk & Newton Expires March 6th, 2006 [Page 13]
Internet-Draft ECRIT Arch Considerations Sept 2005
Appendix A. Additional stuff
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk & Newton Expires March 6th, 2006 [Page 14]