Groupe de travail Réseau	Comité consultatif IAB	
Request for Comments : 3716	IETF	
Catégorie : Information		
Traduction Claude Brière de L'Isle	mars 2004	

L'IETF au sens large : administration et fonctionnement

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune forme de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2004). Tous droits réservés

Résumé
À la fin 2003, le président de l'IETF et le président de l'IAB ont formé un comité consultatif de l'IAB (AdvComm, Advisory Committee) avec le mandat de revoir la structure administrative existante de l'IETF et les relations entre l'éditeur des RFC, le secrétariat de l'IETF, et l'IANA, et de proposer des changements au processus de gestion ou aux structures de l'IETF pour améliorer le fonctionnement global de l'IETF. Le mandat du AdvComm n'incluait pas le processus de normalisation lui-même. Le présent mémoire documente les conclusions et les propositions de l'AdvComm.
Table des Matières
1. Introduction	1
1.1 Vue d'ensemble du processus de travail et des résultats de l'AdvComm	2
1.2 Domaine d'application	2
1.3 Prochaines étapes	2
2. Observations	2
2.1 Structure actuelle de soutien de l'IETF	2
2.2 Points de tension observés	4
2.3 Observation finale	5
3. Face au futur : exigences pour la réussite de l'administration de l'IETF	5
3.1 Gestion des ressources	5
3.2. Intendance	6
3.3 Environnement de travail	7
4. Avis du comité consultatif	7
4.1 Proposition : une seule entité organisationnelle formalisée pour l'IETF	7
4.2 Structures possibles	8
4.3 Qui peut décider	9
5. Considérations sur la sécurité	9
6. Remerciements	9
7. Références pour information	10
Appendice A. Mandat du comité consultatif de l'IAB	10
Appendice B. Apports des présidents actuels de l'IETF et de l'IAB	11
Appendice C. Consultation de ISI : éditeur des RFC	11
C.1 Fonctions d'éditeur des RFC	14
Appendice D. Consultation de Foretec/CNRI : secrétariat et programmation des réunions	16
Appendice E. Consultation de l'ICANN : allocation des paramètres de protocoles par l'IANA	17
Adresse de l'auteur	20
Déclaration complète de droits de reproduction	20

1.	Introduction

Fin 2003, les présidents de IETF et de l'IAB ont formé un comité consultatif de l'IAB (AdvComm, Advisory Committee) avec pour mandat de revoir la structure et les relations administratives existantes de l'IETF (éditeur des RFC, secrétariat de l'IETF, IANA) et de proposer des changements au processus ou à la structure de gestion de l'IETF pour améliorer le fonctionnement global de l'IETF. Cet objet a été défini dans le mandat du comité consultatif de l'IAB, copié à l'Appendice  A. Le mandat de l'AdvComm n'incluait pas le processus de normalisation lui-même.

Le résultat tangible de ce comité est un ensemble d'observations et de recommandations pour la structure exécutive de l'IETF, comment l'IETF pourrait être organisationnellement (re)structurée afin de mener à bien efficacement ses activités administratives. Un préalable nécessaire à cela est une description des questions actuelles et des exigences futures. Le résultat ne représente aucune prise de décision ni mise en œuvre ; voir au paragraphe 1.3 la discussion des suites.

1.1	Vue d'ensemble du processus de travail et des résultats de l'AdvComm
L'AdvComm a été formé en septembre 2003, et a conduit ses travaux dans le courant des deux mois suivants, avant la réunion IETF58 de novembre 2003.

Les membres de l'AdvComm incluaient de nombreuses personnes qui sont, ou ont été, volontaires pour gérer les relations administratives inter organisations de l'IETF ces dernières années. La première phase du travail du comité a donc été d'inclure, de partager, et discuter le corps des connaissances tacites sur ces relations. Cela incluait des apports des présidents actuels de l'IETF et de l'IAB donnés en Appendice B, et a donné les informations sur la structure de l'organisation de l'IETF au paragraphe 2.1.

Le comité a aussi recherché des apports venant de l'autre extrémité de la chaîne des relations administratives existantes (l'éditeur des RFC, le secrétariat, et l'IANA). Le résultat de ces efforts est inclus dans les Appendices C, D, et E, et ils ont aussi été utilisés comme base des observations de la Section 2.

À partir de ces apports, le comité a tiré une liste d'exigences pour le succès futur de l'administration de l'IETF, documentée à la Section 3.

Finalement, le comité a rassemblé quelques avis sur la façon dont l'IETF pourrait envisager de réorganiser sa structure administrative afin de satisfaire ces exigences qui forment la Section 4.

1.2	Domaine d'application
Le AdvComm s'est efforcé de rester concentré sur la structure exécutive de l'IETF -- la collection d'organisations qui travaillent ensemble pour amener au jour les travaux de l'IETF. Cependant, du fait même que ces relations existent pour que le travail soit fait, il était important de garder à l'esprit les travaux conduits par le groupe de travail "IETF PROBLEM" et les propositions de changements de l'IESG, même si le comité s'est efforcé de ne pas empiéter sur le domaine attribué à ces organes. L'objectif est que ces observations et propositions soient pertinentes pour l'IETF d'aujourd'hui et pour les évolutions à moyen terme qui semblent appropriées.

1.3	Prochaines étapes
Le présent document présente l'état des réflexions de l'AdvComm à la fin de deux mois de traitement qui amènent à leur terme les travaux pour lesquels le AdvComm était mandaté.

Les prochaines étapes incluent l'examen de ces matériaux par la communauté, et des propositions d'actions spécifiques qui seront retenues par les présidents de IAB et de l'IETF.

2.	Observations
2.1	Structure actuelle de soutien de l'IETF
2.1.1	Ce que le terme IETF inclut dans le présent document
La [RFC3233] donne une définition de l'IETF, en termes de travail et de participation.

Le présent document discute de la collection d'organisations qui travaillent ensemble pour soutenir l'effort décrit dans la RFC 3233. Dans ce document, le terme"IETF" inclut explicitement l'IESG, les groupes de travail, l'IAB, l'IRTF, et les RG. Ce sens inclusif s'accorde à l'usage commun considérable du terme"IETF". Formellement, les mandats de l'IAB et de l'IRTF sont indépendants de celui de l'IETF. Cependant, plutôt que de forger un nouveau terme pour englober "l'IETF et tous les siens", on suivra ici l'usage commun.

2.1.2	Fonctions
Le travail de l'IETF est effectué par un ensemble spécifique de fonctions. Il est utile de distinguer entre les fonctions et les organisations qui fournissent ces services, comme le souligne le tableau ci-dessous. Dans certains cas, une seule organisation fournit plusieurs services, mais les fonctions sont logiquement distinctes.

Fonction	Appelé (au sein de l'IETF)	Organisation
Soutien à l'IESG	Secrétariat	Foretec/CNRI
Soutien à l'IAB	ISOC/Secrétariat	ISOC, Foretec/CNRI
Soutien aux groupes de travail	Secrétariat	Foretec/CNRI
Soutien à la communauté	Secrétariat	Foretec/CNRI
Réunions de l'IETF	Secrétariat	Foretec/CNRI
Publication des RFC	Éditeur des RFC	USC/ISI
Tenu de l'état des normes	Éditeur des RFC	USC/ISI
Enregistrement des paramètres	IANA	ICANN
Juridique, assurance, etc.	(largement invisible)	Fourni par l'ISOC

Tableau 1 : Fonctions de l'IETF, étiquettes et organisations

Plus en détail, les fonctions peuvent être divisées comme suit :

Soutien à l'IESG : téléréunions, communications, suivi des documents de l'IETF, gestion des documents de travail, site de la Toile, répertoires).

Soutien à l'IAB : téléréunions, communications, gestion des documents de travail (liste de diffusion, site de la Toile, répertoire).

Soutien aux groupes de travail : mandats, suivi des étapes, espace de travail (site de la Toile, liste de diffusion), archive des documents de travail (archives de la liste de diffusion, répertoire des documents).

Soutien à la communauté : site de la Toile, liste de diffusion de l'IETF, annonces, répertoire des projets Internet.

Publication des RFC : site de la Toile, édition des RFC, publication des documents, gestion du répertoire des RFC, enregistrement officiel du statut des normes.

Réunions de l'IETF : Programmation, compte rendu des réunions.

Enregistrement des paramètres des protocoles : création des registres, allocation des paramètres des protocoles, gestion du répertoire des registres accessibles.

Juridique, assurance, etc. : soutien juridique, assurance de responsabilité pour l'IAB, l'IESG, les présidents de groupes de travail, etc., divers.

2.1.3	Soutien
Une présentation du contexte et de la profondeur du soutien qui ont créé l'IETF et lui ont permis de continuer sa contribution exigerait un exposé d'histoire riche et vibrant, qui va bien au delà des objectifs du présent document. Cependant, une très brève introduction aux principaux éléments est nécessaire pour comprendre où en est aujourd'hui l'IETF.

ISOC : depuis 1992, l'ISOC a été l'hébergement organisationnel de l'IETF. Cette activité fait partie d'une mission plus générale de service comme organisation internationale pour la coordination et la coopération mondiale sur l'Internet, la promotion et la maintenance d'un large spectre d'activités centrées sur le développement, la disponibilité, et les technologies associées à l'Internet.

Foretec/CNRI: la corporation pour les initiatives nationales de recherche (CNRI, Corporation for National Research Initiatives) a été fondée en 1986, et depuis 1987, la CNRI a servi la communauté en fournissant les services de secrétariat à l'IETF. Jusqu'au début des années 1990, la CNRI fournissait l'assistance juridique à l'IETF et au secrétariat de l'IETF. Après la fondation de l'ISOC, celle-ci a pris en charge la responsabilité juridique globale de la substance des travaux de l'IETF incluant les efforts du président de l'IETF, de l'IESG, de l'IAB, des directeurs de zone et des présidents de groupe de travail. La CNRI prenait en charge la responsabilité du fonctionnement des travaux de soutien du secrétariat de l'IETF. En 1998, afin de diminuer le coût global des activités, le secrétariat a été réorganisé en plaçant les employés du secrétariat, y compris le directeur exécutif de l'IETF, dans une filiale à but non lucratif de la CNRI (Foretec Seminars, Inc.). Foretec a été fondé en 1997, en anticipation d'une prise en charge autonome du secrétariat. CNRI et sa filiale ont continué d'améliorer le fonctionnement du secrétariat, comme approprié, et de maintenir un personnel qualifié.

USC/ISI : le rôle de l'éditeur des RFC, et de USC/ISI, est détaillé dans la [RFC2555]. La série de documents RFC est un ensemble de notes techniques et organisationnelles sur l'Internet (à l'origine, l'ARPANET) commençant en 1969. Pendant 30 ans, l'éditeur des RFC était Jon Postel, un chercheur scientifique et cadre de la division Réseautage de l'Institut des sciences de l'information de l'USC (ISI, Information Sciences Institute) avec une fonction évoluant graduellement en une équipe dirigée par lui. L'activité d'éditeur des RFC est actuellement organisée comme un projet au sein d'ISI, utilisant l'infrastructure de ISI, et pris en charge par un contrat avec l'ISOC. L'éditeur des RFC est celui qui publie les RFC et est responsable de la révision rédactionnelle finale des documents, ainsi que de la maintenance du répertoire en ligne et de l'index de ces documents.

ICANN : la corporation Internet pour l'allocation de noms et des numéros de l'Internet (ICANN, Internet Corporation for Assigned Names and Numbers) est l'association à but non lucratif qui a été formée en 1998 pour prendre la responsabilité des fonctions d'allocation de l'espace d'adresses IP, d'allocation des paramètres de protocoles, de gestion du système des noms de domaines, et de gestion du système de serveur racine précédemment assurées par l'IANA (à ISI) et d'autres entités au titre d'un contrat avec le gouvernement des États-Unis.

Le schéma du soutien (qui fait quoi) peut être décrit comme suit :

Secrétariat à Foretec/CNRI : soutien à l'IESG ; soutien à l'IAB (gestion des document de travail) ; soutien aux groupes de travail ; soutien à la communauté ; réunions de l'IETF.

Éditeur des RFC à USC/ISI : [pris en charge par l'ISOC, sur la base d'un contrat entre USC/ISI et l'ISOC] publication des RFC ; maintenance des enregistrements d'état des normes.

IANA/ICANN : [Relations définies par l'accord publié dans la RFC 2860] registre des paramètres des protocoles.

ISOC : soutien à l'IAB (Téléconférences) ; financement de l'éditeur des RFC ; diverses dépenses de l'IAB/IESG ; fournit les assurance pour l'IAB, l'IESG, les présidents de groupes de travail, etc..

Les ressources disponibles pour prendre en charge ces activités sont :
Les redevances des réunions --  à travers Foretec ; les contributions des membres de l'ISOC pour les normes ; l'ICANN pour l'IANA.
Les volontaires/leurs employeurs (lorsque applicable) : les participants à l'IETF ; les présidents des groupes de travail ; les éditeurs des documents ; le NOMCOM de l'IETF ; l'IESG ; l'IAB ; le directeur exécutif de l'IAB.

2.2	Points de tension observés
Le AdvComm a noté plusieurs propriétés de l'environnement organisationnel actuel de l'IETF qui causent des tensions dans le système. Elles ont été notées à la fois du point de vue de la direction de l'IETF et de celui des organisations qui soutiennent l'IETF.

2.2.1	Points de tension observés par la direction de l'IETF
La structure actuelle de financement et de fonctionnement de l'IETF dépend de la participation aux réunions de l'IETF. Donc, la tension la plus évidente qui a émergé ces deux dernières années est le déclin de cette participation. Cette tendance, qui s'est poursuivie dans interruption, a résulté en une baisse des revenus de l'IETF (détaillée dans la présentation du président de l'IETF à l'IETF 56 [IETF]), alors même que les exigences du fonctionnement de l'IETF restent constantes ou croissent.

Le résultat a été un déficit du budget pour le fonctionnement qui a commencé en 2002, et est prévu comme devant se poursuivre au moins jusqu'en 2004, même après une hausse substantielle des redevances de réunions. La poursuite des déficits a entamé le capital de travail, rendant l'IETF moins robuste contre de futures désillusions budgétaires potentielles.

La tension financière est réelle, mais la direction de l'IETF a noté plusieurs autres points de tension qui sont des difficultés à trouver et mettre en œuvre des solutions aux questions fiscales. Certaines solutions évidentes ne peuvent pas être mises en œuvre dans la structure actuelle de l'IETF.

Le reste des points de tension mentionnés dans cette section devrait être vu comme des questions pour  lesquelles un soulagement est nécessaire, en particulier à la lumière du besoin de traiter et mettre en œuvre correctement des solutions à la pression financière.

La documentation actuelle des processus et de la structure de l'IETF est, par endroits, vague sur la distribution des responsabilités de la gestion et de la supervision des relations administratives de l'IETF. Cela la rend opaque pour la communauté de l'IETF, et laisse parfois la direction dans une mauvaise position pour une gestion efficace.

De plus, le caractère informel des relations avec certaines autres organisations qui supportent des fonctions clés de l'IETF complique le problème de la détermination de qui a la responsabilité, et comment le consensus et les désirs de la communauté de l'IETF sont reflétés dans l'activité.

Un problème distinct est que l'importante mémoire institutionnelle de l'IETF n'est, dans de nombreux cas, enregistrée nulle part ailleurs que dans la mémoire des gens – ce qui exige une transmission significative de l'histoire orale pour que les transitions de la direction de l'IETF soit efficace.

À part la mémoire institutionnelle, d'autres archives institutionnelles importantes de l'IETF sont dispersées entre diverses organisations, et la recherche de l'ensemble de documentation pertinent (en particulier lorsque c'est nécessaire longtemps après les faits) peut être un défi.

Un autre point de tension se rapporte au besoin d'adapter les processus de soutien en termes de réduction des délais des processus mécaniques. C'est-à-dire, une diminution de la quantité de travail manuel requis pour les plus simples tâches entre les organisations, rendraient plus de ressources disponibles pour se concentrer sur les cas particuliers. Le manque d'automatisation des services de demandes de base est connu pour causer des retards indus ou des échecs de traitement de tâches simples et de routine. Cependant, l'automatisation exige aussi des ressources et une gestion significatives afin de s'assurer de satisfaire les exigences de la communauté.

2.2.2	Points de tension observés par les organisations qui soutiennent l'IETF
Les organisations de soutien rapportent des difficultés pour déterminer les canaux d'autorité pour les décisions – soit trop d'entrées, soit pas d'autorité claire pour la résolution des demandes de changements.

En l'absence d'accords écrits, les organisations de soutien peuvent ne pas avoir de directives claires sur qui donne les directives. Même lorsque des accords existent, l'autorité pour fournir des directives peut n'être pas claire. La genèse des deux problèmes est que l'IETF s'appuie sur des organes externes pour le soutien, mais n'a pas des relations externes suffisamment claires pour lui permettre de fournir des indications sur les exigences ou les directives sur les services qu'elle désire.

2.3	Observation finale
Cette section tente de faire une photographie de l'état actuel de l'organisation de l'IETF, sans faire une fixation sur les causes qui ont amené à l'état actuel. Cependant, il semble clair d'après les observations que l'état actuel ne donne pas une structure adéquate à partir de laquelle aller vers l'avenir : des changements sont nécessaires au sein de la structure administrative et exécutive de l'IETF.

3.	Face au futur : exigences pour la réussite de l'administration de l'IETF

Cette section fait suivre l'ensemble des observations d'un ensemble d'exigences pour une structure administrative de l'IETF qui fonctionne de façon appropriée. Ces exigences sont présentées comme la description par la AdvComm de ce dont l'IETF a besoin, sans regarder immédiatement le degré de disponibilité dans l'environnement actuel. C'est-à-dire que ce sont des "exigences", pas des "exigences de changement".

3.1	Gestion des ressources
3.1.1	Responsabilité budgétaire uniforme
L'IETF a fonctionné dans des époques d'aisance financière et dans des époques de récession économique de l'industrie. Il est raisonnable de s'attendre à ce que l'avenir réserve des tendances aussi variables. Donc, il est important que l'organisation de l'IETF ait la capacité de prendre des décisions pour correspondre aux besoins à tout moment, c'est à dire à l'autonomie budgétaire. À cet instant particulier, des choix difficiles doivent être faits, et le AdvComm pense que c'est la direction de l'IETF, avec l'avis et le consentement de la communauté de l'IETF, qui doit les faire.

3.1.2	Équivalence des source de revenus
L'IETF est actuellement soutenue par l'argent provenant de plusieurs sources, incluant les redevances des réunions, les donations des branches industrielles intéressées et des entités non industrielles, et des donations en matériel ou personnels. L'IETF a besoin d'être capable de prendre en compte toutes les sources de revenu, et toutes les dépenses impliquées dans le fonctionnement de l'IETF, comme éléments d'un budget, pour être libre d'ajuster tous les éléments lorsque les revenus provenant des différentes sources varient, et pour allouer les fonds comme l'exigent raisonnablement les circonstances.

Les avertissements usuels s'appliquent : que les donations ne menacent pas l'indépendance de l'IETF, et que les donations sont plus faciles quand elles sont déductibles des impôts.

3.1.3	Clarté des relations avec les organisations de soutien
Bien que l'IETF ait besoin d'être capable de gérer ses flux de revenus en fonction de ses prévisions de dépenses, elle doit aussi respecter les besoins des organisations de soutien pour gérer leurs propres affaires. C'est-à-dire que le texte ci-dessus ne suggère pas que l'IETF devrait "micro gérer" les affaires financières des organisations de soutien.

Cependant, l'exigence très nette est en faveur de la clarté dans la répartition des droits, des responsabilités, et dans les comptes dans ces relations. Le mécanisme usuel pour documenter une telle clarté est sous forme de contrats. Donc, l'IETF a besoin de relations contractuelles claires avec les organisations qui prennent en charge les services de base, incluant l'organisation des réunions, les services de secrétariat, les services de technologies de l'information, etc.

3.1.4	Souplesse dans le provisionnement de service
L'IETF doit être capable de lever des fonds pour financer le développement de services supplémentaires comme approprié. Cela inclut le développement d'outils pour les participants, la gestion de répertoires, etc.

3.1.5	Efficacité administrative
Les besoins de l'IETF devraient être satisfaits avec le minimum de frais généraux. Cela implique qu'il doit y avoir la possibilité de combiner les efforts lorsque approprié, et d'éviter d'une façon générale la duplication des efforts.

3.2.	Intendance
Les exigences décrites ci-dessous se concentrent principalement sur les besoins de l'administration de l'IETF au jour le jour. Cependant, une gestion responsable inclut l'intendance des futurs travaux de l'IETF.

3.2.1	Responsabilité des changements
L'IETF doit être responsable des changements de sa structure administrative pour répondre à l'évolution des besoins de la communauté. À ce titre, l'administration a besoin de rester le seul responsable vis à vis de la communauté de l'IETF.

Cela signifie aussi que la répartition des responsabilités doit être claire pour la communauté de l'IETF, afin de lui permettre de commenter les actions en cours ou les plans futurs, et aussi lui permettre d'entreprendre des actions lorsque ses besoins ne sont pas traités de façon adéquate.

Cela implique que la responsabilité de la gestion financière au sein de l'IETF doit incomber aux individus qui en sont comptables au sein de la structure organisationnelle de l'IETF.

3.2.2	Persistance et accessibilité des enregistrements
Beaucoup du travail de l'IETF se concentre sur la prise de décisions et des déclarations de clôture. Cependant, la responsabilité ne s'arrête pas à la déclaration d'achèvement. Il y a toutes sortes de raisons qui font que l'histoire doit être documentée de façon adéquate afin que les travaux futurs puissent s'appuyer sur des archives substantielles, et pas seulement sur une histoire orale.

Donc, l'IETF doit tenir et prendre en charge l'archivage de tous ses documents de travail d'une façon qui continue d'être accessible pour tous les contributeurs actuels et futurs de l'IETF.

3.3	Environnement de travail
Une partie de travail d'administration de l'IETF est d'identifier les outils et l'environnement de travail nécessaire pour prendre en charge l'activité courante et de s'assurer de la continuité de leur prise en charge.

3.3.1	Automatisation du service
Chaque fois que le jugement humain n'est pas exigé pour mener à bien une action, les services devraient être automatisés pour fournir le chemin le plus libre de frictions et le délai minimal pour achever l'action.

Plus de procès pourraient être accomplis sans exiger de jugement humain. Chaque fois que possible, ces procès devraient être identifiés, précisés, et automatisés.

Noter que ceci n'est pas destiné à impliquer que TOUS les procès devraient être automatisés ! En réduisant les frictions impliquées dans les étapes qui sont réellement mécaniques, plus de temps et d'énergie seront disponibles pour traiter de façon appropriée celles qui exigent un jugement individuel.

3.3.2	Outils
Qu'ils soient hébergés dans un lieu pris en charge par l'IETF ou offert par contribution individuelle, le groupe de travail "PROBLEM" a identifié le besoin d'une plus grande prise en charge des outils pour les groupes de travail et le développement de spécifications. L'IETF doit être capable d'identifier, développer et prendre en charge un ensemble d'outils d'une richesse et d'une cohérence adéquate pour mener à bien le travail de normalisation.

4.	Avis du comité consultatif

Le comité consultatif a discuté abondamment les matériaux et les observations décrits dans le présent document. Pour le AdvComm, il apparaît clairement que des changements de l'organisation administrative de l'IETF d'un certain niveau sont nécessaires pour traiter les points de tension et satisfaire toutes les exigences mentionnées à la Section 3.

4.1	Proposition : une seule entité organisationnelle formalisée pour l'IETF
Pour s'assurer d'une structure de l'IETF qui soit capable de satisfaire les exigences mentionnées ci-dessus, le AdvComm recommande que l'IETF soit organisée de façon plus formelle. Cela permettrait que l'IETF prenne la pleine responsabilité et la gestion des ressources requises pour accomplir son travail (comme décrit au paragraphe 3.1) fournir et maintenir l'environnement de travail nécessaire pour le travail en cours (comme décrit au paragraphe 3.3) et fournir l'intendance appropriée d'informations institutionnelles requise pour tous les aspects du travail actuel et futur de l'organisation (comme décrit au paragraphe 3.2).

Certains modèles proposés pour établir un tel effort formalisé sont décrits dans les paragraphes qui suivent. Certaines des attentes clés, sans considération de la mise en œuvre finale de formalisation, sont :
o	l'administration de l'IETF resterait de la responsabilité de la direction et de la communauté de l'IETF ; le but serait de s'assurer que les lignes de responsabilité et d'imputation soient plus claires ;
o	cette IETF formalisée serait directement responsable de la gestion des ressources financières (revenus et dépenses) ;
o	cette IETF formalisée serait directement signataire des accords avec les autres organisations, et serait donc capable de négocier et administrer tous les contrats appropriés ;
o	quelle que soit la façon dont ceci est mis en œuvre, cela exigera un petit complément en personnel (par exemple, une personne à plein temps) responsable vis à vis d'aucune autre organisation que celle mandatée par la mission de l'IETF ;
o	néanmoins, il reste un non objectif de créer une entité organisationnelle qui existe simplement dans le but de continuer à exister. Cela devrait être exécuté avec le minimum de formalisme nécessaire pour satisfaire les exigences identifiées.

4.1.1	Commentaires sur la nécessité de cette formalisation
Une importante question est : qu'est ce que cette formalisation proposée fournit qui ne peut l'être par le statu quo ? Le AdvComm estime qu'une formalisation mise en œuvre de façon appropriée de l'IETF permettrait l'unification de la gestion des ressources, de la prise de décision et l'intendance qui est un besoin impératif pour donner de la clarté et assurer un futur viable à l'IETF. Le AdvComm estime de plus qu'il n'est simplement pas possible de la mettre en œuvre dans la répartition et l'arrangement informel existants des responsabilités.

Naturellement, l'acte de formation d'une telle organisation ne satisfait pas immédiatement les exigences mentionnées à la Section 3. Ce n'est pas une baguette magique. Changer la structure formelle ne va pas, par exemple, changer l'état financier de l'IETF. Cependant, le AdvComm estime que cela fournirait la base nécessaire sur laquelle les décisions requises pourraient être prises et sur laquelle on pourrait agir.

En bref, le AdvComm estime qu'on doit d'abord donner la responsabilité de définir l'environnement administratif de l'IETF aux personnes spécifiques qui en sont comptables pour la communauté de l'IETF. Ces personnes peuvent alors prendre les décisions détaillées qui vont changer l'environnement administratif de l'IETF pour satisfaire ces exigences.

4.2	Structures possibles
Le paragraphe 4.1 est délibérément vague sur la nature de l'entité organisationnelle formelle qui peut fournir l'environnement approprié, se concentrant plutôt sur les composants clés de toute mise en œuvre d'une telle formalisation, et sur comment l'activité de formalisation va traiter les exigences mentionnées à la Section 3.

Ayant donc déterminé que la formalisation de l'IETF est vue comme une étape nécessaire, le cadre de base de trois mises en œuvre potentielles est décrit s ci-dessous. Noter que ce ne sont pas des propositions complètes, et qu'il n'y a pas assez de détails disponibles pour recommander un chemin particulier. La direction de l'IETF peut en choisir un pour l'explorer plus en détail, pour formuler une proposition d'action avec des détails suffisants pour une décision d'action.

4.2.1	ISOC
L'IETF est organisée comme une activité de la Internet Society. Un chemin potentiel pour augmenter le formalisme de l'administration de l'IETF serait de mieux définir cette relation. Ce modèle anticipe sur le transfert de personnels de l'ISOC pour former le "petit complément de personnel", et rendrait l'ISOC responsable de toutes les ressources et dépenses  financière de l'IETF.

Cette approche devrait être relativement facile à mettre en œuvre, étant données les relations juridiques existantes de l'ISOC avec l'activité de l'IETF, et son statut de signataire des contrats relatifs à l'IETF (par exemple, l'éditeur des RFC).

Cette proposition est cohérente avec le but de minimiser la quantité de formalisation nécessaire pour satisfaire les exigences de l'IETF.

Cependant, la mission générale de l'ISOC est plus large que l'activité de normalisation de l'IETF, et le conseil d'administration de l'ISOC doit rester concentré sur la répartition des ressources pour remplir cette plus large mission. Cette approche permettrait elle d'avoir les claires lignes de responsabilité que la Section 3 appelle de ses vœux ?

4.2.2	Filiale de l'ISOC
Une modification de la proposition d'hébergement du corps central de l'IETF au sein de l'ISOC serait de créer une filiale à but non lucratif de l'ISOC, avec un mandat spécifiquement centré sur la mission de l'IETF. Cette filiale deviendrait l'entité légale responsable de la gestion des ressources et dépenses de l'IETF, et deviendrait signataire de tous les autres instruments légaux au nom de l'IETF.

En tant que personne juridique de plein droit, la filiale serait responsable en toute indépendance de la réalisation de sa mission. Ce niveau d'indépendance répond au souci à l'égard de la notion de mieux formaliser l'IETF directement au sein de l'ISOC – que la mission de l'IETF pourrait être dérangée par le besoin de l'organisation de pencher en faveur des autres aspects de la plus large mission de l'ISOC. Le rôle de la communauté de l'IETF, et du parent ISOC, pour définir et soutenir cette mission serait décisif pour la création de cette personne juridique.

L'IETF pourrait de plus considérer quel modèle de gouvernance serait le plus approprié pour cette approche. Si il est souhaitable de retirer une partie de la charge administrative à l'IESG et l'IAB, une telle filiale pourrait avoir son propre conseil d'administration, composé de membres appointés par l'IETF et l'ISOC. Un tel conseil serait responsable de la revue des activités et de s'assurer que les efforts de l'organisation sont bien en ligne avec sa mission, que ses finances sont en ordre, et ainsi de suite. La filiale rapporterait à son conseil d'administration. D'autres modèles de gouvernance sont certainement possibles, et un conseil d'administration n'est pas une exigence de cette approche.

En même temps, en tant que filiale, on attend des relations avec l'ISOC qu'elles restent très proches : la filiale bénéficierait de l'infrastructure et du soutien existants de l'ISOC (une approche prudente pour ajouter du formalisme et des redondances structurelles à l'activité de l'IETF) tandis que les relations continueraient à fournir un canal pour que l'IETF soutienne l'ISOC dans la réalisation de sa mission plus large, avec la poursuite de la contribution de l'expertise technique et du soutien des activités.

Cette approche exigerait plus de travail de création que le simple hébergement du travail à l'ISOC. La filiale devrait être créée et ses droits/responsabilités ajustés entre elle et l'ISOC afin de s'assurer que tous deux ont les ressources et les cadres nécessaires pour mener à bien leurs missions.

4.2.3	Entité organisationnelle complètement autonome
Pour compléter le tableau, une troisième option doit être considérée. Au lieu de créer une filiale de l'ISOC comme personne juridique distincte, une personne juridique entièrement nouvelle, "IETF, Inc.", ou "IETF, LLC", pourrait être créée dans le seul but de gérer les activités administratives de l'IETF.

Cela offrirait à l'IETF une autonomie complète avec tous les droits et responsabilités qui s'y attachent. En particulier, une IETF indépendante devrait, au minimum, fonctionner comme une "jeune pousse" pendant les quelques premières années de son existence, avec tous les problèmes de financement et de croissance qui s'y rapportent, et les risques pour la survie. Étant donnés tous les changements organisationnels qui auront lieu au sein de l'IETF durant la même période, le AdvComm estime que les risques financiers et politiques d'une telle approche ne devraient pas être sous estimés.

Par exemple, il serait nécessaire que l'IETF obtienne un capital de travail initial suffisant pour traiter les engagements des premières réunions. Bien qu'il soit concevable de lever un fond de roulement à partir d'avances sur les redevances de réunions, un tel plan de financement ne laisserait pas beaucoup de marge d'erreur ; si une ou plusieurs réunions initiales se trouvent en déficit, la survie d'une IETF agonisante serait compromise. Étant donné l'environnement économique, on ne devrait probablement pas supposer que le fond de roulement pourrait être levé uniquement par des donations d'entreprises, en particulier durant une période initiale dans laquelle le personnel requis pour solliciter et gérer les donations ne serait pas disponible.

De plus, l'impact qu'un tel mouvement aurait sur la capacité de l'ISOC à accomplir sa mission et le rang de l'IETF parmi les organisations gouvernementales doit être considéré.

4.3	Qui peut décider
Le AdvComm estime que la direction de l'IETF, agissant sur l'avis et avec le consentement de la communauté de l'IETF et de l'ISOC, a la capacité et la responsabilité d'agir selon la recommandation de formaliser l'IETF.

5.	Considérations sur la sécurité

Le présent document ne décrit aucun protocole technique et n'a pas d'implications sur la sécurité du réseau.

6.	Remerciements

Le AdvComm remercie sincèrement de leur temps, leurs efforts et leurs soins l'éditeur des RFC, l'IANA, le Secrétariat et les organisations de secrétariat pour fournir des contributions, répondre aux questions de l'AdvComm, et relire et corriger le texte de consultation montré dans les appendices.

Les membres du comité consultatif de l'IAB qui ont préparé ce rapport étaient :
o Bernard Aboba
o Harald Alvestrand (président de l'IETF)
o Lynn St.Amour (président de l'ISOC)
o Fred Baker (président du conseil d'administration de l'ISOC)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (président de l'IAB, président du comité)
o Russ Housley
o John Klensin

7.	Références pour information

[IETF]	Alvestrand, H., "IETF Chair plenary presentation", http://www.ietf.org/proceedings/03mar/slides/plenary-3/index.html , mars 2003.

[INSTR]	Reynolds, J. et B. Braden, Eds., "Instructions to Request for Comments (RFC) Authors", Travail en cours.

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, 3668, 3932, 3979, 3978, 5378, 6410, 8179)

[RFC2223]	J. Postel, J. Reynolds, "Instructions pour les auteurs de RFC", octobre 1997. (Information ; Remplacée par RFC  7322 ; MàJ par RFC  5741, RFC  6949)

[RFC2555]	Éditeur des RFC, et autres, "30 ans de RFC", avril 1999. (Information)

[RFC2860]	B. Carpenter et autres, "Mémorandum d'accord sur le travail de l'IANA", juin 2000. (Information)

[RFC3233]	P. Hoffman, S. Bradner, "Définir l'IETF", février 2002. (BCP0058)

Appendice A.	Mandat du comité consultatif de l'IAB

Date : mardi 2 septembre 2003 16:34:58 -0400
De : Leslie Daigle
Objet : Formation d'un comité consultatif de l'IAB
Pour : Annonce à l'IETF ;

J'ai le plaisir d'annoncer la formation d'un comité consultatif de l'IAB, décrit ci-dessous.

Merci,
pour l'IAB, 
Leslie,

=================

Comité consultatif de l'IAB sur les relations d'administration de l'IETF

L'objet du comité est de revoir les relations d'administration existantes de l'IETF (éditeur des RFC, secrétariat de l'IETF, etc.) et de proposer des changements aux processus ou structures de gestion de l'IETF qui pourraient améliorer le fonctionnement global de l'IETF. Toute proposition sera soumise à revue et acceptation par l'IAB et la plénière de l'IETF. Noter que le mandat du comité consultatif N'INCLUT PAS de proposer des changements au processus de développement des normes (par exemple, à l'organisation des groupes de travail, à la gestion des documents ou des groupes de travail par l'IESG, etc.).

Le comité est présidé par le président de l'IAB, Leslie Daigle, et se compose de :
o Bernard Aboba
o Harald Alvestrand (président de l'IETF)
o Lynn St.Amour (président de l'ISOC)
o Fred Baker (président du conseil d'administration de l'ISOC)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (président de l'IAB, président du comité)
o Russ Housley
o John Klensin

Les apports supplémentaires sont les bienvenus. Le comité fera aussi un effort particulier pour rechercher d'autres apports si nécessaire.

Appendice B.	Apports des présidents actuels de l'IETF et de l'IAB

Contributions de Harald Alvestrand (président de l'IETF) et de Leslie Daigle (président de l'IAB).

Quand on regarde le compte rendu de l'activité administrative de l'IETF, un certain nombre de choses fonctionnent bien :
o	les organisations de soutien sont engagées dans le travail de l'IETF ;
o	les volontaires des groupes de travail de l'IETF peuvent (pour la plupart) se concentrer sur leur travail d'ingénierie, et pas sur de l'économie ;
o	l'argent n'a pas (jusqu'à présent) été suffisant pour couvrir les frais.
Cependant, il y a aussi un certain nombre de défis :
o	l'absence d'archives persistantes des efforts de l'ensemble de l'organisation – des documents de travail, des matériaux des réunions, des communications. Aussi,
*	le manque d'organisation des archives – même lorsque des données sont mémorisées, il peut être difficile ou impossible d'y accéder lorsque elles ne sont plus en cours (par exemple, elles peuvent résider sur le disque dur d'un ancien président du groupe de travail) ;
*	les enregistrements d'historique sont pointillistes (listes des présidents de groupe de travail et anciennes versions de leurs mandats, pour en mentionner quelques uns) ;
o	peu de sauvegardes contre le problème "écrasé par un bus" – beaucoup d'informations sur les relations ne sont pas documentées, et doivent être transférées par la tradition orale. Cela signifie qu'un recouvrement significatif est nécessaire lorsque le personnel change ;
o	les responsabilités de la direction de l'IETF ne sont pas clairement identifiées – normalement traitées par les présidents de l'IETF et de l'IAB, avec l'avis et le consentement de l'IESG et de l'IAB, mais cela rend possible de remettre en cause toute décision de changement ;
o	les contrats n'identifient pas clairement la responsabilité de la direction exécutive. Certaines relations contractuelles ne sont pas documentées, ou ne sont pas visibles pour la direction de l'IETF ;
o	une documentation variable, et souvent peu claire des responsabilités entre la direction de l'IETF et les autres organisations. Cela rend difficile de déterminer comment et où discuter et effectuer des améliorations pour l'IETF qui affectent l'activité d'une ou plusieurs des organisation de soutien ;
o	des responsabilités budgétaires obscures – la direction de l'IETF doit prendre des décisions qui vont impacter les revenus et les coûts des organisations de soutien, mais celles-ci supportent les effets directs du contrôle des revenus et des coûts. Les informations sur l'impact financier des décisions ne sont pas disponibles pour la direction de l'IETF ;
o	partition des finances -- il n'est pas possible à l'IETF de faire des changements qui affecteraient l'équilibre des revenus et des coûts à travers les engagements de sources de revenu/dépense. Par exemple, augmenter les redevances de réunions ne va pas payer des ressources pour l'éditeur des RFC ; plus de soutien de la part de l'ISOC ne règle aucun besoin des fonctions de soutien de groupe de travail de l'IETF ;
o	le manque de clarté et le partage rendent très difficile à la direction de l'IETF, et à la communauté dans son ensemble, de déterminer les points de responsabilité et de mettre en œuvre des changements pour une bonne santé future.
Appendice C.	Consultation de ISI : éditeur des RFC

Note : "RFC2223bis" dans ce texte se réfère à [INSTR], un travail en cours pour mettre à jour la [RFC2223].

Réponses aux questions du comité consultatif de l'IAB sur l'éditeur des RFC, 6 octobre 2003

1)	Description de la fonction que vous remplissez. Cette fonction, et ses relations avec l'IETF, est elle adéquatement décrite dans la RFC 2223bis, ou une description supplémentaire est-elle requise ? Dans ce cas, quelles sont vos suggestions ?

Réponse : un résumé complet des fonctions actuelles de l'éditeur des RFC est inclus ci-dessous. Noter que cette liste n'a pas de relation directe avec la RFC 2223bis, qui contient des instructions pour les auteurs de RFC.

2)	Quels sont les personnels utilisés pour effectuer ces fonctions et quelles sont leurs compétences particulières pour les assurer (individuellement ou en groupe) ?

Réponse : pendant 30 ans, l'éditeur des RFC était Jon Postel, un chercheur scientifique et cadre de la division Réseautage de l'Institut des sciences de l'information de l'Université de Californie du Sud (USC/ISI, Information Sciences Institute). Il est actuellement organisé comme projet au sein de ISI, utilisant l'infrastructure de ISI. Les membres du personnel de ISI suivants composent le projet "Éditeur des RFC" :
Joyce Reynolds : 100 %
Bob Braden : 10 %
Aaron Falk : 10 %
Sandy Ginoza : 100 %
Assistant de projet : 100 %
Assistant de recherche diplômé : 50 %

Braden et Reynolds gèrent conjointement le projet "Éditeur des RFC", avec la supervision du personnel et des budgets.

Joyce Reynolds contribue par ses compétences rédactionnelles et de gestion à l'Internet depuis 1979. Elle a effectué les fonctions de l'IANA sous la direction de Jon Postel de 1983 au décès de Postel en octobre 1998. Elle a continué d'effectuer les tâches de gestion des paramètres de protocole de l'IANA en vertu d'un prêt de l'ISI à l'ICANN, de 1998 à 2001. Elle a été la liaison de l'IANA à l'IESG de 1998 à 2001, avec transition du rôle à Michelle Cotton en 2001. Reynolds a effectué les fonctions d'éditeur des RFC sous la direction de Jon Postel de 1987 à 1998. Reynolds a été membre de l'IETF depuis 1988, et elle a exercé la fonction de directeur de la zone Services d'utilisateur à l'IESG pendant 10 ans. Reynolds assure maintenant la liaison avec l'IAB et l'IESG. Elle assure la relecture finale des épreuves et le contrôle de qualité sur les RFC avant publication.

Bob Braden a fait de nombreuses contributions à la technologie du protocole Internet et à la communauté. Il a aidé à la conception de TCP/IP durant la période de recherche d'origine commençant en 1978, et il a consacré sa carrière professionnelle depuis 1978 à l'Internet. Il a servi pendant 13 ans dans l'IAB d'origine et comme son directeur exécutif pendant environ cinq ans. Depuis 1998, Braden a été co-dirigeant du projet "Éditeur des RFC". Il est le principal réviseur des soumissions individuelles. Il travaille aussi sur des questions techniques en rapport avec le projet "Éditeur des RFC".

Aaron Falk est un acteur significatif dans l'IETF comme président de groupe de travail, dans le domaine des protocoles de transport et des technologies par satellite. Dans l'équipe de l'éditeur des RFC, il s'occupe des questions de politique et traite le développement technique, supervisant le travail de l'étudiant programmeur diplômé.

Sandy Ginoza est le principal éditeur technique. Elle est généralement chargée de gérer la file d'attente de l'éditeur des RFC et beaucoup de l'interface quotidienne avec l'IESG et les auteurs. Ginoza envoie et reçoit énormément de messages, et elle jour un rôle central dans le fonctionnement.

Des assistants de projet à mi-temps, Mieke Van de Kamp et Alison De La Cruz, font l'édition, le balisage, et les épreuves initiales des RFC individuelles. Notre but est d'avoir trois paires d'yeux qui lisent mot à mot chaque RFC, et dans la plupart des cas, on est capables de le faire.

Un assistant de recherche diplômé de l'USC fournit à mi-temps un soutien à la programmation en développant, étendant, et entretenant les scripts et outils de l'éditeur des RFC.

3)	Quels critères utilisez vous pour déterminer si vous avez réussi, et de quelle façon vous réussissez ? En utilisant ces critères, quelle est l'étendue de votre réussite et que pourrait-il être fait, en particulier du côté de l'IETF, pour améliorer cette évaluation ?

Réponse : On peut commencer par une perspective historique de la question. Quand Jon Postel est décédé de façon inattendue il y a 5 ans, Reynolds et Braden ont relevé le défi d'assurer la fonction d'éditeur des RFC de Postel. Le flux de publication a continué, avec une modeste augmentation quantitative et, nous le pensons, pas de perte de qualité. De plus, la transition a été largement invisible pour l'IETF. Le nouveau projet d'éditeur des RFC a défini et précisé de façon significative le processus de publication, amélioré le site de la Toile, ajouté des outils pour améliorer la productivité et la qualité, et adapté les procédures à des réalités changeantes. Nous sommes fiers de ces réalisations.

Les trois axes principaux pour mesurer le succès de l'éditeur des RFC sont a) quantité, b) qualité, et c) accessibilité.

a) Quantité
En gros, le succès quantitatif signifie la capacité à rester en phase avec le taux de soumissions. Comme le taux de soumissions tend à être saccadé, pour éviter de longs délais, on a besoin d'une capacité moyenne qui excède un peu la moyenne. La publication des RFC est nécessairement un processus lourd de travail intensif. Notre but est généralement d'achever le processus de publication en moins de quatre semaines, à l'exclusion des facteurs externes qui échappent à notre contrôle – la dépendance normative à d'autres documents, les retards des auteurs ou de l'IESG, de l'IANA, etc.

b) Qualité
La qualité des publications est plus difficile à mesurer, mais "on la connaît quand on la voit". En considérant la qualité comme l'absence de fautes, on note les fautes qu'on peut observer comme un manque de qualité. Une mesure des fautes est le nombre d'errata qui apparaissent après la publication. De plus, il peut y avoir des fautes qui sont apparentes au lecteur, comme un titre sans signification, une organisation confuse, un résumé inutile, une introduction inadéquate, un formatage trompeur, des phrases mal construites, ou une mauvaise grammaire. Il y a bien sûr des limites à notre capacité à réparer une mauvaise rédaction ; en fin de compte, la qualité dépend des auteurs autant que du processus d'édition. La seule façon de maintenir la qualité est de surveiller continuellement notre travail en interne, de suivre les plaintes externes, et d'ajuster notre pratique pour corriger les fautes fréquentes. Les fautes spécifiques nous ont parfois conduit à créer de nouveaux outils pour vérifier la cohérence, pour éviter des erreurs bureautiques. Parfois, elles ont conduit à de nouvelles lignes directrices pour les utilisateurs (par exemple, sur les abréviations ou sur les sections de résumé.)

c) Accessibilité
Une part importante de la fonction d'éditeur des RFC consiste à fournir une base de données pour localiser les RFC pertinentes. C'est en fait un problème très difficile, parce qu'il y a souvent une sémantique complexe de la Toile parmi les RFC sur un sujet particulier. Nous avons apporté de grandes améliorations à notre moteur de recherches et au site de la Toile, mais il y a indubitablement un besoin de plus de progrès dans ce domaine. Le défi est de fournir de meilleurs postes  de guidage aux utilisateurs sans créer d'exigences significatives d'augmentation de la force de travail. Nous avons fait une grosse utilisation de nos propres outils de recherche et d'accès, et cela nous donne un retour sur leur succès et parfois nous suggère des améliorations.

Finalement, nous proposons des suggestions spécifiques pour répondre à la question, "que peut faire l'IETF pour améliorer l'évaluation de l'éditeur des RFC (c'est-à-dire, notre service à la communauté) ?"
1.	Nous donner de meilleurs documents à publier. Beaucoup sont bien écrits et organisés, mais certains sont mauvais et quelques uns sont très mauvais et ont besoin de beaucoup de travail pour créer des publications acceptables. De meilleurs documents en entrée améliorerait à la fois notre quantité et notre qualité. L'IESG a fait de gros efforts pour améliorer la qualité de projets Internet avant qu'ils deviennent des RFC, et nous leur en sommes reconnaissants. Un problème particulièrement préoccupant est le nombre croissant de RFC dont les auteurs ne sont pas anglophones. Cela peut consommer beaucoup d'efforts d'édition supplémentaires. On ne connaît aucune solution à ce problème, mais nous savons que l'IESG en est conscient et travaille avec eux pour fournir une assistance rédactionnelle lorsque nécessaire au sein des groupes de travail.
2.	Préparer une série de RFC contenant des "feuilles de route" qui décrivent la toile sémantique des RFC dans un domaine particulier. Bien que cela devienne rapidement périmé dans les détails, cela fournirait quand même de très importantes lignes directrices pour les lecteurs de RFC.

L'éditeur des RFC est aussi critique vis à vis de lui-même que n'importe quelle organisation peut l'être, mais nous pensons qu'il n'y a pas de base objective à prétendre que nous ne faisons pas du bon travail pour l'Internet. Nous nous efforçons continuellement à faire mieux.

4)	Comment pourriez vous caractériser la qualité de vos relations avec l'IETF et sa direction ? Y a t-il confiance mutuelle et un sens du travail en commun sur les problèmes, ou percevez vous parfois, vous et vos collègues, ces relations comme celles d'adversaires ?

Réponse : l'éditeur des RFC partage avec une grande partie de la communauté de l'Internet un profond désir de faire avancer la technologie et la pratique de l'Internet. Nous nous considérons comme les partenaires de l'IETF, de l'IESG, et de l'IAB dans cette entreprise.
Bien que les objectifs majeurs coïncident, l'IESG et l'éditeur des RFC ont très normalement des priorités assez différentes. Le rôle de l'éditeur des RFC, historiquement et actuellement, est de créer et conserver la série de documents de RFC comme un canal de haute qualité et vital pour la communication technique, tandis que l'IESG est concerné par la gestion de l'ingénierie de l'Internet et le processus de normalisation. Cette différence conduit parfois à des désaccords honnêtes, mais on trouve généralement des solutions mutuellement satisfaisantes à ces conflits. Le terme "adversaire" semble complètement inapproprié, et nous ne comprenons pas ce qui a pu conduire à ce qu'il apparaisse ici.

5)	Y a-t il des problèmes connus spécifiques que vous souhaiteriez nous faire découvrir et comprendre ? S'il en est, pouvez vous les décrire ?

Réponse :
(A)	Le temps que met l'IESG pour revoir et faire des recommandations sur les soumissions individuelles paraît parfois  excessif. Nous comprenons la charge des membres de l'IESG, mais nous aimerions qu'ils nous aident à tenir le délai de réponse à quelques mois. L'éditeur des RFC a tenté d'élever la barre d'acceptation des soumissions individuelles, pour éviter de gaspiller le précieux temps de l'IESG ainsi que pour maintenir (ou améliorer) la qualité de la série des RFC.

(B)	 Nous aimerions comprendre et soutenir la responsabilité statutaire et historique de l'éditeur des RFC de publier des documents techniques significatifs sur le réseautage dont l'origine est extérieure au processus de normalisation de l'IETF. Cette publication a plusieurs objets importants. L'un d'eux est de faire connaître de nouvelles idées techniques pour qu'elles soient prises en considération et discutées. Nous pensons que le futur succès de l'Internet demande une infusion de nouvelles idées (ou de vieilles idées revitalisées) et que la publication de telles idées comme RFC est importante. Un autre objet est de construire une littérature partagée de discussions techniques mûres, pour aider à éviter des rediscussions périodiques qui ont lieu sur nos listes de diffusion. Finalement, la série des RFC fournit un répertoire historique des idées importantes. Nous avons un nombre considérable d'exemples de suggestions importantes et de développements technologiques partiels qui ont été perdus, ou sont difficiles à localiser, parce qu'elles n'ont pas été publiées comme RFC. La communauté passe trop de temps à réinventer la roue, de nombreuses roues. Notre but ultime est de publier plus de soumissions de haute qualité, de sorte qu'on puisse relever la barre pour la publication. Les publications de soumissions indépendantes représentent seulement une fraction mineure de la production de RFC. Par exemple, jusqu'à présent dans le calendrier 2003 nous avons publié 178 RFC, incluant 14 soumissions indépendantes. Si tous les projets dont nous pensons qu'ils méritent d'être préservés comme RFC devaient être publiés, cette fraction croîtrait, mais nous ne pensons pas que cela dépasse 25  % du nombre total de RFC publiées.

(C)	Nous aimerions travailler avec l'IAB/IESG à réexaminer la question des références normatives. Nous pensons que la définition actuelle de normatif est ambiguë et peu claire, et qu'il en résulte que certaines publications peuvent inutilement être tenues pour des références normatives alors que elles ne sont pas nécessaires.

(D)	Nous aimerions coopérer à des investigations sur la question de l'extension du jeu de caractères au delà de l'US-ASCII, par exemple, à UTF-8. Une question majeure est de savoir si il y a un ensemble d'outils de préparation, affichage, et recherche à la fois pour l'éditeur des RFC et les consommateurs de RFC. Ces outils doivent être disponibles partout et d'une maturité suffisante.

L'éditeur des RFC cherche des idées sur la meilleure façon de continuer à servir la communauté. Nous remercions des suggestions que nous avons reçues, et nous avons adopté autant d'elles qu'il était faisable ; le résultat a été une assez longue liste d'améliorations successives de notre service sur les cinq dernières années.

(6)	Comment voyez vous l'évolution des coûts de votre fonction ? Si les choses deviennent plus coûteuses avec le temps, quels sont les principaux déterminants du coût (par exemple, l'inflation générale, la croissance générale de l'IETF, l'augmentation du nombre de fonctions particulières que vous avez entrepris d'effectuer,...). Faites vous des choses que l'IETF (l'IESG ou autres) demande, que vous ne considérez pas comme en valant la peine et, si il en est, quelles sont elles ?

Réponse : le facteur de coût majeur est le nombre de documents soumis et publiés. Cela a crû relativement lentement au fil du temps. Il nous apparaît que le processus de l'IETF a (peut-être heureusement) été le goulet d'étranglement qui a gardé le taux de production des RFC contre une croissance exponentielle. On ne s'attend pas à ce que cela change radicalement.
Plus en détails, les facteurs de coût sont :
(a) l'inflation (sur les salaires). Ils montrent une petite augmentation annuelle prévisible.
(b) le nombre de RFC publiées. C'est le premier facteur de coût. Le gros des fonctions éditoriales et de coordination est directement attribuable à des documents spécifiques. À présent, on estime que cette catégorie de coûts représente 70  % de notre temps en personnel, et 63  % de nos coûts.
(c) Tâches non directement reliées à des RFC spécifiques. Cela inclut de nombreuses fonctions : gestion (budget et personnel ainsi que développement de politiques et procédures) liaison avec l'IETF, revue des soumissions indépendantes, développement et maintenance des pages de la Toile, scripts, et outils, le projet RFC en ligne, maintenance de la page des Errata de la Toile, etc. Elles sont actuellement estimées exiger 30  % de notre temps en personnel, et 37  % de nos coûts.
Des extensions mineures de fonction peuvent être absorbées avec un faible coût supplémentaire (mais à un rythme modéré). Nous ne proposons aucune extension fonctionnelle majeure pour l'instant ; de telles extensions devraient être chiffrées séparément (lorsque de l'argent sera disponible pour elles).

La mémorisation sur disque et les services de la Toile sont fournis par l'organisation de soutien de ISI et sont traitées comme des frais généraux. La plupart des machines de bureau utilisées par le projet ont à l'origine été achetées sous des contrats de recherche, bien que le budget de l'éditeur des RFC inclue une très petite ligne pour les mises à niveau de l'équipement.

C.1	Fonctions d'éditeur des RFC
Vue d'ensemble
L'éditeur des RFC édite et publie les archives de la série des documents RFC (à l'origine "Demandes de commentaire"). Les RFC forment une série d'archive de mémoires sur la communication informatique et les réseaux de commutation de paquets enregistrant l'histoire technique de l'ARPAnet et de l'Internet, qui commence en 1969. L'éditeur des RFC est financé par la Internet Society et fonctionne sous la direction générale du Bureau d'architecture de l'Internet (IAB, Internet Architecture Board).

L'éditeur des RFC publie les RFC et un index électronique maître de la série des RFC sur l'Internet, via tous les protocoles d'accès courants (actuellement, la Toile, la messagerie électronique, rsync, et FTP). Il annonce l'existence de chaque nouvelle RFC via message électronique à une ou plusieurs listes de diffusion. L'éditeur des RFC maintient un site de la Toile complet avec divers outils et listes pour localiser et accéder aux RFC. Ce site de la Toile contient aussi des informations générales sur les politiques éditoriales des RFC, l'état de la file d'attente de publication, les errata, et toutes les autres informations qui rendent la série des RFC plus accessible et plus utile.

Durant le processus d'édition des RFC, l'éditeur des RFC s'efforce à la qualité, la clarté, et la cohérence du style et du format. Les lignes directrices et procédures éditoriales pour réaliser ces fins sont établies par l'éditeur des RFC après consultation de l'IAB et du groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group). L'éditeur des RFC publie périodiquement une révision de ces lignes directrices aux auteurs.

L'éditeur des RFC se coordonne étroitement avec l'IESG pour mener à bien le processus de normalisation de l'Internet comme documenté dans la dernière révision de "Le processus de normalisation de l'Internet" et ses derniers amendements. L'éditeur des RFC se coordonne aussi étroitement avec l'Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) pour s'assurer que les paramètres utilisés dans les nouvelles descriptions de protocole et leurs révisions sont proprement enregistrés.

Tâches spécifiques

I. Édition et publication des RFC
(1)	Processus de publication. L'éditeur des RFC édite et publie les RFC conformément à la [RFC2026] (ou les documents qui la remplacent) et la RFC 2223bis. Cela inclut les tâches suivantes :
(a)	Effectuer l'édition finale des documents pour maintenir la cohérence du style, des standard rédactionnels, et la clarté. Au minimum, l'éditeur des RFC :
(i)	Copie/édite les documents, incluant la correction des fautes de frappe et de grammaire, et la vérification des incohérences de notation. Les phrases ambiguës sont résolues avec les auteurs.
(ii)	Applique les règles de formatage de la Section 3 de la RFC 2223bis
(iii)	S'assure que les divisions du texte suivent les lignes directrices de la Section 4 de la RFC 2223bis.
(iv)	Vérifie la cohérence des références et citations, et vérifie le contenu des références aux RFC et projets Internet.
(v)	Vérifie que toutes les dépendances normatives sont bien satisfaites.
(vi)	Vérifie que les lignes directrices de la Section 2 of RFC 2223bis sont suivies à l'égard des URL, des titres, des abréviations, des considérations relatives à l'IANA, à la liste des auteurs, et des mots de niveau d'exigence.
(vii)	Formate les documents dans le style standard des RFC.
(viii)	Vérifie la correction des fragments de MIB et d'ABNF publiés, en utilisant des compilateurs.
(b)	Donner aux auteurs une période de revue d'au moins 48 heures pour approuver le document.
(c)	Publier les nouvelles RFC en ligne en les installant dans l'archive officielle des RFC, qui est accessible via HTTP, FTP, et SMTP. L'éditeur des RFC fournit aussi des fichiers compressés agrégés de sous ensembles de la série complète des RFC, accessible via HTTP et FTP. Les fac-similés PDF sont aussi conservés pour toutes les RFC .txt.
(d)	Annoncer publiquement la disponibilité des nouvelles RFC via une liste de diffusion.
(e)	Se coordonner avec l'IANA pour l'allocation des valeurs de paramètre de protocole pour les RFC de la file d'attente de soumission.
(f)	Se coordonner étroitement avec l'IESG pour s'assurer que les règles de la RFC 2026 (ou ses remplaçantes) sont suivies. Le personnel de l'éditeur des RFC participe aux réunions de l'IETF. Une personne désignée de l'éditeur des RFC sert de liaison avec l'IAB et l'IESG.
(2)	Publication des soumissions individuelles. L'éditeur des RFC publie les documents utiles et techniquement compétents qui proviennent d'ailleurs que le procès IETF, en accord avec la RFC 2026. L'éditeur des RFC a la décision finale sur la "publicabilité" de tels documents, avec revue par l'IESG et avis de personnes compétentes. L'éditeur des RFC revoit tous ces documents pour qu'ils aient une qualité éditoriale acceptable et quant à leur contenu, et travaille avec les auteurs lorsque nécessaire pour relever la qualité à un niveau acceptable.
(3)	Méta informations en ligne sur les RFC. L'éditeur des RFC publie les informations d'état suivantes via la Toile et FTP.
(a)	Une liste de toutes les RFC actuellement publiées, incluant les informations bibliographiques complètes et le statut des documents. Cette liste est publiée sous les deux formes lisibles par l'homme et par la machine (XML).
(b)	Un document consistant en résumés des RFC dans chaque gamme de 100.
(c)	Une liste des erreurs trouvées dans les RFC publiées.
(d)	Une "file d'attente de l'éditeur des RFC" spécifiant l'étape de chaque document qui se trouve dans le processus d'édition, revue, et publication.
(e)	Un site de la Toile de l'éditeur des RFC qui contient :
(i)	un moteur de recherche pour les RFC,
(ii)	des informations sur le processus de publication des RFC,
(iii)	des liens avec les éléments publiés ci-dessus.
(4)	Interrogations publiques. Répondre, et lorsque approprié, rediriger, à une large gamme d'interrogations pour courrier électronique reçues dans la boîte aux lettres de l'éditeur des RFC.

II. Amélioration des procès et infrastructures. Quand les ressources le permettent, l'éditeur des RFC améliore ses procès et son infrastructure de répertoires de RFC. Cela inclut des améliorations et extensions à l'ensemble de scripts utilisés par l'éditeur des RFC : (i) pour maintenir ses bases de données et pages de la Toile, et (ii) pour augmenter l'efficacité et la qualité du processus d'édition. Les changements dans la procédure sont souvent suggérés par les membres de l'IETF aussi bien que de l'IESG. Voici des exemples de changements qui sont en cours ou ont été suggérés pour une possible action à l'avenir.
(1)	Processus de publication :
(a)	Accepter les documents en codage XML lorsque ils sont accompagnés d'un outil qui va produire le balisage nroff.
(b)	Étudier la faisabilité d'édition en forme XML des documents soumis, avant la production des versions nroff et .txt finales.
(c)	Adopter des outils supplémentaires pour vérifier les langages de spécification formelle utilisés dans les RFC en plus des MIB, PIB, et ABNF.
(2)	Accessibilité et qualité de la base de données.
(d)	Améliorer l'utilisabilité des informations d'errata.
(i)	Distinguer les simples erreurs typographiques des erreurs de substance.
(ii)	Lier les errata à l'index des RFC sur la page de la Toile.
(e)	Fournir une vue des RFC "améliorée" s'appuyant sur la Toile, qui inclurait :
(i)	des liens sur les autres RFC en rapport et les références,
(ii)	des liens de et vers les pages d'errata en ligne.
(3)	Maintenir un répertoire en ligne des valeurs corrigées des MIB qui ont été publiées dans les RFC.
(4	Compléter le projet RFC en ligne, pour amener en ligne les RFC précoces qui ne sont disponibles que sous forme papier.

Appendice D.	Consultation de Foretec/CNRI : secrétariat et programmation des réunions

Réponses du Secrétariat aux questions d'un comité consultatif de l'IAB, 7 novembre 2003

(1)	Description de la fonction que vous remplissez. Cette fonction, et sa relation avec l'IETF, est elle comprise de façon adéquate pour les besoins du travail, ou une description supplémentaire est-elle requise ? Si oui, que suggérez vous ?

Le travail du Secrétariat est divisé en quatre parties : programmation des réunions, soutien aux groupes de travail, soutien à l'IESG, et soutien à la communauté de l'IETF.

Le programme des réunions de l'IETF inclut d'identifier les lieux de réunion, de négocier les contrats, de travailler en étroite collaboration avec les présidents de groupe de travail et l'IESG pour programmer les événements et éviter des conflits, de préparer les agendas pour les sessions des groupes de travail, d'arranger les F&B et AV, de traiter les réservations, de chercher et inscrire les hôtes, de fournir des accès Internet, une salle de terminaux, et un réseau sans fil lorsque un hôte n'est pas disponible, de fournir le soutien sur site, et de préparer les comptes rendus. La programmation des réunions peut aussi inclure d'organiser les retraits de l'IESG.

Le soutien aux groupes de travail inclut de maintenir et mettre à jour les mandats, les étapes, et autres informations pour les 140 et plus groupes de travail, de chercher les changements de présidents, d'héberger et archiver les listes de diffusion de discussion, et de traiter les demandes de publication des projets Internet comme RFC.

Le soutien à l'IESG inclut de fournir tout le soutien requis pour les téléconférences de l'IESG, qui ont lieu toutes les deux semaines et couvrent jusqu'à vingt documents et plus chacune (c'est-à-dire, de traiter les "derniers appels", de préparer les agendas et paquetages, de modérer la téléconférence, de préparer le compte rendu, d'envoyer les annonces d'approbation, et de mettre à jour les informations dans le traceur de projets Internet) de suivre les mouvements de projet Internet en RFC, d'assurer l'interface avec l'éditeur des RFC, d'effectuer les fonctions administratives associées à la création des groupes de travail, de revoir les mandats et les clôtures, de faire la maintenance des pages du site interne de l'IESG, d'envoyer divers messages à la liste d'annonces de l'IETF au nom de l'IESG, et de les poster sur le site de la Toile, lorsque applicable (par exemple, les appels à l'IESG et les réponses de l'IESG aux appels) de fournir le soutien au NomCom, comme nécessaire (c'est-à-dire, d'envoyer les annonces, d'héberger/mettre à jour le site de la Toile, de faire les arrangements pour les appels en conférence) et de développer les outils fondés sur la Toile pour soutenir la prise de décisions de l'IESG.

Le soutien à la communauté de l'IETF inclut de faire fonctionner les réunions de l'IETF, d'héberger le site de l'IETF, et de le garder à jour, d'héberger les listes d'annonce et de discussion de l'IETF, de répondre aux demandes envoyées au secrétariat de l'IETF, au directeur exécutif, au gestionnaire des réunions, au registraire, au responsable informatique, et aux systèmes de tickets de problèmes, de traiter les notifications de droits de propriété intellectuelle, de traiter les déclarations de liaison, et d'envoyer les projets Internet.

(2)	Quel personnel est utilisé pour accomplir ces fonctions et quelles aptitudes particulières faut-il pour le faire (individuellement ou collectivement) ?
-- Trois personnes effectuent les fonctions administratives.
-- Quatre personnes et demi effectuent le soutien technique.
-- Une personne et demi font du développement.
-- Trois personnes font la maintenance.

(3)	Quels critères utilisez vous pour déterminer si vous réussissez, et comment cous réussissez ? En utilisant ces critères, quel est votre taux de succès et que pourrait-il être fait, en particulier du côté de l'IETF, pour améliorer cette évaluation  ?

La poursuite du fonctionnement et de l'évolution efficace de l'Internet est un but et un défi important auquel fait face l'IETF, et aussi le secrétariat de l'IETF. Travailler ensemble pour aider l'IETF à réaliser cette importante fonction a été un facteur de motivation du soutien de CNRI depuis presque 15 ans. Les critères suivis par CNRI, et (plus récemment) sa filiale Foretec, dans leurs efforts au nom de la communauté Internet entière est de fournir un mécanisme cohérent et digne de confiance qui permette aux personnes intéressées par les questions nombreuses et variées qui sont soulevées au sein de l'IETF pour effectuer leur important travail dans le processus de normalisation de l'Internet sans être dérangées par les tâches de routine administrative associées à de telles entreprises. Bien que je pense que cette activité a été un succès pendant de nombreuses années, il y a toujours de la place pour des améliorations; et un dialogue constant entre CNRI, ISOC, et la direction de l'IETF est utile pour cela. Haut sur ma liste de suggestions serait de trouver un moyen pour augmenter les fonds disponibles pour satisfaire les demandes croissantes adressées au Secrétariat. Nous ne pouvons plus dépendre des seules redevances de participation aux réunions pour cela.

(4)	Comment caractériseriez vous la qualité de vos relations avec l'IETF et sa direction ? Y a t-il une confiance mutuelle et le sentiment d'un travail commun sur les problèmes, ou vous et vos collègues voyez vous parfois ces relations comme d'opposition ?

Bien qu la direction de Foretec puisse avoir des problèmes résultant des demandes du flux de travail quotidien sur des ressources limitées, CNRI attache du pris aux relations de confiance que nous avons eu avec la communauté de l'IETF. Le problème est de coopérer au développement de nouvelles sources de financement, et d'apprendre à vivre avec les ressources disponibles. Il y a aussi un problème quant aux lignes effectives d'autorité pour les besoins de l'exécution de certains aspects du processus global de normalisation. Il y a beaucoup de demandes et de pressions sur l'IESG et donc sur le Secrétariat. Cette demande de la part du flux de travail doit être traitée d'une façon plus systématique pour le bénéfice de tous.

(5)	Y a t-il des problèmes spécifiques connus que vous aimeriez approfondir et comprendre ? Pouvez vous les décrire ?.

La charge de travail est élevée. Étant données les contraintes budgétaires subies par le Secrétariat, il n'y a pas de ressources pour accepter du travail supplémentaire. Le personnel qui soutient tous les domaines est en surcharge juste pour faire face à la charge actuelle. Le Secrétariat ne croit pas que la communauté de l'IETF apprécie la portée de la tâche. Le Secrétariat automatise plus de tâches, réduisant heureusement la charge globale. Il y a une longue file d'attente de demandes pour de nouvelles caractéristiques des outils que le Secrétariat a construit. Il n'y a plus d'argent pour embaucher plus de développeurs. Le directeur exécutif de l'IETF est en train de documenter les procès. Cela a naturellement causé une discussion sur savoir si les procès sont ce que tout le monde veut que les procès soient. Bien que cela soit prévu, cela aussi augmente la charge de travail.

(6)	Comment voyez vous évoluer les coûts de votre fonction ? Si les choses deviennent de plus en plus coûteuses avec le temps, quels sont les principaux déterminants du coût (par exemple, l'inflation générale, la croissance générale de l'IETF, l'augmentation du nombre de fonctions particulières que vous vous trouvez exécuter,...). Faites vous des choses que demande l'IETF (l'IESG ou autres) que vous ne considérez pas comme en valant la peine et, si il en est, quelles sont elles ?

Le budget total pour les activités relatives à l'IETF à Foretec l'an dernier était d'environ 2,5 M$. Le plus gros était couvert par les redevances de réunions de l'IETF, mais le déficit a été couvert par des contributions provenant de CNRI et Foretec. Le conseil d'administration de CNRI a demandé de trouver une solution à ce problème.

Appendice E.	Consultation de l'ICANN : allocation des paramètres de protocoles par l'IANA

Réponses aux questions du comité consultatif de l'IAB sur la fonction d'allocation des paramètres de protocoles par l'IANA le 7 novembre 2003.

(1)	Décrivez la fonction que vous remplissez. Cette fonction, et ses relations avec l'IETF, sont elles adéquatement décrites dans la [RFC2860] (le MOU) et la RFC 2434 (Lignes directrices pour les considérations sur l'IANA), ou une description supplémentaire est elle requise ? Dans ce cas que suggérez vous ?

Selon Michelle Cotton, (IANA), la RFC 2860 reste probablement suffisante comme MOU pour décrire les fonctions que l'IANA assure pour l'IETF. Cet office consiste, bientôt effectifs, en un gestionnaire, trois personnels de bureau techniques (quatre équivalents à temps plein) plus une demi douzaine de personnes agissant en tant que consultants, assurant des fonctions pour l'IETF et les RIR. La portion de cet effort qui soutient l'allocation des paramètres de l'IETF est en gros d'un équivalent à temps plein plus un soutien logiciel et les frais généraux normaux de gestion/emploi. Fondamentalement, la fonction d'allocation des paramètres de l'IETF consiste à accepter les demandes de numéros des protocoles pour les protocoles extensibles (comme le protocole IP, les PID PPP, les accès TCP/UDP, et autres) à les valider conformément aux règles, à identifier le registre approprié, et dans certains cas une portion d'un registre, à allouer le numéro, et à documenter le résultat.

La RFC 2434 a bien servi le personnel de l'IANA comme guide, mais a maintenant besoin d'être mise à jour. Un souci  spécifique sur ce document se rapporte à la signification des termes et à la spécificité des informations fournies à l'IANA dans les projets Internet.

Un problème se rapporte à la signification du terme "consensus de l'IETF". Lorsque un document est passé par un processus de consensus défini, comme un groupe de travail, c'est clair. Lorsque les demandes qui arrivent à l'IANA ne sont pas passées par là, l'IANA a besoin d'instructions spécifiques sur les attentes de l'IETF. Cela vient généralement sous la forme de directives AD ou d'un avis sur consultation. Une amélioration du procès serait cependant utile ; les règles d'affaires qui informent l'IANA lorsque un nouveau registre est approprié, et quelles règles devraient être appliquées, par exemple, dans l'allocation de valeurs dans un certain registre, seraient utiles.

L'allocation des paramètres étant une fonction essentiellement de bureau, des lignes directrices spécifiques au personnel de bureau sont absolument obligatoires, et elles sont souvent lacunaires ou peu claires. Dans les rêves de l'IANA, chaque projet Internet contiendrait une section de considérations relatives à l'IANA, même si tout ce qui est dit était "IANA n'a pas à se soucier de ce projet". En l'absence d'une telle déclaration, la liaison IANA à l'IESG est forcée de lire tout le document au moins deux fois : une quand l'IESG est saisi du document, pour s'assurer que toutes les instructions à l'IANA sont claires, et à nouveau lorsque l'IESG transmet le document, pour s'assurer qu'elle peut effectuer les demandes que fait le projet. Ceci consomme du temps et invite aux erreurs

L'IANA reçoit maintenant un certain niveau d'instructions dans les projets Internet, ce qui est bien. Cependant, même le présent niveau d'avis est fréquemment peu clair. Par exemple, une définition de NCP PPP peut bien demander l'allocation de deux PID, un pour l'échange de données et un pour le NCP lui-même. Ces deux numéros viennent de gammes très différentes : 0001..00FF, 0101..7FFF, 8001..BFFF, et C001..FFFF. Le choix de la gamme est important, en particulier sur les lignes à bas débit qui utilisent la transmission asynchrone en mode octet, car l'allocation des données fait un compromis implicite entre la fréquence relative des messages qui utilisent le protocole spécifié, et la fonction de contrôle des PID est elle aussi partagée. Dans un tel cas, l'IANA a besoin de savoir non pas que "deux PID sont demandés", mais que "deux PID PPP sont demandés, le PID de données nommé <d-name$gt; défini au paragraphe <> dans la gamme de 0001 à 00FF, et le PID de contrôle nommé <c-name$gt; défini au paragraphe <> dans la gamme de 8001 à BFFF".

La descriptions des registres à concevoir doit être également claire. Si la spécification dit dans sa section de considérations relatives à l'IANA que "un registre nommé "Codets Fubar" devrait être construit ; les valeurs initiales dans un tableau <nom> et l'IANA peut allouer des valeurs supplémentaires dans toute valeur restante entre le dernier codet initial et 65535", c'est exactement ce qui va se passer. Si il y a des attentes supplémentaires, comme "on demandera au conseiller en allocation de numéros du groupe de travail" ou "toutes les allocations doivent être faites dans une RFC de statut information ou en cours de normalisation", elles ne seront pas nécessairement satisfaites, sauf si la section de considérations relatives à l'IANA spécifie combien. Ce qu'on met dans la section de considérations relatives à l'IANA est ce qui sera fait. Elle devrait être claire afin que celui qui la met en œuvre obtienne ce qui est demandé. Aussi, des sections de considérations relatives à l'IANA claires aident aussi la communauté, pas seulement l'IANA. Cela fait que (1) les auteurs pensent à tous les aspects de la création d'un registre et donnent des instructions sur la façon de le maintenir mais aussi (2) le public sait et comprend les instructions du nouveau registre et comment ils peuvent obtenir des allocations/enregistrements dans ce registre.

Quelque chose qui aiderait matériellement l'IANA dans son évaluation des projets Internet serait un système de traçage des commentaires du côté IETF. L'utilisation par l'IANA d'un tel système est évident : tout commentaire fait sur le projet va apparaître dans le système, l'IESG peut directement les restituer, et l'IANA peut trouver ce commentaire lorsque le projet lui arrive ultérieurement. Pour être vraiment utile, il devrait aussi inclure au moins tout commentaire de dernier appel de l'IETF et les commentaires AD, incluant les changements acceptés au document. Cela permettrait à l'IANA de revoir aussi ces notes, ce qui peut à son tour donner lieu à d'autres commentaires de l'IANA ("si vous faites ce changement, vous devriez aussi spécifier <> dans la section de considérations relatives à l'IANA") ou peut guider la mise en œuvre de l'IANA.

Les références normatives s'appliquent aux considérations relatives à l'IANA aussi bien qu'aux autres parties de la spécification. Récemment, l'IESG a commencé à passer des documents avant d'autres documents qui sont normatifs pour eux, leur permettant de se tenir dans des files d'attente ultérieures pour les synchroniser avec leurs documents normatifs. Dans le cas particulier où le document normatif définit un registre et où le projet en discussion alloue une valeur de ce registre, ce cas doit être traité dans la file d'attente et dans le processus comme toute autre référence normative.

(2)	Quel personnel a été utilisé pour effectuer ces fonctions et quelles sont leurs compétences particulières pour le faire (individuelles ou collectives) ?

Le personnel affecté à cette fonction, au 4 novembre 2003, inclut Michelle Cotton et un assistant. Ce sont essentiellement des employés de bureau intelligents familiers des applications de bureautique, mais par ailleurs sans entraînement technique particulier. Pour les questions techniques, ils dépendent beaucoup des conseillers au sein de l'IANA ou affectés par l'IETF. On devrait se rappeler que ce n'est pas le travail de l'IANA de comprendre comment chaque protocole fonctionne quand il est défini dans un nouveau registre. L'IANA a besoin de savoir comment créer et maintenir administrativement le registre.

(3)	Quels critères utilisez vous pour déterminer si vous avez réussi, et à quel point ? Avec ces critères, quel est votre réussite et que pouvez vous faire, en particulier à l'égard de l'IETF, pour améliorer cette évaluation ?

La mesure de base du succès est le nombre d'allocations faites. Le sentiment de Michelle est que l'IANA est maintenant un succès modéré, cependant d'autres améliorations peuvent être faites en interne et en externe.

Paul est en train de définir une automatisation fondée sur la Toile qui devrait aider pour divers aspects du travail de l'IANA, incluant en partie la fonction IETF IANA. Michelle pense que cette automatisation va l'aider matériellement pour respecter les délais. Mais pour que cela soit effectué correctement, des lignes directrices de travail claires doivent être données à l'IANA pour chacun des registres existants, lignes directrices dont l'application puisse être directement automatisée. C'est probablement un effort de l'IETF, ou qui exige au moins un sérieux apport de l'IETF.

(4)	Comment caractériseriez vous la qualité de vos relations avec l'IETF et sa direction ? Y a t-il une confiance mutuelle et le sentiment d'un travail commun sur les problèmes, ou vous et vos collègues voyez vous parfois ces relations comme d'opposition ?

Sur ce point, Michelle estime que la relation avec la direction de l'IETF/IAB est amicale et généralement constructive. Elle est très consciente de la charge de travail de AD, et à ce titre essaye de préciser les questions et trouver d'autres personne à qui les poser. Comme cela, elle perçoit le niveau et le volume de communication comme plutôt léger et "presque bien".

Là encore, une plus grande clarté de la politique de l'IESG/WG réduirait sa charge de questions, et il pourrait être utile qu'une liaison de l'IANA à l'IAB existe comme celle qu'a l'IANA avec l'IESG. Ceci est réellement une question pour l'IAB ; si il a des questions pour l'IANA, le président devrait pouvoir l'inviter à commenter ou l'inviter comme liaison.

(5)	Y a t-il des problèmes spécifiques connus que vous aimeriez approfondir et comprendre ? Pouvez vous les décrire ?.

Cette note a fait un point concernant la clarté des instructions, la clarté de la politique, et la clarté des registres. Il y a un travail en cours à l'IANA pour nettoyer les fichiers de registres hérités de l'époque où l'IANA a été séparée du bureau de l'éditeur des RFC ; en traitant les questions de considérations d'affaires déjà soulevées, il pourrait être utile qu'une équipe spéciale de l'IETF revoie leurs registres avec eux et fasse des suggestions.

Il y a un problème actuellement avec la réception d'annonces concernant au moins certains projets Internet. Michelle projette de suivre cela avec le Secrétariat, mais en bref, il apparaît que la liaison de l'IANA n'est pas copiée sur au moins certaines listes sur lesquelles les actions de projets Internet sont annoncées. Cela semble relever des soumissions individuelles dont l'IESG avise l'éditeur des RFC qu'il n'y a "pas de problème" à les publier.

(6)	Comment voyez vous évoluer les coûts de votre fonction ? Si les choses deviennent de plus en plus coûteuse avec le temps, quels sont les principaux déterminants du coût (par exemple, l'inflation générale, la croissance générale de l'IETF, l'augmentation du nombre de fonctions particulières que vous vous trouvez exécuter,...). Faites vous des choses que demande l'IETF (l'IESG ou autres) que vous ne considérez pas comme en valant la peine et, si il en est, quelles sont elles ?

Comme détaillée, la fonction décrite dans la RFC 2860 représente approximativement la charge de l'équivalent d'une personne, plus les facilités, le soutien logiciel, et la charge d'affaires standard. Cela a été le niveau de charge approximatif depuis les cinq dernières années, et il est envisagé qu'il reste le même pour le futur proche. Les questions d'efficacité par rapport aux coûts tournent autour de l'effort de l'homme du terrain impliqué dans la lecture des projets, les enquêtes d'investigation, et tout ce qui a été détaillé ici. Le sens est qu'un système effectif de gestion des commentaires plus les systèmes de flux de travaux que l'ICANN prévoit de mettre en œuvre devraient résulter en une amélioration nette à court terme de l'efficacité et des délais ; la croissance projetée de l'IETF devrait alors consommer cette amélioration au fil du temps.

Adresse de l'auteur

IAB Advisory Committee
IETF
mél : iab@iab.org 

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.