The recent IETF 112 saw several discussions among participants pertaining to the domain name world. One of those was the Registration Protocols Extensions (REGEXT) session on 10 November, and here Antoin Verschuren from Liberty Global explains what was discussed, why more of our European ccTLD registries should get involved in the work of the IETF as well as his background and what led him to becoming interested in the work of the IETF.
CENTR: What is your background?
Antoin Verschuren: I started my career working with several ISPs, starting back in 1994, mainly doing technical system administration like IP address management and domain name registrations, as well as other provisioning management. I was involved with RIPE, ICANN and IETF.
Then I worked for SIDN, the .nl registry and CENTR member for 10 years, as a technology and policy advisor and heavily involved in DNS and DNSSEC development, as well as technical DNS policy and provisioning processes.
The DNSSEC work got me more involved in security, and I enlarged my security work working for the Dutch Ministry of Defence for 3 years, and now I am working at a tier-1 ISP again doing Network Hygiene, so basically BGP and DNS security as part of the World Economic Forum Cyber Security Principles for Internet Service Providers and MANRS (Mutually Agreed Norms for Routing Security).
CENTR: What is your work that led you to becoming involved in the IETF?
AV: The development of EPP back in 1998 for me was my first involvement with the IETF work. Since I was working at a registrar at that moment, I read some proposals for EPP that didn’t match my experience as a registrar at that time. The people involved were mostly (gTLD) registries, and I believed that they did not understand the concept ownership of glue records when EPP was being proposed.
Later when I worked for SIDN, I was also involved in DNS, DNSSEC, ENUM, and RDAP development.
CENTR: Why did you become interested in the IETF?
AV: As a technical person, you know about the RFC standards for Internet protocols. I wanted to automate most of the provisioning processes and found that this new EPP standard was being developed. The reason I noticed was because of an incident at the time when I wanted to register new name servers with Network Solutions for a gTLD registration, and found they were already administratively registered and basically hijacked by one of our clients, even though the names and machines were ours. I thought that was unfair and shouldn’t have happened. So I got involved in the proposals for EPP because I wanted to prevent the same mistake happening again.
CENTR: What was the significance of the REGEXT session at IETF 112 for ccTLDs?
AV: For IETF 112, the focus was mainly on technical adjustments to RDAP to be able to accommodate new ICANN regulations for gTLDs, standardisation of terminology for registry-registrar interactions like reporting or maintenance, and the standard use of internationalised email addresses in EPP for domain name registrations.
CENTR: Why should ccTLDs (or even gTLDs) get involved in the REGEXT working group?
AV: The REGEXT WG focusses on the EPP and RDAP protocols and registry-registrar interactions. Basically, all the interactions between a registry and registrar (and sometimes registrant). If you want an addition or adjustments to those protocols, then you end up in the REGEXT WG to standardise your extension. If you are a registry or registrar and you want to be compliant with your registrars or peers, then you should know the latest adjustments to the protocols and make sure your requirements are taken into account when somebody else proposes a new extension. This is especially important for ccTLD registries, because most of the standardisation is proposed by large (ICANN) gTLD registries or registrars that sometimes forget that the protocols should remain compatible with ccTLDs, RIRs and other “registries in general”. We could certainly use the experience and insight from registries that use EPP and RDAP that are not biased by the ICANN processes and procedures to avoid that a technical protocol specification is mixed with (local) policy.