DNSO Mailling lists archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] Draft Code of Conduct

Hello all,

unfortunately Schlund+Partner hasn't been part of the constitentuency
as the DC meeting took place.

First let me mention that the CoC is something very good and very much 
needed to fill the "gaps" the ICANN Agreement has not specified in detail.

But two points are not really clear to me at the moment:

3.B. Procurement and Retention of Documentation 
	(the first 3., there are two of them!)

In our business model is doesn't really make sense to lose a 
domain to another registrar without cancelling the whole product
(that is webspace, emails etc).
So we would require our customers (the SLD holders) to cancel to 
product and notify us that the domain contained in it will be
sponsored by another registrar. 

So if a transfer of registrar comes from the registry and we do not
have the acknowledgement of our customer, we will immediately 
ask the gaining registrar to provide us the "express authorization",
believing that our customer just "forgot" to notify us.
"commercially reasonable period of time" would then mean 
"while the registrar transfer is running / before the auto-ACK".

This is the same procedure as required by DENIC (.de), and it seems
absolutely necessary to me to double-check a transfer with the losing
registrar, who is currently responsible for the domain and it's
security. [Litte excursion: .de has 110 registrars, 2,000,000 domains
and transfers without the SLD holder's authorization happen all the time,
but most of them are blocked by the losing registrar]

Even if the ICANN Agreement or the CoC would introduce sanctions 
for registrar transfers without express authorization of the SLD
holder, it still could not prevent any registrar from accidently 
transferring a domain and then causing real damage, e.g. the website/emails
going offline.

I just can't sleep well with the idea that any registrar can accidently
transfer our own domain to him without us being able to protect the 
domain by NACKing the transfer.

So, are the five business days of the running transfer an enough
commercially reasonable period of time?

3.B. Disclosure of Identity

Surely every registrar will agree that the SLD holder should first
contact his provider's customer service before going directly to
the registrar. I would appreciate finding a way to keep this "workflow".

Imageine the situation where the registrar is running a tool-free hotline,
but the provider (reseller) has a normal phone number, which would
cause long-distance calls for the customer. And than he gets an
confirmation email from his provider's registrar saying "you can call
us any time toll-free". Why would he bother to first call his provider?
Our reseller get rebates because they're handling the whole customer
service for their customers.

Big exception of course is when the SLD holder has trouble with his
provider. Then he should call directly, but prove he first has tried
it the normal way.

What to you think?


On 2000/07/06, Michael D. Palage wrote:
> Attached please find the proposed code of conduct that Richard Lindsay
> circulated to the Code of Conduct Task Force. Several people have asked to
> see a copy of it. Again, this is still in draft format. Richard Lindsay will
> let us know when a copy suitable for voting upon is available.
> Michael D. Palage
> -----Original Message-----
> From: owner-registrars-coc@dnso.org [mailto:owner-registrars-coc@dnso.org]On
> Behalf Of Richard Lindsay
> Sent: Monday, July 03, 2000 9:52 PM
> To: Registrar COC; ICANN Liaison
> Subject: [registrars-coc] Version II draft
> Greetings all,
> I apologize for the lack of progress, I haven't been too
> aggressive in trying to keep the drafting process hopping.
> However, there is quite a big impetus to get at least
> a first version of some kind of a Code of Conduct
> by the ICANN meetings in Yokohama.  Unfortunately this
> is just a week away, so if we are to make any progress,
> we will have to get to work quickly.
> I am forwarding a revised version of the Code of Conduct.
> This version was drafted with the assistance of input
> from many of the Registrars who attended the meeting
> 2 weeks ago in Washington DC.  The document contains
> many of the same points of the original draft that I
> submitted, but it includes some wording with a clearer
> legal tone (legal council reviewed this document whereas
> my draft had no such support.)
> There are a few points that you will notice are not
> included.  Specifically the provisions regarding Warehousing
> and Registrar mistakes are not included.  This is due to
> the fact that many Registrars present at the meetings
> in DC indicated they would not be supportive of a
> Code of Conduct with those issues included, until there
> was much more discussion of the issues.
> Keep in mind this Code of Conduct has to be a consensus
> based document, so even if the entire CoC working group
> feels very strongly about a certain provision, if the Registrars
> as a whole do not support it, we will not get a working Code
> of Conduct in place.
> In my opinion, this Code of Conduct should be viewed
> as a staged process, similar to the Service Level Agreement
> (SLA).  By no means should this document be considered
> a final version that will not be changed in the future.
> Indeed, I believe the items that were not included in
> this draft should be discussed, and identified in future
> updates to the Code of Conduct.
> Please read over this version carefully and compare this
> with the original version I sent out.  I would like to submit
> this to the Registrars hopefully by the end of the week.
> If believe we should strive to have something approved
> at least by the completion of the ICANN meetings
> (if at all possible!)
> Best regards,
> Richard

Mit freundlichen Gruessen

Eric Schaetzlein

Eric Schaetzlein		Schlund + Partner AG	Tel:  +49 721 91374 50
Leiter Domain Services		Erbprinzenstr. 4-12	Fax:  +49 721 91374 20
				D-76133 Karlsruhe	Mail:  eric@schlund.de

<<< Chronological Index >>>    <<< Thread Index >>>