draft-ietf-opes-iab-04.txt   draft-ietf-opes-iab-05.txt 
Open Pluggable Edge Services A. Barbir Open Pluggable Edge Services A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: June 1, 2004 A. Rousskov Expires: October 11, 2004 A. Rousskov
The Measurement Factory The Measurement Factory
December 2, 2003 April 12, 2004
OPES Treatment of IAB Considerations OPES Treatment of IAB Considerations
draft-ietf-opes-iab-04 draft-ietf-opes-iab-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2004. This Internet-Draft will expire on October 11, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
IETF Internet Architecture Board (IAB) expressed nine IETF Internet Architecture Board (IAB) expressed nine
architecture-level considerations for the Open Pluggable Edge architecture-level considerations for the Open Pluggable Edge
Services (OPES) framework. This document describes how OPES Services (OPES) framework. This document describes how OPES
addresses those considerations. addresses those considerations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5
4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6
5. Notification Considerations . . . . . . . . . . . . . . . . . 8 5. Notification Considerations . . . . . . . . . . . . . . . . . 8
5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8
5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 10
5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11
5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture The Open Pluggable Edge Services (OPES) architecture
[I-D.ietf-opes-architecture], enables cooperative application [I-D.ietf-opes-architecture], enables cooperative application
services (OPES services) between a data provider, a data consumer, services (OPES services) between a data provider, a data consumer,
and zero or more OPES processors. The application services under and zero or more OPES processors. The application services under
consideration analyze and possibly transform application-level consideration analyze and possibly transform application-level
messages exchanged between the data provider and the data consumer. messages exchanged between the data provider and the data consumer.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
issues that OPES solutions should be required to address. These issues that OPES solutions should be required to address. These
recommendations were formulated in the form of a specific IAB recommendations were formulated in the form of a specific IAB
considerations document [RFC3238]. In that document, IAB emphasized considerations document [RFC3238]. In that document, IAB emphasized
that its considerations did not recommend specific solutions and did that its considerations did not recommend specific solutions and did
not mandate specific functional requirements. Addressing an IAB not mandate specific functional requirements. Addressing an IAB
consideration may involve showing appropriate protocol mechanisms or consideration may involve showing appropriate protocol mechanisms or
demonstrating that the issue does not apply. Addressing a demonstrating that the issue does not apply. Addressing a
consideration does not necessarily mean supporting technology implied consideration does not necessarily mean supporting technology implied
by the consideration wording. by the consideration wording.
The primary goal of this document is to show that all IAB The primary goal of this document is to show that all formal IAB
recommendations are addressed by OPES, to the extent that those recommendations are addressed by OPES, to the extent that those
considerations can be addressed by an IETF working group. The considerations can be addressed by an IETF working group. The
limitations of OPES working group to address certain aspects of IAB limitations of OPES working group to address certain aspects of IAB
considerations are also explicitly documented. considerations are also explicitly documented.
There are nine IAB considerations [RFC3238] that OPES has to address. IAB considerations document [RFC3238] contains many informal
In the core of this document are the corresponding nine recommendations. For example, while the IAB informally requires OPES
architecture to "protect end-to-end data integrity by supporting
end-host detection and response to inappropriate behavior by OPES
intermediaries", the IAB has chosen to formalize these requirements
via a set of more specific recommendations, such as Notification
considerations addressed in Section 5.3 and Section 5.4 below. OPES
framework addresses informal IAB recommendations by addressing
corresponding formal considerations.
There are nine formal IAB considerations [RFC3238] that OPES has to
address. In the core of this document are the corresponding nine
"Consideration" sections. For each IAB consideration, its section "Consideration" sections. For each IAB consideration, its section
contains general discussion as well as references to specific OPES contains general discussion as well as references to specific OPES
mechanisms relevant to the consideration. mechanisms relevant to the consideration.
2. Terminology 2. Terminology
This document does not introduce any new terminology but uses This document does not introduce any new terminology but uses
terminology from other OPES documents it quotes. terminology from other OPES documents it quotes.
3. Consideration (2.1) 'One-party consent' 3. Consideration (2.1) 'One-party consent'
"An OPES framework standardized in the IETF must require that the use "An OPES framework standardized in the IETF must require that the use
of any OPES service be explicitly authorized by one of the of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider or application-layer end-hosts (that is, either the content provider or
the client)."[RFC3238] the client)."[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to OPES architecture requires that "OPES processors MUST be consented to
by either the data consumer or data provider application" by either the data consumer or data provider application"
[I-D.ietf-opes-architecture]. This requirement alone cannot prevent [I-D.ietf-opes-architecture]. While this requirement directly
consent-less introduction of OPES processors. In satisfies IAB concern, no requirement alone can prevent consent-less
[I-D.ietf-opes-end-comm], the OPES architecture enables concerned introduction of OPES processors. In other words, OPES framework
parties to detect unwanted OPES processors by examining OPES traces. requires one-party consent but cannot guarantee it in the presence of
The use of traces in OPES is mandatory. incompliant OPES entities.
A tracing mechanism on its own cannot detect processors that are in In [I-D.ietf-opes-end-comm], the OPES architecture enables concerned
violation of OPES specifications. Examples include OPES processors parties to detect unwanted OPES processors by examining OPES traces.
operating in stealth mode. However, the OPES architecture allows the While the use of traces in OPES is mandatory, a tracing mechanism on
use of content signature to verify the authenticity of performed its own cannot detect processors that are in violation of OPES
specifications. Examples include OPES processors operating in
stealth mode. However, the OPES architecture allows the use of
content signature to verify the authenticity of performed
adaptations. Content signatures is a strong but expensive mechanism adaptations. Content signatures is a strong but expensive mechanism
that can detect any modifications of signed content provided that the that can detect any modifications of signed content provided that the
content provider is willing to sign the data and that the client is content provider is willing to sign the data and that the client is
willing to either check the signature or relay received content to willing to either check the signature or relay received content to
the content provider for signature verification. the content provider for signature verification.
OPES adaptations may include copying and other forms of non-modifying OPES entities may copy or otherwise access content without modifying
access to content. These kinds of adaptations cannot be detected by it. Such access cannot be detected using content signatures. Thus,
the above mentioned mechanisms. Thus, "passive" OPES processors can "passive" OPES entities can operate on signed content without the
operate on the content without the data consumer or provider consent. data consumer or provider consent. If content privacy is a concern,
If presence of such processors is a concern, then content encryption then content encryption can be used. A passive processor is no
can be used. A passive processor is no different from a proxy or an different from any intermediary operating outside of OPES framework.
intermediary operating outside of OPES framework. No OPES mechanism No OPES mechanism (existing or foreseeable) can prevent non-modifying
(existing or foreseeable) can prevent non-modifying access to access to content.
content.
In summary, the one-party consent is satisfied by including the
corresponding requirement in the IAB architecture document. That
requirement alone cannot stop incompliant OPES entities to perform
consent-less adaptations, but OPES framework allows for various means
of detecting and/or preventing such adaptations. These means
typically introduce overheads and require some level of
producer-consumer cooperation.
4. Consideration (2.2) 'IP-layer communications' 4. Consideration (2.2) 'IP-layer communications'
"For an OPES framework standardized in the IETF, the OPES "For an OPES framework standardized in the IETF, the OPES
intermediary must be explicitly addressed at the IP layer by the end intermediary must be explicitly addressed at the IP layer by the end
user."[RFC3238] user."[RFC3238]
The OPES architecture requires that "OPES processors MUST be The OPES architecture requires that "OPES processors MUST be
addressable at the IP layer by the end user (data consumer addressable at the IP layer by the end user (data consumer
application)" [I-D.ietf-opes-architecture]. The IAB and the application)" [I-D.ietf-opes-architecture]. The IAB and the
skipping to change at page 8, line 39 skipping to change at page 8, line 40
^ V [with trace] ^ V [with trace]
| | | |
+-<-- [notification] ---+ +-<-- [notification] ---+
Figure 2 Figure 2
Since notifications cannot be piggy-backed to application messages, Since notifications cannot be piggy-backed to application messages,
they create new messages and may double the number of messages the they create new messages and may double the number of messages the
sender has to process. The number of messages that need to be proceed sender has to process. The number of messages that need to be proceed
is larger if several intermediaries on the message path generate is larger if several intermediaries on the message path generate
notifications). Associating notifications with application messages notifications. Associating notifications with application messages
may require duplicating application message information in may require duplicating application message information in
notifications and may require maintaining a sender state until notifications and may require maintaining a sender state until
notification is received. These actions increase the performance notification is received. These actions increase the performance
overhead of notifications. overhead of notifications.
The level of available details in notifications versus provider The level of available details in notifications versus provider
interest in supporting notification is another concern. Experience interest in supporting notification is another concern. Experience
shows that content providers often require very detailed information shows that content providers often require very detailed information
about user actions to be interested in notifications at all. For about user actions to be interested in notifications at all. For
example, Hit Metering protocol [RFC2227] has been designed to supply example, Hit Metering protocol [RFC2227] has been designed to supply
skipping to change at page 9, line 27 skipping to change at page 9, line 28
Thus, instead of explicitly supporting notifications at the protocol Thus, instead of explicitly supporting notifications at the protocol
level, OPES concentrates on tracing facilities. In essence, OPES level, OPES concentrates on tracing facilities. In essence, OPES
supports notifications indirectly, using tracing facilities. In other supports notifications indirectly, using tracing facilities. In other
words, the IAB choice of "Notification" label is interpreted as words, the IAB choice of "Notification" label is interpreted as
"Notification assistance" (i.e. making notifications meaningful) and "Notification assistance" (i.e. making notifications meaningful) and
is not interpreted as a "Notification protocol". is not interpreted as a "Notification protocol".
The above concerns call for making notification optional. The OPES The above concerns call for making notification optional. The OPES
architecture allows for an efficient and meaningful notification architecture allows for an efficient and meaningful notification
protocol to be implemented in certain OPES environments. For protocol to be implemented in certain OPES environments. For
example, a Cable Company Internet Service Provider (Cable ISP) may example, an OPES callout server attached to a gateway or firewall may
provide a user-configurable porn filtering service to its subscribers scan outgoing traffic for signs of worm or virus activity and notify
while having an agreement with the parent Cable Company to send a local Intrusion Detection System (IDS) of potentially compromised
notifications to the content provider when clients (content hosts (e.g., servers or client PCs) inside the network. Such
consumers) use the same filter to block Company's advertisement notifications may use OPES tracing information to pinpoint the
images. If the Cable Company deems such subscriber actions infected host (which could be another OPES entity). In this example,
inappropriate, the company may contact individual subscribers and notifications are essentially sent back to the content producer (the
enforce their ISP usage policy according to the terms of the service local network) and use OPES tracing to supply details.
agreement. In this example, ISP cooperation is expected, the volume
of notifications would be relatively low, and notifications can be Another environment where efficient and meaningful notification using
handled in an automated manner. OPES tracing is possible are Content Delivery Networks (CDNs). A CDN
node may use multiple content adaptation services to customize
generic content supplied by the content producer (a web site). For
example, a callout service may insert advertisements for client-local
events. The CDN node itself may not understand specifics of the ad
insertion algorithm implemented at callout servers. However, the
node may use information in the OPES trace (e.g., coming from the
callout service) to notify the content producer. Such notifications
may be about the number of certain advertisements inserted (i.e., the
number of "impressions" delivered to the customer) or even the number
of ad "clicks" the customer made (e.g., if the node hosts content
linked from the ads). Callout services doing ad insertion may lack
details (e.g., a customer ID/address or a web server authentication
token) to contact the content producer directly in this case. Thus,
OPES trace produced by an OPES service becomes essential in enabling
meaningful notifications that the CDN node sends to the content
producer.
5.2 An example of an OPES trace for HTTP 5.2 An example of an OPES trace for HTTP
The example below illustrates adaptations done to HTTP request at an The example below illustrates adaptations done to HTTP request at an
OPES processor operated by the client ISP. Both original (as sent by OPES processor operated by the client ISP. Both original (as sent by
an end user) and adapted (as received by the origin web server) an end user) and adapted (as received by the origin web server)
requests are shown. The primary adaptation is the modification of requests are shown. The primary adaptation is the modification of
HTTP "Accept" header. The secondary adaptation is the addition of an HTTP "Accept" header. The secondary adaptation is the addition of an
OPES-System HTTP extension header [I-D.ietf-opes-http]. OPES-System HTTP extension header [I-D.ietf-opes-http].
skipping to change at page 14, line 13 skipping to change at page 14, line 13
notification-related considerations above. notification-related considerations above.
7. Consideration (4.1) 'URI resolution' 7. Consideration (4.1) 'URI resolution'
"OPES documentation must be clear in describing these services as "OPES documentation must be clear in describing these services as
being applied to the result of URI resolution, not as URI resolution being applied to the result of URI resolution, not as URI resolution
itself."[RFC3238] itself."[RFC3238]
"OPES Scenarios and Use Cases" specification "OPES Scenarios and Use Cases" specification
[I-D.ietf-opes-scenarios] documents content adaptations that are in [I-D.ietf-opes-scenarios] documents content adaptations that are in
scope of the OPES framework. Scenarios include adaptations of scope of the OPES framework. Scenarios include content adaptation of
requests and responses. These adaptations do not include URI requests and responses. These documented adaptations do not include
resolution adaptations. In some environments, it is technically URI resolution. In some environments, it is technically possible to
possible to adapt URIs (and other kinds of identifiers or addresses) use documented OPES mechanisms to resolve URIs (and other kinds of
using documented OPES mechanisms. The OPES framework cannot identifiers or addresses). The OPES framework cannot effectively
effectively prohibit any specific adaptations. prevent any specific kind of adaptation.
For example, a CDN node may substitute domain names in URLs with
CDN-chosen IP addresses, essentially performing a URI resolution on
behalf of the content producer (i.e., the web site owner). An OPES
callout service running on a user PC may rewrite all HTML-embedded
advertisement URLs to point to a user-specified local image,
essentially performing a URI redirection on behalf of the content
consumer (i.e., the end user). Such URI manipulations are outside of
the OPES framework scope, but cannot be effectively eliminated from
the real world.
8. Consideration (4.2) 'Reference validity' 8. Consideration (4.2) 'Reference validity'
"All proposed services must define their impact on inter- and "All proposed services must define their impact on inter- and
intra-document reference validity."[RFC3238] intra-document reference validity."[RFC3238]
The OPES framework does not propose adaptation services. However, The OPES framework does not propose adaptation services. However,
OPES tracing requirements include identification of OPES OPES tracing requirements include identification of OPES
intermediaries and services (for details, see "Notification" intermediaries and services (for details, see "Notification"
consideration sections in this document). It is required that consideration sections in this document). It is required that
skipping to change at page 19, line 8 skipping to change at page 19, line 8
processor and a callout server via optional (negotiated) transport processor and a callout server via optional (negotiated) transport
encryption mechanisms [I-D.ietf-opes-ocp-core]. encryption mechanisms [I-D.ietf-opes-ocp-core].
For example, TLS encryption [RFC2817] can be used among HTTP hops For example, TLS encryption [RFC2817] can be used among HTTP hops
(some of which could be OPES processors) and between each OPES (some of which could be OPES processors) and between each OPES
processor and a callout server. processor and a callout server.
12. Security Considerations 12. Security Considerations
This document does not define any mechanisms that may be subject to This document does not define any mechanisms that may be subject to
security considerations. Security considerations for OPES mechanisms security considerations. This document scope is to address specific
are discussed in corresponding OPES framework documents. IAB considerations. Security of OPES mechanisms are discussed in
Security Considerations sections of the corresponding OPES framework
documents.
For example, OPES tracing mechanisms assist content providers and
consumers in protecting content integrity and confidentiality by
requiring OPES intermediaries to disclose their presence. Security of
the tracing mechanism is discussed in the Security Considerations
section of [I-D.ietf-opes-end-comm].
13. Compliance 13. Compliance
This document may be perceived as a proof of OPES compliance with IAB This document may be perceived as a proof of OPES compliance with IAB
implied recommendations. However, this document does not introduce implied recommendations. However, this document does not introduce
any compliance subjects. Compliance of OPES implementations is any compliance subjects. Compliance of OPES implementations is
defined in other OPES documents discussed above. defined in other OPES documents discussed above.
Appendix A. Change Log Appendix A. Change Log
RFC Editor Note: This section is to be removed during the final RFC Editor Note: This section is to be removed during the final
publication of the document. publication of the document.
Internal WG revision control ID: $Id: iab-cons.xml,v 1.32 2003/12/03 Internal WG revision control ID: $Id: iab-cons.xml,v 1.36 2004/04/12
06:46:04 rousskov Exp $ 16:06:52 rousskov Exp $
2004/04/08
* Replaced "Cable Company ISP" Notification example with two new
examples to address IESG uncertainty about the meaning of the
old convoluted example.
* Polished text addressing "One-party consent" concern to better
show why the concern is addressed. It is not clear whether the
changes will address IESG review comment that "the WG does not
seem to get it" [because?] the text does not "name situations
where one-party consent does make sense". It is currently not
clear how naming such situations can address IAB concern, and
why naming such situations is in this document scope.
* Polished text discussing URI resolution consideration to talk
more specifically about the resolution of URIs rather than
(more general) adaptation of URIs and added examples. This
change is meant to address IESG concern that URI resolution is
not addressed or the corresponding description is confusing.
* Clarified in the Introduction that the purpose of this document
is to address nine formal IAB considerations, and that we hope
that addressing formal consideration is sufficient to address
any informal ones that are scattered through the IAB
Considerations document. This is meant to address IESG concern
that some [informal] words from the IAB Consideration document
do not explicitly appear in this document.
* Be more specific about where security of OPES mechanisms is
discussed. Added an example of where security of OPES tracing
mechanisms is discussed. This document is about addressing
specific IAB considerations and is not a map/index to OPES
mechanisms or their security. However, polished text and
example may provide the reader with more direct clues on where
to find security-related information that goes beyond the scope
of this document.
2003/11/18 2003/11/18
* Added an example where an efficient and meaningful notification * Added an example where an efficient and meaningful notification
protocol can be implemented in OPES. protocol can be implemented in OPES.
* Assume Communications draft will contain wording about * Assume Communications draft will contain wording about
documenting impact on reference validity. documenting impact on reference validity.
* Use OPES-System HTTP header for examples and mention OPES-Via. * Use OPES-System HTTP header for examples and mention OPES-Via.
skipping to change at page 23, line 8 skipping to change at page 24, line 8
* Added Abbie Barbir as an author. * Added Abbie Barbir as an author.
head-sid7 head-sid7
* Initial revision * Initial revision
Normative References Normative References
[I-D.ietf-opes-end-comm] [I-D.ietf-opes-end-comm]
Barbir, A., "OPES processor and end points Barbir, A., "OPES entities and end points communication",
communications", draft-ietf-opes-end-comm-05 (work in draft-ietf-opes-end-comm-06 (work in progress), December
progress), October 2003. 2003.
[I-D.ietf-opes-architecture] [I-D.ietf-opes-architecture]
Barbir, A., "An Architecture for Open Pluggable Edge Barbir, A., "An Architecture for Open Pluggable Edge
Services (OPES)", draft-ietf-opes-architecture-04 (work in Services (OPES)", draft-ietf-opes-architecture-04 (work in
progress), December 2002. progress), December 2002.
[I-D.ietf-opes-scenarios] [I-D.ietf-opes-scenarios]
Barbir, A., "OPES Use Cases and Deployment Scenarios", Barbir, A., "OPES Use Cases and Deployment Scenarios",
draft-ietf-opes-scenarios-01 (work in progress), August draft-ietf-opes-scenarios-01 (work in progress), August
2002. 2002.
skipping to change at page 25, line 29 skipping to change at page 26, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/