RFC6410, BCP 9 Processus de normalisation Housley & autres

Internet Engineering Task Force (IETF)

R. Housley, Vigil Security

Request for Comments : 6410, BCP 9

D. Crocker, Brandenburg InternetWorking

RFC mise à jour : 2026

E. Burger, Georgetown University

Catégorie : Bonnes pratiques actuelles

octobre 2011

ISSN: 2070-1721

Traduction Claude Brière de L’Isle



Réduction de la voie de la normalisation à deux niveaux de maturité


Résumé

Le présent document met à jour le processus de normalisation de l’équipe d’ingénierie de l’Internet (IETF Internet Engineering Task Force) défini dans la RFC2026. Principalement, il réduit le processus de normalisation de trois niveaux de maturité des textes sur la voie de la normalisation à deux.


Statut de ce mémoire

Le présent document n’est pas une spécification de l’Internet en cours de normalisation ; il est publié dans un but d’information.


Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.


Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc6410


Notice de droits de reproduction

Copyright (c) 2011 IETF Trust et les personnes identifiée comme auteurs du document. Tous droits réservés.


Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.


1. Introduction


Le présent document change le processus des normes de l’Internet défini dans la [RFC2026]. Ces dernières années, l’équipe d’ingénierie de l’Internet (IETF) a rencontré des difficultés à faire avancer les documents le long des niveaux de maturité : proposition de norme, projet de norme, et finalement norme de l’Internet. Ces changements sont destinés à simplifier le processus de normalisation et à réduire les obstacles à la progression des normes tout en préservant les bénéfices les plus importants de l’approche de l’ingénierie de l’IETF. De plus, l’exigence d’une révision annuelle des documents en cours de normalisation qui n’ont pas encore atteint le sommet de l’échelle de maturité a été supprimée du processus de normalisation de l’Internet.


Au fil des ans, il y a eu de nombreuses propositions pour préciser le processus de normalisation de l’Internet pour réduire les obstacles à la progression des normes. Durant le mois de mai 2010, le groupe de pilotage de l’ingénierie de l’Internent (IESG, Internet Engineering Steering Group) a discuté de nombreuses propositions. Ensuite, une discussion plénière à l’IETF 78 en juillet 2010 a montré un soutien significatif à une transition d’une échelle de maturité à trois échelons vers une à deux échelons.


Dans le processus de normalisation de l’Internet, l’expérience d’une proposition de norme est supposée motiver des révisions qui précisent, modifient, améliorent, ou suppriment des caractéristiques. Cependant, ces dernières années, la vaste majorité des documents en cours de normalisation ont été publiés comme des propositions de norme et n’ont jamais avancé à un niveau de maturité supérieur. Très peu de spécifications ont avancé sur l’échelle de maturité dans la dernière décennie. Changer le processus de normalisation de l’Internet de trois niveaux de maturité à deux est destiné à créer un environnement où les leçons de la mise en œuvre et l’expérience du déploiement seront utilisées pour améliorer les spécifications.


Le principal aspect de ce changement est de réviser les exigences pour l’avancement au delà de la proposition de norme. La [RFC2026] exige qu’un rapport documente l’interopérabilité entre au moins deux mises en œuvre à partir de bases de code différentes comme étape intermédiaire ("projet de norme") avant qu’une spécification puisse avancer plus loin au troisième et final niveau de maturité ("Norme") sur la base d’un large déploiement et d’une utilisation générale. À l’opposé, le présent document exige de mesurer l’interopérabilité à travers un large déploiement de multiples mises en œuvre à partir de bases de code différentes, condensant donc deux métriques séparées en une seule.


Le résultat attendu de ce changement est un avancement du niveau de maturité fondé sur la réalisation de spécifications de qualité largement déployées. De plus, le changement résultera en l’incorporation des leçons de l’expérience de la mise en œuvre et du déploiement, et la reconnaissance de l’amélioration des protocoles par la suppression de la complexité associée à des caractéristiques inhabituelles.


Dans la [RFC2026], le large déploiement est essentiellement la métrique utilisée pour l’avancement d’un projet de norme en norme. L’utilisation de la même métrique pour l’avancement au delà du statut de proposition de norme signifie qu’il n’y a plus de distinction utile entre les deux échelons supérieurs de l’échelle de maturité. Donc, l’échelle de maturité est réduite à deux échelons.


De plus, la [RFC2026] exigeait une révision annuelle des spécifications qui n’avaient pas atteint le niveau de maturité supérieur. Cette révision n’est plus nécessaire.


2. Deux niveaux de maturité


Le présent document remplace l’échelle à trois niveaux de maturité définie dans la [RFC2026] par une échelle de maturité à deux échelons. Les spécifications deviennent des normes de l’Internet par un ensemble de deux niveaux de maturité connu sous le nom de "cours de normalisation". Ces niveaux de maturité sont "Proposition de norme" et " Norme de l’Internet".


Une spécification peut, et bien sûr, a des chances d’être révisée lorsque elle avance du statut de proposition de norme à celui de norme de l’Internet. Lorsque une spécification révisée est proposée à l’avancement comme norme de l’Internet, l’IESG devra déterminer la portée et la signification des changements à la spécification, et, si nécessaire et approprié, modifier l’action recommandée. Des révisions mineures et la suppression des caractéristique non utilisées sont prévisibles, mais une révision significative peut exiger que la spécification recueille plus d’expérience au statut de proposition de norme avant de progresser.


2.1 Premier niveau de maturité : Proposition de norme


Les exigences déclarées pour les propositions de normes ne sont pas changées ; elles restent exactement comme spécifié dans la [RFC2026]. Aucune nouvelle exigence n’est introduite ; aucune exigence existante publiée n’est supprimée.


2.2 Second niveau de maturité : Norme Internet


Le niveau de maturité est une fusion des statuts de projet de norme et de norme, comme spécifié dans la [RFC2026]. Le nom choisi évite la confusion entre "Projet de norme" et "Projet Internet".


La caractérisation d’une norme de l’Internet reste celle décrite dans la [RFC2026], qui dit :


Une norme de l’Internet se caractérise par un haut degré de maturité technique et par le sentiment partagé généralement que le protocole ou service spécifié apporte un bénéfice significatif à la communauté de l’Internet.


L’IESG, dans un dernier appel à l’ensemble de l’IETF d’au moins quatre semaines, confirme qu’un document avance du statut de Proposition de norme à celui de Norme de l’Internet. La demande de reclassification est envoyée à l’IESG avec une explication de la façon dont les critères ont été satisfaits. Les critères sont :


(1) Il y a au moins deux mises en œuvre indépendantes qui interopèrent avec un large déploiement et une expérience de fonctionnement réussi.


(2) Il n’y a pas d’errata à l’égard de la spécification qui pourrait causer l’échec d’une nouvelle mise en œuvre à interopérer avec celles déployées.


(3) Il n’y a aucune caractéristique non utilisée dans la spécification qui augmente la complexité de mise en œuvre.


(4) Si la technologie requise pour mettre en œuvre la spécification exige une technologie brevetée ou par ailleurs sous contrôle, l’ensemble des mises en œuvre doit démontrer au moins deux utilisations indépendantes, séparées et réussies du processus de licence.


Après révision et prise en considération des errata significatifs, l’IESG effectuera au niveau de l’ensemble de l’IETF un dernier appel d’au moins quatre semaines sur la reclassification demandée. Si il y a consensus sur la reclassification, la RFC sera reclassifiée sans publication d’une nouvelle RFC.


Comme établi dans la [RFC2026], dans un délai en rapport avec l’expiration de la période de dernier appel, l’IESG devra faire sa détermination finale et notifier sa décision à l’IETF via un message électronique à la liste de diffusion d’annonces de l’IETF. Aucun changement n’est fait au paragraphe 6.1.2 de la [RFC2026].


2.3 Transition vers un cours de normalisation à deux niveaux de maturité


Tout protocole ou service qui est actuellement au niveau de maturité de proposition de norme y reste.


Tout protocole ou service qui est actuellement au niveau de maturité de Norme devra être immédiatement reclassifié comme norme de l’Internet.


Tout protocole ou service qui est actuellement au niveau de maturité de projet de norme abandonné conservera cette classification, en l’absence d’action explicite. Deux actions possibles sont disponibles :


(1) Un projet de norme peut être reclassifié comme norme de l’Internet aussitôt que les critères du paragraphe 2.2 sont satisfaits.


(2) À tout moment après deux ans à partir de l’approbation de ce document comme BCP, l’IESG peut choisir de reclassifier tout document de projet de norme comme proposition de norme.


3. Exigences supprimées

3.1 Suppression de l’exigence de revue annuelle


En pratique, la révision annuelle des documents de proposition de norme et de projet de norme après deux ans (réclamée dans la [RFC2026]) n’a pas eu lieu. L’absence de cette révision n’a pas révélé d’effets contraires sur le processus de normalisation de l’Internet. Par suite, l’exigence de cette révision est abandonnée. Aucun cycle de révision n’est imposé aux documents en cours de normalisation à aucun niveau de maturité.


3.2 Exigence d’un rapport de vérification d’interopérabilité


La vérification de l’interopérabilité a une longue tradition dans le développement des protocoles de l’Internet et reste importante pour la fiabilité du déploiement des services. Le processus de normalisation de l’IETF n’exige plus un rapport formel d’interopérabilité, et on reconnaît que le déploiement et l’utilisation sont suffisants pour montrer l’interopérabilité.


Bien qu’elle ne soit plus exigée par le processus de normalisation de l’IETF, la [RFC5657] peut aider à conduire la vérification de l’interopérabilité.


4. Considérations de sécurité


Le présent document n’affecte pas directement la sécurité de l’Internet.


5. Remerciements


Un processus de normalisation à deux échelons a été proposé de nombreuses fois. Spencer Dawkins, Charlie Perkins, et Dave Crocker ont fait une proposition en 2003. D’autres propositions ont été faites par Scott Bradner en 2004, Brian Carpenter en juin 2005, et Ran Atkinson en 2006. Le présent document emprunte ses idées à beaucoup de ces propositions antérieures ; il incorpore aussi des idées de la discussion de l’IESG de mai 2010, de la discussion de la plénière de l’IETF 78 en juillet 2010, et à une autre proposition soumise par Spencer Dawkins, Dave Crocker, Eric Burger, et Peter Saint-Andre en novembre 2010.


6. Références

6.1 Référence normative


[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)


6.2 Référence pour information


[RFC5657] L. Dusseault, R. Sparks, "Guide pour les rapports sur l'interfonctionnement et la mise en œuvre de l'avancement des projets de normes", BCP0009, septembre 2009. (MàJ RFC2026)


Adresse des auteurs


Russell Housley

Dave Crocker

Eric W. Burger

Vigil Security, LLC

Brandenburg InternetWorking

Georgetown University

mél : housley@vigilsec.com

mél : dcrocker@bbiw.net

mél : eburger@standardstrack.com



URI : http://www.standardstrack.com


page - 4 -