In June this year, we at IIS arranged a workshop about managing the proliferation of EPP extensions, with members from the registrar community and also registry operators. This is a short recap of what was said – and some suggestions on which direction we should take in the future.
Sorry for the bad pun, but yes I’m a Star Trek nerd and could not help it.
One of the big problems in the registry/registrar business today is the Proliferation of EPP extensions that exists.
And it is expanding now when we have all the new gTLD’s coming online.
Epp Extension Registry
The day started with Scott Hollenbeck from Verisign. He described a bit about the process when he created the EPP protocol, and the design philosophies behind it. One of the goals was that it had to be extensible as they did not know all things at the time, and it should be possible to extend it.
But the problem up until today is that we early adopters of the EPP protocol did it in a kind of vacuum, and we came up with our own extensions, sometime just different implementations of the same information that was needed.
Scott Hollenbeck then continued on with a presentation of the new EPP Extension Registry and RFC7451. This is the new way for us registries to send in our EPP extensions and have IANA publish them in a centralized way. After this he also went through a bit about the EPPEXT working group in IETF and described what they are doing there.
Epp IDN Extensions summary from new gTLD program testing
After Scott we had Einar Lönn from IIS on stage, doing a short presentation about the findings we have done about the EPP extensions and what we need for testing the new gTLD program. And we have found (so far) only eleven EPP IDN extensions, and in the first eight months of 2014 we only saw seven different IDN extensions, and 75% of those where the ietf-idn extension.
EPP from a registrar perspective
Next on the list of presenters was Jimmy Bergman from Atomia, which is a software developer that sells a registrar system and has multiple customers using all kind of registries for business. He has a lot of experience with different registries extensions.
One of his points is that EPP extensions is only part of the problem, and the facts that different registries are using different local policies is even a greater problem.
During the discussion there was pointed out that there is an Extension the will help with a lot of this and it’s the Registry Mapping Extension.
EPPEXT (EPP Extension Working Group)
After a coffee break we went through the EPP Extension Working Group and the extensions that they were discussing. The first extension is the draft-ietf-eppext-idnmap-02.
One of the problems with the current version of this drafts is that the table is just being specified by a name (like ‘es’ in the example). And this is a problem. Again you have to go to the registry and ask what they are accepting.
The next one that was discussed was the draft-ietf-eppext-keyrelay-04.
The extensions solves the problem of transferring a DNSSEC signed domain between registrars. The problem is that the key material has to be transferred. And most time the registrars do not have a secure channel between each other to transfer this, but they do have a secure channel to the registry. This extension allows the key materials to be sent between registrars through the registry. This is something we will see more often now when the adoption of DNSSEC increases. And we need to fix it now, before it becomes a too big a problem.
The third extension is the draft-ietf-eppext-launchphase-05.
It’s primarily designed to facilitate sunrise periods of new domains, and is kind of a mandatory one for the new gTLD program. But AFNIC informed that they were using it for handling blocked domains, as you can use it to send and AUTH Code with the create domains message.
And the next extension is the draft-ietf-eppext-tmch-smd-01.
This extension also has much to do with the new gTLD program. Mostly with the trademark clearing house problem. When registering a domain during the sunrise period you have to provide information about why the registrant are entitled to the domain (trademark, court order , treaty or other) and this extension both give you to possibility for transmitting that kind of information. There is also a signed version that works by having ICANN sign a key for the clearing house keys so that we have a chain of trust for this. Fortunately Gustavo Lozano from ICANN was with us and as he was the author for this draft he could explain it well to us.
After this Scott Hollenbeck showed us some extensions that might get into the EPPEXT working group. The first one is the draft-brown-epp-fees-04.
This extensions tries to solve the problem with signalling cost for a domain registration. And again, one of the problem is that there are four versions out there that registries are using, and that also makes it a bit harder for registrars to implement it.
The last extension we talked about was draft-gould-change-poll-02.
This extension is extending the Poll message with information about the changes that takes place outside of control of the registrar. As an example, when a registry deletes a domain due to not renewing.
Register you extension
This was all we went through during the day, and the most prominent thing that Scott tried to send with us was to Register your extensions, and I am glad to say that we at IIS already have registered our iis extension and that it’s now up at the Extension registry.
Extensions for the EPP – https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml
EPPEXT Working Group – http://datatracker.ietf.org/wg/eppext/documents/
Recording of the Workshop – https://www.youtube.com/watch?v=U_VEa6uCFO8