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

From: "Tran, Trung" <[email-masked]>
Date: Thu, 8 Jan 2015 17:11:49 +0000

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?

Trung
From: Jody Kolker <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 8, 2015 at 11:15 AM
To: "Gould, James" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Thanks Jim.

>From a registrar perspective, this will solve the issue of domains that are released after the initial 90 day claims period but still require a claim to be presented to the customer.

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]<mailto:[email-masked]>) 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: EppExt [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Monday, January 05, 2015 3:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

All,

There was an issue raised privately in supporting claims as a Claims Service post the Claims Phase.   According to section 2.4.3 of the RPM Requirements, “...releases for Allocation or registration such reserved domain name at any time following the start date of the Claims Period, such domain MUST be subject to the Claims Services (as described in Section 3) for a period of ninety (90) calendar days following the date Registry Operator releases such domain name for registration…”.  This means that support for the Claims Check Form needs to be revised to indicate whether or not the Claims Create Form is needed for the domain name and the use of the Claims Create Form should be supported in phases other than “claims”.  There are no XML schema changes required to support this.  Please review and provide feedback to the proposed revised language in the draft below to include in the next version of the draft that will also include the Implementation Status section discussed at the IETF-91 EPPEXT meeting.

Change 3.1.1 "Claims Check Form" as follows:

   The Claims Check Form defines a new command called the Claims Check

   Command that is used to determine whether or not there are any

   matching trademarks, in the specified launch phase, for each domain

   name passed in the command, that requires the use of the "Claims Create Form"

   on a Domain Create Command.

   Instead of returning whether the domain name is available, the Claims

   Check Command will return whether or not at least one matching

   trademark exists for the domain name, that requires the use of the

   "Claims Create Form" on a Domain Create Command.

   <launch:name>  Contains the fully qualified name of the queried

           domain name.  This element MUST contain an "exists" attribute

           whose value indicates if a matching trademark exists for the

           domain name that requires the use of the "Claims Create Form" on a Domain Create Command.

           A value of "1" (or "true") means that a

           matching trademark does exist and that the "Claims Create Form" is required on

           a Domain Create Command.  A

           value of "0" (or "false") means that a matching trademark

           does not exist or that the "Claims Create Form" is NOT required on a Domain Create Command.

Change 3.3.2 "Claims Create Form" as follows:

<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.

Based on the above revised language the following may be done:

  1.  During claims phase with a claims check command

     *   If domain has matching trademark

        *   return exists=true

     *   else

        *   return exists=false

  1.  During post claims phase with a claims check command

     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark

        *   return exists=true

     *   else

        *   return exists=false

  1.  During claims phase with a create command

     *   If domain has matching trademark

        *   claims notice is required

     *   else

        *   claims notice is NOT required

  1.  During post claims phase with a create command

     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark return

        *   claims notice is required

     *   else

        *   claims notice is NOT required

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__VerisignInc.com&d=AwMFAg&c=MOptNlVtIETeDALC_lULrw&r=szebc6wpGwppUlrnEyVYLycmIErTch1EX1wsyS31LMM&m=ZToEUQPm3bS0m0H70sVsrqVtbL50FxcWcNdrQ7XC9bg&s=__oleqH0HPAGnoyLyheOlTjwDph4zKQKEkrxnoI8JH4&e=>

“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 8 Jan 2015 09:41:43 -0800

Francisco Obispo
CTO - Registry Operations

2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263

> On Jan 8, 2015, at 9:11 AM, Tran, Trung <[email-masked]> wrote:
>

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 8 Jan 2015 09:44:23 -0800

Hi James,

The only component that is still open is what to call that extended claims phase. Perhaps it’s useful to suggest a name for that special phase (extended-claims?) to avoid having 100 different phase names.

I believe the clarification is very useful.

Thanks

Francisco Obispo

> From: Jody Kolker <[email-masked]>
> To: "Gould, James" <[email-masked]>, "[email-masked]" <[email-masked]>
>> 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]) with any feedback.
>>  
>> To: [email-masked]
>> 	• During claims phase with a claims check command 
>> 		• If domain has matching trademark  
>> 			• return exists=true 
>> 		• else  
>> 			• return exists=false
>> 	• During post claims phase with a claims check command 
>> 		• If domain was released post claims phase start and is within 90 days of release and has matching trademark
>> 			• return exists=true 
>> 		• else  
>> 			• return exists=false 
>>  
>> 	• During claims phase with a create command  
>> 		• If domain has matching trademark  
>> 			• claims notice is required 
>> 		• else  
>> 			• claims notice is NOT required
>> 	• During post claims phase with a create command  
>> 		• If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
>> 			• claims notice is required 
>> 		• else  
>> 			• claims notice is NOT required 
>>  
>>  
>> Thanks,
>>  
>> —
>>  
>> JG
>> 
>> 
>> 
>> James Gould
>> Distinguished Engineer
>> [email-masked]
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> VerisignInc.com
>>  
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Jan 2015 19:15:50 +0000

Trung,

If the desire is to determine whether there is a trademark against the name, the client could pass “claims” even though “claims” may be a past phase, assuming that the server supports it.  Do you know why a client would want to know this if a claims notice is not required for the active phase?

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Jan 8, 2015, at 12:11 PM, Tran, Trung <[email-masked]<mailto:[email-masked]>> wrote:

Trung

Thanks Jim.

Thanks,
Jody Kolker
319-294-3933 (office)

All,

        *   return exists=true

     *   else

        *   return exists=false

        *   return exists=true

     *   else

        *   return exists=false

     *   else

     *   else

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://61/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Jan 2015 19:35:17 +0000

Francisco,

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.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 8, 2015, at 12:44 PM, Francisco Obispo <[email-masked]<mailto:[email-masked]>> wrote:

Hi James,

Thanks

Francisco Obispo

<Mail Attachment.png>

On Jan 8, 2015, at 9:11 AM, Tran, Trung <[email-masked]<mailto:[email-masked]>> wrote:

Trung

Thanks Jim.

Thanks,
Jody Kolker
319-294-3933 (office)

All,

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 8 Jan 2015 12:08:16 -0800

>>> 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 <[email-masked]> wrote:
> 

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Jan 2015 20:23:56 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 8, 2015, at 3:08 PM, Francisco Obispo <[email-masked]<mailto:[email-masked]>> wrote:

On Jan 8, 2015, at 11:35 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Francisco Obispo

<Mail Attachment.png>

---

From: Jody Kolker <[email-masked]>
Date: Thu, 8 Jan 2015 21:50:39 +0000

>From Francisco:

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)

From: Gould, James [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; [email-masked]; 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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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.

Francisco Obispo

<Mail Attachment.png>

---

From: "Gould, James" <[email-masked]>
Date: Fri, 9 Jan 2015 16:27:38 +0000

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1.  During claims phase with a claims check command
     *   If domain has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  2.  During post claims phase with a claims check command
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  3.  During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
     *   If domains has matching trademark
        *   return exists=true
     *   else
        *   return exists=false

  2.  During post claims phase with a create command

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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)

From: Gould, James [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; [email-masked]<mailto:[email-masked]>; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://82/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

Francisco Obispo

<Mail Attachment.png>

---

From: "Tran, Trung" <[email-masked]>
Date: Tue, 13 Jan 2015 03:04:01 +0000

This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <[email-masked]<mailto:[email-masked]>>
Cc: Francisco Obispo <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Tran, Trung" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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=>

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

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=>

Francisco Obispo

<Mail Attachment.png>

---

From: Michael Holloway <[email-masked]>
Date: Tue, 13 Jan 2015 09:18:57 +0100

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: [email-masked] <mailto:[email-masked]>

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 <[email-masked] <mailto:[email-masked]>>
> To: Jody Kolker <[email-masked] <mailto:[email-masked]>>
> Cc: Francisco Obispo <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> "Tran, Trung" <[email-masked] <mailto:[email-masked]>>
>     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. If domain has matching trademark
>              1. return exists=true
>          2. else
>              1. return exists=false
>          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. If domain has matching trademark
>              1. claims notice is required
>          2. else
>              1. claims notice is NOT required
>          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
>     [email-masked]
>
>     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=>
>
>>     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
>>          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. If domain has matching trademark
>>              1. claims notice is required
>>          2. else
>>              1. claims notice is NOT required
>>          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 ([email-masked] <mailto:[email-masked]>)
>>     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:[email-masked]]
>>     *Sent:*Thursday, January 08, 2015 12:24 PM
>>     *To:*Francisco Obispo
>>     *Cc:*Jody Kolker;[email-masked] <mailto:[email-masked]>; 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
>>
>>
>>
>>     *James Gould
>>     *Distinguished Engineer
>>     [email-masked] <x-msg://82/[email-masked]>
>>
>>     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
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         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
>>             <[email-masked] <mailto:[email-masked]>> 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*

---

From: "Gould, James" <[email-masked]>
Date: Tue, 13 Jan 2015 13:34:22 +0000

Trung,

Got it, so it’s really for resale or recreate use cases post the initial create.  I believe that supporting the claims check with “claims” as the phase post the “claims” phase would address this use case, since all domains that have trademarks in the “claims” phase will return exists=“1” as desired.  The question is whether the draft should provide text to cover this use case and I’m assuming that this behavior is a MAY, meaning servers MAY support this behavior.  Do the registrars on the list see a need for this behavior and feel that using the claims check with “claims” as the phase post the “claims” phase is acceptable and how strong of a need is this (MAY or SHOULD).

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 12, 2015, at 10:04 PM, Tran, Trung <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Trung

Jody,

Thoughts?

—

JG

<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
[email-masked]<x-msg://9/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 13 Jan 2015 13:44:43 +0000

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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 13, 2015, at 3:18 AM, Michael Holloway <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]>

Thanks,
Trung

Jody,

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://11/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

---

From: Michael Holloway <[email-masked]>
Date: Tue, 13 Jan 2015 16:08:18 +0100

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

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.
>
> VerisignInc.com <http://VerisignInc.com>
>
> On Jan 13, 2015, at 3:18 AM, Michael Holloway 
> <[email-masked] <mailto:[email-masked]>> 
> 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.
>>
>> 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
>>> 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
>>> <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>, "Tran, Trung" <[email-masked] 
>>> <mailto:[email-masked]>>
>>>     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.
>>>
>>>     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?
>>>
>>>     [email-masked] <x-msg://11/[email-masked]>
>>>
>>>     703-948-3271
>>>     12061 Bluemont Way
>>>     Reston, VA 20190
>>>
>>>     VerisignInc.com
>>>>     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.
>>>>
>>>>             return
>>>>     perspective, I’m not sure if determining if a domain has a
>>>>     claim when all claims periods have expired is needed. This
>>>>     319-329-9805 (mobile) Please contact my direct supervisor
>>>>     Charles Beadnall ([email-masked]
>>>>     <mailto:[email-masked]>) with any feedback.
>>>>     This email message and any attachments hereto is intended for
>>>>     use only by the addressee(s) named herein and may contain
>>>>     *Cc:*Jody Kolker;[email-masked] <mailto:[email-masked]>;
>>>>     Tran, Trung
>>>>     *Subject:*Re: [eppext] draft-ietf-eppext-launchphase Support
>>>>     for a "Claims Service" post the Claims Phase
>>>>     Francisco,
>>>>     requirement for claims check and claims notice) I’m not sure
>>>>     the value in defining a new top-level phase name.  Is there a
>>>>     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
>>>>
>>>>
>>>>
>>>>     *James Gould
>>>>     *Distinguished Engineer
>>>>         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.
>>>>             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*
>> [email-masked] <mailto:[email-masked]>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 13 Jan 2015 15:40:25 +0000

Michael,

I provide feedback inline below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 13, 2015, at 10:08 AM, Michael Holloway <[email-masked]<mailto:[email-masked]>> 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

        *   return exists=true ## The claims exists but it is NOT required on domain_create
     *   else
        *   return exists=false

     *   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?

Michael Holloway

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer
[email-masked]<x-msg://15/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi all

Cheers,
Michael

Michael Holloway

Thanks,
Trung

Jody,

Thoughts?

—

JG

[X]

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 16 Jan 2015 13:38:22 -0800

Just a heads-up - I am testing out some Universal Acceptance stuff for a
document with the Domain Name Association, and I have found that some of
your registries (hosted or directly) are not correctly inhibiting dashes in
the third and fourth positions in check commands.

Should that be on the Registrar to enforce or the Registry?  IMHO both but
think the latter is the right place.

Jothan Frakes
Tel: +1.206-355-0230

On Fri, Jan 9, 2015 at 8:27 AM, Gould, James <[email-masked]> wrote:

>  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?
>
>
>    “claims” as the phase (optional matching trademark past the claims phase
>    use case)*
>       days of release and has matching trademark return
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
>  On Jan 8, 2015, at 4:50 PM, Jody Kolker <[email-masked]> wrote:
>
>   From Francisco:
>
>  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.
>
>
>       days of release and has matching trademark return
>  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)
> Beadnall ([email-masked]) 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:[email-masked] <[email-masked]>]
> *Sent:* Thursday, January 08, 2015 12:24 PM
> *To:* Francisco Obispo
> *Cc:* Jody Kolker; [email-masked]; 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
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com <http://verisigninc.com/>
>
>   On Jan 8, 2015, at 3:08 PM, Francisco Obispo <[email-masked]>
> wrote:
>
>
>   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,
>   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.
>
>
>
> 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*

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 16 Jan 2015 14:24:36 -0800

I should have been more specific on this

I tested a check command for the string 'jo--than' against a suite of
registries and many returned that the name was available, which is
incorrect as it should be blocked by policy.  XN-- is the only exception to
the restriction on dashes at third and fourth position.

Verisign - you're good on this - Uniregistry and Afilias and Centralnic as
well.  Others - mileage varies.

Jothan Frakes
Tel: +1.206-355-0230

On Fri, Jan 16, 2015 at 1:38 PM, Jothan Frakes <[email-masked]> wrote:

>>    passing “claims” as the phase (optional matching trademark past the claims
>>    phase use case)*
>>  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
>>   Once a TLD has ended the mandatory 90 day period of “claims” a
>> registry might decide to call it something else.
>>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 20 Jan 2015 13:58:44 +0000

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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 13, 2015, at 10:40 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Michael,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://57/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi

Cheers,
Michael

Michael Holloway

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi all

Cheers,
Michael

Michael Holloway

Thanks,
Trung

Jody,

Thoughts?

—

JG

[X]

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

---

From: Michael Holloway <[email-masked]>
Date: Wed, 21 Jan 2015 14:41:14 +0100

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

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:
>
> 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.
>
>> [email-masked] <x-msg://57/[email-masked]>
>>
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>>
>> On Jan 13, 2015, at 10:08 AM, Michael Holloway 
>> <[email-masked] 
>> <mailto:[email-masked]>> 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_)
>>> 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]
>>> 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.
>>
>>>      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
>>>     “claims” as the phase (optional matching trademark past the
>>>     claims phase use case)*
>>>      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?
>>>> 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.
>>>>
>>>> [email-masked] <x-msg://15/[email-masked]>
>>>>
>>>> 703-948-3271
>>>> 12061 Bluemont Way
>>>> Reston, VA 20190
>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>> 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
>>>>>>     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
>>>>>>         passing “claims” as the phase (optional matching
>>>>>>         trademark past the claims phase use case)*
>>>>>>>     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?
>>>>>>>     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.
>>>>>>>
>>>>>>>         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. If domain was released post claims phase start and
>>>>>>>             is within 90 days of release and has matching
>>>>>>>             trademark return
>>>>>>>     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)
>>>>>>>     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.
>>>>>>>     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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     *James Gould
>>>>>>>     *Distinguished Engineer
>>>>>>>         names-collision block list (30 day period instead of a
>>>>>>>         60 day end-date sunrise), and we initially thought about
>>>>>>>         “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.
>>>>>>>         called, it seems like we’re going to end up with
>>>>>>>         discrete phase names for anything that is not: claims or
>>>>>>>         sunrise.
>>>>>>>
>>>>>>>             there a past mail list thread on this or is this a
>>>>>>>             new issue?  Please clarify.
>>>>>>>
>>>>>>>         *Francisco Obispo*

---

From: "Gould, James" <[email-masked]>
Date: Wed, 21 Jan 2015 16:30:48 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 21, 2015, at 8:41 AM, Michael Holloway <[email-masked]<mailto:[email-masked]>> 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

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Michael,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi

Cheers,
Michael

Michael Holloway

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi all

Cheers,
Michael

Michael Holloway

Thanks,
Trung

Jody,

Thoughts?

—

JG

[X]

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

---

From: Michael Holloway <[email-masked]>
Date: Thu, 22 Jan 2015 13:07:45 +0100

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

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
>
>
>
>
> *James Gould
> *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> On Jan 21, 2015, at 8:41 AM, Michael Holloway 
>> 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.
>>
>> Trademark check form, so hopefully we can agree with that! That would 
>> be my vote anyway!
>>
>> Regards,
>> Michael
>>
>>
>>
>> *Michael Holloway
>>> 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.
>>>
>>> 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:
>>>
>>>>> 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.
>>>>
>>>> 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_)
>>>>> 4) [new]: A registry _may_ operate a post claims (matching 
>>>>> trademark past the claims phase use case) [create without claims]
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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 
>>>>>          1. *return exists=true *_## The claims exists but it is
>>>>>             NOT required on domain_create_
>>>>>      2. *else*
>>>>>          1. *return exists=false*
>>>>>
>>>>>
>>>>>         return ## How does the client know if 90 days has passed
>>>>>         (extended / post claims) or not without external source?
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> 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
>>>>>>>> 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
>>>>>>>> <mailto:[email-masked]>>, "Tran, Trung" 
>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>>     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.
>>>>>>>>
>>>>>>>>     “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,
>>>>>>>>     trademark past the claims phase use case.  Is this use case
>>>>>>>>     really needed?
>>>>>>>>
>>>>>>>>             trademark
>>>>>>>>     On Jan 8, 2015, at 4:50 PM, Jody Kolker
>>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>>     From Francisco:
>>>>>>>>>     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?
>>>>>>>>>     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”
>>>>>>>>>             trademark
>>>>>>>>>      1. During claims phase with a create command or post
>>>>>>>>>     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.
>>>>>>>>>     *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
>>>>>>>>>         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.
>>>>>>>>>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 22 Jan 2015 13:46:20 +0000

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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Jan 22, 2015, at 7:07 AM, Michael Holloway <[email-masked]<mailto:[email-masked]>> 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.

Cheers,
Michael

Michael Holloway

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer
[email-masked]<x-msg://87/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thanks James

Regards,
Michael

Michael Holloway

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Michael,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi

Cheers,
Michael

Michael Holloway

Thanks,

—

JG

<Mail Attachment.png>

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Hi all

Cheers,
Michael

Michael Holloway

Thanks,
Trung

Jody,

Thoughts?

—

JG

[X]

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)

Francisco,

Thanks,

—

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Francisco Obispo

<Mail Attachment.png>

---

From: Michael Holloway <[email-masked]>
Date: Thu, 22 Jan 2015 14:52:18 +0100

Okay agreed, all good.

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

*Michael Holloway
D: +44 20 7421 8273

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
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> On Jan 22, 2015, at 7:07 AM, Michael Holloway 
>> (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.
>>
>> server supporting claims.  The server SHOULD validate the value 
>> against the active server launch phase supporting claims.
>>
>>> 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
>>> [email-masked] <x-msg://87/[email-masked]>
>>>
>>> 703-948-3271
>>> 12061 Bluemont Way
>>> Reston, VA 20190
>>>
>>>> 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
>>>>> 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:
>>>>>
>>>>> 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.
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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 
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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 
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>> return a simple true/false value, or all the info returned on 
>>>>>>>>> a CNIS lookup exception notice_id etc.
>>>>>>>>>
>>>>>>>>> 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 
>>>>>>>>>> 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
>>>>>>>>>> Subject: Re: [eppext] draft-ietf-eppext-launchphase Support 
>>>>>>>>>>     “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
>>>>>>>>>>     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. 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
>>>>>>>>>>          1. If domain was released post claims phase start
>>>>>>>>>>             and is within 90 days of release and has matching
>>>>>>>>>>             trademark return
>>>>>>>>>>>     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. 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. If domain was released post claims phase start
>>>>>>>>>>>             and is within 90 days of release and has
>>>>>>>>>>>             matching trademark return
>>>>>>>>>>>     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
>>>>>>>>>>>     319-329-9805 (mobile) Please contact my direct
>>>>>>>>>>>     supervisor Charles Beadnall ([email-masked]
>>>>>>>>>>>     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.
>>>>>>>>>>>     *Cc:*Jody Kolker;[email-masked]
>>>>>>>>>>>     <mailto:[email-masked]>; Tran, Trung
>>>>>>>>>>>     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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     *James Gould
>>>>>>>>>>>     *Distinguished Engineer
>>>>>>>>>>>         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.
>>>>>>>>>>>         discrete phase names for anything that is not:
>>>>>>>>>>>         claims or sunrise.
>>>>>>>>>>>
>>>>>>>>>>>             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*