Re: ".au" registry technical specification

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Bruce,

> Note section 2.2, where a new registry/registrar protocol is proposed on the
> basis that
>	the barriers are too high for registrars to use EPP,

2.2 General guidence on barriers to entry, I didn't find the specific
reference to EPP. The same general guidence should be offered to the
registry operator, see also 2.2 item (a). A "competitive" requirement
(a mechanism to meet the theoretical technical requirements of a pool
of registrars, e.g., the 70+ ICANN registrars) may be sufficient to be
a barrier to entry for a proposed registry operator. The technical bar
to entry (and of negative utility where registrant scale is << 10^^5)
is independent of the business issues posed by "competitive" requirements,
which may also be sufficient to be a barrier to entry for a proposed
registry operator.

It is hard to imagine a registry with 10^^3 registrants adopting EPP.
It becomes possible to imagine when the registrant volume is 10^^4.

My assumption is that the .biz registry will have an registrant volume
of 10^^6 -- scale-equivalence with the RRP registries.

Various proposals have been commented upon in this list as having the same
general undesirable characteristic mentioned in this general guidance para,
of being awkward for ICANN registrars, or undesirably complex. A personal
list is transport other than TLS/TCP, asynchronous processing, inheritance
derivations as metaobjects, and metadata. This list is non-exhaustive.

Nominally, some of these proposals could lower the point at which transition
to EPP is economically and technically feasible. Other conceivable proposals,
e.g., transport over SMTP, would lower the transition point.

I'm glad to see that AUNIC and Nominet use SMTP as transport. That was were
we (Crocker, Wesson, Gaetano, Brunner, et al) started at the Orlando IETF BoF
on an SRS -- that SMTP was manditory to implement, if the protocol was to be
of IAHC-general, not ICANN-gTLD, utility.

The consequence of forming a collaborative party restricted to persons or
entities with current or current-year RRP scale-equivalence holdings and/or
expectations, is that the "industry standard" product narrowly reflects the
interests of its creators.

Broadly, the question could be does EPP scale, down not up, from the sweet
spot of RRP scale-equivalence, for registries, and for registrars?

>	and there are no open implementations of EPP available.

2.2 item (e).

An interesting issue. EPP RTKs are available, there is the .info one in java,
the .name one in C++, ours, and possibly others. These contain an EPP client,
in various implementation specific forms (*nix, Win, C++, java), but not the
EPP server, a data base or data base interface, a whois server, and any other
bits that comprise a registry.

My take on the way this issue is posed in the report is that until there is
a server (grotty dbms or dbms interface bits included) implementation that
is "public domain" (or open or reasonably licensed), this issue isn't solved
as far as the Competition Panel (George Michaelson ???) is concerned.

> If it is too hard to implement the IETF standard there will be little take
> up outside a few gtlds.

I agree, and don't view solving contract problems, or competitive problems,
as being a reason for the IETF to form a working group.

Milage varies.

Eric