ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

Re: [gnso-pednr-dt] a modest attempt to draw the post-expiry flow-chart

  • To: PEDNR <gnso-pednr-dt@xxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] a modest attempt to draw the post-expiry flow-chart
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Fri, 5 Feb 2010 12:05:07 -0600


On Feb 5, 2010, at 11:45 AM, Michele Neylon :: Blacknight wrote:

> 
> 
> On 5 Feb 2010, at 17:28, Mike O'Connor wrote:
>> 
>> 
>> - i'd like to gently suggest that this process is perhaps pretty complicated 
>> for a normal person to navigate (imagine your small-business owning uncle, 
>> or a friend who's operating the web site of your neighborhood association, 
>> or a relative who's doing a blog).
>> 
>> - i'd like to throw a "wish list" of ideas in front of you.  some of them 
>> are pretty easy, some are hard, and some are stupendously hard.  but this is 
>> the list that fell out as i (an ops guy) was doing the diagram and what the 
>> heck, a person gets to dream.
> 
> As long as you know there's a difference between dreams and reality :)

you know, i've had a pretty loose grip on reality for quite some time now.  i 
think it was my triple-major in college (drugs, sex, rock n'roll)

> 
> Any chance of you sending me / the list the wishlist in a text format? It's 
> proving impossible to copy / paste from that PDF :)

oops.  i thought i was creating a text-readable PDF.  sorry about that.  here's 
the list;

•Mikey’s Wish List – easy stuff

Originate renewal notices from a consistent/distinctive email address that is 
used for no other purpose (and remind registrants to white-list the address in 
spam filters)
Establish minimum expiration-reminder schedule (pre and post-expiry)
Provide consistent “service disruption” across registrars on expiration
Always disrupt web service on expiration – triggers active/technical response
Do not disrupt email on expiration – to aid in contacting registrant
Provide consistent and informative domain-status flags across registries, 
registrars and TLDs
Provide “plain language” versions of the various policy statements, with 
disclaimers that point to the “real deal” legal stuff
Change confusingly-similar terms like “automatic renewal” vs “auto renew grace 
period”


•Mikey’s Wish List – harder stuff

Work to eliminate confusing registrar-slamming schemes
Establish minimum standards for registrar WHOIS information display (data 
elements, sequence, captions, consistency, availability, etc.)
Provide consistent minimum processes across registrars and TLDs to determine 
domain status
Provide consistent notification/display of deletion, automatic-renewal, 
auto-renew grace-period and redemption grace-period policies on 
reseller/registrar web pages
Provide consistent redemption grace-period intervals rather than leaving it up 
to provider discretion
Provide consistent post-expiry implications when registrants elect not to 
automatically-renew domains and/or opt out of monetization of web addresses

•Mikey’s Wish List – really hard stuff

Eliminate conflict of interest – registrar either generates revenue from 
renewal OR monetization/aftermarket-auction/drop-catching, not both
Offer a mechanism (perhaps a “token”?) during Pending-Delete that can be used 
by registrant to recover the name in the drop-catching/auction post-delete
Shift all TLDs to thick-registry model to aid in normalizing WHOIS-based 
processes

> 
> 
>> 
>> i don't really want to poke a stick in anybody's eye here -- i like 
>> diagramming processes because it's a way to take a look at something in a 
>> way that doesn't necessarily generate quite so much emotion.  it's just a 
>> diagram.  it's almost certainly wrong.  think of it as a place to start.
>> 
>> a final note -- this reflects my own personal work and certainly doesn't 
>> reflect the views of the BC.  view this as the ravings of a deranged lunatic.
> 
> We were going to anyway :)

<grin>

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     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