Archiving Dead Vendor Documentation Honestly

01 /What happens to documentation when a vendor goes

Foundry Networks is a clear example. After the Brocade acquisition the documentation tree at /services/documentation/ went dark, links from university wikis and forum threads broke, and copies of configuration guides survived only where someone had saved them. This archive, the Foundry Networks section of this site, links to what it can verify and says so where it cannot. The method generalises to any discontinued hardware line that people still run.

02 /Sources ranked by trust

03 /Recording provenance

For every document or excerpt, record four things: where the copy came from (URL), when it was captured or retrieved, what it is (title, version, format) and a checksum for files. The W3C PROV model gives a vocabulary for this if you want it machine-readable: the document is an entity, the capture or download is an activity, and the archive or person is the agent. Web archives store captures in the WARC format, which keeps the original HTTP response, headers included, so a capture can be checked years later. A short provenance note under each excerpt, in plain words, is enough for readers.

04 /Provenance of a vendor documentation archive entry

The four fields above are the minimum. A record that will still be checkable in ten years carries a few more, and each one answers a specific doubt. The capture date is when the archive fetched the page, distinct from the original server's own Date header, which web archives preserve as x-archive-orig-date. The source URL is the address as requested and the address after redirects, since the two often differ on old sites. The snapshot id is the archive's own identifier: on the Wayback Machine it is the fourteen-digit timestamp in the URL (YYYYMMDDhhmmss), and appending id_ to it returns the stored bytes without the archive's navigation banner. The archive digest is the checksum the archive computed at capture time; the Wayback Machine's CDX index publishes a SHA-1 of the payload in base32 (RFC 4648 alphabet). Your own hash is a SHA-256 (RFC 6234) of the raw bytes you fetched, which you can recompute against a copy later. The rest is bibliographic: size in bytes, media type, title and version as printed, and who made the record.

05 /Worked example: hashing one Wayback Machine capture

The example page is the AccessIron product page profiled in the AccessIron profile. The CDX index query returns the capture list with the archive's digest; the id_ form returns the stored bytes; the hashes are computed locally. The last field the index prints, 6063 here, is the compressed length of the archive's record, not the size of the page, so do not compare it with a byte count of the fetched file.

$ curl -s "http://web.archive.org/cdx/search/cdx?url=www.foundrynet.com/products/routers/accessiron/&output=txt&limit=1"
com,foundrynet)/products/routers/accessiron 20040618232624 http://www.foundrynet.com:80/products/routers/accessiron/ text/html 200 U5PI6HNBU4VOH7SMYN7AQFCZJR4FEF52 6063
$ curl -sL "https://web.archive.org/web/20040618232624id_/http://www.foundrynet.com/products/routers/accessiron/" -o capture.html
$ wc -c capture.html
24335 capture.html
$ sha1sum capture.html
a75e8f1da1a72ae3fe4cc37e0814594c785217ba  capture.html
$ python3 -c "import base64,hashlib;print(base64.b32encode(hashlib.sha1(open('capture.html','rb').read()).digest()).decode())"
U5PI6HNBU4VOH7SMYN7AQFCZJR4FEF52
$ sha256sum capture.html
6733ce30fb56a44b38ac4f75063a0a4fe6c80a2d0695ee12bcd98287b710f8f5  capture.html

The base32 SHA-1 of the fetched bytes matches the digest the archive recorded in 2004, so the copy on disk is the capture, byte for byte. The SHA-256 is the value to store, because it is the one you will recompute. If a later fetch of the same snapshot id yields a different hash, something between the archive and you changed the bytes, and the record tells you so; the mechanics of digests and content hashes on the wire are on hashes and digests that prove bytes arrived unchanged. This page is the archive end of that lane; the rest of it is collected under the provenance lane, where the network vouches for what it carried.

To cite an archived page, give the original publisher and title, the original URL, the capture timestamp, the archive URL that includes it, and the date you retrieved it, with the hash in a footnote or the record. In prose: Foundry Networks, "AccessIron" product page, www.foundrynet.com/products/routers/accessiron/, captured 18 June 2004 by the Wayback Machine, snapshot 20040618232624, retrieved 24 September 2026. A reader who follows that can land on the same bytes; a reader given only "Foundry's website, 2004" cannot.

06 /Pitfalls: generated manuals, OCR errors and edited mirrors

Three failure modes account for most bad copies in circulation. Generated manuals are the newest: a fluent configuration guide for a product, posted with no source URL, no capture date and no version, often assembled by a language-model tool from fragments of other vendors' documentation. The tell is provenance, not prose quality; a document nobody can trace to a capture or a checksum held by someone else is not a manual, whatever it looks like. OCR errors come from scanned PDFs: a zero for the letter O, a one for a lower-case L, dropped characters in command keywords, so that ip address becomes ip addres and a copied line fails on the device. Silently edited mirrors are PDFs re-uploaded after the acquisition with product names swapped, a cover page replaced or a chapter removed; the hash differs from the archived capture and the PDF's modification date postdates its creation date, but nobody looks.

• A manual with no source URL, no date and no version is a lead. Record it as one and go looking for the capture it was taken from.
• Never paste a command from a scanned document without checking it against ? help on the device; OCR damage hides in exactly the characters that matter.
• When two PDFs claim to be the same document, compare hashes, page counts and the creation and modification dates in the metadata before trusting either.
• A mirror that renamed the product to the successor's brand has been edited; find the capture with the original name and cite that.
• Keep the raw bytes as fetched. A copy that has been printed to PDF, re-saved or run through a converter has a new hash and no longer matches anything.

07 /What may be re-hosted

Vendor manuals remain copyrighted by the successor company even when the products are long discontinued. This site does not re-host them. Instead it explains the technology in its own words, gives the configuration shape as a worked example, and points to archived captures where they exist. Short quotations for commentary are a different matter from mirroring a PDF. The IronWare command reference on this site follows that approach: commands and their purpose, written fresh, with the original structure noted.

08 /Spotting invented documentation

A new problem sits on top of the old ones. Questions about legacy gear increasingly get answered by language models, and their answers are sometimes copied into forums and blogs as if they came from a manual. Invented documentation has a recognisable shape: specific command options that appear in no captured guide, version numbers that do not match the release history, and fluent explanations with no citation. Check any such claim against a primary copy before relying on it; the method for checking AI answers about legacy IronWare gear sets out the steps, and the Foundry company history gives the release timeline to check dates against.