IETF

Un article de Wiki ISOC de la gouvernance de l'internet .

IETF – Internet Engineering Task Force (http://ietf.org)

Dénomination : IETF – Internet Engineering Task Force

Année de Création : 1986, meeting à San Diego. (Histoire de l'IETF : RFC 4677 – LE TAO)

Nature juridique de l’organisation : Il est difficile de caractériser l'IETF. En effet, et cela pose de nombreuses questions, l'IETF n'a pas d'existence légale en dehors de l'ISOC qui lui procure un « parapluie légal » depuis 1992. Par ailleurs, même si l'IETF finalise les standarts d'Internet, la publication revient au RFC Editor et la propriété intellectuelle, auparavant à l'ISOC, appartient dorénavant à l'IETF Trust ((RFC 4371, RFC 4748 et RFC 4841) qui est une autre organisation. De plus, l'IETF doit être considéré comme une fonction ou une communauté mais pas comme une entité cohérente au contraire de l'IESG par exemple. En effet, l'IETF est un ensemble d'Aires de travail, de groupes de travail et d'individus mais pas une organisation.

Missions : Engineering et évolution d'Internet, production de standards techniques et autres nécessaires à ces deux opérations. On notera les missions suivantes : identifier et proposer des solutions aux problèmes d'Internet, Spécifier (donner les spécifications techniques) les développements et les usages des protocoles déjà définis pour régler des problèmes, faire des recommandations à l'IESG à propos de la standardisation des protocoles, faciliter le transfert des technologies à la communauté Internet globale, être un forum d'échange technique à propos d'Internet.

Entrée en activité : 1986 avec un meeting de 21 personnes. 1992 voit son rattachement à l'ISOC par l'intermédiaire de l'IAB et 2005, la création de sa structure administrative. Le RFC 4841 reconnaît l'IETF Trust et constitue une évolution importante dans l'IETF de par l'innovation dans l'appartenance des droits de propriété intellectuelle des standards créés.

Textes de création et de références: Il n'y pas vraiment de texte de création de l'IETF mais ses caractéristiques sont explicitées dans divers RFCs. On se référera tout particulièrement au RFC 4677 appelée aussi le TAO en raison de son titre : « The Tao of IETF: A novice's guide to the IETF ». On se référera aussi utilement aux RFCs suivants, RFCs explicités dans un document annexes : 2031,2028, 3716,4052, 4677, 4333,4071,4371, 3356,4089. Cependant, cette liste n'est pas exhaustive en ce sens que les mêmes informations peuvent sans doute être trouvés ailleurs et même que de nouvelles informations peuvent aussi être trouvées ailleurs. Ces RFCs sont disponibles ici : http://ietf.org/rfc.html et ici : http://www.rfc-editor.org/.

Description de l’organisation :

- Nature des Membres : il n'y a pas de membre à l'IETF, la participation étant libre à condition que l'on finance les frais de participation.

- Rencontre des membres : 3 meetings par an. Cependant, les groupes de travail fonctionne énormément par mailing listes et en dehors des meetings, continuent à être très actif.

- Organigramme : Le travail pratique lié à la publication (inscription, soumission des RFCs..) est réalisé par un Secrétariat (IETF Executive Director -RFC 3710). Ce Secrétariat est sous contrat avec IASA. Le président de l'IETF est nommé par le Nominating Commitee dont le président est nommé par l'ISOC (RFC 3710 S.2).

- Méthode de travail : Groupes de Travail appartenant à des aires plus larges définis dans l'IESG. La création d'un nouveau groupe de travail implique la rédaction d'une charte revue par l'IAB (RFC 4677) et la sélection d'un Chair du WG par l'IESG (et l'AD correspondant). On citera ici D. Clark et Jon Postel dont les déclarations sont instructives à propos du travail de l'IETF : "We reject kings, presidents and voting. We believe in rough consensus and running code" et "Be conservative in what you send and liberal in what you accept"

Contraintes de reporting :

 Ascendantes : L'IETF est une communauté et il est donc difficile d'y trouver des contraintes de reporting évidentes. Cependant, concernant le management technique, il doit s'en rapporter à l'IESG. De plus, son activité administrative est encadré par IASA, dirigé par IAD, lui-même soumis au IAOC. En cas de litige, le ou les membres contestant peuvent avoir à discuter avec l'IESG, l'IAB voire même l'ISOC. Par ailleurs, le RFC 2026 portant sur le processus de construction des standards montre bien les interventions de l'IESG dans la décision de faire changer les propositions de catégorie.

 Descendantes : Il est difficile de trouver une organisation ou des membres particuliers devant se rapporter à l'IETF. Les membres des différents groupes de travail se reportent à leur « Chairs » ou bien encore aux AD -Area Directors de l'IESG. On peut considérer IANA comme ayant des contraintes vis à vis de l'IETF car IANA a été choisi par l'IAB pour choisir certaines données précises dans les protocoles. IANA doit donc attendre les spécifications de l'IETF pour réaliser son travail et par ailleurs, dans le cadre du MoU entre ICANN et IETF à propos d'IANA, il est lui «imposé » d'implémenter les protocoles construits par l'IETF (RFC 2860). NB : L'IETF Trust que l'on pu évoquer précédemment est une création de l'IETF très récente (2006). En effet, l'observation des différents RFCs, toute « nature » confondue, montre que pendant longtemps, c'est l'ISOC qui détenait les droits de propriété intellectuelle dont les caractéristiques et procédures sont détaillées dans le RFC 3979. Les raisons précises ayant motivées ces changements dans l'attribution de ces droits ne sont pas claires et évidentes. On peut cependant dire qu'étant donné que l'ISOC doit rester indépendante du processus de standardisation, lui donner ces IPR pouvait paraître contradictoire. (http://trustee.ietf.org/ et http://www3.tools.ietf.org/group/trust/)