RFC relevance of contains

As per Relevance of the word contains, we have this rfc below:

Network Working Group D.
Request for Comments: 2641 D.
Category: Informational Cabletron Systems
August 1999

Cabletron's VlanHello Protocol
Version 4

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

The VlanHello protocol is part of the InterSwitch Message
(ISMP) which provides interswitch communication between
running Cabletron's SecureFast VLAN (SFVLAN) product. Switches
the VlanHello protocol to discover their neighboring switches
establish the topology of the switch fabric

Table of

1. Introduction...................................... 2
1.1 Data Conventions.............................. 2
2. VlanHello Protocol Operational Overview........... 2
2.1 Neighbor Discovery............................ 2
2.2 Port States................................... 3
2.3 Topology Events............................... 5
2.4 Timers........................................ 9
3. InterSwitch Message Protocol...................... 9
3.1 Frame Header.................................. 10
3.2 ISMP Packet Header............................ 11
3.3 ISMP Message Body............................. 12
4. Interswitch Keepalive Message..................... 13
5. Security Considerations........................... 16
6. References........................................ 16
7. Authors' Addresses................................ 16
8. Full Copyright Statement.......................... 17

Hamilton & Ruffen Informational [Page 1]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

1.

This memo is being distributed to members of the Internet
in order to solicit reactions to the proposals contained herein
While the specification discussed here may not be directly
to the research problems of the Internet, it may be of interest
researchers and implementers

1.1 Data

The methods used in this memo to describe and picture data adhere
the standards of Internet Protocol documentation [RFC1700],
particular

The convention in the documentation of Internet Protocols is
express numbers in decimal and to picture data in "big-endian
order. That is, fields are described left to right, with the
significant octet on the left and the least significant octet
the right

The order of transmission of the header and data described in
document is resolved to the octet level. Whenever a diagram
a group of octets, the order of transmission of those octets
the normal order in which they are read in English

Whenever an octet represents a numeric quantity the left most
in the diagram is the high order or most significant bit.
is, the bit labeled 0 is the most significant bit

Similarly, whenever a multi-octet field represents a
quantity the left most bit of the whole field is the
significant bit. When a multi-octet quantity is transmitted
most significant octet is transmitted first

2. VlanHello Protocol Operational

Switches use the VlanHello protocol to detect their
switches and establish the topology of the switch fabric

2.1 Neighbor

At initialization, each switch sends an Interswitch Keepalive
out all local ports except those which have been preconfigured
that they cannot be Network ports (see Section 2.2). Then, as
switch discovers its neighboring switches via incoming
Keepalive messages, it notifies its local topology services (
Section 2.3), which then build the topology tables for the
fabric

Hamilton & Ruffen Informational [Page 2]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Each switch continues to send Interswitch Keepalive messages
regular intervals (currently 5 seconds). If a switch has not
from one of its neighbors for some predetermined interval (
Section 2.4), notification is sent to all interested services and
neighboring switch is removed from the topology table

Interswitch Keepalive messages are described in Section 4.

2.2 Port

Each port on a switch can be in one of several different states
These states are listed below. Figure 1 shows how the port
changes within the VlanHello protocol

o Unknown. This is the default state of all ports
initialization

o Network. A port is deemed a Network port when the switch
received an Interswitch Keepalive message over the port from
of its neighbor switches. A transition to this state triggers
Neighbor Found event, notifying the local topology servers
the interface is functioning and a 2-way conversation has
established with the neighbor

When the last switch is lost on a Network port, the state of
switch reverts to either Network Only (see next state) or
Unknown, and a Neighbor Lost event is triggered, notifying
local topology servers that the interface is no
operational

o Network Only. Certain types of port interfaces are incapable
accessing user endstations and can only be used to access
switches. Such ports are deemed Network Only ports. If the
switch is lost from a port that has already been deemed a
port, the VlanHello protocol checks the condition of the
interface. If it is the type of interface that can only be
to access other switches, the state of the port is set to
Only. Otherwise, it reverts to Unknown

o Standby. A port is deemed a Standby port under the
conditions

Hamilton & Ruffen Informational [Page 3]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

o The neighbor switch on the port has a higher level
functionality and it has determined that the local switch
incompatible with that functionality. In this circumstance
the MAC entry for the local switch in the Interswitch
message received from the neighbor contains an assigned
of Incompatible

o The list of MAC entries in the Interswitch Keepalive
received from the neighbor switch does not contain an entry
the local switch. In this circumstance, the local
assumes that communication with its neighbor will be one-
only

The VlanHello protocol continues to listen for
Keepalive messages on a Standby port, but does not transmit
Interswitch Keepalive messages over the port. If a message
received that removes the condition under which the port state
set to Standby, the state of the port is set to Network

o Going to Access. When any packet other than an
Keepalive message is received over an Unknown port, the state
the port is changed to Going to Access and a timer is activated
If the timer expires without an Interswitch Keepalive
being received over the port, the port state changes to Access

o Access. A port is deemed an Access port when any packet
than an Interswitch Keepalive message has been received over
port and the Going to Access timer has expired. A port can
be administratively designated an Access "control" port,
the port is to remain an Access port, regardless of the type
messages that are received on it. Interswitch Keepalive
are not sent over Access control ports

Three other types of ports are recognized: the host management port
host data port, and host control port. These ports are designated
initialization and are used to access the host CPU.
Keepalive messages are not sent over these ports

Hamilton & Ruffen Informational [Page 4]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Packet
|

+---------+
Packet in | Unknown |
| +---------+
G-A V |
Timer +----------+ no
exp | Going to |<------[KA msg?] Packet
<------| Access | | |
| +----------+ yes |
V | V yes +---------+
+--------+ V [1-way?]------+-->| Standby |
| Access | [KA msg?] | ^ +---------+
+--------+ | | no | |
| V no |
yes | [compatible?]----+ [KA msg?]
| | |
| | yes |
| V
V +---------+ [1-way?]
+--------->| Network |<--+ |
+---------+ ^ |
| | yes
lost last | +<----[compatible?]
neighbor |

[network
[ only? ]
|
+--------------+ yes | no +---------+
| Network Only |<-----------+----------->| Unknown |
+--------------+ +---------+

Figure 1: Port State

2.3 Topology

When the VlanHello protocol discovers new information about
status of one of its network ports, it notifies its local
service center so that the service center can build or modify
topology tables for the switch fabric. This notification takes
form of a system event, described in a structure known as a
relay structure. These structures are linked in a first-in/first-
(FIFO) queue and processed by the topology servers in the order
which they were received

Hamilton & Ruffen Informational [Page 5]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

A topology relay structure typically contains information
Interswitch Keepalive messages received on the specified port,
shown below

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | Delta options mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08 | Current options mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | |
+ Port neighbor switch identifier +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port neighbor IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | ... Port neighbor IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neighbor chassis MAC addr +
32 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | Neighbor chassis IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Neighbor functional level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | Topology agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | Next event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This 4-octet field contains the number of the event
Valid values are as follows

1 A new neighbor switch was discovered on
specified port
2 The neighbor switch has gained the feature(s
specified in the Delta options mask
3 The neighbor switch has lost the feature(s
specified in the Delta options mask
4 The neighbor switch has timed out and is
down
5 The specified port is down

Hamilton & Ruffen Informational [Page 6]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

6 The neighbor switch has been previously seen on
different port. The specified port is
previous port
7 The specified port is being reassigned to
topology agent. Event is generated by the
(old) agent
8 The port is looped -- that is, the
message was generated by the receiving switch
9 The port is crossed -- that is, a Keepalive
was received on a port not owned by this
agent
10 The neighbor switch's functional level has changed
11 The neighbor switch is running an
version of the protocol
12 Two-way communication with the neighbor switch
been lost
13 The neighbor switch's Keepalive message
number has been reset, indicating the
itself has been reset

Delta options

This 4-octet field contains a bit map specifying the feature(s
gained or lost by the neighbor switch (events 2 and 3 only).
Valid values are as specified for the next field, Current
mask

Current options

This 4-octet field contains a bit map specifying the features
the neighbor switch. Bit assignments are as follows

1 (unused
2 The switch is a VLAN switch
4 The switch has link state capability
8 The switch has loop-free flood path capability
16 The switch has resolve capability
32 (unused
64 The switch has tag-based flood capability
128 The switch has tap capability
256 The switch has message connection capability
512 The switch has redundant access capability
1024 The switch is an isolated switch
4096 The switch is an uplink. (SFVLAN V1.8 only
8192 The switch is an uplink to core. (SFVLAN V1.8 only
16384 The port is an uplink port. (SFVLAN V1.8 only
32768 The port is an uplink flood port. (SFVLAN V1.8 only

Hamilton & Ruffen Informational [Page 7]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Port

This 4-octet field contains the logical number of the local
for which the event was generated

Port neighbor switch

This 10-octet field contains the internal identifier of
neighbor switch discovered on the port. The identifier
of the 6-octet physical (MAC) address of the neighbor switch
followed by the 4-octet logical port number (local to the
switch) on which the neighbor was discovered

Port neighbor IP

This 4-octet field contains the Internet Protocol (IP) address
the neighbor switch

Neighbor chassis MAC

This 6-octet field contains the physical (MAC) address of
chassis of the neighbor switch

Neighbor chassis IP

This 4-octet field contains the Internet Protocol (IP) address
the chassis of the neighbor switch

Neighbor functional

This 4-octet field contains the functional level of the
switch, as determined by the version level of the SecureFast
software under which this switch is operating. Valid values
as follows

1 The switch is running a version of SFVLAN prior to Version 1.8.
2 The switch is running SFVLAN Version 1.8 or greater

Topology

This 4-octet field contains a pointer to the topology agent
generated the event. The pointer here can reference any of
topology agents that send Interswitch Keepalive messages --
is, any agent running the VlanHello protocol

Hamilton & Ruffen Informational [Page 8]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Next

This 4-octet field contains a pointer to the next event
structure in the list

2.4

The VlanHello protocol uses three timers

o Send Hello timer. The Send Hello timer is used to control
interval at which Interswitch Keepalive messages are sent

o Aging timer. The Aging Timer is used to detect when
with a neighboring switch has been lost

o Going to Access timer. The Going to Access timer is used
synchronize the transition of a port state to Access and prevent
port from being prematurely designation as an Access port
network initialization. If an Unknown port receives any
other than an Interswitch Keepalive message, the port state is
to Going To Access. If the switch receives an
Keepalive message over that port before the timer expires,
port state is changed to Network. Otherwise, when the
expires, the port state is changed to Access

3. InterSwitch Message

The VlanHello protocol operates as part of the InterSwitch
Protocol (ISMP) -- part of Cabletron's SecureFast VLAN (SFVLAN
product, as described in [IDsfvlan]. ISMP provides a
method of encapsulating and transmitting network control
exchanged between SFVLAN switches

ISMP message packets are of variable length and have the
general structure

o Frame
o ISMP packet
o ISMP message

Hamilton & Ruffen Informational [Page 9]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

3.1 Frame

ISMP packets are encapsulated within an IEEE 802-compliant
using a standard header as shown below

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address +
08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ +
: :

Destination

This 6-octet field contains the Media Access Control (MAC)
of the multicast channel over which all switches in the
receive ISMP packets. The destination address fields of all
packets contain a value of 01-00-1D-00-00-00.

Source

This 6-octet field contains the physical (MAC) address of
switch originating the ISMP packet

This 2-octet field identifies the type of data carried within
frame. The type field of ISMP packets contains the value 0x81FD

Hamilton & Ruffen Informational [Page 10]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

3.2 ISMP Packet

The ISMP packet header consists of a variable number of octets,
shown below

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
://////// Frame header /////////////////////////////////////////:
+//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////| ISMP Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | ISMP message type | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Code length | |
+-+-+-+-+-+-+-+-+ +
| Authentication code |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :

Frame

This 14-octet field contains the frame header

ISMP

This 2-octet field contains the version number of the
Message Protocol to which this ISMP packet adheres. The
protocol uses ISMP Version 3.0.

ISMP message

This 2-octet field contains a value indicating which type of
message is contained within the message body.
Interswitch Keepalive messages have a message type of 2.

Sequence

This 2-octet field contains an internally generated
number used by the various protocol handlers for
synchronization of messages

Hamilton & Ruffen Informational [Page 11]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Code

This 1-octet field contains the number of octets in
Authentication code field of the message

Authentication

This variable-length field contains an encoded value used
authentication of the ISMP message

3.3 ISMP Message

The ISMP message body is a variable-length field containing
actual data of the ISMP message. The length and content of
field are determined by the value found in the message type field

The format of the VlanHello Interswitch Keepalive message
described in the next section

Hamilton & Ruffen Informational [Page 12]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

4. Interswitch Keepalive

The VlanHello Interswitch Keepalive message consists of a
number of octets, as shown below

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Frame header / +
: ISMP packet header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Version | Switch IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+4 | ... Switch IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n+8 | |
+ Switch ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+16 | |
+ Chassis MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Chassis IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+24 | ... Chassis IP address | Switch type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+28 | Functional level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+32 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+36 | Base MAC count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n+40 | |
: Base MAC entries :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

n = 21 + length of the authentication code of the

Frame header/ISMP packet

This variable-length field contains the frame header and the
packet header

Hamilton & Ruffen Informational [Page 13]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

This 2-octet field contains the version number of the
protocol to which this message adheres. This document
VlanHello Version 4.

Switch IP

This 4-octet field contains the Internet Protocol (IP) address
the sending switch

Switch

This 10-octet field contains the internal ISMP identifier of
sending switch. The identifier is generated by the sending
and consists of the 6-octet physical (MAC) address of the switch
followed by a 4-octet value containing the logical port
over which the switch sent the packet

Chassis

This 6-octet field contains the physical (MAC) address of
chassis of the sending switch

Chassis IP

This 4-octet field contains the Internet Protocol (IP) address
the switch chassis

Switch

This 2-octet field contains the type of the switch. Currently,
only value recognized here is as follows

2 The switch is an SFVLAN switch

Functional

This 4-octet field contains the functional level of the
switch, as determined by the version level of the SecureFast
software under which this switch is operating. Valid values
as follows

1 The switch is running a version of SFVLAN prior to
1.8.
2 The switch is running SFVLAN Version 1.8 or greater

Hamilton & Ruffen Informational [Page 14]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

This 4-octet field contains a bit map specifying the features
the switch. Bit assignments are as follows

1 (unused
2 The switch is a VLAN switch
4 The switch has link state capability
8 The switch has loop-free flood path capability
16 The switch has resolve capability
32 (unused
64 The switch has tag-based flood capability
128 The switch has tap capability
256 The switch has message connection capability
512 The switch has redundant access capability
1024 The switch is an isolated switch
4096 The switch is an uplink. (SFVLAN V1.8 only
8192 The switch is an uplink to core. (SFVLAN V1.8 only
16384 The port is an uplink port. (SFVLAN V1.8 only
32768 The port is an uplink flood port. (SFVLAN V1.8 only

Base MAC

This 2-octet field contains the number of entries in the list
Base MAC entries

Base MAC

This variable-length field contains a list of entries for
neighboring switches that the sending switch has
discovered on the port over which the message was sent. The
of entries is found in the Base MAC count field

Each MAC entry is 10 octets long, structured as follows

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Switch MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Assigned neighbor state ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Assigned neighbor state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hamilton & Ruffen Informational [Page 15]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

Switch MAC

This 6-octet field contains the base MAC address of
neighboring switch

Assigned neighbor

This 4-octet field contains the assigned state of the
switch as perceived by the sending switch. Currently, the
value valid here is 3, indicating a state of

5. Security

Security concerns are not addressed in this document

6.

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.

[IDsfvlan] Ruffen, D., Len, T. and J. Yanacek, "Cabletron'
SecureFast VLAN Operational Model", RFC 2643,
1999.

[IDvlsp] Kane, L., "Cabletron's VLS Protocol Specification",
2642, August 1999.

7. Authors'

Dave
Cabletron Systems, Inc
Post Office Box 5005
Rochester, NH 03866-5005

Phone:(603) 332-9400
EMail: daveh@ctron.

Dave
Cabletron Systems, Inc
Post Office Box 5005
Rochester, NH 03866-5005

Phone:(603) 332-9400
EMail: ruffen@ctron.

Hamilton & Ruffen Informational [Page 16]

RFC 2641 Cabletron's VlanHello Protocol Version 4 August 1999

17. Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Hamilton & Ruffen Informational [Page 17]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX