PHWinfo - Afficher un message

08/08/2005, 16h50

Le Mon, 08 Aug 2005 12:47:20 +0200, Stephane Kanschine a écrit :
>> Beaucoup de gens ont aussi la naiveté de croire que ce code va résoudre
>> tous les problèmes de transfert, notamment le ``slamming''. Il est
>> pourtant connu qu'on ne résout pas un problème non technique à la base
>> par une solution purement technique,
>
> Ce n'est pas une solution purement technique puisque ça fait appel aux
> usages et aux "bons" interlocuteurs. Ça ne résoudra pas tous les
> problèmes, ça rendra le challenge un peu plus difficile.

Dans le monde des télécommunications, le slamming finalement ca ne
rapporte pas grand chose à l'acteur, si ce n'est peut-être un nouveau
client mais surtout beaucoup de problèmes.
Dans les noms de domaine, récupérer un domaine par transfert frauduleux,
cela peut rapporter beaucoup, et sex.com n'est qu'un exemple parmi tant
d'autres.
(ce n'est pas la seule façon de récupérer un domaine, il y a aussi
attendre que le propriétaire oublie de renouveler, ou s'introduire dans
les systèmes du bureau d'enregistrement en volant un mot de passe ou
autre token d'authentification)

Il faut donc faire le nécessaire pour éviter qu'un tiers puisse trop
facilement voler un domaine, donc rendre les transferts aussi difficiles
que possible.

Mais, en sens inverse, comme on part de l'idée qu'il existe des bureaux
d'enregistrement mécréants, il faut un mécanisme pour facilement
pouvoir s'en défaire (de ces bureaux), donc des transferts faciles.

On le voit, les deux motivations sont incompatibles. Il faut trouver le
juste milieu.

Quand EPP a commencé à apparaître, et que l'ICANN était justement en
train de mettre sur pieds sa nouvelle politique de transfert, j'ai entendu
beaucoup de fois, dans les listes de discussion (des bureaux ou autre), et
dans les réunions ICANN des gens dire que EPP allait résoudre tous les
problèmes de transferts, par la simple présence du code supplémentaire.
Personnellement, je n'ai jamais compris l'intérêt dès le départ, mais
tous les autres concepteurs trouvaient cela génial, et compte tenu du
principe de ``rough consensus'' l'idée est passée. Même s'il commence
à y avoir des premiers échos d'une nécessité de remettre EPP sur la
table pour améliorations diverses, il est peu probable qu'il y ait du
changement à ce niveau. Mais pour illustrer la différence de point de
vue: les concepteurs d'EPP présentaient ce code comme quelque chose de
choisit par la propriétaire du domaine lors de l'enregistrement.
Encore de nos jours, c'est très rare (on peut au mieux le changer après,
et encore pas toujours), mais initialement, certains bureaux
d'enregistrement ont même mis le même code pour tous leurs domaines...
ce qui rendait impossible tout transfert !
Il y a donc eu sur ce point un réel décalage entre les alcôves de
l'IETF (ou de Verisign pour ceux qui pensent qu'EPP, comme RRP, n'est que
leur créature), et la pratique.

La conclusion de ce qu'on a dit précédemment c'est qu'au final c'est un
problème de confiance : fait-on confiance à son bureau d'enregistrement
? au registre ? à un tiers ? etc...
Aucune solution technique ne peut résoudre ce problème de confiance, on
ne peut que mettre en place des barrières et, encore plus important selon
moi, des procédures rodées pour gérer les cas problématiques, tant
dans la recherche (est-ce un vol ou non), que dans sa résolution
éventuelle. Il y a du progrès depuis novembre dernier, mais il y a
encore de la place pour faire mieux.

>> ce qui fait que les transferts resteront un point d'achoppement même
>> si la nouvelle procédure de l'ICANN depuis novembre dernier illumine
>> clairement la voie (le rapport qui est sorti récemment sur les vols
>> suite à transferts frauduleux mérite vraiment d'être lu en
>> intégralité...)
>
> Pourrais tu préciser un lien vers ledit rapport si t'il plait ? Je ne
> suis pas sur de penser au même.

Dans tous les bons services d'information sur le nommage, ou sinon
directement:
http://www.icann.org/announcements/h...rt-12jul05.pdf

Il montre en particulier bien que les problèmes récents (comme
panix.com) n'ont rien à voir avec la nouvelle procédure de transferts
depuis novembre dernier, qui n'est probablement pas parfaite, mais
certainement meilleure que la précédente.

Parmi les améliorations auxquelles on peut penser il y a la
participation du registre directement lors du transfert, ce qui n'est
possible que si ce dernier possède les informations nominatives des
contact (ce qui pose encore un autre problème), et même si cela se
répand (.EU par exemple), je doute que beaucoup de registre soit
enthousiasmé (plus de travail pour eux, sans gain réel), quand cela est
possible (si j'ai bien compris, .COM/.NET passent en EPP mais les données
nominatives restent chez les bureaux).

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

08/08/2005, 16h50	#4
Patrick Mevzek Messages: n/a Hébergeur:	Re: transferts .COM/.ORG Le Mon, 08 Aug 2005 12:47:20 +0200, Stephane Kanschine a écrit : >> Beaucoup de gens ont aussi la naiveté de croire que ce code va résoudre >> tous les problèmes de transfert, notamment le ``slamming''. Il est >> pourtant connu qu'on ne résout pas un problème non technique à la base >> par une solution purement technique, > > Ce n'est pas une solution purement technique puisque ça fait appel aux > usages et aux "bons" interlocuteurs. Ça ne résoudra pas tous les > problèmes, ça rendra le challenge un peu plus difficile. Dans le monde des télécommunications, le slamming finalement ca ne rapporte pas grand chose à l'acteur, si ce n'est peut-être un nouveau client mais surtout beaucoup de problèmes. Dans les noms de domaine, récupérer un domaine par transfert frauduleux, cela peut rapporter beaucoup, et sex.com n'est qu'un exemple parmi tant d'autres. (ce n'est pas la seule façon de récupérer un domaine, il y a aussi attendre que le propriétaire oublie de renouveler, ou s'introduire dans les systèmes du bureau d'enregistrement en volant un mot de passe ou autre token d'authentification) Il faut donc faire le nécessaire pour éviter qu'un tiers puisse trop facilement voler un domaine, donc rendre les transferts aussi difficiles que possible. Mais, en sens inverse, comme on part de l'idée qu'il existe des bureaux d'enregistrement mécréants, il faut un mécanisme pour facilement pouvoir s'en défaire (de ces bureaux), donc des transferts faciles. On le voit, les deux motivations sont incompatibles. Il faut trouver le juste milieu. Quand EPP a commencé à apparaître, et que l'ICANN était justement en train de mettre sur pieds sa nouvelle politique de transfert, j'ai entendu beaucoup de fois, dans les listes de discussion (des bureaux ou autre), et dans les réunions ICANN des gens dire que EPP allait résoudre tous les problèmes de transferts, par la simple présence du code supplémentaire. Personnellement, je n'ai jamais compris l'intérêt dès le départ, mais tous les autres concepteurs trouvaient cela génial, et compte tenu du principe de ``rough consensus'' l'idée est passée. Même s'il commence à y avoir des premiers échos d'une nécessité de remettre EPP sur la table pour améliorations diverses, il est peu probable qu'il y ait du changement à ce niveau. Mais pour illustrer la différence de point de vue: les concepteurs d'EPP présentaient ce code comme quelque chose de choisit par la propriétaire du domaine lors de l'enregistrement. Encore de nos jours, c'est très rare (on peut au mieux le changer après, et encore pas toujours), mais initialement, certains bureaux d'enregistrement ont même mis le même code pour tous leurs domaines... ce qui rendait impossible tout transfert ! Il y a donc eu sur ce point un réel décalage entre les alcôves de l'IETF (ou de Verisign pour ceux qui pensent qu'EPP, comme RRP, n'est que leur créature), et la pratique. La conclusion de ce qu'on a dit précédemment c'est qu'au final c'est un problème de confiance : fait-on confiance à son bureau d'enregistrement ? au registre ? à un tiers ? etc... Aucune solution technique ne peut résoudre ce problème de confiance, on ne peut que mettre en place des barrières et, encore plus important selon moi, des procédures rodées pour gérer les cas problématiques, tant dans la recherche (est-ce un vol ou non), que dans sa résolution éventuelle. Il y a du progrès depuis novembre dernier, mais il y a encore de la place pour faire mieux. >> ce qui fait que les transferts resteront un point d'achoppement même >> si la nouvelle procédure de l'ICANN depuis novembre dernier illumine >> clairement la voie (le rapport qui est sorti récemment sur les vols >> suite à transferts frauduleux mérite vraiment d'être lu en >> intégralité...) > > Pourrais tu préciser un lien vers ledit rapport si t'il plait ? Je ne > suis pas sur de penser au même. Dans tous les bons services d'information sur le nommage, ou sinon directement: http://www.icann.org/announcements/h...rt-12jul05.pdf Il montre en particulier bien que les problèmes récents (comme panix.com) n'ont rien à voir avec la nouvelle procédure de transferts depuis novembre dernier, qui n'est probablement pas parfaite, mais certainement meilleure que la précédente. Parmi les améliorations auxquelles on peut penser il y a la participation du registre directement lors du transfert, ce qui n'est possible que si ce dernier possède les informations nominatives des contact (ce qui pose encore un autre problème), et même si cela se répand (.EU par exemple), je doute que beaucoup de registre soit enthousiasmé (plus de travail pour eux, sans gain réel), quand cela est possible (si j'ai bien compris, .COM/.NET passent en EPP mais les données nominatives restent chez les bureaux). -- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>