I strongly suggest that the group review the proposed (draft-draft)
requirements <attached> and see if they meet the goals of this group.
-e
On Monday, June 02, 2003 12:23 AM, Barry Shein
[SMTP:bzs(_at_)world(_dot_)std(_dot_)com] wrote:
On the other hand, spam has been around for almost 10 years, and has
certainly been a major concern at public sites since at least 1997,
almost seven years ago.
So, although a quick solution of some magnitude is almost mandatory
just to stop something major kicking over the entire chessboard (death
of the net and all that), let's not completely rule out so-called
long-term, slow adoption approaches with 5-10 year horizons or even
longer.
8<...>8
Anti Spam Research Group R. Brand
Internet-Draft Procinct Security Corporation
Expires: Mmmmmmm D, YYYY E. Williams
Information Brokers, Inc.
May 29, 2003
Anti Spam Research Group Requirements
draft-irtf-asrg-requirements-xx
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Mmmmmmm dd, yyyy.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights
Reserved.
Abstract
The purpose of the Anti Spam Research Group (ASRG) is to
investigate the [spam] problem (loosely defined as \x91non consent-
based communications\x92) as a large-scale network problem,
understand the problem and collectively propose and evaluate
solutions to the problem. This Internet-Draft describes the
high-level requirements for proposed methodologies for
addressing the problem, including the rationale for those
requirements where clarification is needed. Scenarios are used
to illustrate some requirements.
Internet-Draft Requirements May 29, 2003
Table of Contents
1. Introduction 4
1.1 Conventions Used In This Document 4
1.2 Reasons for the ASRG Proposal Requirements 4
1.3 Terminology 5
1.3.1 Anti-spam 5
1.3.2 Bulk E-mail 5
1.3.3 Caller 5
1.3.4 Callback 5
1.3.5 Challenge/Response System 5
1.3.6 Consent 5
1.3.7 Consent Based Communications 5
1.3.8 Commercial E-mail 6
1.3.9 Domain Name System (DNS) 6
1.3.10 E-mail 6
1.3.11 False Negative 6
1.3.12 False Positive 6
1.3.13 Legitimate Messaging 6
1.3.14 Message Content 6
1.3.15 Message Envelope Forgery 6
1.3.16 Message Envelope Protocol 6
1.3.17 Message Header 7
1.3.18 Message Header Forgery 7
1.3.19 Message Origination 7
1.3.20 Message Originator 7
1.3.21 Message Transfer Agent 7
1.3.22 Message Transfer System 7
1.3.23 Message User Agent 7
1.3.24 Message Store/Message Storage Agent 8
1.3.25 Non Consent Based Communication (spam) 8
1.3.26 Open Relay MTA 8
1.3.27 Opt-In 8
1.3.28 Opt-Out 8
1.3.29 Recipient/Receiver 8
1.3.30 Sender 8
1.3.31 Spammer 8
1.3.32 Relay MTA 8
1.3.33 Selective Relay MTA 9
1.3.34 Reverse DNS 9
1.3.35 Transport Protocol 9
1.3.36 Unsolicited Bulk E-Mail 9
1.3.37 Unsolicited Commercial E-Mail 9
1.4 Anti Spam Technical Framework 9
1.5 Organization of Requirements 10
2. Requirements 10
2.1 Use of existing RFCs 10
2.1.1 Rationale: 10
2.2 Inexpensive 10
2.2.1 Rational: 10
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 2]
Internet-Draft Requirements May 29, 2003
2.3 Ease of Use 11
2.3.1 Rationale: 11
2.4 Ease of Deployment 11
2.4.1 Rational: 11
2.5 Interoperable 11
2.5.1 Rational: 11
2.6 Highly Effective 12
2.6.1 Rationale: 12
2.7 Persistently Effective 12
2.7.1 Rational: 12
2.8 Doesn't Interfere With The Delivery Of Legitimate Mail 12
2.8.1 Rationale: 12
2.9 Single Solution 12
2.9.1 Rationale: 12
2.10 Technical Rather Than Legislative 13
2.10.1 Rationale: 13
2.11 Complexity 13
2.11.1 Rationale: 13
2.12 Implement ability 13
2.12.1 Rationale: 13
2.13 Other Platforms 14
2.13.1 Rationale: 14
2.14 Accountability and Anonymity 14
2.14.1 Rationale: 14
3. Security Considerations 14
Informative References 15
Authors' Addresses 15
Full Copyright Statement 16
Acknowledgements 16
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 3]
Internet-Draft Requirements May 29, 2003
1. Introduction
This is an unordered simple listing of possible criteria for
ASRG to evaluate anti-spam solutions.
The ASRG should solicit both additional criteria and also
argumentation/analysis as to which criteria are appropriate and
important and which are not.
1.1 Conventions Used In This Document
This is not an IETF standards track document[1]. As it is not
such a document the keywords MUST, MUST NOT, SHOULD, and MAY
are NOT as in [2], but rather:
o MUST: This word, or the terms "REQUIRED" or "SHALL", means
that the described behavior or characteristic is an absolute
requirement for a proposed ASRG specification.
o MUST NOT: This phrase, or the phrase "SHALL NOT", means that
the described behavior or characteristic is an absolute
prohibition of a proposed ASRG specification.
o SHOULD: This word, or the adjective "RECOMMENDED", means
that there may exist valid reasons in particular circumstances
for a proposed ASRG specification to ignore described behavior or
characteristics.
o MAY: This word, or the adjective "OPTIONAL", means that
described behavior or characteristics are truly optional for a
proposed ASRG specification. One proposed specification may
choose to include the described behavior or characteristic while
another proposed specification may omit the same behavior or
characteristic.
1.2 Reasons for the ASRG Proposal Requirements
The reasons for development this set of requirements for ASRG
proposals are derived from the ASRG charter. The charter
states:
"The purpose of the ASRG is to understand the problem
and collectively propose and evaluate solutions to the
problem. While some techniques focus on local text
classification approaches, many traditional and
evolving techniques include approaches that involve new
network architectures or changes to the existing
applications and protocols.
ASRG will investigate the spam problem as a large-scale
network problem. The ASRG will begin its work by
developing a taxonomy of the problem and the proposed
solutions. This taxonomy should involve casting the
spam problem into different perspectives, such as
examining the similarities between spam and denial-of-
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 4]
Internet-Draft Requirements May 29, 2003
service; spam and intrusion detection/prevention; and
spam and authentication, authorization, and accounting.
ASRG will consider the issues of deployment for
proposed solutions, emphasizing the investigation of
methods that have a realistic chance of wide-scale
deployment.
The work of the ASRG will also include investigating
techniques to evaluate the usefulness and cost of
proposed solutions. Usefulness is described by the
effectiveness, accuracy, and incentive structure of the
system. The cost of the system refers to the burden
imposed on users and operators of the communications
system. These costs include any changes to the normal
use of the system or actual changes in the monetary
costs of using the system. The group will investigate
evaluation infrastructures such as public trace data
archives and research tools to measure and analyze the
problem and the solutions.
ASRG will not pursue research into legal issues of
spam, other than the extent to which these issues
affect, support, or constrain the technology."
This scope provides the basis framework for the development and
evaluation of proposals. This document provides the core
requirements applied by the research group for evaluation of
ASRG proposals.
1.3 Terminology
In an effort to develop a common reference point for the
evaluation of proposals and solutions we have compiled the
following list of commonly used terms relating to anti-[spam]
technology and efforts. The terms are presented in the
sections that follow in alphabetical order. In addition some
specific applications/examples of techniques described are
presented in Appendix [TBD].
1.3.1 Anti-spam (Requires consensus definition - RCD)
1.3.2 Bulk E-mail (RCD)
1.3.3 Caller (RCD)
1.3.4 Callback (RCD)
1.3.5 Challenge/Response System (RCD)
1.3.6 Consent (RCD)
1.3.7 Consent Based Communications (RCD)
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 5]
Internet-Draft Requirements May 29, 2003
1.3.8 Commercial E-mail (RCD)
1.3.9 Domain Name System (DNS)
A system for associating character based names with
numerically based internet protocol addresses [3]. The DNS works
with in the framework of internetwork communications to provide
names (called domain names) to zones of authority. The DNS is a
facility for mapping user friendly names to transactional end
point identifiers (IP addresses). The DNS is heavily utilized by
messaging systems to determine end point identifiers for message
relays and message termination points[8]. A full definition of
the operation of the DNS is outside of the scope of this
document.
1.3.10 E-mail
The term commonly used to describe a system of messaging based
in a network of distributed systems and acted on by computer
software and human actors. E-mail is a method of communications
used in Internet for multiple purposes too numerous to list in
this definition.
1.3.11 False Negative
In the context of this paper, a false negative is as defined
in [7] and is determined after a message filter test. A False
Negative (FN) is where a "Message fails to match the test
criteria, but the criteria are not sufficiently strong."
1.3.12 False Positive
In the context of this paper, a false positive is as defined
in [7] and is determined after a message filter test. A False
Positive (FP) is where a "Message matches test criteria but the
criteria are too aggressive."
1.3.13 Legitimate Messaging (RCD)
1.3.14 Message Content
That part of a messaging transaction that contains data as
described by [4],[9]. Message content consists of
RFC2822/RFC822 compliant data.
1.3.15 Message Envelope Forgery (RCD)
1.3.16 Message Envelope Protocol
The protocol used during message transfer to insert message
content into the message transfer system. The primary envelope
protocol used in Internet is defined in [5]. The message
envelope protocol precedes the transfer of message content and
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 6]
Internet-Draft Requirements May 29, 2003
terminates message content transfer.
1.3.17 Message Header
That part of message content that precedes the message body
and/or dictates the methodology for parsing the message into
message body parts as defined in [4],[6].
1.3.18 Message Header Forgery (RCD)
1.3.19 Message Origination
The process of inserting an original or revised message into
the message transfer system by an MUA, a human actor or any
system in the network of systems that comprise the message
transfer system.
1.3.20 Message Originator
An actor, human or machine, that causes the insertion of an
original or revised message into the message transfer system.
1.3.21 Message Transfer Agent
A Message Transfer Agent (MTA) is a system within the Message
Transfer System that participates in message transport on the
behalf of Message Originators.
1.3.22 Message Transfer System
The definition of the Message Transfer System (MTS) is described
by the following and associates elements in the MTS as follows:
Message Transfer System
+---> MTA <-> MTA <-> MTA <----+
| | | |
| V V |
MUA <-> MS MS <-> MUA
The MTS also exhibits control points as described in [7]
for addressing [spam].
1.3.23 Message User Agent
A program or user interface that provides access for a human
actor to the MTS and/or messages stored in a message store. A
message user agent (MUA) provides the human friendly interface,
if needed, for sending and receiving message transactions.
It may also supply an user-level programming interface, for
programmatic access to user functionality. An MUA may
also provide capabilities for editing, deleting, filtering,
sorting and storing messages. MUA features vary across
platforms and implementations.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 7]
Internet-Draft Requirements May 29, 2003
1.3.24 Message Store/Message Storage Agent
A system that provides storage for messages, the system usually
is acting on behalf of a human actor, but this is not required.
An MUA may act on a local message store or may provide access
to a remote message storage system, or both. In the latter sense
the term message storage agent is typically used. The term
message store (MS) is usually, though not exclusively associated
with a system where messages are stored prior to retrieval by an MUA.
1.3.25 Non Consent Based Communication (spam) (RCD)
1.3.26 Open Relay MTA
An MTA which is configured to relay mail for local domains and
foreign domains not associated with the MTA, without restricting
access to the relay functions. In essence an Open Relay MTA
typically relays messages for known and unknown domains because
of improper configuration.
1.3.27 Opt-In (RCD)
1.3.28 Opt-Out (RCD)
1.3.29 Recipient/Receiver
A computer system, application or process that is the final,
terminating end of a messaging transmission sequence. A
receiver is engaged in the activity of receiving final
delivery of a message comprising an message envelope and
optional content. A receiver usually is acting on behalf of
a human actor, but this is not required.
1.3.30 Sender
A computer system, application or process that is the origin,
terminating end of a messaging transmission sequence. A sender
is engaged in the activity of initial posting of a message
comprising an message envelope and optional content. A sender
usually is acting on behalf of a human actor, but this is not
required. Sender may also be a message header field [4].
1.3.31 Spammer (RCD)
1.3.32 Relay MTA
An MTA configured to participate in a store-and-forward
sequence between a sender's MTA and a receiver's MTA. The
term Relay MTA is meant to apply to MTA systems that do not
transact with MUAs, but only with other MTAs.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 8]
Internet-Draft Requirements May 29, 2003
1.3.33 Selective Relay MTA
An MTA configured to recognize and participate in a
store-and-forward sequence between a sender's MTA and a
receiver's MTA but only for messages that are originated from
known domains[8]. A Selective Relay MTA is distinguished from
other Relay MTAs by performing authentication and/or
origination checks before relaying a message. The term
Selective Relay MTA may apply to MTA systems that transact
with MUAs, and with other MTAs.
1.3.34 Reverse DNS
Term used to describe the process of using the DNS to query for a
mapping from numeric end point identifier (IP address) to
character based user friendly name (domain name).
1.3.35 Message Transfer Protocol
For purposes of this document a Message Transfer Protocol
describes a communications protocol used to communicate
information between computer systems for the purpose of
performing the exchange of application message data. The
protocol may provide reliable or unreliable communications.
The Transfer Protocol is independent of message content,
although it may impose other communications constraints.
1.3.36 Unsolicited Bulk E-Mail (RCD)
1.3.37 Unsolicited Commercial E-Mail (RCD)
1.4 Anti Spam Technical Framework
This document assumes the technical framework for anti-[spam]
proposals using the terminology defined in Section 1.3, we
assume the MTS is the primary means for transferring messages
among senders and recipients. The MTS consists of at least two
MTAs, MUAs and MS systems. The MTS relies on the DNS to
locate network information about relevant systems. The MTS
uses various transport, envelope and message technologies that
are well known to [spammers] and MTS applications.
These are the only assumptions we make concerning approaches to
proposals that will be evaluated. Using that logic the
following should not matter:
o Whether MTA, MUA, the MTS or some MTS component, e.g. MS; is
the platform for the proposed solution.
o Whether the proposed solution is the specification of
protocol extensions or an entirely new protocol.
o Whether the proposed solution uses existing technologies or
leverages existing technology.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 9]
Internet-Draft Requirements May 29, 2003
1.5 Organization of Requirements
The requirements outlined in this document reflect the high
level aspects for operational deployment of a solution. For
each requirement we will state the requirement as clearly as
possible without attempting to dictate a specific idea. Then
the rationale for stating the requirement and its importance
will be given along with its relative usefulness to a proposal
or specification. Optionally, we will provide an operational
scenario describing how such a feature may be used in the
environment being considered. Scenario\x92s are only illustrative
of actions a feature might enable.
It is expected that proposals will at a minimum meet the
requirements laid out in this document. However, this document
should only be used generally as a single criteria among others
used to evaluate a proposal. The ASRG may use additional
metrics for evaluation of proposals of competing designs.
2. Requirements
2.1 Use of existing RFCs
ASRG proposals SHALL reference and use previously published
RFCs where possible.
2.1.1 Rationale:
The IETF has already completed a great deal of research and
work into the areas of authentication, identification,
authorization, messaging and messaging communications and other
related protocols. In order to facilitate the work of this
group and its search for a solution it is wise to consider
defined and accepted standards.
2.2 Inexpensive
The proposal MUST consider the computational and storage
expense for users and technologies within the MTS utilizing the
proposed approach.
2.2.1 Rational:
Any additional overhead imposed on systems in the operating
environment may influence the level of deployment of the
proposed approach. To enhance deployment opportunities it is
smart to consider the impact of the approach on computational
and human resources.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 10]
Internet-Draft Requirements May 29, 2003
2.3 Ease of Use
The approach SHALL consider the ease of use for message system
managers, senders and recipients in all messaging situations.
2.3.1 Rationale:
For successful adoption by the user community proposals must
provide support for typical and atypical messaging situations
involving two or more parties. Many different correspondent
scenarios exist in the MTS a proposal which limits the ease of
messaging in existing scenarios will limit adoption.
2.4 Ease of Deployment
The proposal SHOULD consider deployment on any basis and take
into account existing systems deployed and operating in the
MTS.
2.4.1 Rational:
Any solution to the problems with \x91spam\x92 should be easily
deployed to facilitate either incremental or wide-spread
adoption. Existing systems will likely continue to be used,
thus a solution that leverages existing technology or MTS \x91anti-
spam\x92 implementations will also speed introduction. A proposal
that relies on non-existent infrastructure or technology is not
likely to be deployed.
2.5 Interoperable
Proposals MUST be interoperable with existing MTS uses.
2.5.1 Rational:
In order to be widely deployed and functional in the existing
environment the proposal must consider interoperation with
legacy protocols and systems. The existing MTS environment
consists of web based messaging client, offline MUAs, MUAs that
support direct access to MS and delivery to MTA relays, etc.
Additionally, the platforms that manage messaging applications
are also heterogeneous, designers must consider the practicality
of operation using multiple operating systems and technologies.
Proposals must not be specific to a single operating system or
system platform.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 11]
Internet-Draft Requirements May 29, 2003
2.6 Highly Effective
The proposal MUST provide an effective solution and identify the
subset of [spam] it will be effective against with Assumptions.
2.6.1 Rationale:
Although proposals may differ in approach all proposals will be
evaluated using an appropriate application of the assumptions
presented and the solution set described. This will provide
a consistent basis and measures for evaluation of the
approach.
2.7 Persistently Effective
The proposal SHOULD provide more than a step in an environment
of escalating countermeasures.
2.7.1 Rational:
Authors should consider the status quo concerning the
development and deployment of stop-gap measures a failure.
Solutions or research into the problem should present a
threat analysis with the threat(s) being addressed, protection
goals, possible countermeasures and defenses against those
countermeasures over the longest period possible or that
provably work forever.
2.8 Doesn't Interfere With The Delivery Of Legitimate Mail
The proposal MUST consider, address and keep at a minimum
impacts on [legitimate] messaging traffic within the MTS.
2.8.1 Rationale:
Proposals must consider the reasons for successful widespread
deployment of the current MTS: low latency, high
deliverability, scalability, functionality for multiple content
types, etc. Authors should develop proposals that minimize
impact in these critical areas for [legitimate] MTS uses. Thus
an optimal proposal will impact only [spam] and not
[legitimate] messaging traffic.
2.9 Goal Oriented Solution
The proposal SHOULD provide a carefully drafted scope of its
goals and its effectiveness at addressing those goals. Systems
SHOULD consider how they interoperate with other [anti-spam] systems.
2.9.1 Rationale:
A single solution that will work for all people is the optimum
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 12]
Internet-Draft Requirements May 29, 2003
solution. However, designers should provide documentation that
carefully scopes out the goals and effectively addresses them.
Interoperation of [anti-spam] solutions may benefit the overall
solution. A solution that is optimal also impacts all of the
problems associated with [spam], such as [list of problem terms].
Approaches that impact a sub-domain of problems should be
designed to leverage that approach with other approaches to
broaden the overall solution.
2.10 Legislative and Policy Considerations
The proposal SHOULD consider how laws and policies affect, support
or constrain the technology.
2.10.1 Rationale:
A proposal should consider how legal and policy issues affect,
support, or constrain the technology. If a solution supports
or is supported by particular legislation, then this should be
explicitly stated. We encourage authors to understand the
relationship between the technology and the legislation and
effects of a solution on enforcement of legislation as it
relates to aiding in enforcement.
2.11 Complexity
The proposal SHOULD strive for simplicity versus complexity.
2.11.1 Rationale:
Any technical solution that meets the criteria described for
success should remain as simple as possible within the
constraints of the methodology. Regardless of the method used
to address the problems of [spam], the proposal should be
easily understood or described using simple terms. The less
complex the solution or a description of its functioning, the
more likely the adoption by a wide audience.
2.12 Implement ability
Proposals MUST represent a methodology or technology that it is
possible to implement.
2.12.1 Rationale:
While many theories for addressing and eradicating the problems
being addressed exist only a sub-set of the possible universe
of theories can be developed into a solution that can be
successfully implemented. In order to preserve the resources
for evaluation of proposals and limit discussion of non-
workable proposals, designers must present proposals where the
consideration of ease of implementation, perceived
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 13]
Internet-Draft Requirements May 29, 2003
implementation difficulties, existing implementations,
reference implementations, and/or interoperable implementations
have been addressed.
2.13 Other Platforms
Proposals MAY consider methodologies that are effective on
platforms and system alternatives to the traditional MTS.
2.13.1 Rationale:
Technologies are emerging and available as alternative
messaging environments to the traditional MTS. Designers may
consider including specific or general methodologies that will
interoperate with or integrate with these emerging and
alternative technologies. Methods that work with instant
messengers, receive-only alphanumeric pagers, two-way
alphanumeric pagers, and/or SMS/phone text messaging are some
of the technologies that are considered good candidates for
evaluation.
2.14 Accountability and Anonymity
Proposals MUST address issues of accountability and anonymity
of MTS users, specifically message senders.
2.14.1 Rationale:
One of the most pernicious issues involving [spam] are related
to accountability of the [spammers] who provide invalid or
simulated information in order to \x93game the system\x94 provided by
the current MTS. Designers MUST describe the issues of
accountability addressed by their proposal. Message
origination and message formatting forgery must be considered
in designs, an optimal design would allow tracing of messages
to the sending person, organization and/or system.
Additionally, there is just cause for preserving sender
anonymity and supporting the use of appropriate \x91anonymization\x92
services that currently exist. Designers must consider the
impact of accountability by a proposal on these systems and
address the issues related to preserving anonymity for
[legitimate] uses.
3. Security Considerations
This document does not address security matters. However,
security and privacy are important concerns that must be
considered while developing a solution which deals with public
and private correspondence. Security considerations should be
established by the ASRG but are not presently included.
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 14]
Internet-Draft Requirements May 29, 2003
Informative References
[1] Bradner, S., "The Internet Standards Process -- Revision
3", BCP9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
and RFC 1035, November 1987.
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
[5] Klensin, J. "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[7] Crocker, D. "Technical Considerations for Spam Control
Mechanisms", work in progress, Internet-Draft
draft-crocker-spam-techconsider-00.txt, April 2003.
[8] Partridge, C., "Mail Routing and the Domain System", STD
14, RFC 974, January 1986.
[9] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
Authors' Addresses
Rusell L. Brand
Procinct Security Corporation
870 Market Street, Suite 1105
San Francisco, CA 94102
US
EMail: Brand(_at_)responsible(_dot_)com
URI: http://www.procinct.com/
Eric D. Williams
Information Brokers, Inc.
1309 S Street, SE
Washington, DC 20020
US
EMail: eric(_at_)infobro(_dot_)com
URI: http://www.infobro.com/
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 15]
Internet-Draft Requirements May 29, 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgements
Funding for the RFC Editor function is currently provided by
the Internet Society.
The following individuals contributed substantially to this document
and should be recognized for their efforts. This document would not
exist without their help:
Dave Crocker John Kyme [william-at-elan.net]
Alan DeKok J C Lawrence
Phillip Hallam-Baker Steven F Siirila
Jason Hihn Brad Templeton
Paul Judge Jim Youll
Brand & Williams Expires: Mmmmmmm D, YYYY [Page 16]