Re: Lists and EPP

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