Subject: Re: [regext] TLD Phase Discovery

From: "Gould, James" <[email-masked]>
Date: Thu, 3 Aug 2017 16:12:41 +0000

Roger,

I believe TLD level EPP policies is relevant, but is best suited for something outside of the Launch Phase or Registry Fee command-response extensions.   An example policy EPP mapping is the Registry Mapping (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html) that does provide launch phase schedule information at the TLD (zone) level.  Something like the Registry Mapping with extensions to define the features and policies of EPP extensions like the Launch Phase or Registry Fee extensions is best suited for defining and discovering the features and policies.

—

JG

[id:[email-masked]]

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

From: regext <[email-masked]> on behalf of Roger Carney <[email-masked]>
Date: Thursday, August 3, 2017 at 12:03 PM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] [regext] TLD Phase Discovery

Good Morning,

Coming out of Prague I mentioned that I would post to the list the idea of a Launch Phase Mapping/List feature. I believe the thought was to come up with some way to query the registry for a list of phases and associated dates for a TLD.

Are there any thoughts on where/how this might be best implemented? Or more importantly if such a feature is even needed? I feel that it is needed.

Thanks
Roger

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 3 Aug 2017 18:31:38 +0200

Gould, James <[email-masked]> 2017-08-03 18:13
> I believe TLD level EPP policies is relevant, but is best suited for something outside of the Launch Phase or Registry Fee command-response extensions.   An example policy EPP mapping is the Regist…

I agree with Roger that auto-discovery should be a problem to be
tackled and replied with solutions. For TLD phases but also for a lot
of other "knobs" and options in EPP.

And I totally agree with James on the Registry Mapping extension, that
could be suited for this task.

I would even be very happy if VeriSign
could push forward to make this EPP extension a standard, to be used
by many registries.

-- 
Patrick Mevzek

---

From: Thomas Corte <[email-masked]>
Date: Fri, 4 Aug 2017 13:19:50 +0200

James,

On 03/08/2017 18:12, Gould, James wrote:

> Roger,
> 
> I believe TLD level EPP policies is relevant, but is best suited for
> something outside of the Launch Phase or Registry Fee command-response
> extensions.   An example policy EPP mapping is the Registry Mapping
> (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html)
> that does provide launch phase schedule information at the TLD (zone)
> level.  Something like the Registry Mapping with extensions to define the
> features and policies of EPP extensions like the Launch Phase or Registry
> Fee extensions is best suited for defining and discovering the features
> and policies.    

This "Registry Mapping" extension seems suitable to discover the more
"static" properties of a registry's setup (including the generally
supported phases).

However, what I'd also like to see is a more "dynamic" phase discovery.
In particular, we should cover cases in which a specific domain name may
only be available when created in specific launch phases, and provide a
way to determine these phases (this functionality was unfortunately
removed from the fee extension in draft-ietf-regext-epp-fees-06).

To me, such a feature seems closely tied to the "Availability Check Form"
defined in the launch phase extension, which is defined exactly for that
purpose (from the launch phase extension draft: "Domain names may be made
available only in unique launch phases, whilst remaining unavailable for
concurrent launch phases.").
The only problem is that the "Availability Check Form" forces registrars
to perform trial-and-error probing, since it requires the specification
of a launch phase and will only tell whether or not that phase is
suitable. Registrars need to check all known launch phases in turn until
a suitable one is found.

The problem of launch phase discovery for specific names could therefore
be solved as an extension of the launch phase extension, e.g. by making
the specification of the phase for the "Availability Check Form"
*optional* and, if not specified, allowing the command to return a list
of suitable launch phases for the name.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Gould, James" <[email-masked]>
Date: Fri, 4 Aug 2017 14:58:16 +0000

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.  The Availability Check Form of draft-ietf-regext-launchphase extends the Domain Check to qualify which phase the Domain Check should be executed against.  There is no extension of the Domain Check Response with the Availability Check Form since the intent is to only provide the target launch phase to execute the availability logic for.  

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

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:   <check>
C:    <domain:check
C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:      <domain:name>domain1.example</domain:name>
C:      <domain:name>domain2.example</domain:name>
C:      <domain:name>domain3.example</domain:name>
C:    </domain:check>
C:   </check>
C:   <extension>
C:    <launch:check
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:     type="phase-avail"/>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>            

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="1000">
S:     <msg>Command completed successfully</msg>
S:    </result>
S:    <extension>
S:     <launch:chkData
S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:      <launch:pd>
S:        <launch:name>domain1.example</launch:name>
S:        <launch:phase avail=”1”>sunrise</launch:phase>
S:        <launch:phase avail=”0” name=”lrp”>claims</launch:phase>
S:        <launch:phase avail=”1” name=”open”>claims</launch:phase>
S:        <launch:phase avail=”1”>claims</launch:phase>
S:      </launch:pd>
S:      <launch:pd>
S:        <launch:name>domain2.example</launch:name>
S:        <launch:phase avail=”0”>sunrise</launch:phase>
S:        <launch:phase avail=”0” name=”lrp”>claims</launch:phase>
S:        <launch:phase avail=”0” name=”open”>claims</launch:phase>
S:        <launch:phase avail=”0”>claims</launch:phase>
S:      </launch:pd>
S:      <launch:pd>
S:        <launch:name>domain3.example</launch:name>
S:        <launch:phase avail=”1”>sunrise</launch:phase>
S:        <launch:phase avail=”1” name=”lrp”>claims</launch:phase>
S:        <launch:phase avail=”1” name=”open”>claims</launch:phase>
S:        <launch:phase avail=”1”>claims</launch:phase>
S:      </launch:pd>
S:     </launch:chkData>
S:    </extension>
S:    <trID>
S:     <clTRID>ABC-12345</clTRID>
S:     <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>
 
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.         
 
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

On 8/4/17, 7:19 AM, "regext on behalf of Thomas Corte" <[email-masked] on behalf of [email-masked]> wrote:

    James,

    

    
    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Thomas Corte <[email-masked]>
Date: Mon, 7 Aug 2017 11:22:23 +0200

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 7 Aug 2017 15:18:30 +0000

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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

    James,

    
    
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?  

    

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.  

    
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.       

    
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.  

    

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

---

From: Thomas Corte <[email-masked]>
Date: Mon, 7 Aug 2017 17:57:35 +0200

James,

On 07/08/2017 17:18, Gould, James wrote:

> ... 

I can see the reasoning behind this outreach, though personally I
wouldn't subscribe to a strictly "democratic" approach with regard to
this topic (or any technical decision for that matter).

For example, in my experience as a registrar client developer, many
registries' EPP servers don't properly handle XML namespaces (in that
they're requiring clients to use the specific namespace prefixes used in
the RFC examples, but don't allow arbitrary other prefixes).
Other registries' EPP servers do occasionally send EPP responses that
violate the EPP schemas.
While these are clearly violations of the relevant specs, someone might
argue that EPP clients not using the "standard" XML namespace prefixes,
or EPP clients actively validating EPP responses against the schemas,
represent "corner cases" not worth supporting.
Needless to say, I wouldn't agree.

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

Sure, but no command is "lightweight" from the server's perspective if it
has to be sent multiple times to achieve its goal.

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

In our use case, we simply modeled the concept of "premium" domain names
around launch phases. For each category of premium domain names, a launch
phase exists in which only the names from the category are available.
So here it's strictly policy (i.e., the lists or premium names in each
category) that determines a name's availability in a launch phase, not
whether or not the name already exists, or which data is passed along
with the registration.

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Mon, 7 Aug 2017 16:25:50 +0000

Hi Thomas,

Are the premium names only available in the General Availability phase or are they available in Landrush or any other early access phases?

Thanks,
Jody Kolker

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

James,

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

I can see the reasoning behind this outreach, though personally I wouldn't subscribe to a strictly "democratic" approach with regard to this topic (or any technical decision for that matter).

For example, in my experience as a registrar client developer, many registries' EPP servers don't properly handle XML namespaces (in that they're requiring clients to use the specific namespace prefixes used in the RFC examples, but don't allow arbitrary other prefixes).
Other registries' EPP servers do occasionally send EPP responses that violate the EPP schemas.
While these are clearly violations of the relevant specs, someone might argue that EPP clients not using the "standard" XML namespace prefixes, or EPP clients actively validating EPP responses against the schemas, represent "corner cases" not worth supporting.
Needless to say, I wouldn't agree.

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

Sure, but no command is "lightweight" from the server's perspective if it has to be sent multiple times to achieve its goal.

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

In our use case, we simply modeled the concept of "premium" domain names around launch phases. For each category of premium domain names, a launch phase exists in which only the names from the category are available.
So here it's strictly policy (i.e., the lists or premium names in each
category) that determines a name's availability in a launch phase, not whether or not the name already exists, or which data is passed along with the registration.

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Mon, 7 Aug 2017 16:27:02 +0000

Also -

<<

In this paragraph, it sounds like the domain:create command does not need a fee to be sent into create the premium domain.  It only needs the correct phase?  Is that correct?

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

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

James,

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Mon, 7 Aug 2017 16:29:25 +0000

Sorry for the spread out questions.

Thomas - In your implementation, is the premium phase specified in the "phase" attribute or in the "subphase" attribute?

Thanks,
Jody Kolker

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

James,

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Mon, 7 Aug 2017 18:35:23 +0200

Hello Jody,

> Are the premium names only available in the General Availability phase or are they available in Landrush or any other early access phases?

One of our TLDs offered premium names during the "claims" phase, which
was essentially accomplished by using sub-phases of "claims" representing
the respective premium category.
Similar solutions are possible in "landrush" or "sunrise".

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Mon, 7 Aug 2017 18:45:55 +0200

Hello Jody,

> In this paragraph, it sounds like the domain:create command does not need a fee to be sent into create the premium domain.  It only needs the correct phase?  Is that correct?

Yes, requiring registrars to specify the correct phase was exactly our
approach to preventing the accidental registration of expensive names.

It seemed like a natural solution at the time - the fee extension didn't
seem mature (and widespread) enough to be used, and launch phases allowed
us to essentially introduce domain/tariff categories without the need for
yet another proprietary extension, which we're trying to avoid as much as
possible.

Later, when the fee extension seemed suitable, we added it as an
*alternative* to the launch phase extension. I.e., a registrar can now
*either* provide the correct phase *or* supply the expected fees (or
both). Yet with the latest changes to the fee extension, our server can
no longer truthfully report correct fees since the registrar would have
to know the right phase up front, creating a chicken-egg problem.

> In your implementation, is the premium phase specified in the "phase" attribute or in the "subphase" attribute?

Both approaches are possible, entirely "custom" phases or sub-phases of a
standard phase.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: Roger D Carney <[email-masked]>
Date: Mon, 7 Aug 2017 16:50:40 +0000

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:[email-masked]] On Behalf Of Gould, James
Sent: Monday, August 07, 2017 10:19 AM
To: Thomas Corte <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [regext] TLD Phase Discovery

Thomas,

Thanks,

—

JG

James Gould

Distinguished Engineer

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

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

    James,

    at some point.

    Best regards,

    Thomas

    --

    D-44227 Dortmund                       E-Mail: [email-masked]<mailto:[email-masked]>

    Germany

    regext mailing list

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

regext mailing list

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

---

From: Roger D Carney <[email-masked]>
Date: Mon, 7 Aug 2017 16:50:49 +0000

Good Morning,

Thomas, I think the Fee draft can handle your use case of using launch phase for premium names (a premium string is only available in one phase/subphase combination so if client does not pass phase you should return that one valid combination). Can you provide examples where it does not work?

Thanks

Roger

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

James,

Best regards,

Thomas

--

Germany

regext mailing list

---

From: Jody Kolker <[email-masked]>
Date: Mon, 7 Aug 2017 16:53:42 +0000

Thanks Thomas.

Comments below - JWK.

Thanks,
Jody Kolker

-----Original Message-----
From: Thomas Corte [mailto:[email-masked]] 
Sent: Monday, August 07, 2017 11:46 AM
To: Jody Kolker <[email-masked]>; Gould, James <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [regext] TLD Phase Discovery

Hello Jody,

> In this paragraph, it sounds like the domain:create command does not need a fee to be sent into create the premium domain.  It only needs the correct phase?  Is that correct?

Yes, requiring registrars to specify the correct phase was exactly our approach to preventing the accidental registration of expensive names.

It seemed like a natural solution at the time - the fee extension didn't seem mature (and widespread) enough to be used, and launch phases allowed us to essentially introduce domain/tariff categories without the need for yet another proprietary extension, which we're trying to avoid as much as possible.

Later, when the fee extension seemed suitable, we added it as an
*alternative* to the launch phase extension. I.e., a registrar can now
*either* provide the correct phase *or* supply the expected fees (or both). Yet with the latest changes to the fee extension, our server can no longer truthfully report correct fees since the registrar would have to know the right phase up front, creating a chicken-egg problem.
---  JWK
When a domain is sold to a customer, a check command is sent first to determine the availability.  That check command can be sent without any phase attributes.  
According to the spec when this is done the phase that is currently active would be returned in the response.  
The returned phase would then be used for the create command, resolving the chicken and egg problem, unless I'm missing something (entirely possible).

Does that sound correct?
--- JWK

> In your implementation, is the premium phase specified in the "phase" attribute or in the "subphase" attribute?

Both approaches are possible, entirely "custom" phases or sub-phases of a standard phase.

Best regards,

Thomas

                                 Registereintrag:

                                 Geschäftsführer:

---

From: "Gould, James" <[email-masked]>
Date: Mon, 7 Aug 2017 18:55:18 +0000

Thomas, 

Use of the phase and sub-phase as a mechanism for clients to indicate fee or domain grouping categories was not the intent in draft-ietf-regext-launchphase.  At the IETF-98 REGEXT WG meeting it was unclear when there would be overlapping launch phases.  The launch phase and sub-phase is meant to cover the launch of the TLD itself, where your overlapping phases does not apply to the TLD but to groups of domains within the TLD.  I believe use of draft-ietf-regext-epp-fees is the appropriate path forward for the grouping of premium domains and not use of phases and sub-phases in draft-ietf-regext-launchphase.  If you fully transition to leverage draft-ietf-regext-epp-fees for premium domain grouping, do you have any need for overlapping launch phases in draft-ietf-regext-launchphase, and if so please describe why?

Thanks,   
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/7/17, 12:45 PM, "Thomas Corte" <[email-masked]> wrote:

    Hello Jody,

    

    

    Best regards,
    
    Thomas

    
                                     Registereintrag:
    
                                     Geschäftsführer:

---

From: Thomas Corte <[email-masked]>
Date: Tue, 8 Aug 2017 10:52:21 +0200

Hello Jody,

> The returned phase would then be used for the create command, resolving the chicken and egg problem, unless I'm missing something (entirely possible).

Not sure whether you're referring to the launch phase or the fee
extension, but I don't think that either of them has a solution:

- The availabilty check form in the launch phase extension doesn't
  explicitly allow omitting the launch phase in the check command.
  While the XSD allows it syntactically, that case isn't covered in
  the description. Also, even if it was allowed, the check *response*
  as defined in the XSD only allows a single launch phase to be returned
  (and not one per checked domain domain, which would be needed here).

- The latest fee extension draft explicitly states that, in case no
  phase is specified but multiple ones are active, the
  server MUST respond with an error. However, in our concept,
  multiple phases are technically active at all times,
  so returning the right phase instead wouldn't be feasible.

  The only way out I'd see in this case would be a less strict
  interpretation of "active" phase: a phase is "active" if the
  domain name in question is available in that phase. However,
  this seems a bit of a stretch to me.

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Tue, 8 Aug 2017 10:55:48 +0200

Hello Roger,

On 2017-08-07 18:50, Roger D Carney wrote:

> Good Morning,
> 
> Thomas, I think the Fee draft can handle your use case of using launch
> phase for premium names (a premium string is only available in one
> phase/subphase combination so if client does not pass phase you should
> return that one valid combination). Can you provide examples where it
> does not work?

See my previous response to Jody: strictly interpreting the fee
extension, we would not be allowed to return the right phase/subphase
combination, since, technically, multiple phases are continually active
at the same time in our model.
However (and I'm warming up to the idea), interpreting the "active"
attribute as *specific to a particular domain name* (rather than as a
general term) would indeed make it feasible.

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Tue, 8 Aug 2017 11:11:24 +0200

Hello James,

On 2017-08-07 20:55, Gould, James wrote:

> Use of the phase and sub-phase as a mechanism for clients to indicate
> fee or domain grouping categories was not the intent in
> draft-ietf-regext-launchphase.  At the IETF-98 REGEXT WG meeting it
> was unclear when there would be overlapping launch phases.

I think that the launch phase draft itself provides a use case. One of
the examples for the availability check form contains the custom phase
name "idn-release", which most likely refers to a registry introducing a
new set of IDN tables (which may happen years after the TLD initially
launched), making new domains available which were previously not
available, potentially at a different price and most likely with a
different registration model, i.e. as applications rather than immediate
registrations. Such an "idn-release" phase would most likely be run in
parallel to a (perpetually running) "open" phase for ordinary domain names.

> The launch
> phase and sub-phase is meant to cover the launch of the TLD itself,
> where your overlapping phases does not apply to the TLD but to groups
> of domains within the TLD.

The IDN rollout depicted above contains a use case (which as obviously
anticipated by the launch phase draft authors) where groups of domains
are available in different phases.

> I believe use of
> draft-ietf-regext-epp-fees is the appropriate path forward for the
> grouping of premium domains and not use of phases and sub-phases in
> draft-ietf-regext-launchphase.  If you fully transition to leverage
> draft-ietf-regext-epp-fees for premium domain grouping, do you have
> any need for overlapping launch phases in
> draft-ietf-regext-launchphase, and if so please describe why?

A need for overlapping launch phases might always arise, see above.
Also, nowhere in the launch phase extension draft has the use of
overlapping launch phases been excluded or forbidden. On the contrary,
at one point it is explicitly mentioned that "Domain names may be made
available only in unique launch phases, whilst remaining unavailable for
 concurrent launch phases.".

Of course, a "phase-agnostic" implementation of premium domain names is
possible and can indeed be accomplished with the fee extension as it is
currently drafted.
That said, the refactoring efforts involved to migrate a registry system
like ours which has been designed in a phase-centric way are
non-negligible. As it currently stands, I'd rather try to stretch the
interpretation of the launch phase/fee extension specs in order to make
them work with our model if need be. That's why I'd rather see the specs
offering a clean solution for our model than forcing us to work around them.

Best regards,

Thomas

---

From: "Gould, James" <[email-masked]>
Date: Tue, 8 Aug 2017 14:25:41 +0000

Thomas,

My feedback is provided below “JG-“.  

Overall, I believe that “phase-agnostic” premium domain names is not a model that draft-ietf-regext-launchphase is designed for or should be designed for.  My recommendation is to focus on how draft-ietf-regext-epp-fees can meet your needs for premium domain names without coupling it with launch phases as an alternative for fee classifications.   
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/8/17, 5:11 AM, "regext on behalf of Thomas Corte" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

    

JG- draft-ietf-regext-launchphase does support multiple launch phases in sequence or in parallel to meet the needs of launching a TLD, but what you describe is not a launch phase by releasing previously reserved domain names (e.g., “idn-release”).  There are many approaches that can be taken for the releasing of reserved domain names and I don’t see defining a parallel custom launch phase to the open launch phase as an effective one.  Someone could attempt to morph the releasing of reserved domain names into a launch phase, but it is not what draft-ietf-regext-launchphase was designed for. 

JG-The launch phases fundamentally define the registration flow that is expected of the client, so it is cross-cutting for a TLD that does not work well for a subset of domain names. 

    
    
JG-I agree that there may be a use case where a domain name may be available in only specific launch phases, but it is a corner case that is already supported by draft-ietf-regext-epp-fees.  I don’t believe that “phase-agnostic” premium domain names is a model that draft-ietf-regext-launchphase is designed for or should be designed for.  My recommendation is to focus on how draft-ietf-regext-epp-fees can meet your needs for premium domain names without coupling it with launch phases as an alternative for fee classifications.   

    Best regards,
    
    Thomas

---

From: Thomas Corte <[email-masked]>
Date: Tue, 8 Aug 2017 17:41:16 +0200

James,

On 2017-08-08 16:25, Gould, James wrote:

> Overall, I believe that “phase-agnostic” premium domain names is not
> a model that draft-ietf-regext-launchphase is designed for or should
> be designed for.

I assume you mean "phase-aware". By "phase-agnostic", I meant the
opposite, i.e. the model you're proposing - premium domains which are
not connected to or dependent on launch phases.

> My recommendation is to focus on how
> draft-ietf-regext-epp-fees can meet your needs for premium domain
> names without coupling it with launch phases as an alternative for
> fee classifications.

As said in a previous e-mail, a complete refactoring of our premium
model seems prohibitively expensive at this juncture, since all our
tariff management, promotion infrastructure, registration policy engine
code etc. is closely tied to launch phases. We might be able to still
retain our use of the fee extension, if only by completely hiding any
launch phase related data from it, even if the system still works with
launch phases under the hood.
If all else fails, we can always use a proprietary extension.

Still, and this is going back to the original topic of phase discovery:
if it was clearly (as I demonstrated out in a previous e-mail) the
intention of the launch phase extension authors to allow multiple phases
at the same time, and to make certain domain names only available in
certain phases, why should we make it so hard for registrars to discover
the right phase for their domain?
Why not offer a "phase-avail" check form to discover the phase in which
a domain is available, rather than forcing *all* registrars to code
their own iteration of <check>s over all known (for some definition of
"known") launch phases to discover it?

Best regards,

Thomas

                                 Registereintrag:

                                 Geschäftsführer:

---

From: "Gould, James" <[email-masked]>
Date: Fri, 11 Aug 2017 17:27:37 +0000

Thomas,

Yes, I really meant “phase-aware” premium domain names.  Launch phases in draft-ietf-regext-launchphase are associated with the TLD and launch phases are not meant to be a method of grouping domain names like premium domain names.  I view overlapping launch phases as a corner case that is already handled by draft-ietf-regext-launchphase.  The availability of domain names by phase is already handled by draft-ietf-regext-launchphase with the Availability Check Form, which may not be optimized for your use case but does handle the intended purpose of draft-ietf-regext-launchphase.  Considering these points, I don’t believe that adding a Phase Availability Check Form is warranted.  If there is additional interest in adding a Phase Availability Check Form to draft-ietf-regext-launchphase by the working group, please share it publically on the list or privately.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/8/17, 11:41 AM, "regext on behalf of Thomas Corte" <[email-masked] on behalf of [email-masked]> wrote:

    James,

    

    
    Best regards,
    
    Thomas

    
                                     Registereintrag:
    
                                     Geschäftsführer:

---

From: Thomas Corte <[email-masked]>
Date: Mon, 14 Aug 2017 14:34:20 +0200

James,

On 2017-08-11 19:27, Gould, James wrote:

> launch phases are not meant to be a method of grouping domain
> names like premium domain names.

Says who? As I pointed out in previous e-mails, the launch phase
extension spec's wording

  "Domain names may be made available
   only in unique launch phases, whilst remaining unavailable for
   concurrent launch phases."

clearly suggests otherwise.

Aside from premium domain names, there are other examples where such a
grouping may be necessary, such as when phases are used to introduce new
IDN tables, or to make certain names available only to certain eligible
registrants when a TLD is first launched.
Determining the right phase for a name with a single EPP command should
be possible in such scenarios.

> I view overlapping launch phases as
> a corner case that is already handled by
> draft-ietf-regext-launchphase.

It is, but obviously not in a way that's satisfactory for registrars or
registries. Trial-and-error probing for the right phase isn't a solution
I'd deem suitable.

Best regards,

Thomas