Un certain nombre de fonctions
administrativo-politico-techniques dans l'Internet sont assurées
par un service nommé l'IANA
(Internet Assigned Numbers Authority). Cela va
du spectaculaire (l'instruction des demandes d'ajout ou de
suppression des TLD) jusqu'au routinier (la
gestion des innombrables registres techniques que l'IANA maintient
pour le compte de l'IETF). L'IANA est un
service de l'ICANN et l'ICANN est sous
tutelle du gouvernement états-unien pour effectuer ce travail, dit
« fonction IANA ». Le gouvernement états-unien a annoncé en 2014 qu'il
envisageait peut-être dans le futur de diminuer la dépendance de
l'ICANN et a demandé, en attendant, aux parties intéressées, de
soumettre des propositions. L'ICANN, toujours ravie qu'on propose
des discussions et des réunions, a créé le ICG (IANA stewardship
transition Coordination Group) qui a à son tour sollicité
des commentaires. Ce nouveau RFC est la
réponse de l'IETF à cet appel, ne concernant que la gestion des
registres techniques. La gestion des noms de
domaine et des adresses IP, bien
plus politicienne et bien plus brûlante (surtout pour les noms de
domaine) n'y
figure pas. Voici donc « la position de l'IETF concernant l'avenir
de la gestion des registres IANA, dans l'hypothèse où le
gouvernement états-unien relâcherait son emprise ». Pour résumer
cette position : la gestion des registres des paramètres des
protocoles fonctionne actuellement bien et, quelles que soient les
manœuvres autour de l'évolution du rôle du gouvernement US, il ne
faut pas la changer. Ce RFC a été terminé en janvier 2015 mais n'est
publié que maintenant, après l'approbation du plan de transition
par l'ICANN en mars 2016 à sa réunion de
Marrakech, et après l'accord du
gouvernement états-unien en août.
L'agence du gouvernement états-unien chargée de superviser
l'ICANN se nomme
NTIA,
dépendant du ministère du
commerce (notez la vision de l'Internet que cela implique). Notez que cette supervision n'est pas
le seul levier direct de ce gouvernement sur la gestion de
ressources critiques de l'Internet. Il y a aussi la gestion de la
racine du DNS, effectuée via
Verisign. En mars 2014, génée par les
révélations de Snowden, la NTIA a annoncé un projet d'évolution du statut de
l'ICANN, passant du gouvernement états-unien à quelque chose de
nouveau, encore à discuter. La NTIA a posé ses conditions (par
exemple que le quelque chose de nouveau ne devait pas être
multi-gouvernemental), et annoncé que, s'il n'y avait pas de plan
satisfaisant (satisfaisant pour la NTIA) proposé, le projet serait
abandonné ou redéfini.
C'est là qu'a été créé l'ICG (IANA Stewardship
Coordination Group) dont la charte figure en annexe B de
ce RFC. C'est cet ICG qui a émis l'appel aux commentaires (qui
figure en annexe C du RFC). Cet appel demande entre autre de
préciser si les réponses concernent la partie « noms de domaine »,
la partie « adresses IP » ou bien la partie « paramètres des
protocoles » du travail de l'IANA (ce RFC
concerne la troisième partie). Les réponses sont disponibles en ligne.
La section 2 de ce RFC est la réponse formelle de l'IETF,
suivant le plan de l'appel à commentaires de l'ICG. D'abord,
l'IETF répond à la question « l'IANA sert à quoi, pour vous ? »
Bien des protocoles conçus ou gérés par l'IETF ont besoin de
registres pour des paramètres du protocole. Par exemple, le
protocole HTTP (RFC 7231) a des codes de retour des
opérations (comme le célèbre 404) qui sont stockés
à l'IANA. Ajouter un tel code (par exemple 451 pour
« contenu censuré ») ne nécessite donc pas de modifier la norme HTTP.
Ou bien,
pour prendre un exemple nettement moins connu, le
protocole PCP (RFC 6887) dispose d'un certain nombre d'options, qui ne sont
pas fixées une fois pour toutes dans la norme mais sont notées
dans
un registre IANA, ce qui permet d'en ajouter facilement de
nouvelles.
Pour que l'Internet fonctionne, il faut que ces paramètres des
protocoles soient utilisés de la même manière par tous. Par
exemple, cela signifie que les développeurs de logiciels Internet
doivent utiliser les mêmes registres, en l'occurrence, ceux de
l'IANA. Ainsi, un serveur HTTP peut renvoyer le code 403 en
sachant bien que cela sera interprété par tous les clients comme
signifiant « Accès interdit », car le code 403 figure dans le
registre IANA avec cette définition. Ce rôle de l'IANA pour l'IETF
est documenté dans le RFC 5226.
L'IANA gère également le TLD
.arpa, qui est
considéré comme un des registres de paramètres (RFC 3172).
Ce travail de l'IANA pour le compte de l'IETF est effectué en
application du RFC 2860 (voir aussi ses
déclinaisons concrètes), qui est le
« contrat » entre les deux activités.
La question suivante est « qui êtes-vous ? »
L'IETF se présente donc,
SDO internationale, ouverte et dont la
mission est décrite dans le RFC 3935. L'IETF
fait les normes techniques de l'Internet « de la couche
3 jusqu'au bas de la couche
7 ». C'est elle qui est responsable
d'IP de BGP, du
DNS, de HTTP,
etc. (Oui, tous les lecteurs de ce blog savent cela mais la
réponse de l'IETF est conçue pour être lue par un public plus
large.) Le côté ouvert de l'IETF est précisé dans le RFC 6852, le processus de création des normes
dans le RFC 2026.
Une question difficile dans l'appel à commentaires était
« quels recouvrements y a-t-il entre votre activité et celles
d'autres organisations ou groupes ? » D'abord, la réponse met en
avant le fait que les participants à l'IETF sont souvent membres
d'autres organisations. (On parle de « participants » car l'IETF
n'a pas de mécanisme d'adhésion formel.)
Ensuite, l'IETF a évidemment des activités qui s'approchent de
très près de celles d'autres groupes, avec parfois des discussions
sur la frontière. Ainsi, le RFC 6761, qui
fait l'objet de beaucoup de débats en ce moment, prévoit un
mécanisme d'enregistrement de noms de domaine par l'IETF, alors
que certains voudraient que cela soit un monopole de
l'ICANN. C'est aussi le cas des adresses IP (mais cela suscite
bien moins d'intérêt car c'est plus important mais moins
spectaculaire). Ainsi, si l'IANA gère l'espace d'adressage IP, l'IETF alloue également des
portions de cet espace (RFC 7020, RFC 7249, et un exemple concret, les
ULA du RFC 4193). Il y
a aussi bien sûr des recouvrements envers ce que fait l'IETF, et le
travail des opérationnels qui décident (ou pas) de déployer les
protocoles normalisés. Par exemple, la gestion des
serveurs racine du DNS est à la fois un
secteur de l'IETF (RFC 7720) et des
opérateurs de ces serveurs.
Les activités de l'IETF concernant IP et
le routage l'amènent par contre du côté
des RIR (par exemple lorsque l'IETF a ses
propres allocations d'adresse, comme dans le RFC 6890). Un changement de norme technique peut impacter
les opérationnels (nouvelles choses à gérer) et les RIR. Ainsi,
l'extension de la taille des numéros d'AS
de deux à quatre octets (RFC 6793) imposait
évidemment aux RIR de changer leur logiciel et leur politique,
pour allouer ces nouveaux numéros.
Pour tous ces points, le RFC insiste sur l'importance de la
coordination entre ces acteurs, et sur les nombreux contacts que
l'IETF maintient avec toutes ces communautés.
L'appel à commentaires de l'ICG demande ensuite comment les
politiques sont décidées et comment les conflits sont gérés. Pour
l'IETF, les principes figurent dans les RFC 6220 et RFC 5226. En gros,
quelqu'un qui veut changer la politique de l'IETF, par exemple
modifier le RFC 5226 (c'est justement en
cours de discussion) va écrire un premier document, un
Internet Draft, essayer de susciter de
l'intérêt, en général le faire adopter par un des groupes de
travail (à moins qu'un groupe soit créé spécialement), la
proposition doit réunir un consensus (RFC 7282) et c'est
souvent l'IESG qui prend la décision
finale. Le tout est scandé par des last calls
où les organisateurs demandent aux participants un dernier avis
avant que le document n'avance. (Pour le fonctionnement des
groupes de travail, on peut lire le RFC 2418, mais il n'est plus complètement à jour.)
Et les conflits ? Ils sont normalement réglés dans les groupes
de travail mais, si c'est grave, la section 6.5 du RFC 2026 décrit un mécanisme d'appels successifs.
Un concept souvent cité en ce moment dans les discussions
autour de l'ICANN et celui de redevabilité
(accountability). L'organisation est-elle
redevable à quelqu'un, ou bien est-ce un clan mafieux fermé qui
décide de
tout en interne et ne rend de comptes à personne (comme le
CIO ou la
FIFA) ? L'appel à commentaires demande donc
de la documentation sur les mécanismes de redevabilité du
répondeur. Pour l'IETF, c'est l'IAB qui
joue ce rôle, en confirmant (ou pas) les nominations et en
traitant les appels mentionnés un peu plus haut. C'est aussi l'IAB
qui gère les canaux de communication (liaisons)
avec les autres organisations. Et c'est l'IAB qui décide quel
opérateur gère les registres de paramètres de protocole,
actuellement l'ICANN via sa fonction IANA. L'IAB est
officiellement décrite dans le RFC 2850. Elle est elle-même redevable devant les
participants à l'IETF, par son mécanisme de désignation (RFC 3777).
Quel est le degré de formalisation de votre relation avec
l'IANA, demande ensuite l'appel à commentaires ? Un
MoU existe (RFC 2860). Son suivi quotidien est assuré par l'IAD
(IETF Administrative Director), lui-même sous
contrôle de l'IAOC (IETF Administrative Oversight
Committee, cf. RFC 4071). Une de
leurs tâches est de suivre les rapports de l'IANA
sur ses résultats.
En théorie, si un conflit grave surgissait entre l'IETF et
l'IANA, l'IETF pourrait mettre fin au travail en commun et choisir
un nouvel opérateur pour ses registres (et ce RFC serait alors
sans objet). Mais cela ne s'est jamais
produit et une telle perspective semble peu probable.
L'appel à commentaires demande aussi à ceux qui répondent
d'indiquer de quelle juridiction ils dépendent et quelles sont
les lois qui leur sont applicables. L'IETF répond que son activité
est mondiale (ce qui est vrai) et que les textes entre l'IANA et
l'IETF ne spécifient pas de juridiction (ce qui est exact mais
incomplet : l'IETF étant une activité de
l'ISOC, l'IETF dépend de la juridiction
états-unienne, comme le montrent, par exemple, les injonctions reçues).
Commencent ensuite les questions sensibles, par exemple les
demandes de suggestions concernant les mécanismes futurs qui
remplaceraient la NTIA. La réponse du RFC est qu'aucun changement
n'est demandé par l'IETF : le système actuel avec l'IETF, l'ICANN,
l'IAB, etc, a bien fonctionné, sans implication du NTIA, et n'a
donc aucun besoin d'être remplacé ou « amélioré ». Les RFC 2860 et RFC 6220
fournissent un cadre satisfaisant et le résultat l'est également.
Cette partie de la réponse contient quand même quelques
souhaits, pas forcément de changement mais de points importants à
garder en tête :
- Les registres des paramètres de protocole sont dans le
domaine public (ils sont un « bien
commun ») et doivent le rester, quels que soient les changements
futurs.
- S'il y a un changement, il faudra que l'ICANN et le nouvel
opérateur travaillent ensemble à rendre la transition la plus
invisible possible.
Et le RFC réaffirme les
principes
que l'IAB avait posé en mars 2014 :
- La « communauté technique Internet » se débrouille très
bien à l'heure actuelle et n'a pas besoin d'intervention
extérieure.
- L'enregistrement des paramètres techniques des protocoles
doit reposer sur l'ouverture, la transparence et la
redevabilité.
- Tout changement devrait respecter les textes et les
accords existants (jolie façon de dire qu'aucun changement n'est
souhaité).
- Les registres des paramètres techniques des protocoles et
les autres registres (comme les RIR pour
les adresses IP) sont essentiels, et fonctionnent aujourd'hui
correctement.
- L'IETF va continuer dans son rôle.
- La gestion des registres des paramètres techniques est un
service public.
J'avais signalé plus haut que la NTIA avait posé un certain
nombre d'exigences pour accepter un éventuel plan de
transition. La suite de l'appel à commentaires rappelle ces
exigences et demande dans quelle mesure les propositions faites
sont conformes à ces oukases. D'abord, la NTIA demande de
« continuer avec le modèle multi-partiesprenantes » (ne me
demandez pas de définir ce modèle...) L'IETF répond qu'en tant
qu'organisation ouverte à tous, elle suit déjà ce modèle (même
réponse à la demande de la NTIA que le futur éventuel système
« conserve l'ouverture de l'Internet »). Ensuite,
la NTIA exige de préserver « la sécurité et la stabilité du
DNS » (une des phrases les plus citées dans
les milieux de la gouvernance Internet...)
L'IETF ne proposant pas de changement, la stabilité est
certainement préservée. Puis le gouvernement états-unien veut que
les propositions « satisfassent les utilisateurs et répondent à
leurs besoins ». Le RFC estime que l'utilisation massive dans le
monde des protocoles TCP/IP et donc des
registres de l'IANA montre clairement que les utilisateurs sont
contents. Dernier ordre de la NTIA : que la solution future ne
soit pas multi-gouvernementale (rappelons que le mécanisme actuel
de supervision de l'ICANN est mono-gouvernemental). L'IETF
réplique que l'IAB n'est pas une
organisation gouvernementale et que l'ordre est donc suivi.
L'appel à commentaires de l'ICG demande également par quel
processus la réponse a été élaborée, une bonne façon de vérifier
que le répondant a appliqué ses beaux principes, y compris lors de
la conception de sa réponse. L'IETF explique que la réponse a été
développée par le groupe de travail
IANAPLAN, qui, comme tous les groupes de travail de l'IETF,
était ouvert à tous et faisait tout son travail publiquement
(cf. les archives de la liste de diffusion du
groupe). Pour le montrer, comme le demande l'appel à
commentaire, l'IETF cite de nombreux documents publiquement
accessibles :
Le RFC estime que tout ce processus montre un net consensus de
l'IETF en faveur de cette réponse. Quelques points sont restés
contentieux jusqu'au bout (comme la demande que le nom de domaine
iana.org soit transféré à l'IETF Trust).
Quelques lectures supplémentaires sur cette opération de
transition :
