ICANN ICANN Email List Archives

[gnso-pednr-dt]


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

Re: [gnso-pednr-dt] Additional proposed recommendations

  • To: Ron Wickersham <rjw@xxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] Additional proposed recommendations
  • From: Jeff Eckhaus <eckhaus@xxxxxxxxxxxxxxx>
  • Date: Wed, 10 Nov 2010 16:22:50 -0800

Ron,

I am sorry to put you on the spot, but could you please go into further
detail when you say "do not feel it is a substitute for the multiple
issues that have arisen in public comments and WG deliberations". It would
be great if you could state what those issues are so they could be
addressed specifically in the discussions here. Right now we are going
back and forth over days, and I am not sure days are really the issue at
hand here. Is there an actual problem that a registrar has deleted the
name on the expiration date and then did not offer RGP, or that the
registrar has auctioned off or sold a name at expiration date and the
registrant did not have an ability to renew? If that is the problem that
this WG sees then lets address that issue and then move on to the next
one.





Thanks


Jeff




On 11/9/10 9:50 PM, "Ron Wickersham" <rjw@xxxxxxxxxxxxxxxxx> wrote:

>i think the list of recommendations below is constructive to outline some
>items that appear from a participant's view as possible with some tweaking
>to refine issues that have been raised in the weekly deliberations.
>
>i'm not sure i understand the other proposal on the table completely, but
>it appears to be a consensus policy proposal that adds a new 5-day grace
>period just post expiration.   i can generally support that proposal as an
>additional policy but do not feel it is a substitute for the multiple
>issues that have arisen in public comments and WG deliberations.   the
>goal stated for the new 5-day grace period to be consistent between all
>registrars is definitely commendable since that is an issue that comes up
>often in our discussions, and a necessary element if education, which has
>been advanced to assist registrants, is to have any chance of success.
>
>i've included comments inline below...
>
>-ron
>
>On Tue, 9 Nov 2010, 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.>
>
>even though i was in favor of a longer period, i can support 30 days as a
>minimum.
>
>> =    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 the new 5-day grace extension is incorporated suggest that notification
>be a part of entering the 5-day grace extention, or in other words, that
>the 5-day grace period begin when the notification is sent, and a
>mandatory notification be required to be sent at the end of the 5-day
>grace extension.
>
>> =    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
>                                                            ^^^ no
>> 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]
>
>i would suggest specifying a fixed number rather than a range, and would
>substitute "within 5 days" for "within 3-5 days".   when a range is
>stated it is not clear if the cessation should not be before 3 days or
>not, and the implied range of "within 5 days" is "within 0 to 5 days".
>
>is there is problem with 0 to 5 days?
>
>> =    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.
>
>suggest that the wording be "If registrar provides any web..." since
>this only occurs when the registrant has a hosting agreement with the
>registrar/provider.   when hosting is separate, removing the DNS
>delegation
>in the root servers makes the registrant's own server or separately
>contracted server unreachable after DNS caches expire.
>
>> =    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.>
>
>may i suggest "or" be repaced with "and".
>
>> =    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.>
>
>i believe that this is the most contentious aspect, yet in my view it is
>what has been identified as the most confusing issue and deserves our
>group's best effort to advance a solution that addresses this.
>
>> =    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]
>
>i believe that this is the second most important area the WG can
>accomplish.
>this education aspect was identified early on, and was 1/3 of the mission
>of Internic, before the web was invented and ICANN existed.   it fits well
>within the function and mission of ICANN and by including education it
>helps
>focus deliberation of policies so that they can be explained with
>reasonable
>educational materials to inform those affected.
>
>> =    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.
>
>this is a very important aspect and i've heard no disagreement within the
>WG's deliberations to suggest otherwise.
>
>> Registrar Exceptions
>
>---snip---
>
>no need now for comments on the items below, since some of them are in
>more tentative form and some are dependent on reaching consensus above.
>
>-ron


Please NOTE: This electronic message, including any attachments, may include 
privileged, confidential and/or inside information owned by Demand Media, Inc. 
Any distribution or use of this communication by anyone other than the intended 
recipient(s) is strictly prohibited and may be unlawful.  If you are not the 
intended recipient, please notify the sender by replying to this message and 
then delete it from your system. Thank you.




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

Privacy Policy | Terms of Service | Cookies Policy