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

[Michael Holloway <[e-mail]>]

Okay agreed, all good.

Sorry I got my lanes crossed on the Trademark Claims Check re type 
attribute vs phase name...

*Michael Holloway
Senior Systems Administrator**| Com Laude*
E: [e-mail] <mailto:[e-mail]>
D: [phone]


On 01/22/2015 02:46 PM, Gould, James wrote:
> Michael,
>
> We had the discussion a while back on the provreg mailing list ( 
> http://www.ietf.org/mail-archive/web/provreg/current/msg07286.html ) 
> about support for overlapping phases, which resulted in adding the 
> text in the 09 draft to handle the overlap of the “claims” and 
> “landrush” phases.  I view a phase as a TLD level attribute as opposed 
> to a domain level attribute that defines the interface expected by the 
> server.  Supporting a list of phases adds undue complexity 
> in draft-ietf-eppext-launchphase.
>
> For the Trademark Check Form, the <launch:phase> element is not passed 
> in the command or returned in the response since it’s really not 
> applicable.  The <launch:phase> element is being set to optional 
> (minOccurs=“0”) for the check command (checkType) and response 
> (chkDataType), but is defined as required in the text for the Claims 
> Check Form and Availability Check Form.  Let me know whether this 
> makes sense.
>
> Thanks,
>
> —
>
>
> JG
>
>
>
>
> *James Gould
> *Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com <http://VerisignInc.com>
>
> On Jan 22, 2015, at 7:07 AM, Michael Holloway 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>> Hi James
>>
>> Yes I think that wording is fine, but [at the risk of pointlessly 
>> complicating the issue again], there are possibly multiple concurrent 
>> phases. In some instances, a domain might be valid in more than one 
>> (e.g. a regional TLD where phases depend on the registrants location 
>> or type), and in some cases such as collisions the domain might only 
>> be available in one of the active phases (e.g. collisions). Is it 
>> worth loosing to an "an" instead of "the" phase? Veto if you think 
>> its pointless.
>>
>> <launch:phase>   Contains the value of an active launch phase of the 
>> server supporting claims.  The server SHOULD validate the value 
>> against the active server launch phase supporting claims.
>>
>> Also, TM check form should be a SHOULD
>> 3.1.3 Trademark Check Form
>> ...
>> <launch:phase>   The launch phase that SHOULD be "trademark"
>>
>>
>> Cheers,
>> Michael
>>
>> *Michael Holloway
>> Senior Systems Administrator**| Com Laude*
>> E: [e-mail] <mailto:[e-mail]>
>>
>>
>> On 01/21/2015 05:30 PM, Gould, James wrote:
>>> Michael,
>>>
>>> How about just using a more generic description of the 
>>> <launch:phase> element in both the Claims Check Form of section 
>>> 3.1.1 and the Claims Create Form of section 3.3.2, since both forms 
>>> can be executed outside of the “claims” phase?  Something like the 
>>> description from the General Create Form of section 3.3.3:
>>>
>>>               <launch:phase>   Contains the value of the active 
>>> launch phase of the server.  The server SHOULD validate the value 
>>> against the active server launch phase.
>>>
>>>
>>> —
>>>
>>> JG
>>>
>>>
>>> <Mail Attachment.png>
>>>
>>> *James Gould
>>> *Distinguished Engineer
>>> [e-mail] <x-msg://87/[e-mail]>
>>>
>>> 703-948-3271
>>> 12061 Bluemont Way
>>> Reston, VA 20190
>>>
>>> VerisignInc.com <http://verisigninc.com/>
>>>
>>> On Jan 21, 2015, at 8:41 AM, Michael Holloway 
>>> <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> Thanks James
>>>>
>>>> From a registrar perspective I would say this solves the issue 
>>>> without the risk of breaking working clients. I would be interested 
>>>> to hear the opinion of anyone [else] representing registries here 
>>>> whether they would support the extra type attribute since its 
>>>> essentially optional extra, or whether they would prefer to support 
>>>> using he existing schema.
>>>>
>>>> I think in the case of the latter it would suggest using Claims 
>>>> check on phases outside of "claims" (e.g. "open"),  and then some 
>>>> guidance would need to be offered (in the draft) to define exactly 
>>>> what the "open" phase is; .I.E is it the period _after_ claims, or 
>>>> is the 'open registration' (aka general availability) period 
>>>> _during_ the claims period; and therefore when to and when not to 
>>>> use the "open" phase. Some minor wording changes would be required 
>>>> in 3.1.1 Claims check form to change it from `/The launch phase 
>>>> that SHOULD be "claims"`/ , to "MAY", perhaps with a bit more info.
>>>>
>>>> In light of the above I think it would be far simpler to go with 
>>>> the Trademark check form, so hopefully we can agree with that! That 
>>>> would be my vote anyway!
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>>
>>>> *Michael Holloway
>>>> Senior Systems Administrator**| Com Laude*
>>>> E: [e-mail] <mailto:[e-mail]>
>>>>
>>>> On 01/20/2015 02:58 PM, Gould, James wrote:
>>>>> All,
>>>>>
>>>>> I had a private thread with some about the proposal of referencing 
>>>>> the past “claims” phase in the claims check command to support 
>>>>> Trung’s request.  The issue is that some clients are hard coding 
>>>>> “claims” as the phase in the claims check command and currently 
>>>>> there is little to no support for the claims check command outside 
>>>>> of the “claims” phase, so clients may inadvertently go through the 
>>>>> claims process when it is not required or even potentially 
>>>>> rejected on create.  I see the concern with adding a new feature 
>>>>> that may inadvertently cause interface issues.  Although I am not 
>>>>> crazy about making an XML schema change, we may be able to tweak 
>>>>> things to support both the the claims check outside of the 
>>>>> “claims” phase and also support Trung’s request to determine 
>>>>> whether or not a trademark matches a name independent of the 
>>>>> requirement for a claims notice for other use cases like the 
>>>>> resale of domain names.
>>>>>
>>>>> We already support a “type" attribute in the <launch:check> 
>>>>> element, section 3.1, to define the check form of the command, 
>>>>> which currently support “claims” and “avail” for the Claims Check 
>>>>> Form and the Availability Check Form, respectively.  The default 
>>>>> form is the Claims Check Form, which is updated to return 
>>>>> “exists=1” if there is a matching trademark and a claims notice is 
>>>>> required on create, per the proposed check changes.  We could add 
>>>>> a Trademark Check Form (e.g. add section 3.1.3) that is indicated 
>>>>> by setting the “type” attribute to “trademark”.  The interface for 
>>>>> the Trademark Check Form is consistent with the Claims Check Form, 
>>>>> except the <launch:phase> element is not applicable, so therefore 
>>>>> in the schema we would make the <launch:phase> element optional, 
>>>>> and the server would only match the domain to the matching set of 
>>>>> trademarks to return the same response as with the Claims Check 
>>>>> Form.  The <launch:phase> element would still be required for the 
>>>>> Claims Check Form and the Availability Check Form based on the 
>>>>> draft text.  As stated in section 3.1, the forms supported by the 
>>>>> server is determined by server policy, so the Trademark Check Form 
>>>>> would is an option but is not required.  The check command using 
>>>>> the Trademark Check Form would look like:
>>>>>
>>>>>     C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>>>>>     C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
>>>>>     C:  <command>
>>>>>     C:   <check>
>>>>>     C:    <domain:check
>>>>>     C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>>>>>     C:      <domain:name>example1.tld</domain:name>
>>>>>     C:      <domain:name>example2.tld</domain:name>
>>>>>     C:    </domain:check>
>>>>>     C:   </check>
>>>>>     C:   <extension>
>>>>>     C:    <launch:check
>>>>>     C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
>>>>>     C:     type=“trademark"/>
>>>>>     C:   </extension>
>>>>>     C:   <clTRID>ABC-12345</clTRID>
>>>>>     C:  </command>
>>>>>     C:</epp>
>>>>>
>>>>>
>>>>> To support this, section 3.1.3 Trademark Check Form would need to 
>>>>> be added along with some text changes on the “trademark” value for 
>>>>> the “type” attribute in section 3.1, <enumeration 
>>>>> value=“trademark”/> would need to be added to the checkFormType in 
>>>>> the schema, and minOccurs=“0” would need to be added to the 
>>>>> “phase” element of checkType in the schema.
>>>>>
>>>>> Let me know your thoughts on this option.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> —
>>>>>
>>>>> JG
>>>>>
>>>>>
>>>>> <Mail Attachment.png>
>>>>>
>>>>> *James Gould
>>>>> *Distinguished Engineer
>>>>> [e-mail] <x-msg://82/[e-mail]>
>>>>>
>>>>> 703-948-3271
>>>>> 12061 Bluemont Way
>>>>> Reston, VA 20190
>>>>>
>>>>> VerisignInc.com <http://verisigninc.com/>
>>>>>
>>>>> On Jan 13, 2015, at 10:40 AM, Gould, James <[e-mail] 
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>> Michael,
>>>>>>
>>>>>> I provide feedback inline below.
>>>>>>
>>>>>> —
>>>>>>
>>>>>> JG
>>>>>>
>>>>>>
>>>>>> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
>>>>>>
>>>>>> *James Gould
>>>>>> *Distinguished Engineer
>>>>>> [e-mail] <x-msg://57/[e-mail]>
>>>>>>
>>>>>> 703-948-3271
>>>>>> 12061 Bluemont Way
>>>>>> Reston, VA 20190
>>>>>>
>>>>>> VerisignInc.com <http://verisigninc.com/>
>>>>>>
>>>>>> On Jan 13, 2015, at 10:08 AM, Michael Holloway 
>>>>>> <[e-mail] 
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> The use case for the claims check post the claims phase is used 
>>>>>> to address the release of domain names that did not go through 90 
>>>>>> days of claims, which I believe is a modified version of your #2 
>>>>>> below.
>>>>>>
>>>>>> Let’s take the three basic phases defined 
>>>>>> in draft-ietf-eppext-launchphase as an example with sunrise, 
>>>>>> claims, and open.  We can pretty much remove the sunrise phase 
>>>>>> from the example for now, so let’s focus on the claims and open 
>>>>>> phases.  Assuming that claims.tld is available through sunrise 
>>>>>> and the claims phase, so if a claims check is done with “open” as 
>>>>>> the phase, the response would be exists=“0”, since there is no 
>>>>>> requirement to provide the claims notice on create.  If 
>>>>>> reserved.tld was released during the “open” phase, then a claims 
>>>>>> check on reserved.tld, with “open” as the phase, the response 
>>>>>> would be exists=“1”, since a claims notice is required on create. 
>>>>>>  Based on Trung’s use case, a client may want to know whether or 
>>>>>> not there is a trademark on the domain name independent of when 
>>>>>> the domain name is released, so the client can send a claims 
>>>>>> check with the phase as “claims” to get that answer.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> Based on the updated text, the client will only receive a claims 
>>>>>> check response with exists=“1” if “create with claims form” is 
>>>>>> required.  The updated text does not support #4, since the only 
>>>>>> time that “exists=0” is if a claims notice is required.  This way 
>>>>>> a client can continue to use the claims check without any extra 
>>>>>> logic of passing special attributes or sub-phases to get the 
>>>>>> answer that is needed, which is whether a claims notice is 
>>>>>> required on create.  Trung use case is an exception to the rule, 
>>>>>> where a client wants to know whether there is a matching 
>>>>>> trademark for the domain name independent of whether a claims 
>>>>>> notice is required on create, so passing “claims” as the phase 
>>>>>> past the “claims” phase may support that.
>>>>>>
>>>>>> Let me know whether or not this helps.
>>>>>>
>>>>>>
>>>>>>> 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: [e-mail] 
>>>>>>> <mailto:[e-mail]>
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> <Mail Attachment.png>
>>>>>>>>
>>>>>>>> *James Gould
>>>>>>>> *Distinguished Engineer
>>>>>>>> [e-mail] <x-msg://15/[e-mail]>
>>>>>>>>
>>>>>>>> 703-948-3271
>>>>>>>> 12061 Bluemont Way
>>>>>>>> Reston, VA 20190
>>>>>>>>
>>>>>>>> VerisignInc.com <http://verisigninc.com/>
>>>>>>>>
>>>>>>>> On Jan 13, 2015, at 3:18 AM, Michael Holloway 
>>>>>>>> <[e-mail] 
>>>>>>>> <mailto:[e-mail]>> 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: [e-mail] 
>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>> Date: Friday, January 9, 2015 at 11:27 AM
>>>>>>>>>> To: Jody Kolker <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>> Cc: Francisco Obispo <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>>, "[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>" <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>>, "Tran, Trung" 
>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>> 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
>>>>>>>>>>     [e-mail] <x-msg://11/[e-mail]>
>>>>>>>>>>
>>>>>>>>>>     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
>>>>>>>>>>     <[e-mail] <mailto:[e-mail]>> 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 ([e-mail]
>>>>>>>>>>>     <mailto:[e-mail]>) 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:[e-mail]]
>>>>>>>>>>>     *Sent:*Thursday, January 08, 2015 12:24 PM
>>>>>>>>>>>     *To:*Francisco Obispo
>>>>>>>>>>>     *Cc:*Jody Kolker;[e-mail]
>>>>>>>>>>>     <mailto:[e-mail]>; 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
>>>>>>>>>>>     [e-mail] <x-msg://82/[e-mail]>
>>>>>>>>>>>
>>>>>>>>>>>     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
>>>>>>>>>>>     <[e-mail]
>>>>>>>>>>>     <mailto:[e-mail]>> 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
>>>>>>>>>>>             <[e-mail]
>>>>>>>>>>>             <mailto:[e-mail]>> 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. [phone]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> EppExt mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/eppext
>>>>>>>>> _______________________________________________
>>>>>>>>> EppExt mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/eppext
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> EppExt mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/eppext
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> EppExt mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/eppext
>>>>
>>>>
>>>> _______________________________________________
>>>> EppExt mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/eppext
>>>
>