Summary

  • Milan's preliminary IETF venue report marks test 3.1 Met. That test asks whether 80% of attendees can obtain a visa without excessive effort or cost, but the published explanation addresses non-discrimination, the separate subject of test 3.2.
  • The mismatch is a failure of public evidence binding, not proof that Milan misses the 80% threshold. The report may be corrected or supplemented through the community-feedback stage, and it carries no recommendation by design.
  • Montevideo's parallel report shows the intended separation: its 3.1 row expressly addresses the 80% access question, while 3.2 addresses non-discrimination. The comparison concerns record structure, not which city should be selected.
  • Daniel Kade proposes a compact criterion-evidence receipt that binds each status to the exact test, sources, method, cutoff, uncertainty, assessor, revision history and later decision stage.

The square and the sentence disagree

The Milan report is a five-page preliminary assessment made on 9 July 2026. It names Allianz MiCo as a possible venue and presents nine tests covering venue capacity, Internet access, visas, travel risk, health, air quality, unrest and lived experience of discrimination. Its summary records eight as Met, none as Uncertain or Not Met, and one as not assessed. The report's visual grammar is simple: green means Met, yellow means uncertain but possible, red means Not met and grey means unable or not assessed.

At row 3.1, the grammar breaks. The test printed in the left column is specific: “Visa requirements are such that 80% of IETF attendees will be able to obtain a visa without excessive effort or cost.” A supporting explanation should therefore show, at minimum, how attendee-country distribution was related to visa-free entry or a standard application route at reasonable cost. The current IETF template even supplies that form of answer.

The Milan sentence does something else. It states that Italian visa rules are not discriminatory on the basis of race, ethnicity, religion, gender, sexual orientation or gender identity and points to Italy's foreign ministry. That is the exact kind of answer needed for row 3.2. The next row asks that non-discrimination question and repeats materially the same sentence and source. Both indicators are green.

The defect is narrow and visible. It is not a finding about Italian law, the accessibility of Milan or the fitness of Allianz MiCo. The public row simply does not tell a reader why 3.1 passed. It gives no attendee-country distribution, no weighted percentage, no account of visa-free versus standard application routes, no interpretation of excessive effort or cost, and no assessment cutoff beside the conclusion. Perhaps the Secretariat performed that work and the wrong sentence was pasted into the report. Perhaps an intended calculation remains to be added. The public record does not allow either inference to become fact.

That distinction is essential. An unsupported green square is not automatically a false green square. It is a status whose basis cannot yet be reconstructed from the document that presents it.

Montevideo is a control, not a rival verdict

The companion Montevideo report helps because it uses the same template on the same date. Its row 3.1 says that 80% of attendees, by country, can enter Uruguay without a visa or through a standard application process at reasonable cost. Its row 3.2 then separately says that the visa rules are not discriminatory on the listed grounds. The sentences are short and do not disclose the underlying country table, but each answers the question printed beside it.

This comparison should not be turned into a city contest. Montevideo has its own unresolved entries: insufficient air-quality data and the lived-experience test both remain unassessed. Its summary records seven Met and two not assessed. Milan records eight Met and one not assessed. Those totals do not form a league table, and neither report recommends approval or rejection.

Montevideo is useful here only as an internal control. It demonstrates that the report format can keep access coverage and non-discrimination separate. The Milan mismatch is therefore not an ambiguity inherent in the template. One row has inherited the explanation of its neighbour.

Even the Montevideo wording leaves a second question for good governance: where is the calculation behind “80%”? A clear conclusion is better than the wrong conclusion, but a reproducible result is better than either. An aggregate table could state the attendee-country reference period, the population used, visa-free share, standard-process share, excluded or missing cases, assumed cost range and resulting percentage. It need not publish any participant's name, nationality or visa history.

No recommendation is the correct preliminary state

The blank recommendation section is not evidence of an unfinished or defective process. The current IETF Venue Assessment Report template says that a preliminary report can contain only partial information and therefore has no recommendation. Community feedback and research triggered by it are expected to supply the difference between the preliminary and final report.

The 14 August call for input follows that design. It describes both Milan and Montevideo as carrying “no recommendation,” invites messages through a publicly visible one-way list and says feedback is also collated on a public Trello board. The call was scheduled to close on 28 August 2026. At the observation cutoff, it would be wrong to call either city approved, rejected or selected.

The grey row in each report reinforces the point. Test 6.1 asks whether the city is unsafe for participants because of discrimination, assessed through the lived experience of IETF participants. Both reports say community feedback is required. A desk researcher cannot manufacture lived experience from a travel advisory or a legal summary. Here, “not assessed” is not institutional weakness. It is a correct admission that the evidence must come from people who have the relevant experience.

The process is designed to change the record. After feedback, the IETF LLC may conduct more remote research, alter an assessment and issue an updated report with an approve or reject recommendation. A rejection ends that city's path. An approval merely advances it. Detailed assessment, possible site visits, commercial questions, hotel availability and local support follow. Concerns about the core reasons why the IETF meets may require an IESG viability decision. The LLC Board later considers a confidential decision pack before any contract, and public notification comes after contracting.

Those stages are separate authority acts. A green cell is not an Executive Director recommendation. A recommendation is not a detailed commercial assessment. An assessment is not an IESG finding. An IESG finding is not LLC Board approval. Board approval is not a signed contract. The report matters precisely because it carries evidence from one stage into the next; it should not be made to impersonate the later stages.

“Overwhelming majority” became an operational test

RFC 8718 gives the institutional frame. It asks the IASA to apply best judgment, keep the selection process as open as practicable and consult the community early enough for views to matter before a contract is considered. Among the important city criteria, it says that travel barriers to entry, including visa requirements, should be likely to allow an overwhelming majority of willing participants to attend. It instructs the IASA to read travel barriers broadly in the context of whether a successful meeting can be held.

The report template operationalizes that general requirement as an 80% test. That move is useful: a vague adjective becomes something an assessment can answer. But operationalization creates a new duty. Once a percentage is used, the record needs a denominator, a population and a method. Otherwise the apparent precision belongs to the question but not to the answer.

The denominator is not trivial. “IETF attendees” could mean registered participants at several recent meetings, participants expected in the relevant region, unique individuals, person-meeting observations or another forecast. Country weighting could use nationality, residence or usual travel origin, each of which has different privacy and predictive consequences. “Standard application process” needs a boundary, and “reasonable cost” can mean something very different to an employer-funded traveller and a self-funded contributor. The article does not select a method; it asks the public record to name the one used.

This is not an argument for publishing a spreadsheet of personal circumstances. The calculation can be aggregate. The institution can state: reference meetings, country-level counts, official entry route, assumed fees, ordinary processing steps, exceptional cases, missing-data treatment and result. A reviewer can then challenge a source or assumption without learning who holds which passport.

The same discipline protects the assessor. Without a method, a green status can be read as casual judgment. With a bounded calculation and a stated cutoff, it becomes a result that was reasonable on the evidence available at a particular time—even if later policy changes require a new assessment.

Public feedback should repair the record, not guess at it

The ordinary response to the Milan mismatch is straightforward: identify it in the open feedback process, publish the criterion-matched evidence or change the status, and preserve the revision. No allegation of bad faith is needed. No claim that Italy fails the test is justified. The public process is already at the stage intended for precisely this sort of correction.

Good feedback can be compact. It can name the report and version, quote test number 3.1, note that the explanation answers 3.2, ask for the 80% method or a status change, and distinguish the clerical issue from a substantive view of Milan. That gives staff an actionable correction instead of forcing them to interpret a general objection to the city.

RFC 8711 provides a separate and more formal accountability route. A participant may ask the IETF LLC Board to review an Executive Director or Board decision or action believed not to follow IETF BCPs or LLC policies and procedures. Such a request must describe the action, the alleged violation and a proposed remedy; the LLC is expected to publish the request and response or result. That mechanism should not be inflated into the ordinary way to fix a preliminary table. The feedback stage is earlier, lighter and more proportionate.

Proportionality matters for institutional legitimacy. If every typo becomes an appeal, review systems become unusable. If a visible mismatch is ignored because it might be “only” a typo, the published record becomes unreliable. A local correction with attributable history preserves both administrative capacity and public confidence.

A criterion-evidence receipt

Daniel Kade's proposal is to attach a compact criterion-evidence receipt to every assessed row. This is analysis, not current IETF policy. The receipt need not turn a five-page report into a data warehouse. It must make the status travel with enough context that another person can understand, test and revise it.

First, name the authority and version: the RFC requirement, any updating BCP and the assessment-template version. Second, preserve the test identity and exact question. A status should never be copied without the label that gives it meaning. Third, state scope: country, city or venue, the named subject and the assessment cutoff.

Fourth, bind the evidence. List the relevant source or aggregate calculation beside the criterion, with one sentence explaining why it answers this test. Fifth, state method: population, weighting, threshold, missing-data treatment and any local exception. Sixth, record status and uncertainty together. “Met” should be accompanied by the basis; “unable to assess” should say what evidence is awaited.

Seventh, identify the accountable office and stage. The record should say whether the row belongs to an initial Secretariat assessment, an Executive Director's preliminary report, a revised final report or a later decision pack. Eighth, preserve revisions: previous status, corrected text, feedback reference, date and reason. Ninth, record downstream disposition without merging it into the criterion: further research, recommendation, rejection, detailed assessment, IESG review if needed, Board decision and contract state.

The receipt also needs limits. It must not reveal individual visa histories, private feedback, protected personal characteristics, confidential venue bids or the contents of the Board's commercial pack. It does not transfer selection power from the LLC, create a public vote or turn every data source into a veto. Its purpose is smaller: make the handoff between evidence and authority legible.

Correction is part of the evidence

A common temptation is to replace the duplicated Milan sentence and move on. That would improve the report but lose a governance opportunity. A revision note can say that the preliminary 3.1 explanation duplicated 3.2, identify the corrected evidence and state whether the green status changed. The original version can remain available or at least be fingerprinted and dated.

That history serves three audiences. Community reviewers can see that their input changed the record. Staff can distinguish a content correction from a policy change. Later decision-makers can know whether a green result was stable, newly supported or reversed. The correction stops looking like embarrassment management and becomes evidence that the process works.

Version history is especially important when tables are visually compressed. A colour can be copied into a slide, summary or decision pack while the explanatory sentence is left behind. If the receipt carries the test ID, evidence hash or source date and current revision, the copied status remains traceable. If not, the square can outlive the reason it was coloured.

The IETF has reason to favour this discipline. Its technical work depends on exact versioning, attributable changes and the difference between a proposal, an approved text and an implementation. Venue administration is not protocol design, but the institutional lesson transfers cleanly: state without provenance is easy to move and hard to trust.

What the record supports now

At the cutoff, the supportable conclusion is deliberately modest. Milan's preliminary report contains a public mismatch between test 3.1 and its explanation. The same explanation appears under the neighbouring non-discrimination test. The report marks both Met. The parallel Montevideo report and the official template show that the two questions are intended to be answered separately.

The record does not establish that Milan fails the 80% access test, that the green status must turn red or yellow, or that Montevideo should be preferred. It does not reveal what internal research may exist. It does not produce a final recommendation. It does show exactly where public feedback can improve the evidence before later authority attaches to it.

The smallness of the error is not a reason to ignore it. It is a reason the correction should be cheap. A venue decision can involve contracts, travel burdens, participation and institutional trust. The evidence chain begins with ordinary rows in an ordinary table. If those rows answer their own questions, later discretion remains visible. If they do not, colour becomes a substitute for explanation.

A green box should be allowed to say “Met.” It should never be asked to say “trust us.”

Evidence limits

This analysis uses the two preliminary reports, the current report template, the call for input, IETF meeting-planning pages and RFCs 8718, 8711 and 9712. It does not have the Secretariat's internal working papers, the attendee-country calculation, private feedback, the complete Trello record, confidential venue information or a later final report. It cannot determine either city's eventual recommendation, commercial availability, Board decision or contract status.

The source omission is a disclosure finding only. It does not prove that the calculation was never performed. The Montevideo comparison demonstrates intended field semantics but does not validate its underlying calculation or rank the cities. The criterion-evidence receipt is Daniel Kade's proposed administrative safeguard, not an adopted IETF requirement.

Sources

  1. Call for input: Venue assessment reports for Montevideo and Milan
  2. Milan Venue Assessment Report
  3. Montevideo Venue Assessment Report
  4. IETF Venue Assessment Report template v3
  5. IETF Meeting Venue Identification and Selection Process
  6. IETF Meeting Location Assessment
  7. RFC 8718: IETF Plenary Meeting Venue Selection Process
  8. RFC 8711: Structure of the IETF Administrative Support Activity, Version 2.0
  9. RFC 9712: IETF Meeting Venue Requirements Review