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

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

On 16 Nov 2010, at 07:18, Alan Greenberg wrote:

> My comments in BLUE For clarity (hoping that the colours get through the 
> mailing list).
> 
> I have already addressed some of these issues in my general message sent just 
> before this one.
> 
> 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
> 
> Not sure which part you are questioning. The (0-45) + 30, or the "typically 
> 60"?

either - you keep referring to "how things were", but I still haven't seen any 
clearly documented references to this and various people have also questioned 
this in the past

> 
> 
> 
> 
>> > 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 ..
> 
> Don't understand that. To use and example, if the domain in question is 
> galaxy.org then after expiration and having interrupted the service, you KNOW 
> that mail sent to the admin contact of <hitchhiker@xxxxxxxxxx> will not get 
> through. 

You don't know how we send email to registrants.


> 
>> >
>> > =     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"
> 
> I don't want to get into a semantics game. The current RAA uses the term 
> "notice" generally without a verb. The intent is that "notice must not be 
> given solely by pull methods"

You are the one who raised it - not me.



> 
> 
>> >
>> > =     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
> 
> We want the registrant to be able to receive and act on notices sent by the 
> registrar. Isn't it reasonable to tell the registrant how they should expect 
> to receive them? 

No, because by specifying them narrowly you would make it hard for us to use 
alternatives or if the listed method didn't work for whatever reason or was not 
available we wouldn't be able to use a different one

> 
> 
>> >
>> > =     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
> 
> The concept is that the RrSG or a (not currently existing) Registrar 
> Association develops a set of best practices and Registrars who adhere to 
> them may display the "Gold Star of Registrar Practices". 


Ok, but I honestly can't see that ever happening

> 
> 
>> >
>> > 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?
> 
> The the registration/renewal does not go through. 

That's a legal and economic nightmare



> Just as many registrars today ask the registrant to tick off a box saying 
> that they have read and understand the registration agreement.
> 
> 
>> >
>> > =     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
> 
> Why? This is not saying that every registrar must use e-mail and SMS - that 
> was just an example of what a particular registrar might do.

I don't see what you are getting at. You don't seem to understand that while a 
small number of registrars *might* be in a position to do certain things that 
it does not scale. And don't forget that the registrar is also going to be held 
accountable for action (or inaction) on the part of their resellers


> 
> 
>> >
>> >
>> > 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
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845