ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-vi-feb10] J-Team, some comments

  • To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] J-Team, some comments
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 06 Apr 2010 16:56:46 -0400

Jeff,

I'm sure you have, I simply didn't see them, in fact, I didn't see
anything that spoke to the publication path as being subject to any
policy issue.

fooDNS, the DNS provider for .foo, which may, or may not do rapid
update, receives the information delta from the .foo registry either
every couple of clock ticks, per entry, or every couple of hours, in
bulk, and at each partial sync of state between the .foo database and
fooDNS's preparation of, or simple publication of a .foo registry
produced zonefile, fooDNS has more knowledge about the state of all
registrations in the .foo zone than any other registrar. In particular
it has all published knowlege from all registrars which have
provisioned the .foo zone since the last state sync event.

Since the construction of an address or rate throttle agile whois
mining system is trivial, fooDNS may as well be assumed to have, only
seconds behind any zone published data, the contact data, term of
registration, ... data, there really is little "knowledge" which .foo
holds, which fooDNS can not obtain within a very short interval of delay.

How, if something provides a substantive portion of the registry
service, can we ensure no covert economic advantage accrues if that
thing is also a registrar for the registry?

More generally, going back to the original CORE SRS of the late 90s,
when we came up with a system of mutual distrust as the basis for a
shared registry system, how are we building a better system with
all-but-one mutual distrust?

Eric



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy