ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

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

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

Alan I am happy to walk through the use case if you give me a call.  I will
try now though in email

In short many registrars vary expiration behaviour based on the individual
circumstances around the customer.

Take me for example, I have a number of godaddy email accounts that expire a
long time after the domain they are associated with.  In my case Godaddy
would not want to darken my domain by some brute force policy just because I
failed to renew.  They would more likely leave me expired for an extended
period of time while they tried to track me down. Why? In my case (and many
others) the domain is a loss leader. They really want to keep me as a
customer.

The use case where it was valuable to darken a domain to get someone's
attention is out of date by about 6-7 years.  Even then I am not sure it
would have worked, registrants some years ago often parked domains for a
number of reasons: speculation, haven't decided how to launch associated
online services yet, protective/preventative registration and others.  They
often forgot about even active domains because the internet was such as new
animal in the average person's life.   

Nowadays it's pretty different. There are comparatively few parked domains,
domains are either being actively used in PPC, for primary web services or
are forwarded to other primary web services.  Darkening a domain used for
anything other than primary web services would likely not get the
registrant's attention anyways.   

In short, we need to recognize that if the goal is to help the most
registrants, the use cases indicate that a mandatory darkening of the domain
prior to RGP is likely to hurt more Registrants than it helps.  It's like
robbing from the poor to give to the poor - doesn't really get us ahead.

Michael Young

M:+1-647-289-1220


-----Original Message-----
From: Alan Greenberg [mailto:alan.greenberg@xxxxxxxxx] 
Sent: January-10-11 3:30 PM
To: Michael Young; 'Mike O'Connor'
Cc: 'PEDNR'
Subject: RE: [gnso-pednr-dt] Comments on GoDaddy data and proposal

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