Request for Comments: MN-UTIL-01
Category: Informational. Independent RFC style memo. Not an IETF document.
Author: Mark Nichols
Date: January 2026
Protocol Architects Are Not the Creators of the Internet.
Protocols enable interoperability.
The Web enables publishing.
Internet operation requires infrastructure activation.
An informational memo on the activation gap between protocol interoperability and utility grade operation.
Abstract
TCP/IP standardized interoperability and end to end transport semantics. The World Wide Web standardized publishing and retrieval. Neither TCP/IP nor the Web specifies, provisions, or enforces the path properties required for utility grade Internet operation at global scale.
This memo defines terminology to distinguish interoperability standards from utility grade operation and specifies operational requirements for “infrastructure activation”: provisioned transport, interconnection strategy, routing policy control, redundancy, locality, continuous monitoring, incident response, and enforceable service accountability. This memo proposes no protocol changes.
Networking protocols enabled internetworking. The Web enabled publishing and retrieval. Neither, by itself, created the Internet without codependency on other contributors and technology, which are so numerous they are uncountable and beyond scope for attribution.
The rule (IETF, not opinion)
IETF RFC 1122 states: “The Internet is a network of networks.”
RFC 1122 also makes the consequence explicit: each host is directly connected to some particular network, and its “connection to the Internet” is conceptual, meaning it exists because networks interconnect, not because a protocol was published.
What the rule forces you to admit: If the Internet is a network of networks, then:
The Internet is not “a protocol.”
The Internet is not “a paper.”
The Internet is not “a university lab output.”
The Internet exists only when independent networks are physically and operationally interconnected into a working fabric.
This is not philosophy. This is what the IETF wrote down as the architectural assumption for Internet hosts.
Figure 1. Three layer model. Protocols enable interoperability. The Web enables publishing. Utility grade Internet behavior requires infrastructure activation.
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. It is an RFC style informational memo published independently and is not an IETF document.
Copyright Notice
Copyright (c) 2026 Mark Nichols.
Table of Contents
-
Introduction
1.1 Category statement
1.2 Scope -
Conventions and requirement language
-
Terminology
-
Problem statement: interoperability without utility
4.1 Common failure modes -
What TCP/IP and routing do, and do not do
5.1 TCP transport semantics
5.2 IP and interdomain routing -
What the Web does, and does not do
-
Requirements for utility grade Internet operation
7.1 Transport provisioning
7.2 Interconnection capacity and strategy
7.3 Routing policy control
7.4 Redundancy and disaster recovery
7.5 Locality
7.6 Continuous operations
7.7 Accountability and enforceability -
Attribution clarification
-
Security considerations
-
IANA considerations
-
References
Appendix A. Evidence criteria for “Internet utility” claims
1. Introduction
Public headlines and institutional profiles frequently use “created the Internet” as shorthand for protocol authorship. Some extend the same shorthand to the Web (HTTP, HTML, URIs). This memo separates:
-
Interoperability standards, which define protocol semantics enabling heterogeneous systems and networks to exchange data.
-
Utility grade Internet operation, which is repeatable, measurable, and enforceable service behavior suitable for commerce and institutional dependence across borders.
1.1 Category statement
Designing protocols, or leading development of protocols or the Web software system, is not equivalent to creating utility grade Internet operation. A whole system creation claim requires whole system evidence. Protocol correctness and adoption do not imply utility grade operation.
Protocol authorship is often interpreted as whole system authorship in public narratives. This memo does not diminish protocol invention credit. It clarifies a different claim: creation of utility grade, enforceable global service behavior.
Misattribution is now appearing in educational materials, where simplified creator narratives are presented as literal technical history. For example, a recent school textbook presented a single person “created the Internet” claim as fact.
1.2 Scope
This memo defines terms and operational requirements for utility grade operation. It proposes no new protocols and does not rename existing terms.
2. Conventions and requirement language
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this memo are to be interpreted as described in RFC 2119 and RFC 8174.
3. Terminology
Interoperability: The ability of heterogeneous systems and networks to exchange data using shared protocol semantics.
Internet (internetwork): A network of networks in which packets can be forwarded between administrative domains.
Internet utility (utility grade Internet operation): A service environment in which end to end outcomes are sufficiently predictable and accountable to support commerce and institutional dependence across borders. Defining attributes include measurability, repeatability, enforceability, and operational accountability.
Corridor: The practical end to end path experienced by a flow, shaped by transport, interconnection, routing policy, and queue treatment.
Infrastructure activation: The work required to turn interoperable networking into a dependable utility, including provisioned transport, interconnection strategy, routing policy control, redundancy, locality, and continuous operations.
Activation gap: The difference between:
(a) standards compliant endpoint behavior, and
(b) corridor properties required for predictable long lived sessions and secure transactions across borders.
4. Problem statement: interoperability without utility
In an interoperable internetwork, reachability may exist while utility grade behavior does not. The activation gap exists when endpoints remain standards compliant but corridor properties fall outside the envelope required by applications and transactions.
4.1 Common failure modes
The following observable conditions can occur while protocols remain correct:
-
high RTT variance and multi second spikes
-
loss and jitter that collapse long lived sessions
-
congested interconnects and chokepoints
-
policy driven queue treatment and class of service degradation
-
middlebox or application time budgets expiring before recovery converges
-
unstable routing policy interactions under load or failure
These failures are utility failures, not protocol definition failures.
5. What TCP/IP and routing do, and do not do
5.1 TCP transport semantics
TCP provides end to end transport semantics between endpoints, including reliable delivery, ordering, flow control, congestion response, and session recovery state.
TCP does not and cannot guarantee corridor viability across independent networks. Specifically, TCP:
-
does not select paths and does not control interdomain routing policy
-
does not provision capacity or ensure headroom
-
does not require redundancy or diverse corridors to exist
-
does not enforce priority, scheduling, or QoS across domains
-
cannot prevent application or middlebox timeouts
-
does not provide network operations alarms by itself
5.2 IP and interdomain routing
IP provides addressing and forwarding semantics and a best effort abstraction for internetworking.
IP and interdomain routing protocols can exchange reachability and can support failover only when alternate topology exists and policy permits its use. Reachability is not equivalent to utility. Interconnect capacity and routing policy frequently dominate user outcomes.
6. What the Web does, and does not do
The Web defines a publishing and retrieval system: naming (URIs), retrieval (HTTP request and response), and documents with links (HTML) implemented in clients and servers.
The Web does not create corridor viability or utility grade delivery. It:
-
does not create transport capacity or corridor headroom
-
does not control interconnection capacity, routing policy, or queue treatment
-
does not ensure that secure sessions complete at global distance
-
does not provide operational accountability for performance
The Web can make “content exists” true. It cannot make “content arrives predictably at distance” true without an engineered corridor underneath.
7. Requirements for utility grade Internet operation
A deployment that claims utility grade Internet operation across borders MUST satisfy the requirements in this section for the scope of its claimed service.
7.1 Transport provisioning
The operator MUST provision transport with sufficient headroom to keep RTT variance, loss, and jitter within bounds required by intended sessions and transactions.
The operator SHOULD provision diverse corridors across meaningful failure domains (facility, carrier, geography).
7.2 Interconnection capacity and strategy
The operator MUST ensure POP level interconnection capacity consistent with intended service outcomes, including port capacity, cross connects, exchange strategy, and congestion avoidance at handoffs.
The operator MUST treat persistent interconnect congestion as a service failure requiring remediation.
7.3 Routing policy control
The operator MUST implement routing policy control using operator controlled equipment and AS level intent at backbone facing handoffs.
The operator MUST validate failover behavior under realistic failure conditions and policy constraints.
7.4 Redundancy and disaster recovery
The operator MUST implement redundancy across meaningful failure domains and MUST demonstrate that redundancy is usable under policy and operational constraints.
The operator SHOULD conduct regular failover and restoration drills.
7.5 Locality
The operator SHOULD implement locality via distributed hosting, caching, replication, or placement to reduce dependency on long haul corridors for common retrieval paths and transaction flows.
7.6 Continuous operations
The operator MUST implement continuous operations sufficient to detect, isolate, and remediate corridor failures and performance collapse, including monitoring, alerting, escalation, incident response, and change control.
7.7 Accountability and enforceability
The operator MUST define measurable obligations appropriate to the claimed service, including targets, reporting, accountability, and enforceable commitments such as SLAs and remedies.
8. Attribution clarification
It is technically accurate to credit protocol architects and standards bodies for interoperability. It is not technically accurate to credit interoperability standards alone for the emergence of a global commercial utility.
The Internet utility is an operational outcome produced by infrastructure activation and operations discipline at scale. Protocols are necessary for interoperability. They are not sufficient for utility grade global behavior.
9. Security considerations
This memo proposes no protocol changes. Predictable completion of secure sessions depends on corridor viability and on operational practices including monitoring, incident response, and accountable interconnection. Corridor instability and policy driven impairment SHOULD be treated as availability and security risks, not merely performance issues.
10. IANA considerations
None.
11. References
11.1 Normative References
RFC 2119. Key words for use in RFCs to indicate requirement levels.
RFC 8174. Ambiguity of uppercase vs lowercase in RFC 2119 key words.
11.2 Informative References
RFC 1122. Requirements for Internet Hosts. Communication Layers.
RFC 9293. Transmission Control Protocol (TCP).
RFC 4271. Border Gateway Protocol 4 (BGP-4).