Summary

  • RIPE NCC published RIPE-224, an IPv6 request form for Internet exchange points coauthored by Timothy Lowe, Nurani Nimpuno and Sabrina Waschke. On 17 August 2001, Nimpuno announced that the registry was starting assignments to requesting exchanges and would ask pending applicants to complete the form.
  • Four days later, the chairs of the exchange-point and IPv6 working groups challenged the claim that the policy had reached final consensus. Operators argued that waiting was obstructing wanted IPv6 service. Nimpuno explained RIPE NCC's reading of the earlier discussion and acknowledged that coordination with the chairs needed improvement.
  • On 10 September, the chairs said an interim proposal had cleared its comment period and asked RIPE NCC to publish it and begin making assignments. The episode shows where a usable application form, a real operator need and a community policy decision each entered the same workflow.

The form arrived before the argument ended

Anyone running an Internet exchange point in the RIPE NCC service region in August 2001 could find a new document with a reassuring title: IPv6 Request Form for Internet Exchange Points. The form had a RIPE document number, three named authors and a date. It told applicants where to send their request. It specified what would happen if they omitted a registry identifier or changed the templates. A bureaucracy, at least on paper, was ready to receive mail.

Nurani Nimpuno announced the operational step on 17 August. Speaking as RIPE NCC's Internet Address Policy Manager, she said the registry was starting to make IPv6 assignments to requesting exchanges, and pending applicants would be asked to complete the new form. Her message in the RIPE archive described the policy discussion as having reached consensus. The announcement linked an administrative action to a community verdict.

Four days later, Fearghas McKay and David Kessens put a sharp question in reply. They chaired the exchange-point and IPv6 working groups, respectively. In the original discussion thread, they said that they did not think the final proposal had been approved by the wider community. They asked RIPE NCC to suspend the proposed policy until the group could consider a final text. The form existed. The people who would conduct the policy consensus call said the call was unfinished.

This was a surprisingly tangible disagreement. Nobody had to speculate about an invisible implementation plan. An applicant could hold RIPE-224, fill in the fields and send it to the hostmaster address. The chairs could point to the absence of a final policy proposal on the list. Between the two documents stood an operator who wanted a neutral peering network to speak IPv6 without borrowing a member ISP's address space.

A form is an invitation with conditions

RIPE-224 looked like paperwork, but every question in it made a policy choice operational. Asking for a corporate record made the applicant show that an organization existed. Asking for open membership rules made it show that other networks could join. Asking for three members with BGP peering relationships made the claim to be an exchange testable against named peers. Asking for an addressing plan put a technical need behind the request for unique space. An applicant could read those fields and understand the class of institution RIPE NCC was prepared to serve.

A hostmaster could use the answers to decide whether the request fitted that class. The form was already a gate.

That is why the chairs cared about the document behind it. They were not debating whether an IXP should supply a postal address in the right box. They were asking whether the working groups had authorized RIPE NCC to make assignments under the criteria the box implied. The 21 August thread shows a particular kind of governance dispute: staff saw a concluded discussion and a waiting queue; chairs saw an unfinished final text. Both could point to public records. The argument turned on when a series of comments becomes a decision that an applicant can rely on.

For the exchange operator, this distinction arrived as delay. The neutral peering fabric needed identifiers of its own. The member ISP whose address space it might otherwise borrow could change its relationship with the exchange. Customers asking to pass IPv6 traffic would not wait patiently for a seminar on the status of mailing-list silence. Walker's complaint and Doering's account of DECIX using SpaceNet space placed the form dispute in a live network setting. A missing policy paragraph could keep a real peering service waiting, even when a ready form sat on the registry's website.

For the registry, the cost of guessing wrong ran in the other direction. Once RIPE NCC began making assignments under a criterion, applicants could plan around it. If the working groups later decided the criterion lacked consensus, the registry would have to explain why it had used it and how existing assignments fitted the revised policy. A pending request could be parked; an issued resource would become part of an operator's network plan. The September solution therefore did more than allow staff to press “send.”

It attached the operating process to an explicitly approved interim rule and preserved room to revise technical details later.

Nimpuno stood at that junction as a named employee, not an abstract “registry.” She coauthored the form, announced the operational start, and then answered the chairs with a chronology of RIPE discussion and the pending requests. Her reply did not erase the chairs’ role. It acknowledged that coordination with them needed work. The episode gives her a sharper profile than a job title does: she was the person who had to turn community talk into an intake desk, then defend the desk's authority when the policy chairs asked for its ticket.

Why an exchange needed its own numbers

The physical purpose was simple. An Internet exchange links networks so they can exchange traffic. Its peering fabric has addresses; the participating ISPs have their own address space. If the exchange uses the space of one member for common infrastructure, its neutral point of connection becomes dependent on a participant's network. The later RIPE-256 policy describes the need for peering-mesh addresses independent of those used by member networks. The 2001 mailing-list discussion wrestled with that operating problem before the wording was settled.

The ordinary route to a large IPv6 allocation was a poor fit for many exchanges. The April–June working-group record discussed exchanges that did not assign addresses to dozens of customers and often needed only a small prefix for their own infrastructure. Participants considered /64s, /48s, multiple physical fabrics and the risk of granting a special path to a class of requester. Those choices determined how an exchange's technical independence would be recognized.

Operator frustration surfaced once the new form met a pause request. In the August thread, Steve Walker said an application process was the obstacle to switching on IPv6 traffic for customers who wanted the service. Gert Doering, speaking as a SpaceNet operator, said DECIX was using addresses from SpaceNet's IPv6 block as a workaround. Those participants described specific service delays and an interim technical workaround. Another meeting had a cost for them.

That cost gave Nimpuno's August move its urgency. The registry had applications in hand. In her 23 August response, she said several IXP requests had been pending since April. She described intensive discussion at a RIPE meeting and on mailing lists, followed by a June summary and little further objection to the wording. RIPE NCC interpreted that sequence as sufficient to implement the policy and serve waiting requesters. She also said the registry needed to improve coordination with the working-group chairs. Both parts of her message matter: the operational queue was real, and so was the disagreement about the point at which the queue could be processed.

A form that asks who you are

RIPE-224 rewards a close reading. The four-page original PDF asked an applicant to describe the organization and provide an extract from its corporate documentation showing that it existed to facilitate traffic exchange among ISPs. It required a clear, open membership policy and asked for the joining rules. Those fields tested whether the requester looked like the kind of exchange point the special IPv6 path was meant to serve.

The form then asked for a list of members and their autonomous system numbers. At least three had to have BGP peering relationships in the default-free zone, as the form defined it. RIPE NCC said it would check the RIPE Database and could contact the listed peers. This checked actual network relationships behind the claim to be an Internet exchange. The applicant had to connect its organizational claim to independently inspectable routing participants.

Next came address usage. The applicant had to show how its existing IPv4 and IPv6 space was used, with physically separate subnets distinguished. An addressing plan for the intended IPv6 infrastructure followed, including immediate, one-year and two-year needs. The example in the form was a /64 neutral peering mesh. A request for unique space could thus be judged against a map of actual and planned exchange infrastructure.

The document also specified an operational failure mode. A request lacking the proper RIPE NCC registry identifier would be returned; altering templates could delay handling. That warning has the unmistakable sound of an office preparing to process real requests. The three authors—Timothy Lowe, Nimpuno and Sabrina Waschke—had prepared an instrument that staff and applicants could use. The argument over the rules it would administer was still open.

Each box narrowed the applicant pool

The organizational evidence had a purpose beyond administrative neatness. The form asked for documentation showing that the requester existed to facilitate Internet traffic exchange among ISPs. That excluded a company seeking IPv6 space for an unrelated product from simply calling itself an exchange. The open-membership requirement went further: a private arrangement among a fixed handful of networks would need to explain how other eligible participants could join. These were substantive conditions expressed as documents an applicant had to attach.

The application process did not merely collect facts; it made the boundary of the special IXP path visible.

The three-peer test added an operational check. A listed member and ASN could be checked against RIPE Database information, and the form warned that RIPE NCC might contact peers. That gives the claim to be an exchange an external reference point. An applicant can write “open exchange” in a narrative paragraph; it is harder to invent three live peering relationships that survive a registry check. The criterion also shaped whom the policy helped. An emerging exchange with fewer than three qualifying peers might have a real plan and still not satisfy that version of the request form.

The field converted a concept of “exchange point” into a threshold with practical consequences.

Existing-address-use questions served a different purpose. They asked what space the requester already held and how separate physical networks were addressed. The immediate, one-year and two-year plan invited the applicant to set present needs against foreseeable growth. That record could help RIPE NCC choose a suitable prefix and later explain why it had done so. A request for unique IPv6 space is easiest to evaluate when the exchange can show the peering fabric it operates and the scale it expects. The form's example of a /64 neutral peering mesh made that infrastructure concrete.

It was an example of a use, not a promise that every future exchange would receive the same size.

The later RIPE-256 policy shows one way the community eventually wrote the qualification and prefix-size choice. It described a layer-2 IXP with at least three connected ISPs and an open joining policy. It specified a /64 for an exchange certain that one network would suffice and a /48 otherwise. It also warned that the space assigned under this path might not be globally routable. The form and the later policy share recognizable concerns, but their dates matter. The 2002 text is evidence of the later settled publication, while the August 2001 exchange records the quarrel over what could be done immediately.

There is a revealing contrast in the paper trail. A request with the wrong registry identifier could be sent back by return mail. The question of whether the community had authorized the whole class of assignments could not be solved by correcting a template. The hostmaster process was ready to reject malformed applications; the governance process still had to establish a reliable basis for accepting well-formed ones. Nimpuno's desk had excellent boxes. The chairs wanted the decision rule beside them.

Two sides of the same deadline

McKay and Kessens, the two working-group chairs, explained their objection with care. In the 21 August exchange, they said a final policy proposal should be submitted to the list after incorporating the comments received. The working group could then raise major objections before a published policy became effective. Kessens wanted a final text and a last opportunity for major objections. A document describing how requests would be judged was still missing, even while the request form was available.

Operators answered from the other side of the deadline. Robert Kiessling said the discussion had gone on too long and urged the group to implement the arrangement. Walker described customers waiting for IPv6 service. Hans Petter Holen asked whether interim assignments could be made and reviewed once the final discussion closed. They wanted a rule soon enough to serve waiting exchange operators and their users.

Nimpuno's reply occupied a third position: the registry had understood the previous discussion as a concluded policy and had prepared to serve the backlog. She recounted the June summary and lack of further objections. She also accepted the importance of implementing the policy the community actually agreed and the need to work better with the chairs. The correspondence shows when an implementation team and process chairs read the same silence and draft status differently.

The chairs had to identify the policy text that had cleared open review. RIPE NCC staff had pending requests to answer. Exchange operators had infrastructure and customers waiting. The question was where the final authorization step sat between discussion, form publication and assignment. It was small enough to be settled by a mailing-list process and important enough to stop people mid-request.

Silence on a list is a dangerous punctuation mark

The dispute was partly about how to read the absence of further objection. Nimpuno's 23 August message recounted meetings, mailing-list exchanges, a June summary and little response after that summary. From an implementation desk with pending applications, the sequence looked like a decision the registry could finally act on. The chairs read the record more cautiously: comments had to be incorporated into a final proposal, placed before the community and left open to a last round of major objections. A quiet list can mean consent. It can also mean that people are waiting for the final text they were promised.

The two readings reflected different responsibilities. RIPE NCC staff had to answer operators who had been waiting since April. McKay and Kessens had to say when their working groups had completed the policy process. Neither responsibility dissolved the other. If staff waited for every possible wording concern to disappear, the neutral exchange might keep borrowing space from a member. If chairs accepted every implementation-ready form as proof of consensus, the community's chance to reject or revise the criteria would shrink. The argument was over the handoff between those jobs.

The August thread made those clocks visible. Operators pressed for a quick route to IPv6 exchange service. A chair asked for a final proposal and a chance to object to that actual text. Nimpuno set out why the registry believed the previous discussion had been sufficient and accepted that its coordination could improve. The participants were not merely trading procedural slogans. One side had customers and a workaround; another had the obligation to make a community decision legible; staff had a queue to process and a form ready to use.

The August letters also show why a “consensus” label can carry more weight than the person who writes it expects. In Nimpuno's announcement, the label connected the start of assignments to the RIPE community's authority. When the chairs disputed it, they were challenging the basis for that operational act, not Nimpuno's ability to design a useful form. Their reply drew a boundary around who could announce the end of policy discussion. The registry's later cooperation with the interim route shows the boundary being worked out through the same public channels that produced the disagreement.

The eventual September statement gave silence a clearer meaning. The chairs had published an interim proposal, set a date for comments, seen that date pass without a fundamental change in direction, and then asked RIPE NCC to proceed. That is an explicit sequence an operator, staff member or community participant could point to. It did not pretend that every technical question was solved. It identified which questions were settled enough for action and which remained on the work list. The difference between August and September was not merely another month on the calendar. It was a more specific public authorization for the desk to open.

September built the missing bridge

The way out appears in a 10 September message from McKay and Kessens. The final date for comments on an interim proposal had passed. Its direction had not fundamentally changed. The chairs said the interim policy was approved, asked RIPE NCC to publish it and requested that first assignments begin. The text also left specific questions for later work, including default /64 versus /48 size, the address block to use, documentation and registry entries.

This was a useful compromise because it made provisional authority explicit. The group could start serving operators under a named interim arrangement while preserving a list of unresolved details. The chairs described /64 assignments within reserved /48 boundaries, leaving space for a later change of mind about prefix size. The design spent address space to buy policy reversibility. The applicants could move forward; the group retained a way to revisit the parameters.

The RIPE NCC 2001 annual report later recorded the IXP IPv6 policy among the year's policy developments and pointed to the interim discussion and request form. The report records the institution's later account. The September message records the chairs' contemporary request to publish the interim approach after the awkward August exchange.

The prefix-size design made the interim nature practical. The chairs proposed /64 assignments within /48 boundaries kept available for possible later expansion. That is a technical way of preserving future choice. An exchange could begin with addresses for a peering mesh while the group continued to debate whether /64 or /48 should be the default. By reserving the larger boundary, RIPE NCC could reduce the disruption of a later change. Policy uncertainty was managed in the address plan, not merely noted in a meeting minute.

That maneuver had a cost in planning discipline. Keeping room around an assignment requires the registry to think about future allocation boundaries before every question is settled. But the alternative was to make operators wait until the last prefix-size argument ended. The September compromise used a provisional shape that could serve real exchanges and keep the later decision open. It is a vivid example of why policy and engineering cannot always be serialized into neat phases. The interim policy and the address reservation were designed together.

A further RIPE policy document dated August 2002 put the IXP arrangement into concise published form. It described a layer-2 exchange with at least three connected ISPs and an open joining policy, set a /64 for an exchange certain it needed only one network, and a /48 otherwise, and pointed requesters to the form. It also warned that space assigned under the policy might not be globally routable. That document records how the IXP path was later stated, after the 2001 debate.

The clerk, the chairs and the customer

Nimpuno was one of three named authors of the request form and the RIPE NCC manager who announced the start of a service. When challenged, she supplied the registry's account of the process, identified the waiting queue and accepted a need for closer coordination. Those actions made her a useful guide to the edge between policy and execution. The public record shows how the disagreement surfaced and how the chairs later authorized an interim path. Assignment counts for the disputed weeks would require a separate registry record.

The chairs had their own responsibility. A working group's silence after long discussion can look like assent to staff trying to resolve a backlog. To the people charged with concluding policy discussion, the missing final text mattered. Kessens' distinction between a request form and the rule for judging a request is particularly sharp. The form could ask for three peering members and an addressing plan; the policy still needed to say why those tests were the right ones and whether the group had accepted them.

And the customer mattered. Walker's impatient note and Doering's account of borrowed address space turn an abstract process dispute into an operating problem. A neutral exchange needed identifiers for a shared peering fabric. Its members needed a service that could move. A months-long wait imposes costs even when the final answer eventually arrives. The interim arrangement addressed the operators' calendar alongside the remaining policy questions.

The 2001 episode is funny in the way real administrative stories are funny. The application form had places for names, ASNs, contacts, network plans and a registry identifier. It even warned that rearranging the boxes could delay an answer. The people who had to decide whether the boxes represented accepted policy then told the registry to slow down. A month later, they agreed on an interim rule that let the applications proceed and left harder questions on the table. The desk opened, closed halfway, and reopened with a rule attached.

The episode also explains why Nimpuno deserves more than a line in a policy chronology. She worked at the place where an exchange operator's request, a hostmaster's checklist and a working group's decision touched. The August announcement made a service promise. Her later reply laid out why RIPE NCC believed it could keep that promise and acknowledged the chairs' process concern. The September approval gave the promise a public footing. Those are distinct acts by distinct people, recorded in their own words and dates.

For the applicant holding RIPE-224, the difference between them was the difference between a form ready to submit and an assignment process ready to stand behind.

It is an unusually clear record of infrastructure governance because the argument did not remain in a meeting slogan. The form, the mailing-list challenge and the interim rule can be placed side by side. They show exactly where administrative readiness outran a shared decision, and how the gap was closed.