Aller au contenu principal

14. Modifications par rapport aux éditions antérieures du BCP 26

14.1. 2016: Modifications dans ce document par rapport au RFC 5226​

Ajouts importants :

  • Suppression des mots-clés, du texte type et de la référence du RFC 2119, en privilégiant un langage clair -- il ne s'agit pas d'une spécification de protocole.

  • Ajout de la Section 1.1, « Réserver les IANA Considerations à l'IANA »

  • Ajout de la Section 1.2, « Informations mises à jour »

  • Ajout de la Section 2.1, « Organisation des registres »

  • Ajout de bonnes pratiques pour la sélection d'une politique appropriée dans la Section 4.

  • Ajout de la Section 4.12, « Utilisation de plusieurs politiques en combinaison »

  • Ajout de la Section 2.3, « Spécification du contrôle des modifications pour un registre »

  • Ajout de la Section 3.4, « Allocations précoces »

  • Déplacement de chaque politique bien connue dans une sous-section distincte de la Section 4.

  • Ajout de la Section 5.4, « Examens d'experts et cycle de vie des documents »

  • Ajout de la Section 7, « Références de documentation dans les registres IANA »

  • Ajout de la Section 8, « Que faire dans les documents "bis" »

  • Ajout de la Section 9.5, « Personne de contact vs cessionnaire ou propriétaire »

  • Ajout de la Section 9.6, « Fermeture ou obsolescence d'un registre/d'enregistrements »

Clarifications et autres :

  • Une certaine réorganisation -- déplacement de texte pour plus de clarté et une lecture plus facile.

  • Apport de clarifications sur l'identification des registres IANA et l'utilisation d'URL pour ceux-ci.

  • Clarification de la distinction entre « Unassigned » et « Reserved ».

  • Apport de quelques clarifications dans « Expert Review » concernant les instructions à l'expert désigné.

  • Apport de quelques clarifications dans « Specification Required » sur la manière de déclarer cette politique.

  • Diverses clarifications mineures et modifications rédactionnelles dans l'ensemble du document.

14.2. 2008: Modifications dans le RFC 5226 par rapport au RFC 2434​

Les modifications incluent :

  • Réorganisation importante du texte afin de développer les descriptions et de mieux regrouper des sujets tels que « la mise à jour de registres » par opposition à « la création de nouveaux registres », afin de permettre aux auteurs de trouver plus facilement le texte le plus applicable à leurs besoins.

  • De nombreuses modifications rédactionnelles pour améliorer la lisibilité.

  • Remplacement du terme « IETF Consensus » par « IETF Review » et ajout de clarifications supplémentaires. L'expérience a montré que les gens voient les mots « IETF Consensus » (sans consulter la définition réelle) et se hâtent de faire des suppositions incorrectes sur ce que le terme signifie dans le contexte des IANA Considerations.

  • Ajout de « RFC Required » à la liste des politiques définies.

  • Des indications et des exemples beaucoup plus explicites sur « ce qu'il faut mettre dans les RFC ».

  • « Specification Required » implique désormais le recours à un expert désigné pour évaluer si les spécifications sont suffisamment claires.

  • Ajout d'une section décrivant les enregistrements provisoires.

  • Modification importante de la formulation dans la section « Designated Experts ». L'objectif principal est de clarifier que les experts examinateurs sont redevables envers la communauté et de fournir quelques orientations sur les critères d'examen dans le cas par défaut.

  • Modification de la formulation pour supprimer tout recours d'appel spécial. Le processus d'appel normal du RFC 2026 est utilisé.

  • Ajout d'une section sur la récupération des valeurs inutilisées.

  • Ajout d'une section sur les enregistrements après coup.

  • Ajout d'une section indiquant que les listes de diffusion utilisées pour évaluer d'éventuelles affectations (par exemple par un expert désigné) sont soumises aux règles normales de l'IETF.