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

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 10 Jul 2020 11:48:02 +0200

Hello,

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

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

Another clarifying question: the above only needs to happen if the client
at least signaled its general understanding of the fee-1.0 extension in
the EPP <login> command, correct?

Otherwise (i.e., if the server needs to report premiums as unavailable
even to clients who are not aware of fee-1.0), this RFC would be asking
for a change in a server's behavior just by virtue of introducing support
for fee-1.0, which would mean that clients not using any fee extension
(or an older version which didn't yet have this requirement) would see an
unexpected code-breaking change, no?

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: Mon, 13 Jul 2020 19:46:39 +0000

Thomas, 

Signaling support for fee-1.0 in the login services is not material for this use case.  The key element is whether the create of the premium domain name will fail if the client does not know the correct fee and the fee extension is required to be passed on create.  I don't see a code breakage scenario here, but I don't know what mix of extensions you're dealing with.  
  
-- 
 
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 7/10/20, 5:48 AM, "regext on behalf of Thomas Corte (TANGO support)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    

    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1XzwM8MKi6M1-HWG_c8XsyUrX-tt-VgbAlfTCUGb9Lx3MPgi6UDluTdlcRJFP7royaFdSgSNGny3bfC_scy0lFWmNl2_VVRop-NJI7XZAzEB1O09cQoiuiWOf9SYkj1kOJgngNMpWzGKkNFu2Lq7fRoaaJuKQ-dMEeX6ea3dw76nsG7kwWiPr5kvbge0cv48mJ2SaTaGuPbv5QK-_UsaJLuvPu58h3fo0Q3TqOm2Pj_lwO3Bi490P_YnBubP0klINpMjZwVB12xL3FsXgxjU9vQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 14 Jul 2020 11:52:14 +0200

James,

> Signaling support for fee-1.0 in the login services is not material for this use case.  The key element is whether the create of the premium domain name will fail if the client does not know the co…

So, case in point: once we roll out support for fee-1.0, TANGO will also
keep supporting the older fee extension versions fee-0.8, fee-0.21 and
fee-0.23 (the RFC recommends to allow older versions to facilitate
migration to new versions).

Now, none of these old versions had the requirement to report "domain not
available" if no fee extension is included in a premium domain check.

So, registrars currently using fee-0.21 for example will expect
availability checks to truthfully report avail=1 for premium domains in
such a scenario. Just the fact that the registry system was updated to
also support fee-1.0 should not change the system's behavior from their
point of view, should it? Otherwise, they would be forced to change their
<domain:check> clients to include the fee extension to get the previous
availability results - to accommodate a change caused by a fee extension
version they don't even use.

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: Tue, 14 Jul 2020 12:01:28 +0000

Thomas,

The versions of the fee extension that you reference have similar language associated with returning avail="0" for premium domains:

1. fee-0.23 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-08#section-4
2. fee-0.21 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-05#section-4
 
In both cases it reads:

   The server MUST return avail="0" in its response to a <check> command
   for any domain name 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 domain name.

The very old fee-0.8 version specifies in https://tools.ietf.org/html/draft-brown-epp-fees-05#section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this extension must be used.", which provides flexibility for the server to normalize the behavior as defined in draft-ietf-regext-epp-fees-05, draft-ietf-regext-epp-fees-08, and RFC 8748.  

This use case was discussed at length in the working group, where returning a premium domain name as available without the required fee to use on create will result in a failure downstream.  This is the reason for the language starting in draft-ietf-regext-epp-fees-04.     

Thanks,

-- 
 
JG

James Gould
Fellow Engineer

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

On 7/14/20, 5:52 AM, "regext on behalf of Thomas Corte (TANGO support)" <[email-masked] on behalf of [email-masked]> wrote:

    James,

    

    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1tS78h3zvnAPOtomCdUHVDM7D17WfX22p7Pd6zVlMsgS7lzILKOFXHeNh8Isr52cCXcvBSyQkAjKy5zjYK_vBbzpvnNtdI0R5NVrFQzRfv8jgv9C-99xdcmRQKwkeUqvWb4lnu8Tw8WH4t_lgA2ZF8VF4zgoPcDVKXKjN7HgN1owdVTlosmxBYewNDGlYXWIXhTuj4owNa0-n7d-SrGRBiT1FzRcNuu_UpoGGAx_fcq6fRKp8O3O3l_i7I9UzKI0fDJ2m4-Zj8evpLArNgCwbUuU_H8ynwmD9WouiD4aDy68/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 14 Jul 2020 14:26:25 +0200

Hello James,

>    domain <create> command when no <fee> extension is provided for that

Ok, thanks for pointing this out - looks as if we missed this addition
when we upgraded our system from the older versions we had supported
previously.

> The very old fee-0.8 version specifies in https://tools.ietf.org/html/draft-brown-epp-fees-05#section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this ex…

Sure, it provides flexibility, but a registry must still be wary about
the implications of any change in server behavior, even if the previous
behavior resulted from a wrong implementation. We'll need to take this
into consideration when altering the check results of our system where
legacy versions of the extension are used. Our fee-1.0 implementation
will for sure adhere to the language in the RFC.

By the way, you're right that fee-0.8 is very old, however you'd be
surprised that, for many registries, it is still the latest version they
will support, with some only supporting even *older* versions (like
fee-0.5 in the case of CentralNic).
This has led to the unpleasant situation that some bigger registrars who
want to avoid the effort of implementing newer versions even put pressure
on registries to introduce support for these older versions, as they
regard them as the established "de-facto" standard.

Based on this experience, I'm afraid it will take a long time until
fee-1.0 will be widely adopted by registries or registrars, if ever.

Best regards,

Thomas

---

From: "Gould, James" <[email-masked]>
Date: Tue, 14 Jul 2020 13:09:57 +0000

Thomas,

 >   fee-1.0 will be widely adopted by registries or registrars, if ever.

You bring up an interesting topic of the practice that we've been following with using pointed schema versions (e.g., 0.5, 0.8, 0.11) up until a draft completes WGLC, which then bumps the schema to 1.0.  In the past the schema versions were set to 1.0 and non-backward compatible changes were not isolated, which is fixed by the pointed version practice.  If servers and clients lock in on particular pointed versions, then it puts upgrading to the RFC version (1.0) at risk.  I hope that clients would apply pressure for servers to implement to the RFC once it's published, which should consolidate the implementations to a single version.  The pointed versions should be deprecated and removed over a period of time.  The timelines will differ based on server policy, but servers should be looking to implement to the RFC.  

-- 
 
JG

James Gould
Fellow Engineer

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

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

    Hello James,
    
    On 7/14/20 14:01, Gould, James wrote:
    
    > 1. fee-0.23 - https://secure-web.cisco.com/1kiROHoyjrP19LUExMku9rtxvisvx9NJMKw1wSLWwZCdjj5knAvCDts_hGetyd6bQENmggXNsIrgEHw8WCX68BU7IMZlk_v3dQ50AlcsDhXhknVr5eoFrR3JRBRH7won79Mya81Sr6LvWBgi540gAS1P-U_QN03xgFVCPXxui-KjDceHA2v6L7_PwOcyQAbFZJ4kCSbfGMGDWS1HXwY4I2dYYouKMPNXz_cV80CuvWtCojqr2pwqE5f6U2OcXAsqCC7_Fe09BvoSSo1LTXxdX4N2HvAKh_E8Krw7kx6OS_Ok/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-fees-08%23section-4
    > 2. fee-0.21 - https://secure-web.cisco.com/1Uq5JtRLa--5dKWQkUzCW6Q7PFEND_NYkXdPQTy_B5riLnQjvMInA41XD73paaLCRdHAK9OpjFUqhe3YYrSGy88F5R3J0CPx-ua_WapjtFDLSYyQGDooO78aCWKW0Ue2hnZ-PidSxKjbxc-IbCUisaVa8b-Fm0HkJqJizP2QL7OBE-534awcgbpuoyCmsjnOGtMazHEzk7TxbMVtsQ5E4RTxUf_p7XBTM-MS4JRO5iLrPjb7Psqwk0SH1SOKWeDKVvVVLcCXSzhx3DAaqbtQ-2LbBOyxADfVnrcXpu-DkgQM/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-fees-05%23section-4
    >  
    > In both cases it reads:
    > 

    > The very old fee-0.8 version specifies in https://secure-web.cisco.com/1QqHpNJJXZNFCGtsHrsi3YvVQeySWIrERGgDbIjZ0ryI7hw-1Qcjq5jUYfLMHJG3Gh0fC7SqgJgBa5LUPPZyv-Sd4yAIeV8d62sszDGnmFhlpNBN6J9DIO3zzeRg5CfjtWlcHycxaY8A7bXKM6_39O2cT8HmEtqOZu3IceTHwxF1ZsNFszUPXPxDlhkzOrhkp_4IO1s29UGdTVHTPGRHwWiDvYS9eIzB322EdVlwlsY8F884n8zVmlSjiOoBDdVme97R8f8cDEcsbJskDvyEeMYhyHElBOoiasNWIeaKXQq4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-brown-epp-fees-05%23section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this extension must be used.", which provides flexibility for the server to normalize the behavior as defined in draft-ietf-regext-epp-fees-05, draft-ietf-regext-epp-fees-08, and RFC 8748.  

    
    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/12H21mMcVVt1O6ED0owoA5ZrlZgxkwD7P1zR1V5ILRhQa2o75D6pcV_MU3VBS218gvQIVqAn_rD_uEvMmceNyc5SsqZY_-146kpe3W8ySEu59RQhcFMM7Z1h_O7G-6qW7As34yQt1F53ubsNKeWnsfw3qNu-XixlsNmupMoofqnYqHyddj4Jr4g7V-r_kNoeLkghMvyjnynXxlWg21q6LD3mxpLsG_Lvl5UOTUGWOTHPfMR_QIV9iiJ-ydb-bHDD-NR_LwFZYFJy2bU6qWTKb8fH9LIc-ecVDbJDnYPNW0As/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 14 Jul 2020 10:21:34 -0500

> fee-1.0 will be widely adopted by registries or registrars, if ever.

It was exactly the same situation when EPP was being specified, registries implemented it before epp-1.0 went out as an RFC, and it took several years for "EPP 0.7" to disappear (its most notable difference was on the transport part, where the frame didn't have the length prefixed).
But it did disappear finally, so not all hopes are lost :-)

It is a classical chicken and egg problem based on the fact that registries, once they got one version working have no or very little incentive to change (being similar as other registries is not a strong force for them) and for registrars as long as not all registries do the same thing they have anyway to code for the extra case and then once they done it for one registry they could as well use that for others. So for registries they have only one case to handle, where registrars have many but for registries each registrar is like any other, besides its market position eventually.

However, for a non trivial number of players in this game they are bound by contracts that
can basically force them to implement new standards after some given delay.
But that wouldn't apply for ccTLDs where each registry is king in its kingdom.

Besides market pressure, that has its limits here, I see only contractual forces able to move things around.

As for the technical level, I am not sure anything can be done. Even if you add in all drafts
something like "this draft version 0.971268413 MUST NOT be used after the RFC is published with version 1.0", it wouldn't prevent the current situation in practice (you would just have stronger text in the RFC to point implementors to).

Maintaining a public list of what each registries support (as a gentle nudge) may not help, nor something like https://github.com/dns-violations/
I would eye towards something close to TLS "Grease" framework, but I am really not sold that any technical solution can solve the problem there.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 14 Jul 2020 17:48:51 +0200

Hello,

> But that wouldn't apply for ccTLDs where each registry is king in its kingdom.

True, and even for gTLDs, there is no real pressure here since ICANN
doesn't seem to be particularly aware of the EPP fee extension (or care
about interoperability with regard to domain price tiers for that
matter). But that may (and should) change, of course.
> Besides market pressure, that has its limits here, I see only contractual forces able to move things around.

It could go a long way if some of the larger registries (Verisign,
Afilias, Neustar, CentralNic, Donuts) would care to implement the RFC
version *and* start to phase out the older versions with clear deadlines.

As long as they keep supporting ancient versions of the extension (or, in
the case of Donuts, use their own proprietary one), the larger registrars
will see no incentive to implement newer versions, and will in turn
pressure smaller registries into adding support for these ancient
versions (e.g. by threatening to otherwise not include their premium
domains in their portfolios).

Best regards,

Thomas

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 14 Jul 2020 11:12:33 -0500

> domains in their portfolios).

Can work both ways: registrars could in the same way put pressure on registries
to implement new version otherwise they can threat to stop selling their premium
names.
There are even various industry groups where such subject could be tackled on
non-technical aspects of it
(but then for "fee" it is a little more complicated because this is related to prices,
and various jurisdiction have laws prohibiting competitors to discuss in private
circles anything that could be related to price issues, in order to make sure the market
remains non-captive and really competitive).

But that is kind of shooting themselves in the foot if the registry does not go
forward (and the registrar really stop using the old version), as it would be for
a registry to stop providing an old version for real even if some of its smaller
registrars do not support the newest one.

Like BCP38, changes like that provide not null but minimum benefit to the actor
of the change, while it provides huge benefit to the whole ecosystem.
(the last one transitioning and finally removing the old version completely from
all systems may be even the one with the highest benefit to the community).

But in short, no one gets benefit of starting first.
Hence, outside forces need to come into play to tilt the current balance.

-- 
  Patrick Mevzek
  [email-masked]