WDIFF

draft-rosen-sipping-cap-02.txt --> draft-rosen-sipping-cap-03.txt

SIPPING B. Rosen
Internet-Draft NeuStar, Inc.
Intended status: Standards Track H. Schulzrinne
Expires: January 13, September 8, 2009 Columbia U.
H. Tschofenig
Nokia Siemens Networks
July 12, 2008
March 7, 2009

Session Initiation Protocol (SIP) Event Package for the Common Alerting
Protocol (CAP)
draft-rosen-sipping-cap-02.txt
draft-rosen-sipping-cap-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

This Internet-Draft is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
provisions of BCP 78 and 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 January 13, September 8, 2009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Rosen, et al. Expires September 8, 2009 [Page 1]

Internet-Draft SIP CAP March 2009

Abstract

The Common Alerting Protocol (CAP) is an XML document format for
exchanging emergency alerts and public warnings. This document
allows CAP documents to be distributed via the event notification
mechanism available with the Session Initiation Protocol (SIP).

Rosen, et al. Expires January 13, 2009 [Page 1]

Internet-Draft SIP CAP July 2008

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The 'common-alerting-protocol' Event Package . . . . . . . . . 3
3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 4
3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 4
3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 5
3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 5
3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 5
3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 6
3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6
3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6
3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 6
3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 6
3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7
3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7
3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7
3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 7
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Known Open Issues 8
5.1. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9
5.2. Forgery . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 9
5.3. Replay Attack . . 9
7.1. Registration of the 'common-alerting-protocol' Event
Package . . . . . . . . . . . . . . . . . . . . 9
5.4. Unauthorized Distribution . . . . . . 9
7.2. Registration of the
'application/common-alerting-protocol+xml' MIME type . . . 9
8. Acknowledgments . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . 10
9. References . . . . . 10
6.1. Registration of the 'common-alerting-protocol' Event
Package . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References
6.2. Registration of the
'application/common-alerting-protocol+xml' MIME type . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . 11
8. Normative References . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12

Rosen, et al. Expires January 13, September 8, 2009 [Page 2]

Internet-Draft SIP CAP July 2008 March 2009

1. Introduction

The Common Alerting Protocol (CAP) [cap] is an XML document format
for exchanging emergency alerts and public warnings. This document
allows CAP documents to be distributed via the event notification
mechanism available with the Session Initiation Protocol (SIP).

Additionally, a MIME object is registered to allow CAP documents to
be exchanged in other SIP documents.

2. Terminology

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 [RFC2119].

3. The 'common-alerting-protocol' Event Package

RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote
nodes and receiving notifications of changes (events) in their
states. It leaves the definition of many aspects of these events to
concrete extensions, known as event packages. This document defines
such an event package. This section fills in the information
required for all event packages by RFC 3265.

Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP
User Agents to publish event state. According to RFC 3903, any event
package intended to be used in conjunction with the SIP PUBLISH
method has to include a considerations section. This section also
fills the information for all event packages to be used with PUBLISH
requests.

We define

This document defines a new "common-alerting-protocol" event package.
Event Publication Agents (EPA) use PUBLISH requests to inform an
Event State Compositor (ESC) of changes in the common-alerting-protocol common-alerting-
protocol event package. Acting as a notifier, the ESC notifies
subscribers about emergency alerts and public warnings.

3.1. Package Name

The name of this package is "common-alerting-protocol". As specified
in RFC 3265 [RFC3265], this value appears in the Event header field
present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903
[RFC3903], this value also appears in the Event header field present
in PUBLISH requests.

Rosen, et al. Expires January 13, September 8, 2009 [Page 3]

Internet-Draft SIP CAP July 2008 March 2009

3.2. Event Package Parameters

RFC 3265 [RFC3265] allows event packages to define additional
parameters carried in the Event header field. This event package,
"common-alerting-protocol", does not define additional parameters.

3.3. SUBSCRIBE Bodies

According to

RFC 3265 [RFC3265], [RFC3265] allows a SUBSCRIBE request can to contain a body. The purpose of
This document allows the body depends on its type.

[Editor's Note: It is an open issue whether subscriptions to the
"common-alerting-protocol" event package carry contain civic and geodetic location
information to be carried. The 2D location shapes listed in their
body, such as
[I-D.ietf-geopriv-pdif-lo-profile], e.g., <Point> <Polygon>,
<Circle>, <Ellipse>, <ArcBand>, and a polygon defining an area for which notifications
should be received. See Section 6.]

3.4. Subscription Duration <civicAddress> element, defined
in [RFC5139], in the body of the message. The default recipient of the
SUBSCRIBE message SHOULD use this information to restrict the warning
messages that are being delivered. [Editor's note: Information about
the type of alerts that shall be received may need to be indicated as
well.]

3.4. Subscription Duration

The default expiration time for subscriptions within this package is
3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify
an alternate expiration in the Expires header field.

3.5. NOTIFY Bodies

As described in RFC 3265 [RFC3265], the NOTIFY message will contain
bodies describing the state of the subscribed resource. This body is
in a format listed in the Accept header field of the SUBSCRIBE
request, or a package-specific default format if the Accept header
field was omitted from the SUBSCRIBE request.

In this event package, the body of the notification contains a Common
Alerting Protocol (CAP) document, i.e., an XML document. The format
of the XML documents used by CAP are described in [cap].

For an initial notify, unlike for other event packages, there is no
current initial state, unless there's a pending alert. Hence,
returning a NOTIFY with a non-empty body only makes sense if there
are indeed active alerts.

All subscribers and notifiers of the "common-alerting-protocol" event
package MUST support the "application/common-alerting-protocol+xml"
data format. The SUBSCRIBE request MAY contain an Accept header
field. If no such header field is present, it has a default value of
"application/common-alerting-protocol+xml" (assuming that the Event
header field contains a value of "common-alerting-protocol"). If the
Accept header field is present, it MUST include "application/
common-alerting-protocol+xml".

Rosen, et al. Expires January 13, September 8, 2009 [Page 4]

Internet-Draft SIP CAP July 2008 March 2009

Accept header field is present, it MUST include "application/
common-alerting-protocol+xml".

3.6. Notifier Processing of SUBSCRIBE Requests

The contents of a CAP document contains public information. Hence,
providing CAP documents may not require authorization by subscribers.

3.7. Notifier Generation of NOTIFY Requests

RFC 3265 [RFC3265] details the formatting and structure of NOTIFY
messages. However, packages are mandated to provide detailed
information on when to send a NOTIFY, how to compute the state of the
resource, how to generate neutral or fake state information, and
whether state information is complete or partial. This section
describes those details for the common-alerting-protocol event
package.

A notifier MAY send a NOTIFY at any time. Typically, it will send
one when an alert or early warning message is available. The NOTIFY
request contains a body containing one or multiple CAP document(s).
The times at which the NOTIFY is sent for a particular subscriber,
and the contents of the body within that notification, are subject to
any rules specified by the authorization policy that governs the
subscription.

In the case of a pending subscription, when final authorization is
determined, a NOTIFY can be sent. If the result of the authorization
decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
complete CAP document. If the subscription is rejected, a NOTIFY MAY
be sent. As described in RFC 3265 [RFC3265], the Subscription-State
header field indicates the state of the subscription.

The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header field in the most recent SUBSCRIBE request, or
using the type "application/common-alerting-protocol+xml" if no
Accept header field was present.

Notifiers will typically act as Event State Compositors (ESC) and
thus will learn the 'common-alerting-protocol' event state via
PUBLISH requests sent from authorized Event Publication Agents
(EPAs).

3.8. Subscriber Processing of NOTIFY Requests

RFC 3265 [RFC3265] leaves it to event packages to describe the
process followed by the subscriber upon receipt of a NOTIFY request,
including any logic required to form a coherent resource state.

Rosen, et al. Expires January 13, September 8, 2009 [Page 5]

Internet-Draft SIP CAP July 2008 March 2009

3.9. Handling of Forked Requests

RFC 3265 [RFC3265] requires each package to describe handling of
forked SUBSCRIBE requests.

This specification only allows a single dialog to be constructed as a
result of emitting an initial SUBSCRIBE request.

3.10. Rate of Notifications

RFC 3265 [RFC3265] requires each package to specify the maximum rate
at which notifications can be sent.

Notifiers SHOULD NOT generate notifications for a single user at a
rate of more than once every five seconds.

3.11. State Agents

RFC 3265 [RFC3265] requires each package to consider the role of
state agents in the package and, if they are used, to specify how
authentication and authorization are done. This specification allows
state agents to be located in the network.

3.12. Examples

An example is provided in Section 4.

3.13. Use of URIs to Retrieve State

RFC 3265 [RFC3265] allows packages to use URIs to retrieve large
state documents.

CAP documents are fairly small. This event package does not provide
a mechanism to use URIs to retrieve large state documents.

3.14. PUBLISH Bodies

RFC 3903 [RFC3903] requires event packages to define the content
types expected in PUBLISH requests.

In this event package, the body of a PUBLISH request may contain a
CAP document. A CAP document describes an emergency alert or an
early warning event.

All EPAs and ESCs MUST support the "application/
common-alerting-protocol+xml" data format and MAY support other
formats.

Rosen, et al. Expires January 13, September 8, 2009 [Page 6]

Internet-Draft SIP CAP July 2008 March 2009

Note that this document does not mandate how CAP documents are made
available to the Public Warning System, for example by authorities or
similar organizations. The PUBLISH mechanism is one way.

3.15. PUBLISH Response Bodies

This specification assumes that a PUBLISH also conveys a CAP document
that is later sent further on to watchers.

3.16. Multiple Sources for Event State

RFC 3903 [RFC3903] requires event packages to specify whether
multiple sources can contribute to the event state view at the ESC.

This event package allows different EPAs to publish CAP documents for
a particular user. The concept of composition is not applicable for
this application usage.

3.17. Event State Segmentation

RFC 3903 [RFC3903] defines segments within a state document. Each
segment is defined as one of potentially many identifiable sections
in the published event state.

This event package defines does not differentiate between different
segments.

3.18. Rate of Publication

RFC 3903 [RFC3903] allows event packages to define their own rate of
publication.

There are no rate-limiting recommendations for common-alerting-
protocol publication. Since emergency alerts and early warning
events are typically rare there is no periodicity, nor a minimum or
maximum rate of publication.

4. Examples

Here is an example of a CAP document.

Rosen, et al. Expires January 13, September 8, 2009 [Page 7]

Internet-Draft SIP CAP July 2008 March 2009

<?xml version="1.0" encoding="UTF-8"?>

<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>KSTO1055887203</identifier>
<sender>KSTO@NWS.NOAA.GOV</sender>
<sent>2003-06-17T14:57:00-07:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Met</category>
<event>SEVERE THUNDERSTORM</event>
<urgency>Severe</urgency>
<certainty>Likely</certainty>
<eventCode>same=SVR</eventCode>
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description> AT 254 PM PDT...
NATIONAL WEATHER SERVICE
DOPPLER RADAR INDICATED A SEVERE
THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
OR ABOUT 18 MILES SOUTHEAST OF
KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
INTENSE RAIN AND STRONG DAMAGING WINDS
ARE LIKELY WITH THIS STORM </description>
<instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
UNTIL THE STORM PASSES </instruction>
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
IN CALIFORNIA, EXTREME NORTHEASTERN
CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
ALPINE COUNTY IN CALIFORNIA </areaDesc>
<polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14 </polygon>
<geocode>fips6=006109</geocode>
<geocode>fips6=006109</geocode>
<geocode>fips6=006103</geocode>
</area>
</info>
</alert>

Example for a Severe Thunderstorm Warning

5. Security Considerations

This section discusses security considerations when using SIP to
distribute warning messages using CAP.

Rosen, et al. Expires January 13, September 8, 2009 [Page 8]

Internet-Draft SIP CAP July 2008

5. Security Considerations

[Editor's Note: A future version of this document will describe
security considerations.]

6. Known Open Issues

Frequently, alerting events are only of regional interest since they
only have regional impact. For example: March 2009

5.1. Man-in-the-Middle Attacks

Threat:

The attacker could then conceivably attempt to impersonate the
subject (the putative caller) to some SIP-based target entity.

Countermeasures:

Such an attack is implausible for several reasons. The public in NYC does not
really need subject's
assertion:
* should be signed, thus causing any alterations to break its
integrity and make such alterations detectable.
* the intended recipients may be alerted about listed in the optionally present
audience restriction, which is a wild fire at Lake Tahoe. One
possible solution cleartext field. As such, it
would not allow automatic processing but could give the
receiving user further hints.
* Issuer is represented in the ability to allow SUBSCRIBE bodies to have a
region description that describes CAP document (in the geographic region of interest,
as a polygon.

LoST <sender>
element).
* validity period for the CAP document may also play be restricted.

5.2. Forgery

Threat:

A malicious user could forge or alter a role here, namely CAP document in order to
convey messages to SIP entities that get back a list immediate attention of URLs
where I can send
users.

Countermeasures:

To avoid this kind of attack, the SUBSCRIBE requests to. There may be a need entities must assure that proper
mechanisms for
urn:service:alerts service URN registry.

7. IANA Considerations

7.1. Registration of protecting the 'common-alerting-protocol' Event Package

This specification registers an event package, based on CAP documents are employed, e.g.,
signing the
registration procedures defined CAP document itself. Section 3.3.2.1 of [cap]
specifies the signing of CAP documents.

5.3. Replay Attack

Threat:

Theft of CAP documents described in RFC 3265 [RFC3265]. The following
is this document and replay of it
at a later time.

Countermeasures:

A CAP document contains the information required mandatory <identifier>, <sender>,
<sent> elements and an optional <expire> element. These
attributes make the CAP document unique for such a registration:
Package Name: common-alerting-protocol
Package specific sender and

Rosen, et al. Expires September 8, 2009 [Page 9]

Internet-Draft SIP CAP March 2009

provide time restrictions. An entity that has received a CAP
message already within the indicated timeframe is able to detect a
replayed message and, if the content of that message is unchanged,
then no additional security vulnerability is created. Nodes that
enter the area of a disaster after the initial distribution of
warnings have not yet seen the CAP message and, as such, would not
be able to distinguish a replay from the initial message being
sent around. However, if the threat that lead to the distribution
of warning messages is still imminent then there is no reason not
to worry about that message. The source distributing the early
warning messages is, however, adviced to carefully select a value
for the <expires> element and it is RECOMMENDED to set this
element.

5.4. Unauthorized Distribution

Threat:

When an entity receives a CAP message it has to determine whether
the entity distributing the CAP messages is genuine to avoid
accepting messages that are injected by malicious users with the
potential desire to at least get the users immediate attention.

Countermeasures:

When receiving a CAP document a couple of verification steps must
be performed. First, it needs to be ensured that the message was
delivered via a trusted entitiy (such as a trusted SIP proxy) and
that the communication channel between the User Agent and it's SIP
proxy is properly secured to exclude various attacks at the SIP
level. Then, the message contains the <sender> that may contain
an entity that falls within the white list of the entity receiving
the message. Finally, the message is protected by a digital
signature and the entity signing the CAP message may again be
listed in a white list of the receiving entity and may therefore
be trusted. If none of these verification checks lead to a
positive indication of a known sender then the CAP document should
be treated as suspicious and configuration at the receiving entity
may dictate how to process and display CAP documents in such a
case.

6. IANA Considerations

6.1. Registration of the 'common-alerting-protocol' Event Package

This specification registers an event package, based on the
registration procedures defined in RFC 3265 [RFC3265]. The following

Rosen, et al. Expires September 8, 2009 [Page 10]

Internet-Draft SIP CAP March 2009

is the information required for such a registration:
Package Name: common-alerting-protocol
Package or Template-Package: This is a package.
Published Document: RFC XXX [Replace by the RFC number of this
specification].
Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com

7.2.

6.2. Registration of the 'application/common-alerting-protocol+xml'
MIME type

To: ietf-types@iana.org
Subject: Registration of MIME media type application/ common-
alerting-protocol+xml
MIME media type name: application
MIME subtype name: common-alerting-protocol+xml
Required parameters: (none)
Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629].

Rosen, et al. Expires January 13, 2009 [Page 9]

Internet-Draft SIP CAP July 2008 the character encoding of
enclosed XML. Default is UTF-8 [RFC3629].
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry
payloads of the Common Alerting Protocol (CAP).
Interoperability considerations: This content type provides a way to
convey CAP payloads.
Published specification: RFC XXX [Replace by the RFC number of this
specification].
Applications which use this media type: Applications that convey
alerts and early warnings according to the CAP standard.
Additional information: OASIS has published the Common Alerting
Protocol at http://www.oasis-open.org/committees/
documents.php&wg_abbrev=emergency [cap].
Person & email address to contact for further information: Hannes
Tschofenig, Hannes.Tschofenig@nsn.com
Intended usage: Limited use
Author/Change controller: IETF SIPPING working group
Other information: This media type is a specialization of
application/xml RFC 3023 [RFC3023], and many of the considerations
described there also apply to application/
common-alerting-protocol+xml.

7. Acknowledgments

The authors would like to thank Cullen Jennings for supporting this
work. We would also like to thank the participants of the Early
Warning Adhoc meeting at IETF#69.

9. References

9.1.

Rosen, et al. Expires September 8, 2009 [Page 11]

Internet-Draft SIP CAP March 2009

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.

[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
1.1", October 2005.

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.

[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media

Rosen, et al. Expires January 13, 2009 [Page 10]

Internet-Draft SIP CAP July 2008
Types", RFC 3023, January 2001.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.

9.2. Informative References

[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008.

[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.

Authors' Addresses

Brian Rosen
NeuStar, Inc.
470 Conrad Dr
Mars, PA 16046
US

Phone:
Email: br@brianrosen.net

Rosen, et al. Expires September 8, 2009 [Page 12]

Internet-Draft SIP CAP March 2009

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US

Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland

Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at

Rosen, et al. Expires January 13, 2009 [Page 11]

Internet-Draft SIP CAP July 2008

Full Copyright Statement

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.

Rosen, et al. Expires January 13, September 8, 2009 [Page 12] 13]

----