Summary

  • In May 2015, Alain Durand turned five years of available IANA request statistics into a map of work across domain names, number resources and protocol parameters. His post made patterns visible to transition participants without claiming to determine the transition.
  • The categories mattered: new generic top-level domains changed naming requests; number-resource requests stayed broadly level even as the IANA IPv4 pool had been exhausted and returned blocks were redistributed; protocol-parameter registries formed the largest registry set, while Private Enterprise Number requests dominated that category’s use.
  • Request volume can show what arrived and when. It cannot, on its own, establish how difficult a request was, whether it was handled accurately, how much operational risk it carried, or who had authority to set the policy it implemented.

A new colleague meets a familiar institution

Alain Durand’s May 2015 post begins with a useful admission. He had spent more than two decades in the Internet Engineering Task Force. He had chaired working groups, written RFCs and used IANA registries as a participant in technical work. But after joining ICANN a few months earlier, he found that he knew the registries as an external user better than he knew the service operation behind them.

Part of his new role, he wrote, was to support the IANA Stewardship Transition. He responded by looking backward through the statistics available to him and assembling five years of usage data. The resulting post was not a proposal for a new constitution, an audit of every IANA decision or a claim that one measure could rank the work. It was an attempt to understand the scale and pattern of services that a transition conversation was asking people to govern.

That distinction gives the piece its human center. Durand did not present himself as a newcomer to Internet engineering. He identified a narrower gap between knowing how a registry looks to someone who requests an assignment and knowing how a function operator receives, validates and processes requests across a large set of registries. His decision was to learn the service from its observable traces rather than infer its workload from its name or from the prominence of a single controversy.

The result was a working map. It made the number of maintained registries visible, separated three communities whose requests had different causes, and gave readers a time series rather than a snapshot. The map was useful precisely because it did not pretend that “IANA work” was one uniform queue.

The evidence does not show that Durand’s post changed the transition proposal, altered its governance or caused any later service-level measure. Its stated purpose was more modest: to help readers understand the scope of the functions. That is enough to make the exercise consequential. When a service is discussed as if it were a single technical office, a view of its actual request mix can correct the conversation before people start making decisions about capacity, oversight or continuity.

The limits matter just as much. A chart is not a neutral substitute for judgment. Choices about what counts as a request, how categories are grouped, which series receive separate axes and how a total is assembled all shape what a reader notices. Durand’s post gives us a clear account of what he observed. It also gives us a chance to ask what those observations can and cannot establish.

More than 2,800 records, but no single kind of work

Durand described an IANA department maintaining more than 2,800 registries for three operational communities. He identified domain names, number resources, and protocol parameters, including the IETF’s registries. Many registries were, in his description, essentially text files. That plain description can make the work sound smaller than it is. A registry may be a list, but the operating obligation is to apply the rules that govern changes to the list, preserve accurate records and make the resulting assignment available to others who depend on it.

The figure of 2,800 is a count of registries, not a count of equally active services. It tells a reader how broad the catalog was. It does not say how many registries received requests in a given month, how complex their changes were, how much staff time each required or what an error in one record might mean downstream. Treating every registry as an equal unit would turn an inventory into a workload estimate without evidence.

The three community labels also describe more than three departments. They gather different kinds of request, different technical vocabularies and different policy settings. Names work includes changes to top-level-domain records and delegations. Number resources include allocations of IPv4, IPv6 and autonomous-system number blocks to regional registries. Protocol parameters include a long catalogue of values that standards and implementations rely on. A shared operator may execute all three, but that does not make the underlying tasks interchangeable.

This matters for staffing and for governance. A queue of routine contact changes can expand quickly while remaining procedurally standardized. A single delegation or re-delegation may involve a longer validation path and more parties. A number-resource request may be infrequent yet depend on the precise implementation of an agreed global policy. A protocol-parameter request may be mechanically simple while still requiring the operator to follow a registry-specific procedure, consult an expert or refer a dispute to the right standards body.

A single count can obscure these differences in either direction. It can make a high-volume series look most important simply because more entries appear on a graph. It can also make an infrequent series look negligible when its records have high consequence or high complexity. Neither conclusion follows from frequency alone.

The measurement problem is therefore not that counting is useless. It is that the unit being counted must be named before the count is interpreted. Durand’s post made several units visible instead of offering only an aggregate. It let a reader see that IANA was coordinating a set of services whose demand came from distinct operational communities. That is a better starting point for understanding the operator than assuming that one function name corresponds to one workload.

Names work did not move as one curve

Durand divided domain-name requests into broad categories. For country-code top-level domains, he separated delegations and re-delegations from changes such as administrative or technical contact updates and DS-record updates. The generic-domain view likewise distinguished delegations and re-delegations from changes to records such as name servers, contacts and DS data.

This split gives a reader a first way to distinguish the number of requests from their meaning. A change to a contact record is not the same operational event as a delegation decision. The systems may record both as requests, but a service manager would not necessarily assign the same validation, coordination or elapsed-time assumptions to each. Durand’s categories do not tell us how long each case took or how many people were involved. They do show that the service itself recognized unlike kinds of work.

His generic-domain graph also made a program change visible. With the introduction of new gTLDs, the volume of delegation and re-delegation requests increased substantially. That is an example of a demand curve responding to a policy and market environment. It does not mean that the operator itself created the program or that the increase represented a corresponding expansion in the social value of names. It means that a new class of delegated domains produced more requests for the relevant operating service.

The administrative implication is practical. If an organization forecasts staffing from the prior average alone, a new program can make its baseline stale. The five-year chart is helpful because it places the increase in context: the curve did not simply rise at a constant rate. A visible step or sustained change may call for a different plan from a gradual fluctuation inside the existing pattern.

But a chart that shows more requests does not reveal how much additional labor they required. One hundred uniform requests could take less time than ten complicated ones. A spike could reflect many independent requests, a batch of changes generated by one program, a procedural backlog being cleared, or a change in the rules for what is counted. The graph establishes the first-order fact of more recorded requests. Determining the operational burden requires supporting evidence such as processing time, validation steps, rework, escalation and staffing.

There is also a difference between a trend and a forecast. Durand’s five-year view documented a pattern that had already occurred. The new-gTLD increase showed that historical predictability had conditions. It was not a promise that future request volumes would repeat the same path. A responsible organization could use the series to ask what changed, then test whether the new level persisted. It should not treat an earlier average as a guarantee.

The useful contribution is that the naming work was not left as a single line. The separation makes it possible to ask which kind of demand changed. That is already a more answerable question than “Did IANA become busier?” It is not yet an answer about cost, quality or institutional authority.

Stable number requests did not mean a stable world

The number-resource section tracks requests to IANA for IPv4 and IPv6 unicast blocks and autonomous-system number blocks. Durand reported that the large IPv6 blocks requested by regional Internet registries had been requested before 2010, with no additional requests in that series afterward. He also recorded the exhaustion of IANA’s pool of unallocated IPv4 unicast addresses in 2011 and noted that a few blocks later returned to ICANN and were redistributed to the RIRs under global policies.

Those are three different facts: a request pattern for large IPv6 blocks, an exhaustion event in one central pool, and later returns that were redistributed according to policy. They should not be collapsed into a claim that address demand disappeared. IANA’s allocation requests are not the same measurement as traffic across the Internet, the number of addresses used by networks, or the ongoing work of the regional registries. A flat series at the IANA boundary cannot represent all activity downstream.

The distinction is especially important in a scarce-resource setting. A pool can be exhausted even while the number of requests handled by the central function remains stable or declines. Scarcity is a statement about available stock relative to rules for distribution; a request chart is a statement about observed flow through a particular operator. One may inform the other, but they are not the same variable.

The return of a few IPv4 blocks illustrates why an operational record benefits from context. A simple line graph might show a new request after exhaustion and invite the reader to assume that an ordinary reserve remained. Durand’s prose explains that returned blocks were later redistributed under global policies. The fact that a block appeared again in the pool did not erase the prior exhaustion or create a fresh, unconstrained supply. The applicable policy and the origin of the block matter.

For managers, stable volume can conceal a change in the work’s consequences. If each request interacts with a finite pool, a redistribution may be more consequential than a high-volume series of routine parameter assignments. If policy changes alter eligibility or timing, the request count may move little even though the interpretation of each case changes. A volume series is valuable for capacity planning only when the operator retains information about the rules and state associated with each request.

The 2015 performance report adds another distinction. Its number-resource section described measures for correct policy implementation, whether the registry was updated before the requester was notified, how many clarification rounds were needed, completion within a defined period and public transparency. The report said no number-resource requests had been completed during that month. The performance categories therefore tell a reader what obligations were being tracked, while the zero-completion note warns against reading the month as evidence of a busy or idle system without checking the underlying activity.

The broad lesson is not that the number-resource line was misleading. Durand himself described it as stable. The lesson is that stability at the request-count level leaves open what happened to supply, policy, downstream use and the consequences attached to each transaction. A good analysis preserves those distinctions.

A long registry tail and one unusually active series

The protocol-parameter section highlights a different mismatch between inventory size and request volume. Durand wrote that the vast majority of registries maintained by ICANN as IANA function operator were protocol parameters defined and used by the IETF. Yet within the usage data, the most heavily used IETF protocol-parameter registry was the Private Enterprise Number registry. PEN values are commonly used in Simple Network Management Protocol management-information-base configurations.

A large number of registries does not imply that every one receives an equal stream of changes. A long-tail service can contain many registries that are rarely touched and a small number that attract repeated requests. That is a common challenge in infrastructure operations: an inventory describes breadth, while activity data describe concentration. Both are needed. A budget built from the number of registries alone may overstate routine work in quiet namespaces and understate the burst load in the busy ones.

Durand made one deliberate charting choice to help readers see this. He separated PEN requests from other IETF requests because their frequency made the remaining series harder to read on the same chart. This was a choice about presentation, but also a choice about what kinds of comparison were possible. Without the separate PEN line, the smaller request series could appear almost flat beside it. Once split, both the concentrated registry and the lower-volume remainder became easier to inspect.

That choice does not make the graph a complete complexity measure. It gives a better view of frequency. The post does not tell the reader whether PEN registrations were more or less difficult than other protocol-parameter changes, which registries required expert consultation, how often requests were corrected or how much time each type consumed. A busy registry may be predictable and easy to automate. A rare registry may require careful review and carry a larger risk of incompatible implementations. The record needed to answer those questions would sit beside the request series, not inside it.

The technical context also helps prevent a category error. Protocol-parameter registers are not a single policy domain simply because one operator maintains the records. RFC 2860 says that, for protocols within the IETF’s scope, IANA assigns and registers parameters according to criteria and procedures specified in RFCs. In technical doubt, it seeks guidance from the Internet Engineering Steering Group. The operator’s count shows that requests arrived. The standards documents and associated procedures establish how those requests should be handled.

This boundary is easy to miss when the operator’s name stands in for the entire system. A reader can see “IANA assigned a value” and infer that IANA chose the substantive rule. The agreement shows why that inference can be wrong for IETF-scope parameters. The registry operator maintains the record and applies instructions; the relevant standards process supplies the applicable criteria and, in specified cases, guidance.

Durand’s long participation in the IETF gives that distinction a personal dimension without making him its sole author. RFC 3901, which he coauthored with Johan Ihren, offers operational guidance for DNS deployment during mixed IPv4 and IPv6 transport. It recommends that each zone keep at least one IPv4-reachable authoritative server, a continuity measure aimed at preventing resolution paths from breaking for clients that cannot use IPv6. The recommendation is about operating a protocol across a transition, not about measuring IANA’s registry workload.

It shows the technical perspective he brought to the question: operational continuity depends on details that a request total cannot express.

He also appears among the five editors and authors of RFC 3363, which considered IPv6 address representation in DNS, and coauthored the informational operational discussion in RFC 4472 with Ihren and Pekka Savola. These are collaborative records, not evidence of a lone architect. They make it plausible that a long-time standards participant would want to understand how registry operation looked from inside the service. They do not justify crediting him with the whole policy or engineering history of IPv6 DNS.

The final graph is useful because it is not the only graph

Durand’s last chart combined requests across the three communities over five years. He noted that the ccTLD and gTLD delegation and re-delegation lines used a secondary axis on the right so the graph could be read alongside other series. He reported that new-gTLD introductions substantially increased the relevant delegation volume, that number-resource requests remained flat and that protocol-parameter requests began rising after a lull around mid-2012. With the new-gTLD exception, he described the aggregate volume as predictable over the period.

A combined chart can answer an important question: how did the total volume of recorded requests move across functions? It can help a manager recognize that a spike in one stream did not necessarily mean every stream changed at once. It can also put an exceptional program increase beside the longer baseline rather than forcing a reader to compare unrelated snapshots.

But a total can obscure as well as summarize. If a series occupies a secondary axis, readers must notice that the scales differ. If one registry generates far more events than another, the aggregate may largely reflect that high-frequency stream. If a low-frequency task carries substantial consequences, the total can make it visually disappear. The arithmetic may be correct while the intuitive comparison becomes weak.

The second axis is not a flaw by itself. It is a reminder that chart design does part of the reasoning. A well-labeled chart can show two scales without pretending the underlying counts are directly comparable in operational importance. A less careful reader might compare slopes or heights as if the same vertical movement meant the same quantity. Durand explicitly signaled the separate axis, giving the audience a chance to read it correctly. The accompanying text also named the principal trend in each community rather than asking the aggregate to speak alone.

There is a broader measurement principle here: aggregation should come after classification, not replace it. First define what the events are. Then decide which categories can be added, which need separate scales, and which require a different performance measure. A total that follows these steps can summarize. A total that erases them risks becoming an attractive but uninformative number.

Durand’s post contains evidence of classification, but not every definition a later auditor would want. It does not publish a detailed data dictionary for each graph in the text; it does not show, in accessible tables, every monthly value; and it does not document how duplicates, reopened cases or requests that never completed were handled. These limits do not invalidate the analysis. They delimit it. The reader can learn the direction and relative pattern he reported, but should not reconstruct an exact statistical model or a precise workload budget from the prose alone.

The figure that the overall series was predictable also has a narrow meaning. The request volume was predictable in the five-year record apart from the new-gTLD effect. It does not establish that staff hours, risk, latency, correctness, funding needs or customer satisfaction were equally predictable. Prediction is always prediction of a specified variable. The post’s variable was request volume. Extending it to other outcomes would require other data.

Volume and performance met in the same month

A useful comparison sits beside Durand’s article. IANA published a May 2015 C.4.4 performance report under the contract then governing ICANN’s performance of the functions. It reported measures such as whether routine root-zone changes were processed within a defined time, whether approved changes were implemented correctly, and whether number-resource requests met timeliness, process-quality and transparency requirements.

For routine changes to delegated TLD records, the report set a target that 80 percent be processed end to end within 21 days. The May actual was 86.1 percent; the report listed accuracy at 100 percent against a 100 percent target. The number-resource section defined several separate indicators and also said that no number-resource requests were completed in the reporting month.

These measures answer a different question from Durand’s five-year graphs. The graphs ask how many requests arrived in broad categories. The contract report asks whether specified service obligations were met. Neither replaces the other. A service can receive a rising volume and still meet its time target. A service can receive a small volume and still fail on a case whose impact is high. A count alone cannot show that the result was accurate; an accuracy percentage alone cannot show how much work arrived or how complex it was.

The reports also show why denominators deserve attention. If there are no completed number-resource requests in a month, a reader needs to know how each percentage was calculated, whether the metric concerns requests from an earlier period or an ongoing process, and what observations are included. A headline that says a target was met is not the same as a count of completed work. The official report supplies the activity note, which helps a careful reader avoid treating the percentage as a measure of volume.

Nothing in the evidence suggests that Durand’s post caused the C.4.4 report or that he designed its measures. The contract-reporting system existed in the same period, and the two public records can be compared because they measure distinct dimensions. Durand’s post made broad usage patterns easier to see. The performance report made selected timeliness, accuracy, process and transparency obligations inspectable.

The pairing suggests a more useful measurement package: request count by category; arrival and completion timestamps; time spent waiting for an external decision; number of clarification cycles; correction and accuracy records; backlog age; and customer-visible consequences. The first two would help describe flow. The next set would help explain process quality. The last would help connect service performance to the people and systems that rely on it. No single metric can stand in for all those questions.

A count can still be the right first move. If an operator cannot tell which service receives which requests, it cannot sensibly forecast a queue or diagnose a shift. But a service report becomes more accountable when it can show both the work arriving and what happened to it.

The transition was collective, and the functions stayed distinct

Durand said his analysis might help people actively involved in the stewardship transition understand the scope of IANA functions. Timing matters: he published in May 2015, as the transition proposal was still being assembled. But timing is not evidence of influence. The reviewed public sources do not show that his charts were cited as a basis for the final proposal, that he selected its architecture or that his personal view determined what the communities agreed.

The final ICG proposal, transmitted in March 2016, describes three operational communities with direct relationships to the functions operator: domain names, number resources and protocol parameters. It says policy and oversight responsibility for the three functions resided in those separate communities. It then records different arrangements: a naming-function contract and monitoring structures; an agreement between ICANN and the five RIRs for number services; and the continued IETF agreement and its established policies and oversight for protocol parameters.

This structure reinforces why the count categories mattered. The same operator might process requests for each community, but the customer relationship, policy origin and accountability path were not identical. The name of the operator was not itself a complete explanation of who decided what rule applied. A monthly graph could make demand legible; it could not grant a unified policy mandate to the person or organization that ran the registry files.

The Board accepted the ICG proposal on 10 March 2016. That collective decision should remain collective in the account. Durand’s own description places him in a technical staff role supporting the process. It does not place him among the selected community representatives or make him the author of the final proposals. His public article is evidence of a contribution to understanding the work, not proof of authorship over governance.

That distinction preserves the value of his work. There is no need to exaggerate an individual’s influence to show why an operational analysis mattered. A transition involves contract, accountability, continuity and legitimacy. To design it responsibly, people need to know what the service does and how it behaves. Evidence about volume is one input into that picture. So are response times, correctness, policy documents, customer experience, security controls, funding and contingency plans.

A request chart is not a constitutional document. It cannot answer which community has a right to set a policy or what procedure applies when a request is disputed. Yet a governance design that ignores how a function operates is also incomplete. If rules assign responsibility to people who cannot see the relevant data, they may be unable to distinguish normal activity from a warning sign. If a service operator controls all the data and its definitions, customers may lack the evidence needed to challenge an interpretation.

The useful relation between evidence and authority is therefore not substitution but separation. Evidence tells decision-makers what happened under a set of definitions. Authority determines who may interpret the evidence, set rules and demand a remedy. A durable oversight system needs both, with a visible path between them.

What the public record lets us say about Durand

The evidence establishes a small but clear sequence. Durand joined ICANN in March 2015. He wrote that he had long used IANA registries through IETF work but did not know their internal operation closely. His role involved supporting the transition process. He gathered five years of available usage data, divided the presentation by community and request type, separated PEN activity for readability and summarized the aggregate trend.

That sequence describes a work decision and a public result. It does not reveal his private motives beyond what he wrote. It does not tell us who assigned the project, whether other staff assembled the underlying data, how the charts were reviewed, whether the data collection was exhaustive or whether the post changed a budget or proposal. A careful profile does not need to fill those gaps with imagined scenes.

His technical record helps explain why the exercise fits his background. The RFCs associated with him show work on IPv6 and DNS, including operational guidance that was coauthored and reviewed through an engineering process. Those documents concern interoperability, continuity and the practical consequences of protocol deployment. The 2015 usage study had a related, though distinct, concern: how a common record-keeping service was being used across different technical communities.

The evidence also limits how broad a biography this can become. The article does not reconstruct every employer or project in Durand’s career. The available sources here support a focused portrait: a technical participant moved inside an organization, noticed that familiarity with the public registry was not the same as knowledge of operations, and used statistics to understand the difference. That is the story because it can be tied to an observable decision and a published result.

The result was not a new service model or a validated workload forecast. It was a clearer account of request patterns at a moment when the operator’s future oversight was under public discussion. Readers could see which patterns changed and which remained broadly stable. They could also see that the work was not one large queue. These are meaningful organizational outputs even if they do not settle who should govern the functions.

The question “What did Durand achieve?” can therefore be answered without turning him into a sole architect. He made a slice of IANA operations easier to discuss. He helped move a conversation from the abstraction of “the IANA function” toward identifiable service streams. The scale of the claim matches the scale of the evidence.

A map is not a mandate

The phrase “how much the community uses” appears in Durand’s own explanation for his study. Usage is a useful lens because services must be sized for real demand, not merely for the organization chart. Yet use does not define the entire public value of an infrastructure function. Some records change rarely precisely because they coordinate an agreed namespace that many systems can rely on. A low event count may accompany a high continuity obligation.

Nor can usage decide whose rules the operator should follow. A registry may receive requests under a policy developed by a separate technical community. The operator’s work may be essential while its discretion remains bounded. The authority to assign values, set standards, approve a delegation or change a policy may reside elsewhere. RFC 2860 is explicit about the IETF boundary for protocol parameters; the transition proposal records separate policy and oversight communities for all three categories.

The opposite error is also possible: because an operator does not originate a policy, people may underestimate the importance of implementation. A correctly maintained registry can be the point at which a written rule becomes usable by network operators. A delay or inaccurate entry can affect implementations, naming, routing or coordination. Policy ownership and operational responsibility are distinct, but neither is trivial.

A serious evaluation therefore asks several questions separately:

  • What kind of request or change is being counted?
  • What rule governs acceptance, and who established it?
  • How long did processing take, and how much time was under the operator’s control?
  • Was the resulting record accurate and publicly available?
  • What systems or users depended on the result?
  • Which body can review a disagreement or require correction?
  • If one operator fails, can another take over without losing the history, data or expertise needed for continuity?

The usage charts answer mainly the first question and provide a partial baseline for the second-order operational questions that follow. They do not answer the complete list. That is not a criticism of a post that set out to understand scope. It is a reason to read the post for the question it asked rather than use it as evidence for a larger conclusion.

The public reporting system still reflects the need to keep these dimensions apart. The current IANA performance index provides separate surfaces for naming SLAs, number-resource SLAs, IETF protocol-assignment statistics, root-zone-maintainer performance and other records. The report taxonomy is not a simple continuation of Durand’s 2015 chart, and there is no evidence that it was caused by his study. It does show that performance accounting is organized by service relationships and measures, not by a single universal IANA score.

Durand’s most durable contribution in the available record is thus epistemic rather than constitutional. He showed readers what the data could reveal: different service streams, a visible program-driven shift, a stable number-request pattern and a long registry catalog with a concentrated request series. The careful reader can also see what the data cannot reveal without additional evidence.

For an operator, that boundary is practical. If a board sees a rising request series, it should ask whether staffing, process or controls need to change. If a community sees a stable series, it should not assume that policy is settled or consequences are small. If a transition proposal refers to the same operator across functions, it should still preserve the separate customers, rules and review rights attached to each function.

A count can make operations legible. It cannot by itself make those operations legitimate. Durand’s post is strongest when read as a map: a way to see where work arrived and how its pattern changed, before asking who sets the rules, how well the service performed and who is able to act when the evidence points to a problem.

Sources