Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
Michael Holloway <michael.holloway@comlaude.com> Tue, 13 January 2015 15:09 UTC
Return-Path: <michael.holloway@comlaude.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 315CB1A8F3F
for <eppext@ietfa.amsl.com>; Tue, 13 Jan 2015 07:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.281
X-Spam-Level:
X-Spam-Status: No, score=0.281 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001,
J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001,
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 tn672wH19N2K for <eppext@ietfa.amsl.com>;
Tue, 13 Jan 2015 07:08:50 -0800 (PST)
Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com
[108.166.43.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 858391A8AE6
for <eppext@ietf.org>; Tue, 13 Jan 2015 07:08:21 -0800 (PST)
Received: from smtp23.relay.ord1c.emailsrvr.com (localhost.localdomain
[127.0.0.1])
by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DE5692805B6;
Tue, 13 Jan 2015 10:08:20 -0500 (EST)
X-SMTPDoctor-Processed: csmtpprox beta
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D7B62280601;
Tue, 13 Jan 2015 10:08:20 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp23.relay.ord1c.emailsrvr.com (Authenticated sender:
m4bh-AT-comlaude.com) with ESMTPSA id 479292805B6;
Tue, 13 Jan 2015 10:08:19 -0500 (EST)
X-Sender-Id: m4bh@comlaude.com
Received: from [192.168.1.10] (p578E66C0.dip0.t-ipconnect.de [87.142.102.192])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA)
by 0.0.0.0:465 (trex/5.4.2); Tue, 13 Jan 2015 15:08:20 GMT
Message-ID: <54B534E2.8050001@comlaude.com>
Date: Tue, 13 Jan 2015 16:08:18 +0100
From: Michael Holloway <michael.holloway@comlaude.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Gould, James" <JGould@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> <54B4D4F1.6070405@comlaude.com>
<EF1D8AA2-F340-4782-BE72-BB271203C1D1@verisign.com>
In-Reply-To: <EF1D8AA2-F340-4782-BE72-BB271203C1D1@verisign.com>
Content-Type: multipart/alternative;
boundary="------------070202070009010008090902"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/dlDbY1XFY9_4TqiIRgyXoTL07pE>
Cc: "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 15:09:01 -0000
Hi
Re TMDB: I was thinking specifically of the post claims phase since at
this point the CNIS (label+tld) itself it no longer required for
registrations. The post claims lookup seems to be aimed at determining,
for information purposes only (without "acking" in the create), whether
or not there is a trademark registered against the term (i.e. label
only) therefore there is no reason to check claims via TLD. This is a
little OT anyway (my fault sorry), but hopefully you see where I am
coming from.
Back to LaunchPhase: my concern with simply using the "claims" phase is
that it can cause ambiguity, take the following four phase statuses, and
compare with the logic below (to which I commented in _underlined red_)
1) A registry _must_ operate a 90 days claims phase
2) A registry _must_ operate 90 days extended claims period on domains
that are released at a later date (collisions etc, and I don't know what
may be coming up in the future)
3) A registry _may_ operate a continued claims phase past the 90 domains
for all domains. [create with claims form]
4) [new]: A registry _may_ operate a post claims (matching trademark
past the claims phase use case) [create without claims]
If the client checks a domain for claims and gets result claims=true,
then how does it know which of the above rules matched? In the case of
(4) the claims lookup returns true even though the domain is no longer
in (1) or (2) [and the registry has opted not to do (3)], so using the
claims create form would be incorrect at this point despite receiving
claims=true. This is why I suggest a different sub_phase should be used,
OR a different flag added (more complex of course) to differentiate.
I hope this makes sense; and apologies if I am missing something
fundamental!
Cheers,
Michael
1. During claims phase with a claims check command
1. If domain has matching trademark
1. return exists=true
2. else
1. return exists=false
2. During post claims phase with a claims check command
1. If domain was released post claims phase start and is within 90
days of release and has matching trademark
1. return exists=true
2. else
1. 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)*
1. *If domains has matching trademark *
1. *return exists=true *_## The claims exists but it is NOT
required on domain_create_
2. *else*
1. *return exists=false*
1. During claims phase with a create command
1. If domain has matching trademark
1. claims notice is required
2. else
1. claims notice is NOT required
2. During post claims phase with a create command
1. If domain was released post claims phase start and is within 90
days of release and has matching trademark return ## How does
the client know if 90 days has passed (extended / post claims)
or not without external source?
1. claims notice is required
2. else
1. claims notice is NOT required
*
Michael Holloway
Senior Systems Administrator**| Com Laude*
E: michael.holloway@comlaude.com <mailto:michael.holloway@comlaude.com>
On 01/13/2015 02:44 PM, Gould, James wrote:
> Michael,
>
> The split out of the responsibility of the registries and the CNIS /
> TMDB was worked out a couple of years ago, where there was a desire to
> not make the CNIS the critical path for the majority of the
> registrations. The agreement was for the registries to provide the
> claims check service and enforce the claims notice on create based on
> a feed of trademark labels from the TMDB to the registries.
>
> The proposal is to support the claims service post the “claims” phase
> by passing the active phase to the server and the server will return
> whether or not the claims notice is required based on a combination of
> a matching trademark and whether the domain name already went through
> 90 days of the claims service. From a client perspective it means
> utilizing the claims check in a similar fashion during and post the
> claims phase. The use case brought up by Trung was more of an
> exception to the rule, in the client wanting to know whether there is
> a matching trademark for a domain name independent of the requirement
> for passing the claims notice. In that case, the proposal is to pass
> “claims” as the phase independent of the active phase to get a true or
> false answer to whether a trademark matches the domain name.
>
> Do the proposals work for you?
>
> Thanks,
>
> —
>
>
> JG
>
>
>
>
> *James Gould
> *Distinguished Engineer
> jgould@Verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com <http://VerisignInc.com>
>
> On Jan 13, 2015, at 3:18 AM, Michael Holloway
> <michael.holloway@comlaude.com <mailto:michael.holloway@comlaude.com>>
> wrote:
>
>> Hi all
>>
>> Just a thought; would it not be more appropriate to facilitate this
>> on the TMDB by adding a lookup based on label. This could return a
>> simple true/false value, or all the info returned on a CNIS lookup
>> exception notice_id etc.
>>
>> The problem with having and post claims service on the EPP server
>> without changing the phase name is that the EPP client then has to
>> decide when /not/ to submit claims data in a domain_create if the
>> domain has a claim. As it is, various registries are extending the
>> claims periods past 90 days, so its contradictory to have extended
>> claims and post claims defined the same way in the query but without
>> a defined (or facilitated) way to differentiate the requirement for a
>> domain_create.
>>
>> I would be more comfortable with defining a specific sub_phase for
>> the purpose, or even better skipping the middle man and going
>> straight to the TMDB.
>>
>> Cheers,
>> Michael
>>
>> *Michael Holloway
>> Senior Systems Administrator**| Com Laude*
>> E: michael.holloway@comlaude.com <mailto:michael.holloway@comlaude.com>
>>
>>
>> On 01/13/2015 04:04 AM, Tran, Trung 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
>>> 1. If domain has matching trademark
>>> 1. return exists=true
>>> 2. else
>>> 1. return exists=false
>>> 2. During post claims phase with a claims check command
>>> 1. If domain was released post claims phase start and is
>>> within 90 days of release and has matching trademark
>>> 1. return exists=true
>>> 2. else
>>> 1. 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)*
>>> 1. *If domains has matching trademark *
>>> 1. *return exists=true*
>>> 2. *else*
>>> 1. *return exists=false*
>>>
>>>
>>> 1. During claims phase with a create command
>>> 1. If domain has matching trademark
>>> 1. claims notice is required
>>> 2. else
>>> 1. claims notice is NOT required
>>> 2. During post claims phase with a create command
>>> 1. If domain was released post claims phase start and is
>>> within 90 days of release and has matching trademark return
>>> 1. claims notice is required
>>> 2. else
>>> 1. claims notice is NOT required
>>>
>>>
>>> Thoughts?
>>>
>>> —
>>>
>>> JG
>>>
>>>
>>>
>>>
>>> *James Gould
>>> *Distinguished Engineer
>>> jgould@Verisign.com <x-msg://11/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”
>>>> 1. If domain has matching trademark
>>>> 1. return exists=true
>>>> 2. else
>>>> 1. return exists=false
>>>> 2. During post claims phase with a claims check command with a
>>>> sub-phase of “extended”
>>>> 1. If domain was released post claims phase start and is
>>>> within 90 days of release and has matching trademark
>>>> 1. return exists=true
>>>> 2. else
>>>> 1. return exists=false
>>>>
>>>> 1. During claims phase with a create command or post claims
>>>> phase without a sub-phase of “extended”
>>>> 1. If domain has matching trademark
>>>> 1. claims notice is required
>>>> 2. else
>>>> 1. claims notice is NOT required
>>>> 2. During post claims phase with a create command with a
>>>> sub-phase of “extended”
>>>> 1. If domain was released post claims phase start and is
>>>> within 90 days of release and has matching trademark
>>>> return
>>>> 1. claims notice is required
>>>> 2. else
>>>> 1. 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 mailing list
>>> EppExt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eppext
>> _______________________________________________
>> EppExt mailing list
>> EppExt@ietf.org <mailto:EppExt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/eppext
>
- [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