Mon blog

Un aspect peu connu du travail de normalisation est la nécessité de tenir des registres de certains paramètres, lorsque la liste de ces derniers n'est pas fixée dans un RFC. Par exemple, les algorithmes publiés dans le DNS pour IPsec ne sont pas définis de manière limitative dans le RFC 4025 mais sont enregistrés dans un registre public. Pour les RFC, ces registres sont tenus par l'IANA. Celle-ci ne décide pas quels registres elle doit tenir ni à quelle condition un nouveau paramètre peut y rentrer, elle applique les décisions contenus dans la section IANA Considerations d'un RFC. C'est cette section qui était décrite ici. Ce RFC a depuis été remplacé par le RFC 8126.

Prenons l'exemple du RFC 3315 (DHCP). Sa section 24 contient le texte This document defines several new name spaces associated with DHCPv6 and DHCPv6 options: - Message types - Status codes - DUID - Option codes IANA has established a registry of values for each of these name spaces, which are described in the remainder of this section. These name spaces will be managed by the IANA and all will be managed separately from the name spaces defined for DHCPv4.. En application de ce texte, l'IANA a créé le registre DHCPv6 and DHCPv6 options qu'on peut consulter en ligne à https://www.iana.org/assignments/dhcpv6-parameters. Et comment ajoute-t-on des entrées dans ce registre ? En suivant les règles données dans ce même RFC : New DHCP option codes are tentatively assigned after the specification for the associated option, published as an Internet Draft, has received expert review by a designated expert [11]. The final assignment of DHCP option codes is through Standards Action, as defined in RFC 2434 [11]. .

Pour aider les auteurs de RFC à écrire correctement cette section IANA Considerations, notre RFC 5226, qui succède au RFC 2434, pose quelques règles.

Les sections 1 et 2 du RFC décrivent le problème général de la gestion d'un espace de nommage (namespace). Tous ces espaces n'ont pas les mêmes caractéristiques. Certains sont très petits (le champ protocole, qui n'a que huit bits soit 256 valeurs possibles, cf. RFC 5237) et doivent donc être gérés avec prudence, certains sont hiérarchiques comme le DNS ou comme les OID et peuvent donc être délégués, certains sont immenses, et peuvent être gérés avec moins de précautions (mais nécessitent quand même des règles, comme expliqué dans la section 2).

La section 3 décrit le rôle des experts sur lesquels doit parfois s'appuyer l'IANA. Certains registres nécessitent en effet un choix technique avec l'enregistrement d'un nouveau paramètre et l'IANA n'a pas forcément les compétences nécessaires pour cette évaluation. Elle délègue alors cette tâche à un expert (designated expert). Par exemple, pour le registre des langues, défini par le RFC 4646, l'expert actuel est Michael Everson. Ce registre utilise également une autre possibilité décrite dans cette section, une liste de discussion qui sert à un examen collectif des requêtes (pour le registre des langues, cette liste est ietf-languages@iana.org). La section 3 discute des autres choix qui auraient pu être faits (par exemple un examen par le groupe de travail qui a créé le RFC, ce qui n'est pas possible, les groupes de travail IETF ayant une durée de vie limitée). Elle explique ensuite les devoirs de l'expert (comme la nécessité de répondre relativement rapidement, section 3.3, chose qui est loin d'être toujours faite).

La section 4 est consacrée à la création d'un nouveau registre. Si un RFC doit demander une telle création, il doit préciser quelle politique d'enregistrement devra suivre l'IANA. C'est une des parties les plus intéressantes du RFC, notamment sa section 4.1 qui explique les politiques possibles, par exemple :

• Allocation hiérarchique (« Hierarchical Allocation »), où l'IANA ne délègue que les noms de plus haut niveau, laissant d'autres registres allouer les nouveaux inférieurs. C'est le cas par exemple des adresses IP.
• Premier Arrivé, Premier Servi (« First Come First Served »), où toute requête est acceptable et est faite dans l'ordre d'arrivée. Les entrées dans le préfixe OID iso.org.dod.internet.private.enterprise sont un bon exemple (https://www.iana.org/assignments/enterprise-numbers mais attention, le registre est lourd à charger). C'est sans doute la plus « libérale » des politiques d'enregistrement.
• Examen par un expert (« Expert review »), comme indiqué plus haut. C'est ainsi que sont gérés les plans des URI permanents du RFC 7595.
• Spécification nécessaire (« Specification required ») où un texte écrit et stable décrivant le paramètre souhaité est nécessaire (ce texte n'est pas forcément un RFC, il y a d'ailleurs une politique « RFC required »). Les profils de ROHC (RFC 5795) sont enregistrées sous cette condition.
• Examen par l'IETF (« IETF Review »), l'une des plus « lourdes », puisqu'il faut un RFC « officiel », qui soit passé par l'IESG ou par un groupe de travail IETF (tous les RFC ne sont pas dans ce cas, certains sont des contributions individuelles). C'est la politique des extensions TLS du RFC 6066 (cf. RFC 5246, section 12, qui utilisait encore l'ancien terme de « IETF Consensus »).
• Action de normalisation (« Standards Action »), encore plus difficile, le RFC doit être sur le chemin des normes et donc avoir été approuvé par l'IESG. C'est le cas par exemple des types de message BGP (RFC 4271, section 4.1), en raison de la faible taille de l'espace en question (un seul octet, donc un nombre de valeurs limité) et sans doute aussi en raison de l'extrême criticité de BGP. C'est aussi la politique pour les options DHCP données en exemple plus haut.
• Et il existe encore l'approbation par l'IESG qui est la politique de dernier recours, à utiliser en cas de cafouillage du processus.

Parmi les autres points que doit spécifier le RFC qui crée un nouveau registre, le format de celui-ci (section 4.2). À noter que l'IANA n'utilise pas d'outils pour tester ce format (les registres IANA étaient de simples fichiers texte, maintenus avec un éditeur ordinaire mais ont migré pour la plupart vers XML, depuis la publication de ce RFC) et que des erreurs de syntaxe sont parfois apparues dans des registres.

La section 5 couvre l'enregistrement de nouveaux paramètres dans un registre existant. C'est elle qui précise, entre autres, que l'IANA ne laisse normalement pas le choix de la valeur du paramètre au demandeur (mais, en pratique, l'IANA est sympa et a accepté beaucoup de demandes humoristiques comme le port TCP n° 1984 pour le logiciel Big Brother...)

Enfin, diverses questions sont traitées dans la section 6, comme la récupération de valeurs qui avaient été affectées mais qui ne le sont plus (le RFC 3942 l'avait fait mais c'est évidemment impossible dès que les paramètres en question ont une... valeur, ce qui est le cas entre autres des adresses IP).

Bien que la plupart des allocations effectuées par l'IANA ne sont guère polémiques (à l'exception des noms de domaine et des adresses IP, qui sont des sujets très chauds), notre RFC 5226 prévoit une procédure d'appel, décrite en section 7. Cela n'a pas suffit à régler quelques cas pénibles comme l'enregistrement de CARP.

Ce RFC 5226 remplace le RFC 2434 (et a lui-même été remplacé depuis par le RFC 8126). Les principaux changements sont détaillés dans la section 10. Par exemple, le terme de propagande IETF Consensus a été remplacé par le plus neutre IETF Review. (Les organisations qui parlent de leur consensus policy le font en général pour faire taire les critiques, en prétendant que tout le monde est d'accord.) Les changements sont en général de simples clarifications, le nouveau RFC étant plus directif que l'ancien. Les autres changements sont souvent l'ajout de questions nouvelles, comme la récupération de valeurs qui avaient été allouées.

Les relations entre l'IETF et l'IANA sont fixées par le MOU contenu dans le RFC 2860. À noter que tout n'est pas couvert dans ce RFC, notamment des limites aux demandes de l'IETF. Que se passerait-il par exemple si l'IETF demandait à l'IANA, qui ne facture pas ses prestations, de créer un registre de milliards d'entrées, très dynamique et donc très coûteux à maintenir ? Pour l'instant, l'IANA ne peut pas, en théorie, le refuser et la question s'est parfois posée à l'IETF de savoir si tel ou tel registre n'était pas trop demander.

Puisque l'IANA est un acteur important de l'Internet, rappelons aussi que, bien que la fonction de l'IANA soit actuellement assurée par l'ICANN, la tâche de gestion des protocoles et des registres n'a rien à voir avec les activités, essentiellement politiciennes, de l'ICANN.