Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type

From: Patrick Mevzek <[email-masked]>
Date: Sat, 2 Jul 2011 18:44:26 +0200

Patrik Fältström <[email-masked]> 2011-06-17 12:10
> When you do transfer of a domain, what happens with the host and contact objects that are bound to the domain? What notifications are sent, and what actions have to be taken?
> 
> I think, even though we have 200+ different business models, I claim those can be implemented with only say 3-5 different ways of doing transfer.
 
I mostly agree with this.

> > It might be better to approach this from a different direction. How about defining a standard set of registry transactions -- create/delete/modify objects, renew and transfer a domain name, etc -- and writing this up as a BCP? Once that's done, the BCP could be encoded in a standard test suite. In other words, document what it is that's to be tested before developing a test suite. Some tests might be optional (for instance IDN and DNSSEC might not be deployed in places) while others are mandatory.
> 
> I fully support this. And is implicitly what I am asking for. That registries try to, before they invent their own epp architecture, look carefully at if they can not reuse what someone else is doing.

I would suggest before that to make sure that each registry document
and publish (eventually up to an IETF Informative RFC) their
extensions.
So that we would have a "catalogue" of what is happening on the field.

However this purely technical hope is severly constrained by an
economic one: each registry taken independantly has no
financial/economical/technical interest in redoing things that work
today but using another extension (so the current fragmentation has
little hope to be resolved), and even documenting it clearly and
publishing it outside of their registrars circle (and this is indeed
one example of response I got when I query registries for their
technical details as an EPP implementor but not an accredited
registrar with them).
And I do not see, since it is not a purely technical issue in the
hands of IETF, how to "convince" people to correct this situation.

So, Patrick, I agree with you, registries should "try to" see what exists
already before reinventing the wheel, but how to achieve that? I
honestly have no idea while still believing it is a worthwile goal.
Maybe registrars (as a group) + independant implementors should try to
raise their voice together...

As for the new ones with the new gTLDs, the smartest ones (those
having read Michele excellent recent post on CircleID for example) will make
sure to lower the technical differences as much as possible, and reuse
existing extensions (but back to square one: they have to be published
and well known beforehand). Others will either need anyway to create
new extension based on their own needs (and there it could go wrong
in many ways... I'm not sure there are many prospective gTLDs
operators being here, but I hope being wrong), or would argue they can
do things better/differently and then create a new extension for
something already done by some current registries.

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 2 Jul 2011 18:52:25 +0200

Hello Keith,

Keith Gaughan <[email-masked]> 2011-06-16 18:26
> This is the first in a series of suggestions from a registrar's point of view
> improvements that can be made to and around EPP to make the life of registrars
> easier. Consider them food for thought if nothing else.
 
At least personnally I welcome your initiative and wish that other
registrars participate here and do the same.

> A standard EPP test suite from OT&E would, I think, serve two important
> purposes. Firstly, it would be an immense help to registrar who are
> developing their domain management systems for the first time as not all of
> us use Net::DRI for Perl or EPP-RTK for Java and C++. Ours, for instance, is
> written in a combination of Python and PHP. Secondly, it would mean that
> registrars would only need to run through the test suite *once*, which would
> greatly reduce the management overhead for both registrars and registries
> during accreditation. A central registry, likely maintained by ICANN, listing
> whether a registrar has successfully completed a particular part of the test
> suite, would also be useful.
 
I'm not sure this suits ICANN mandate or role. I even fear it would
complicate the system.

However, I also agree with Klaus and Wil: current accreditation tests
are *worthless* and I would say even *dangerous*.

They mandate to do things specifically forbidden in EPP (such as
syntax of some elements outside accepted values), and seem to concentrate in detail with some
arcane parts that almost never appear in production.

Obviously, not all registry certification tests are equal, some are more
worthless than others :-)

End results (and it's not an hypothesis, I have direct personal proof
of that): registrars build (or buy) a quick custom script that send to
the registries the rubbish they wait for, and pass the accreditation
test without problems. It has no bearing on what they will really use in production,
meaning it would be something completely different. So the tests in
that case do not verify anything... except maybe the registry own
systems :-)

There are also some registries that also accepts tests even if
not 100% passed.

So I'm not against certification tests per se, as I believe they could
fulfill an useful role of making sure that registrars technical team
EPP knowledge level is raised up an acceptable level, before having it
in production, and through the support channel. Again, as a personal
direct observation, many calls to registry support people are tied
with some very basic questions such as "how to do a connection from
language X" (when X is not included in registries SDK) or "how to
setup my SSL certificate".

But technical tests as they are done today are a burden without actual
benefits.
Back in ICANN 2010 Brussels, I've proposed the idea of having a
cross-registry EPP test suite
(
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/index.html#slide19
)
that could be done in such a way that it works for both directions,
and may also solve part of the problem raised here by Keith in another
thread, such as the registry policies for various operations.
And following Jim's idea there, it could be done as a BCP.

What also seems to me more important is mandating the registries to have a
working OT&E system well used during upgrades with enough advance
warnings and documentations on new/changed extensions.

I would also suppose that the first registrars of the new gTLDs will
be current registrars, meaning they obviously already have a working
EPP implementation. Forcing them to pass new certification tests would
be a loss of time, except if they are limited to each registry
specific parts and new extensions.

-- 
Patrick Mevzek

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Sun, 3 Jul 2011 05:51:19 +0200

> honestly have no idea while still believing it is a worthwile goal.

We can not police, but IETF can help by "stop being so nice" and ack that two registries that require ANY change in the registrar epp implementation are NOT interoperable. If just that is known, we are in a better situation.

> raise their voice together...

I think/hope that is what is now happening? ;-)

   Patrik - tired of all non-interoperable registry inventions in epp

---

From: Patrik Wallstrom <[email-masked]>
Date: Mon, 4 Jul 2011 12:07:24 +0200

> We can not police, but IETF can help by "stop being so nice" and ack that two registries that require ANY change in the registrar epp implementation are NOT interoperable. If just that is known, we…

That would be very hard for the IETF to do for a protocol that the IETF claims to be extensible, right? If you want protocols that can be policed like that, at least that word should not be in the name of the standard. :)

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Mon, 4 Jul 2011 12:20:03 +0200

> That would be very hard for the IETF to do for a protocol that the IETF claims to be extensible, right? If you want protocols that can be policed like that, at least that word should not be in the…

Absolutely correct!

As I have said before, I was the area director and because of that somewhat responsible when epp was standardized. I did then not envision what problems would arise.

   Patrik

---

From: Theo Kramer <[email-masked]>
Date: Mon, 4 Jul 2011 13:41:35 +0200

>   Patrik - tired of all non-interoperable registry inventions in epp

The OASIS ebCPPA protocol defines a mechanism for trading partners to implement a collaborative business process by defining a collaboration profile. Perhaps such an approach could be investigated for EPP Registries and Registrars to formalize interoperability with the formal collaboration profiles registered with ICANN or IETF ...

-- 
Regards
Theo