Re: Lists and EPP

[email protected]
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.