Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

"Gould, James" <JGould@verisign.com> Tue, 13 January 2015 13:34 UTC

Return-Path: <JGould@verisign.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B191A8ADA for <eppext@ietfa.amsl.com>; Tue, 13 Jan 2015 05:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level:
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2FcCAgTSyFz for <eppext@ietfa.amsl.com>; Tue, 13 Jan 2015 05:34:29 -0800 (PST)
Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC01A8ADD for <eppext@ietf.org>; Tue, 13 Jan 2015 05:34:25 -0800 (PST)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKVLUe4Pkpob+5Orj2j1L4iov/NSKNStXj@postini.com; Tue, 13 Jan 2015 05:34:28 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0DDYNDM032619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:34:23 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 08:34:23 -0500
From: "Gould, James" <JGould@verisign.com>
To: "Tran, Trung" <Trung.Tran@neustar.biz>
Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgAEEEYA=
Date: Tue, 13 Jan 2015 13:34:22 +0000
Message-ID: <7D5A771D-7B44-4868-B996-00305D07FE77@verisign.com>
References: <D0D41AB9.46E54%trung.tran@neustar.biz> <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <B392E842-86BF-4F1E-96FC-ED2EA7E19F6D@verisign.com> <D5A4D4D5-C37A-442D-981B-3381483A292B@uniregistry.com> <CF36E711-27BD-47A6-938E-B9B1804DFD0E@verisign.com> <BLUPR02MB034B2D11DA287B2DB2A4B59BF470@BLUPR02MB034.namprd02.prod.outlook.com> <C3F2FBCA-C800-4CC2-BD49-D36D028B5522@verisign.com> <D0D9F3EF.49253%trung.tran@neustar.biz>
In-Reply-To: <D0D9F3EF.49253%trung.tran@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_7D5A771D7B444868B99600305D07FE77verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ggW_gAcNAEWWYeYi1VDhY3Q17Wg>
Cc: Jody Kolker <jkolker@godaddy.com>, Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 13:34:34 -0000

Trung,

Got it, so it’s really for resale or recreate use cases post the initial create.  I believe that supporting the claims check with “claims” as the phase post the “claims” phase would address this use case, since all domains that have trademarks in the “claims” phase will return exists=“1” as desired.  The question is whether the draft should provide text to cover this use case and I’m assuming that this behavior is a MAY, meaning servers MAY support this behavior.  Do the registrars on the list see a need for this behavior and feel that using the claims check with “claims” as the phase post the “claims” phase is acceptable and how strong of a need is this (MAY or SHOULD).

Thanks,


—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Jan 12, 2015, at 10:04 PM, Tran, Trung <Trung.Tran@neustar.biz<mailto:Trung.Tran@neustar.biz>> wrote:

This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com<mailto:JGould@verisign.com>>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com<mailto:jkolker@godaddy.com>>
Cc: Francisco Obispo <fobispo@uniregistry.com<mailto:fobispo@uniregistry.com>>, "eppext@ietf.org<mailto:eppext@ietf.org>" <eppext@ietf.org<mailto:eppext@ietf.org>>, "Tran, Trung" <trung.tran@neustar.biz<mailto:trung.tran@neustar.biz>>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?


  1.  During claims phase with a claims check command
     *   If domain has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  2.  During post claims phase with a claims check command
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  3.  During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
     *   If domains has matching trademark
        *   return exists=true
     *   else
        *   return exists=false


  1.  During claims phase with a create command
     *   If domain has matching trademark
        *   claims notice is required
     *   else
        *   claims notice is NOT required
  2.  During post claims phase with a create command
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark return
        *   claims notice is required
     *   else
        *   claims notice is NOT required

Thoughts?

—

JG


<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://9/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__VerisignInc.com&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=szebc6wpGwppUlrnEyVYLycmIErTch1EX1wsyS31LMM&m=a_JzT0U7GbcwWgKca9Yn1v1l7xxuwH3lVAP_eW0V09I&s=yC8iNOnjjvMIbW-gZsn7rA62FX8o8ZmCI14bhrQZ7TI&e=>

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com<mailto:jkolker@godaddy.com>> wrote:

>From Francisco:

Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.

With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?

This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.


  1.  During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
     *   If domain has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  2.  During post claims phase with a claims check command with a sub-phase of “extended”
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark
        *   return exists=true
     *   else
        *   return exists=false



  1.  During claims phase with a create command or post claims phase without a sub-phase of “extended”
     *   If domain has matching trademark
        *   claims notice is required
     *   else
        *   claims notice is NOT required
  2.  During post claims phase with a create command with a sub-phase of “extended”
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark return
        *   claims notice is required
     *   else
        *   claims notice is NOT required

This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com<mailto:cbeadnall@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

From: Gould, James [mailto:JGould@verisign.com]
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org<mailto:eppext@ietf.org>; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Francisco,

I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.

Thanks,

—


JG

<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://82/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__verisigninc.com_&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=szebc6wpGwppUlrnEyVYLycmIErTch1EX1wsyS31LMM&m=a_JzT0U7GbcwWgKca9Yn1v1l7xxuwH3lVAP_eW0V09I&s=3GJIlJDRYzqHAwoiiYIQ35ek_aOxjUrEB5OfZMjak-8&e=>

On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com<mailto:fobispo@uniregistry.com>> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to
pass the claims notice for domain names outside of the claims phase.


Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else.

We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.

Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.


On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com<mailto:JGould@verisign.com>> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263

<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>