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

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

I have been asked to clarify a few of the items. 
Hopefully this will address those questions here 
, and also add a few more thoughts.
At 09/11/2010 10: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.>
An earlier version of this separated the fact 
that it be a consensus policy from the 
specification of the number of days. Since 
consensus may be reachable of the former easier 
than on the latter, I suggest that we separate this into two recommendations.

> =       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).
Although one could debate whether e-mail is truly 
"push" since typically you need to fetch your 
mail from a server, the intent here was to 
include e-mail as an acceptable push method.

> =       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.
This said what it meant. The policy/RAA will not 
prescribe specific notification methods, but the 
agreement must alert the registrant to what 
methods will be used (as a minimum). Typically I 
would guess that this would be "e-mail to the 
administrative contact" or something similar.

> =       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.>
The intent here is that the price displayed is 
the then-current price. Although any registrar is 
welcome to guarantee that this price will be 
honoured when the domain expired in 10 years, 
that was not the intent of this requirement.
For the RGP price in the current RAA, it says: 
"3.7.5.6 If Registrar operates a website for 
domain registration or renewal, it should state, 
both at the time of registration and in a clear 
place on its website, any fee charged for the 
recovery of a domain name during the Redemption 
Grace Period." I have not heard about any 
confusion regarding this, so presume similar 
wording can be used for the pre-delete recovery 
price with registrars using whater words they 
feel are necessary to that they are not 
unreasonably setting registrant expectations.

> =       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.>
I agree with the comments that this may be 
difficult, or should be tied to some other part 
of WHOIS revision. That is why I made  the 
comments on time-lines. Clearly we will need to look at the alternatives.

> =       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.
This was not an attempt to sneak in a requirement 
that all names must be deleted instead of 
auctioned/sold/transferred. As much as some 
people would like to see that happen, we have 
decided that it is not in scope for this PDP. 
"Offering the RGP" is applicable only for those 
domains that the registrar, for whatever reason, DOES delete.

> =       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.
This wording surely needs to be cleaned up. The 
intent is that a registrar cannon relieve 
themselves of an RAA responsibility simply 
because it is delegated to a reseller (and 
possibly to multiple nested resellers). It is 
likely a fact of business law regardless of 
whether it is in the RAA, but it is important 
that it is explicit. The current RAA makes it 
clear for a specific list of Registrar 
responsibilities, but not for all that could be delegated.


> 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.
My preference is that there be no exceptions. 
However, I believe that this will not be 
something that can be sold to all registrars, 
particularly those outside of North America and 
Western Europe where business practices may be 
quite different. An alternative is to provide 
multiple options on how to do certain things in 
the policy. But that will be awkward and will 
never meet the variable needs. I think that the 
type of exceptions requested will generally fall 
into specific categories and will not be too 
onerous to implement. But we will need to look at the details.


> 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.>
Whatever is decided in the previous discussion 
regarding Registrars applies here as well.
Alan



> 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.