[gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names

Tue Jun 10 21:19:49 UTC 2014

Hi all,

We have been thinking a great deal about this and cannot come to any other
conclusion is that this will be a major pain with little to no benefit to
anyone involved. I like the idea of addressing this at a policy level to
see if this can be removed or retracted based on information and evidence
we have to date. How many claims notices have been served by the TMCH, how
many registrations did not go through because the registrant did not agree
to the Claims Notification. how many URS's have been sent?  I believe that
ICANN made this mandatory in the RPM "negotiations" and hopefully they can
reverse this the same way they mandated it.

Now that we are stuck with this , I think we still need to work towards a
solution and think this is going to be driven by Registrars and how their
solutions are setup. Even if a Registry decides to run eternal claims , if
the registrar has their system set for .EXAMPLE TLD to only run claims for
90 days , it will be a bad user experience as the registration will fail,
if the claims acknowledgment is not submitted. On the other side , if the
Registrar has eternal claims running , then it will require all SLD's on
the claims list to go through the TMCH, regardless if it is past 90 days.
This is not a great option either , as it would add a tremendous workload
to both Registries and Registrars and I do not see Registrars keeping this
eternal claims on

I think a possible solution for both sides is to have domain level claims
checks. When a registrant searches for a domains at their favorite
registrar , the registrar would send a claims check to the Registry. If the
Registry has been in GA for over 90 days and the domain name was available
the whole time (not on reserve) then it would return that there is no
claims on this domain , even if it is actually in the TMCH. If it was just
taken off reserve and is less than 90 days than it would come back with yes
for Claims and the registrar would need to pull the claims notice and
present it to the registrant.

While this is still not ideal , it is the least burdensome method to
registries and registrars and will cause the least amount of confusion for
registrants

Would love to hear any thoughts on this or any other proposals as we get
closer to London meeting

Jeff

On Thu, May 29, 2014 at 1:38 PM, Gould, James <JGould at verisign.com> wrote:

>   I agree with both Jeff and Elaine that having a discussion at the ICANN
> meeting along with further discussion on the list ahead of the meeting
> would be very useful.  Can someone from ICANN respond to the request for
> adding this to the ICANN meeting agenda?
>
>  Thanks,
>
>   --
>
>
>
> JG
>
>
>
>
>
> James Gould
>
> Principal Software Engineer
>
> jgould at verisign.com
>
>
>
> 703-948-3271 (Office)
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
> VerisignInc.com
>
>   From: Jeffrey Eckhaus <jeff at rightside.co>
> Date: Tuesday, May 27, 2014 at 4:13 PM
> To: Elaine Pruis <elaine at donuts.co>
>
> Cc: "tmch-tech at icann.org" <tmch-tech at icann.org>, "gtld-tech at icann.org" <
> gtld-tech at icann.org>
> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for
> Release or Allocation of Reserved Domain Names
>
>   Great idea Elaine. We are still thinking about this since we are
> looking at it from the Registry and Registrar side and the few weeks
> leading up to London would be helpful .
>
>  I think we should continue discussion on the list leading up to the
> event , try to get to a plan right before event and maybe try to finalize
> something with ICANN in London
>
>  Jeff
>
>
>
>
>  On May 27, 2014, at 11:17 AM, Elaine Pruis <elaine at donuts.co> wrote:
>
>  There are a few more options we can consider for Claims.  Considering
> there is some dissent over how to apply the RPM requirements to reserved
> names it would be wise to meet in London for further discussion.  That will
> give folks some time to come up with additional options.
> Would the ICANN person managing this list please arrange for that?
>
>
>
>        *Elaine Pruis*
>  Vice President, Operations
>  * ……………………………… *
> * …… *
> * …… *
>   elaine at donuts.co
>    +1 509-899-3161
>
> <Donuts_Logo_Signature.png>
>
>  On May 27, 2014, at 5:46 AM, Wil Tan <wil at cloudregistry.net> wrote:
>
>
> On Thu, May 22, 2014 at 6:23 AM, Gould, James <JGould at verisign.com> wrote:
>
>>
>>   I prefer option 2 for the “Allocation of the reserved names” problem.
>>  I prefer option 4 first, followed by option 3, for the “Handling the
>> claims service for reserved names that have marks in the TMCH” problem.
>>
>>
>  Running eternal claims services is clearly not a view shared by all
> registries. The middle ground -- asking registrars and registries to
> reactivate all the claims machinery for a subset of names -- presents a
> significant challenge.
>
>  As such, I concur with option 4 or 3 for handling claims for reserved
> names with marks in TMCH.
>
>  .wil
>
>
>
>
> Please NOTE: This electronic message, including any attachments, may
> include privileged, confidential and/or inside information owned by Rightside
> Group, Ltd. 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.
>
>

-- 

Please NOTE: This electronic message, including any attachments, may 
include privileged, confidential and/or inside information owned by Rightside 
Group, Ltd. 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20140610/7b96f3cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[129].png
Type: image/png
Size: 4109 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20140610/7b96f3cf/3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74129-0001.png>