Re: Uniform Poll Responses for Launch Phase Results

James,

On Fri, Mar 1, 2013 at 9:48 PM, James Mitchell <
[email protected]> 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****
>
>  - the registrar does not have to charge registration fees in advance, nor
> give refunds
>

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

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