Protocols Are Not the Internet: The IETF Internet-Draft by Mark Nichols

Protocol Designers Are Not the Creators of the Internet: The IETF Internet-Draft draft-mnichols-protocols-not-the-internet-01 States the Distinction in the IETF's Own Words

Preamble: Mark Nichols posted revision 01 of the Internet-Draft draft-mnichols-protocols-not-the-internet to the IETF Datatracker on September 25, 2026, and the text below this record is the posted revision, section for section, with the IETF's own addresses for every format it serves.

0. The submission record states where the posted revision lives, what changed from the -00, and what the IETF's own checks said.

0.1 Mark Nichols posted draft-mnichols-protocols-not-the-internet-01, an individual submission to the IETF, on September 25, 2026, and the IETF Secretariat's posting notice of the same day recorded the name draft-mnichols-protocols-not-the-internet, the revision 01, the title Protocol Architects Are Not the Creators of the Internet, the date 2026-09-25, the group Individual Submission, and a length of 11 pages. The IETF Datatracker lists the revision as an Active Internet-Draft, individual, with its status page at https://datatracker.ietf.org/doc/draft-mnichols-protocols-not-the-internet/, and the revision expires on March 29, 2027, 185 days after posting, unless a further revision is posted before that date.

0.2 The IETF serves the posted revision in four forms, and each address below is the IETF's own: the plain text at https://www.ietf.org/archive/id/draft-mnichols-protocols-not-the-internet-01.txt, the HTML at https://www.ietf.org/archive/id/draft-mnichols-protocols-not-the-internet-01.html, the source XML at https://www.ietf.org/archive/id/draft-mnichols-protocols-not-the-internet-01.xml, and the Datatracker's htmlized rendering at https://datatracker.ietf.org/doc/html/draft-mnichols-protocols-not-the-internet. The IETF's own diff tool shows every change between revision 00 and revision 01 at https://author-tools.ietf.org/iddiff?url2=draft-mnichols-protocols-not-the-internet-01.

0.3 Revision 00 was posted on January 29, 2026 and expired on August 2, 2026, and it remains archived on the Datatracker at https://datatracker.ietf.org/doc/draft-mnichols-protocols-not-the-internet/00/. Revision 01 carries every sentence of revision 00's sections 1 through 10, and it adds three subsections to section 8: subsection 8.1, which states the IETF's own definition of the Internet from RFC 2026, The Internet Standards Process, Revision 3, of October 1996; subsection 8.2, which states the requirement levels of RFC 2026 and the grades that STD 1 gave IP and TCP in RFC 1200 of April 1991 and RFC 2200 of June 1997, and the retirement of STD 1 by RFC 7100 of December 2013; and subsection 8.3, which states what the ARPANET's Request for Quotations No. DAHC15 69 Q 0002 of July 29, 1968 required of the network contractor. Revision 01 also removes the duplicated Status of This Memo and Copyright Notice that revision 00 carried, because revision 00's source supplied its own copies of both and the IETF's processor added the required copies beneath them.

0.4 The IETF's submission tool validated revision 01 before posting it, and its idnits check, version 2.17.1, reported no errors, no flaws, no warnings, and no comments, with the boilerplate required by RFC 5378 and the IETF Trust found in order. The tool's idnits3 check, which the IETF states is not yet a required check, reported one item on revision 01's source: the rfc element declares an IETF submission stream while the Datatracker records no stream for the document, and that declaration will be removed in the next revision.

0.5 An Internet-Draft is a working document, and the Datatracker states above every individual draft that the draft is not endorsed by the IETF and has no formal standing in the IETF standards process. Mark Nichols posted this draft so that the distinction its section 8 draws, in the IETF's own words from RFC 2026, RFC 1200, RFC 2200, and RFC 7100, stands at an ietf.org address in the IETF's own document format, and the draft has been requested of no stream and reviewed by no editor as of September 25, 2026.

0.6 The text from the next heading to the Author's Address is the posted revision 01, section for section, with the IETF's rendering of its references, and it is reproduced here so that any reader of this site can cite the draft by its own section numbers without leaving the record.

0.7 The claims on this page are open to challenge on the same terms as every claim on marknichols.com. A challenger who holds that a claim on this page is wrong, or that the Internet is something other than the publicly joinable network of networks of the registry lineage defined at The Governing Definitions and Controlling Facts of marknichols.com, states the competing claim or definition in one sentence, names the document that carries it and the document's date, and sends both to mark@marknichols.com. A challenge submitted with its document is answered on this page, and a competing definition submitted with its document is added to this page as an exhibit with attribution to the person who submitted it; a challenge submitted without a document is an opinion and is heard as one. The distinction the site's definition rests on, that protocols enable interoperability and are not the Internet, is stated in the IETF's own words, RFC 2026 and STD 1, in the Internet-Draft draft-mnichols-protocols-not-the-internet-01, posted by Mark Nichols to the IETF Datatracker on September 25, 2026 at https://datatracker.ietf.org/doc/draft-mnichols-protocols-not-the-internet/ and stated on this site at Protocols Are Not the Internet: The IETF Internet-Draft by Mark Nichols, so a challenger may also address the definition in the venue that publishes the protocol standards themselves. Any person who holds expertise in telecommunications and a competing claim or definition is invited to bring both, in writing, with the document.

Network Working Group

Internet-Draft: draft-mnichols-protocols-not-the-internet-01

Intended status: Informational

Expires: 29 March 2027

M. Nichols

25 September 2026

Protocol Architects Are Not the Creators of the Internet

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 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 29 March 2027.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction

1.1. Category statement

1.2. Scope

1.3. Thesis

2. Conventions and requirement language

3. Terminology

4. Problem statement: interoperability without utility

4.1. Common failure modes

5. What TCP/IP and routing do, and do not do

5.1. TCP transport semantics

5.2. IP and interdomain routing

6. What the Web does, and does not do

7. 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

8. Attribution clarification

8.1. The IETF's own definition of the Internet

8.2. The IETF's own requirement levels never required TCP

8.3. Historical note: the 1968 ARPANET specification placed reliability and a delay bound in the network

9. Security considerations

10. IANA considerations

11. References

11.1. Normative References

11.2. Informative References

Author's Address

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:

(a) Interoperability standards, which define protocol semantics enabling heterogeneous systems and networks to exchange data.

(b) Utility grade Internet operation, which is repeatable, measurable, and enforceable service behavior suitable for commerce and institutional dependence across borders.

Figure 1: Three layer model. Protocols enable interoperability. The Web enables publishing. Utility grade Internet behavior requires infrastructure activation. The figure stacks three layers: Layer 3, Infrastructure activation, Utility grade Internet behavior; Layer 2, The Web, Publishing and retrieval; Layer 1, Protocols, Interoperability.

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 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

Protocols and the Web define semantics. The Internet is the deployed, interconnected, operated system those semantics run on.

Protocols are necessary. They are not the Internet.

1.3. Thesis

Protocols enable interoperability. The Web enables publishing and retrieval. Internet operation requires infrastructure activation.

Protocols are necessary. They are not the Internet.

2. Conventions and requirement language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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:

(a) high RTT variance and multi second spikes

(b) loss and jitter that collapse long lived sessions

(d) policy driven queue treatment and class of service degradation

(e) middlebox or application time budgets expiring before recovery converges

(f) 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:

(a) does not select paths and does not control interdomain routing policy

(b) does not provision capacity or ensure headroom

(d) does not enforce priority, scheduling, or QoS across domains

(e) cannot prevent application or middlebox timeouts

(f) 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:

(a) does not create transport capacity or corridor headroom

(b) does not control interconnection capacity, routing policy, or queue treatment

(d) 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 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 behavior.

8.1. The IETF's own definition of the Internet

The IETF's own process document states the distinction this memo draws. RFC 2026, The Internet Standards Process, Revision 3 [RFC2026], published in October 1996 as BCP 9 with Scott O. Bradner of Harvard University as its author, defines the Internet in Section 1.1 as a loosely organized international collaboration of autonomous, interconnected networks, and states that the Internet supports host-to-host communication through "voluntary adherence to open protocols and procedures defined by Internet Standards." Section 1.1 further states that many isolated interconnected networks use the Internet Standards without being connected to the global Internet, and that the Internet Standards Process covers protocols, procedures, and conventions used in or by the Internet whether or not they are part of the TCP/IP protocol suite. Section 5 of RFC 2026 states that the Internet is composed of networks operated by a great variety of organizations with diverse goals and rules. Under the IETF's own definition, therefore, the Internet is a collaboration of networks, adherence to the protocols is voluntary, and a network that runs the Internet Standards is not thereby connected to the Internet. Each of those three statements is the IETF's own, and each is consistent with the category statement in Section 1.1 of this memo: protocol authorship is not creation of the interconnected, operated system.

8.2. The IETF's own requirement levels never required TCP

RFC 2026, Section 3.3 [RFC2026], defines the requirement levels applied to Internet Standards: Required means implementation is required for minimal conformance by Internet systems using the TCP/IP Protocol Suite, with IP and ICMP as the section's own example; Recommended means implementation is recommended but not required; and Elective means the applicability statement creates no explicit necessity to implement the specification. The IETF's standards registry applied those levels. STD 1 in its April 1991 edition, RFC 1200 [RFC1200], graded IP Required and TCP Recommended, and STD 1 in its June 1997 edition, RFC 2200 [RFC2200], carried the same two grades unchanged. The Required grade binds the conformance of a system that has elected to implement the suite; no Internet Standard requires a network to adopt the suite, and the registry never graded TCP Required even inside the suite's own conformance vocabulary. The IETF retired STD 1 itself by RFC 7100 [RFC7100] in December 2013, which obsoleted RFC 5000 and moved STD 1 to Historic status. The statement "the Internet requires TCP/IP" therefore appears in no IETF instrument: the IETF's definition names networks, the IETF's adherence is voluntary, and the IETF's own grade for TCP was Recommended.

8.3. Historical note: the 1968 ARPANET specification placed reliability and a delay bound in the network

The requirements of Section 7 of this memo have a documented ancestor in the earliest specification of the ARPANET. Request for Quotations No. DAHC15 69 Q 0002 [RFQ1968], issued July 29, 1968 by the Defense Supply Service-Washington of the Department of the Army for the Advanced Research Projects Agency under ARPA Order No. 1260, solicited the Interface Message Processors for the ARPA computer network and specified nineteen nodes on 50 kilobit per second leased common-carrier lines. Its Statement of Work required the network contractor to provide fault detection and recovery to guarantee virtually error-free transmission, through acknowledgment and retransmission performed by the Interface Message Processors inside the network; it made error checking, fault detection, fault recovery, line switching, and carrier quality assessment the sole responsibility of the network contractor; and it required an average message delay under one half second for a fully loaded network, ranking message delay first among the network's performance criteria, ahead of reliability and capacity. Provisioned transport, a delay bound, reliability inside the network, and a single accountable operator are the properties Section 7 of this memo requires for utility grade operation, and the owner of the ARPANET specified all four in 1968, twelve years before RFC 761 [RFC0761] of January 1980 specified TCP on the assumption of a potentially unreliable datagram service beneath it. The activation gap defined in Section 3 of this memo therefore did not originate with internetworking; it originated when the reliability and delay obligations that the 1968 specification placed on the network operator were reassigned to the end hosts.

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

11.2. Informative References

[RFC0761] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, DOI 10.17487/RFC761, January 1980, https://www.rfc-editor.org/info/rfc761.

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, https://www.rfc-editor.org/info/rfc1122.

[RFC1200] DARPA and IAB, "IAB official protocol standards", RFC 1200, DOI 10.17487/RFC1200, April 1991, https://www.rfc-editor.org/info/rfc1200.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, https://www.rfc-editor.org/info/rfc2026.

[RFC2200] Postel, J., "Internet Official Protocol Standards", RFC 2200, DOI 10.17487/RFC2200, June 1997, https://www.rfc-editor.org/info/rfc2200.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271.

[RFC7100] Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, DOI 10.17487/RFC7100, December 2013, https://www.rfc-editor.org/info/rfc7100.

[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, https://www.rfc-editor.org/info/rfc9293.

[RFQ1968] Defense Supply Service-Washington, Department of the Army, for the Advanced Research Projects Agency, "Request for Quotations No. DAHC15 69 Q 0002, Interface Message Processors for the ARPA Computer Network", ARPA Order No. 1260, 29 July 1968, http://historyofcomputercommunications.info/assets/pdf/arpanet-rfq.pdf.

Author's Address

Mark Nichols

Email: mark@marknichols.com