[gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names

Wed May 21 20:23:09 UTC 2014

Nic,

I agree that finding a consistent / standard approach to this would benefit all participants.  There are two problems that need to be addressed for these names, which include:

  1.  Allocation of the reserved names
     *   Should reserved name applications get created and allocated per draft-ietf-eppext-launchphase?
        *   The creation of applications may be mixed with registrations.  This is not a launch phase, but a release of a set of domains.  For registrars not explicitly participating in the release of the reserved names, it would be unclear why an application was created over a registration.  One mechanism to mitigate this is to require the <launch:create> extension with the “type” attribute set to “application” for the reserved domains.  I’m assuming that the check response would return back unavailable for reserved domains with a reason like “reserved domain” so not to mislead non-participating registrars.
        *   Following the full application state machine, as defined in draft-ietf-eppext-launchphase, may be overkill for releasing a smaller set of names.  Registrars may be discouraged from participating based on the level of complexity associated with the application state machine.
     *   Should an allocation string / token be used to authorize the registration of a reserved domain name that is made available out-of-band?  For example, an auction provider could provide the allocation string / token to the winner of the auction and the registrar would pass it with the domain create of the reserved domain via either the RFC 5731 authorization info or another EPP extension.
        *   The registries and the registrars would need to support a new mechanism for creating a reserved domain in using the allocation string / token.
        *   This is simpler than using the application state machine of draft-ietf-eppext-launchphase.
  2.  Handling the claims service for reserved names that have marks in the TMCH
     *   This problem was the point of the initial list posting, where the claims service would need to be re-enabled by registries and participating registrars for use only with the reserved domains potentially well past the claims launch phase.  This assumes that a registry does not run claims indefinitely.  Since reserved names would probably not be released all at once, this cycle would have to be repeated many times for each TLD.
     *   The options include:
        *   Registries and participating registrars must fully support the claims service based on the RPM requirements.  The registry must re-enable the claims check service, must re-enable the claims acknowledgement verification, and must re-enable the LORDN interface for a subset of the domain names.  The registrars must re-enable the use of the claims check service, must re-enable their interface with the CNIS, and must re-enable passing the claims acknowledgement for reserved domains that have marks.
           *   This is a great amount of overhead for the registries and the registrars for releasing a set of domain names potentially well past the claims launch period.
           *   This will discourage registrar participation.
           *   The registries must keep support for claims indefinitely that can be enabled later.
        *   Registries and participating registrars support asynchronous claims acknowledgement out-of-band of EPP.
           *   The registries would allow the creation of reserved domains that will be put in pendingCreate if there is a matching mark.  The claims acknowledge would need to be passed to the registry out-of-band to allocate the domain.
           *   Reserved domains that don’t have matching marks will be immediately allocated, assuming that the registry does not have a pendingCreate model.
        *   As Roy suggested, require claims service notification from the registries to the TMCH without the front-end claims service requirements.  I would loosely define this as “Claims Lite”, where the TMCH and subsequently ICANN will receive systematic notification of reserved name allocations that have marks.  We could consider broadening the notifications to include providing the initial reserved name list, release of the reserved domains, and finally allocation of all reserved domains.
           *   The registrars would not be impacted at all since there is no need to present the claims notice to the registrant, so therefore it will encourage registrar participation.
           *   Registries would need to support a new LORDN-like interface with the TMCH that may require a broader set of systematic notifications for monitoring and visibility by the mark holders and ICANN.
           *   Registries would not be required to support the claims check service and claims acknowledge validation.
           *   This could be an alternate approach to what is currently defined in the RPM requirements for the claims service.
        *   Don’t require support for the claims service for the releasing of reserved names.
           *   The reserved domains will be registered and allocated after the required claims launch period, where other domains registered and allocated during the “open” phase have no equivalent requirement.

 I prefer option 2 for the “Allocation of the reserved names” problem.  I prefer option 4 first, followed by option 3, for the “Handling the claims service for reserved names that have marks in the TMCH” problem.

Are there any other problems or options that need to be considered?  Are there any preferences from both registries and registrars?

--

JG

[cid:2D02DBFE-952D-4A9F-B173-6E9B7013FE70]

James Gould
Principal Software Engineer
jgould at verisign.com<mailto:jgould at verisign.com>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Nic Steinbach <nic at name.com<mailto:nic at name.com>>
Date: Monday, May 19, 2014 at 10:32 AM
To: Rubens Kuhl <rubensk at nic.br<mailto:rubensk at nic.br>>
Cc: "tmch-tech at icann.org<mailto:tmch-tech at icann.org>" <tmch-tech at icann.org<mailto:tmch-tech at icann.org>>, "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names

It would be nice to have a standard way of addressing this - supporting claims indefinitely, pursuing an alternate method like the one mentioned by Roy or any other solution - but I think given the TLD roll out so far standardization across all platforms seems unlikely. A PDP would not have tangible results before some registries would like to pursue this path. I would be surprised if a registry didn't implement a delayed reserved rollout along these lines this quarter and it will only pick from there.

Instead registries need to realize the development burdens on registry operators and registrars so that there reserved rollout is as standard as possible and enticing enough to make these burdens worthwhile. Given the nature of these names - it is certainly possible to make the program enticing. I would guess that as least within a registry operator, the mechanism for addressing both the claims and the validation piece that goes along with this would be standard.

We fully expect to support various models as long as the benefits and requirements are communicated clearly and translate to a sound business decision for all parties involved.

On Mon, May 19, 2014 at 8:03 AM, Rubens Kuhl <rubensk at nic.br<mailto:rubensk at nic.br>> wrote:

Seth,

Have you been able to use GDD Portal to get eternal claims service ? It seems to require a fixed date when submitting TLD Startup Info...

Rubens

Em 19/05/2014, à(s) 11:00:000, Seth Goldman <sethamin at google.com<mailto:sethamin at google.com>> escreveu:

We are planning to offer an eternal claims service on all our TLDs. It's better for trademark holders, plus it's operationally simpler.

Seth

On Mon, May 19, 2014 at 7:53 AM, Gould, James <JGould at verisign.com<mailto:JGould at verisign.com>> wrote:
According to section 2.4.3 of the Rights Protection Mechanism (RPM) Requirements, it states:

If Registry Operator reserves a domain name from registration in accordance with Section 2.6 of the Agreement and Specification 5 of the Agreement and thereafter (i) releases for Allocation or registration such reserved domain name at any time prior to the start date of the Claims Period, such domain name MUST be treated like any other domain name for any applicable Sunrise Period, Limited Registration Period, Launch Program or Claims Period, or (ii) releases for Allocation or registration such reserved domain name at any time following the start date of the Claims Period, such domain name MUST be subject to the Claims Services (as defined in Section 3) for a period of ninety (90) calendar days following the date Registry Operator releases such domain name for registration as long as the Trademark Clearinghouse (or any ICANN-designated successor thereto) remains in operation.

For registries that plan on releasing domain names after the Claims Period, such as to support the release of premium domain names or 2 character domain names, they will have to support the Claims Services well past the Claims Period (potentially years).  This represents a costly burden to the registries having to indefinitely download the DNL list, support the claims check, validating the domain creates against the DNL list for a subset of domain names, and support the TMCH LORDN interface.  This also represents a costly burden to registrars or discourages registrar participation in supporting the release of reserved domain names.  The registrars would need to know to use the claims check, use the CNIS for presenting the claims notice, and passing the claims acknowledgement indefinitely.

Since this is a complex issue impacting registries and registrars, what approaches are being considered?  Do the registries and registrars have any issues with supporting the Claims Service indefinitely?

Please respond with your thoughts and concerns.

Thanks,

--

JG

<3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[99].png>

James Gould
Principal Software Engineer
jgould at verisign.com<mailto:jgould at verisign.com>

703-948-3271<tel:703-948-3271> (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>
“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.”

--
Nic Steinbach
Strategic Relationship Manager
209.681.7838
[http://name.com/images/email-signature-logo1.jpg]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20140521/3e07e265/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[59].png
Type: image/png
Size: 4109 bytes
Desc: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[59].png
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20140521/3e07e265/3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B7459-0001.png>