draft-ietf-ippm-owdp-08.txt   draft-ietf-ippm-owdp-09.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: November 2004 Anatoly Karp Expiration Date: January 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
May 2004 July 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-08.txt> <draft-ietf-ippm-owdp-09.txt>
1. Status of this Memo 1. 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
first 29 bits. first 29 bits.
In unauthenticated mode, Username, Token, and Client-IV are unused. In unauthenticated mode, Username, Token, and Client-IV are unused.
Otherwise, Username is a 16-octet indicator of which shared secret Otherwise, Username is a 16-octet indicator of which shared secret
the client wishes to use to authenticate or encrypt and Token is the the client wishes to use to authenticate or encrypt and Token is the
concatenation of a 16-octet challenge and a 16-octet Session-key, concatenation of a 16-octet challenge and a 16-octet Session-key,
encrypted using the AES (Advanced Encryption Standard) [AES] in encrypted using the AES (Advanced Encryption Standard) [AES] in
Cipher Block Chaining (CBC). Encryption MUST be performed using an Cipher Block Chaining (CBC). Encryption MUST be performed using an
Initialization Vector (IV) of zero and a key value that is the shared Initialization Vector (IV) of zero and a key value that is the shared
secret associated with Username. The shared secret will typically be secret associated with Username. (Both the server and the client use
provided as a passphrase; in this case, the MD5 sum [RFC1321] of the the same mappings from user names to secret keys; the server, being
passphrase (without possible newline character(s) at the end of the prepared to conduct sessions with more than one client, uses user
passphrase) SHOULD be used as a key for encryption by the client and names to choose the appropriate secret key; a client would typically
decryption by the server (the passphrase also SHOULD NOT contain have different secret keys for different servers. The situation is
newlines in the middle). analogous to that of passwords, except that secret keys, rather than
being the typical low-entropy passwords, are suitable for use as AES
keys.) The shared secret will typically be provided as a passphrase;
in this case, the MD5 sum [RFC1321] of the passphrase (without
possible newline character(s) at the end of the passphrase) SHOULD be
used as a key for encryption by the client and decryption by the
server (the passphrase also SHOULD NOT contain newlines in the
middle).
Session-key and Client-IV are generated randomly by the client. Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher. Client-IV merely needs to be
unique (i.e., it MUST never be repeated for different sessions using
the same secret key; a simple way to achieve that without the use of
cumbersome state is to generate the Client-IV strings using a
cryptographically secure pseudo-random number source: if this is
done, the first repetition is unlikely to occur before 2^64 sessions
with the same secret key are conducted).
The server MUST respond with the following message: The server MUST respond with the following message:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Unused, MBZ (15 octets) | | Unused, MBZ (15 octets) |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
skipping to change at page 8, line 29 skipping to change at page 8, line 43
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime (Timestamp) | | Uptime (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Zero Padding (8 octets) | | Integrity Zero Padding (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unused 15-octet part MUST be zero. The client MUST ignore its The Unused 15-octet part MUST be zero. The client MUST ignore its
value. value. MBZ (MUST be zero) fields here and hereafter have the same
semantics: the party that sends the message MUST set the field to a
string of zero bits; the party that interprets the message MUST
ignore the value. (This way the field could be used for future
extensions.)
Server-IV is generated randomly by the server. In unauthenticated Server-IV is generated randomly by the server. In unauthenticated
mode, Server-IV is unused. mode, Server-IV is unused.
A zero value in the Accept field means that the server accepts the A zero value in the Accept field means that the server accepts the
authentication and is willing to conduct further transactions. A authentication and is willing to conduct further transactions. A
value of 1 means that the server does not accept the authentication value of 1 means that the server does not accept the authentication
provided by the client or, for some other reason, is not willing to provided by the client or, for some other reason, is not willing to
conduct further transactions in this OWAMP-Control session. All conduct further transactions in this OWAMP-Control session. All
other values are reserved. The client MUST interpret all values of other values are reserved. The client MUST interpret all values of
skipping to change at page 14, line 28 skipping to change at page 15, line 28
communication is IPv6-based. If it has no IPv4 addresses at all, the communication is IPv6-based. If it has no IPv4 addresses at all, the
last 4 octets of an IPv6 address can be used instead. Note that SID last 4 octets of an IPv6 address can be used instead. Note that SID
is always chosen by the receiver. If truly random values are not is always chosen by the receiver. If truly random values are not
available, it is important that SID be made unpredictable as available, it is important that SID be made unpredictable as
knowledge of SID might be used for access control. knowledge of SID might be used for access control.
5.4. Send Schedules 5.4. Send Schedules
The sender and the receiver need to both know the same send schedule. The sender and the receiver need to both know the same send schedule.
This way, when packets are lost, the receiver knows when they were This way, when packets are lost, the receiver knows when they were
sent. It is desirable to compress common schedules and still to be supposed to be sent. It is desirable to compress common schedules
able to use an arbitrary one for the test sessions. In many cases, and still to be able to use an arbitrary one for the test sessions.
the schedule will consist of repeated sequences of packets: this way, In many cases, the schedule will consist of repeated sequences of
the sequence performs some test, and the test is repeated a number of packets: this way, the sequence performs some test, and the test is
times to gather statistics. repeated a number of times to gather statistics.
To implement this, we have a schedule with a given number of `slots'. To implement this, we have a schedule with a given number of `slots'.
Each slots has a type and a parameter. Two types are supported: Each slots has a type and a parameter. Two types are supported:
exponentially distributed pseudo-random quantity (denoted by a code exponentially distributed pseudo-random quantity (denoted by a code
of 0) and a fixed quantity (denoted by a code of 1). The parameter of 0) and a fixed quantity (denoted by a code of 1). The parameter
is expressed as a timestamp and specifies a time interval. For a is expressed as a timestamp and specifies a time interval. For a
type 0 slot (exponentially distributed pseudo-random quantity) this type 0 slot (exponentially distributed pseudo-random quantity) this
interval is the mean value (or 1/lambda if the distribution density interval is the mean value (or 1/lambda if the distribution density
function is expressed as lambda*exp(-lambda*x) for positive values of function is expressed as lambda*exp(-lambda*x) for positive values of
x). For a type 1 slot, the parameter is the delay itself. The x). For a type 1 slot, the parameter is the delay itself. The
skipping to change at page 19, line 11 skipping to change at page 20, line 11
the Request-Session command. the Request-Session command.
If a receiver of an OWAMP-Test session learns through OWAMP-Control If a receiver of an OWAMP-Test session learns through OWAMP-Control
Stop-Sessions message that the OWAMP-Test sender's last sequence Stop-Sessions message that the OWAMP-Test sender's last sequence
number is lower than any sequence number actually received, the number is lower than any sequence number actually received, the
results of the complete OWAMP-Test session MUST be invalidated. results of the complete OWAMP-Test session MUST be invalidated.
A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control
Stop-Sessions command, MUST discard any packet records -- including Stop-Sessions command, MUST discard any packet records -- including
lost packet records -- with a (computed) send time that falls between lost packet records -- with a (computed) send time that falls between
the current time minus timeout and the current time. This ensures the current time minus Timeout and the current time. This ensures
statistical consistency for the measurement of loss and duplicates in statistical consistency for the measurement of loss and duplicates in
the event that the timeout is greater than the time it takes for the the event that the Timeout is greater than the time it takes for the
Stop-Sessions command to take place. Stop-Sessions command to take place.
To effect complete sessions, each side of the control connection To effect complete sessions, each side of the control connection
SHOULD wait until all Sessions are complete before sending the Stop- SHOULD wait until all Sessions are complete before sending the Stop-
Sessions message. The completed time of each sessions is determined Sessions message. The completed time of each sessions is determined
as Timeout after the scheduled time for the last sequence number. as Timeout after the scheduled time for the last sequence number.
Endpoints MAY add a small increment to the computed completed time Endpoints MAY add a small increment to the computed completed time
for send endpoints to ensure the Stop-Sessions message reaches the for send endpoints to ensure the Stop-Sessions message reaches the
receiver endpoint after Timeout. receiver endpoint after Timeout.
skipping to change at page 21, line 19 skipping to change at page 22, line 19
command because of a session that ended prematurely; or it might command because of a session that ended prematurely; or it might
be greater because of duplicates. be greater because of duplicates.
+ 12 octets of Integrity Zero Padding. + 12 octets of Integrity Zero Padding.
+ Zero or more (as specified) packet records. + Zero or more (as specified) packet records.
Each packet record is 25 octets, and includes 4 octets of sequence Each packet record is 25 octets, and includes 4 octets of sequence
number, 8 octets of send timestamp, 2 octets of send timestamp error number, 8 octets of send timestamp, 2 octets of send timestamp error
estimate, 8 octets of receive timestamp, and 2 octets of receive estimate, 8 octets of receive timestamp, and 2 octets of receive
timestamp error estimate and 1 octet of TTL (in this order): timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number | 00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp | 04| Send Timestamp |
08| | 08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | | 12| Send Error Estimate | |
skipping to change at page 21, line 45 skipping to change at page 22, line 45
24| TTL | 24| TTL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Packet records are sent out in the same order they are made when the Packet records are sent out in the same order they are made when the
results of the session are recorded. Therefore, the data is in results of the session are recorded. Therefore, the data is in
arrival order. arrival order.
Note that lost packets (if any losses were detected during the OWAMP- Note that lost packets (if any losses were detected during the OWAMP-
Test session) MUST appear in the sequence of packets. They can Test session) MUST appear in the sequence of packets. They can
appear either at the point when the loss was detected or at any later appear either at the point when the loss was detected or at any later
point. Lost packet records are distinguished by the receive point. Lost packet records are distinguished as follows:
timestamp consisting of a string of zero bits and an error estimate
with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for + A send timestamp filled with the presumed send time (as computed
definition of these quantities and explanation of timestamp format by the send schedule).
and error estimate format).
+ A send error estimate filled with Multiplier=1, Scale=64, and S=0
(see the OWAMP-Test description for definition of these quantities
and explanation of timestamp format and error estimate format).
+ A receive timestamp consisting of all zero bits.
+ A normal receive error estimate as determined by the error of the
clock being used to declare the packet lost (it MUST be declared
lost if it is not received Timeout after the presumed send time as
determined by the receivers clock).
+ A TTL value of 255.
The last (possibly full, possibly incomplete) block (16 octets) of The last (possibly full, possibly incomplete) block (16 octets) of
data is padded with zeros if necessary. (These zeros are simple data is padded with zeros if necessary. (These zeros are simple
padding and should be distinguished from the 16 octets of Integrity padding and should be distinguished from the 16 octets of Integrity
Zero Padding that follow the session data and conclude the response Zero Padding that follow the session data and conclude the response
to Fetch-Session.) to Fetch-Session.)
6. OWAMP-Test 6. OWAMP-Test
This section describes OWAMP-Test protocol. It runs over UDP using This section describes OWAMP-Test protocol. It runs over UDP using
skipping to change at page 22, line 29 skipping to change at page 23, line 42
OWAMP-Control session inherit its mode. OWAMP-Control session inherit its mode.
OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and
OWAMP-Test receiver can potentially all be different machines. (In a OWAMP-Test receiver can potentially all be different machines. (In a
typical case we expect that there will be only two machines.) typical case we expect that there will be only two machines.)
6.1. Sender Behavior 6.1. Sender Behavior
The sender sends the receiver a stream of packets with schedule as The sender sends the receiver a stream of packets with schedule as
specified in the Request-Session command. The sender SHOULD set the specified in the Request-Session command. The sender SHOULD set the
TTL in the UDP packet to 255. The format of the body of a UDP packet TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The
in the stream depends on the mode being used. format of the body of a UDP packet in the stream depends on the mode
being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 25, line 32 skipping to change at page 26, line 49
Receiver knows when the sender will send packets. The following Receiver knows when the sender will send packets. The following
parameter is defined: Timeout (from Request-Session). Packets that parameter is defined: Timeout (from Request-Session). Packets that
are delayed by more than Timeout are considered lost (or `as good as are delayed by more than Timeout are considered lost (or `as good as
lost'). Note that there is never an actual assurance of loss by the lost'). Note that there is never an actual assurance of loss by the
network: a `lost' packet might still be delivered at any time. The network: a `lost' packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255). within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never To the best of the authors' knowledge, this requirement was never
actually implemented (and of course only a complete and universal actually implemented (and of course only a complete and universal
implementation would ensure that packets don't travel for longer than implementation would ensure that packets don't travel for longer than
TTL seconds). Further, IPv4 specification makes no claims about the TTL seconds). In fact, in IPv6 the name of this field has actually
time it takes the packet to traverse the last link of the path. been changed to Hop Limit. Further, IPv4 specification makes no
claims about the time it takes the packet to traverse the last link
of the path.
The choice of a reasonable value of Timeout is a problem faced by a The choice of a reasonable value of Timeout is a problem faced by a
user of OWAMP protocol, not by an implementor. A value such as two user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the data faster than interactive `one-way ping') might wish to obtain the data faster than
that. that.
As packets are received, As packets are received,
+ Timestamp the received packet. + Timestamp the received packet.
+ In authenticated or encrypted mode, decrypt first block (16 + In authenticated or encrypted mode, decrypt first block (16
octets) of packet body. octets) of packet body.
+ Store the packet sequence number, send time, receive time, and the + Store the packet sequence number, send time, receive time, and the
TTL from the packet IP header for the results to be transferred. TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for
the results to be transferred.
+ Packets not received within the Timeout are considered lost. They + Packets not received within the Timeout are considered lost. They
are recorded with their true seqno, presumed send time, receive are recorded with their true seqno, presumed send time, receive
time consisting of a string of zero bits, and TTL of 255. time consisting of a string of zero bits, and TTL (or Hop Limit)
of 255.
Implementations SHOULD fetch the TTL value from the IP header of the Implementations SHOULD fetch the TTL/Hop Limit value from the IP
packet. If an implementation does not fetch the actual TTL value header of the packet. If an implementation does not fetch the actual
(the only good reason to not do so is inability to access the TTL TTL value (the only good reason to not do so is inability to access
field of arriving packets), it MUST record the TTL value as 255. the TTL field of arriving packets), it MUST record the TTL value as
255.
Packets that are actually received are recorded in the order of Packets that are actually received are recorded in the order of
arrival. Lost packet records serve as indications of the send times arrival. Lost packet records serve as indications of the send times
of lost packets. They SHOULD be placed either at the point where the of lost packets. They SHOULD be placed either at the point where the
receiver learns about the loss or at any later point; in particular, receiver learns about the loss or at any later point; in particular,
one MAY place all the records that correspond to lost packets at the one MAY place all the records that correspond to lost packets at the
very end. very end.
Packets that have send time in the future MUST be recorded normally, Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be without changing their send timestamp, unless they have to be
skipping to change at page 30, line 39 skipping to change at page 32, line 9
client. client.
OWAMP-Test sessions could be used as covert channels of information. OWAMP-Test sessions could be used as covert channels of information.
Environments that are worried about covert channels should take this Environments that are worried about covert channels should take this
into consideration. into consideration.
Notice that AES in counter mode is used for pseudo-random number Notice that AES in counter mode is used for pseudo-random number
generation, so implementation of AES MUST be included even in a generation, so implementation of AES MUST be included even in a
server that only supports unauthenticated mode. server that only supports unauthenticated mode.
9.1. An OWAMP server can consume resources of various kinds. The two
most important kinds of resources are network capacity and memory
(primary or secondary) for storing test results.
Any implementation of OWAMP server MUST include technical mechanisms
to limit the use of network capacity and memory. Mechanisms for
managing the resources consumed by unauthenticated users and users
authenticated with a username and passphrase SHOULD be separate. The
default configuration of an implementation MUST enable these
mechanisms and set the resource use limits to conservatively low
values.
One way to design the resource limitation mechanisms is as follows:
assign each session to a user class. User classes are partially
ordered with ``includes'' relation, with one class (``all users'')
that is always present and that includes any other class. The
assignment of a session to a user class can be based on the presence
of authentication of the session, the user name, IP address range,
time of day, and, perhaps, other factors. Each user class would have
a limit for usage of network capacity (specified in units of
bit/second) and memory for storing test results (specified in units
of octets). Along with the limits for resource use, current use
would be tracked by the server. When a session is requested by a
user in a specific user class, the resources needed for this session
are computed: the average network capacity use (based on the sending
schedule) and the maximum memory use (based on the number of packets
and number of octets each packet would need to be stored internally
-- note that outgoing sessions would not require any memory use).
These resource use numbers are added to the current resource use
numbers for the given user class; if such addition would take the
resource use outside of the limits for the given user class, the
session is rejected. When resources are reclaimed, corresponding
measures are subtracted from the current use. Network capacity is
reclaimed as soon as the session ends. Memory is reclaimed when the
data is deleted. For unauthenticated sessions, memory consumed by an
OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control
connection that initiated the session is closed (gracefully or
otherwise). For authenticated sessions, the administrator who
configures the service should be able to decide the exact policy, but
useful policy mechanisms that MAY be implemented are the ability to
automatically reclaim memory when the data is retrieved and the
ability to reclaim memory after a certain configurable (based on user
class) period of time passes after the OWAMP-Test session terminates.
10. IANA Considerations 10. IANA Considerations
IANA is requested to allocate a well-known TCP port number for OWAMP- IANA is requested to allocate a well-known TCP port number for OWAMP-
Control part of the OWAMP protocol. Control part of the OWAMP protocol.
11. Internationalization Considerations 11. Internationalization Considerations
The protocol does not carry any information in a natural language. The protocol does not carry any information in a natural language.
12. Appendix A: Sample Implementation of Exponential Deviate Computation 12. Appendix A: Sample Implementation of Exponential Deviate Computation
skipping to change at page 38, line 17 skipping to change at page 40, line 22
Stanislav Shalunov <shalunov@internet2.edu> Stanislav Shalunov <shalunov@internet2.edu>
Benjamin Teitelbaum <ben@internet2.edu> Benjamin Teitelbaum <ben@internet2.edu>
Anatoly Karp <ankarp@yahoo.com> Anatoly Karp <ankarp@yahoo.com>
Jeff Boote <boote@internet2.edu> Jeff Boote <boote@internet2.edu>
Matthew J. Zekauskas <matt@internet2.edu> Matthew J. Zekauskas <matt@internet2.edu>
Expiration date: November 2004 Expiration date: January 2005
 End of changes. 

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