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. Même
chose pour les types de média du RFC 6838, qui ont leur propre
registre. 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 contenues
dans la section IANA Considerations d'un RFC. C'est
cette section qui est décrite ici. Ce RFC remplace l'ancien RFC 5226.
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 and 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.
».
L'intérêt d'avoir une section obligatoire IANA
Considerations est de concentrer en un seul endroit les
informations nécessaires à l'IANA pour faire son travail. Pour aider les auteurs de RFC à
écrire correctement cette section IANA
Considerations, notre RFC 8126, qui succède au
RFC 5226, pose quelques règles.
La section 1 du RFC décrit 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 1).
Cette même section 1 résume les points essentiels que doit
connaitre l'auteur d'un RFC, notamment d'avoir une section dédiée
IANA Considerations, et de n'y mettre que ce qui
est strictement nécessaire à l'IANA (pas de digressions, pas de
détails techniques).
La section 2 est consacrée à la création d'un nouveau registre. Il
y a bien des décisions à prendre à ce stade. Par exemple, notre RFC
recommande de voir si on ne peut pas faire un registre arborescent, où
l'action de l'IANA se limiterait à la racine de ce registre, diminuant
ainsi sa charge de travail. (C'est le cas des
URN du RFC 8141.)
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 qui explique
les politiques possibles :
- 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 aussi le cas des
plans d'URI provisoires (RFC 7595) ou des états de traitement du courrier (RFC 6729). C'est sans doute la plus
« libérale » des politiques d'enregistrement. (Il n'y a pas de
mécanisme explicite contre les vilains qui enregistreraient plein de
valeurs inutiles, avait noté l'examen
de sécurité.)
- Examen par un expert (« Expert review »),
comme détaillé plus bas (section 5 du RFC). C'est ainsi
que sont gérés les plans des URI permanents du RFC 7595, ou bien les types de méthode
d'EAP
(RFC 3748, sections 6 et 7.2,
notez que Expert review était appelé
Designated expert à cette époque).
- 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 »). Il faut en outre un examen par un expert, comme
dans la politique ci-dessus, l'expert vérifiant que la spécification
est claire. Les profils de ROHC (RFC 5795)
sont enregistrées sous cette condition. Les utilisations de certificat
de DANE (RFC 6698,
section 7.2) sont
« RFC nécessaire ».
- 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.
- Utilisation privée (« Private use ») est une
politique possible, qui est en fait l'absence de registre, et donc
l'absence de politique de registre : chacun utilise les valeurs qu'il
veut. Par exemple, dans le protocole TLS (RFC 5246, section 12), les valeurs 224 à 255 des identifiants
numériques du type de certificat sont à usage
privé ; chacun s'en sert comme il veut, sans coordination.
- Utilisation à des fins expérimentales (« Experimental
use »), est en pratique la même chose que l'utilisation
privée. La seule différence est le but (tester temporairement une
idée, cf. RFC 3692). C'est le cas des valeurs des en-têtes
IP du RFC 4727.
- Et il existe encore l'approbation
par l'IESG (« IESG approval ») qui est la politique de dernier
recours, à utiliser en cas de cafouillage du processus.
- Et le cas un peu particulier de l'allocation hiérarchique
(« Hierarchical allocation ») où l'IANA ne gère que
le registre de plus haut niveau, selon une des politiques ci-dessus,
déléguant les niveaux inférieurs à d'autres registres. C'est le cas
par exemple des adresses
IP ou bien sûr des noms de domaine.
Le choix d'une politique n'est pas évident : elle ne doit pas être
trop stricte (ce qui ferait souffrir les auteurs de protocoles,
confrontés à une bureaucratie pénible) mais pas non plus trop laxiste
(ce qui risquerait de remplir les registres de valeurs inutiles, les
rendant difficilement utilisables). En tout cas, c'est une des
décisions importantes qu'il faut prendre lors de l'écriture d'une spécification.
Notre RFC conseille (sans l'imposer) d'utiliser une de ces
politiques (« well-known policies »). Elles ont été
testés en pratique et fonctionnent, concevoir une nouvelle politique
fait courir le risque qu'elle soit incohérente ou insuffisamment
spécifiée, et, de toute façon, déroutera les lecteurs et l'IANA, qui
devront apprendre une nouvelle règle.
Parmi les autres points que doit spécifier le RFC qui crée un nouveau
registre, le format de celui-ci (section 2.2 ; la plupart des
registres sont maintenus en
XML, mais même dans ce cas, des détails de syntaxe, comme les
valeurs acceptables, peuvent devoir être précisés). Notez que le
format n'est pas forcément automatiquement vérifié par l'IANA.
Notre RFC recommande également de bien préciser si le
registre accepte des caractères non-ASCII
(cf. RFC 8264, section 10).
Autre choix à faire dans un registre, le pouvoir de changer les
règles (change control). Pour des normes IETF (RFC
sur le chemin des normes), c'est en général l'IETF qui a ce pouvoir,
mais des registres IANA peuvent être créés pour des protocoles qui ne sont
pas gérés par l'IETF et, dans ce cas, le pouvoir peut appartenir à une
autre organisation. C'est ainsi que les types de données
XML (RFC 7303), comme le
application/calendar+xml (RFC 6321) sont contrôlés par le W3C.
La section 3 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...)
La section 6 donne des noms aux différents états d'enregistrement
d'une valeur. Le registre note l'état de chaque
valeur, parmi ces choix :
- Réservé à une utilisation privée,
- Réservé à une utilisation expérimentale,
- Non affecté (et donc libre),
- Réservé (non alloué mais non libre, par exemple parce que la
norme a préféré le garder pour de futures extensions),
- Affecté,
- Utilisation connue, mais non officiellement affecté, ce qui se
produit parfois quand un malotru s'approprie des valeurs sans passer
par les procédures normales, comme dans le cas du RFC 8093.
Par exemple, si on prend les types de messages
BGP, on voit dans
le
registre que 0 est réservé, les valeurs à partir de 6 sont
libres, les autres sont affectées (1 =
OPEN, etc).
La section 5 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, leur nom est noté à côté de celui du registre). Par exemple, pour le registre des langues, défini par le RFC 5646, 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 5.1 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 5.3, chose qui est loin d'être toujours faite).
Enfin, diverses questions sont traitées dans la section 9, 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 8126 prévoit une
procédure d'appel, décrite en section 10. Cela
n'a pas suffit à régler quelques cas pénibles comme l'enregistrement de CARP.
Ce RFC 8126 remplace le RFC 5226. Les principaux
changements sont détaillés dans la section 14.1 :
- Moins de texte normatif style RFC 2119,
puisqu'il ne s'agit pas de la description d'un protocole,
- Meilleure description des registres hiérarchiques,
- Ajout d'une partie sur le pouvoir de changer les règles
(change control),
- Ajout de la possibilité de fermer un registre,
- Ajout de la section 8 sur le cas de RFC qui remplacent un RFC
existant,
- Etc.
Notez que notre RFC est également complété
en ligne par
des informations
plus récentes.
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. La « fonction IANA » (création et gestion
de ces registres) est formellement nommée IFO (IANA Functions
Operator) ou IPPSO (IANA Protocol Parameter
Services Operator) mais tout le monde dit simplement « IANA ».
