Re: Uniform Poll Responses for Launch Phase Results

All,

Here at ARI we do not view applications as domains in pendingCreate, instead we view applications as an EOI, requiring only domain name and registrant. Collecting name server or technical contact information for all applications is unnecessary as many applications may not result in the allocation of a domain name; additionally at time of submitting applications many are not aware of the name server details they would need (nor should they need to be) we would prefer not to collect contact information that has no purpose.

We realise that some Registrars may want to reuse a lot of their existing code – and this is why we do overload the domain object (as you can see in our extension) for collection of the applications, thus if people do send technical contacts or name servers etc the system doesn’t break.

In terms of the allocation process, we are planning to go a completely different way with this. Instead of the server allocating the domain, we will require the registrar allocate the domain name once all is settled on their end. We will notify the Registrar of applications they have been successful with and they can then perform allocation of those (by creating the actual name) at their leisure. Allocation will be performed by sending a domain create with an allocation token using a key-value pair extension. We'd be happy to receive feedback on this approach.

The benefits with this approach are
 - the registrar does not have to charge registration fees in advance, nor give refunds
 - the registrar is not possibly left out of pocket, charged registration fees by the registry for service side allocation of domainsfor no show registrants
 - allocation follows the normal flow of information (registrar requesting a domain name); registrars can activate any services as normal during the registration process

And the benefits continue – it’s a much simpler technical and business process for Registrars.

It should be noted that this process will be used by us for all sunrise and land rush phases. We are yet to see drawbacks for this mechanism, as we allow registrars to bulk allocate domain names through support if they so desire, resulting in either a confirmation emails or poll message (if requested by the registrar).

Also, we fully subscribe to the Go-Daddy principal that any time an action is taken on an object sponsored by a Registrar, where that action was not initiated by the Registrar’s EPP systems, poll messages are used to notify Registrars.

Thanks,
 James

From: <Gould>, James <[email protected]<mailto:[email protected]>>
Date: Friday, 1 March 2013 4:39 AM
To: Rubens Kuhl <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results

I view an application as a domain in pendingCreate status, so I believe that the pending action poll message, per RFC 5731, is appropriate to notify the result of the application.  Using the <launch:infData> extension, it can provide the specific status and application identifier.  Do you believe that it makes sense to also include the poll messages for the intermediate state transitions?

Below could be the successful application:


   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1301">
   S:      <msg>Command completed successfully; ack to dequeue</msg>
   S:    </result>
   S:    <msgQ count="5" id="12345">
   S:      <qDate>2013-04-04T22:01:00.0Z</qDate>
   S:      <msg>Application successfully allocated.</msg>
   S:    </msgQ>
   S:    <resData>
   S:      <domain:panData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name paResult="1">example.tld</domain:name>
   S:        <domain:paTRID>
   S:          <clTRID>ABC-12345</clTRID>
   S:          <svTRID>54321-XYZ</svTRID>
   S:        </domain:paTRID>

   S:        <domain:paDate>2013-04-04T22:00:00.0Z</domain:paDate>
   S:      </domain:panData>
   S:    </resData>


   S:    <extension>
   S:      <launch:infData
   S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:        <launch:phase>sunrise</launch:phase>
   S:          <launch:applicationID>abc123</launch:applicationID>
   S:          <launch:status s="allocated"/>
   S:      </launch:infData>

   S:    </extension>


S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID> S: </response> S:</epp>

Below could be the unsuccessful application:


   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1301">
   S:      <msg>Command completed successfully; ack to dequeue</msg>
   S:    </result>
   S:    <msgQ count="5" id="12345">
   S:      <qDate>2013-04-04T22:01:00.0Z</qDate>
   S:      <msg>Application rejected.</msg>
   S:    </msgQ>
   S:    <resData>
   S:      <domain:panData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name paResult="0">example.tld</domain:name>
   S:        <domain:paTRID>
   S:          <clTRID>ABC-12345</clTRID>
   S:          <svTRID>54321-XYZ</svTRID>
   S:        </domain:paTRID>

   S:        <domain:paDate>2013-04-04T22:00:00.0Z</domain:paDate>
   S:      </domain:panData>
   S:    </resData>


   S:    <extension>
   S:      <launch:infData
   S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:        <launch:phase>sunrise</launch:phase>
   S:          <launch:applicationID>abc123</launch:applicationID>
   S:          <launch:status s="rejected"/>
   S:      </launch:infData>

   S:    </extension>


S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID> S: </response> S:</epp>

It would make sense to include something around the poll messaging in the draft.  What are the thoughts to this?

Jim

________________________________
From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Rubens Kuhl [[email protected]<mailto:[email protected]>]
Sent: Thursday, February 28, 2013 12:21 PM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results


Em 28/02/2013, às 14:15:000, <[email protected]<mailto:[email protected]>> escreveu:

Hi, All.  I've been catching up today on the good work that is being done by so many in this group to nail down a functional common standard to support TLD launch phases via EPP.  Thank you for all you are doing in this regard!

From a registrar perspective, there's a feature that I would find enormously helpful in facilitating TLD launches - poll messages to indicate when a domain application reaches a terminal state: allocated, rejected, or other.

Historically, for TLD launches, one of the most labor-intensive steps in the process for Go Daddy has been reconciling the results of sunrise and landrush phases by either processing a spreadsheet emailed to us by the registry or performing repeated whois queries to try to find out whether the domain has been allocated to us or not.  Both of these approaches are more manual than my liking.

As we approach the onrush of gTLD launches, we will be collaborating with our registry partners to provide poll messages to communicate the outcomes of domain applications, and it would be beneficial for all of us in the industry, I think, if the attributes of such poll messages were common across all TLDs.

Question 1 - Is it reasonable to expect that gTLD applications could culminate in a poll message communicating the outcome back to the requesting registrar?

Yes. We cannot see ourselves not sending a poll message. But what are you suggesting is a very interesting idea of having it standardized. There is value in not having 1400 different poll messages...

Question 2 - If so, do the following <poll> response examples seem suitable: adhering to existing EPP standards AND containing sufficient information to sync up with the registrar?


        <obj:apID>abc123</obj:applicationID>

What's the ID syntax reference on the current draft-tan ?


Rubens

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg