Ways to Define User Expectations
RFC 1746
|
Document |
Type |
|
RFC - Informational
(December 1994; No errata)
|
|
Authors |
|
Bill Manning
,
Don Perkins
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 1746 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group B. Manning
Request for Comments: 1746 ISI
Category: Informational D. Perkins
Houston ISD
December 1994
Ways to Define User Expectations
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This paper covers basic fundamentals that must be understood when one
defines, interprets, or implements methods to control user
expectations on or over the Internet.
1. Background
User agreements are a form of acceptable use policy (AUP) are an
implicit part of internetworking since they place parameters on user
expectation. They define the desired and expected behaviour of those
who participate. Everyone has one, whether published or not. This
applies to networks that provide transit paths for other networks as
well as end sites and the individual users that use systems. A
better understanding of an AUP, and how to formulate one seems to be
increasingly important as the global net encompases new environments
as varied as K12 schools and real-time systems. AUP's are used to
determine pricing, customer base, type and quality of service
metrics, and a host of other provider services.
2. Components of an Agreement
In defining your particular agreement there are three areas that must
be addressed. They are where you get service from, who your peers
are, and whom you provide service to. A good understanding of these
concepts will make or break the policies you formulate.
2.1 Where you get service from
Each entity gets its service from one or more other providers,
either a level three service, such as IP transit, or a level two
service, such as circuits. The provider of such services usually has
an policy in the form of an agreement or contract specifying terms
Manning & Perkins [Page 1]
RFC 1746 Ways to Define User Expectations December 1994
and conditions of use. This forms the basis for the type of service
offerings that you as an entity can provide. If you get service from
several providers, all of them need to be considered in the
formation of policy.
2.2 Who your peers are
Are your policies consistent with those offered by your peers? In
many cases, the formation of policy will define who your peers are.
It is important to clearly identify which areas you intend to reach
and the community you wish to be a contributing, productive part of.
Once this is clear, formulate polices along those lines.
2.3 Who you provide service to
It is required that you inform those who use your services just what
your policies are. Without this information, it will be almost
impossible for them to distinguish what to expect from your service
offering. Without a clear policy it is possible that litigation may
ensue. It is important to reflect community standards in the creation
of policy.
3. Some Issues to consider
IP provided services can be complex. They comprise both information
and communication. In the formulation of policy it is critical that
the policy provide for security and access to information and
communication while ensuring that the resource use does not
overburden the system's capabilities. These conflicting demands must
be analyzed and a synthesis arrived at. This hints a fourth
component of an AUP, that it has a method to extract compliance.
This is so site specific that further analysis will not be attempted
here.
Some items that should be considered in the formation of policy are:
- privacy - morals & ethics
- freedom of expression - legal constraints
- safety - harassment
- plagiarism - resource utilization
- indemnification - targeted areas of interest
- expected behaviours - remedies and recourse
This should not be considered as an exhaustive list but as pointers
for those types of things to be considered when policy is formed.
Manning & Perkins [Page 2]
RFC 1746 Ways to Define User Expectations December 1994
4. Security Considerations
Security and Liability issues are not discussed in this memo.
5. Summary
User Agreements are here to stay. As the Interconnected mesh of
networks grows, the choices presented to end-users mandate that
provider/user expectations are clearly presented. Use of these
guidelines will help create a clearer, better defined environment for
Show full document text