Thomas Narten (IBM)Harald
Alvestrand (Google)2008-05-202015-06-242008May
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
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 .
Prenons l'exemple du (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 à . 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 , qui
succède au , 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. ) 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 , 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 ( 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 .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 ()
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 (cf. , 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 (, 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 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 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 remplace le (et a lui-même
été remplacé depuis par le ). 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 . À
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.