[gnso-pednr-dt] Additional proposed recommendations

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

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.