RFC relevance of assigned

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

Network Working Group S.
Request for Comments: 3182 R.
Obsoletes: 2752
Category: Standards Track R.
P.
T.

S.
PolicyConsulting.
R.

October 2001

Identity Representation for

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

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

This document describes the representation of identity information
POLICY_DATA object for supporting policy based admission control
the Resource ReSerVation Protocol (RSVP). The goal of
representation is to allow a process on a system to securely
the owner and the application of the communicating process (e.g.,
user id) and convey this information in RSVP messages (PATH or RESV
in a secure manner. We describe the encoding of identities as
policy element. We describe the processing rules to
identity policy elements for multicast merged flows. Subsequently
we describe representations of user identities for Kerberos
Public Key based user authentication mechanisms. In summary,
describe the use of this identity information in an
setting

This memo corrects an RSVP POLICY_DATA P-Type codepoint
error and a field size definition error in ErrorValue in RFC 2752.

Yadav, et al. Standards Track [Page 1]

RFC 3182 Identity Representation for RSVP October 2001

1. Conventions used in this

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC 2119].

2.

RSVP [RFC 2205] is a resource reservation setup protocol designed
an integrated services Internet [RFC 1633]. RSVP is used by a
to request specific quality of service (QoS) from the network
particular application data streams or flows. RSVP is also used
routers to deliver QoS requests to all nodes along the path(s) of
flows and to establish and maintain state to provide the
service. RSVP requests will generally result in resources
reserved in each node along the data path. RSVP allows
users to obtain preferential access to network resources, under
control of an admission control mechanism. Permission to make
reservation is based both upon the availability of the
resources along the path of the data and upon satisfaction of
rules. Providing policy based admission control mechanism based
user identity or application is one of the prime requirements

In order to solve these problems and implement identity based
control it is required to identify the user and/or application
a RSVP request

This document proposes a mechanism for sending
information in the RSVP messages and enables authorization
based on policy and identity

We describe the authentication policy element (AUTH_DATA)
in the POLICY_DATA object. User process can generate an AUTH_
policy element and gives it to RSVP process (service) on
originating host. RSVP service inserts AUTH_DATA into the
message to identify the owner (user and/or application) making
request for network resources. Network elements, such as routers
authenticate request using the credentials presented in the AUTH_
and admit the RSVP message based on admission policy. After
request has been authenticated, first hop router installs the
state and forwards the new policy element returned by the
Decision Point (PDP) [POL-FRAME].

Yadav, et al. Standards Track [Page 2]

RFC 3182 Identity Representation for RSVP October 2001

3. Policy Element for Authentication

3.1 Policy Data Object

POLICY_DATA objects contain policy information and are carried
RSVP messages. A detail description of the format of POLICY_
object can be found in "RSVP Extensions for Policy Control" [POL
EXT].

3.2 Authentication Data Policy

In this section, we describe a policy element (PE)
authentication data (AUTH_DATA). AUTH_DATA policy element contains
list of authentication attributes

+-------------+-------------+-------------+-------------+
| Length | P-Type = Identity Type |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List //
+-------------------------------------------------------+

The length of the policy element (including the Length and P-Type
is in number of octets (MUST be a multiple of 4) and indicates
end of the authentication attribute list

P-Type (Identity Type
Type of identity information contained in this Policy
supplied as the Policy element type (P-type). The
Assigned Numbers Authority (IANA) acts as a registry for
element types for identity as described in the [POL-EXT].
Initially, the registry contains the following P-Types
identity

2 AUTH_USER Authentication scheme to identify

3 AUTH_APP Authentication scheme to

Authentication Attribute

Authentication attributes contain information specific
authentication method and type of AUTH_DATA. The policy
provides the mechanism for grouping a collection of
attributes

Yadav, et al. Standards Track [Page 3]

RFC 3182 Identity Representation for RSVP October 2001

3.3 Authentication

Authentication attributes MUST be encoded as a multiple of 4 octets
attributes that are not a multiple of 4 octets long MUST be padded
a 4-octet boundary

+--------+--------+--------+--------+
| Length | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+

The length field is two octets and indicates the actual length
the attribute (including the Length and A-Type fields) in
of octets. The length does not include any bytes padding to
value field to make the attribute multiple of 4 octets long

A-
Authentication attribute type (A-Type) field is one octet.
acts as a registry for A-Types as described in the section 8,
IANA Considerations. Initially, the registry contains
following A-Types

1 POLICY_LOCATOR Unique string for locating
admission policy (such as X.500
described in [RFC 1779]).

2 CREDENTIAL User credential such as
ticket, or digital certificate
Application credential such
application ID

3 DIGITAL_SIGNATURE Digital signature of
authentication data policy element

4 POLICY_ERROR_OBJECT Detailed information on
failures

Authentication attribute sub-type field is one octet. Value
SubType depends on A-type

Value
The value field contains the attribute specific information

Yadav, et al. Standards Track [Page 4]

RFC 3182 Identity Representation for RSVP October 2001

3.3.1 Policy

POLICY_LOCATOR is used to locate the admission policy for the user
application. Distinguished Name (DN) is unique for each User
application hence a DN is used as policy locator

+-------+-------+-------+-------+
| Length |A-Type |SubType
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------

Length of the attribute, which MUST be >= 4.

A-
POLICY_

Following sub types for POLICY_LOCATOR are defined. IANA acts
a registry for POLICY_LOCATOR sub types as described in
section 8, IANA Considerations. Initially, the registry
the following sub types for POLICY_LOCATOR

1 ASCII_DN OctetString contains the X.500 DN
described in the RFC 1779 as an
string

2 UNICODE_DN OctetString contains the X.500 DN
in the RFC 1779 as an UNICODE string

3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500
DN. The Kerberos session key or
certificate private key is used
encryption. For Kerberos encryption
format is the same as returned
gss_seal [RFC 1509].

4 UNICODE_DN_ENCRYPT OctetString contains the encrypted
X.500 DN. The Kerberos session key
digital certificate private key is used
encryption. For Kerberos encryption
format is the same as returned
gss_seal [RFC 1509].

The OctetString field contains the DN

Yadav, et al. Standards Track [Page 5]

RFC 3182 Identity Representation for RSVP October 2001

3.3.2

CREDENTIAL indicates the credential of the user or application to
authenticated. For Kerberos authentication method the
object contains the Kerberos session ticket. For public key
authentication this field contains a digital certificate

A summary of the CREDENTIAL attribute format is shown below.
fields are transmitted from left to right

+-------+-------+-------+-------+
| Length |A-Type |SubType
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------

Length of the attribute, which MUST be >= 4.

A-

IANA acts as a registry for CREDENTIAL sub types as described
the section 8, IANA Considerations. Initially, the
contains the following sub types for CREDENTIAL

1 ASCII_ID OctetString contains user or
identification in plain ASCII text string

2 UNICODE_ID OctetString contains user or
identification in plain UNICODE text string

3 KERBEROS_TKT OctetString contains Kerberos ticket

4 X509_V3_CERT OctetString contains X.509 V3
certificate [X.509].

5 PGP_CERT OctetString contains PGP digital certificate

The OctetString contains the user or application credential

Yadav, et al. Standards Track [Page 6]

RFC 3182 Identity Representation for RSVP October 2001

3.3.3 Digital

The DIGITAL_SIGNATURE attribute MUST be the last attribute in
attribute list and contains the digital signature of the AUTH_
policy element. The digital signature signs all data in
AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The
used to compute the digital signature depends on the
method specified by the CREDENTIAL SubType field

A summary of DIGITAL_SIGNATURE attribute format is described below

+-------+-------+-------+-------+
| Length |A-Type |SubType
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------

Length of the attribute, which MUST be >= 4.

A-
DIGITAL_

No sub types for DIGITAL_SIGNATURE are currently defined.
field MUST be set to 0.

OctetString contains the digital signature of the AUTH_DATA

3.3.4 Policy Error

This attribute is used to carry any specific policy control
generated by a node when processing/validating an Authentication
Policy Element. When a RSVP policy node (local policy decision
or remote PDP) encounters a request that fails policy control due
its Authentication Policy Element, it SHOULD add a POLICY_ERROR_
containing additional information about the reason the
occurred into the policy element. This will then cause
appropriate PATH_ERROR or RESV_ERROR message to be generated with
policy element and appropriate RSVP error code in the message,
is returned to the request's source

The AUTH_DATA policy element in the PATH or RSVP message SHOULD
contain the POLICY_ERROR_OBJECT attribute. These are only
into PATH_ERROR and RESV_ERROR messages when generated by
aware intermediate nodes

Yadav, et al. Standards Track [Page 7]

RFC 3182 Identity Representation for RSVP October 2001

+----------+----------+----------+----------+
| Length | A-Type | SubType |
+----------+----------+----------+----------+
| 0 (Reserved) | ErrorValue |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+

Length of the attribute, which MUST be >= 8.

A-
POLICY_ERROR_

No sub types for POLICY_ERROR_CODE are currently defined.
field MUST be set to 0.

A 16-bit bit code containing the reason that the policy
point failed to process the policy element. IANA acts as
registry for ErrorValues as described in section 8,
Considerations. Following values have been defined

1 ERROR_NO_MORE_INFO No information is available
2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials
not supported

3 INSUFFICIENT_PRIVILEGES The credentials do not
sufficient privilege

4 EXPIRED_CREDENTIAL The credential has expired

5 IDENTITY_CHANGED Identity has changed

The OctetString field contains information from the
decision point that MAY contain additional information about
policy failure. For example, it may include a human-
message in the ASCII text

4. Authentication Data

Authentication attributes are grouped in a policy element
represent the identity credentials

Yadav, et al. Standards Track [Page 8]

RFC 3182 Identity Representation for RSVP October 2001

4.1 Simple User

In simple user authentication method the user login ID (in
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A
of the simple user AUTH_DATA policy element is shown below

+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length |CREDENTIAL | ASCII_ID |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+

4.2 Kerberos User

Kerberos [RFC 1510] authentication uses a trusted third party (
Kerberos Distribution Center - KDC) to provide for authentication
the user to a network server. It is assumed that a KDC is
and both host and verifier of authentication information (router
PDP) implement Kerberos authentication

A summary of the Kerberos AUTH_DATA policy element is shown below

+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+

4.2.1. Operational Setting using Kerberos

An RSVP enabled host is configured to construct and insert AUTH_
policy element into RSVP messages that designate use of the
authentication method (KERBEROS_TKT). Upon RSVP
initialization, the user application contacts the KDC to obtain
Kerberos ticket for the next network node or its PDP. A router
generating a RSVP message contacts the KDC to obtain a

Yadav, et al. Standards Track [Page 9]

RFC 3182 Identity Representation for RSVP October 2001

ticket for the next hop network node or its PDP. The identity of
PDP or next network hop can be statically configured, learned
DHCP or maintained in a directory service. The Kerberos ticket
sent to the next network node (which may be a router or host) in
RSVP message. The KDC is used to validate the ticket
authentication the user sending RSVP message

4.3 Public Key based User

In public key based user authentication method digital certificate
encoded as user credentials. The digital signature is used
authenticating the user. A summary of the public key user AUTH_
policy element is shown below

+--------------+--------------+--------------+--------------+
| Length | P-type = AUTH_USER |
+--------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length | CREDENTIAL | SubType |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length |DIGITAL_SIGN. | 0 |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+

4.3.1. Operational Setting for public key based

Public key based authentication assumes following

- RSVP service requestors have a pair of keys (private key
public key).

- Private key is secured with the user

- Public keys are stored in digital certificates and a
party, certificate authority (CA) issues these
certificates

- The verifier (PDP or router) has the ability to verify
digital certificate

Yadav, et al. Standards Track [Page 10]

RFC 3182 Identity Representation for RSVP October 2001

RSVP requestor uses its private key to generate DIGITAL_SIGNATURE
User Authenticators (router, PDP) use the user's public key (
in the digital certificate) to verify the signature and
the user

4.4 Simple Application

The application authentication method encodes the
identification such as an executable filename as plain ASCII
UNICODE text

+----------------+--------------+--------------+--------------+
| Length | P-type = AUTH_APP |
+----------------+--------------+--------------+--------------+
| Length |POLICY_LOCATOR| SubType |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes
| the form of a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length | CREDENTIAL | ASCII_ID |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe
+----------------+--------------+--------------+--------------+

5.

+-----+ +-----+
| PDP |-------+ | PDP |
+-----+ | ................... +-----+
| : : |
+--------+ : Transit : +-------+
+----| Router |------: Network : -------| Router|--+
| +--------+ : : +-------+ |
| | :.................: | |
| | | |
Host A B C

Figure 1: User and Application Authentication using AUTH_DATA

Network nodes (hosts/routers) generate AUTH_DATA policy elements
contents of which are depend on the identity type used and
authentication method used. These generally contain
credentials (Kerberos ticket or digital certificate) and
locators (which can be the X.500 Distinguished Name of the user
network node or application names). Network nodes generate AUTH_
policy element containing the authentication identity when making
RSVP request or forwarding a RSVP message

Yadav, et al. Standards Track [Page 11]

RFC 3182 Identity Representation for RSVP October 2001

Network nodes generate user AUTH_DATA policy element using
following rules

1. For unicast sessions the user policy locator is copied from
previous hop. The authentication credentials are for the
network node identity

2. For multicast messages the user policy locator is for the
network node identity. The authentication credentials are for
current network node

Network nodes generate application AUTH_DATA policy element using
following rules

1. For unicast sessions the application AUTH_DATA is copied from
previous hop

2. For multicast messages the application AUTH_DATA is either
first application AUTH_DATA in the message or chosen by the PDP

6. Message Processing

6.1 Message Generation (RSVP Host

An RSVP message is created as specified in [RFC 2205] with
modifications

1. RSVP message MAY contain multiple AUTH_DATA policy elements

2. Authentication policy element (AUTH_DATA) is created and
IdentityType field is set to indicate the identity type in
policy element

- DN is inserted as POLICY_LOCATOR attribute

- Credentials such as Kerberos ticket or digital certificate
inserted as the CREDENTIAL attribute

3. POLICY_DATA object (containing the AUTH_DATA policy element)
inserted in the RSVP message in appropriate place. If
object is not computed for the RSVP message then an
object SHOULD be computed for this POLICY_DATA object,
described in the [POL_EXT], and SHOULD be inserted as a
Data option

Yadav, et al. Standards Track [Page 12]

RFC 3182 Identity Representation for RSVP October 2001

6.2 Message Reception (Router

RSVP message is processed as specified in [RFC 2205] with
modifications

1. If router is not policy aware then it SHOULD send the RSVP
to the PDP and wait for response. If the router is policy
then it ignores the policy data objects and continues
the RSVP message

2. Reject the message if the response from the PDP is negative

3. Continue processing the RSVP message

6.3 Authentication (Router/PDP

1. Retrieve the AUTH_DATA policy element. Check the PE type
and return an error if the identity type is not supported

2. Verify user

- Simple authentication: e.g., Get user ID and validate it,
get executable name and validate it

- Kerberos: Send the Kerberos ticket to the KDC to obtain
session key. Using the session key authenticate the user

- Public Key: Validate the certificate that it was issued by
trusted Certificate Authority (CA) and authenticate the user
application by verifying the digital signature

7. Error

If PDP fails to verify the AUTH_DATA policy element then it
return policy control failure (Error Code = 02) to the PEP.
error values are described in [RFC 2205] and [POL-EXT]. Also
SHOULD supply a policy data object containing an AUTH_DATA
Element with A-Type=POLICY_ERROR_CODE containing more details on
Policy Control failure (see section 3.3.4). The PEP will
this Policy Data object in the outgoing RSVP Error message

8. IANA

Following the policies outlined in [IANA-CONSIDERATIONS],
RSVP Policy Elements (P-type values) are assigned by IETF
action as described in [POL-EXT].

Yadav, et al. Standards Track [Page 13]

RFC 3182 Identity Representation for RSVP October 2001

P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP
assigned the value 3.

Following the policies outlined in [IANA-CONSIDERATIONS],
authentication attribute types (A-Type) in the range 0-127
allocated through an IETF Consensus action, A-Type values
128-255 are reserved for Private Use and are not assigned by IANA

A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL
assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the
3. A-Type POLICY_ERROR_OBJECT is assigned the value 4.

Following the policies outlined in [IANA-CONSIDERATIONS],
POLICY_LOCATOR SubType values in the range 0-127 are
through an IETF Consensus action, POLICY_LOCATOR SubType
between 128-255 are reserved for Private Use and are not assigned
IANA

POLICY_LOCATOR SubType ASCII_DN is assigned the value 1,
UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT
assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned
value 4.

Following the policies outlined in [IANA-CONSIDERATIONS],
SubType values in the range 0-127 are allocated through an
Consensus action, CREDENTIAL SubType values between 128-255
reserved for Private Use and are not assigned by IANA

CREDENTIAL SubType ASCII_ID is assigned the value 1,
UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is
the value 3, SubType X509_V3_CERT is assigned the value 4,
PGP_CERT is assigned the value 5.

Following the policies outlined in [IANA-CONSIDERATIONS],
in the range 0-32767 are allocated through an IETF Consensus action
ErrorValues between 32768-65535 are reserved for Private Use and
not assigned by IANA

ErrorValue ERROR_NO_MORE_INFO is assigned the value 1,
UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2,
INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_
is assigned the value 4, and IDENTITY_CHANGED is assigned the
5.

Yadav, et al. Standards Track [Page 14]

RFC 3182 Identity Representation for RSVP October 2001

9. Security

The purpose of this memo is to describe a mechanism to
RSVP requests based on user identity in a secure manner.
INTEGRITY object is used to protect the policy object containing
identity information from security (replay) attacks. Combining
AUTH_DATA policy element and the INTEGRITY object results in a
access control that enforces authentication based on both
identity of the user and the identity of the originating node

Simple authentication does not contain credential that can
securely authenticated and is inherently less secured

The Kerberos authentication mechanism is reasonably well secured

User authentication using a public key certificate is known
provide the strongest security

10.

We would like to thank Andrew Smith, Bob Lindell and many others
their valuable comments on this memo

11.

[ASCII] Coded Character Set -- 7-Bit American
Code for Information Interchange, ANSI X3.4-
1986.

[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines
Writing an IANA Considerations Section
RFCs", BCP 26, RFC 2434, October 1998.

[POL-EXT] Herzog, S., "RSVP Extensions for
Control", RFC 2750, January 2000.

[POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "
Framework for Policy-based Admission
RSVP", RFC 2753, January 2000.

[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos
Authentication Service (V5)", RFC 1510,
September 1993.

[RFC 1704] Haller, N. and R. Atkinson, "On
Authentication", RFC 1704, October 1994.

Yadav, et al. Standards Track [Page 15]

RFC 3182 Identity Representation for RSVP October 2001

[RFC 1779] Killie, S., "A String Representation
Distinguished Names", RFC 1779, March 1995.

[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S
and S. Jamin, "Resource ReSerVation
(RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997.

[RFC 2209] Braden, R. and L. Zhang, "Resource
Protocol (RSVP) - Version 1 Message
Rules", RFC 2209, September 1997.

[RFC 2119] Bradner, S., "Key words for use in RFCs
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.

[RFC 2751] Herzog, S., "Signaled Preemption
Policy Element", RFC 2751, January 2000.

[UNICODE] The Unicode Consortium, "The Unicode Standard
Version 2.0", Addison-Wesley, Reading, MA
1996.

[X.509] Housley, R., Ford, W., Polk, W. and D. Solo
"Internet X.509 Public Key
Certificate and CRL Profile", RFC 2459,
1999.

[X.509-ITU] ITU-T (formerly CCITT) Information technology -
Open Systems Interconnection - The Directory
Authentication Framework Recommendation X.509
ISO/IEC 9594-8

12. Authors'

Satyendra
Intel, JF3-206
2111 NE 25th
Hillsboro, OR 97124

EMail: Satyendra.Yadav@intel.

Yadav, et al. Standards Track [Page 16]

RFC 3182 Identity Representation for RSVP October 2001

Raj
Intel, JF3-206
2111 NE 25th
Hillsboro, OR 97124

EMail: Raj.Yavatkar@intel.

Ramesh

1 Microsoft
Redmond, WA 98054

EMail: rameshpa@microsoft.

Peter

1 Microsoft
Redmond, WA 98054

EMail: peterf@microsoft.

Tim

1 Microsoft
Redmond, WA 98054

EMail: timmoore@microsoft.

Shai
PolicyConsulting.
200 Clove Rd
New Rochelle, NY 10801

EMail: herzog@policyconsulting.

Rodney
Intel, BD
28 Crosby
Bedford, MA 01730

EMail: rodney.hess@intel.

Yadav, et al. Standards Track [Page 17]

RFC 3182 Identity Representation for RSVP October 2001

13. Full Copyright

Copyright (C) The Internet Society (2001). 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

Yadav, et al. Standards Track [Page 18]

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