Subject: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Thu, 25 Jun 2020 19:32:53 +0200

Hello,

we're currently working on implementing RFC 8748 (EPP Registry Fee
Extension) in our registry system, and I just stumbled upon this
paragraph in section 4 (Server Handling of Fee Information):

   "The server MUST return avail="0" in its response to a <check> command
   for any object in the <check> command that does not include the
   <fee:check> extension where the server would fail a domain <create>
   command when no <fee> extension is provided for that same object."

If my interpretation of this is correct, this means that the server is
supposed to reply avail="0" in a <domain:check> response for all
available domains which do not have a standard price, i.e. which require
the acceptance of special fees via the fee extension on <domain:create>,
unless the client supplies (any?) fee extension in with the
<domain:check> command.

I admit that I missed this part even in older versions of the draft, so I
may be late to the party.
Anyhow, I wonder:

* Is it a good idea to simply claim that a name is not available,
  even though it actually *is* available (if the client is ready to pay
  the special price)?

* Which kind of fee check extension is sufficient to report the name
  as "available"? What if the registrar merely checks for a renewal
  price, but not for a create price?
  Should he still get avail="1", even though he may still be oblivious to
  the higher registration price?

I understand that this is maybe another attempt to protect registrars
from offering / registering premium names inadvertently, but is it the
right way to do this?

Fee-unaware registrars may lose business by reporting names as taken,
even though they may be able to register them manually for their
customers (without EPP) after determining the price out-of-band.
And requiring the fee extension in the transform commands for
non-standard prices should be protection enough against inadvertent
premium registrations.

Also, it seems somewhat questionable to affect the outcome of the plain
availability check depending on the presence of the fee extension.

Thoughts?

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
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: Thu, 25 Jun 2020 19:40:40 +0000

Thomas,

I provide responses to your questions embedded below.  

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

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

On 6/25/20, 1:33 PM, "regext on behalf of Thomas Corte (TANGO support)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    

    
JG - Yes, returning a name as not available is be compliant with the RFC.  

JG - The RFC only specifies that the fee extension needs to be provided to support the create command, so checking the renewal fee is not applicable.   

JG - Yes, returning a premium domain name as unavailable when the create will fail is the right way to do it.  

    
JG - There was much discussion around this use case in the working group.  

    Thoughts?
    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1v_YJ06qRdzwmH9Hkg036A-xEBGAaLOxurmipvITWVRFQeyYrMo0C4WbNqva3xaKZcf-i37NRcE9PBISmus8MMBTI9ZMNT9MdtBIiK7wx3eAp5SYV9cZ8nFrBm1ZIfqkduCE3pUYhPuy03eD0w9q4IyIptZBPS2MZ6gWecLS0zbc_3UjY92AFrLuIoldci7mUpZhFAW-PI-AjMLnLmPAYmWMSiIibsygbDVZdcSAZJtZGF0pK-12cQ1zChm4PaAUJ9GSvev_RhbBvNBgyKzFKOg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 26 Jun 2020 15:46:36 +0200

Hello James,

thanks for your reply, I'll go back to check out the respective thread.

> JG - The RFC only specifies that the fee extension needs to be provided to support the create command, so checking the renewal fee is not applicable.   

So, just to be sure, to the following check for a *renew* fee of a
premium domain, the server should respond with avail="0" (as the check
merely asks for a renewal price, not a creation price)?

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <command>
    <check>
      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>premium-a1.tango</domain:name>
      </domain:check>
    </check>
    <extension>
      <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
        <fee:command name="renew">
          <fee:period unit="y">1</fee:period>
        </fee:command>
      </fee:check>
    </extension>
    <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
  </command>
</epp>

While the following check asking for a creation price should be responded
with avail="1"?

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <command>
    <check>
      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>premium-a1.tango</domain:name>
      </domain:check>
    </check>
    <extension>
      <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
        <fee:command name="create">
          <fee:period unit="y">1</fee:period>
        </fee:command>
      </fee:check>
    </extension>
    <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
  </command>
</epp>

Just trying to clarify this, as the RFC isn't all that clear about which
exact conditions the fee check extension must meet in order to qualify
for a positive availability check of free premium domains.

Best regards,

Thomas

---

From: "Gould, James" <[email-masked]>
Date: Fri, 26 Jun 2020 14:18:18 +0000

Thomas,

The goal is to cover the case of a client not passing the fee extension at all, with the assumption that the fee extension would reference the create command.  It's simpler to make the case based on the existence or non-existence of the fee extension in the check command, but there may be cases were the renew fee matches the create fee.  It's up to the server to determine whether a particular domain will fail on create without the client having the correct non-standard fee.  I realize that there are corner cases where the client may know the fee, based on assuming that the create fee matches the renew fee, or the fees are provided out-of-band to EPP, but to cover the intent of the RFC the safest approach is to return avail="0" for a premium domain if the fee extension is not passed in the check command.

The server MUST return avail="0" in its response to a <check> command
for any object in the <check> command that does not include the
<fee:check> extension for which the server would likewise fail a
domain <create> command when no <fee> extension is provided for that
same object. 

-- 
 
JG

James Gould
Fellow Engineer

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

On 6/26/20, 9:46 AM, "regext on behalf of Thomas Corte (TANGO support)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

    

    

    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1d4W9Y-JRwUyOsQ5LPwv-1m17UOtveZT4o2_R0VWZfpbiTqJanWb6E-ksO15h7ClxoQY3q9NGnpriFo71j-Jz3SWN4WQcemobVYCyNQp3gp_mAdwxpm-wlzqcs8vUSfe2t-A7ZIYAlHo9X9Bx1otNjXIk8Zq-YRdB6RWikXkuNjOFtRnO2RX89P5ciZ5jM7_thR1kE8aILbzhJMq0uWRyPbLAFIAf3ZOwPH5IZ4oUskSUB4se2h6c4ZgbpfMzl0P0ZPvKG2RzjnF3PXa-m62nDg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 26 Jun 2020 16:41:26 +0200

Hello James,

On 6/26/20 16:18, Gould, James wrote:

> but to cover the intent of the RFC the safest approach is to return avail="0" for a premium domain if the fee extension is not passed in the check command.

In my example, the fee extension was passed, but only asking for the
*renew* fee (which may be standard), not for the *create* fee (which may
be non-standard). Based on your answer above, the server would have to
return avail=1" then (because *some* fee extension was passed), however
the client would still be unaware that the create fee is non-standard.

If the "safest approach" is the goal here, it would probably be better
(albeit indeed more implementation effort) to not only require the fee
extension, but to specifically require the fee extension checking the
"create" price, no?

In this case, the RFC text may need a clarification, as it currently
doesn't reflect such a specific requirement. I'm aware this is a rare
corner case, but still one that should be covered.

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, 26 Jun 2020 14:46:56 +0000

Thomas,

Yes, to cover the corner case, avail="0" is the best response when the client does not include "create" in the fee extension of the check command of a premium domain name.  Without knowing the create fee of the premium, the create will likely fail, thus avail="0" is the correct answer.  The intent of the language in the RFC was to cover the broader case of a client that doesn't pass the fee extension at all in the check command, but your corner case is applicable.    

-- 
 
JG

James Gould
Fellow Engineer

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

On 6/26/20, 10:41 AM, "Thomas Corte (TANGO support)" <[email-masked]> wrote:

    Hello James,

    

    
    Best regards,
    
    Thomas

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 26 Jun 2020 08:15:47 -0700

@Tomas  I could see someone submitting a non-conforming fee extension in
the check command to trick the registry into providing basic availability
or taken of a name.

Possible: perhaps
Probable: unlikely

You make a good point that the respective command, especially billable
events, should perhaps check that the appropriate fee extension was sent.
Depending upon the registry implementation, this could theoretically work,
but a registrar would still have to pay the respective registry designated
fee for a create/renew/transfer,

I am working very hard to imagine why someone would go to the trouble of
sending the wrong fee extension with a command if they were going to be
sending one at all.

Jothan Frakes

On Fri, Jun 26, 2020 at 7:47 AM Gould, James <jgould=
[email-masked]> wrote:

> Thomas,
>
> Yes, to cover the corner case, avail="0" is the best response when the
> client does not include "create" in the fee extension of the check command
> of a premium domain name.  Without knowing the create fee of the premium,
> the create will likely fail, thus avail="0" is the correct answer.  The
> intent of the language in the RFC was to cover the broader case of a client
> that doesn't pass the fee extension at all in the check command, but your
> corner case is applicable.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> [email-masked]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
>     > but to cover the intent of the RFC the safest approach is to return
> avail="0" for a premium domain if the fee extension is not passed in the
> check command.
>
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 26 Jun 2020 17:24:02 +0200

Hello Jothan,

On 6/26/20 17:15, Jothan Frakes wrote:

> events, should perhaps check that the appropriate fee extension was
> sent.  Depending upon the registry implementation, this could
> theoretically work, but a registrar would still have to pay the
> respective registry designated fee for a create/renew/transfer,   

Sure, the subsequent domain create attempt would still fail if the wrong
command was sent in the extension, even if the availability check was
"tricked" into confirming availability.

> sending the wrong fee extension with a command if they were going to be

Agreed, it's more work to get this wrong than right. We'll go with the
John's lax interpretation in our implementation and will report avail="1"
for premium names as long as the check command contains *any* fee
extension whatsoever.

Best regards,

Thomas