Re: [regext] TLD Phase Discovery

[Roger D Carney <[e-mail]>]

Good Morning,



To me it seems:

1. That this is somewhat of a corner case.

2. I don't think the current draft of launchphase addresses the issue Thomas is expressing.

3. I don't think there is a need to modify launchphase for this functionality.



Sending a separate note to discuss Thomas' issue.





Thanks

Roger





-----Original Message-----
From: regext [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Monday, August 07, 2017 10:19 AM
To: Thomas Corte <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [regext] TLD Phase Discovery



Thomas,



My feedback is provided below with a “JG-“ prefix.



From a high level, we need other registries and registrars to weigh in on this topic to answer the following:



1. Is phase-dependent availability (e.g., domain available only in specific launch phases) a corner case?

2. Does the existing Availability Check Form in draft-ietf-regext-launchphase satisfy the need?

3. Is adding a new check form to draft-ietf-regext-launchphase (e.g., Phase Availability Check Form) needed?



My answer to the questions is Yes, Yes, and No.  We need others to help determine the path forward for draft-ietf-regext-launchphase.



Thanks,



—

JG







James Gould

Distinguished Engineer

[e-mail]<mailto:[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 8/7/17, 5:22 AM, "regext on behalf of Thomas Corte" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:



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



JG-I believe this use case is a “corner case”.  Of the TLD’s that we’ve launched, there are only a few that had specific availability rules associated with a Limited Registration Period (LRP), that did not warrant creating or changing a check form defined in draft-ietf-eppext-launchphase.  The Availability Check Form was added to draft-ietf-eppext-launchphase based on a request by James Mitchell.  Can the other registries identify whether this is a corner case or not?  I would also like to hear from the registries and the registrars whether the existing Availability Check Form does not address it?



    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.



JG-I believe the Available Check Form was added to fulfil the need of determining whether a domain is available in a specific launch phase.  The Availability Check Form should be lightweight and it should not be very difficult for a client to get what is needed once they know what the launch phases are either out-of-band or via an extension like the Registry Mapping.



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



JG-Yes, the question for this use case is whether the availability is strictly based on policy, meaning given the list of known launch phases would the domain name be available in each phase based on its policy?  The registration of the domain name, the registration of a variant, and the registration of some other dependent objects (e.g., e-mail forwarding or defensive registration in .name) does not impact the value of the availability, or does it?  If the availability is based on policy and based on registered data, then the response would need to be more complex in providing a reason why a domain is not available.



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



JG-I agree; although it may need to include a reason element if the availability is based on more than simply checking against the policy.  The policy would most likely be driven by reference data that can be cached and can be very fast.  I would prefer for the availability to be strictly based on policy and leave combining policy and registration data for the logic in the Availability Check Form.



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



JG-I still believe that a new check form is not warranted, but I would like to hear from other registries and registrars on whether this is a corner case and whether the existing Availability Check Form does not adequately address the need.



    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]<mailto:[e-mail]>

    Germany



    _______________________________________________

    regext mailing list

    [e-mail]<mailto:[e-mail]>

    https://www.ietf.org/mailman/listinfo/regext





_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext