< draft-polk-ieprep-flow-model-considerations-00.txt   draft-polk-ieprep-flow-model-considerations-01.txt >
Internet Engineering Task Force James M. Polk Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: July 16th, 2003 Expiration: Nov 19th, 2003
File: draft-polk-ieprep-flow-model-considerations-00.txt File: draft-polk-ieprep-flow-model-considerations-01.txt
Considerations for IEPREP Related Considerations for IEPREP Related
Protocol Packet Flow Models Protocol Packet Flow Models
January 16th, 2003 May 19th, 2003
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference material at any time. It is inappropriate to use Internet-Drafts as reference
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
Abstract Abstract
This document diagrams the packet flows - both signaling and data - of This document diagrams the packet flows - both signaling and data -
Internet Emergency Preparedness (IEPREP) related protocols. This document of Internet Emergency Preparedness (IEPREP) related protocols. This
serves as a point of reference for the WG when discussing if (and document serves as a point of reference for the WG when discussing
which) QoS mechanisms should be employed for each individual (application) which QoS mechanisms can be employed for each individual
protocol packet flow to function properly during congestion events from IP (application) protocol packet flow to function properly during
source to IP destination. congestion events from IP source to IP destination, as well as a
potentially different QOS mechanism for a related but separate data
Table of Contents flow (if present).
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Terms and Definitions . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Changes between document versions . . . . . . . . . . . . 3
1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . 3 2. Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . . 4
2.0 Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . . . . 3 3. Control and Data Plane Diagrams . . . . . . . . . . . . . . . 5
3.0 Control and Data Plane Diagrams . . . . . . . . . . . . . . . . . 4 3.1 In-Band Point-to-Point Communications . . . . . . . . . . 5
3.1 In-Band Point-to-Point Communications . . . . . . . . . . . . . . 4 3.2 In-Band Signaling Via an Intermediate Server . . . . . . 6
3.2 In-Band Signaling Via a Server . . . . . . . . . . . . . . . . . . 5 3.2.1 In-Band Signaling to a Composed Device . . . . . . . . 6
3.3 Out-of-Band Signaling . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Out-of-Band Signaling . . . . . . . . . . . . . . . . . . 7
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 3.3.1 Out-of-Band Signaling with one Control plane . . . . . 7
5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.2 Out-of-Band Signaling with two Control planes . . . . . 8
6.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Author Information . . . . . . . . . . . . . . . . . . . . . 10
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
1.0 Introduction 1. Introduction
This document diagrams the packet flows - both signaling and data - of This document diagrams the packet flows - both signaling and data -
Internet Emergency Preparedness (IEPREP) related protocols. This document of Internet Emergency Preparedness (IEPREP) related protocols. This
should be seen as a point of reference for the WG when discussing if (and document should be seen as a point of reference for the WG when
which) QoS mechanisms should be employed for each individual (application) discussing which QoS mechanisms can be employed for each individual
protocol packet flow to function properly during congestion events from IP (application) protocol packet flow to function properly during
source to IP destination. congestion events from IP source to IP destination, as well as a
potentially different QOS mechanism for a related but separate data
flow (if present).
The models shown within the document will focus (and list) those protocols The models shown within the document will focus (and list) those
of interest to the Internet Emergency Preparedness (IEPREP) Working Group. protocols of interest to the Internet Emergency Preparedness
Of particular interest here is the classification of protocols that have (IEPREP) Working Group. Of particular interest here is the
their signaling packets travel along the same path as the data packets, classification of protocols that have their signaling packets travel
and which protocols do not share the data path with their signaling along the same path as the data packets, and which protocols do not
packets. share the data path with their signaling packets.
This document will focus on the concept that in most IETF protocols there This document will focus on the concept that in most IETF protocols
are one or two control planes and one data plane. there are one or two control planes and one data plane.
1.1 Motivation 1.1 Motivation
This document clarifies paths taken by signaling and data packets for This document clarifies paths taken by signaling and data packets
typical IETF protocols. These concepts will help facilitate IEPREP for typical IETF protocols. These concepts will help facilitate
discussions on ensuring applications perform adequately during congestive IEPREP discussions on ensuring applications perform adequately
events. during congestive events.
1.2 Terms and Definitions 1.2 Terms and Definitions
The following are pointed out for clarity: The following are pointed out for clarity:
Control Plane - See "In-Band Signaling" and "Out-of-Band Signaling" Control Plane - See "In-Band Signaling" and "Out-of-Band
Signaling"
Data Plane - the data packet (media, text, MIME body) path between Data Plane - the data packet (media, text, MIME body) path
an IP source and one or more endpoints between an IP source and one or more endpoints
Intermediary Server - Any server that is the destination of control Intermediary Server - Any server that is the destination of
information from the IP source. These packets can either be control information from the IP source. These packets can
for the server itself, or for further forwarding toward the either be for the server itself, or for further forwarding
intended destination possibly manipulating the packet(s) in toward the intended destination possibly manipulating the
transit packet(s) in transit
In-Band Signaling - the control plane packets traversing the same In-Band Signaling - the control plane packets traversing the same
path as the data plane between endpoints (same source IP path as the data plane between endpoints (same source IP
address and port number, as well as the same destination IP address and port number, as well as the same destination IP
address and port number) address and port number)
Out-of-Band Signaling - the control plane taking a different path Out-of-Band Signaling - the control plane taking a different path
than the data path or the In-Band control plane (either the than the data path or the In-Band control plane (either the
source and destination IP addresses are different between the source and destination IP addresses are different between
control packets and data packets, or the port numbers used the control packets and data packets, or the port numbers
between the same source and destination IP addresses is used between the same source and destination IP addresses
different) are different)
2.0 Why Do Packet Paths Matter? 1.3 Changes between document versions
Most IETF communications use the following simple model: Here is the list of changes between internet draft versions -00 and
-01:
Sender ========> Router(s) ========> Receiver - named Figure 2 either a Triangle Model (with one server) or
Trapezoidal Model (multiple servers) for further clarification
- added Figure 4b to solve confusion surrounding categorization of
FTP
- added sections 3.3.1 and 3.3.2 to show that there can be more than
one Out-of-Band Control plane
- the above bullet resulted in the split up of Figure 5 into Figures
5a & 5b to solve the lack of categorization of MEGACO/H.248 and
H.323 in which there are two Out-Of-Band Control planes for one
data plane
- changed the document formatting to be consistent with recent RFCs
published
- added comment in Abstract and Intro sections stating that due to
the separation of paths for a communications type, different QOS
mechanisms can be considered for each plane/path
- removed the word "intermediate" from Figure 2 to relieve confusion
2. Why Do Packet Paths Matter?
Most IETF communications use the following simple model:
Sender ========> Router(s) ========> Receiver
Figure 1. Direct IP Communications Figure 1. Direct IP Communications
But many IP communications use this model (or a variant of it): But many IP communications use this model (or a variant of it):
Intermediate Server Server (one or more)
/ \ / \
Out-of-Band / \ Out-of-Band Out-of-Band / \ Out-of-Band
Control plane A / \ Control plane B Control plane A / \ Control plane B
/ Data plane \ / Data plane \
============================> ============================>
Sender Receiver Sender Receiver
++++++++++++++++++++++++++++> ++++++++++++++++++++++++++++>
In-Band Control plane In-Band Control plane
Figure 2. IP Communications using Intermediate Server Figure 2. IP Communications using Server(s)
The data plane can be within the signaling protocol (in the case of Figure 2 is called a Triangle Model when only one server is utilized
Instant Messaging), or it can be a completely different protocol (i.e. RTP by the sender and receiver. But when more than one server is used
for Voice or Video [1] or SMTP [2]). In some cases, there is no In-Band between endpoints, it is called a Trapezoidal Model.
control plane. In other cases, there is no out-of-band control plane. Some
protocols use both Out-of-Band control planes (A & B) in Figure 2
separately (such as with MEGACO/H.248[3] or H.323[4]).
An additional aspect of this model in Figure 2 above is that there will The data plane can be within the signaling protocol (in the case of
likely be more than one intermediate server involved in most protocols Instant Messaging), or it can be a completely different protocol
that communicate through any intermediate server. Most likely there is one (i.e. RTP for Voice or Video [1] or SMTP [2]). In some cases, there
in the source IP device's domain, and there is also one in the destination is no In-Band control plane. In other cases, there is no out-of-band
IP device's domain. There may or may not be any intermediate servers in control plane. Some protocols use both Out-of-Band control planes (A
the ISP(s) between these two domains; sometimes there might be several & B in Figure 2) separately (such as with MEGACO/H.248[3] or
servers between the source and destination domains. H.323[4]).
Because there can be up to 3 separate communications planes, with up to 2 An additional aspect of this model in Figure 2 is that there will
different packet paths for a communications transfer, it is important to likely be more than one (intermediate) server involved in most
understand which protocols transmit their packets on which path. The rest protocols that communicate through any intermediate server. Most
of this document will provide these various packet path models for IEPREP likely there is one in the source IP device's domain, and there is
related protocols. also one in the destination IP device's domain. There may or may not
be any intermediate servers in the ISP(s) between these two domains;
sometimes there might be several servers between the source and
destination domains.
Keep in mind that the "Receiver" in many of these diagrams is either (or Because there can be up to 3 separate control planes, with up to 2
both) a server and/or a user device. different packet paths for a data transfer, it is important to
understand which protocols transmit their packets on which path. The
rest of this document will provide these various packet path models
for IEPREP related protocols.
Also note that this document doesn't cover an exhaustive IETF protocols Keep in mind that the "Receiver" in many of these diagrams is either
list, each categorized, but attempts to include those that are of interest (or both) a server and/or a user device.
to the IEPREP effort.
3.0 Control and Data Plane Diagrams Also note that this document doesn't cover an exhaustive IETF
protocols list, but attempts to include those that are of interest
to the IEPREP effort.
Figure 1 (above) showed the simplest of IP communication between source 3. Control and Data Plane Diagrams
and destination, but this model requires the source to know the IP address
of the destination, for that source to use a protocol that requires no Figure 1 (above) showed the simplest of IP communication between
intermediate servers, and that protocol to have all necessary signaling source and destination. However, Figure 1 assumes the source device
and data traverse point to point. knows the IP address of the destination device (which is not always
the case).
3.1 In-Band Point-to-Point Communications 3.1 In-Band Point-to-Point Communications
This model is true only if the communication is as in the previous This model is true only if the communication is as in the previous
paragraph: one protocol (with one port number) and one path though a paragraph: one protocol (with one port number) and one path through
network. Figure 3 below shows this in diagram form: a network. Figure 3 below shows this in diagram form:
The signaling flow model shown in Figure 3 only applies to those
protocols that communicate from a source IP device (using one
protocol port number) and another destination IP device (using the
same protocol port number).
--------> --------> --------> --------> --------> -------->
Sender Router1 Router2 Receiver Sender Router1 Router2 Receiver
========> ========> ========> ========> ========> ========>
Legend: ----> In-Band Control plane (signaling) Legend: ----> In-Band Control plane (signaling)
====> Data plane (media/text/file) ====> Data plane (media/text/file)
Figure 3. In-Band Signaling example Figure 3. In-Band Signaling example
Protocols that use this model for IP communications are: Protocols that use this model for IP communications are:
- H.323 (without a Gatekeeper only)[4] - H.323 (without a Gatekeeper only)[4]
- Telnet [5] - Telnet [5]
- SIP (when the UAC knows the IP address of the UAS)[6] - SIP (when the UAC knows the IP address of the UAS)[6]
- HTTP [7] - HTTP [7]
- POP3 [8] - POP3 [8]
- IMAP [9] - IMAP [9]
The data plane in these protocols is set-up by the signaling (control) The data plane in these protocols is set-up by the signaling
plane between endpoints. (control) plane between endpoints.
3.2 In-Band Signaling Via a Server 3.2 In-Band Signaling Via an Intermediate Server
A variation on the In-Band Model shown in Figure 3 (above) is the one in A variation on the In-Band Model shown in Figure 3 (above) is the
Figure 4 in which all communications traverse an Intermediate Server(s). one in Figure 4a in which all communications traverse an
Here the signaling and data are contained with the same protocol that hops Intermediate Server(s). Here the signaling and data are contained
through a server(s) on its path towards the destination IP device. with the same protocol that hops through a server(s) on its path
towards the destination IP device.
In Figure 4 below, the placement of one or more routers doesn't directly In Figure 4a below, the placement of one or more routers doesn't
affect the path of the packets between the Sender to the Server and on to directly affect the path of the packets between the Sender to the
the Receiver, therefore none are shown here to make the diagram cleaner. Server and on to the Receiver, therefore none are shown here to make
the diagram cleaner.
--------------> -------------> --------------> ------------->
Sender Intermediary Server Receiver Sender Intermediary Server Receiver
==============> =============> ==============> =============>
Legend: ----> In-Band Control plane (signaling) Legend: ----> In-Band Control plane (signaling)
====> Data (media/text/file) plane ====> Data (media/text/file) plane
Figure 4. In-Band Signaling example Figure 4a. In-Band Signaling example
Signaling protocol that uses this model for IP communications is: Signaling protocol that uses this model for IP communications is:
- SIP (when used for instant messaging[10]) - SIP (when used for instant messaging[10])
The data plane generally occurs within the signaling packets as MIME The data between the two endpoints generally is within the signaling
bodies or text. packets as MIME bodies or text.
3.2.1 In-Band Signaling to a Composed Device
In-Band signaling comes in two basic models: one with a decomposed
or intermediate model (in which the destination IP device is
separate physically and logically from the server) as just shown in
Figure 4a, and a physically composed destination device (in which
the server is same device as the data receiver, but logically
separated) shown next in Figure 4b.
In this model (Figure 4b), the communications is between the same
two IP devices, but the signaling uses a different protocol port
than that of the data packets between the two devices.
+---------------+
| ___________ |
| | | |
------>| | Server | |
/ | |___________| |
-----> --------- | ___________ |
Sender Router1 | | | |
=====> ================>| | receiver | |
| |___________| |
| |
+---------------+
Composed IP Device
Legend: ----> In-Band Control plane (signaling)
====> Data (media/text/file) plane
Figure 4b. In-Band Signaling example
Protocol that uses this model for IP communications is:
- FTP [11]
A case could be made for POP3 and IMAP functioning under this model,
with SMTP being the data plane; but it was decided that since SMTP
was a different protocol (and not just port number) that these 3
protocols would be categorized in their native models.
3.3 Out-of-Band Signaling 3.3 Out-of-Band Signaling
Out-of-Band control is the case where a signaling protocol (likely) Out-of-Band control is the case where a signaling protocol (likely)
establishes the data plane via some intermediate server or servers (see establishes the data plane via some intermediate server or servers
Figure 5). In this example, the data packets are not transmitted to or (see Figure 5). In the triangle model as shown in
through the server (towards the ultimate receiver). The signaling path
from the sender to the server is not the same path as the data plane from 3.3.1 Out-of-Band Signaling with one Control plane
the sender to the receiver (which is direct in this example). Here each
path could be considered for different treatment and handling. Figure 5a shows one type of the Triangle Model depicting a single
Out-of-Band Control plane from Sender to Server to Receiver; the
data packets are not transmitted to or through the server (towards
the ultimate receiver). The signaling path from the sender to the
server is not the same path as the data plane from the sender to the
receiver (which is direct in this example). Here each path could be
considered for different treatment and handling.
Intermediary Server Intermediary Server
^ . ^ .
. . . .
............. .............> ............. .............>
Sender Router1 Router2 Receiver Sender Router1 Router2 Receiver
========> ========> ========> ========> ========> ========>
Legend: ....> Out-of-Band Control plane (signaling) Legend: ....> Out-of-Band Control plane (signaling)
====> Data (media/text/file) plane ====> Data (media/text/file) plane
Figure 5. Out-of-Band Signaling example Figure 5a. 'Single' Out-of-Band Signaling example
Protocols that use this model for IP communications are: Protocol that uses this model for IP communications is:
- SIP (for Voice and Video when the UAC does not know the IP - SIP (for Voice and Video when the UAC does not know the IP
address of the UAS, thus requiring a Proxy Server [6]) address of the UAS, thus requiring a Proxy Server [6])
- FTP [11]
H.323 [4] and MEGACO/H.248 [3] are not categorized here because these Aside from minor incremented or added/subtracted headers within the
protocols use two independent control planes between the Gatekeeper or SIP message by the (Proxy) Server, the SIP message essentially
Media Gateway Controller and each endpoint or termination (see Figure 2 - arrives in tact at the UAS.
control planes A & B).
As an example of the data plane in Figure 5 above with SIP signaling, the As an example of the data plane in Figure 5a above with SIP
data protocol is RTP (either Voice or Video [1]). signaling, the data protocol could be RTP (either Voice or Video
[1]).
4.0 Security Considerations 3.3.2 Out-of-Band Signaling with two Control planes
This document merely discusses the modeling differences of various IETF Figure 5b shows the other Triangle Model for Out-of-Band Signaling
protocols which control the communications signal between a source and in which there are multiple control planes (generally one each
(one or more) destination(s), therefore there are no special security between the endpoints and the server). These different control
considerations. planes are shown as (a) and (b) in Figure 5b. Each control plane
will be unique to that endpoint from the server.
5.0 IANA Considerations Server/Controller
^ ^
(a) . . (b)
<............ .............>
Sender Router1 Router2 Receiver
========> ========> ========>
There are no IANA considerations within this document Legend: ....> Out-of-Band Control plane (signaling)
====> Data (media/text/file) plane
6.0 Acknowledgements Figure 5b. 'Dual' Out-of-Band Signaling example
To Scott Bradner, Kimberly King, and Henning Schulzrinne for their Protocols that use this model for IP communications are:
comments and suggestions
7.0 References - MEGACO/H.248 [3]
- H.323 (H.225/H.245) [4] with a Gatekeeper
With both ITU-T protocols listed above, each uses unique control
signaling - where signal 'a' is different than signal 'b' - between
the endpoints and the server to facilitate the endpoints
communicating.
Similar to SIP in Figure 5a, MEGACO/H.248 and H.323 can use RTP in
the data plane.
4. Security Considerations
This document is restricted to discussion of the modeling
differences of various IETF protocols which control the
communications signal between a source and (one or more)
destination(s), therefore there are no special security
considerations.
5. IANA Considerations
There are no IANA considerations within this document
6. Acknowledgements
To Scott Bradner, Kimberly King, Senthilkumar Ayyasamy and Henning
Schulzrinne for their comments and suggestions
7. References
[1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ôRTP: A [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ôRTP: A
Transport Protocol for Real-Time Applicationsö, RFC 1889, January Transport Protocol for Real-Time Applicationsö, RFC 1889, January
1996 1996
[2] J. Klensin, "Simple Mail Transfer Protocol, RFC 2821, April 2001 [2] J. Klensin, "Simple Mail Transfer Protocol, RFC 2821, April 2001
[3] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. [3] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J.
Segers, ôMegaco Protocol Version 1.0ö, RFC 3015, November 2000. Segers, ôMegaco Protocol Version 1.0ö, RFC 3015, November 2000.
skipping to change at page 8, line 5 skipping to change at page 10, line 26
[9] M. Crispin, "Internet Message Access Protocol - Version 4 rev1", [9] M. Crispin, "Internet Message Access Protocol - Version 4 rev1",
RFC 2060, Dec 1996 RFC 2060, Dec 1996
[10] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. [10] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D.
Gurle, " Session Initiation Protocol (SIP) Extension for Instant Gurle, " Session Initiation Protocol (SIP) Extension for Instant
Messaging", RFC 3428, December 2002 Messaging", RFC 3428, December 2002
[11] J. Postel, J. Reynolds, "File Transfer Protocol", RFC 959, Oct [11] J. Postel, J. Reynolds, "File Transfer Protocol", RFC 959, Oct
1985 1985
8.0 Authors Information 8. Authors Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA Richardson, Texas 75082 USA
jmpolk@cisco.com jmpolk@cisco.com
"Copyright (C) The Internet Society (2002). 9. Full Copyright Statement
All Rights Reserved.
This document and translations of it may be copied and furnished to "Copyright (C) The Internet Society (2002).
others, and derivative works that comment on or otherwise explain it All Rights Reserved.
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be This document and translations of it may be copied and furnished to
revoked by the Internet Society or its successors or assigns. others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
This document and the information contained herein is provided on an The limited permissions granted above are perpetual and will not be
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING revoked by the Internet Society or its successors or assigns.
TASK FORCE DISCLAIMS 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."
The Expiration date for this Internet Draft is: This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
July 16th, 2003 The Expiration date for this Internet Draft is:
Nov 19th, 2003
 End of changes. 62 change blocks. 
190 lines changed or deleted 317 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/