Summary
- RFC 1087 was a 1989 IAB policy statement for a historically specific, U.S.-sponsored research Internet; it named unacceptable intentional conduct without specifying an enforcement protocol.
- The later Site Security Handbooks make the missing operating layer explicit: a site with owners must choose, communicate and implement its own acceptable-use policy, procedures and limits.
A strong sentence with a narrow kind of force
RFC 1087 is short enough that its tone can conceal its scope. The Internet Activities Board described an Internet assembled through U.S. Government, industry and academic resources, first for network research and then for a wider research community. It called that system a national facility, linked its usefulness to availability and accessibility, and warned that irresponsible use threatened continued service. In that setting, the document said that access and use were a privilege.
The statement then endorsed a five-part boundary. Intentional unauthorized access, disruption of intended use, waste of people, capacity or computer resources, destruction of information integrity, and compromise of users’ privacy were each characterized as unethical and unacceptable. Those categories mattered. They made a shared concern legible at a time when a connected research infrastructure had become valuable enough to be disrupted across institutional lines.
But a category is not a finding. “Unauthorized access” does not say which resource was owned by whom, which local rule was in force, what account or packet was involved, whether a person acted intentionally, or what evidence survived. “Disruption” does not measure an outage, identify its cause or select a remedy. A policy can frame why a question deserves attention while leaving the factual and operational work unresolved.
That is not a weakness peculiar to 1989. It is a basic boundary between a norm and a control. A control needs a scope, a responsible operator, a mechanism, an input and a decision rule. A finding needs evidence appropriate to the claimed event. An authorization needs a principal with power over the affected resource. RFC 1087 supplied none of those as a general Internet service. It supplied a policy statement.
The document did not pretend otherwise
The restraint is visible in the RFC’s final move. The IAB said it planned, with federal agencies and other interested parties, to identify and set up technical and procedural mechanisms that could make the Internet more resistant to disruption. The wording separates the concern from the mechanisms that might address it. It also recognizes a trade-off: security could be expensive and could inhibit the free flow of information that made the network valuable.
That sentence does not announce a universal enforcement plane. It does not define a sensor, a credential, a routing rule, a sanction, a tribunal or a jurisdiction. Nor does it say that every network has the same owner, risk appetite or legal environment. It says that mechanisms and procedures must still be found and set up in concert with relevant parties.
The distinction matters because policy language often acquires imaginary machinery after the fact. Once a rule sounds plainly right, readers can assume it has already selected the operator, validated the evidence and authorized the consequence. Those later steps may be necessary. They are not contained in the moral clarity of the first sentence.
From a shared warning to a site-owned policy
RFC 1244, published two years later as the Site Security Handbook, makes the next layer concrete. It describes itself as a guide and framework rather than a cookbook. A site must make decisions, gain agreement, communicate policy and implement it. Its definition of a site centres an organization with computers or network-related resources; the guide assumes that the site can set procedures with the concurrence and support of those who own its resources.
That is a material change in operational posture. An acceptable-use policy at a site can say which accounts, systems and traffic are in scope. It can state limits to access and authority, identify who may respond to an incident and explain what users are expected to do. The policy is still not a packet trace, but it at least connects a declared rule to a responsible resource holder and an implementation context.
RFC 2196 later repeats the logic in more explicit policy architecture. It calls itself informational, says a security policy should specify the mechanisms through which requirements can be met, and treats an appropriate-use policy as part of a wider local security policy. It asks its readers to account for laws and regulations, communicate expectations and review the policy. RFC 2504 then addresses users as a companion handbook, offering guidance without claiming to prove that a particular site has granted them permission.
Together the four documents show a useful historical sequence. A broad policy can name a risk. A site must translate that risk into rules for resources it actually governs. Operators must choose mechanisms and procedures. Evidence must still be gathered before anyone calls a particular event a breach. None of those steps can be skipped by repeating the first policy sentence more loudly.
What an acceptable-use statement cannot settle
A 1989 IAB statement does not determine today’s legal rule, a current provider’s terms, an organization’s asset ownership or a user’s authorization. It does not prove that a particular packet was malicious, that an outage was intentional, that a monitoring system was configured correctly or that an enforcement action was proportionate. It does not establish a current deployment, a contractual relationship, a jurisdiction or a factual incident.
The limitation protects both rigor and reversibility. If the concern is intrusion, a site can define its assets, collect relevant evidence, select accountable controls and revise them as risks change. If the concern is service continuity, an operator can identify the path, capacity or host state that actually matters. Treating a historic policy as if it already made those local decisions compresses different kinds of authority into one document and makes correction harder when the facts differ.
Sources and evidence boundary
The frozen source packet is RFCs 1087, 1244, 2196 and 2504. RFC 1087 provides the 1989 IAB statement, its research-infrastructure context, five enumerated categories and its reference to future technical and procedural mechanisms. RFCs 1244 and 2196 provide the site-owned policy, implementation, mechanisms and review comparison. RFC 2504 provides the user-facing companion context. None proves a present violation, identity, permission, legal result, jurisdiction, deployment, enforcement outcome or universal authority.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
