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

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

On 12 Nov 2010, at 17:11, Alan Greenberg wrote:

> Michele, perhaps this is a new direction in policy, although I suspect there 
> are other examples if we look for them. Regardless, the concept of 
> "exceptions" was to address the regular comments from registrars that 
> "one-size-fits-all" solutions will generate real operational and business 
> problems.
> 
> As a simple example, consider the case of the Brazilian registrar that didn't 
> want to darken/redirect traffic soon after expiration. He said they would 
> ultimately do that if other means of waking up the registrant did not work, 
> but first they wanted to be able to take those other means. So we are 
> certainly not going to mandate by policy that you every registrar smakes 
> phone calls or sends registered letters to alert the registrant, but if 
> someone wants to do that instead of darkening/redirecting the domain, the 
> exception process will allow them to do that. It would not give them an 
> exception from the intent of the policy, but from the particular 
> implementation prescribed as the default. A completely impractical and 
> unwieldy alternative would be for the policy to list 10 (or whatever) 
> different method of achieving the end. But no one wants to do that, nor would 
> it be effective.

Alan

While I understand what you are trying to do with this I don't see it being 
workable, which is why I do not support it.
The other option is to choose a baseline and let registrars choose to exceed 
that baseline depending on their own situation / business model / customer base 
etc etc 

I made other comments on your post, but I think you only saw the first 
paragraph :)

Regards

Michele


> 
> Alan
> 
> At 12/11/2010 08:50 AM, Michele Neylon :: Blacknight wrote:
> 
>> 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
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845