<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>As someone who uses this information to put people in prison, it
is not as useless as you may think it is even when it's
"incorrect", or for that matter "whois privacy protected".<br>
</p>
<br>
<div class="moz-cite-prefix">On 7/5/2016 4:08 AM, Volker Greimann
wrote:<br>
</div>
<blockquote
cite="mid:bc3898bf-ef51-0417-c25c-6498f596ff2e@key-systems.net"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Ultimately, everyone accessing the internet can be identified
at the level of the access provider. The domain name is probably
the most useless point to identify a user, as the domain name
registrant may not even have to do anything with a specific use.
<br>
</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 04.07.2016 um 19:25 schrieb
Stephanie Perrin:<br>
</div>
<blockquote
cite="mid:9eff015d-403f-b7f7-ecfe-04b2800bc9ef@mail.utoronto.ca"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p><font size="+1"><font face="Lucida Grande">One point here,
and it is not a big one. I don't accept that accuracy is
a sine qua non (see para 5). Contactability is, I think
it ends there. Excessive focus on accuracy of data, when
that data is not necessary any more is a cost and consumer
burden, not to mention an invasion of privacy. (eg. if I
have changed my mastercard number but my registration is
paid for two years, no need to change it in the record) <br>
</font></font></p>
<p><font size="+1"><font face="Lucida Grande">I did not comment
earlier on Volker's remark that responsibility for
accuracy of data rests with the registrant, but I agree
whole heartedly. How can it be otherwise? Some parties
would like to authenticate every individual and every
transaction on the INternet, and see the registrars as the
entry point and therefore the logical ones to bear this
(enormous) burden. </font></font><font size="+1"><font
face="Lucida Grande"><font size="+1"><font face="Lucida
Grande">This is unnecessary and will price domains out
of the range of individuals who can benefit most from
their own place on the Internet, in my view. </font></font>
It would hardly be appropriate for the policy person to
point out that in any authentication scheme, identifying
the individual in the first place (prior to tying that
individual to some identifier) is a big, costly and
complex matter that has slowed down many an implementation
of secure transactions. We need to limit our attempts to
identify individuals to only what is necessary.</font></font></p>
<p><br>
</p>
<font size="+1">Stephanie Perrin<br>
PS I wish I had taken better notes on the whole thick/thin
whois issue during EWG. Since it took me a good while to
figure out how this thing had developed in the first place,
(and many thanks to my EWG colleagues who patiently explained
it to me over and over again) I may have missed an invitation
to throw it out and discuss it again from scratch.....but I
doubt it. Anyway, we were already talking about tiered access
by then and different configurations of the model which would
make it much less relevant.<br>
</font>
<div class="moz-cite-prefix"><font size="+1">On 2016-07-04
12:22, Carlton Samuels wrote:</font><br>
</div>
<blockquote
cite="mid:CAOZQb9T+p9T8ZLtSKzYJqjBfCkSUXN2Y+SSN1fpOZqLVpA7+xg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">Coming to
this conversation late but as a member of the EWG, my
recollection is we took seriously the stated objective
to chart a next generation RDDS unfettered by existing
WHOIS constraints.</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">To that
end, I was one of those who insisted and the group
accepted and grappled with the basic question; was there
a need for a RDDS and, to what purpose. For those
mindful of the ALAC perspective, this would not be new;
the ALAC is on record from as early as 2009 insisting
that for policy development purposes, the need and
purpose for a RDDS ought, by reason and judgment, to be
the first declarative act of any policy development
process. You would have seen a reprise of that
principle here. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">We were
acutely aware that some principles we espoused are
contrary by nature - privacy vs. security, transparency
vs. confidentiality and so on - and that balancing the
scale between contention sets of principles was not
going to be for the faint-hearted. Some time ago I used
a metaphor to describe what was achieved; we set out to
design and build a sleek racehorse but with the
contentions, likely ended up with a two-humped camel.
Naturally, some took umbrage on behalf of camels. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">My
recollection - and the record will show - the EWG spent
an inordinate amount of time looking at use cases, the
thinking being it would allow extraction of a set of
principles grounded in facts on the ground. Yes, some
of us had concerns about this as starting point to get
to principles; use cases conflated both appropriate and
alleged inappropriate uses, highlighting some of the
alleged noisome abuses. Some of us soldiered on ,
embracing the idea that a comprehensive problem
statement provides the best indicator to an improved
model. This is why the gripes of current stakeholders,
the expert opinions and deeper knowledge of what ails
the current system took so much time of our
deliberations. </font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">The
mitigation model that emerged is fairly easy to script.
I cannot recall any contest to the idea that data
accuracy is sine qua non for any RDDS. Yes, we are very
much aware of the distributed nature of current WHOIS
and even examined a model so configured in the solution
set we discussed. Again, balancing the contentions, the
centralized database offers certain advantages - and
these are listed in details - at least for standard
enforcement, query and access control. The concept of a
minimum set of RDDS data elements for global unfettered
display stems from privacy concerns and, coincidentally,
a nod to the 'thin' model. Gated access in the model
addressed the concerns from the perspective of a broader
set of business reasons for RDDS access, privacy and the
evaluation of and better knowledge of purposeful use. <br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1"><br>
</font></div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><font size="+1">I could
give a lot more examples that underscore a different
narrative. Not just because I spent almost 2 years of
my life working this on a truly voluntary basis - I do
not make a living from the ecosystem and my day job has
no connection to it - but for the fact I sincerely
believe that what was achieved was remarkable in and of
itself. </font><br>
</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small"><br>
</div>
<div class="gmail_default" style="font-family:comic sans
ms,sans-serif;font-size:small">-Carlton</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature"
data-smartmail="gmail_signature"><br>
==============================<br>
Carlton A Samuels<br>
Mobile: 876-818-1799<br>
<i><font color="#33CC00">Strategy, Planning, Governance,
Assessment & Turnaround</font></i><br>
=============================</div>
</div>
<br>
<div class="gmail_quote">On Wed, Jun 29, 2016 at 8:04 PM,
Gomes, Chuck <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:cgomes@verisign.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:cgomes@verisign.com">cgomes@verisign.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Andrew,<br>
<br>
I am sorry to take so long to respond to your very
thoughtful message but as you know I have been pretty
busy here in Helsinki. It seems to me personally that
you make some suggestions that could possibly be
constructive to the work ahead but I have two primary
concerns:<br>
<br>
1. I am pretty sure that it would require a charter
change. To do that would require going back to the GNSO
Council with the proposed changes and seeking their
approval. That is something that is not out of the
question but it could cause some delays and I would want
to make sure that there is strong WG support for doing
so. Also, I think we need to remember that a lot of
very smart people spent quite a bit of time developing
the framework that resulted in the charter so I think we
should consider possible changes with that in mind.<br>
<br>
2. My understanding is that EWG debated things like you
are suggesting quite intensely. As you know I was not a
member of the EWG but Lisa has provided some thoughts
about that I include below.<br>
<br>
" It might be useful to reflect upon the EWG's
experience with system modeling. After starting with use
cases, some EWG members needed a system model against
which to test principles on purposes, data needs, and
associated privacy, access, and accuracy issues. This
led to the EWG's Initial Report proposing both a set of
principles and an Aggregated RDS system model to support
those principles - but without much explanation of the
ARDS. Over the year that followed, the EWG evaluated
half a dozen system models, drilling deeper into two
(Federated and Synchronized) to examine feasibility and
costs before recommending the SRDS. Both SRDS and FRDS
models use RDAP; neither stores data in a single
physical location. While the SRDS is a "thick" storage
model where queries are served from synchronized data,
the runner-up FRDS actually uses "thin" registries,
querying data from registrars and validators in
real-time.<br>
<br>
"While some possible requirements may reflect a
particular system model - for example, those drawn from
today's WHOIS policies -- our PDP WG has yet to consider
whether to recommend a next-gen system. But no matter
what model we recommend, perhaps we can learn from the
EWG's experience. First, while envisioning a possible
new model early on was helpful to some, reaching
agreement on a recommended model was not possible until
the EWG was nearly finished, following feasibility and
cost analysis. Second, while each had pros/cons, both
models were found to be capable of supporting the EWG's
principles. In other words, model choice did not drive
the EWG's principles - principles and criteria such as
cost drove the EWG's choice of model."<br>
<br>
I want to add to Lisa's thoughts my own personal
opinion: I don't think the issue of Federated v.
Synchronized is a closed issue. My understanding is
that the final recommendation in the EWG report could
have been more the result of the desire to finish the
work than a strong consensus. Whether I am right on
that or not, our WG can consider both and make our own
decision between either one or some variation.<br>
<br>
Finally, I want to encourage all WG members to share
your thoughts on Andrews comments and on my responses
above.<br>
<span class="HOEnZb"><font color="#888888"><br>
Chuck<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>]
On Behalf Of Andrew Sullivan<br>
Sent: Friday, June 24, 2016 10:04 PM<br>
To: <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
Subject: [gnso-rds-pdp-wg] Apologies, and some
reflections on requirements<br>
<br>
Dear colleagues,<br>
<br>
Apologies first. I'm not going to be in Helsinki.
I'm in the middle of a move from NH back to Toronto,
and it turns out that my movers'<br>
understanding of, "I need to leave on $date,"
entails arranging things such that goods will arrive
after $date. Alas, in this case the goods arrive
Monday. I will attempt to follow the ICANN meetings
remotely next week, but I expect it will be tricky.<br>
<br>
I have been deeply dissatisfied with the way the
work is going, and I believe it is because I see a
mismatch in what we are trying to do and the kind of
system we are trying to do it to. In particular, I
think we are trying to treat the RDS as a single
monolithic system, and attempting to build
"requirements" that match that assumption. Here is
an effort to sketch why I think that. I didn't have
time to write a short note, &c. &c. Sorry
this is long.<br>
<br>
Since the very introduction of the
competitive-registrar model (and arguably before
that), the RDS has been a distributed database. It
is far less successful than the other distrubuted
database we all know and love -- DNS -- but it is
nevertheless distributed.<br>
<br>
The distribution comes from different parties having
various parts of the data. In so-called "thin"
registries, this was always the case.<br>
The registry has names and nameservers, and since
the invention of registrars knows who the registrar
is. But if you wanted to know certain kinds of
data, you had to ask the registrar in question.<br>
<br>
Because in (say) 1999-2001 nobody had anything
better than the whois/rwhois/whois++ protocol(s) to
deliver this kind of data, a whole bunch of bad
compromises got enshrined in policy. First, we
continued to use whois and its descendents (anything
on port 43) as the model for all of this. The plain
fact is that whois was obsolete nearly at birth.
It's a terrible protocol, and should be taken behind
the ice house and put out of its misery.<br>
<br>
Second, in order to "fix up" whois, clients were
created all over the Internet that built in a bunch
of assumptions about whom to ask for what data. The
consequence of this was that clients routinely got
bad data as they queried the wrong server. Old
registrar data hung around even after a transfer.
When I worked on the org transition from Verisign to
PIR in 2003 (?), it took a long time before whois
clients stopped asking Verisign about org data. And
so on.<br>
<br>
Third, in an attempt to hack around the above
technical flaws in an already-obsolete protocol,
"thick whois" gained popularity in possibly the
worst possible arrangement known to data science.
Instead of insisting that registries hold the data
and that registrars and everyone else treat the
registry data as The Truth, we created "thick"<br>
whois in registries _without allowing registrars to
stop their service_. Any half-competent database
person will tell you that storing "the same data" in
two places that don't have tight connections is an
excellent way to create data inconsistency, but is
not a good way to arrive at the truth. (Latterly,
as though illustrating the tendency of people to
double down on bad ideas, there have been
suggestions that ICANN should run the One Giant RDS
of the Universe and hold all the data in a central
place. What could possibly go wrong?)<br>
<br>
The thread running through this history of error is
the idea that the RDS is one system. But like the
DNS, it only appears to be one system. It's
actually a "distributed database", where in this
case the distribution is separable on organization
lines. That is, registries -- including ICANN, who
can be thought of in this case as both the registry
and registrar for the root zone -- have some data.<br>
Registrars have some other data. Resellers and
privacy/proxy services have yet other data. In many
cases, the data does not need to be shared across
these organizational lines to make it queryable by
humans.<br>
<br>
The reason that isn't clear to most of us is because
whois -- the RDS we use today -- _was_ designed as a
monolithic system. It was designed that way because
back when it was created -- RFC 812 is from _1982_!
-- the database _was_ a monolithic database. Whois
(the protocol and the client program) continues to
have all the deficiencies for distributed use that
you might expect of a program or protocol designed
to talk to exactly one authoritative service.<br>
Whois++ and rwhois attempted to graft on to this
basic protocol some<br>
distributed operation, but the graft didn't really
take and the ornamental shrub now looks like a weed.<br>
<br>
People have nevertheless internalized the
whois-based thinking, which is why we keep asking
things like, "What data should be collected?"<br>
In a distributed system like this, that's barely
interesting, for the commercial interests in this
case all militate against collecting data that
nobody needs for any function. Instead, we should
ask what data should be collected _by different
actors_. This implicitly involves describing what
those actors are doing to require the data.<br>
<br>
The nice thing, of course, is that protocol
designers have done _a lot_ of this work for us,
when they were working on RDAP. They did this
because they were trying to come up with use cases
for the protocol, which finally did away with the
monolithic-system thinking of whois and offers us a
protocol designed precisely to work in the
distributed-database environment that is the actual
registration system. That we even still have a work
step that involves evaluating what protocol we're
going to use for all this makes me a little ill.<br>
<br>
It seems to me that we can just say that we have to
embrace the distributed-database fact. For first,
it's a fact of how registration actually works now.
If we don't agree with that, I think we should give
up. Second, it's consistent with how every single
other thing on the Internet that has not crashed and
burned works. The Internet cannot scale depending
on monolithic systems. And nobody has the power to
impose one anyway.<br>
<br>
Once we have done that, there are still important
policy issues about what data ought to be collected
by anyone, under what conditions they might reveal
it to someone else (and who that someone else is),
and so on. But there are empirical tests for
whether some of the answers people are proposing
really match the distributed nature of the system.
If they don't, we can close off those avenues of
inquiry, because they'll never be productive.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
<br>
--<br>
Andrew Sullivan<br>
<a moz-do-not-send="true"
href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>