Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results

From: Wil Tan <[email-masked]>
Date: Fri, 1 Mar 2013 21:15:15 +1100

On Fri, Mar 1, 2013 at 4:39 AM, Gould, James <[email-masked]> wrote:

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

Indeed, that is exactly what we have done in past launches using the
pre-draft launchphase extension. I'm not sure why we neglected to encoded
in the draft. It definitely makes a lot of sense to have it standardised!

.wil

---

From: James Mitchell <[email-masked]>
Date: Fri, 1 Mar 2013 21:48:44 +1100

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-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2013 4:39 AM
To: Rubens Kuhl <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Rubens Kuhl [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 28, 2013 12:21 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results

Em 28/02/2013, às 14:15:000, <[email-masked]<mailto:[email-masked]>> 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

---

From: Wil Tan <[email-masked]>
Date: Fri, 1 Mar 2013 22:54:29 +1100

James,

On Fri, Mar 1, 2013 at 9:48 PM, James Mitchell <
[email-masked]> wrote:

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

I can see merits to this approach. It would be interesting to hear from
registrars if this approach is preferable to reconciling based on poll
messages indicating server-initiated allocation.

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

Why not define the allocation token in a specification instead of using
key-value pairs?

>  **
>
> The benefits with this approach are****
>

I suspect it makes sense for registrars to charge in advance anyway, or
they may find themselves in a situation of not finding a buyer after the
domain is ready for allocation. What happens then? Is there a grace period
within which the registrar has to allocate the domain? Will there be a way
for the registrar to cancel the order and the registry giving the domain to
a different applicant?

> ****
>
>  - the registrar is not possibly left out of pocket, charged registration
> fees by the registry for service side allocation of domainsfor no show
> registrants
>

 This only happens if they do not charge in advance.

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

As I mentioned above, the potential drawback is the lifecycle / policy /
processes after an application is ready for allocation. Should a registrar
prefer the usual way of server-initiated allocation, they would have to
fall back to a manual process of requesting registry support to bulk
allocate domains.

> 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.****
>
>
>
Agreed, it's a good principle, and the approach outlined by Jim Gould is
key to promoting interoperability and reducing manual efforts by registrars.

.wil

---

From: Mike O'Connell <[email-masked]>
Date: Fri, 1 Mar 2013 13:33:13 +0200

All,

We will approach launch slightly differently in that an EPP create must be submitted initially (with or without nameserver information) with payment and eventual resolution occurring out of band.

It would not be an issue to generate a standard poll message for success or failure for launch applications

+1

Regards,

--

Mike O'Connell
EPP Administrator
+27 11 314 0077

On 01 Mar 2013, at 12:48 PM, James Mitchell <[email-masked]> wrote:

> From: <Gould>, James <[email-masked]>
> To: Rubens Kuhl <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>    S:    <trID>
>    S:      <clTRID>BCD-23456</clTRID>
>    S:      <svTRID>65432-WXY</svTRID>
>    S:    </trID>
>    S:  </response>
>    S:</epp>
> 
>    S:    <trID>
>    S:      <clTRID>BCD-23456</clTRID>
>    S:      <svTRID>65432-WXY</svTRID>
>    S:    </trID>
>    S:  </response>
>    S:</epp>
> 
> From: [email-masked] [[email-masked]] on behalf of Rubens Kuhl [[email-masked]]
> To: [email-masked]
> Cc: [email-masked]
> Em 28/02/2013, às 14:15:000, <[email-masked]> escreveu:
> 
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Fri, 01 Mar 2013 15:00:15 +0100

Hi,

On 03/01/2013 11:48 AM, James Mitchell wrote:
> 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.

in the past we had to use two different ways in detecting if an
application has been successful:
- panData message as James Gould posted
- domain:info with or without application Id to fetch the domain data

In both cases we could check against local data which customer's
application was successful.

Regarding your approach, I've these questions for clarification:
- How can a registrar know which application was successful, if no
  contact data has been passed? If we have e.g. five customers that
  apply for the same name in sunrise with trademarks, how do we know
  which one is allowed to register the domain name?
- How do you plan to notify the registrar?

> - allocation follows the normal flow of information (registrar
>   requesting a domain name); registrars can activate any services as
>   normal during the registration process

In my opinion a 1001, action pending and later panData message is a
normal registration process as well, that will even not require any
extra work on the registrar side. Your approach would be a completely
new process that has to be implemented from the ground up.

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142

GPG-Key: 0x186C5F77
GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77

---

From: "Gould, James" <[email-masked]>
Date: Fri, 1 Mar 2013 14:22:24 +0000

James,

I don't agree that your flow is a "much simpler technical and business process for Registrars", since it adds an additional step (client allocation) that clients must do to get a domain allocated.  There can be many billing models (debit for application create, debit at server allocation, debit for both, support grace period credits, etc.) that don't really play into the interface flow.  The general flow that we've been discussing thus far for applications is:

  1.  Client creates application
  2.  Server optionally executes offline verification
  3.  Server allocates domain name (e.g. auction, priority selection, etc.)
  4.  Server notifies clients of result (rejected or allocated)

Independent of the poll messaging, in this flow the client is required to invoke only one command with the server in step 1.  Your flow adds a step 5 for the client to create the domain name using the "allocation token" returned in step 4.

In your flow, how do you plan to deal with applications in limbo because the client for some reason does not send the domain create with the allocation token (e.g. second limbo application round)?  Why delay the resolution of allocated applications with name servers already set by not using the name servers set on the application and requiring an additional client allocation step?

Your flow does not change the concept of an application being a domain in pendingCreate.  Since the domain mapping is being extended and the create of an application does not immediately allocate the domain name, it reflects a pending action.  If an application was a separate object with it's own object mapping, then it could be considered a simple create.  What you have added is an extra state "pendingClientAllocation" or "clientAllocation", and a required action by the registrar to use the domain create with the "allocation token" to allocate the domain name.  The "pendingClientAllocation" state of the application could transition to the "allocated" state once the registrar successfully sends the domain create, which could per RFC 5731 result in the pending action poll message.  Sending a pending action poll message might be unnecessary since the client took the action, but it would be compliant with RFC 5731.   The "clientAllocation" state could be a terminal state that would use the pending action poll message for notification.

I question the need at all for the "allocation token", since a combination of the existing attributes of the application and the domain name being created (domain name, registrar, and auth-info) could be used to authorize the client allocation.  Is there another purpose of the "allocation token" that I'm missing?

Thanks,

Jim

________________________________
From: James Mitchell [[email-masked]]
Sent: Friday, March 01, 2013 5:48 AM
To: Gould, James; Rubens Kuhl; [email-masked]
Cc: [email-masked]
Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results

All,

Thanks,
 James

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

   S:    <extension>
   S:      <launch:infData

   S:    </extension>

   S:    <extension>
   S:      <launch:infData

   S:    </extension>

Jim

From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]

Rubens

---

From: Gregory Berezowsky <[email-masked]>
Date: Fri, 1 Mar 2013 15:06:55 -0500

I'm with James Gould on this one. 

I don't see the point of introducing a new object mapping when the pendingAction/poll queue notification model seems to elegantly satisfy the requirements that I'm aware of and has been used for the launch of several registries.

Standardizing on a registration workflow model that is conceptually sound and has been implemented successfully by different registrar and registry stakeholders helps to mitigate the risks surrounding at least this one area of concern. It also does not require every participating stakeholder to implement support for a completely new mapping. 

The registrar "charge everybody/refund all but one" issue that James Mitchell pointed out sounds like a valid concern. I would be curious to see more registrar feedback to see if there are recommendations on whether this is actually an issue and what strategies have been or could be applied to deal with it.

Cheers,

Greg

On 01-Mar-2013, at 9:22 AM, "Gould, James" <[email-masked]> wrote:

> Client creates application
> Server optionally executes offline verification 
> Server allocates domain name (e.g. auction, priority selection, etc.)
> Server notifies clients of result (rejected or allocated)
> To: Rubens Kuhl <[email-masked]" <[email-masked]>
> Cc: "[email-masked]>
> From: [email-masked] [[email-masked]]

---

From: James Mitchell <[email-masked]>
Date: Sat, 2 Mar 2013 07:28:13 +1100

Response below.

>- How do you plan to notify the registrar?

We will notify a registrar of all applications won (domain name,
application id, registrant contact id) by email. If registrars prefer we
can notify them via poll message as well.

Note that we have been talking to some registrars who do not plan on
integrating the sunrise/landrush submission process into their core
registration systems, and have expressed interest in this model as a way
to get data into those systems. We are happy to change our process if this
all seems to fall apart, however thought we should point out how we are
planning on implementing it given feedback from registrars.

>new process that has to be implemented from the ground up.

I never said that it does not work. This model should work well for $5
domain names, someone will be prepared to lose that when either submitting
applications or on successful allocation. If domain names cost $50 or
more, few people will put that down to only to lose in auction, or
registrars will have 5 days to delete the allocated name if payment cannot
be obtained.

This whole process will have to be implemented from the ground up
including the launch phase mapping, the trademark clearinghouse
functionality etc etc.