[gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1
gca at icginc.com
Tue May 24 17:12:34 UTC 2016
Excerpts from SAC061 and SAC055 are below; please add to the draft list of possible requirements.
SAC061: SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services
"The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy
Development Process. A separate security risk assessment should also be conducted regarding the implementation of the policy. "
SAC055: WHOIS: Blind Men And An Elephant
"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."
"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."
"Internationalization MUST be supported by default, not called out separately. The focus should be on Recommendation 2 from the IRD-WG final report."
"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."
"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."
"The SSAC believes that law enforcement has a legitimate need to access the real identity of the responsible party(ies) for a domain name."
"The SSAC believes that security practitioners have a legitimate need to access the real identity of those responsible for a domain name."
"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
"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."
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Gomes, Chuck
Sent: Wednesday, May 18, 2016 10:30 AM
To: Lisa Phifer <lisa at corecom.com>; gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1
I want to encourage everyone to review the list of 'possible requirements' as soon as possible and add requirements from other sources between now and 31 May. 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. 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'.
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. 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. 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.
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. This is not the time to evaluate whether or not you support any of the 'possible requirements'. We will do that together in task 12.
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. In our meeting next week, we will review the status so let's try to make good progress before then.
If you have any questions, please ask them on this list.
Thanks in advance,
From: gnso-rds-pdp-wg-bounces at icann.org<mailto:gnso-rds-pdp-wg-bounces at icann.org> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Lisa Phifer
Sent: Wednesday, May 18, 2016 3:33 AM
To: gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: [gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1
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:
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: https://community.icann.org/x/8waOAw
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.
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).
Please contribute possible requirements via email to the full WG mailing list <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>, 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.
At 12:12 AM 5/18/2016, Marika Konings wrote:
3. Introduction to draft possible requirements documents and discussion of next steps
* 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
* 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.
* 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.
* 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.
* 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
* Requirements are not included in any specific order
* Will be an iterative process going through these
* See notation section in the document to understand the references by which possible requirements have been identified
* For further details on the associated questions, please refer to the charter
* 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 " ".
* For sorting purposes, update numbering to 01, 02, 03, etc.
* Possible requirements do not have to be (and probably won't be) specific to today's WHOIS - starting from a clean slate approach.
* 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.
* Indented proposed requirements indicate relationship with previous proposed requirement
* 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.
* 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.
* Some proposed requirements may overlap or be duplicates - that will be dealt with in the deliberation phase.
* 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.
* 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.
* Foundational questions to be found at the end of the document.
* 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.
* 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.
* Before diving into deliberations, need to agree on approach as well as method for assessing consensus.
* 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.
Action item: 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gnso-rds-pdp-wg