Résumé

  • RFC 2860 consigne l’accord de mars 2000 sur le travail technique de l’IANA pour les protocoles relevant de l’IETF et de l’IRTF. Les RFC fixent d’abord les critères ; l’IESG guide les cas ambigus et l’IAB intervient dans les différends définis par le texte.
  • L’accord écarte les questions de politique relatives à l’attribution des noms de domaine et des blocs d’adresses IP, mais maintient certaines attributions techniques dans son champ. Il prévoit aussi des registres publics, des motifs techniques de refus, des recours et une résiliation avec préavis de six mois.

Analyse

Un recours suppose d’abord que la décision soit lisible. La section 4.5 de RFC 2860 demande une interface en ligne pour les requêtes de paramètres de protocole et une réponse dans un délai raisonnable : exécuter l’attribution ou la refuser pour non-conformité aux exigences techniques applicables. Le refus ne peut reposer que sur des motifs techniques légitimes. Pour un registre créé par une action de l’IETF, la demande rejetée peut être portée devant l’IESG, puis devant l’IAB selon la procédure de la section 4.2. Le texte décrit une voie de contestation ; il ne rapporte pas qu’un cas particulier l’ait empruntée.

Cette voie s’appuie sur une règle de départ. Selon la section 4.1, l’IANA attribue et enregistre les paramètres conformément aux critères et procédures des RFC : normes proposées, provisoires ou complètes, bonnes pratiques actuelles et tout autre RFC qui demande une attribution. En l’absence de critère, ou si le texte est ambigu, l’IANA poursuit la pratique traditionnelle, sauf instruction contraire de l’IESG. En cas de doute ou de différend technique, elle demande et suit les indications techniques de l’IESG ; celui-ci peut désigner un expert.

Les parties prévoient aussi d’élaborer les critères manquants au fil du temps, que l’IANA appliquera sur instruction de l’IESG.

Si le désaccord oppose l’IANA à l’IESG, la section 4.2 change de niveau : les deux cherchent l’avis de l’IAB, dont la décision est finale selon le mémorandum. Le document ne présente donc pas l’IESG comme arbitre de chaque conflit. Il distingue les questions ordinaires de critère, les désaccords techniques et le différend entre l’opérateur et l’organe qui le guide.

La transparence complète le recours. La section 4.4 demande que chaque attribution en vigueur, coordonnées du bénéficiaire comprises, soit publiée en ligne et gratuitement ; une attribution déjà publiée dans une RFC par l’éditeur des RFC répond à cette exigence. Cette règle donne au lecteur un point de vérification. Elle ne transforme pas la publication d’une valeur en preuve que toute demande voisine a été autorisée, ni ne dit à elle seule si une attribution contestée a été mise en œuvre.

La section 4.3 explique pourquoi le périmètre ne se résume pas à une liste de ressources. Les enjeux de politique liés à l’attribution des noms de domaine et des blocs d’adresses IP sont hors champ. Mais les noms utilisés pour le DNS inverse, les blocs spécialisés de multidiffusion ou de diffusion anycast, ainsi que les attributions expérimentales, restent soumis à la section 4 lorsqu’ils ne sont pas considérés comme des questions de politique. Si une politique d’ICANN empêchait le respect de ces règles pour ces cas, ICANN devait en informer l’IETF ; celui-ci pouvait alors résilier l’accord.

On peut donc parler d’une limite entre types de décision, pas d’une exclusion générale des noms ou des adresses.

Le contexte institutionnel est lui aussi borné. Publié en juin 2000 avec le statut Informational, RFC 2860 ne définit aucune norme Internet. Il reproduit le mémorandum signé le 1er mars par l’IETF et ICANN, puis ratifié par le conseil d’ICANN le 10 mars. Le texte indique que son objet exclusif est le travail technique de l’IANA pour les protocoles de l’IETF et de l’IRTF ; il reconnaît qu’ICANN peut fournir des services comparables à des registres hors de ce champ.

Deux articles complètent le circuit de décision. L’IANA peut occuper des sièges de liaison sans droit de vote dans certains comités de l’IETF et participer aux discussions sur les exigences techniques ; elle examine aussi les documents en dernière consultation publique pour signaler ses préoccupations à l’IESG. Pour les paramètres relevant principalement de l’IRTF, la section 5 substitue l’IRTF et l’IRSG à l’IETF et à l’IESG. Si la classification du paramètre est elle-même incertaine, l’IAB tranche.

Enfin, l’accord peut être modifié ou résilié d’un commun accord, ou résilié par l’une des parties avec un préavis d’au moins six mois. RFC 6220, publié en 2011, décrit plus tard les fonctions des opérateurs de registres de paramètres de l’IETF et rappelle que l’IETF conserve la responsabilité de la gestion de ses paramètres. Ce texte ultérieur éclaire la fonction d’opérateur ; il ne démontre pas que chaque détail de l’accord de 2000 est resté identique.

RFC 2860 établit une répartition écrite des tâches, des règles de publication et un chemin de contestation. Il ne prouve ni la conformité opérationnelle dans chaque dossier, ni l’issue d’un recours, ni l’autorité qui s’applique aux questions de politique laissées hors de son champ. Ces limites font partie du dossier, pas d’un détail à combler par supposition.

Sources

Le texte de référence est RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, notamment ses sections 1 à 5. Pour la description ultérieure du rôle des opérateurs de registres, voir RFC 6220.