D. McPhersonO. Kolkman (ISOC)J.C. KlensinG. Huston (APNIC)Internet Architecture BoardFebruary20202020-02-28
Ce RFC
officiel de l'IAB décrit le rôle de l'opérateur des registres
des protocoles utilisé par l'IETF. Des tas de protocoles normalisés par
cet organisme ont besoin de garder une trace des noms ou numéros
réservés (par exemple les numéros de port de TCP ou UDP, les numéros d'options
DHCP, etc.) C'est le rôle de l'opérateur du
registre qui garde ces réservations (aujourd'hui, essentiellement
l'IANA). Ce RFC remplace le , suite à la création de la nouvelle structure
administrative de l'IETF, dans le .
L'IETF n'assure pas ce rôle d'opérateur du
registre elle-même. Elle se focalise sur la production de normes
(les RFC) et
délègue la gestion du registre. Pourquoi les valeurs en question
ne sont-elles pas directement mises dans les RFC ? Parce qu'elles
évoluent plus vite que la norme elle-même. Ainsi, l'enregistrement
d'un nouveau type d'enregistrement DNS est un processus bien plus souple que de
modifier un RFC et la liste de
tels types ne peut donc pas être figée dans un RFC (ceux-ci
ne sont jamais modifiés, seulement remplacés, et cela n'arrive pas
souvent).
Mais on ne peut pas non plus laisser chacun définir ses propres
paramètres, car cela empêcherait toute interprétation
commune. D'où cette idée d'un registre des paramètres. Les règles
d'enregistrement dans ce registre, la politique suivie, sont
décrites pour chaque norme dans la section IANA
considerations du RFC, en utilisant le vocabulaire et
les concepts du (pour les types
d'enregistrements DNS, cités plus haut, les détails sont dans le
).
Plusieurs autres SDO suivent ce même principe de
séparation entre la normalisation et l'enregistrement (en
revanche, les groupes fermés d'industriels qui tentent d'imposer
leur standard ne séparent pas en général ces deux fonctions). Par
exemple, l'ISO définit, pour la plupart de ses
normes, une Registration Authority ou bien une
Maintenance Agency qui va tenir le
registre. (Exemples : l'opérateur du registre de ISO
15924 est le consortium Unicode
et celui du registre de ISO 639 est
SIL. Contre-exemple : l'opérateur du
registre de ISO 3166 est l'ISO elle-même.)
Pourquoi cette séparation ? Les raisons sont multiples mais l'une
des principales est la volonté de séparer la politique de base
(définie dans la norme) et l'enregistrement effectif, pour gérer
tout conflit d'intérêts éventuel. Un opérateur de registre séparé
peut être plus indépendant, afin de ne pas retarder ou bloquer
l'enregistrement d'un paramètre pour des raisons commerciales ou
politiques. Notons aussi que bien d'autres fonctions liées à
l'IETF sont également assurées à l'extérieur, comme la publication
des RFC.
Contre-exemple, celui du W3C, qui utilise très peu de registres et
pas d'opérateur de registre officiel séparé. En pratique, c'est
l'IANA qui gère plusieurs registres Web, comme celui des
URI
bien
connus (), celui des types
de fichiers (comme application/pdf ou
image/png), celui des en-têtes
(utilisés notamment par HTTP), etc. En
dehors de l'IANA, le W3C a quelques registres gérés en interne
comme celui de
Xpointer. Pour le reste, la politique du W3C est plutôt
qu'un registre est un point de passage obligé et que de tels
points ne sont pas souhaitables.
Dans le cas de l'IETF, les documents existants sont le , qui décrit le processus de
normalisation mais pas celui d'enregistrement. Ce dernier est
traditionnellement connu sous le nom de « fonction IANA » (d'où la
section IANA considerations des RFC) même si,
en pratique, ce n'est pas toujours l'IANA qui l'effectue. (Les
registres de l'IANA sont en .)
La section 2 du RFC expose donc le rôle et les responsabilités
du(des) opérateur(s) de registres de paramètres. Celui(ceux)-ci,
nommés avec majuscules IETF Protocol Parameter Registry
Operator, seront choisis par l'IETF LLC
(). J'ai mis le pluriel car
l'IANA n'assure pas actuellement la totalité
du rôle : il existe d'autres opérateurs de registres, en général
sur des tâches très secondaires comme par exemple le RIPE-NCC pour
l'enregistrement en
e164.arpa
(ENUM, cf. ). Dans le futur, on pourrait imaginer un rôle
moins exclusif pour l'IANA.
La section 2.1 est la (longue) liste des devoirs qu'implique le
rôle d'opérateur de registre. Il y a bien sûr le tenue du registre
à proprement parler mais ce n'est pas tout. En voici une partie :
Donner des avis sur les futurs RFC (concrètement, relire les
sections IANA considerations à l'avance, pour
voir si elles ne poseraient pas de problèmes insurmontables au
registre).Suivre les RFC : l'opérateur du registre n'est pas censé
déterminer la politique mais l'appliquer. Si un RFC dit que
l'enregistrement dans tel registre se fait sans contrainte,
l'opérateur du registre ne peut pas refuser un enregistrement, par
exemple. Chaque registre a une politique d'enregistrement,
expliquée dans le RFC correspondant (les règles générales figurent
dans le ).Bien indiquer dans chaque registre les références notamment
le numéro du RFC qui normalise ce registre et pour chaque
paramètre enregistré dans le registre, indiquer la source de ce
paramètre et la date d'enregistrement.En cas de désaccord ou de problème, se tourner vers
l'IESG, seule habilitée à trancher.Diffuser gratuitement les registres qui
sont tous publics par défaut (contrairement à ce qui se passe chez
l'ultra-dinosaure ISO). Un exemple est le registre de
DHCP, en .Maintenir les listes de diffusion spécifiées pour certains
registres, par exemple lorsque l'enregistrement nécessite un
examen par un expert, sous l'œil du public.Produire des rapports réguliers à destination de
l'IAB,
suivant le mais aussi suivant
l'accord
supplémentaire qui l'a complété, et à destination de toute
l'IETF. Aujourd'hui, cela se fait sous la forme de l'exposé IANA
qu'il y a à chaque plénière de l'IETF. Ces rapports incluent des
points comme les performances de l'opérateur du registre (délai de
traitement, par exemple).Ne pas oublier que les droits de propriété intellectuelle sur ces
registres sont gérés par l'IETF Trust ().
Après cette description des devoirs de l'opérateur du registre,
la section 2 continue avec les devoirs des autres acteurs. En
section 2.2, ceux de l'IAB, qui supervise l'opérateur du registre :
l'IAB procède à la délégation formelle du registre, après que
l'IETF LLC ait identifié
les candidats. L'IAB décide, l'IETF LLC gère la relation avec
l'opérateur.
En section 2.3, le rôle de l'IESG : celui-ci s'occupe
de la partie technique, vérifier que les RFC comportent une bonne
section IANA considerations, identifier les
experts techniques si le RFC précise que l'enregistrement est
précédé d'une évaluation technique (exemple : le , où l'enregistrement d'une
langue dans le registre
des langues est précédé d'une telle évaluation par un
linguiste), répondre aux questions de
l'opérateur du registre si celui-ci a un problème pratique.
En section 2.4, le rôle de l'IETF Trust
(). Il gère la propriété
intellectuelle de l'IETF donc est « propriétaire » du contenu des
registres. Enfin, en section 2.5, le rôle de l'IETF LLC, bras administratif de
l'IETF, qui est de gérer au quotidien les relations avec
l'opérateur du registre. (C'est la principale nouveauté de ce RFC,
par rapport au , que le remplacement
de l'ancienne structure par cette IETF LLC.)
Voilà, l'essentiel était là mais la section 3 rajoute quelques
détails.