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