Re: Uniform Poll Responses for Launch Phase Results

John McFadden <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
Jim,
                Having the poll message would be great for us as well (MarkMonitor).  Using the <launch:infData> is fine witih us.

John

John J McFadden
Director Domain Products
MarkMonitor
Direct: +1.208.389.5741
Fax: +1.208.389.5771
[email protected]<mailto:[email protected]>
www.markmonitor.com<http://www.markmonitor.com/>

From: [email protected] [mailto:[email protected]] On Behalf Of Gould, James
Sent: Thursday, February 28, 2013 10:58 AM
To: [email protected]; [email protected]
Subject: Re: [provreg] Uniform Poll Responses for Launch Phase Results

Jeremy,

No problem, I believe that a general poll message with the <launch:infData> extension can be used for the intermediate state transitions and the pending action poll message with the <launch:infData> extension can be used for the end state transition.

What do others think?

Jim

________________________________
From: [email protected]<mailto:[email protected]> [[email protected]] on behalf of [email protected]<mailto:[email protected]> [[email protected]]
Sent: Thursday, February 28, 2013 12:54 PM
To: [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.

I agree, this would accomplish the desired result.  And if all registries would adopt, the whole community would benefit, all the way down to the registrant in the form of real-time information about the status of their application.


> Do you believe that it makes sense to also include the poll messages for the intermediate state transitions?

Go Daddy's position is that anytime a domain changes state at the registry, outside of a direct request from the registrar, it is appropriate for the registry to notify the registrar via poll message.  So, yes, poll messages for intermediate state transitions would be desired.  I consider those as "nice-to-have," while poll messages for the allocated and rejected statuses are a "must-have."



Thanks,
Jeremy Bushlack
GoDaddy.com<http://GoDaddy.com>
[email protected]<mailto:[email protected]>
http://www.godaddy.com
319-294-3934
We're hiring!<http://x.co/openings>

I value service, simplicity, and facts. How am I doing? Reply to my supervisor, Roger Carney ([email protected]<mailto:[email protected]>).

-------- Original Message --------
Subject: RE: [provreg] Uniform Poll Responses for Launch Phase Results
From: "Gould, James" <[email protected]<mailto:[email protected]>>
Date: Thu, February 28, 2013 11:39 am
To: Rubens Kuhl <[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>>
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]>]
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.