In article (Dans l'article) <42bd00dc$0$11742$636a15ce@news.free.fr>,
Maxime VALETTE <maxime.valette@wanadoo.fr> wrote (écrivait):

> Stéphan Dompé a écrit :
>
> > par exemple le transfert d'un .ORG est plus complexe que celui d'un .COM
>
> Et dire qu'il y a quelques mois c'était l'inverse... =)

ah bon ?
qu'y a t il comme differences ? qu'y a t il eu comme changements ?

--
http://tDeContes.hd.free.fr/
http://palestine-hn.org/
http://www.aapel.org/bdp/BLpas_concerne.html

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

Le Mon, 08 Aug 2005 00:43:05 +0200, Thomas a écrit :
>> > par exemple le transfert d'un .ORG est plus complexe que celui d'un .COM
>>
>> Et dire qu'il y a quelques mois c'était l'inverse... =)
>
> ah bon ?
> qu'y a t il comme differences ? qu'y a t il eu comme changements ?

..ORG fonctionne en EPP suite à son basculement chez Afilias.
..COM continue de fonctionner en RRP (basculement en cours vers EPP)

Le protocole EPP utilise un mécanisme supplémentaire : un code, appelé
auth info dans le protocole, qui est comme un mot de passe, par domaine.
Ce code est nécessaire pour le nouveau bureau d'enregistrement lors de la
demande de transfert. Et ce code n'est accessible/modifiable que par le
bureau d'enregistrement qui gère le domaine. En théorie ce code est
connu du client, les concepteurs du protocole ont eu la naiveté de croire
que les déposants allaient le choisir à la création du domaine (une des
quelques erreurs du protocole)

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 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é...)

--
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>

Salut Patrick,

On Mon, 08 Aug 2005 02:35:14 +0200, Patrick Mevzek wrote:
>
> 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.

> 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.

A plus tard..
--
Stephane Kanschine

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>

On Mon, 08 Aug 2005 17:50:44 +0200, Patrick Mevzek wrote:
>>
>> 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.

<cut/>

Merci pour ce résumé fort instructif, il doit tout de même me manquer
quelques connaissances basiques pour bien appréhender le problème.

> 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.

Ça me semble surtout incompatible (voir incroyable) avec les sommes et
les assurances demandées, de s'encombrer des problèmes liés aux
mécreants.

> [...] 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.

Réguler/Diriger/..., c'est 50% d'éducation (si ce n'est pas plus) pour
faire passer un message. Ce qui en pratique n'est jamais fait, en se
reposant sur la responsabilité des autres.

> 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,

Ok.

>> 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

Merci, j'étais effectivement sur une autre publication du 12 qui ne
parlait pas vraiment de la même chose :-)

--
Stephane Kanschine

In article (Dans l'article)
<pan.2005.08.08.16.50.46.428604@online.net>,
Stephane Kanschine <skanschine+news@online.net> wrote (écrivait):

> On Mon, 08 Aug 2005 17:50:44 +0200, Patrick Mevzek wrote:
> >>
> >> 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.
> >
> > > [...]
> >
> > [...]

merci à vous 2 pour les explications :-))

--
http://tDeContes.hd.free.fr/
http://palestine-hn.org/
http://www.aapel.org/bdp/BLpas_concerne.html

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"