Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Wallstrom <[e-mail]>]

On 09 Mar 2014, at 13:19, Patrik Fältström <[e-mail]> wrote:

> On 2014-03-09 10:19, Patrik Wallstrom wrote:
>> But the fact is that EPP is several magnitudes better harmonized
>> between TLDs compared to that registrars are offering their
>> customers. There is no way around that today, and the registrars have
>> no incentive at all to improve the situation. For all the registrars
>> to offer the same API to their customers would really remove the
>> lock-in effect that the proprietary interfaces that they have today.
> 
> The same lock-in as registries use already today with registrars.

No, it is not the same lock-in.

> My point is that there is absolutely no difference between how
> registries lock in registrars (and because of that the registrants) and
> how the registrars lock in customers.

Yes, there is. Let me explain how.

Registries are using variants of the same protocol, EPP. Registries are typically serving exactly one name space. And this is where the lock-in  for the registrar come in - there are no other registries that serve the same name space.

Registrars are not using the same protocol, if any, as anybody else at all. They typically serve multiple name spaces. The large registrars have most of the name spaces available.

> Harmonizing the interface to registrars is _extremely_hard_ given how
> different the epp implementation is for the registries. The registrars
> that "lock in" (using your terminology) the registrants do that mainly
> because they support a specific flavor of registries, and have designed
> their API for those registries. If other registries where to be
> supported, the API would be different.

I totally agree with your description of the registrars interface, and this was my main point.

Since I have looked in more detail on many registrar interfaces, they typically do not resemble each other in any way at all. They all serve different purposes.

1. Manage domains (register or delete domains).
2. Manage wallets (to see their invoices, refill accounts).
3. Update zone content (unusual).
4. Manage web sites.
5. Manage web site content.
6. Manage virtual private servers (VPS).
7. Update DNSSEC material (extremely unusual).

These are also all mixed up, so there is no interface that covers all of it, some choose only one or two of the things in the list, with any combination they choose.

The API:s are also implemented in a variety of flavours as well, XMP-RPC, REST, SOAP and whatever they can come up with.

This also makes it extremely difficult (on a whole other level compared to registrars talking to registries) for a registrant to move their automated interaction with one registrar to another registrar.

>> So how could we change this? I don’t see this happening from a
>> standard organization at all. So yes - registrars is really a big
>> reason for incompatibility. Registries could easily bypass the
>> current rrr model by exposing API:s directly to registrants, but it
>> wouldn’t be very popular with the registrars…
> 
> In no particular order:
> 
> 1. By having people stop claiming epp is one protocol and blaming the
> registrars being the problem. Pointing fingers does not help, because as
> in this thread, energy has to be spent on explaining the differences in
> epp between TLDs.

Yes. Nobody is pointing any fingers here. And this is all good work.

> 2. By having registries agreeing on whether DS or DNSKEY is the data
> they want, or by accepting both.

It seems that this is not going to happen.

> 3. By having the IETF effort of to start with cataloging the epp
> extensions used by registries, and secondly working hard to try to
> harmonize the extensions.

This is what the eppext wg is doing now.

> 4. By having the registrars that have an API harmonize their efforts
> just like registries harmonize theirs.

Have you, as a registrar, put any effort into this? Where do you suggest this work is going to take place?

An “interesting" idea would be having ICANN to implement the base of this as part of the RAA.

> Also: note that registries do sent the wholesale price for the domain
> registration, and the price on the market today for domain names is set
> by the ones that cross subsidize domain name costs with income from
> other services. Because of that there is a price squeeze which in some
> markets turn into negative revenue for registrars that sell domain
> names. Registries that now and then dump the wholesale prices does not
> make the situation better, as the end users start to believe the price
> is very low. Registrars complain on this behavior by registries, but the
> registries continue to do price dumping -- i.e. continue the price squeeze.
> 
> Given this pricing structure, and that registries do change their
> implementations far too often, where do you think registrars do spend
> the money they have? They MUST support what the changes the registries
> do, they do not HAVE TO implement a common API.

Well, registries have made registrars do DNSSEC before. So if we would actually try to describe a standardised interface for the registrars, there could be ways to make the registrars implement this new interface. Pressure from customers, registrars and ICANN combined, perhaps?

> So, the registries MUST be the ones that start. Although there are many
> registrars that will follow. Including Frobbit that I am technical lead at.
> 
> Now as I wrote above, IETF have started some very good work on epp
> extensions but I am amazed how many registries refuse to participate,
> complain, and fight against it. As long as they do, why should
> registrars be nice(r)?
> 
> The market is broken, and as I said, I think we in IETF (when I was Area
> Director btw) where too nice when the whole epp work took place.

There are way more problems for a registrar to implement EPP for the different registries than the extensions. You know that as well.

Registries have different policies regarding what names are allowed, how different objects are actually used, and different ways of handling expired domains. And this is already within the defined standard without any extensions.