<html>
<body>
Thanks very much Greg. <br><br>
I have added SAC061 to the inputs list and put you down as volunteering
for both SAC055 and SAC061.<br><br>
All, sign-up list and further instructions on how to volunteer to be
posted shortly...<br><br>
<br><br>
At 11:12 AM 5/24/2016, Greg Aaron wrote:<br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>
Excerpts from SAC061 and SAC055 are below; please add to the draft list
of possible requirements.<br>
&nbsp;<br>
&nbsp;<br>
SAC061: SSAC Comment on ICANN’s Initial Report from the Expert Working
Group on gTLD Directory Services<br>
&nbsp;<br>
&quot;The ICANN Board should ensure that a formal security risk
assessment of the registration data policy be conducted as an input into
the Policy<br>
Development Process. A separate security risk assessment should also be
conducted regarding the implementation of the policy. &quot;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
SAC055: WHOIS: Blind Men And An Elephant<br>
&nbsp;<br>
&quot;The SSAC believes that there is a critical need for a policy
asserting the purpose of collecting and maintaining registration data.
This policy should address the operational concerns of the parties who
collect, maintain or use this data as it relates to ICANN’s
remit.&quot;<br>
&nbsp;<br>
&quot;An accuracy policy should define each data element and require that
it be examined and indicate for each element a method for determining the
level ofaccuracy of the data.&quot;<br>
&nbsp;<br>
&quot;Internationalization MUST be supported by default, not called out
separately. The focus should be on Recommendation 2 from the IRD-WG final
report.&quot;<br>
&nbsp;<br>
&quot;Policies with respect to the accuracy of registration data should
apply equally to all registration data without regard to whether it is
internationalized or ASCII registration data.&quot;<br>
&nbsp;<br>
&quot;develop clear targets for compliance with respect to registration
data accuracy; performance provisions such as SLA must be considered as
part of the compliance function.&quot;<br>
&nbsp;<br>
&quot;The SSAC believes that law enforcement has a legitimate need to
access the real identity of the responsible party(ies) for a domain
name.&quot;<br>
&nbsp;<br>
&quot;The SSAC believes that security practitioners have a legitimate
need to access the real identity of those responsible for a domain
name.&quot;<br>
&nbsp;<br>
&quot;develop clear targets for compliance with respect to registration
data accuracy (see Section 3.2.1 below).... ICANN should take appropriate
measures to reduce the number of WHOIS registrations that fall into the
accuracy groups Substantial Failure and Full<br>
Failure&quot;<br>
&nbsp;<br>
&quot;ICANN should ensure that there is a clear, unambiguous and
enforceable chain of contractual agreements with registries, registrars,
and registrants to require the provision and maintenance of accurate
WHOIS data. As part of these agreements, ICANN should ensure that clear,
enforceable and graduated sanctions apply to registries, registrars and
registrants that do not comply with its WHOIS policies. These sanctions
should include de-registration and/or deaccreditation as appropriate in
cases of serious or serial non-compliance.&quot;<br>
&nbsp;<br>
--Greg<br>
&nbsp;<br>
<b>From:</b> gnso-rds-pdp-wg-bounces@icann.org
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] <b>On Behalf Of </b>Gomes,
Chuck<br>
<b>Sent:</b> Wednesday, May 18, 2016 10:30 AM<br>
<b>To:</b> Lisa Phifer &lt;lisa@corecom.com&gt;;
gnso-rds-pdp-wg@icann.org<br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] RDS PDP WG initial list of possible
requirements draft 1<br>
<b>Importance:</b> High<br>
&nbsp;<br>
I want to encourage&nbsp; everyone to review the list of ‘possible
requirements’ as soon as possible and add requirements from other sources
between now and 31 May.&nbsp; I realize that that is only two weeks away,
but if all of us take advantage of the knowledge and experience we have,
I think we should be able to make good progress.&nbsp; For those that
reviewed and summarized documents as part of the purpose, data and
privacy sub-teams, I encourage you to use the knowledge you gained to
identify new ‘possible requirements’.<br>
&nbsp;<br>
No one is expected to review all possible sources for additional
‘possible requirements’, but if all of us use the our individual
knowledge and expertise to fulfill this task, our collective efforts
should help us develop a 90 to 95% percent complete list.&nbsp; It is
understood that we will discover new ‘possible requirements’ along the
way, and that is fine, so it is not as if we cannot add them later
on.&nbsp; At the same time, the list we develop over the next several
weeks will provide the initial foundation for our deliberations in task
12 of our work plan so it is important that we maximize our efforts
now.<br>
&nbsp;<br>
Please note that all everyone is asked to do at this time is identify
‘possible requirements’ along with the source and the associated charter
question.&nbsp; This is not the time to evaluate whether or not you
support any of the ‘possible requirements’.&nbsp; We will do that
together in task 12.<br>
&nbsp;<br>
A lot more information about this was covered in this week’s meeting so I
strongly encourage those of you who missed the call to listen to the
recording and/or read the transcript once they are available.&nbsp; In
our meeting next week, we will review the status so let’s try to make
good progress before then.<br>
&nbsp;<br>
If you have any questions, please ask them on this list.<br>
&nbsp;<br>
Thanks in advance,<br>
&nbsp;<br>
Chuck<br>
&nbsp;<br>
<b>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] <b>On Behalf Of </b>Lisa
Phifer<br>
<b>Sent:</b> Wednesday, May 18, 2016 3:33 AM<br>
<b>To:</b>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>
<b>Subject:</b> [gnso-rds-pdp-wg] RDS PDP WG initial list of possible
requirements draft 1<br>
&nbsp;<br>
Dear all,<br><br>
Attached please find a first draft of an initial list of possible
requirements (task 8). You may also find the attached file posted on the
wiki:<br><br>
<a href="https://community.icann.org/download/attachments/59639539/RDS%20PDP%20List%20of%20Possible%20Requirements%20Draft%2017%20May.docx">
https://community.icann.org/download/attachments/59639539/RDS%20PDP%20List%20of%20Possible%20Requirements%20Draft%2017%20May.docx<br>
<br>
</a>For those not on today's WG call, please review Chuck's introduction
to this list (see call notes below). The call recording and transcript
will also be posted shortly on the meeting page:
<a href="https://community.icann.org/x/8waOAw">
https://community.icann.org/x/8waOAw<br><br>
</a><b><i>All WG members are now asked to read/listen to Chuck's
introduction and then contribute further possible requirements, focusing
initially on the 5 fundamental questions.<br><br>
</i></b>The goal of task 8 is to gather possible requirements from many
different sources, creating a comprehensive and inclusive foundation for
future systematic WG deliberation (task 12). <br><br>
Please contribute possible requirements via email to the full WG mailing
list
&lt;<a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a>&gt;, identifying associated charter
question(s) and sources. You are encouraged to supplement the initial
list with possible requirements quoted or paraphrased from input
documents summarized by sub-teams. You may also draw from other source
documents or suggest new possible requirements of your own. Staff will
then gather all possible requirements into a consolidated initial list
for WG use in completing task 8.<br><br>
Best regards,<br>
Lisa<br><br>
At 12:12 AM 5/18/2016, Marika Konings wrote:<br>
<i>3. Introduction to draft possible requirements documents and
discussion of next steps</i> 
<ul>
<li>Key to explain background and approach of document first to ensure
there is a common understanding of this document and how it should be
read 
<li>Per the Board's direction, starting of with possible requirements
from EWG Final Report - that does not give those requirements any special
priority. WG will be asked to add to the list, using the sources and
input that has been gathered by the sub-teams. Eventually SG/Cs will also
be asked to provide input. Also possible to identify requirements that
didn't come from any of those sources.&nbsp; 
<li>Initial list will be compliled without any debate on the merits.
Following that, deliberation will be done in a systematic manner, going
through each of the proposed requirements to determine whether these
should be included in the list of proposed requirements or not. 
<li>The possible requirements listed in this document are organized as
follows: 1. Possible Requirements that map to one or more of the eleven
(11) questions in the charter. Note that the same requirement may address
multiple questions. 2. Possible Requirements that may not map to any
question identified in the charter. 3. Possible Foundational Questions
that must be answered based on all other requirements. 
<li>Way they are currently grouped in 11 charter questions is not fixed -
requirement may fit in more than 1 question and/or move requirements
around 
<li>Requirements are not included in any specific order 
<li>Will be an iterative process going through these 
<li>See notation section in the document to understand the references by
which possible requirements have been identified 
<li>For further details on the associated questions, please refer to the
charter 
<li>Some proposed requirements are quoted verbatim, some were not
possible to quote as they were more implied - flexible about how it is
included. Those that are quoted are in between &quot; &quot;.&nbsp; 
<li>For sorting purposes, update numbering to 01, 02, 03, etc. 
<li>Possible requirements do not have to be (and probably won't be)
specific to today's WHOIS - starting from a clean slate approach.&nbsp; 
<li>Order of proposed requirements may not necessarily be the order of
deliberation - it is currently ordered in this way following the order of
the charter. 
<li>Indented proposed requirements indicate relationship with previous
proposed requirement 
<li>How will coding work if there is no reference doc? If there are
suggestions that are made on the email list, for example, that link would
then be included as the source. Importance is to be able to link it back
to the original source, whether that is a document, report or individual
suggestion.&nbsp; 
<li>D# refers to the source of the possible requirement, whether that is
a published document, an email message to the WG, or even WG meeting
notes. Those are all sources - the idea is merely to be able to find the
source when the time comes to deliberate. 
<li>Some proposed requirements may overlap or be duplicates - that will
be dealt with in the deliberation phase.&nbsp; 
<li>The process framework alignment is intended to help guide the WG in
focusing on possible requirements to be dealt with in phase 1, deferring
policy definition and implementation guidance to future phase. 
<li>See top of page 22 - current version of possible requirements cover
the first five questions of the charter. However, cross-curring questions
have been included as place-holders to be expanded later and to allow for
possible requirements to be moved or added.&nbsp; 
<li>Foundational questions to be found at the end of the document. 
<li>Next step is for WG to review this initial list of possible
requirements and WG to supplement to the list (not to evaluate, only
add). See step 8c of the work plan. Deadline for input according to the
work plan: 31 May. However, not unlikely that additional possible
requirements may be discovered further down the road. 
<li>By 2nd June, create a second list of the possible requirements which
is to serve as a foundation for the WG deliberations, as well as outreach
to the community to identify any requirements that may have been
missed.&nbsp; 
<li>Before diving into deliberations, need to agree on approach as well
as method for assessing consensus.&nbsp; 
<li>Deliberation (pros / cons, whether it should be included as a
requirement, etc.) will only happen once a full list of possible
requirements has been developed - WG will do this in a systematic way
e.g. by category. 
</ul><b>Action item</b>: WG to review this initial list of possible
requirements (to be circulated to the mailing list shortly) and WG to
supplement to the list (not to evaluate, only add). Deadline for input
according to the work plan: 31 May.</blockquote></body>
</html>