Mon blog

Bien des protocoles réseaux nécessitent l'allocation de nombres particuliers, un numéro de protocole, une valeur pour une option, etc (ce que ce RFC nomme des « code points »). Cette allocation est typiquement stockée dans un registre IANA. Lorsque l'allocation nécessite un examen formel par l'IETF ou un de ses groupes et comités, un problème d'œuf et de poule surgit : pour avoir l'allocation du nombre, il faut un document, par exemple un RFC mais pour publier ce document, il faut une allocation du nombre. Pour briser ce cercle vicieux, ce RFC, héritier du RFC 4020, expose les règles selon lesquelles l'IANA peut allouer un nombre avant une publication formelle d'une norme.

Les politiques d'allocation de nombres et autres code points à l'IETF sont exposées dans le RFC 5226. Dans certains cas, le problème ne se pose pas. Par exemple, la politique PAPS « Premier Arrivé, Premier Servi » (First come, first served), où toute requête est acceptable et est faite dans l'ordre d'arrivée, ne nécessite pas de document publié et peut donc se faire sans tambours ni trompettes. Même chose pour « Examen par un expert » (Expert review). Par contre, certaines politiques sont plus restrictives, par exemple parce que l'espace de nommage utilisé est très étroit et qu'il faut l'utiliser prudemment. La politique « Examen par l'IETF » (IETF review) impose par exemple un RFC et pas n'importe lequel. La politique « Action de normalisation » (Standards action) impose en outre que ce RFC soit sur le « chemin des normes ». Dans ces deux cas, on a le problème d'œuf et de poule mentionné plus haut. Parfois, les auteurs d'un protocole résolvent le problème « à la rache » en s'attribuant d'autorité un numéro qui leur semble libre et en l'utilisant dans le futur RFC... et dans des mises en œuvre du protocole qui sont testées sur le réseau. Si l'IANA choisit ensuite d'allouer un autre numéro au moment de la normalisation, des ennuis sans nombre vont surgir. Par exemple, les premières mises en œuvre n'interagiront pas avec celles qui ont été faites après la normalisation.

Faut-il taper sur ces auteurs trop pressés ? Non, car ce n'est pas entièrement de leur faute : le processus de normalisation est long, très long, et on ne peut pas décemment leur reprocher d'avoir voulu essayer leur nouveau jouet à l'avance. En outre, c'est dans l'intérêt général que les nouveaux protocoles soient testés pour de bon, avant la publication officielle de la norme. Cela permet d'éliminer les mauvaises idées au feu de la réalité. Cette importance donné aux « programmes qui marchent » (running code) est justement un des points qui a assuré le succès de l'IETF face à des SDO concurrentes. D'ailleurs, les règles de certains groupes à l'IETF imposent ce déploiement avant la normalisation (voir par exemple le RFC 4794 qui a remplacé le RFC 1264, qui était encore plus radical).

Donc, puisque ces allocations précoces (early allocations) sont une bonne chose, quelles règles doivent-elles suivre ? La section 2 de notre RFC impose que toutes ces conditions soient remplies avant qu'une allocation précoce soit acceptée :

• La politique d'allocation pour l'espace de nommage considéré doit être « Norme nécessaire » (si cette norme est un RFC), « RFC obligatoire », « Examen par l'IETF », ou « Action de normalisation ». (La liste de ces politiques était bien plus courte dans le RFC 4020.)
• Un document Internet-Draft doit exister, décrivant le protocole ou le système qui a besoin de cette allocation. Rappelons qu'un Internet-Draft ne nécessite pas d'autorisation et peut être publié sans formalités.
• La spécification dans cet Internet-Draft doit être stable, le protocole ne doit plus changer de manière incompatible (ce qui nécessiterait d'allouer un nouveau numéro après).
• Les présidents du groupe de travail et les directeurs de zone d'activité IETF doivent approuver cette allocation, en prenant en compte l'intérêt de la communauté pour ce nouveau protocole.

C'est contraignant, mais le but est d'éviter les abus qui mèneraient à un épuisement rapide d'un des registres IANA (cf. section 5).

Une fois ces prérequis rassemblés, les auteurs de l'Internet-Draft font une requête à l'IANA. Celle-ci alloue le nouveau numéro ou code point, et le marque comme Temporaire, en indiquant la date. En effet, une allocation précoce n'est valable qu'un an. Au bout d'un an, elle doit avoir été transformée en allocation ferme, ou bien renouvelée en répétant tout le processus. Sinon, elle sera marquée comme expirée (pas de réutilisation possible) puis comme abandonnée (réutilisation possible, s'il n'y a pas de mises en œuvre du protocole qui trainent, et si l'espace de nommage est presque épuisé).

Un exemple d'un enregistrement temporaire ? Aujourd'hui, vous trouvez par exemple la valeur 5 dans les modes de réponse du test de connectivité de MPLS : https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#reply-modes note « 5 - Reply via specified path (TEMPORARY - expires 2012-01-20) [sic] ».

Pas de changements drastiques depuis le RFC 4020, le principal étant l'extension des allocations précoces à d'autres politiques d'allocation. Il y a eu peu de débats sur ce nouveau RFC : après tout, il s'agit de cas spécifiques qui ne concernent pas tous les participants à l'IETF.