Mon blog

L'IETF a annoncé le 24 avril 2017 la dissolution du groupe de travail DBOUND. Je n'écrirai donc pas d'article sur les RFC de ce groupe, il n'y en a eu aucun. Pourquoi cet échec ?

D'abord, voyons quel était le problème que voulait résoudre ce groupe. DBOUND signifie Domain Boundaries et il s'agissait en gros d'indiquer publiquement quelles étaient les frontières organisationnelles dans les noms de domaine. Minute, vont se dire certains lecteurs, c'est facile ! Dans www.foobar.example, la frontière est forcément entre foobar et le truc appelé à tort « extension » .example ? Mais c'est complètement faux, les coupures (passage d'une organisation à une autre) peuvent être à plein d'endroits différents et rien dans le nom de domaine ne l'indique. (Cf. mon article sur « La terminologie des parties d'un nom de domaine ».)

Et, au passage, pourquoi est-ce que c'est important de savoir que signal.eu.org et eahm.eu.org ne dépendent pas de la même organisation ? Parce que plusieurs services en dépendent. (Une liste partielle de raisons figure dans mon article « Trouver le domaine responsable ».) Par exemple, on pourrait vouloir, dans la barre d'adresses du navigateur Web, colorier différemment le domaine enregistré le plus haut dans l'arbre, pour éviter certains trucs utilisés par le hameçonnage.

Aujourd'hui, comme il y a un vrai besoin, la plupart des utilisateurs se servent de la « Public Suffix List » de Mozilla. Cela marche « suffisamment » mais son principal inconvénient est qu'elle n'est pas administrée par les gérants de noms de domaine, et qu'elle n'est donc jamais à jour.

C'est là dessus que devait travailler le groupe DBOUND. Il devait « développer une solution unique pour déterminer les frontières organisationnelles ». Le travail a commencé sur une liste de diffusion en janvier 2014, et le groupe lui-même a été créé en avril 2015. Plusieurs documents ont été proposés mais aucun n'a réuni même un début de commencement de consensus. (Même pas le document de description du problème, draft-sullivan-dbound-problem-statement.)

Suivant un principe général de l'IETF, qu'un groupe de travail est fait pour travailler et qu'il ne faut pas maintenir en vie artificiellement des groupes qui ne produiront manifestement rien d'utile, le groupe a donc été dissous.

Pourquoi cet échec ? Il n'y a sans doute pas une raison unique. Parmi les explications :

• Le problème est bien plus compliqué qu'il n'en a l'air (comme beaucoup de problèmes qu'on aborde avec des yakafokon), par exemple parce qu'il n'est pas évident qu'il faille les mêmes frontières pour toutes les applications,
• Il y a un désaccord de fond entre ceux qui disent que l'indication des frontières doit être faite par le domaine parent (au-dessus de la frontière), car c'est lui qui fixe les règles d'enregistrement, et ceux qui disent qu'elle doit être faite par le domaine fils (car c'est lui qui sait son propre statut),
• Et, tout simplement, intérêt insuffisant pour un problème dont la partie la plus urgente (les cookies) est déjà partiellement résolu. L'IETF étant une organisation de volontaires, s'il n'y a pas de volontaire, rien ne se passe.