The Daily Resolver beta Resolving your questions about internet policy All content based on publicly available sources. Any views or opinions expressed on this website are those of the administrator and do not reflect the official position of any agency or employer. IETF & ICANN · live 17 Sep 2026
Select a column to widen it

Blog

IETF and ICANN, newest first

IETF

The IETF writes the technical standards the internet runs on — TLS, HTTP, DNS, email, routing. The below descriptions of IETF working groups attempt to summarize their work and implementation considerations should they produce a standard that is widely adopted.

How the process works

What a working group is

A group chartered to solve one defined problem, then closed when it is done. It lives on a public mailing list, is run by volunteer chairs, and answers to an Area Director. The three meetings a year are useful, but the decisions happen on the list.

How things get decided

By rough consensus rather than voting. Chairs judge whether objections have been addressed, not whether more people said yes. That means a well-argued technical objection from one person can hold up work, and that a company cannot outvote anyone.

How a document becomes a standard

  1. Internet-Draft. Anyone can publish one. It expires after six months unless revised, and carries a version number like -03.
  2. Adoption. The working group takes it on and it is renamed draft-ietf-. This is the point at which it becomes the group's document rather than the author's.
  3. Working Group Last Call. A fixed window for final objections. The most useful moment to intervene, and the one this site tracks most closely.
  4. IESG review. The steering group reviews it across all areas. Objections here are usually about consistency with other work.
  5. RFC Editor. Editing and publication. Can take months with no substantive change.
  6. RFC. Published with a permanent number. Note that an RFC is not law: nobody is obliged to implement one, and adoption is decided by the market.

Words you will see

areaOne of seven subject groupings — security, routing, transport and so on — each run by Area Directors.
BOFA birds-of-a-feather session: an exploratory meeting held before a working group exists, to see whether there is interest and agreement.
rough consensusNot unanimity and not a majority. The chairs' judgement that the remaining disagreement has been fairly heard and addressed.
hybrid key exchangeCombining a classical and a post-quantum algorithm so the result holds if either one survives. Appears across TLS, PKI, SSH and IPsec work.
harvest now, decrypt laterTraffic captured today and stored, to be decrypted once a quantum computer exists. The reason post-quantum deadlines are earlier than they look.
MLSMessaging Layer Security, RFC 9420. Group key agreement for end-to-end encrypted messaging, and the layer most interoperability work assumes.
YANG moduleA machine-readable schema describing what a network device exposes to a management system. The unit of standardisation across most operations groups.
HTTP message signaturesRFC 9421. Signing chosen parts of an HTTP request so a receiver can verify its origin and integrity. Used by both bot authentication and workload identity work.
selective disclosureRevealing part of a credential without revealing the rest — proving you are over 18 without showing a date of birth.

Working group outputs can impact different types of businesses in different ways. The below outlines potential impacts to certain business sectors, focusing on 1) standards a business may need to implement, and 2) new concepts a business should understand.

Participation in the IETF varies significantly between companies. Below are some data points providing information about how certain companies participate.

How a company shows up

Chair and area-director seats

Organisation profiles

Sources. Chair and AD rosters, draft author affiliations, meeting registration lists and IPR disclosures — all published by the IETF. A large share of participants use personal email addresses, so affiliation is assisted by a reviewed alias table rather than resolved automatically.
About this summary. Group names, acronyms, areas, document states and Last Call status come from the live Datatracker and refresh on their own. The briefs are written by hand from Datatracker research, and each one carries the date its facts were last checked — the prose cites revision numbers and document states, and those go stale between checks. ICANN policy processes, implementation projects and their expected completion dates are from ICANN's Implementing Policy page, checked 16 Sep 2026. Participation figures on the Company data tab are placeholder content showing the shape of the product.

ICANN

ICANN coordinates the domain name system: which top-level domains exist, who runs them, and the rules registries and registrars must follow. Unlike the IETF, its output is binding — policy takes effect through the contracts that registries and registrars sign.

How the process works

Who makes the policy

A community of organised groups rather than individuals. Generic domains are handled by the GNSO, which is split into a Contracted Parties House (registries and registrars) and a Non-Contracted Parties House (business, intellectual property, non-commercial). Country codes sit with the ccNSO. Governments advise through the GAC, and security specialists through the SSAC.

What a working group is here

Usually a Policy Development Process, or PDP: a chartered group working to a defined question, often with representative membership rather than open participation, meeting weekly or more. Slower and more formal than the IETF, and far fewer of them run at once.

How a policy becomes an obligation

  1. Issue Report. Staff scope the question and the Council decides whether to start a process.
  2. PDP working group. The chartered group deliberates, publishes an Initial Report and takes public comment.
  3. Final Report. Recommendations with the level of consensus recorded for each one.
  4. Council and Board. The GNSO Council votes, then the ICANN Board adopts.
  5. Implementation Review Team. Volunteers work with staff to turn recommendations into contract language. This is the last point at which requirements can still be shaped, and it is open to anyone who turns up.
  6. Effective date. Contracted parties get a notice window, usually at least six months, then compliance is enforceable.

Words you will see

consensus policyA policy that becomes binding through the registry or registrar agreement. There is no opting out.
contracted partyA registry operator or accredited registrar — the organisations ICANN can actually oblige to do something.
EPDPAn expedited policy process, used when something needs settling faster than the standard route allows.

Open policy development at ICANN, plus the standing bodies whose output tends to become policy later. Far fewer moving parts than the IETF, and each one lands directly on a contract.

After a policy has been adopted by the ICANN Board, it is implemented by ICANN staff. Below are policies still in the implementation stage.

About this column. Policy processes, implementation projects and expected completion dates are from ICANN's Implementing Policy page, checked 16 Sep 2026. Write-ups and participation figures are placeholder content.

All content based on publicly available sources. Any views or opinions expressed on this website are those of the administrator and do not reflect the official position of any agency or employer.