<p dir="ltr">Morning,</p>
<p dir="ltr">Thanks Lisa for these notes.</p>
<p dir="ltr">I apologize for not have been able to attend. </p>
<p dir="ltr">Will go through the actions items</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 21 déc. 2016 08:09, "Lisa Phifer" <<a href="mailto:lisa@corecom.com">lisa@corecom.com</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>
<font face="Arial, Helvetica">Dear All,<br><br>
Please find below the notes and action items from today's meeting. Please
note that our next WG call will be on 10 January.<br><br>
Best regards,<br>
Lisa<br><br>
<b>RDS PDP WG Meeting - 21 December 2016<br><br>
</b><i>These high-level notes are designed to help PDP WG members
navigate through the content of the call and are not meant as a
substitute for the transcript and/or recording. The MP3, transcript, and
chat are provided separately and are posted on the wiki at:
<a href="https://community.icann.org/x/i6TDAw" target="_blank">
https://community.icann.org/x/<wbr>i6TDAw</a><br><br>
1. Roll call / SOI</i>
<ul>
<li>Roll call will be taken from Adobe Connect
<li>Please remember to keep your SOIs up to date
</li></li></ul><br>
<i>2. Review poll results </i>
<ul>
<li>Refer to poll results posted at
<a href="https://community.icann.org/x/i6TDAw" target="_blank">
https://community.icann.org/x/<wbr>i6TDAw</a>
<li>Result Summary: Option (b) had greatest support, followed by options
(a) and (e). Just two respondents agreed with option (c) – no limitation
by purpose, and two respondents stated that their answers differed for
subsets of thin data elements. No support for option (d) – eliminating
access to “thin data” entirely.
<li>Consideration of poll results as a guide to find a productive path
forward for deliberations
<li>90% of respondents through purpose should play some kind of role in
policy for "thin data" - strong indication the WG should
consider legitimate/illegitmate purposes. Why shouldn't policy take
purpose into consideration?
<li>Possible reasons: cost and effort involved in checking and enforcing
purpose, limited benefit in return for that cost; not sure we can prevent
sharing data after it was taken from the system; extra layers of access
control may not be warranted for minimal data included in thin data
<li>Reactions: May want to separate anonymous access from identification
or authentication for access to thin data - may not want to allow
anonymous access? Privacy policies may require authentication but that
may lead to logging access which may not be desirable
<li>Is the answer for thin data different than for other registration
data? Purposes for thin data may be more technical, may not require PII,
may pose less risk of abuse (and be dealt with using rate limiting, etc)
because thin data includes few elements - so why should it be hidden?
There are purpose(s) for thin data but access shouldn't be limited
<li>The language used in the poll questions may have led to results that
are farther apart than we really are - I didn't find options satisfactory
so I wrote option (e) to include anonymous access without declaring a
purpose. The wording implied access controls to check purpose, which is
why (e) is closer to (c) than (a).
<li>Re: "except for illegitimate purposes" - if someone does
bad things, their access can be blocked - but what does that cost?
<li>Two of the thin data elements are already accessible anonymously -
name servers, domain name - so the set of thin data elements you might
control access to is very small
<li>How hard is it to authenticate requestors? Really hard for today's
WHOIS or an open system
<li>Even with this limited number of responses, we have opposing views
about whether purpose should play an inclusive or exclusive role in “thin
data” policy. But further deliberation on specific purpose(s) and thin
data elements may uncover common ground.
<li>We may be stumbling a bit over possible implementations when trying
to visualize impact of potential policy requirements. For example,
captive portal pages often offer both anonymous Internet access and
authenticated access to more network resources – it is possible to
implement both kinds of policies. While we need to consider whether
implementation of potential policies is feasible, policy should drive
implementation not the other way around
</li></li></li></li></li></li></li></li></li></li></li></li></li></ul><br>
<i>3. Continue deliberation on question 2.1, focusing on thin data</i>
<ul>
<li>Is there anyone who thinks we should not consider purpose at all?
<li><b>Agreement: Concluding that purpose is useful to consider further
(without implying authentication, disclosure, or access control)..</b>
<li>Refer to handout posted at
<a href="https://community.icann.org/x/i6TDAw" target="_blank">
https://community.icann.org/x/</a>
<a href="https://community.icann.org/x/i6TDAw" target="_blank">i6TDAw</a>
<li>What is the purpose of collecting thin data elements? Specifically:
<li>What is the purpose of collecting the domain name's Sponsoring
Registrar? It tells the registrant who is responsible for their domain
name (but see note about Resellers below), required by policy to help
facilitate registrar to registrar transfers; see also EWG pg 129-132 for
purposes of any field
<li>There's also a contractual line through the reseller to the
registrar; may have an optional Reseller field for registrars who wish to
avail themselves of it
<li>What is the purpose of collecting the domain name registration's
Status(es)?
<li>Could put "thin data" elements into a few categories - (1)
Registrar/URL, (2) operational data - Name Servers, (3) rest are metadata
about the domain registration such as dates, status
<li>Note that many thin data elements are not "collected" per
se - the fields are populated but from the RDS/WHOIS perspective we refer
to collection
<li><b>Agreement that for all <u>thin data elements</u>, there is <u>at
least one purpose for collection</u></b>
<li>Referring to EWG report pages 129-131, the thin data elements are
listed by purpose - are there comments on the purposes listed for
"thin data" elements?
<li>Noted that purposes listed by EWG were not comprehensive - but they
were recommended as "permissible"
</li></li></li></li></li></li></li></li></li></li></li></li></ul><br>
<b>Action:</b> Staff to launch poll to confirm two main points of
agreement and allow those not on call to weigh in; poll to remain open
through the holidays with results aggregated for use in next WG call 10
January<br><br>
<i>4. Confirm next meeting date: Tuesday 10 January 2017 at 17.00
UTC<br><br>
<br>
</i><b>Meeting Materials: <br>
</b><a href="https://community.icann.org/x/i6TDAw" target="_blank">
https://community.icann.org/x/<wbr>i6TDAw</a><br>
</font></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>