DNSO Mailling lists archives


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

Re: [registrars] Outstanding issues on Registrar Transfers

Michael D. Palage wrote:
> Elana:
> Your request to re-open discussions on the XFER document is premature. Let
> me remind you that what we are looking for is consensus and not unanimity.

I have a question about what you mean
by "consensus". According to my records (and correct
me if I have missed something here) this issue
was first formalized when Ross circulated a document
on Aug 20th. 

About 1 month later, on Sept 19th, in an email
from you (Mike Palage), you said:

"This morning I posted what I believe was a final compromise document 
on the transfer issue between the drafters. However, I have been 
informed by one of the parties that there were material changes that 
are unacceptable."

(What's with the "compromise .... between the (TWO) drafters" anyway?
Who died and made them "King" of this issue?)

and later that day:

"I would like to thank Ross and Elana for the efforts that they have
undertaken to produce a consensus document on the XFER issue over the past
couple of weeks. Unfortunately it seems that they have been unable to agree
on some rather important and critical final elements. I therefore encourage
Elana and Ross to continue their potential resolution online instead of
their previous offline discussions over the past week. Hopefully this online
discussion will flesh out the points of disagreement and allow the registrar
constituency to understand the differences between the documents and allow
they to vote informatively next week."

(Consensus between who? Ross and Elana? So what?)

and still later:

"Listed below is a unified document resolving outstanding differences between
document A and document B posted earlier today. Therefore please consider
this unified document the current position paper for discussion. Discussion
and comment period will take place over the several days with voting to
begin on Monday."

On Sept 24th the following was received:

"ISSUE 1: The comment period for the Registrar XFER issue will close today
and voting will begin within 24 hours upon completion of a ballot."

The next day (Sept 25th) the ballot went live.

"Listed below is the ballot in connection with the Registrar XFER issue. As
you will see the ballot is simply an approve or disapprove option."

To which I said "disapprove" and a few people
got upset. 

I think review of this issue was rushed. I know I didn't have
time to fully digest it. After it took Ross and Elana
about 1 month to produce a "consensus" (which was not really
even a consensus if you review some of YOUR comments) 

...then you said that the

"comment period will take place over the (next) several
days with voting to begin on Monday."

I don't think "several days" is enough even if the document
is supposed to be fluid and changeable. 

I'm not even sure how Ross and Elana were supposed
to be representative of everyone anyway. No offense, but...

And it appears that Elana, one of the drafters,
is not entirely happy with the compromise anyway.

As a rule, I don't like things that are rushed
through (like this) even if I perceive that they
might benefit our company. To me, this smacks of the
same way the Verisign contract revision went down.
"Done deal, vote, slam bam". Maybe everyone else
feels comfortable having this document approved
with (correct me if I missed something)
no comments from anyone modifying or questioning
the document. But I don't.

> If there is no consensus when the votes are tallied, then I agree that we
> should return to negotiations.

Who are the parties involved in the
negotiations? Ross and Elana? 


Aug 20th - Ross writes proposed solution
Sept 19th - Ross and Elana (sorta somewhat) agree on things
Sept 24th - All comments are due!
Sept 25th - Voting begins!

Larry Erlich


> Mike
> P.S. I have not yet received Register.com's vote.
> > -----Original Message-----
> > From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> > Behalf Of Elana Broitman
> > Sent: Sunday, October 07, 2001 4:34 PM
> > To: registrars@dnso.org
> > Subject: [registrars] Outstanding issues on Registrar Transfers
> >
> >
> > In view of the many emails, such as from Larry, Bhavin, and Bruce
> > regarding
> > the transfer policies, it appears that there remain some significant
> > outstanding issues for the transfer process.  It raises the question of
> > agreeing on a document before dealing with these significant
> > issues that may
> > change the transfer principles.  I want to raise that as a
> > question ahead of
> > the Tuesday call.  I also want to resend the list of issues that I thought
> > remained outside the document, below.
> > Regards, Elana
> >
> >
> > 1)    Definition of individual who has the apparent authority to
> > legally bind
> > the Registered Name holder.
> >
> > The Registry Agreement and ICANN's statements do not clarify this term.
> > Yet, it is often the crux of the issue and there is often a
> > difference among
> > registrars regarding the definition of "apparent authority."  Some
> > registrars consider only the registrant or administrative contact to be
> > authoritative. Others may allow billing, technical, or other contacts to
> > serve as authorized representatives for the purpose of granting apparent
> > authority.  Yet others allow resellers to provide apparent authority.  We
> > could draft a list of authorized contacts, but that runs the risk of
> > unnecessarily limiting some registrar's legitimate definition or business
> > model.
> >
> > However, there clearly needs to be some standard, so that we do not have a
> > situation where conflicting transfer instructions are sent on behalf of a
> > registrant. Just as the IRDX document has a procedure pursuant to which a
> > gaining registrar refers to the Whois of the losing registrar in order to
> > verify a transfer request, similarly the gaining registrar must
> > refer to the
> > apparent authority recognized by the losing registrar in the initial
> > registration process in order to obtain authorization for the
> > transfer.  In
> > other words, if an admin contact was the apparent authority during
> > registration, then the individual holding that position should
> > authorize the
> > transfer or at the very least authorize the new "authority."  This would
> > allow for an objective standard while retaining flexibility.
> >
> > RECOMMEND: "apparent authority, as defined by the Losing Registrar's
> > practices"
> >
> >
> > 2)    Process for Transfers initiated by Indirect Partners of Gaining
> > Registrars.
> >
> > The current IRDX document allows for only 2 processes - paper and email -
> > both of which rely on a direct channel from the registrar to the
> > registrant.
> > This WOULD NOT allow  indirect partners to initiate or process transfer
> > requests.  Yet, there is no reason to stifle this business model currently
> > used by many registrars, as long as appropriate protections and
> > documentation are in place.
> >
> > RECOMMEND: Include process for transfers going through indirect channels,
> > and require such processes to be authorized using the same
> > documentation as
> > the direct channel + evidence of a contract between the indirect
> > partner and
> > the registrar that obligates the indirect partner to adhere to the same
> > minimum standards.
> >
> >
> > 3)    Gaining Registrar transferring domain names back to the
> > Losing Registrar
> > in a case where it has been demonstrated that the Gaining
> > Registrar did not
> > act in accordance with the practices and processes contemplated by this
> > document.  Gaining Registrar's indemnification of the Losing Registrar
> > against legal recourse in such cases.
> >
> > This is a matter of making all parties whole after erroneous transactions.
> > If registrars are to trust each other's processes so that they
> > make changes
> > without requiring confirmation by their customers, they and their
> > customers
> > must be made whole if transfers were not authorized. A gaining registrar
> > that initiated and completed the transfer of a domain name without proper
> > authorization must transfer the name back, and indemnify the losing
> > registrar against any potential liability associated with this
> > transaction.
> > This entire exercise is about instilling trust in transfer processes such
> > that registrars can essentially "take each other's word for it."  If a
> > registrar fails that test, and is not providing for consumer protection,
> > other registrars must be able expeditiously to return to checking
> > with their
> > registrants, at least until confidence is regained.
> >
> > RECOMMEND:  In cases of erroneous or unauthorized transfers, Gaining
> > Registrar transfers domain name back to Losing Registrar and indemnifies
> > such registrar against any potential liability.
> >
> > 4)    Appropriateness of Registrar Lock.
> >
> > Some registrars have a business model of "locking down" their customers'
> > domain names - in other words, automatically nacking all
> > transfers for such
> > domain names without checking with the registrant.  Some registrars may do
> > this only upon request by customers; others may institute such a policy
> > automatically for all customers.  The "lock down" policy is
> > clearly at odds
> > with one of the fundamental principles motivating this document -
> > to promote
> > market choice.
> >
> > RECOMMEND: We must consider and institute the appropriate benchmarks for
> > "locks."
> >
> >
> > 5)    A requirement to authenticate or notarize some, or all, of
> > the transfer
> > documentation procured by the Gaining Registrar.
> >
> > Contracts - particularly between companies - are often
> > authenticated.  It is
> > not always necessary to use a notary public, but it does provide an
> > important lawyer of security to rely on authentication authorities,
> > particularly if the issue of "apparent authority" is unclear.
> >
> > RECOMMEND: Written contracts to be authenticated (e.g., in the US
> > this could
> > mean notarized).
> >

Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com

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