<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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><font size="+1"><font face="Lucida Grande"></font></font><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">cgomes@verisign.com</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 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>