ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

Re: [gnso-pednr-dt] PEDNR: A proposed path forward

  • To: "James M. Bladel" <jbladel@xxxxxxxxxxx>, Alan Greenberg <alan.greenberg@xxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] PEDNR: A proposed path forward
  • From: MICHAEL YOUNG <myoung@xxxxxxxxxxxxxxx>
  • Date: Sun, 07 Nov 2010 16:53:14 -0400

Hi all,

Just quick update about where the Registries are with this idea.  I did
forward the proposal to our list and have scheduled it for discussion in the
RySG meeting this Wednesday.

Thus far I have received no negative feedback or showstopper concerns.

Initial comments that came back indicate at least some interest in RGP being
forwarded to the status of a consensus policy BUT at least one Registry
would require an exception .Coop.  It¹s also possible that in another use
case such as new ³Corporate² Registries ( ie. Dot IBM or dot Google - now
talking about NTLDs), where they don¹t actually sell any registrations and
ultimately hold the related IP on the whole domain space, that RGP would not
be an appropriate as a mandatory grace period. I don¹t know yet if the RySG
feels strongly just yet about RGP as a consensus policy, this Wednesday¹s
meeting should clarify that.

Another raised point in our mailing list was an interest to see this
new(ish) grace period within autorenew grace be a little longer than five
days. Again I will clarify that on Wednesday and provide feedback.

I¹d like to thank James, Alan and everyone that worked so hard to push this
proposal forward to the group.  I believe we all would like to move forward
with to a successful conclusion of this effort and this proposal has great
promise of getting us to that end.

Michael Young


On 10-11-03 2:22 AM, "James M. Bladel" <jbladel@xxxxxxxxxxx> wrote:

> Thanks, Alan.  And while not an entirely "new" grace period, the proposal
> would set aside the first 5 days of the Auto-Renew Grace Period for renewal by
> the RAE, and postpones the registrar's own post-expiry practices (whatever
> those may be) until this period has concluded.  And since this is not free to
> the registrar, we must allow the registrar the option of explicitly deleting
> the name and initiating the 30 day Redemption Grace Period at the registry.
> 
> As discussed on the call, most (if not all) of the larger registrars already
> exceed this minimum by several days or even weeks.  But the proposal would
> provide a new (and standardized) protection for RAEs who have missed their
> renewal date either by error or miscommunication.
> 
> Thanks--
> 
> J.
> 
>> -------- Original Message --------
>> Subject: RE: [gnso-pednr-dt] PEDNR: A proposed path forward
>> From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
>> Date: Tue, November 02, 2010 3:26 pm
>> To: "James M. Bladel" <jbladel@xxxxxxxxxxx>
>> Cc: "PEDNR " <gnso-pednr-dt@xxxxxxxxx>
>> 
>>  James, as mentioned on the call, I didn't read this proposal as a new period
>> but as a replacement for the one we have been talking about. That pus it in a
>> different light.
>> 
>>  Regarding the 30-75, prior to the practice of transferring/auctioning names
>> (but after the EDDP), a name would either be renewed or deleted. It could be
>> deleted by the registrar immediately after expiration, but under EDDP, it
>> could not be held for more than 45 days following expiration. Once deleted,
>> it would go into RGP for 30 days. So a registrant had a total between 30 days
>> (if the registrar deleted immediately) and 75 days (if the registrar held
>> onto the name for the full 45 days).
>> 
>>  Alan
>> 
>>  At 02/11/2010 01:55 PM, James M. Bladel wrote:
>>  
>>> Alan and Team:
>>> 
>>>  I'm not clear on the "30-75 days" example given below.  Currently, there is
>>> nothing in consensus policy to prevent a registrar from deleting a name
>>> -immediately- upon expiration.  So offering a 5-day window backed by policy
>>> is indeed significant.
>>> 
>>>  And let's keep in mind that the intention behind this proposed grace period
>>> is to allow for mis-communication, billing errors, differing holiday
>>> calendars, etc.  Anything greater than 5 days and we are, in effect,
>>> requiring registrars to offer free services and disregarding the
>>> responsibilities of the Registrant.  Most registrars would likely opt for
>>> immediate deletion to avoid these extra costs.
>>> 
>>>  Looking forward to our call.
>>> 
>>>  J.
>>> 
>>>   -------- Original Message --------
>>>  Subject: Re: [gnso-pednr-dt] PEDNR: A proposed path forward
>>>  From: Alan Greenberg <alan.greenberg@xxxxxxxxx >
>>>  Date: Tue, November 02, 2010 12:48 pm
>>>  To: "James M. Bladel" <jbladel@xxxxxxxxxxx>, "PEDNR "
>>>  < gnso-pednr-dt@xxxxxxxxx <mailto:gnso-pednr-dt@xxxxxxxxx> >
>>> 
>>>  James, thanks for getting this going. There is some good stuff here,
>>>  but as you can surely imagine, in my view it does not really go far
>>>  enough. I will make a few comments below, but more will come.
>>> 
>>>  Alan
>>> 
>>>  At 01/11/2010 03:12 PM, James M. Bladel wrote:
>>> 
>>>>  >Good afternoon, everyone.
>>>>  >
>>>>  >
>>>>  >With our review of community feedback complete, several of us on the WG
>>>>  >have been working to synthesize all the various positions and opinions
>>>>  >expressed on PEDNR into a compromise proposal.
>>>>  >
>>>>  >
>>>>  >The objectives of putting this forward are:
>>>>  >
>>>>  >(1) Provide additional safeguards for registrants to guard against the
>>>>  >inadvertent loss of registrations, secured by Consensus Policy.
>>>>  >(2) Provide some consistency in the registrant's experience with
>>>>  >expiring names.
>>>>  >(3) Accomplish (1) and (3) in a manner that does not unnecessarily
>>>>  >disrupt the numerous commercial and non-commercial activities in our
>>>>  >industry.
>>>>  >
>>>>  >With these in mind, we submit the following slate of proposals for your
>>>>  >consideration.
>>>>  >
>>>>  >
>>>>  >Grace Period (Secured by Consensus Policy)
>>>>  >-------------------------------------------
>>>>  >Guaranteed five-day registrar grace period (what to call it will need to
>>>>  >be determined so as to avoid confusion with similarly named periods)
>>>>  >following expiration. Only the RAE can recover/renew name during this
>>>>  >period. While the name will not go to auction during this period, it
>>>>  >could be explicitly deleted by the Registrar, which commences the RGP.
>>> 
>>>  Before registrars began the practice of transferring and auctioning
>>>  domains at expiration, all registrants had a 30-75 day period within
>>>  which to recover their expired name. Typically it was 60. This WG has
>>>  decided not to question the registrar right/ability 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.
>>> 
>>>  So, my question to counter Jeff's is not why more time, but rather
>>>  why is it that registrars feel that REDUCING the amount of time by a
>>>  factor of 6 to 15 times is reasonable.
>>> 
>>>  I do appreciate that this proposal says that registrars will delay
>>>  beginning auctions until the period has expired. It is a nice idea.
>>>  But this is not really of importance from the point of view of our
>>>  charter, which is considering whether the name is recoverable. Some
>>>  registrars have a practice of starting auctions very early, but the
>>>  terms are t hat if a RAE comes in and says they want it back, the
>>>  auction/sale is cancelled or reversed.
>>> 
>>>>  >Renewal notices (Secured by Consensus Policy)
>>>>  >---------------------------------------------
>>>>  >Requirement to send (by a method at each registrar's discretion) a
>>>>  >minimum of one renewal notice to registrant no later than 10 days prior
>>>>  >to expiry, and a second notice the day prior to the expiry date
>>>>  >notifying the RAE that the 5-day registrar grace period will begin the
>>>>  >following day.
>>> 
>>>  This is basically in line with what we have discussed before, but I
>>>  would like to understand why the first notice may come so late, given
>>>  the statements that have been made about monthly bill processing and
>>>  the time it may take for a registrant to process a payment.
>>> 
>>>>  > Whois
>>>>  >-----
>>>>  >No changes to Whois recommended.
>>> 
>>>  This was one of the few things that we had almost complete consensus
>>>  on, so I am a bit surprised that it is now off the table. I do
>>>  recognize that it is one of the few things that we have been talking
>>>  about that would require a significant work effort on behalf of all
>>>  registrars and registries, but I think that taking it off the table
>>>  (as opposed to a long phase-in time) is premature.
>>> 
>>>>  >
>>>>  >
>>>>  >Community Education
>>>>  >-------------------
>>>>  >Registrars:
>>>>  >Best practice recommendation: A registrar will design and host a
>>>>  >neutral-content site with important information about how to properly
>>>>  >steward a domain name and prevent unintended loss.
>>>>  >Registrar should provide on its web site, and send to registrant in
>>>>  >separate e-mail to registrant immediately following initial
>>>>  >registration, a set of instructions for keeping domain name records
>>>>  >current and for lessening the chance of mistakenly allowing the name to
>>>>  >expire.
>>> 
>>>  No problem here.
>>> 
>>>>  >
>>>>  >ALAC:
>>>>  >Budget time/money/resources to public education campaign to encourage
>>>>  >renewals and prevent unwanted loss of a name.
>>> 
>>>  Not sure this fits as an ALAC task (all the more so because we HAVE
>>>  no money and minimal non-volunteer resources) but certainly ICANN
>>>  with involvement of ALAC is reasonable.
>>> 
>>>  As I said, more to come, since there are a number of issues that have
>>>  been omitted completely (such as web sites going dark or redirected),
>>>  but that will wait.
>>> 
>>>  Alan
>>> 
>>>  
>>   
> 



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

Privacy Policy | Terms of Service | Cookies Policy