Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs

[Patrick Mevzek <provreg@contact.dotandco.com>]

Hollenbeck, Scott <shollenbeck@verisign.com> 2008-12-18 16:16
> If you're asking about overall adoption, I know that it's used by all of
> the gTLD operators (it's an ICANN requirement) and many ccTLD operators.
> Patrick Mevzek recently reported on recent deployments here:
> 
> http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair
> o-ccnso-techday-200811.html
> 
> Sorry if the URL gets broken across two lines.
 
If that can help, from my software, here are some registries using EPP,
sometimes alongside other ancillary protocols, and sometimes still in
the process of deploying it (sorry in advance for any error).

aero
fr re (being currently deployed)
ag
si (being currently deployed)
asia
at
au
be
biz
br
bz
cat
la
cx
gs
tl
ki
ms
mu
nf
ht
na
coop
cz
eu
hn
i.3.4.e164.arpa (Infrastructure Enum in Austria)
info
lc
lu
me
mn
mobi
name
uk
no (being currently deployed)
nu
org
pl (over HTTPS)
pro
pt
sc
se
ch
li
travel
us
vc
com
net
cc
tv
jobs

There is also:
es (over HTTPS)
cn
tw
im
cl
ac
sh
io
tm
in

And I'm sure I've forgotten some...

From the ICANN Caïro meeting I can see that even some "small" ccTLD
operator are now interested to provide EPP to their registrars (since
most registrars are registering in multiple TLDs, it makes sense for
them to consolidate their protocols and so it make sense for a
registry to suit them).

In short there is a massive move towards EPP (we may already have
crossed the top of the curve), and no move in the opposite direction
(past critics of EPP, specifically in ccTLDs, have changed their
minds or at least agreed to move towards EPP)

> > 1. Move RFC 4930-4934 to full standard without change.  I am 
> > willing to attempt this, although it's less likely to pass 
> > IETF last call than the other options due to the obsolescence 
> > of some of the normative references.
> > 
> > 2. Republish with only references updated.  This will require 
> > somewhat less use of the RFC 3967 procedures and make improve 
> > the odds of a successful last call.
> > 
> > 3. Republish with references updated and operational 
> > clarifications; primarily documenting the TLS practices that 
> > have been used in practice to interoperate.  I recognize 
> > there is some risk that the new TLS practices text will not 
> > be correct, which is why I've decided I'm willing to let this 
> > issue pass for a draft->full advancement.  IMHO, the problem 
> > should have been noticed and fixed when advancing to draft so 
> > any errata could be applied when advancing to full.  We 
> > missed the window where it was most appropriate to fix that 
> > sort of problem, so we shouldn't hold advancement hostage 
> > over the issue, IMHO.  I can't promise my the rest of the 
> > IESG will agree, but that's my opinion.
> > 
> > So the steps to advance are:
> > 
> > A. Provide data for the "significant benefit to the Internet" 
> > litmus test. 
> > I'll need to
> >    defend this before the IESG.

Besides the number of TLDs/domain names managed through/with EPP,
some quick ideas:
- native support for IPv6 in hostnames (was added only late in RRP,
see RFC3632)
- use of XML hence Unicode hence native support for any kind of IDNs
(if the unicode string version need to be passed during the exchange,
without any encoding)
- support of ENUM provision
- support of DNSSEC provision
- extensibility to cater for needs of current and future TLDs
- standardization on an « EPP authcode » needed for domain name
transfers, being adopted by more and more TLDs, this simplifies the
life of registrants (the merit of this use can be discussed, but at
least it is starting to be uniform in multiple TLDs)

> > B. Choose option 1-3, publish revised I-Ds as appropriate C. 
> > It would be very helpful to provide candidate RFC 3967 text 
> > for the last call notice.
> > 
> > and I'll take it forward from there.
> 
> I'm open to either option 2 or 3.  What do others think?

From an implementor point of view again, TLS is not a problem for EPP
deployment, I mean besides just knowing if the registry verify the
client certificate and if so which client certificates issuers the
registry accept, that it is enough to fullfill RFC4934 (EPP over
TCP).
It is far more complicated to enable the interoperability on the
protocol level, taking into account each registry EPP extensions and
various tweaks in namespaces, ordering, result codes, etc.

So I would favor option 2, or after that option 3, so that not too
much time is used for TLS which is not a big issue for EPP in my
mind.

-- 
Patrick Mevzek