ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

RE: [gnso-pednr-dt] Comments on GoDaddy data and proposal

  • To: Michael Young <myoung@xxxxxxxxxxxxxxx>, "'Mike O'Connor'" <mike@xxxxxxxxxx>
  • Subject: RE: [gnso-pednr-dt] Comments on GoDaddy data and proposal
  • From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
  • Date: Mon, 10 Jan 2011 15:29:58 -0500


At 10/01/2011 02:08 PM, Michael Young wrote:
Guys here's a thought on a possible compromise that might add value.

Mikey and I had extensive conversations and noted that darkening a name (by
a mandatory policy) can solve for one edge case but actually can create an
equivalent amount of harm to other registrants.  So unfortunately at the end
of the day you may have saved a small amount of registrants from losing a
domain, but you likely just caused service interruption to an equal number
of registrants (or greater) that would never have suffered it otherwise.  So
no net gain with mandatory policies that darken the domain.

I would really like to understand how an interruption will cause more problems than the domain completely disappearing. Ultimately, the domain will need to be renewed or deleted within 45 days of expiration. If it is deleted, it will (for most gTLDs) go into RGP and that causes the darkening and it is fine with me.

If a registrar wants to renew it on my behalf, even though I have not left a valid credit card or contacted them, that is also fine with me. Is this normal practice? If not, the domain will ultimately not be usable by the original registrant.

The real goal is getting the attention of the registrant.

An idea:

Perhaps a reasonable alternative would be that registrars, at the time of
registration, consistently request a backup/emergency contact that also gets
notified during the expiration process.  That contact mechanism would have
to be at the registrar's operational discretion since it would need to
support automation.  It could be something like a cell number for texting,
it could be something like an email address that CANNOT BE in the registered
domain, but is something more/different than the standard registrant contact
object.  This contact would explicitly not be a registry contact object, it
would be a matter between the registrar and the registrant for backup
communication during the expiration process.

Thoughts?

I strongly support such mechanisms. But I agree with the folks who said that mandating them may be difficult. Moreover, we have said from the very beginning of this PDP that we are looking to have policy that compels ALL registrar to provide reasonable notice to registrants and not just the larger ones who may take extra pains to do it right.

Alan


Michael Young

M:+1-647-289-1220


-----Original Message-----
From: Mike O'Connor [mailto:mike@xxxxxxxxxx]
Sent: January-10-11 1:22 PM
To: Alan Greenberg
Cc: PEDNR
Subject: Re: [gnso-pednr-dt] Comments on GoDaddy data and proposal


hi all,

i'm finally fully back into the regular routine after a great trip through
South America and the usual holiday madness.

here's where i'm at;

-- Berry dragged me through the data and i realized that the data wasn't
telling me what i thought it was -- so i'm less enthusiastic about 10 days
than i was in Cartagena.

-- i want a clear signal sent to the world (not just the registrant) that
the domain has expired and sufficient time for the registrant to respond to
that signal.

-- i'm willing to listen to ideas other than "the domain going dark" as the
signal, but i remain deeply skeptical of any signal that is sent based on
contact information, or sent by the same channels that have failed in the
past.




On Jan 10, 2011, at 11:52 AM, Alan Greenberg wrote:

>
> In preparation for our meeting tomorrow, I would appreciate you forwarding
and comments to the list prior to the meeting.
>
> Alan

- - - - - - - - -
phone   651-647-6109
fax             866-280-2356
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google,
etc.)




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

Privacy Policy | Terms of Service | Cookies Policy