Summary
- At 08:59 UTC on 9 September, an author asked DNSOP to adopt a new DNS latency measurement draft under a subject headed “Call for Adoption.” At 10:37 UTC, chair Benno Overeinder said DNSOP chairs issue such calls and described author announcement and discussion as preceding steps.
- The correction was not a rejection. At the reporting cutoff, the document remained revision 00, an active individual Internet-Draft in
I-D Existsstate, with no Working Group adoption or IETF endorsement recorded. - The draft makes a parallel technical argument: “DNS latency” can cover different scopes, observation points and timing components. A process label cannot confer authority, and a metric label cannot confer comparability; both need provenance.
Ninety-eight minutes between a request and a correction
The first message reached the DNSOP list at 08:59 UTC. Jishuang Wang wrote that he would like to request Working Group adoption of A Framework for DNS Resolution Latency Measurement. The body invited feedback on three sensible questions: whether the problem belongs in DNSOP, whether the proposed terminology is useful and whether the group would support adoption as a starting point.
The overstatement sat in the subject. It called the message a “Call for Adoption,” a phrase that can be read as the opening of a formal Working Group process rather than a participant's request for one.
At 10:37 UTC, DNSOP chair Benno Overeinder answered publicly. He said the chairs issue calls for adoption. A draft should first be discussed on the mailing list and, preferably, presented in a DNSOP session. An author may announce the draft and ask about fit and usefulness, but should do so without “Call for Adoption” in the title. Depending on that discussion and the Working Group's interest, the chairs can open a call as a third step.
That answer did not reject the document. It did not decide technical merit, close discussion or promise that no call would occur. It restored the correct present tense: an author had made a request; the chairs had not yet opened the state named in the subject.
The tracker says “individual,” not “adopted”
The Datatracker record is unambiguous at this article's cutoff. Revision 00 is an active individual Internet-Draft. Its IESG state is I-D Exists. The page carries the standard warning that anyone may submit an I-D, that this one is not endorsed by the IETF and that it has no formal standing in the standards process.
The history records the initial upload on 9 September, not a Working Group adoption event. The draft header says “Intended status: Informational” and gives an expiry date of 13 March 2027, while the Datatracker's formal intended-status field is blank. A header aspiration and a populated workflow field are different evidence.
The safe state chain is therefore longer than the subject line:
author announces ≠ chairs open adoption call ≠ chairs assess WG interest ≠ WG adopts ≠ document advances ≠ RFC published.
Each transition can happen later. None should be backfilled merely because an earlier message used the next state's name.
Open participation does not mean self-issued authority
This boundary is not a defence of closed standards work. It is what keeps open participation legible. Anyone can submit an Internet-Draft, post analysis, ask for discussion and argue that a draft should become Working Group work. The power to speak is broad; the power to declare a formal process transition is narrower.
RFC 2418 says most Working Group work occurs on the mailing list and assigns chairs responsibility for managing process and judging rough consensus. It also warns that message volume is not itself evidence of consensus. RFC 7282 sharpens the point: open technical objections must be considered; a large number of affirmative responses does not manufacture consensus around an unanswered issue.
Neither RFC supplies the exact three-step DNSOP practice in the chair's reply. That local sequence is evidenced by the reply itself. The RFCs explain why the role boundary matters: a consensus process needs an accountable caller who distinguishes discussion, polling, objection handling and decision.
If every participant could declare that a call had started by choosing the phrase, the archive would contain competing official-looking clocks. Which opening time governs? Which revision is under review? When does the response window close? Who assesses the objections? Formal authority answers those questions without limiting who may contribute.
The draft studies the same problem inside a number
The irony is productive. The revision 00 text argues that reports called “DNS latency” often measure unlike parts of resolution. A number can look precise while its semantic state remains ambiguous.
The draft separates three conceptual timing components. TC1 is communication between a client and recursive resolver. TC2 is processing inside the recursive resolver, which can include cache lookup, policy evaluation, DNSSEC validation and response construction. TC3 is interaction between the recursive resolver and one or more authoritative servers.
An end-to-end result can contain TC1, TC2 and TC3. A resolver-processing result may contain only TC2. A client-to-recursive result may be TC1; a recursive-to-authoritative result may be TC3. RFC 9499 provides stable names for the DNS roles, but naming the roles does not tell a reader which path a particular timer covered.
Context changes the meaning again. Cache state, transport, query type, network connectivity, location, resolver configuration and deployment architecture may all matter. RFC 7858 describes connection reuse and setup considerations for DNS over TLS. RFC 9250 defines DNS over QUIC. These standards do not prove that one transport is faster; they show why a transport label and connection state belong beside an elapsed-time result.
A median and P95 can therefore be mathematically correct yet operationally incomparable to another median and P95. Different sampling methods, observation intervals, scopes or contexts may describe different questions.
A measurement needs a passport, not a more impressive decimal
The draft proposes a reusable description template. It includes a measurement identifier and objective; the scope and observation point; the timing components included; operating context; observation interval; sampling method; statistical representation; and notes.
Its worked example describes TC3 observed at a recursive resolver, under a cache miss, using DNS over QUIC and IPv6 against an anycast authoritative service, over the first quarter of 2026, using passive observation. The example gives a median of 14.2 milliseconds and P95 of 27.6 milliseconds and notes DNSSEC validation. The draft explicitly calls the example illustrative.
Not every field must appear in every operational display. The text allows incremental adoption. But omission has a cost: the value becomes harder to interpret and compare. Interoperability here means that different implementations can describe results consistently, not that they must use the same algorithm or return identical numbers.
That is a useful minimum specification. It leaves laboratories and operators free to choose tools while demanding enough context for a downstream reader to know what was timed. A leaderboard should not gain credibility by adding decimal places to semantically different measurements.
One provenance envelope, two independent records
The process correction and the measurement framework point to a common design rule: the wrapper must not silently advance the state of its contents. A subject cannot turn a request into an official call. A dashboard label cannot turn unlike timers into a comparison.
A state-and-measurement provenance envelope can preserve both boundaries. This is my editorial proposal, not an IETF, DNSOP or draft requirement.
The process record would name the draft and revision, preserve an immutable digest, identify the author's announcement and requested action, and record the sender's role. If chairs later issue a call, that event would receive its own message identifier, opening time, closing time and revision. The discussion corpus would be linked, with substantive issues rather than response counts. A chair's declared outcome would then create the next recorded state. Shepherd, stream, IESG and RFC identifiers would appear only if those later transitions occur.
The measurement record would use the draft's own semantic fields: objective, scope, point, TC1/TC2/TC3 composition, context, interval, sampling and statistical representation. The raw dataset or protected internal reference could remain with its steward, but the public claim would retain enough context to be audited.
The two records should be linked, not merged. An official adoption state would not validate any latency number. A beautifully documented measurement would not confer Working Group status on the draft. Each kind of authority remains bounded to what it can prove.
Heng Lu's Policy Mirror asks institutions to keep actor, rule and evidence visible. Here that means preserving who requested, who could call, what state existed and what a number contained. The Minimum Initial Specification supports a compact common envelope with room for local extensions. Why BTW Media Exists sets the editorial limit: report the request without upgrading it to a call, and report the metric without upgrading it to a comparison.
The chair's response was small and timely. Its value lies in preventing a convenient label from becoming institutional memory. The draft offers the same service to operations: preserve enough context now so that a number does not acquire a meaning later that its measurement never supported.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance