ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

Re: [gnso-pednr-dt] Your feedback requested - outstanding items from last week's call

  • To: Ron Wickersham <rjw@xxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] Your feedback requested - outstanding items from last week's call
  • From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
  • Date: Tue, 1 Feb 2011 14:02:47 -0500


At 01/02/2011 01:49 PM, Ron Wickersham wrote:


On Tue, 1 Feb 2011, Marika Konings wrote:

> Dear All,
>
> In order to facilitate discussion and input prior to our meeting, also for those not being able to join today's call, please find below the main outstanding items based on last week's meeting:
>
> * Recommendation #2 - Define Registered Name Holder at Expiration" (RNHaE) as the Registered Name Holder of record just prior to the Expiration of the Registered Name.
>
> Comments: The language needs to be precise regarding which registrant is being referred to. Presumably the one that is in WHOIS prior to Expiration. (Any suggestions for further improvement?)

It seems to me that the "Registrant" or Registered Name Holder is that
person/organization who had the right to renew the domain prior to expiry
and during the Autorenew Grace Period it is already understood that
this "Registrant" is whom is being talked about as being offered the
grace-period renewal "right".   Changing the WHOIS does not change this.

Can our wording be the same as that currently in use for the Autorenew
Grace Period?

Currently, most registrants give their permission at registration time to allow the name to be reassigned to someone else post-expiration. And that someone-else renews it. The proposal here is that such a reassignment permission doesn't count in this case.


> * Recommendation #3 - Following expiration, during Autorenew Grace Period, if a Registrar Deletes a Registered Name and that Registered Name enters the RGP, the Registrar must allow the Registered Name Holder at Expiration to redeem the Registered Name. This is regardless of any changes made to Whois data or other records between expiration of the domain and entering RGP. This is excepted where the Registrant has explicitly agreed to a reassignment of the domain, in a separate unilateral action at the time of reassignment, name to another Registered Name Holder.
>
> Comments: Michael Young to provide further information. The WG also discussed that the recommendation should specify what the authoritative source for the information on the Registered Name Holder at expiration should be e.g. as shown in WHOIS. (WG members encouraged to provide alternative language for consideration)

There can only be _one_ Registered Name Holder at a time.   And if it is
clear who that is before expiry, and who it is during the Autorenew Grace
Period, then why is it unclear during any newly-created Grace Period?

I agree that WHOIS is not authoritative in this case, and support changes
in WHOIS, but that is beyond the scope of this WG, other than to point
out the confusion and lack of transparancy in the current practice of
some Registrars with respect to their changes in WHOIS after expiry.

And the Registered Name Holder is the only one who can authorize
reassignment of the domain.  (Well there is an exception for courts
to instruct ICANN or a Registry to reassign).

After expiry (and all grace periods have passed) the original procedure
was to place the domain back in the pool of available domain names.  More
recent practice is to _involuntarily_ reassign the Registered Name Holder
to a Registry (or their assignee) for exclusive remarketing the domain name.

Not quite. It is not involuntary. The registrant DOES give permission (whether they are conscious of this or not) - way ahead of time.


I would be interested in clarification of this involuntary reassignment...
is it in the RAAs or is it in the Registration Service Agreement between
the Registrant and the Registrar/Reseller?


-ron




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

Privacy Policy | Terms of Service | Cookies Policy