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

"Gould, James" <JGould@verisign.com> Wed, 21 January 2015 16:31 UTC

Return-Path: <JGould@verisign.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D01A1B21 for <eppext@ietfa.amsl.com>; Wed, 21 Jan 2015 08:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDR-aQ8usNIz for <eppext@ietfa.amsl.com>; Wed, 21 Jan 2015 08:30:56 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924001A1B1C for <eppext@ietf.org>; Wed, 21 Jan 2015 08:30:51 -0800 (PST)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKVL/UOzkS4IgfceOgZdexL0NlWU5ZiJ81@postini.com; Wed, 21 Jan 2015 08:30:52 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0LGUoYx004175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 11:30:50 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 21 Jan 2015 11:30:49 -0500
From: "Gould, James" <JGould@verisign.com>
To: Michael Holloway <michael.holloway@comlaude.com>
Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgIAAF1sAgAAI+ACACuPxAIABjWoAgAAvWQA=
Date: Wed, 21 Jan 2015 16:30:48 +0000
Message-ID: <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com>
References: <D0D41AB9.46E54%trung.tran@neustar.biz> <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <B392E842-86BF-4F1E-96FC-ED2EA7E19F6D@verisign.com> <D5A4D4D5-C37A-442D-981B-3381483A292B@uniregistry.com> <CF36E711-27BD-47A6-938E-B9B1804DFD0E@verisign.com> <BLUPR02MB034B2D11DA287B2DB2A4B59BF470@BLUPR02MB034.namprd02.prod.outlook.com> <C3F2FBCA-C800-4CC2-BD49-D36D028B5522@verisign.com> <D0D9F3EF.49253%trung.tran@neustar.biz> <54B4D4F1.6070405@comlaude.com> <EF1D8AA2-F340-4782-BE72-BB271203C1D1@verisign.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> <54BFAC7A.7090500@comlaude.com>
In-Reply-To: <54BFAC7A.7090500@comlaude.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_378DCFEE69D7468EB928EE35378FE875verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/Z7TkTk4LgB27v6vTOYlux_aPftM>
Cc: "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2015 16:31:04 -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


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

On Jan 21, 2015, at 8:41 AM, Michael Holloway <michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>> wrote:

Thanks James

>From a registrar perspective I would say this solves the issue without the risk of breaking working clients. I would be interested to hear the opinion of anyone [else] representing registries here whether they would support the extra type attribute since its essentially optional extra, or whether they would prefer to support using he existing schema.

I think in the case of the latter it would suggest using Claims check on phases outside of "claims" (e.g. "open"),  and then some guidance would need to be offered (in the draft) to define exactly what the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availability) period during the claims period; and therefore when to and when not to use the "open" phase. Some minor wording changes would be required in 3.1.1 Claims check form to change it from `The launch phase that SHOULD be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Trademark check form, so hopefully we can agree with that! That would be my vote anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the past “claims” phase in the claims check command to support Trung’s request.  The issue is that some clients are hard coding “claims” as the phase in the claims check command and currently there is little to no support for the claims check command outside of the “claims” phase, so clients may inadvertently go through the claims process when it is not required or even potentially rejected on create.  I see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not crazy about making an XML schema change, we may be able to tweak things to support both the the claims check outside of the “claims” phase and also support Trung’s request to determine whether or not a trademark matches a name independent of the requirement for a claims notice for other use cases like the resale of domain names.

We already support a “type" attribute in the <launch:check> element, section 3.1, to define the check form of the command, which currently support “claims” and “avail” for the Claims Check Form and the Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return “exists=1” if there is a matching trademark and a claims notice is required on create, per the proposed check changes.  We could add a Trademark Check Form (e.g. add section 3.1.3) that is indicated by setting the “type” attribute to “trademark”.  The interface for the Trademark Check Form is consistent with the Claims Check Form, except the <launch:phase> element is not applicable, so therefore in the schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademarks to return the same response as with the Claims Check Form.  The <launch:phase> element would still be required for the Claims Check Form and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the server is determined by server policy, so the Trademark Check Form would is an option but is not required.  The check command using the Trademark Check Form would look like:


   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
   C:     type=“trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>



To support this, section 3.1.3 Trademark Check Form would need to be added along with some text changes on the “trademark” value for the “type” attribute in section 3.1, <enumeration value=“trademark”/> would need to be added to the checkFormType in the schema, and minOccurs=“0” would need to be added to the “phase” element of checkType in the schema.

Let me know your thoughts on this option.

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://82/jgould@Verisign.com>

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

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

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com<mailto:JGould@verisign.com>> wrote:

Michael,

I provide feedback inline below.

—

JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://57/jgould@Verisign.com>

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

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

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from.

The use case for the claims check post the claims phase is used to address the release of domain names that did not go through 90 days of claims, which I believe is a modified version of your #2 below.

Let’s take the three basic phases defined in draft-ietf-eppext-launchphase as an example with sunrise, claims, and open.  We can pretty much remove the sunrise phase from the example for now, so let’s focus on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a claims check is done with “open” as the phase, the response would be exists=“0”, since there is no requirement to provide the claims notice on create.  If reserved.tld was released during the “open” phase, then a claims check on reserved.tld, with “open” as the phase, the response would be exists=“1”, since a claims notice is required on create.  Based on Trung’s use case, a client may want to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client can send a claims check with the phase as “claims” to get that answer.



Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domains for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create without claims]

If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate.


Based on the updated text, the client will only receive a claims check response with exists=“1” if “create with claims form” is required.  The updated text does not support #4, since the only time that “exists=0” is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic of passing special attributes or sub-phases to get the answer that is needed, which is whether a claims notice is required on create.  Trung use case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domain name independent of whether a claims notice is required on create, so passing “claims” as the phase past the “claims” phase may support that.

Let me know whether or not this helps.


I hope this makes sense; and apologies if I am missing something fundamental!

Cheers,
Michael


  1.  During claims phase with a claims check command
     *   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 ## The claims exists but it is NOT required on domain_create
     *   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
  2.  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 ## How does the client know if 90 days has passed (extended / post claims) or not without external source?
        *   claims notice is required
     *   else
        *   claims notice is NOT required



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / TMDB was worked out a couple of years ago, where there was a desire to not make the CNIS the critical path for the majority of the registrations.  The agreement was for the registries to provide the claims check service and enforce the claims notice on create based on a feed of trademark labels from the TMDB to the registries.

The proposal is to support the claims service post the “claims” phase by passing the active phase to the server and the server will return whether or not the claims notice is required based on a combination of a matching trademark and whether the domain name already went through 90 days of the claims service.  From a client perspective it means utilizing the claims check in a similar fashion during and post the claims phase.  The use case brought up by Trung was more of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name independent of the requirement for passing the claims notice.  In that case, the proposal is to pass “claims” as the phase independent of the active phase to get a true or false answer to whether a trademark matches the domain name.

Do the proposals work for you?

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://15/jgould@Verisign.com>

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

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

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com<mailto:michael.holloway@comlaude.com>


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com<mailto:JGould@verisign.com>>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com<mailto:jkolker@godaddy.com>>
Cc: Francisco Obispo <fobispo@uniregistry.com<mailto:fobispo@uniregistry.com>>, "eppext@ietf.org<mailto:eppext@ietf.org>" <eppext@ietf.org<mailto:eppext@ietf.org>>, "Tran, Trung" <trung.tran@neustar.biz<mailto:trung.tran@neustar.biz>>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

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

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


  1.  During claims phase with a claims check command
     *   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


  1.  During claims phase with a create command
     *   If domain has matching trademark
        *   claims notice is required
     *   else
        *   claims notice is NOT required
  2.  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

Thoughts?

—

JG


[X]

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://11/jgould@Verisign.com>

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

VerisignInc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__VerisignInc.com&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=szebc6wpGwppUlrnEyVYLycmIErTch1EX1wsyS31LMM&m=a_JzT0U7GbcwWgKca9Yn1v1l7xxuwH3lVAP_eW0V09I&s=yC8iNOnjjvMIbW-gZsn7rA62FX8o8ZmCI14bhrQZ7TI&e=>

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com<mailto:jkolker@godaddy.com>> wrote:

>From Francisco:

Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.

With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?

This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.


  1.  During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
     *   If domain has matching trademark
        *   return exists=true
     *   else
        *   return exists=false
  2.  During post claims phase with a claims check command with a sub-phase of “extended”
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark
        *   return exists=true
     *   else
        *   return exists=false



  1.  During claims phase with a create command or post claims phase without a sub-phase of “extended”
     *   If domain has matching trademark
        *   claims notice is required
     *   else
        *   claims notice is NOT required
  2.  During post claims phase with a create command with a sub-phase of “extended”
     *   If domain was released post claims phase start and is within 90 days of release and has matching trademark return
        *   claims notice is required
     *   else
        *   claims notice is NOT required

This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.

Thoughts?

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com<mailto:cbeadnall@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

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

Francisco,

I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.

Thanks,

—


JG

<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://82/jgould@Verisign.com>

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

VerisignInc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__verisigninc.com_&d=AwMF-g&c=MOptNlVtIETeDALC_lULrw&r=szebc6wpGwppUlrnEyVYLycmIErTch1EX1wsyS31LMM&m=a_JzT0U7GbcwWgKca9Yn1v1l7xxuwH3lVAP_eW0V09I&s=3GJIlJDRYzqHAwoiiYIQ35ek_aOxjUrEB5OfZMjak-8&e=>

On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com<mailto:fobispo@uniregistry.com>> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to
pass the claims notice for domain names outside of the claims phase.


Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else.

We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.

Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.


On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com<mailto:JGould@verisign.com>> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


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




_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext



_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext




_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext



_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext