4. Choisir une politique d'enregistrement et politiques usuelles

4. Choisir une politique d'enregistrement et politiques usuelles (Choosing a Registration Policy and Well-Known Policies)

Une politique d'enregistrement (registration policy) est la politique qui régit l'acceptation des nouvelles affectations (assignments) dans un registre (registry). Plusieurs points méritent d'être considérés lors de sa définition.

Si l'espace de noms (namespace) du registre est limité, les affectations doivent être faites avec prudence pour éviter l'épuisement.

Même lorsque l'espace est en pratique illimité, il reste souvent souhaitable d'avoir au moins un examen minimal avant affectation afin de:

• empêcher l'accaparement ou le gaspillage inutile de valeurs. Par exemple, si l'espace est constitué de chaînes, il peut être souhaitable d'empêcher des entités d'obtenir de grands ensembles de chaînes correspondant à des noms désirables (noms d'entreprises existantes, par exemple).

• fournir une vérification de cohérence (sanity check) que la demande a réellement un sens et est nécessaire. L'expérience montre qu'un examen minimal de la part d'un expert du domaine (subject matter expert) est utile pour éviter des affectations lorsque la demande est mal formée ou non nécessaire (par exemple, une affectation existante pour un service essentiellement équivalent existe déjà).

Sans doute surtout, des extensions non examinées peuvent affecter l'interopérabilité (interoperability) et la sécurité (security). Voir [RFC6709].

Lorsque l'espace de noms est en pratique illimité et qu'il n'y a pas de problèmes potentiels d'interopérabilité ou de sécurité, les numéros affectés (assigned numbers) peuvent en général être attribués à quiconque sans examen subjectif. Dans de tels cas, l'IANA (Internet Assigned Numbers Authority) peut effectuer les affectations directement, à condition qu'on lui fournisse des instructions détaillées sur les types de demandes qu'elle doit satisfaire et qu'elle puisse le faire sans exercer de jugement subjectif.

Lorsque ce n'est pas le cas, un certain niveau d'examen est requis. Il importe toutefois d'équilibrer examen suffisant et facilité d'enregistrement. Souvent, les personnes qui enregistrent ne sont pas des participants IETF; les demandes proviennent d'autres organisations de normalisation, d'organisations non directement impliquées dans les normes, de travaux communautaires ad hoc (d'un projet open source, par exemple), etc. L'enregistrement ne doit pas être inutilement difficile, inutilement coûteux (en temps et autres ressources), ni inutilement exposé au refus.

Bien qu'il soit parfois nécessaire de restreindre ce qui est enregistré (p. ex. pour des ressources limitées telles que des bits dans un octet, ou pour des éléments dont des valeurs non prises en charge peuvent nuire au fonctionnement du protocole), dans de nombreux cas il est plus important que ce qui est utilisé soit représenté dans le registre. Des critères d'examen trop stricts et un coût excessif (temps et effort) découragent les tentatives d'enregistrement. Si un registre ne reflète pas les éléments de protocole réellement utilisés, cela peut nuire au déploiement des protocoles sur Internet, et le registre lui-même se dévalue.

Il importe donc de réfléchir spécifiquement à la politique d'enregistrement, et non d'en choisir une arbitrairement ni de copier du texte d'un autre document. Les groupes de travail et autres auteurs de documents doivent faire preuve de discernement en choisissant des politiques adaptées lorsque leurs documents créent des registres. Ils doivent choisir la politique la moins stricte compatible avec les besoins du registre, et apporter une justification précise pour les politiques exigeant une forte implication communautaire (plus strictes qu'Expert Review ou Specification Required, au sens des politiques usuelles). Les besoins varient d'un registre à l'autre et, en fait, dans le temps; ce BCP (Best Current Practice) ne sera pas le dernier mot sur le sujet.

Les politiques suivantes sont définies pour un usage courant. Elles couvrent une gamme de politiques typiques ayant servi à décrire les procédures d'affectation de nouvelles valeurs dans un espace de noms. Il n'est pas strictement exigé que les documents emploient ces termes; l'exigence réelle est que les instructions à l'IANA soient claires et sans ambiguïté. Toutefois, l'usage de ces termes est fortement recommandé car leurs significations sont largement comprises. Des politiques nouvelles, y compris celles combinant de façon originale des éléments associés à ces termes, peuvent être utilisées si aucune de ces politiques ne convient; une explication de ce constat facilitera le processus d'examen. Les termes sont entièrement expliqués dans les sous-sections suivantes.

1. Private Use
2. Experimental Use
3. Hierarchical Allocation
4. First Come First Served
5. Expert Review
6. Specification Required
7. RFC Required
8. IETF Review
9. Standards Action
10. IESG Approval

Il convient de noter qu'il est souvent pertinent de partitionner un espace de noms en plusieurs catégories, les affectations étant traitées différemment dans chaque catégorie. De nombreux protocoles partitionnent désormais les espaces de noms en deux parties ou plus, une plage étant réservée à Private Use ou Experimental Use tandis que d'autres plages sont réservées à des affectations globalement uniques selon un processus d'examen. Diviser un espace de noms en plages permet d'appliquer des politiques différentes selon les plages et les cas d'usage.

De même, il sera souvent utile de spécifier plusieurs politiques en parallèle, chacune s'appliquant dans des circonstances différentes. Pour plus de discussion, voir Section 4.12.

Exemples de RFC spécifiant plusieurs politiques en parallèle:

• LDAP [RFC4520]
• TLS ClientCertificateType Identifiers [RFC5246] (comme détaillé dans les sous-sections ci-dessous)
• MPLS Pseudowire Types Registry [RFC4446]