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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Dec 2008 08:29:13 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, December 15, 2008 11:58 PM
> To: Hollenbeck, Scott; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Standards Track Advancement Request for EPP RFCs
> 
> Apologies for taking far too long to review this in detail.
> 
> I've had several discussions about where to set the bar for 
> advancement to full standard status.  RFC 2026 does have this 
> statement:
> 
>    A specification for which significant implementation and 
> successful operational
>    experience has been obtained may be elevated to the 
> Internet Standard level. An
>    Internet Standard (which may simply be referred to as a 
> Standard) is characterized
>    by a high degree of technical maturity and by a generally 
> held belief that the
>    specified protocol or service provides significant benefit 
> to the Internet community.
> 
> I believe the implementation report fully covers the first 
> sentence.  I would want an answer for the second sentence 
> before going forward with this
> -- certainly domain registration is a significant benefit to 
> the Internet community, so to answer this question, I'd like 
> a rough idea about how often this protocol is used in 
> production between vendors for domain registration.  Do you 
> have any information on that?

Depends on what you mean by "how often".  It's used for several million
transactions per day between VeriSign and registrars managing .com and
.net domains.  I don't have direct access to production stats for other
registry operators, so I'd like to ask others to speak up here as
appropriate.

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.

> Beyond that, I think the bar should be set very high before 
> permitting _changes_ during the advancement from draft to 
> full standard.  After talking with other parties, I suspect 
> that while my concerns about TLS would improve the quality of 
> the specification, they are not something I feel the IESG 
> should force an author/WG change during this advancement 
> (it's something I would strongly favor for republication at 
> proposed or draft, however).
> 
> I don't feel any of the normative references are 
> inappropriate for an RFC
> 3967 downward reference.
> 
> 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.
> 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?

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Dec 2008 10:09:09 -0500

Scott,

I admire your patience over advancing this.

NeuStar has been using EPP for a long time, in a lot of ways, and 
reliably for our domain name registry business.  We have even already 
implemented the DNSSEC extensions and whatever extensions have been 
needed for our business model.

When I talk to other registry operators, EPP is nearly always 
mentioned.  Operators have been and still are converting to it.  I 
don't think the RIRs have but just about all TLD operators I have 
come across use it.

Registry operators tend not to document this nor issue reports 
measuring this.  Other tasks take precedence.

Regarding the options - I've never run into any issue with the 
original spec, I doubt that we have updated anything for quite a 
while.  (We did add DNSSEC extensions and some others, but nothing 
touching the base.)  So I don't have a real opinion on the needed 
changes.  (As in I don't think/know of anything [is] needed.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 18 Dec 2008 17:03:57 +0100

Hi Scott,

Yes, this worth some compliments.

    When I talk to other registry operators, EPP is nearly always
    mentioned.  Operators have been and still are converting to it.
    I don't think the RIRs have but just about all TLD operators I
    have come across use it.

Yes, and it is too bad that they don't. There is an opportunity to
learn from ech other experience here. And since the registry operators
do have to document and explain these to their registrars anyway,
the extra effort shouldn't be that much, at least, that's what I
think.

    Regarding the options - I've never run into any issue with the
    original spec, I doubt that we have updated anything for quite
    a while.  (We did add DNSSEC extensions and some others, but
    nothing touching the base.)  So I don't have a real opinion on
    the needed changes.  (As in I don't think/know of anything [is]
    needed.)

I'm pretty neutral to the options as well. I always thought that
during advancing a document removing (unused) material was not a
real problem but changing and or adding material, other then updating
references, is close to a no-no, so I would go for the easier one
(1 or 2) to keep the processes going. But there are likely people
way better versed in IETF process to see what the risk there is for
advancing these RFCs.

	jaap

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 18 Dec 2008 17:45:09 +0100

Jaap Akkerhuis <[email-masked]> 2008-12-18 17:24
> Yes, this worth some compliments.
 
Count me too.

> the extra effort shouldn't be that much, at least, that's what I

If I can again share my experience on this as a third party EPP client implementor,
some registries are very hostile even in providing their
documentation (describing their local EPP extensions).
Some explain that their local registrar market is very competitive
and they fear to be criticized.
However, most of the time the documentation is public or at least can
be available upon request (but I did not hear back from .NL for
example :-)).
As for building their EPP extension it seems that most registry did
it in house, and not always putting their own registrars in the loop
and working with them. It happens with some registries, but
definitively not all of them.
As for OT&E access to test interoperability it is almost impossible
(there are some nice exceptions) to have one if you are not a
registrar in the relevant TLD. Speaking as for myself I would love to
test interoperability with all EPP registries, but of course I can't
be a registrar in all of them.

If anyone has any idea to change that, I sure would like to hear and
help.

And as I can see by the very low response to my other thread about my
draft, there does not seem to be a lot of interest among registries
to collaborate, share their experiences, and build things together. I
could understand that for gTLDs that would say there are under a
competitive market, but I do not understand that at all for ccTLDs.
Maybe (probably) I'm not using the correct form and channels to
propagate this idea.

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 18 Dec 2008 18:18:53 +0100

Hollenbeck, Scott <[email-masked]> 2008-12-18 16:16
> 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)

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

>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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 Dec 2008 16:04:00 +0100

On Thu, Dec 18, 2008 at 05:45:09PM +0100,
 Patrick Mevzek <[email-masked]> wrote 
 a message of 52 lines which said:

> And as I can see by the very low response to my other thread about
> my draft, there does not seem to be a lot of interest among
> registries to collaborate, share their experiences, and build things
> together.

Hold on! I've read it, I was planning to comment on it but it was
posted only nine days ago and there were other things to do during
this time...