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

[Thomas Corte (TANGO support)]

James,

On 7/13/20 21:46, Gould, James wrote:

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

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
 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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

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  command
   for any domain name in the  command that does not include the
extension for which the server would likewise fail a
   domain  command when no  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
jgo...@verisign.com 


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

Verisign.com 

On 7/14/20, 5:52 AM, "regext on behalf of Thomas Corte (TANGO support)" 
 wrote:

James,

On 7/13/20 21:46, Gould, James wrote:

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

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
 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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org

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


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

Hello James,

On 7/14/20 14:01, Gould, James wrote:

> 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  command
>for any domain name in the  command that does not include the
> extension for which the server would likewise fail a
>domain  command when no  extension is provided for that
>same domain name.

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

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

-- 
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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

Thomas,

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

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
jgo...@verisign.com 


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

Verisign.com 

On 7/14/20, 8:26 AM, "regext on behalf of Thomas Corte (TANGO support)" 
 wrote:

Hello James,

On 7/14/20 14:01, Gould, James wrote:

> 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://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 server MUST return avail="0" in its response to a  command
>for any domain name in the  command that does not include the
> extension for which the server would likewise fail a
>domain  command when no  extension is provided for that
>same domain name.

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

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

[regext] =?UTF-8?Q?Re:__RFC_8748, _EPP_Registry_Fee_Extension:_availabilit?= y check result depending on fee extension?

[Patrick Mevzek]

On Tue, Jul 14, 2020, at 07:26, Thomas Corte (TANGO support) wrote:

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

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

Hello,

On 7/14/20 17:21, Patrick Mevzek wrote:

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

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

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Patrick Mevzek]

On Tue, Jul 14, 2020, at 10:48, Thomas Corte (TANGO support) wrote:

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

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext