Summary

  • RFC 2860 records a March 2000 IETF–ICANN memorandum that confines its subject to IANA’s technical work for IETF and IRTF protocols. It gives RFC procedures priority, sends ambiguity to the IESG, and sends IANA–IESG disputes to the IAB.
  • The memorandum excludes policy issues in domain-name and IP-block assignments, not every technical assignment involving those spaces. It also requires public assignment information, a request facility, technical grounds for denial, an appeal route, and a six-month cancellation option.

Analysis

Section 4.3 draws a line, then immediately shows why the line cannot be reduced to “DNS and addresses are outside.” Policy issues in assigning domain names and IP address blocks are outside the memorandum. Yet inverse-DNS names, specialised multicast or anycast blocks, and experimental assignments remain subject to Section 4 when they are not treated as policy issues. If an ICANN policy were to prevent compliance for those specified technical assignments, the text requires notice to the IETF and allows the IETF to cancel the memorandum. The boundary is about the character of the question, not simply the object being assigned.

That distinction sits inside an agreement with a deliberately limited purpose. RFC 2860 is Informational; it says it does not specify an Internet standard. It places on record a memorandum signed by the IETF and ICANN on 1 March 2000 and ratified by the ICANN Board on 10 March. The memorandum says it defines the technical work IANA performs on behalf of the IETF and IRTF. It also recognises that ICANN may provide similar services for registries created outside IETF or IRTF action. The same name therefore does not imply one universal assignment mandate.

For protocols within IETF scope, Section 4.1 makes RFCs the first source of criteria and procedure. The list is broad: Proposed, Draft and full Internet Standards, Best Current Practice documents, and any other RFC that calls for an IANA assignment. When a document supplies no rule, or leaves ambiguity, IANA continues traditional practice unless the IESG directs otherwise. In doubt or technical dispute, IANA seeks and follows technical guidance from the IESG; where appropriate, the IESG can appoint an expert. The parties also undertake to develop missing criteria over time, which IANA adopts when instructed by the IESG.

Section 4.2 handles the next conflict rather than pretending the first path always settles it. A technical dispute between IANA and the IESG goes to the IAB, whose decision is final under the memorandum. Sections 4.4 and 4.5 make the process inspectable from outside: current assignment information, including assignee contact details, must be online and free; a public online facility must accept requests; assignments should be executed or denied promptly against applicable technical requirements; denial is limited to legitimate technical grounds. For an IETF-scope registry, a denied request can be appealed to the IESG and then the IAB.

These provisions describe a route through a decision. They do not prove how often it was used or what any particular appeal would decide.

The agreement adds two quieter forms of participation. Under Section 4.6, IANA receives non-voting liaison seats on appropriate IETF committees as the IETF determines, and may join discussions about technical assignment requirements. Under Section 4.7, IANA reviews IETF Last Call documents for issues of concern and raises them with the IESG. That gives the operator a channel to surface implementation and registry concerns while leaving the IETF to set the criteria and instructions described elsewhere in the text.

Section 5 carries a parallel procedure into the IRTF: for parameters principally related to research, the IRTF and IRSG stand in for the IETF and IESG. If the classification itself is disputed, the IAB decides whether the parameter relates principally to one side or the other. The memorandum’s architecture is therefore not a single chain of command for all registries; it is a scoped process with a rule for deciding which process applies.

The exit provision is part of that architecture. The memorandum remains effective until the parties mutually modify or cancel it, or either party cancels it with at least six months’ notice. That clause gives the technical arrangement a defined way to change without implying that a cancellation occurred. RFC 6220, published in 2011, later describes delegated operators for IETF protocol-parameter registries and says the IETF retains authority and responsibility for managing its protocol parameters. It is useful as a later description of the operator role, not proof that every 2000 arrangement remained unchanged.

The documents establish the assigned work, stated boundary, escalation path and publication duties. They do not establish operational compliance, a specific assignment outcome, or who governed the policy questions Section 4.3 excludes. Reading the memorandum closely is valuable precisely because it keeps those claims apart.

Sources

The primary record is RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, especially Sections 1–5. The later role description is RFC 6220, Defining the Role and Function of IETF Protocol Parameter Registry Operators. RFC 2860’s publication status and its account of the signing and ratification dates are stated in the RFC itself.