Protocol and Software Architects Are Not the Creators of the Internet
Spoiler Alert: A Spoke Did Not Create the Wheel. Air Does Not Create a Tire.
And the Internet, a Network of Networks, Requires Physical Infrastructure Activation and Operations.
Request for Comments: MN-UTIL-01
Category: Informational
Updates: None
Obsoletes: None
Status: Independent RFC-style memo. Not an IETF document.
Author: Mark Nichols
Date: January 2026
Internet-Draft source for “Protocol Architects Are Not the Creators of the Internet” (RFCXML v3)
Links
Topic page: https://marknichols.com/protocol-architects-are-not-the-creators-of-the-internet/
GitHub repo: https://github.com/marknichols1960/draft-mnichols-protocols-not-the-internet
Summary (non-normative)
Internet protocols enable interoperability.
The Web enables publishing and retrieval.
The Internet exists only when independent networks are physically and operationally interconnected into a working fabric.
Any claim of “creating the Internet” requires infrastructure activation across networks.
This memo defines the activation gap between protocol interoperability and utility-grade Internet operation.
Abstract
TCP/IP standardized interoperable end-to-end transport semantics. The World Wide Web standardized publishing and retrieval on top of internetworking. Neither TCP/IP nor the Web specifies, provisions, or enforces the corridor properties required for utility-grade Internet operation at global scale.
This memo defines terminology that distinguishes interoperability standards from utility-grade operation and specifies operational requirements for infrastructure activation, including provisioned transport, interconnection capacity and strategy, routing policy control, redundancy across failure domains, locality, continuous monitoring, incident response, and enforceable service accountability. This memo proposes no protocol changes.
The rule (IETF, not opinion)
IETF RFC 1122 states: “The Internet is a network of networks.”
RFC 1122 further states that each host is directly connected to some particular network, and its “connection to the Internet” is conceptual. The Internet exists because networks interconnect, not because a protocol was published.
What the rule forces you to admit (non-normative)
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. It is an architectural assumption stated in the host requirements RFCs.
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. This document is 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
11.1 Normative References
11.2 Informative 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 two different categories of contribution:
-
Interoperability standards define protocol semantics enabling heterogeneous systems and networks to exchange data.
-
Utility-grade Internet operation is repeatable, measurable, and enforceable service behavior suitable for commerce and institutional dependence across borders.
Protocol correctness and adoption do not imply utility-grade operation. A whole-system creation claim requires whole-system evidence.
1.1 Category Statement
Designing protocols, leading protocol development, or leading Web software development is not equivalent to creating utility-grade Internet operation. This memo does not diminish protocol invention credit. It clarifies a different claim: creation of utility-grade, enforceable global service behavior.
Public narratives often interpret protocol authorship as whole-system authorship. That interpretation is technically incorrect when “the Internet” is defined as a network of networks and treated as a utility outcome.
Misattribution now appears in educational materials, where simplified creator narratives are presented as literal technical history.
1.2 Scope
This memo defines terms and operational requirements for utility-grade operation and infrastructure activation. It proposes no new protocols, no protocol modifications, and no renaming of established Internet 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 provisioning, interconnection capacity, routing policy, and queue treatment across administrative domains.
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
-
application and middlebox timeouts expiring before recovery converges
-
unstable routing policy interactions under load or failure
These failures are utility failures, not protocol definition failures.