Summary

  • Internet Society Board Resolution 2026-14 reaffirmed the existing NomCom liaison guideline, with no revisions, by unanimous written consent on 10 July 2026. It took effect immediately.
  • The guideline still refers three times to RFC 3777—for the process, confidentiality and liaison rules—even though RFC 3777 was superseded by RFC 7437 and the current BCP 10 is RFC 8713.
  • The rule assigns the liaison two duties: convey facts and views believed to reflect Board consensus, and act in the IETF’s best interest. It says the first should prevail if the duties conflict.
  • RFC 8713 also contains both duties, but says additional responsibilities assigned by an organisation may not conflict with its provisions. Liaisons do not vote on candidate selection.
  • No evidence was found of an actual conflict, improper intervention or effect on a candidate. The governance gap is documentary: the Board has not published a clause-level successor crosswalk explaining how its priority rule fits the current RFC.
  • Internet Society should issue a short, privacy-preserving rule receipt. It should map the old references to RFC 8713, state the conflict interpretation and record future rule-level dispositions without exposing NomCom deliberations.

A reaffirmation is a present-tense act

Resolution 2026-14 looks at first like routine policy maintenance. Internet Society’s Governance Committee reviewed four Board policies. It recommended amendments to three and presented the fourth—the guideline for the Board’s liaison to the IETF Nominating Committee—in its existing form. The Board approved the package by unanimous written consent on 10 July. For the liaison guideline, the resolution says that no revisions were proposed and that the text was reaffirmed with immediate effect.

That distinction matters. The guideline originated in 2012, but the public cannot reasonably treat it as a forgotten page that survived a website migration. The Governance Committee placed it before the Board. The Board chose to keep it. A current banner now records the 2026 reaffirmation.

Reaffirmation does not rewrite every dated reference by implication. Nor does it prove that the policy is invalid because one citation is old. It does make the status question unavoidable: what exact process did the Board reaffirm?

The public text answers with RFC 3777. It says the liaison’s main role is to ensure that the process defined there is followed. It requires periodic Board reports consistent with that RFC’s confidentiality rules. Its second numbered instruction again directs the liaison to follow RFC 3777’s liaison rules.

RFC 3777 was published in June 2004. The RFC Editor now marks it obsolete and points to RFC 7437. RFC 7437, published in 2015, records that it obsoleted RFC 3777. Its own information page records that RFC 8713 then obsoleted it. RFC 8713 was published in February 2020 and is the current BCP 10 specification for operation of the IETF Nominating and Recall Committees.

This is not a broken-link story. All three documents remain readable. It is an incorporation story. The policy does not say whether “RFC 3777” freezes the 2004 text, means the current successor to that text, or identifies particular duties that continue through the BCP chain. A reader can infer the sensible operational answer. A reader should not have to infer a current Board instruction after a formal review.

The liaison carries two mandates, not one vote

The role is easy to overstate because the NomCom chooses candidates for some of the IETF’s most consequential positions. The current RFC prevents that shortcut. The Internet Society Board may appoint a liaison at its discretion, but the liaison does not vote on candidate selection. The NomCom Chair, other liaisons and advisors are also excluded from that vote. Their influence is informational and procedural, not a ballot over names.

Internet Society’s instruction further separates the liaison channel from ordinary participation. The person holding the role may submit personal feedback only through channels available to other IETF participants, such as the general feedback form. In the liaison channel, personal preference should not be visible. The liaison is expected to stick to facts and views that the liaison believes represent Board consensus.

That is a narrow representational mandate. It does not let the liaison speak for Internet users, for the Internet Society’s membership as a whole, or for an undefined global community. It identifies one institutional principal: the Board of Trustees. Lu Heng’s distinction between a stakeholder and a principal is useful here precisely because the policy does not rely on ambient participation. The Board appoints; the liaison conveys the Board’s views within a bounded role.

But a second mandate sits beside the first. Internet Society tells the liaison to act in the best interest of the IETF. It then supplies a meta-rule for disagreement among its three guidelines: use best judgment, but let the Board-consensus instruction prevail over the IETF-best-interest instruction when the two conflict.

That is not an accusation hidden between the lines. It is an express design choice. It also does not show that a conflict has ever occurred. The policy describes what should happen if one does.

The appropriate question is therefore not whether a liaison improperly influenced a candidate. There is no public evidence for that claim. The question is whether a current public rule adequately explains the boundary between the liaison’s organisational agency and the process duty owed inside NomCom.

RFC 8713 retained both duties and added a hard edge

The current BCP did not eliminate the dual role. Section 4.7 of RFC 8713 says liaisons are responsible for helping ensure that the NomCom and its Chair execute their duties in the best interests of the IETF community. It also says liaisons are expected to represent the views of their respective organisations, provide information about those organisations and carry questions and responses across the interface.

Those obligations can coexist most of the time. An Internet Society Board view about institutional experience, governance requirements or the operation of a confirming body may help the NomCom do its work. Organisational representation is not automatically interference. A liaison is there because the committee benefits from a defined connection to another body.

RFC 8713 also gives the role a process-monitoring function. A liaison should review NomCom operation and execution, report concerns immediately to the Chair and, if the matter cannot be resolved, use the RFC’s dispute-resolution process. This is more than passive observation, but it is still bounded. The concern travels through a named route; it does not become a candidate-selection vote.

The hard edge appears in the sentence governing other responsibilities. A liaison may have duties required by the appointing organisation or requested by NomCom, except that those duties may not conflict with another provision of RFC 8713.

Internet Society’s priority rule and RFC 8713’s no-conflict clause are not necessarily contradictory. The Board-consensus duty is also contemplated by the RFC, not merely added from outside. “Best interests” is a standard requiring judgment, not a measurable switch. A Board view may itself be framed as protecting the IETF. And the Internet Society wording may be intended to govern how the liaison speaks, while the RFC governs what the committee role may do.

Yet those are interpretations. The reaffirmed policy does not publish them. Its meta-rule anticipates a conflict between duties and assigns priority. The current RFC says additional responsibilities cannot conflict with its provisions. A clause-level crosswalk should say whether Internet Society sees no legal conflict, how it distinguishes speech from action and which rule controls if the liaison believes an instruction cannot be reconciled with the current BCP.

The need is strongest because the decision environment is confidential. Outsiders cannot test the interpretation by reading candidate deliberations, and they should not be able to. The institution must make the rule clear before any hard case, rather than relying on disclosure after one.

The version chain changes more than a number

Replacing 3777 with 8713 would remove the visible anachronism, but a responsible update requires more than search-and-replace. RFC 8713 consolidated changes in the IETF’s institutional environment, including the IETF Trust and IETF LLC roles. It changed and reorganised provisions, and it now has a later update of its own. Section numbers and institutional labels cannot be assumed to map one-for-one from the 2004 text.

The confidentiality reference illustrates the risk. The Internet Society guideline tells the liaison to give periodic reports to the Board consistently with RFC 3777’s confidentiality rules. The durable proposition is sensible: Board reporting must not expose candidate-specific information or NomCom deliberations. But a current instruction should identify the current confidentiality provision and explain the level at which reporting is permitted. “Process operating normally,” “a procedural concern was referred,” and “a dispute was resolved” are different from candidate assessments. The rule should mark that line.

The liaison-rules reference also needs a crosswalk. RFC 8713 states that the liaison represents organisational views, provides information, monitors process, escalates unresolved concerns and has no candidate-selection vote. Those are concrete functions. A policy that cites them by current section gives a future liaison, NomCom Chair and Board the same map.

Finally, the priority rule needs its own status. If the Board intends to retain it, the policy should say why it is consistent with RFC 8713 and whether it applies only to expression of a view or also to a procedural intervention. If the Board believes the current RFC’s no-conflict condition already limits the meta-rule, that limit should be written. If the priority was a 2012 solution to a problem that no longer exists, the Board should retire it explicitly rather than leaving a reader to decide.

None of these options requires a new account of past NomCom work. A prospective crosswalk can preserve the historical text and date the new interpretation.

Accountability does not require opening the candidate room

NomCom confidentiality is not a defect to be overcome by publishing more names. Candidates must be able to provide information, receive feedback and be assessed without a running public campaign. RFC 8713 also directs the process away from public statements of support or opposition. A governance repair that exposed candidate material would damage the institution it claims to improve.

The public object should therefore be a rule receipt, not a deliberation log.

The first part can be static. For every 2012 clause, list the current RFC 8713 section, the retained duty, any changed institutional term and the interpretation adopted by the Board. Mark the obsolete citation as historical. Record the 2012 adoption and 2026 reaffirmation as separate states.

The second part can be event-driven and deliberately sparse. If a future interpretation question reaches the NomCom Chair or the RFC dispute route, publish only an issue class, the roles involved in referral, the applicable provisions, the date and a disposition such as resolved, withdrawn or escalated. Do not identify a candidate, reproduce a view, describe a Board position on a person or reveal committee discussion.

That receipt would not let an outsider second-guess candidate selection. It would let the outsider verify that an institutional instruction was tested against the current process rule and that the correct route handled the question.

Thin governance is the appropriate design. Publish the minimum common state necessary to distinguish mandate, advice, oversight and selection. Keep confidential evidence confidential. Do not let secrecy about candidates become secrecy about the rule.

The missing principal problem is narrower here—and still instructive

Much Internet-governance criticism begins where “community” language substitutes for authorisation. This case is different in an important way. Internet Society’s guideline identifies the represented body. The liaison is not self-selected, and the policy does not pretend that participation alone creates the right to speak. In that sense, the rule is more disciplined than vague multi-stakeholder claims.

The discipline fails only if the identified mandate is allowed to float beyond its scope. Board consensus authorises the liaison to convey a Board view. It does not turn that view into NomCom consensus, give the liaison a vote or make the Board the principal of the IETF community. The IETF-best-interest duty protects the process from precisely that slide.

The written priority therefore deserves public precision, not rhetorical alarm. A liaison can be a faithful agent of the Board and a responsible participant in an IETF process only if the interface says what happens when those responsibilities point in different directions. “Best judgment” may be unavoidable at the moment of decision. It is not a substitute for a current rule, a referral route and an institutional interpretation.

The Board has already performed the act that makes the question timely. It reviewed the guideline and reaffirmed it without revision. The next act should be smaller: connect the text it kept to the BCP that now governs the room.

Sources

  1. Internet Society — Guidelines for the Board of Trustees liaison to the IETF Nomination Committee
  2. Internet Society — Resolution 2026-14, unanimous written consent
  3. RFC Editor — RFC 3777 information page
  4. RFC Editor — RFC 7437 information page
  5. RFC Editor — RFC 8713, current BCP 10 NomCom process
  6. Lu Heng — The Multi-Stakeholder Mirage