ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

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

  • To: Alan Greenberg <alan.greenberg@xxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] Additional proposed recommendations
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Fri, 12 Nov 2010 07:29:02 -0600

hi all,

sorry this reply is sooo late.  but i wanted to speak up in support of *this* 
suggestion too -- i really like the notion of getting some stuff out on the 
table so that we can start hammering out a suggestion for the future.  

way to go Alan.  let the negotiations continue.  :-)

mikey


On Nov 9, 2010, at 9:34 AM, 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. 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.>
> 
> =     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.
> 
> =     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).
> 
> =     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.
> 
> =     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 and when 
> pre-and post-expiration renewal notices are provided. <Rationale: This is 
> comparable to the current requirement regarding RGP redemption pricing.>
> 
> =     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.>
> 
> =     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]
> 
> =     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.
> 
> 
> 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.
> 
> 
> 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
> 
> 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.
> 
> =     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.
> 
> =     Request at least two different modes of contact information (example: 
> e-mail and SMS) with explanation why two are needed.
> 
> 
> 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.
> 

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