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

[Michael Holloway <[e-mail]>]

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
>
>
>
>
> *James Gould
> *Distinguished Engineer
> [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