Summary

  • On its about page, Seattle Internet Exchange states that participants have no requirements other than following "the rules of the exchange", that there are no peering requirements, and that its route servers are optional.
  • On its participants page, the exchange publishes the member table in five machine-readable formats and states that "some data" comes from PeeringDB and is updated hourly, while asking participants to keep that external record current.

A prospective participant's first question is narrow and practical. If I connect and announce my address blocks through the exchange's shared router, what stands between my announcement and everyone else's? The answer to that question is a policy before it is a device. It decides which blocks are accepted from whom, which registry records are consulted when a block is claimed, whether an announcement that fails a cryptographic origin check is dropped, logged, or passed along, and whether any limit is placed on how many blocks one member may announce.

That policy is what a counterparty wants when it asks an exchange to describe itself, because it is the part that changes outcomes. Size statistics describe the consequences of past decisions about who joined. Filtering policy describes what will happen to the next announcement.

The two pages read for this article do not describe that policy. What they do, and do consistently, is separate two jobs that are usually discussed as one. The first job is deciding who may participate and on what terms, and the about page disposes of it in a single sentence that hands the question to a document. The second job is publishing who is present, and the participants page performs it in unusual depth: five serialisations of the same table, one of them refreshed hourly from a database the exchange does not own.

That separation is the finding. It is not a scandal and not a gap in competence. It is a deliberate allocation of publishing effort, and it has a cost that falls precisely on the reader who arrives with the question in the first paragraph.

Three sentences that stand in for a conditions list

Quoted as retrieved on 21 October 2026 from the exchange's about page:

"There are no requirements of participants, other than they follow the rules of the exchange."

"There are no peering requirements, although peering with other members is encouraged and is basically the point of connecting to the exchange."

"We offer optional route servers."

Read as an interface rather than as promotion, each sentence removes one thing a prospective participant might reasonably have expected to be obligatory.

The first removes the list. A reader who wants conditions is told that conditions exist somewhere else, under a name — the rules of the exchange — that the sentence does not define and the page does not reproduce. That is a normal drafting habit in institutions, and it is also a real transfer of work: the sentence that could have told a member what it is agreeing to instead tells it where to look.

The second removes the obligation to peer while describing peering as the point of connecting. This is not a contradiction so much as a stance: the exchange declines to require what it recommends. For a member, the difference matters operationally. A requirement would need enforcement, a definition of what counts as peering, and a way to handle members who peer with nobody. A recommendation needs none of that, and it leaves the choice where the member's own commercial judgement sits.

The third is the only sentence written in the operator's first person plural, and it is a product description rather than a condition. It does not say the shared router is the exchange's principal service, and it does not say what the router does with an announcement beyond forwarding it. It says the service is available to those who want it.

Taken together, the three sentences describe an exchange that governs admission through a document, leaves behaviour on the fabric to the members, and offers a convenience on top. That is a coherent posture. It is also a posture that places every technically consequential question one step outside the page a stranger will actually read.

Five ways to fetch one table

The participants page says, in a single line quoted as retrieved on 21 October 2026 from the exchange's participants page:

"This table is also available in these formats: [ CSV | Euro-IX JSON | PCH | SIX JSON | TSV ]"

Five serialisations of one register is not five copies of one decision. It is a statement about who the operator expects to read it.

A comma-separated file is for a person with a spreadsheet, and it is the format that survives contact with someone who does not write code. Tab-separated values does the same job for the shell, where a pipeline can cut a column without a parser. The two JSON entries are where the interesting distinction sits: one is associated with Euro-IX, an association of internet exchanges that maintains a shared vocabulary for exchanging participant data; the other is described as the operator's own. The fifth points to Packet Clearing House, an organisation that publishes internet exchange and routing data.

The consequence is that the same rows can be consumed by four different classes of reader: a human doing ad hoc analysis, a member or researcher comparing exchanges through a shared schema, a global aggregator assembling a picture across many exchanges, and whatever tools the operator runs against its own dialect. None of those readers is required to use any particular one, and the page conditions nothing on the choice.

What the line does not provide is a field list, a version number, or a statement that the five carry the same columns. A reader who needs to know whether the Euro-IX rendering of a row matches the rendered table has to fetch both and compare. That is a small piece of work and an easy one to skip, and skipping it is how two consumers of the same register end up disagreeing about a member's presence.

'Some data' and the two clocks

Two sentences on the same page do more analytical work than any statistic the exchange could have published, quoted as retrieved on 21 October 2026 from the participants page:

"Some data is from PeeringDB.com and is updated hourly."

"Please keep your record there current."

The qualifier is the most informative word in the pair. Some data, not all of it. The register is composite, and it says so: one part arrives from PeeringDB, the volunteer-maintained public database in which networks describe themselves, their facilities and their peering arrangements; the other part comes from somewhere the sentence does not name, which can only be the operator's own records of who is connected to it.

The refresh rate, one hour, belongs to the mirrored part. It is a statement about how often the copy runs, not about how often the underlying facts change. This is the point that a reader in a hurry will get wrong, because a table described as updated hourly reads as current in every cell. It is not. A member that changed its network months ago and never touched its PeeringDB entry will appear in the register with whatever it wrote then, and the row will look exactly as fresh as one edited this morning.

The second sentence then moves the maintenance obligation. The operator does not instruct participants to keep the exchange's record current. It asks them to keep the third-party record current, because that record is what the exchange copies. Responsibility is divided three ways: the participant maintains the source row, PeeringDB holds it, and SIX assembles, mirrors and republishes it on a schedule the participant does not control.

For anyone using the register as evidence, the practical rule follows directly. The table is a claim of presence, and a mirror of a self-description. It establishes that a network is associated with the exchange. It does not establish what that network does, what it announces, or how it is connected, because nothing in the mechanism verifies the content of the row against the network's actual routing.

Where obligation is written

The phrase the about page uses — the rules of the exchange — is a deferral, and deferrals are ordinary in shared infrastructure. Constitutional documents are referenced by name all the time; a page that restated the terms in full would drift from the operative version and create its own authority problem.

What makes this deferral worth reporting is which page carries it. The about page is the one document a prospective participant reads before contacting anyone. Where an exchange writes its conditions onto that page, a reader can compare exchanges by comparing text. Where it defers, as here, the comparison moves to a document the reader must request or find, and the public page becomes a signpost rather than a specification.

There is a second effect, subtler and more consequential. A deferral protects the operator from being held to a paraphrase, and it also protects the operator from having to state a commitment in public at all. A sentence of the form "we screen announcements against the registry objects their origin holders publish, and drop the ones that fail" would be a promise a member could quote back. A sentence pointing at the rules is not. That asymmetry is not unique to this exchange, and it is why due diligence on an internet exchange so often stalls at the same place: the pages that are easy to read are not the pages that bind.

What the register is genuinely good for

The negative reading, that the table cannot tell you what a member does, undersells what the exchange has built. Three uses survive the caveat and are worth naming, because they explain why the observability layer is elaborate even though the policy layer is thin.

First, the register is an index. It answers who to talk to, and it does so in a form that a script can consume and a person can read. That is the beginning of most peering conversations and not a trivial thing to publish at all, since the alternative is a member list in prose that nobody maintains.

Second, publishing through a shared vocabulary makes an individual exchange comparable without requiring it to assert anything about itself. The comparability comes from the schema, not from the operator's claims. An exchange that wanted similar comparability for its policy would need to publish field definitions, versioning and a change log — instruments a participant table does not need and an institution is rarely eager to build.

Third, the mirror lowers maintenance cost in a way that is honest about its own limits. Copying a row is cheaper than soliciting one, and asking participants to maintain the source row is a reasonable division of labour. The cost is that the exchange cannot vouch for what it republishes, and does not claim to: the provenance sentence is doing precisely that work.

Put together, these three uses describe a register designed to be accurate about presence and agnostic about behaviour. That is a defensible design. It becomes a problem only when a reader treats the register as a verification of behaviour, which the volume of machine-readable output makes tempting.

The reader's problem, stated plainly

For a network considering a connection, the practical sequence that the pages imply is: read the register to find the members you care about; read each member's own records to learn what it says about itself; then ask the exchange for the document the about page names. Only the third step produces a statement the exchange is prepared to be held to, and it is the only step that cannot be completed from a browser.

For the exchange, the sequence is cheaper and the incentives are real. A register that assembles itself from a volunteer database and republishes in five formats is a public-facing asset that costs almost nothing to run and looks substantial from outside. A published filtering policy costs review cycles, creates expectations, and invites the argument that comes with any commitment.

That difference in cost is, in the end, the mechanism behind the split. Observability is cheap to publish and policy is expensive to publish, so an institution optimising for a useful public presence will publish the first and defer the second, and the deferral will look like modesty rather than like a choice.

Evidence boundaries

This article rests on two pages of the operator's public site, retrieved on 21 October 2026 and linked above: the about page and the participants page. The text of "the rules of the exchange" was not obtained in readable form for this reading, and no document describing route-server filtering, RPKI route origin validation, IRR-derived prefix filters or maximum prefix lengths was obtained either; accordingly this article makes no claim about what those rules require or about what the route servers do with an announcement, and its subject is limited to the interface the two pages constitute.

No first-party participant count, port count, traffic figure, fee schedule or governance-body composition was obtained, and none is attributed to the exchange. Whether the CSV, TSV and JSON files behind the formats line carry the same fields as the rendered table was not tested; format plurality is reported, field-by-field equivalence is not. Repeated attempts to retrieve the rules text and the route-server documentation during the reporting window returned provider errors rather than documents, which is a fact about this reading and not a finding about the exchange.