[nc-transfer] Re: Official Comments from the Registry Constituency on Transfers

["Ross Wm. Rader" <ross@tucows.com>]

These are great Jeff - extremely constructive and much more inline with what
I was expecting from the Registries v. Roger's comments at the Names Council
meeting.

Agreed that we should discuss these on the call tomorrow. It would be useful
if we could also turn our minds as to how we can sync the modifications
coming from the comment period with Bruce's recommendations of last week
(this week?)


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog
----- Original Message -----
From: "Neuman, Jeff" <Jeff.Neuman@neustar.us>
To: <nc-transfer@dnso.org>
Cc: <mcade@att.com>; <ross@tucows.com>
Sent: Wednesday, November 06, 2002 1:41 PM
Subject: Official Comments from the Registry Constituency on Transfers


> All,
>
> Here are the comments I have received thus far from the Registry
> Constituency.  I may have some more before the TF Call tomorrow as well.
>
>
> 1)  The only way that "binding policies between registrars and registries"
> can be implemented is to amend registry and registrar agreements with each
> other and ICANN.  How does the task force think this would
> happen?<?xml:namespace prefix = o ns =
> "urn:schemas-microsoft-com:office:office" />
>
> 2)  In the Summary, 1)c) is terribly idealistic: "transfers become
> transactions predicated on trust and an assumed lack of malfeasance."
When
> you consider the diversity among registrars and then add the thousands of
> resellers to the equation, there needs to be a balance between protection
> against fraud or mistakes and ease of process.
>
> 3)  General Principle r) applies to EPP only and is really not a general
> principle but rather an explicit requirement.  The TF should make it clear
> that this only applies to EPP-based Registries.
>
> 4)  General Principle s) is not clear. What is meant by "the Losing
> Registrar MUST NOT employ transfer processes as a mechanism to secure
> payment for services from a Registrant."  This seems to contradict 3)e)v)
> which allows a NACK of a transfer if payment has not been made for the
> previous period.
>
> 5)  General Principle t) may need to be reworked in order to reflect that
a
> Registrar should be allowed to have a LOCK service so long as the LOCK
> service allows the Registrant to UNLOCK the name as well.
>
> General Provisions:
>
> 3)d)ii) - what is a "reasonable request by the Losing Registrar."  That is
> way to subjective and must be explicitly defined in an objectively
> measurable way or the words "reasonable request" should be deleted.  We
> believe that the Gaining Registrar should ALWAYS turn over the
documentation
> upon ANY request rather than having it be a reasonable request.  Having it
> be only upon a "reasonable" request is too subjective and will require
> someone to interpret whether the request is reasonable or not.  Plus, the
> current contracts require the gaining registrar to turn this over upon ANY
> request (whether or not reasonable).
>
> 3)f)iii) should probably be qualified further.  Situations where a
> registrant has subscribed to a service with the registrar to LOCK a name
to
> prevent unauthorized transfers and where the registrar has clear
procedures
> for the registrant to remove that status should probably be allowed.
>
> 3)g) - same as the comment for 3)d)ii) above.
>
> Gaining Registrar Processes Narrative:
>
> 5)b) - How would the accuracy of Whois data be verified after the fact?
> Whois data could have changed.  This is especially problematic for the
> Non-EPP based registries.
>
> 5)k)ii) - It appears that the FOA is not required for electronic
> authorization.  Is that intentional?  It seems like the FOA should be
> required for all authorizations or that all email authorizations should be
> standardized to avoid confusion for users and ensure simplicity of the
> process.
>
> Optional Losing Registrar Processes Narrative:
>
> 7)d) Probably should add "&/or Admin Contact" after Registrant in both
> places.  Depending on the business model employed by registrars, it might
> not always be possible to notify the Registrant.
>
> Resolution of Disputes:
>
> 8)b) - There are two references to "9.a.i."  What is the correct
reference?
> I don't think there is a "9.a.i" in the entire document.
>
> 8)c)iii) - Depending on what type of enforcement process is used, access
to
> Whois and accuracy of Whois data are required for registrars, registries
and
> the DRP.  Some steps should be taken toward this objective (e.g., if
Losing
> Registrar Whois is inaccessible or inaccurate, should a transfer be
allowed?
> Otherwise, it would be an easy way to block transfers.
>
> 8)e)i)(1) - It seems to me that the DRP rules drafting committee should be
> primarily composed of registrars and registries instead of TF members.  It
> is critical to have strong involvement of those who understand operational
> impacts.
>
> 8)e)iv) - I am not sure that the DRP should decide resolution.  The DRP
> should only determine whether or not the policy has been violated.
> Resolution then would happen based on the agreed to policy.
>
> 8)e)vi) - How would fees be collected?  It would create a collection
problem
> for ICANN. Registrars paying registrars directly wouldn't work.
>
> We can discuss these more tomorrow.
>
> Jeffrey J. Neuman, Esq.
> Director, Law & Policy
> NeuStar, Inc.
> Loudoun Tech Center
> 46000 Center Oak Plaza
> Building X
> Sterling, VA 20166
> p: (571) 434-5772
> f:  (571) 434-5735
> e-mail: Jeff.Neuman@Neustar.us <mailto:Jeff.Neuman@Neustar.us>
>
> PLEASE NOTE THE CHANGE OF ADDRESS AND TELEPHONE NUMBER AS WE HAVE MOVED
FROM
> OUR WASHINGTON, DC OFFICE.  THANKS.
>
>
> The information contained in this e-mail message is intended only for the
> personal and confidential use of the recipient(s) named above. This
message
> may be an attorney-client communication and/or work product and as such is
> privileged and confidential. If the reader of this message is not the
> intended recipient or an agent responsible for delivering it to the
intended
> recipient, you are hereby notified that you have received this e-mail
> message and any attachments hereto in error and that any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately by e-mail, and delete the original message.
>
>
>