Greboca  

Blog de Stéphane Bortzmeyer  -  RFC 8715: Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust

 -  28 février - 

Le passage de la structure administrative de l'IETF vers « IASA 2.0 » (IASA = IETF Administrative Support Activity, cf. RFC 8711) a nécessité des changements dans la manière dont les membres de l'IETF Trust sont désignés. Ces changements sont décrits dans le RFC 8714, et expliqués brièvement dans ce court RFC.

Petit rappel : l'IETF Trust gère la propriété intellectuelle de l'IETF, comme la marque ou comme le nom de domaine ietf.org et, bien sûr, comme les RFC, dont la licence dépend formellement de cet IETF Trust. Cet IETF Trust est enregistré aux États-Unis. Au début, les membres de l'IAOC (IETF Administrative Oversight Committee) étaient également membres de l'IETF Trust. L'IAOC ayant été supprimé par le RFC 8711, il fallait donc changer les règles de désignation, ce qu'a fait le RFC 8714.

Lors des discussions sur la création de l'« IASA 2 » (IETF Administrative Support Activity, deuxième version), il avait été envisagé de fusionner l'IETF Trust avec la nouvelle structure, l'IETF LLC. Finalement, l'IETF Trust reste une organisation indépendante. Les raisons ? D'abord, une volonté de minimiser les changements liés au projet « IASA 2 », ensuite, l'observation du fait que le travail de l'IETF Trust est assez différent de celui de la IETF LLC (décrite dans le RFC 8711). L'IETF Trust a une activité calme, avec peu ou pas de problèmes urgents à résoudre, et les changements sont rares.

Mais comme il fallait bien tenir compte de la disparition de l'IAOC, le choix a été de réduire la taille de l'IETF Trust, plutôt que de créer un mécanisme alternatif à l'IAOC (puisque, comme indiqué plus haut, l'IETF Trust ne demande pas beaucoup de travail). Les cinq membres sont désignés par le comité de nomination de l'IETF (« NomCom »), par l'IESG et par l'ISOC. Pour ce dernier cas, le RFC note qu'on aurait pu utiliser l'IETF LLC et pas l'ISOC, mais que l'ISOC semblait plus adaptée, pour une tâche qui est assez politique (l'IETF LLC est normalement purement administrative).

Sinon, vous pouvez voir ici un appel à candidatures du NomCom pour l'IETF Trust.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

RFC 8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

 -  31 mai - 

Le protocole DOTS (Distributed Denial-of-Service Open Threat Signaling) vise à permettre au client d'un service anti-dDoS de demander au service (...)


RFC 8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification

 -  31 mai - 

Le système DOTS (Distributed Denial-of-Service Open Threat Signaling) est conçu pour permettre la coordination des défenseurs pendant une attaque (...)


RFC 8788: Eligibility for the 2020-2021 Nominating Committee

 -  28 mai - 

Un très court RFC sorti dans l'urgence pour résoudre un petit problème politique. Les membres du NomCom (Nominating Committee) de l'IETF sont (...)


Représentation sous forme texte de ce qui passe sur le réseau

 -  18 mai - 

Dans beaucoup de protocoles réseau, ce qui passe « sur le câble » est dans un format binaire incompréhensible pour un humain. Il est souvent utile de (...)


Obfuscation; A User's Guide for Privacy and Protest

 -  17 mai - 

Beaucoup d'efforts sont aujourd'hui dépensés pour protéger la vie privée sur l'Internet. En effet, le déploiement des réseaux informatiques a permis (...)