<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-pednr-dt] Additional proposed recommendations
- To: "Mike O'Connor" <mike@xxxxxxxxxx>
- Subject: Re: [gnso-pednr-dt] Additional proposed recommendations
- From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
- Date: Fri, 12 Nov 2010 12:03:50 -0500
Mikey, thanks for the support. One thing I want
to clarify is that, as I said at the end of the
last meeting, my intent in putting this out was
not as a negotiating position to then be
compromised on, but to put on the table
recommendations that some on the group feel are
needed. Perhaps we will ultimately reach
consensus on some issues by negotiation, but
first I want to put them out and see how much
support there was, and discuss whether they meet
anyone's expectations or desires.
Alan
At 12/11/2010 08:29 AM, you wrote:
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
>>>
|