Re: Lists and EPP

In a practical sense, I think that the point Jim raised about the
impact of GoDaddy requesting their .COM list is one that has a scaling
concern.  Registries have a web or ftp portal for the reports and
materials that are not going to flow through the EPP system in its
current form.   There's also zone file access and ICANN reports or
other types of integrations or systems that a registry operates that
are isolated from the EPP system because they can be generated from
read-only or reporting snapshots of the databases and not adversely
impact the fluidity and pace of responses to the rest of the users.

There are simply some things that are more wisely served out of band.

With respect to the implementation variance on EPP that I've witnessed
over the years...   It seems to me that no matter what, there will be
different implementations.

I'd like to drop in the comment that while this is a technical
discussion, we should be mindful that it not be so clinical a
discussion that we arrive at something obtuse to meeting the need of
the user.  I'd infer that the registrar is the user here.

A registrar wants to clone as much code and deal with as little delta
or re-write as possible, so that they can quickly put a TLD in place
and make sure their customer can renew and manage their domain name.
This is an area that the incumbent registries have some significant
advantage over new ones.  If someone's already tied into Afilias for
.info or .org, or Neustar for .biz or .co, there's a lot less of a
scope to adding another TLD at that registry as opposed to some new
setup.

ccTLDs are trying to conform to EPP (predominantly this is to have
wider adoption in the ICANN registrar world), but they're stuffing
their implementations with each of their policy/business logic.
Sometimes it is an obtuse fit.  This pertains to expiry, grace
periods, registrant validation, or other areas of delta that exist (ie
Nominet is 2y units (vs 1y) add/renew with max 2 year (vs 10y max)).
Each has its own flavor.  Some registries like DE offer monthly
domains.

I am not suggesting that EPP is as good as it will ever get, but
wherever we collectively can make provisioning for registrars as
consistent and seamless across as many implementations as possible, I
think we'd have the reasonable grounds to claim some victory.

My basis for recommendation of  'simplimentation' is the 201X newTLD
round.  We're about to start to see an onslaught of articles where
registrars are going to talk about how they can only assimilate 1 TLD
per month or perhaps 3 in 2 months.  Registrars are also going to have
to make pragmatic choices about a variety of factors like the
integration time and weigh that against anticipated demand or other
factors when they plan out what TLD in what order.  In the presence of
the alleged thundering herd of TLDs, registrars will have to pick and
choose.

For a newco registry service provider that has fewer institutional
registrar integrations, the more conformity to other existing
implementations means the ability to tick the box next to 'can re-use
existing code' - and this dissolves resistance points that can leave
the TLD(s) on your platform sitting patiently awaiting integration
while other more simple ones are getting quickly added at registrars.

I realize this sounds more like it came from the sales or business
development lines than the technical side of the house, but it really
is and will be an important factor that should be considered.

-Jothan




On Wed, Jun 8, 2011 at 2:40 PM,  <[email protected]> wrote:
>
> [resent, moderator feel free to ignore prior version from an alternate
>  mailbox.]
>
>> I dare to say that as I as Area Director when epp was invented could
>> have pushed back more, but I did not. So I blame myself.
>
> Before you blame yourself, the fundamental choices were never available
> to the ADs to alter -- XML as the syntax, client-server as the event
> model, with the universe of communication restricted to registrars and
> a registry, in a design univers of 6 registries and 60 registrars.
>
> However, if you're inviting blame for errors as AD, your personal
> decision to prevent XML-over-SMTP meant that a lot of registries and
> registrars in cc-land, where the 3pm drop never presents a race
> condition, had a transport predicate you thought necessary and I thought
> unnecessary.
>
> If Harald is around he can take the blame for his binary valued "do
> not publish" mechanism as a putatively useful alternative to data
> collection policy announcements.
>
> With no criticism to Scott, the importance of the VGRS inventory to the
> ICANN registrars really made any design choices that attempted to extend
> the 6+60 model were doomed.
>
> We didn't get:
>        o containers, so glops of contact, host and domain data
> could be flushed in either direction;
>        o symmetric event model, so regsitries could notify registrars
> of things like "your hair is on fire", other than via polling;
>        o generalization of the endpoints, so escrow could be implemented
> via EPP;
>        o generalization of the endpoints, so registrars could proxy to
> accredited registrars for registries they lack accreditation (cause the
> world was com/net/org/biz/info/foo) via EPP;
>        o (and this is not a criticism of anything to time and tech) the
> means to elegantly exend the XML syntax (the "X" is over-rated);
>
> I'm sure I've forgotten many things that are useful for some notion of
> how a provisioning protocl that doesn't have the 6+60/C-S/tcp/race model
> set of restrictions.
>
> And mistakes are normal, so this isn't a harsh criticism, but the set
> of pre-IETF constraints has had consequences, and may have more consequences
> as the model grows beyond 6+60 to more 3166 parties and all the 201x new
> adds.
>
> Eric
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg