Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
Jody Kolker <jkolker@godaddy.com> Thu, 08 January 2015 21:51 UTC
Return-Path: <jkolker@godaddy.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 98D641A005D
for <eppext@ietfa.amsl.com>; Thu, 8 Jan 2015 13:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6,
J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, 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 LNR1D4cVEGmj for <eppext@ietfa.amsl.com>;
Thu, 8 Jan 2015 13:51:06 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com
(mail-bn1on0722.outbound.protection.outlook.com
[IPv6:2a01:111:f400:fc10::722])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 92AD51A01A9
for <eppext@ietf.org>; Thu, 8 Jan 2015 13:51:05 -0800 (PST)
Received: from BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) by
BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) with Microsoft SMTP
Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 21:50:41 +0000
Received: from BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) by
BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) with mapi id
15.01.0049.002; Thu, 8 Jan 2015 21:50:41 +0000
From: Jody Kolker <jkolker@godaddy.com>
To: "Gould, James" <JGould@verisign.com>, Francisco Obispo
<fobispo@uniregistry.com>
Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims
Service" post the Claims Phase
Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy2fq2AgAAe/ICAAAk3AIAABGEAgAATFuA=
Date: Thu, 8 Jan 2015 21:50:39 +0000
Message-ID: <BLUPR02MB034B2D11DA287B2DB2A4B59BF470@BLUPR02MB034.namprd02.prod.outlook.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>
In-Reply-To: <CF36E711-27BD-47A6-938E-B9B1804DFD0E@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [64.202.160.233]
authentication-results: spf=none (sender IP is )
smtp.mailfrom=jkolker@godaddy.com;
x-dmarcaction: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR02MB034;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB034;
x-forefront-prvs: 0450A714CB
x-forefront-antispam-report: SFV:NSPM;
SFS:(10019020)(189002)(31014004)(164054003)(377454003)(199003)(38284003)(24454002)(19580405001)(19580395003)(19300405004)(101416001)(31966008)(74316001)(20776003)(92566001)(230783001)(16236675004)(17760045003)(99936001)(54606007)(76176999)(50986999)(66066001)(54356999)(4396001)(93886004)(64706001)(97736003)(19609705001)(54206007)(87936001)(2656002)(19617315012)(21056001)(122556002)(62966003)(107046002)(33656002)(16601075003)(105586002)(77156002)(19625215002)(40100003)(99286002)(106356001)(68736005)(106116001)(120916001)(86362001)(2900100001)(99396003)(46102003)(76576001)(18206015028)(2950100001)(15975445007)(102836002);
DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB034;
H:BLUPR02MB034.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv;
PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: godaddy.com does not designate
permitted sender hosts)
Content-Type: multipart/related;
boundary="_004_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_";
type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 21:50:39.9740 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB034
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/WDi7BGOsf4kb-Y0dYLgWM5dJ2bA>
Cc: "Tran, Trung" <Trung.Tran@neustar.biz>, "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: Thu, 08 Jan 2015 21:51:14 -0000
>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; 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
[cid:image001.png@01D02B47.ACAB1530]
James Gould
Distinguished Engineer
jgould@Verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>
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