<p dir="ltr">Good analysis...It confirms that we need to divide the question raised earlier in the meeting in two parts.</p>
<p dir="ltr">Best Regards<br>
@__f_f__<br>
<a href="http://about.me/farell">about.me/farell</a> <br>
________________________________.<br>
Mail sent from my mobile phone. Excuse for brievety.</p>
<div class="gmail_quote">Le 25 avr. 2017 22:49, "Sam Lanfranco" <<a href="mailto:sam@lanfranco.net">sam@lanfranco.net</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
At the risk of an unbroken line of stupid comments I offer
the following. (<i>With the caveat that here you can hit the <</i><i><b>DELETE</b></i><i>>
button </i><i><span class="m_1925988459268134561moz-smiley-s2"><span>:-(</span></span></i><i>
and get on with things</i>) On Adobe Connect such offerings as
this cost us real time. <br>
I
come to this as an economist who thinks of data as “inventory” and
realize that
economists are often accused of opinions that lead anywhere, or
nowhere. <u></u><u></u><br>
<br>
Might there be some merit to ICANN simply having a minimalist
approach, deciding on and defining open access data as “thin data”.
“Thick data”
would simply be all authoritative data that is not “thin data”.
“Gated data” would
be Thick data with defined terms of access. There is little logic in
having
gated thin data and gated thick data. There is just gated data,
possibly with
differential terms of access for different users. <u></u><u></u><br>
<br>
Might there be some merit in defining “authoritative data”
simply as: verified (as best the registrar can); at a designated
repository;
and with defined terms of access (Open, Gated, Closed). <u></u><u></u><br>
<br>
The authoritative data set fields can be defined in terms of
what Registrars, Registries, and ICANN need to run their respective
businesses.
The partitions between open, gated and closed data will vary by
jurisdiction as
individual registrars and registries conformed to binding national
data
protection and access regimes. This is not a “carve it in stone”
exercise, it
is more like a building a lego set of authoritative pieces that have
limits to assembly,
and will be subject to differential access depending on
jurisdiction. <u></u><u></u><br>
<br>
There will always be pressures with regard to what data and
what access, but that is nothing new. If ICANN wants to own the
kitchen, it has
to put up with the heat. In the face of evolving national data
security and
access policies ICANN’s role could be as a stakeholder and friend of
the
process, striving for common and sane legislation across
jurisdictions. Should we/could we wish for anything more?<br>
<br>
<u></u><u></u><img src="cid:part1.6FE4493B.0933DB93@lanfranco.net" alt="" height="287" width="394"><br>
<br>
Sam Lanfranco <br>
(<font color="#660000"><i>under comment protection <span class="m_1925988459268134561moz-smiley-s7"><span>:-\</span></span> </i></font>)<br>
</div>
<br>______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br></blockquote></div>