Re: [regext] TLD Phase Discovery

[Thomas Corte <[e-mail]>]

James,

On 04/08/2017 16:58, Gould, James wrote:

> Thomas,
> 
> I believe the domain-level availability based on launch phases is a
> corner case that as you point out is currently supported by the
> Availability Check Form in draft-ietf-regext-launchphase.  Providing
> trial-and-error probing is sort of the point of the Check Command and
> its extensions, so I’m not sure whether there is a real problem to
> solve here.

Imagine a registry setup where certain domains names are available, but
only in certain launch phases (as described in the current launch phase
extension spec, so it's obviously not a "corner case" scenario at all).

Now, to find the right launch phase, a registrar seeking to register one
of those names now needs to:

1) Determine the available launch phases (either out-of-band, or using
the newly discussed facility to enumerate existing launch phases, i.e.
possibly yet another extension)

2) Send one <check> command for every single of these launch phases,
until the server signals the domain's availability for the name.

With x launch phases running in parallel, this would require up to x+1
commands just to determine the right phase.
That's not only inconvenient for the registrar, but also puts a strain on
the server where no optimization of this task can happen.

> Your proposal is to pass any empty <launch:check> extension element
> with type=”avail”, to indicate the Availability Check Form, to the
> Domain Check Command for the server to return the list of launch
> phases where the domain name is available. What is the expected
> behavior of the Domain Check Command itself?  Is the availability of
> the domain name based on the current phase?  If this is the case, then
> we’re getting into the territory of merging two commands (availability
> of domain in current phase and get a list of phases that the domain is
> available) into one.  If such a feature is really needed, I would
> propose creating another check form (e.g. “Phase Availability Check
> This Form” with a type value of “phase-avail”) that only returns the
> list of phases that the domain is available in or a list of all the
> known phases with an availability flag for each phase.  This would
> define a new Phase Availability Check Command that would return the
> <launch:chkData> extension of an EPP Response like what is done for
> the Claims Check Form or the Trademark Check Form.

I agree that the actual availability check's semantics need to be
carefully defined in this scenario. A new check form (which doesn't
return any data outside of the extension) could be the way to go here.

> The following is what a Phase Availability Check Command and Response
> may look like where all of the known phases with an availability flag
> for each phase is returned: ...

The command/response examples you provided are exactly what I'd like to
see in order to solve this problem.

> I question the need for this functionality, since I view the
> domain-level availability based on launch phases as being already
> supported by the Availability Check Form in
> draft-ietf-regext-launchphase, and adding a new check form to
> draft-ietf-regext-launchphase as meeting the same need in a different
> way for a corner case.  I would like to hear from the registries and
> registrars of whether this additional functionality is needed.  I
> believe it is not needed.

As depicted above, the alternative to the proposed functionality involves
a lot of commands, plus possibly an out-of-band determination of launch
phases, which may cause the registrar to work with outdated information
at some point.

Sure, if the goal is to keep EPP "minimal" in terms of having exactly one
way to accomplish a certain task, this may not be needed. But one could
argue that even now, EPP has some features which are unnecessary in this
regard. There's arguably no need for a <contact:check> to determine
whether a contact ID is available; the registrar can simply try to create
the contact and see what happens (and some are actually doing exactly
that). Again, the benefit of having the less costly <check> available is
a lower load on the server.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: [phone]
Martin-Schmeisser-Weg 9                       Fax: [phone]
D-44227 Dortmund                       E-Mail: [e-mail]
Germany