Re: Lists and EPP

Jothan, I think you are right on the spot!

   Patrik

On 9 jun 2011, at 02.42, Jothan Frakes wrote:

> 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