Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
"Tran, Trung" <Trung.Tran@neustar.biz> Tue, 13 January 2015 03:04 UTC
Return-Path: <Trung.Tran@neustar.biz>
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 546F41A89EF
for <eppext@ietfa.amsl.com>; Mon, 12 Jan 2015 19:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level:
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334,
J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7,
SPF_PASS=-0.001] autolearn=no
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 blqWXgRApsN7 for <eppext@ietfa.amsl.com>;
Mon, 12 Jan 2015 19:04:05 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com
[67.231.157.90])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 84BA11A886C
for <eppext@ietf.org>; Mon, 12 Jan 2015 19:04:05 -0800 (PST)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1])
by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t0D30H6j016705;
Mon, 12 Jan 2015 22:04:02 -0500
Received: from stntexhc11.cis.neustar.com ([156.154.17.216])
by mx0b-0018ba01.pphosted.com with ESMTP id 1rvn4grg5a-1
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Mon, 12 Jan 2015 22:04:01 -0500
Received: from stntexmb12.cis.neustar.com ([169.254.2.192]) by
stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 12 Jan
2015 22:04:01 -0500
From: "Tran, Trung" <Trung.Tran@neustar.biz>
To: "Gould, James" <JGould@verisign.com>, Jody Kolker <jkolker@godaddy.com>
Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims
Service" post the Claims Phase
Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgA
Date: Tue, 13 Jan 2015 03:04:01 +0000
Message-ID: <D0D9F3EF.49253%trung.tran@neustar.biz>
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>
In-Reply-To: <C3F2FBCA-C800-4CC2-BD49-D36D028B5522@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [192.168.128.76]
Content-Type: multipart/mixed;
boundary="_004_D0D9F3EF49253trungtranneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7679
signatures=670600
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
kscore.is_bulkscore=8.21569173803383e-09 kscore.compositescore=0
circleOfTrustscore=0 compositescore=0.993311949948012
urlsuspect_oldscore=0.993311949948012 suspectscore=0
recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0
kscore.is_spamscore=0 recipient_to_sender_totalscore=0
recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012
spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9
adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=7.0.1-1402240000 definitions=main-1501130029
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/MIqkks4FNzJeAdWb0ILVlz6ylDc>
Cc: 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 03:04:09 -0000
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
[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<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
- [eppext] draft-ietf-eppext-launchphase Support fo… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Jody Kolker
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Tran, Trung
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Francisco Obispo
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Francisco Obispo
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Francisco Obispo
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Jody Kolker
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Tran, Trung
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Michael Holloway
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Rik Ribbers
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Michael Holloway
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Jothan Frakes
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Jothan Frakes
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Michael Holloway
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Michael Holloway
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Gould, James
- Re: [eppext] draft-ietf-eppext-launchphase Suppor… Michael Holloway