draft-ietf-rtfm-ruleset-language-05.txt   draft-ietf-rtfm-ruleset-language-06.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
Expires November 1999 Expires December 1999
SRL: A Language for Describing Traffic Flows SRL: A Language for Describing Traffic Flows
and Specifying Actions for Flow Groups and Specifying Actions for Flow Groups
<draft-ietf-rtfm-ruleset-language-05.txt> <draft-ietf-rtfm-ruleset-language-06.txt>
Status of this Memo Status of this Memo
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 all
provisions of Section 10 of RFC2026. 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 Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
Abstract Abstract
This document describes a language for specifying rulesets, i.e. This document describes a language for specifying rulesets, i.e.
configuration files which may be loaded into a traffic flow meter so as configuration files which may be loaded into a traffic flow meter so as
to specify which traffic flows are measured by the meter, and the to specify which traffic flows are measured by the meter, and the
information it will store for each flow. information it will store for each flow.
Contents Contents
1 Purpose and Scope 3 1 Purpose and Scope 2
1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 2
1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 SRL Language Description 5 2 SRL Language Description 4
2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Statement 6 3 Statement 5
3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 10 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 11 3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 10
3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 12 3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 11
3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 12 3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 11
3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 12 3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 11
3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 12 3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 11
3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 13 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 12
3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Example Programs 14 4 Example Programs 13
4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 14 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 13
4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 15 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 14
5 IANA Considerations 16 5 Security Considerations 16
6 APPENDICES 17 6 IANA Considerations 16
6.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 17
6.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 19
6.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 19
7 Acknowledgments 21 7 APPENDICES 16
7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 16
7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 18
7.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 19
8 References 21 8 Acknowledgments 21
9 Author's Address 21 9 References 21
10 Author's Address 21
1 Purpose and Scope 1 Purpose and Scope
A ruleset for an RTFM Meter is a sequence of instructions to be executed A ruleset for an RTFM Meter is a sequence of instructions to be executed
by the meter's Pattern Matching Engine (PME). The form of these by the meter's Pattern Matching Engine (PME). The form of these
instructions is described in detail in the 'RTFM Architecture' and 'RTFM instructions is described in detail in the 'RTFM Architecture' and 'RTFM
Meter MIB' documents [1], [2], but most users - at least initially - Meter MIB' documents [1], [2], but most users - at least initially -
find them confusing and difficult to write, mainly because the effect of find them confusing and difficult to write, mainly because the effect of
each instruction is strongly dependent on the state of the meter's each instruction is strongly dependent on the state of the meter's
Packet Matching Engine at the moment of its execution. Packet Matching Engine at the moment of its execution.
skipping to change at page 3, line 29 skipping to change at page 3, line 29
which can then be downloaded to RTFM meters. which can then be downloaded to RTFM meters.
An SRL compiler is available as part of NeTraMet (a free-software An SRL compiler is available as part of NeTraMet (a free-software
implementation of the RTFM meter and manager), version 4.2 [3]. implementation of the RTFM meter and manager), version 4.2 [3].
1.1 RTFM Meters and Traffic Flows 1.1 RTFM Meters and Traffic Flows
The RTFM Architecture [1] defines a set of 'attributes' which apply to The RTFM Architecture [1] defines a set of 'attributes' which apply to
network traffic. Among the attributes are 'address attributes,' such as network traffic. Among the attributes are 'address attributes,' such as
PeerType, PeerAddress, TransType and TransAddress, which have meaning PeerType, PeerAddress, TransType and TransAddress, which have meaning
for many protocols, e.g. for IP traffic (PeerType == IP) PeerAddress is for many protocols, e.g. for IPv4 traffic (PeerType == 1) PeerAddress
an IP address, TransType is TCP, UDP, ICMP, etc., and TransAddress is is an IP address, TransType is TCP(6), UDP(17), ICMP(1), etc., and
usually an IP port number. TransAddress is usually an IP port number.
An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter
as they pass across a network between two end points (or to/from a as they pass across a network between two end points (or to/from a
single end point). Each 'end point' of a flow is specified by the set single end point). Each 'end point' of a flow is specified by the set
of values of its address attributes. of values of its address attributes.
An 'RTFM Meter' is a measuring device - e.g. a program running on a An 'RTFM Meter' is a measuring device - e.g. a program running on a
Unix or PC host - which observes passing packets and builds 'Flow Data Unix or PC host - which observes passing packets and builds 'Flow Data
Records' for the flows of interest. Records' for the flows of interest.
skipping to change at page 5, line 46 skipping to change at page 6, line 7
the equal sign, and continues up to (but not including) the closing the equal sign, and continues up to (but not including) the closing
semicolon. If a semicolon is required within the defined text it must semicolon. If a semicolon is required within the defined text it must
be preceded by a backslash, i.e. \; in an SRL define produces ; in the be preceded by a backslash, i.e. \; in an SRL define produces ; in the
text. text.
Wherever defname appears elsewhere in the program, it will be replaced Wherever defname appears elsewhere in the program, it will be replaced
by the defined text. by the defined text.
For example, For example,
DEFINE ftp = (20, 21); DEFINE ftp = (20, 21); # Well-known Port numbers from [4]
DEFINE telnet = 23; DEFINE telnet = 23;
DEFINE www = 80; DEFINE www = 80;
2.2 Program 2.2 Program
------------+-------+-------- Statement -------+-------+----------- ------------+-------+-------- Statement -------+-------+-----------
| | | | | | | |
| +------- Declaration ------+ | | +------- Declaration ------+ |
| | | |
+---------------------<--------------------+ +---------------------<--------------------+
skipping to change at page 14, line 36 skipping to change at page 14, line 36
statement executed after RETURN will be the statement immediately statement executed after RETURN will be the statement immediately
following ENDCALL. following ENDCALL.
4 Example Programs 4 Example Programs
4.1 Classify IP Port Numbers 4.1 Classify IP Port Numbers
# #
# Classify IP port numbers # Classify IP port numbers
# #
if SourcePeerType == IP save; define IPv4 = 1; # Address Family number from [4]
else ignore; # Not an IP packet
# #
define ftp = (20, 21); # Well-Known Port numbers from [4]
define telnet = 23;
define www = 80;
#
define tcp = 6; # Protocol numbers from [4]
define udp = 17;
#
if SourcePeerType == IPv4 save;
else ignore; # Not an IPv4 packet
#
if (SourceTransType == tcp __ SourceTransType == udp) save, {
if SourceTransAddress == (www, ftp, telnet) nomatch; if SourceTransAddress == (www, ftp, telnet) nomatch;
# We want the well-known port as Dest # We want the well-known port as Dest
# #
if DestTransAddress == telnet if DestTransAddress == telnet
save, store FlowKind := 'T'; save, store FlowKind := 'T';
else if DestTransAddress == www else if DestTransAddress == www
save, store FlowKind := 'W'; save, store FlowKind := 'W';
else if DestTransAddress == ftp else if DestTransAddress == ftp
save, store FlowKind := 'F'; save, store FlowKind := 'F';
else { else {
save DestTransAddress; save DestTransAddress;
store FlowKind := '?'; store FlowKind := '?';
} }
}
else save SourceTransType = 0;
#
save SourcePeerAddress /32; save SourcePeerAddress /32;
save DestPeerAddress /32; save DestPeerAddress /32;
count; count;
# #
This program counts only IP packets, saving SourceTransType (tcp, udp or This program counts only IP packets, saving SourceTransType (tcp, udp or
0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W'
for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The
program uses a NOMATCH action to specify the packet direction - its program uses a NOMATCH action to specify the packet direction - its
resulting flows will have the well-known ports as their destination. resulting flows will have the well-known ports as their destination.
skipping to change at page 16, line 35 skipping to change at page 17, line 5
save SourcePeerAddress /24; save SourcePeerAddress /24;
save DestPeerAddress /24; save DestPeerAddress /24;
count; count;
This version uses a NOMATCH statement to ensure that its resulting flows This version uses a NOMATCH statement to ensure that its resulting flows
have my_net as their source. The NOMATCH also rejects my_net -> my_net have my_net as their source. The NOMATCH also rejects my_net -> my_net
traffic. Traffic which doesn't have my_net as source or destination traffic. Traffic which doesn't have my_net as source or destination
saves 24 bits of its peer addresses (the subroutine might only have saves 24 bits of its peer addresses (the subroutine might only have
saved 16) before counting such an unusual flow. saved 16) before counting such an unusual flow.
5 IANA Considerations 5 Security Considerations
SRL is a language for creating rulesets (i.e. configuration files) for
RTFM Traffic Meters - it does not present any security issues in itself.
On the other hand, flow data gathered using such rulesets may well be
valuable. It is therefore important to take proper precautions to
ensure that access to the meter and its data is secure. Ways to achieve
this are discussed in detail in the Architecture and Meter MIB documents
[1,2].
6 IANA Considerations
Appendix C below lists the RTFM attributes by name. Since SRL only Appendix C below lists the RTFM attributes by name. Since SRL only
refers to attributes by name, SRL users do not have to know the refers to attributes by name, SRL users do not have to know the
attribute numbers. attribute numbers.
The size (in bytes) of the various attribute values is also listed in The size (in bytes) of the various attribute values is also listed in
Appendix C. These sizes reflect the object sizes for the attribute Appendix C. These sizes reflect the object sizes for the attribute
values as they are stored in the RTFM Meter MIB [2]. values as they are stored in the RTFM Meter MIB [2].
IANA considerations for allocating new attributes are discussed in IANA considerations for allocating new attributes are discussed in
detail in the RTFM Architecture document [1]. detail in the RTFM Architecture document [1].
6 APPENDICES 7 APPENDICES
6.1 Appendix A: SRL Syntax in BNF 7.1 Appendix A: SRL Syntax in BNF
<SRL program> ::= <S or D> | <SRL program> <S or D> <SRL program> ::= <S or D> | <SRL program> <S or D>
<S or D> ::= <statement> | <declaration> <S or D> ::= <statement> | <declaration>
<declaration> ::= <Subroutine declaration> <declaration> ::= <Subroutine declaration>
<statement> ::= <IF statement> | <statement> ::= <IF statement> |
<Compound statement> | <Compound statement> |
<Imperative statement> | <Imperative statement> |
skipping to change at page 19, line 12 skipping to change at page 19, line 37
<int label seq> ::= <integer> : | <int label seq> <integer> : <int label seq> ::= <integer> : | <int label seq> <integer> :
The following are terminals, recognised by the scanner: The following are terminals, recognised by the scanner:
<identifier> Described in section 2 <identifier> Described in section 2
<integer> A decimal integer <integer> A decimal integer
<attribute> Attribute name, as listed in Appendix C <attribute> Attribute name, as listed in Appendix C
<value>, <mask> Described in section 5.2 <value>, <mask> Described in Appendix B
<width> ::= <integer> <width> ::= <integer>
<label> ::= <identifier> <label> ::= <identifier>
<variable> ::= SourceClass _ DestClass _ FlowClass _ <variable> ::= SourceClass | DestClass | FlowClass |
SourceKind _ DestKind _ FlowKind SourceKind | DestKind | FlowKind
6.2 Appendix B: Syntax for Values and Masks 7.2 Appendix B: Syntax for Values and Masks
Values and masks consist of sequences of numeric fields, each of one or Values and masks consist of sequences of numeric fields, each of one or
more bytes. The non-blank character following a field indicates the more bytes. The non-blank character following a field indicates the
field width, and whether the number is decimal or hexadecimal. These field width, and whether the number is decimal or hexadecimal. These
'field type' characters may be: 'field type' characters may be:
. period decimal, single byte . period decimal, single byte
- minus hex, single byte - minus hex, single byte
! exclaim decimal, two bytes ! exclaim decimal, two bytes
skipping to change at page 19, line 46 skipping to change at page 20, line 24
and 1.3.0.10.0.50 are two different ways to specify the same value. and 1.3.0.10.0.50 are two different ways to specify the same value.
Unspecified fields (at the right-hand side of a value or mask) are set Unspecified fields (at the right-hand side of a value or mask) are set
to zero, i.e. 130.216 is the same as 130.216.0.0. to zero, i.e. 130.216 is the same as 130.216.0.0.
If only a single field is specified (no field width character), the If only a single field is specified (no field width character), the
value given fills the whole field. For example, 23 and 0.23 specify the value given fills the whole field. For example, 23 and 0.23 specify the
same value for a SourceTransAddress operand. For variables (which have same value for a SourceTransAddress operand. For variables (which have
one-byte values) a C-style character constant may also be used. one-byte values) a C-style character constant may also be used.
In addition, addresses and masks may also use the conventions set IPv6 addresses and masks may also be used, following the conventions set
out in the IP Version 6 Addressing Architecture RFC [4]. out in the IP Version 6 Addressing Architecture RFC [5].
6.3 Appendix C: RTFM Attribute Information 7.3 Appendix C: RTFM Attribute Information
The following attributes may be tested in an IF statement, and their The following attributes may be tested in an IF statement, and their
values may be SAVEd (except for MatchingStoD). Their size (in bytes) is values may be SAVEd (except for MatchingStoD). Their maximum size (in
shown to the left, and a brief description is given for each. bytes) is shown to the left, and a brief description is given for each.
The names given here are reserved words in SRL (they are <attribute>
terminals in the grammar given in Appendix A).
Note that this table gives only a very brief summary. The Meter MIB
[2] provides the definitive specification of attributes and their
allowed values. The MIB variables which represent flow attributes
have 'flowData' prepended to their names to indicate that they belong
to the MIB's flowData table.
1 SourceInterface, DestInterface 1 SourceInterface, DestInterface
Interface(s) on which the flow was observed Interface(s) on which the flow was observed
1 SourceAdjacentType, DestAdjacentType 1 SourceAdjacentType, DestAdjacentType
Indicates the interface type(s) Indicates the interface type(s), i.e. an ifType from [4], or
an Address Family Number (if metering within a tunnel)
6 SourceAdjacentAddress, DestAdjacentAddress 20 SourceAdjacentAddress, DestAdjacentAddress
For IEEE 802.x interfaces, the MAC addresses for the flow For IEEE 802.x interfaces, the MAC addresses for the flow
1 SourcePeerType, DestPeerType 1 SourcePeerType, DestPeerType
Peer protocol types, e.g. IPv4, Novell, Ethertalk, .. Peer protocol types, i.e. Address Family Number from [4],
such as IPv4, Novell, Ethertalk, ..
4 SourcePeerAddress, DestPeerAddress 20 SourcePeerAddress, DestPeerAddress
Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk)) Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk))
1 SourceTransType, DestTransType 1 SourceTransType, DestTransType
Transport layer type, e.g TCP, UDP, IS-IS Transport layer type, i.e.. Protocol Number from [4]
such as tcp(6), udp(17), ospf(89), ..
2 SourceTransAddress, DestTransAddress 2 SourceTransAddress, DestTransAddress
Transport layer addresses (port numbers for TCP and UDP) Transport layer addresses (e.g. port numbers for TCP and UDP)
1 FlowRuleset 1 FlowRuleset
Rule set number for the flow Rule set number for the flow
1 MatchingStoD 1 MatchingStoD
Indicates whether the packet is being matched with its Indicates whether the packet is being matched with its
addresses in 'wire order.' See reference [1] for details. addresses in 'wire order.' See reference [1] for details.
The following variables may be tested in an IF, and their values may be The following variables may be tested in an IF, and their values may be
set by a STORE. They all have one-byte values. set by a STORE. They all have one-byte values.
skipping to change at page 20, line 49 skipping to change at page 21, line 41
The following RTFM attributes are not address attributes - they are The following RTFM attributes are not address attributes - they are
measured attributes of a flow. Their values may be read from an RTFM measured attributes of a flow. Their values may be read from an RTFM
meter. (For example, NeTraMet uses a FORMAT statement to specify which meter. (For example, NeTraMet uses a FORMAT statement to specify which
attribute values are to be read from the meter.) attribute values are to be read from the meter.)
8 ToOctets, FromOctets 8 ToOctets, FromOctets
Total number of octets seen for each direction of the flow Total number of octets seen for each direction of the flow
8 ToPDUs, FromPDUs 8 ToPDUs, FromPDUs
Total number of PDUs seen for each direction of the flow Total number of PDUs seen for each direction of the flow
4 FirstTime, LastTime 4 FirstTime, LastActiveTime
Time (in centiseconds) that first and last PDUs were seen Time (in centiseconds) that first and last PDUs were seen
for the flow for the flow
Other attributes will be defined by the RTFM working group from time to Other attributes will be defined by the RTFM working group from time to
time. time.
7 Acknowledgments 8 Acknowledgments
The SRL language is part of the RTFM Working Group's efforts to make the The SRL language is part of the RTFM Working Group's efforts to make the
RTFM traffic measurement system easier to use. Initial work on the RTFM traffic measurement system easier to use. Initial work on the
language was done by Cyndi Mills and Brad Frazee in Boston. SRL was language was done by Cyndi Mills and Brad Frazee in Boston. SRL was
developed in Auckland; it was greatly assisted by detailed discussion developed in Auckland; it was greatly assisted by detailed discussion
with John White and Russell Fulton. Discussion has continued on the with John White and Russell Fulton. Discussion has continued on the
RTFM and NeTraMet mailing lists. RTFM and NeTraMet mailing lists.
8 References 9 References
[1] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow [1] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow
Measurement: Architecture", RFC 2063, The University of Measurement: Architecture", RFC 2063, The University of
Auckland, GTE Laboratories, Inc, January 1997. Auckland, GTE Laboratories, Inc, January 1997.
[2] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC [2] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
2064, The University of Auckland, January 1997. RFC 2064, The University of Auckland, January 1997.
[3] Brownlee, N., NeTraMet home page, [3] Brownlee, N., NeTraMet home page,
http://www.auckland.ac.nz/net/NeTraMet http://www.auckland.ac.nz/net/NeTraMet
[4] Hinden, R., and Deering, S., "IP Version 6 Addressing [4] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700,
ISI, October 1994.
[5] Hinden, R., and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, Nokia, Cisco Systems, July 1998. Architecture", RFC 2373, Nokia, Cisco Systems, July 1998.
9 Author's Address 10 Author's Address
Nevil Brownlee Nevil Brownlee
Information Technology Systems & Services Information Technology Systems & Services
The University of Auckland The University of Auckland
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Expires November 1999 Expires December 1999
 End of changes. 40 change blocks. 
74 lines changed or deleted 113 lines changed or added

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