



Network Working Group                                         M. Nichols
Internet-Draft                                              January 2026
Intended status: Informational                                          
Expires: 2 August 2026


        Protocol Architects Are Not the Creators of the Internet
              draft-mnichols-protocols-not-the-internet-00

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.

   Figure 1.  Three layer model.  Protocols enable interoperability.
   The Web enables publishing.  Utility grade Internet behavior requires
   infrastructure activation.

Thesis

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

   Protocols are necessary.  They are not the Internet.

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.






Nichols                   Expires 2 August 2026                 [Page 1]

Internet-Draft                 MN-UTIL-01                   January 2026


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 5 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Category statement  . . . . . . . . . . . . . . . . . . .   3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and requirement language  . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Problem statement: interoperability without utility . . . . .   4
     4.1.  Common failure modes  . . . . . . . . . . . . . . . . . .   4
   5.  What TCP/IP and routing do, and do not do . . . . . . . . . .   5
     5.1.  TCP transport semantics . . . . . . . . . . . . . . . . .   5
     5.2.  IP and interdomain routing  . . . . . . . . . . . . . . .   5
   6.  What the Web does, and does not do  . . . . . . . . . . . . .   6
   7.  Requirements for utility grade Internet operation . . . . . .   6
     7.1.  Transport provisioning  . . . . . . . . . . . . . . . . .   6
     7.2.  Interconnection capacity and strategy . . . . . . . . . .   6
     7.3.  Routing policy control  . . . . . . . . . . . . . . . . .   7
     7.4.  Redundancy and disaster recovery  . . . . . . . . . . . .   7
     7.5.  Locality  . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.6.  Continuous operations . . . . . . . . . . . . . . . . . .   7



Nichols                   Expires 2 August 2026                 [Page 2]

Internet-Draft                 MN-UTIL-01                   January 2026


     7.7.  Accountability and enforceability . . . . . . . . . . . .   7
   8.  Attribution clarification . . . . . . . . . . . . . . . . . .   7
   9.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   10. IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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





Nichols                   Expires 2 August 2026                 [Page 3]

Internet-Draft                 MN-UTIL-01                   January 2026


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




Nichols                   Expires 2 August 2026                 [Page 4]

Internet-Draft                 MN-UTIL-01                   January 2026


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



Nichols                   Expires 2 August 2026                 [Page 5]

Internet-Draft                 MN-UTIL-01                   January 2026


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.





Nichols                   Expires 2 August 2026                 [Page 6]

Internet-Draft                 MN-UTIL-01                   January 2026


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.





Nichols                   Expires 2 August 2026                 [Page 7]

Internet-Draft                 MN-UTIL-01                   January 2026


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

Author's Address

   Mark Nichols
   Email: mark@marknichols.com


















Nichols                   Expires 2 August 2026                 [Page 8]
