Summary

  • RFC 3167 did not revise the routing mechanism in RFC 1745. It recorded a request to move that 1994 standards-track document to Historic, citing non-deployment on the public Internet and implementation complexity.
  • The original RFC 1745 page still carries its publication-time standards-track notice, while the RFC Editor’s current information page labels it Historic. Those are different snapshots, not necessarily a contradiction.

The discrepancy sits in plain sight. Open RFC 1745 and its first page says it “specifies an Internet standards track protocol.” Open the RFC Editor’s information record today and the classification above the archived text is “Historic.” The title, date and technical text have not become a new document; the status attached to the record has moved on.

RFC 3167 is a compact clue to why. Published in August 2001 as an Informational RFC, it is titled “Request to Move RFC 1745 to Historic Status.” David Meyer and John Scudder wrote that a review of standards related to BGP had surfaced the BGP/IDRP–OSPF interaction described by RFC 1745. They said it had never been deployed in the public Internet and would require significant implementation complexity. The proposed response was reclassification.

That wording matters. RFC 3167 is a request, and its own memo status says it does not specify an Internet standard. It is evidence that two engineers publicly made a case for changing a document’s standing. It is not, by itself, the IESG’s decision notice, a dated audit of every network, or a record of how the status update was completed. The current RFC Editor catalog independently shows the present result: RFC 1745 is labeled Historic. The available artifacts establish the request and today’s label, but do not justify inventing the missing procedural link between them.

There is also a time-layer trap. RFC 1745 was issued in December 1994 with boilerplate describing its status then. That front matter belongs to the artifact as published. A later status is catalog metadata about the document now. The first page need not be silently rewritten for the record to change; indeed, preserving the historical page helps readers see what was asserted at issuance. A reader who treats old boilerplate as a live registry field will mistake the archive for a current dashboard.

RFC 2026, the 1996 Internet Standards Process, supplies vocabulary for the distinction. It calls Historic an off-track maturity level for a specification superseded by a newer one or otherwise considered obsolete. For retirement of a standards-track specification, it describes an IESG-approved status change, Last Call and notification procedures, and allows a request to come from a working group, an Area Director or another interested party. This tells us how the process was framed in that edition. It does not show which exact procedural event changed RFC 1745’s status, or when.

Nor does “Historic” mean the technical paper has been erased or that no equipment anywhere can still implement it. The RFC Editor continues to serve RFC 1745, including its technical description. Historic is a classification of standards standing, not a universal inventory of deployed code. Likewise, RFC 3167’s sentence about non-deployment is the authors’ stated basis for a proposal; it is not a census methodology or a permanent claim that no private or experimental use ever occurred.

The record is useful precisely because it keeps these categories close together. A standards-track publication made a technical specification available. Years later, a review identified a mismatch between that standing and reported practice, and a request proposed a new classification. Today’s information page presents the Historic label, while the original artifact retains its earlier wording. Publication, operational use, a status-change request, a decision, and the current index are related events—but they are not interchangeable evidence.

RFC 6410 later changed the standards-track ladder from three maturity levels to two and removed an annual review requirement. That later reform is not the mechanism behind RFC 1745’s reclassification; it is a reminder that status vocabularies themselves have histories. A label must be read against the process and date that produced it. The safe reading of this small documentary trail is therefore narrower, and stronger: RFC 3167 records an argument about non-use; the live catalog records RFC 1745’s Historic status; neither record should be made to claim more than it says.

Sources: RFC 3167, Request to Move RFC 1745 to Historic Status; RFC 3167 in the IETF Datatracker; RFC 1745 original text; RFC 1745 current RFC Editor record; RFC 1745 in the IETF Datatracker; RFC 2026, The Internet Standards Process; RFC 2026 in the IETF Datatracker; RFC 6410, Reducing the Standards Track to Two Maturity Levels; RFC 6410 current record; RFC Editor RFC-series guide.