Re: [gnso-pednr-dt] Additional proposed recommendations

["Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>]

On 12 Nov 2010, at 14:06, James M. Bladel wrote:

> I'm concerned that we are allowing the Perfect to become the enemy of the 
> Good. 
> 
> Many of us have the stated goal of moving this PDP to some sort of meaningful 
> conclusion, with tangible outcomes to show for our work.  I'm convinced that 
> the original proposal does this, while also providing an opportunity to 
> study/measure/quantify the issue further and leaving the door open to future 
> work.
> 
> But if we continue to bolt on new proposals, I'm concerned that the consensus 
> we've worked to build will evaporate, and we will be working on this for 
> another 12-18 months, with no assurances that the result will be any better 
> than what we have on the table now.
> 
> Just my thoughts before the weekend. 

James

You pretty much summed up my feelings on this. Thanks

Regards

Michele

> 
> J.
> 
> -------- Original Message --------
> Subject: Re: [gnso-pednr-dt] Additional proposed recommendations
> From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
> Date: Fri, November 12, 2010 7:50 am
> To: PEDNR <gnso-pednr-dt@xxxxxxxxx>
> 
> 
> Alan
> 
> Your email confused me
> 
> Either you are advocating a policy change or you aren't.
> 
> The "exceptions allowed" concept seems to break that badly
> 
> With respect to the specific items you mentioned, I'm sure others will have 
> comments of their own, so I'll just limit myself to the ones that I have 
> clear reactions to
> 
> To start with this entire PDP has been run on the basis of there being a 
> problem, however there is little or no factual evidence of there being one.
> 
> Any "cases" that people seem to be able to find to point to are related to 
> registrants not paying for renewals (either intentionally or otherwise)
> 
> In the IRTP WG, for example, we were able to work with actual data from 
> ICANN's compliance team who had collated a spreadsheet itemising and 
> classifying actual complaints submitted by the public
> 
> 
> 
> On 9 Nov 2010, at 15:34, Alan Greenberg wrote:
> 
> > 
> > To the possible list of recommendations, I would like to add the following. 
> > Although I have consulted with a number of people on this, and have general 
> > support, I am submitting this on my own behalf (and clearly not wearing the 
> > Chair hat).
> > 
> > These recommendations are all in line with the non-registrar WG survey 
> > results and also with the outcomes of the user survey.
> > 
> > With one exception to be noted, based on the results of the registrar 
> > survey we did at the start of the PDP, the recommendations should not 
> > require significant changes in business processes or massive changes to 
> > their procedures (at least as far as I understand). Some of these replicate 
> > (perhaps with an added twist) what was in the proposal tabled by James. It 
> > does introduce a new ICANN process.
> > 
> > Consensus Policies - Registrars
> > 
> > =   Registrar must allow recovery of domain name by the registrant of 
> > record prior to expiration (RAE) for at least a period of thirty (30) days 
> > after expiration or until the name is deleted, whichever comes first. 
> > <Rationale: Before the registrars started transferring and auctioning 
> > domains at expiration, all registrants had a 30-75 day period within which 
> > to recover. Typically it was 60.
> 
> I'm not sure that's factually correct
> 
> If it is please provide links to tangible data
> 
> 
> 
> > This WG has decided not to question their right to do this (which does earn 
> > a lot of money for some), but that is no reason to reduce the time that a 
> > registrant has to recover. That is where the 30 came from, since it was the 
> > absolute minimum before. And that required deleting the name on day 1 of 
> > expiration, a practice that few registrars had. Note that this version of 
> > the guaranteed period does NOT place restrictions on Registrars about when 
> > they may begin a sale/auction, but does restrict when they can finalize it. 
> > This is in line with the current practices described by registrars under 
> > which I believe all registrars surveyed gave registrants at least 30 days 
> > to recover.>
> > 
> > =   Registrar must send at least two renewal notifications alerting the 
> > registrant to the upcoming expiration. [Exceptions allowed - see below] <As 
> > per James' proposal but allowing exceptions.>
> 
> Rejected.
> Either everyone does it or nobody does it.
> 
> You can't expect it to be a policy for some and not for others 
> 
> 
> > 
> > =   If only two renewal notifications are sent, one must be sent one month 
> > prior to expiration (±4 days) and one must be sent one week prior to 
> > expiration (±3 days). If more that two alert notifications are sent, the 
> > timing of two of them must be comparable to the timings specified. 
> > [Exceptions allowed]
> > 
> > =   At least one notification must be sent to the registrant after 
> > expiration. {The timing to be specified.} [Exceptions allowed]
> > 
> > =   If notifications are normally sent to a point of contact using the 
> > domain in question, and delivery had been interrupted by post-expiration 
> > actions, post-expiration notifications must be sent to some other contact 
> > point associated with the registrant if one exists.
> 
> We have no way of knowing this until we send the notification and we probably 
> can't really do anything about it anyway .. 
> > 
> > =   Notifications must include "push" methods in addition to any "pull" 
> > methods - not solely be via methods that require logging into the 
> > registrar's system to retrieve them (ie the Registrar's Domain Management 
> > Panel).
> 
> Redundant. You already specified that notifications be "sent"
> 
> > 
> > =   The registration agreement and registrar web site (if one is used) must 
> > clearly indicate what methods will be used to deliver pre- and 
> > post-expiration notifications.
> 
> Disagree
> The key thing is that we send them in a "sane" manner. Forcing us to specify 
> exactly how could have secondary consequences
> 
> > 
> > =   Web site or sites reached via the domain name must not longer be 
> > reachable through the use of the domain name within 3-5 days after 
> > expiration. [Exceptions allowed] <Note that this and the next item alter 
> > the intent of the Autorenew Grace Period, but it is exactly what most 
> > Registrars do today, and there seems to be widespread belief that this is 
> > the only relatively fail-safe method of catching the RAE's attention. The 
> > exception process will allow Registrars with other business models and 
> > other notification methods to carry on their businesses without change.>
> > 
> > =   All non-web services must cease to function within 3-5 days after 
> > expiration. [Exceptions allowed]
> > 
> > =   If registrar allows any web access to the domain name after the 
> > "disable" date, the page shown must explicitly say that the domain has 
> > expired and give instructions to the RAE on how to recover the domain.
> > 
> > =   The price charged for post-expiration recovery must be explicitly 
> > stated in the registration agreement or on the Registrar's web site (if 
> > any). This price must also be provided to the RAE at registration time
> 
> That is not practically possible.
> 
> If you register a domain today for 10 years there is no way that the 
> registrar can know what the registry is going to be charging them to renew 
> the domain in 10 years time. It is wholly unreasonable, impractical and 
> impossible to expect registrars to be locked into providing pricing at day 0 
> that is valid at day 3650
> 
> Unless of course you want us all to start charging say $10k / year for a .com 
> ?
> 
> 
> 
> > and when pre-and post-expiration renewal notices are provided. <Rationale: 
> > This is comparable to the current requirement regarding RGP redemption 
> > pricing.>
> 
> No it isn't
> 
> > 
> > =   Modify WHOIS to clearly indicate whether a domain has been renewed from 
> > a registrant:registrar point of view. Specifically, it should clearly 
> > identify a domain in the Auto Renew Grace Period which has not been 
> > explicitly renewed by the registrant <This proposal is the one that would 
> > require significant effort on behalf of all registrars and registries. If 
> > adopted, it would require significant phase-in time which should not impact 
> > the schedule of the other items.>
> 
> While I'd personally love to see this at some point, it's probably best left 
> to a more comprehensive review of WHOIS.
> I can't see this being supported by registries or registrars 
> 
> > 
> > =   In the event that ICANN gives reasonable notice to Registrar that ICANN 
> > has published web content providing educational materials with respect to 
> > registrant responsibilities and the gTLD domain life-cycle, and such 
> > content is developed in consultation with Registrars, Registrars who have a 
> > web presence must point to it. [Exceptions allowed]
> 
> Again with the exceptions
> 
> Either we all have to do something or we don't
> 
> The alternative is that you admit that we're all adults and are capable of 
> adopting "best practices" .. 
> 
> > 
> > =   All Registrars must offer the RGP for gTLDs where the Registry offers 
> > it.
> 
> > 
> > =   All RAA provisions applicable to Registrars dealing with 
> > registrar-registrant interactions must be carried out by either the 
> > registrar or, at their option, by a reseller. In the latter case, 
> > Registrars are still responsible for any breaches.
> 
> We already are under the 2009 RAA
> 
> 
> > 
> > 
> > Registrar Exceptions
> > 
> > For all provisions where Exceptions are allowed, the Registrar may submit a 
> > request to ICANN to substitute some other mechanism instead of the one(s) 
> > specified, and must demonstrate how this alternative mechanism will provide 
> > at least the same protection while better fitting to the Registrar's 
> > business model or services. Such requests will be reviewed by an impartial 
> > panel (similar to that provided with the Registry RSTEP process, or perhaps 
> > even the same panel) and shall be acted upon in a timely manner by ICANN.
> 
> No.
> 
> 
> > 
> > 
> > Consensus Policy - Registries
> > 
> > =   All unsponsored gTLD Registries shall offer the RGP. For currently 
> > existing gTLDs that do not currently offer the RGP, a transition period 
> > shall be allowed. All new gTLDs must offer the RGP. There could be an 
> > automatic exemption for TLDs that do not sell domains at all (what has been 
> > referred to in the VI group as SRSU).
> > 
> > =   Modify WHOIS to clearly indicate whether a domain has been renewed from 
> > a registrant:registrar point of view. <With caveat as noted above.>
> > 
> > 
> > Registrar Best Practices
> > 
> > This could perhaps be implemented in one of two ways.
> > 
> > a. The Registrar community can develop these Best Practices including some 
> > methodology which will give registrars an incentive to implement them if 
> > applicable. or
> 
> Why would we give ourselves incentives?
> 
> Sorry - I don't follow that
> 
> > 
> > b. ICANN can develop these Best Practices and provide a financial incentive 
> > to registrars who follow them.
> > 
> > These are not meant to be verbatim Best Practices but will serve as a basis 
> > for their full development.
> > 
> > =   Issue a warning if contact addresses use the domain being registered / 
> > renewed / updated.
> 
> Technically difficult if not impossible to implement
> > 
> > =   Expiration-related provisions of registration agreement clear and 
> > understandable by a non-lawyer, non-domain-professional.
> > 
> > =   Provide notification of impact of not having sufficient accurate 
> > contact information at time of registration, renewal, ICANN-mandated Whois 
> > update notice. Require positive acknowledgement if via web.
> 
> And if they don't acknowledge it what then?
> 
> > 
> > =   Request at least two different modes of contact information (example: 
> > e-mail and SMS) with explanation why two are needed.
> 
> Technically problematic and impossible to implement across all registrars and 
> other channels
> 
> > 
> > 
> > Other issues to consider:
> > 
> > =   Renaming the Autorenew Grace Period to make it clear that it is not the 
> > Automatic Renewal option offered by some Registrars to registrants.
> > 
> > 
> 
> Mr Michele Neylon
> Blacknight Solutions
> Hosting & Colocation, Brand Protection
> ICANN Accredited Registrar
> http://www.blacknight.com/
> http://blog.blacknight.com/
> http://blacknight.mobi/
> http://mneylon.tel
> Intl. +353 (0) 59 9183072
> US: 213-233-1612 
> UK: 0844 484 9361
> Locall: 1850 929 929
> Twitter: http://twitter.com/mneylon
> 
> PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
> -------------------------------
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
> Road,Graiguecullen,Carlow,Ireland Company No.: 370845
> 
> 

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845