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

["Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>]

Good question and sorry for my shorthand response before.  In my proposal the 
only restrictions are within the TLD.
Jeffrey J. Neuman, Esq.
Vice President, Law & Policy
NeuStar, Inc.
Jeff.Neuman@xxxxxxxxxxx



----- Original Message -----
From: Tim Ruiz <tim@xxxxxxxxxxx>
To: Neuman, Jeff
Cc: 'randruff@xxxxxxxxxxxxxxx' <randruff@xxxxxxxxxxxxxxx>; 
'Gnso-vi-feb10@xxxxxxxxx' <Gnso-vi-feb10@xxxxxxxxx>; 'ebw@xxxxxxxxxxxxxxxxxxxx' 
<ebw@xxxxxxxxxxxxxxxxxxxx>
Sent: Tue Apr 06 19:37:15 2010
Subject: RE: [gnso-vi-feb10] J-Team, some comments

> If the RSP is affiliated with the Registry Operator...
> the RSP may not be a registrar.

At all, or just for that gTLD? 

Tim

-------- Original Message --------
Subject: Re: [gnso-vi-feb10] J-Team, some comments
From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
Date: Tue, April 06, 2010 4:03 pm
To: "'ebw@xxxxxxxxxxxxxxxxxxxx'" <ebw@xxxxxxxxxxxxxxxxxxxx>
Cc: "'randruff@xxxxxxxxxxxxxxx'" <randruff@xxxxxxxxxxxxxxx>, 
"'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>


Eric,

My language addresses this. If the RSP is affiliated with the Registry
Operator as in your example, the RSP may not be a registrar. If the RSP
is not affiliated with the Registry Operator, there are strict
separation requirements if the RSP has an affiliate is a registrar,
subject to audits and sanctions as well as data use restrictions.

The other 2 proposals do not address this.
Jeffrey J. Neuman, Esq.
Vice President, Law & Policy
NeuStar, Inc.
Jeff.Neuman@xxxxxxxxxxx



----- Original Message -----
From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
To: Neuman, Jeff
Cc: 'randruff@xxxxxxxxxxxxxxx' <randruff@xxxxxxxxxxxxxxx>;
'Gnso-vi-feb10@xxxxxxxxx' <Gnso-vi-feb10@xxxxxxxxx>
Sent: Tue Apr 06 16:56:46 2010
Subject: Re: [gnso-vi-feb10] J-Team, some comments

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