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

["Mike O'Connor" <mike@xxxxxxxxxx>]

On Feb 5, 2010, at 1:02 PM, Michele Neylon :: Blacknight wrote:

> 
> 
> On 5 Feb 2010, at 18:05, Mike O'Connor wrote:
> 
>> 
>> 
>> 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)
> 
> For direct registrations under a registrar that shouldn't be an issue. How 
> it's handle by resellers will vary, but I assume they'd be using an email 
> addy that is in some way linked to them ..

yah, me too.  one of the tricky bits here is what to do if the reseller goes 
away (as happened to my friend).  in a way, it would be nice if the same 
practice could be fostered at the reseller level, with the addition of some 
gizmo that ensures that registrants get notices from the registrar if the 
reseller's gone.  like i said -- a little tricky.  maybe *renewal* notices 
*always* come from the registrar?  or maybe a "backup" renewal notice that 
comes from one level up the chain (from the registrar in the case of reseller, 
or from the registry if it's a registrar)?

> 
> 
>> 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
> 
> That won't work
> 
> Technically it's impossible. 
> 
> If the registrant registers AND hosts the domain with us, for example, we 
> could, hypothetically, do this. Stress on "hypothetically". 
> 
> If the domain is using someone else's DNS, which is often the case, we 
> wouldn't have any real visibility on the email
> 
> ALSO
> 
> Email is linked to hosting of some kind.
> 
> If the registrant registers the domain at the same time as they buy the 
> hosting then both services will probably (though not always) expire at the 
> same time.
> 
> Why would a provider continue giving service if they hadn't been paid for it?

hm.  good points all.  could we narrow it?  dropping the web page is easy, 
right?  preserving the email of the registrant is tricky.  clever ideas needed 
here.  maybe validate the email address of the registrant and force it NOT to 
be in the domain?  dunno -- a head scratcher...  i know that a key to the 
puzzle is some mechanism to communicate with the registrant *after* expiry.

> 
> 
>> Provide consistent and informative domain-status flags across registries, 
>> registrars and TLDs
> 
> Do you mean in relation to WHOIS?

yeah -- this relates to our conversation on the IRTP call a few weeks ago where 
we all agreed that the domain-status flags were pretty obtuse.  there's a 
glimmer of hope in looking at the "extended" fields of the status flags in an 
EPP registry...  a massive amount of coordination would be required between 
registrars in thin registries where they're all running their own separate 
WHOIS systems.  but maybe a standards-setting exercise could iron those out.

> 
>> 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
> 
> What do you mean?

ah.  that one popped in because of the process diagram.  remember, our 
"civilian" registrant has to determine whether the renewal notices they're 
getting are even legitimate -- and it's pretty hard for them to tell sometimes. 
 so i dropped this one in here with the intent of backing up a recommendation 
that's coming out of the RAP working group to try to amp up the enforcement of 
WHOIS data misuse, and also take a look at other alternatives with regard to 
getting rid of slamming.

> 
> 
>> Establish minimum standards for registrar WHOIS information display (data 
>> elements, sequence, captions, consistency, availability, etc.)
> 
> Do you mean the format?

yeah.  right now there's lots of variation in the way that registrars display 
WHOIS data.  some show it all, some don't.  some link to underlying registry 
data, some don't.  the sequence and headers of the data differ.  it varies by 
TLD.  it varies by whether there's a thick or thin registry.  it varies by port 
(80 vs 43).  etc.  and etc.  so a consistent format would be great -- and, 
would also help with transfers, methinks.

> 
>> 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
> 
> What do you mean by "consistent"?

this little group of four wishes is really trying to highlight how much 
variability there is in the process right now.  that variability is sometimes 
to be heralded as a Good Thing (stoutly defending the diverse ecology of 
competing providers notion here), but sometimes causes confusion and error.  
there's a very delicate balancing act to be maintained, but i think it would be 
neat if we could get a bit more predictability in the process.  specifically 
relating to the last one -- the implications of "not automatically renewing" or 
"opt in/out of monetization" choices by registrants have pretty different 
implications across providers.  i think it would be great to have conventions 
there.  "if you don't automatically renew, here's what you can expect" that's 
similar across providers would be very helpful.


> 
> 
> 
>> 
>> •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
> 
> I can't see that being acceptable to be honest. I think, in many ways, what 
> you are hoping to achieve can be addressed in other manners without 
> necessarily disrupting business practices

i'm mostly trying to plop that issue on the agenda -- i'm pretty flexible about 
how we tackle it.  i think the main problem is this.  let's imagine that a 
really good domain has slipped into AGRP.  how would you like to be the 
customer service person coaching the customer through the recovery process, 
knowing that your employer is going to make a boatload of money on the auction 
if the customer DOESN'T renew the name.  i'd really like to creatively figure 
out a way to eliminate that conflict.  

> 
> 
>> 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'd support that, though I suspect the registries might not. Apart from 
> anything to do with expiry it would do away with a lot of the issues related 
> to transfers

this is just one that keeps coming up over and over.  it would help a lot of 
things on the "operational" side of things if we could get that infrastructure 
in place.  there are certainly a lot of issues to puzzle through, including 
trust issues, but i think it would be worth the effort.

thanks,

mikey

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