[registrars] XFER History

["Michael D. Palage" <michael@palage.com>]

Prior to Montevideo, efforts were made between Ross and Elana to produce a
unified position paper based upon the original standard operating procedure
of AUTOACK which most registrars have supported in the various straw polls
and votes.

Approx two weeks ago, a unified position paper was put forward for vote
among the constituency. After consultation with ICANN staff, it was
recommended that the vote be circulated to all ICANN accredited registrars.
I intend to release the results of this vote at the end of this week.

Mike





> -----Original Message-----
> From: Super-User [mailto:root@netscott.com]On Behalf Of Larry Erlich
> Sent: Sunday, October 07, 2001 7:54 PM
> To: Michael D. Palage
> Cc: registrars@dnso.org
> Subject: 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?
>
> Summary:
>
> 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
>
> http://www.DomainRegistry.com
>
> >
> > 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
> -----------------------------------------------------------------
>