[gnso-rds-pdp-wg] Possible approach to consensus in deliberation of possible requirements for RDS PDP WG

[Gomes, Chuck]

Per Action Item #3 from yesterday's WG call, attached is a slighted revised 'possible approach for consensus in deliberation of possible requirements for RDS PDP WG'.  This version was revised from the one presented in the WG call; edits were made and comments inserted in an effort to reflect the WG discussion that occurred in the meeting. Given on-going list discussion, all WG members are encouraged to review and comment with an aim to 'finalise' the approach during next week's meeting. To aid in discussion, below is a recap of two proposals made during yesterday's WG call with some pros & cons.

Proposal 1: When indicating level of support for possible requirements within initial report(s), identify whether there is support or lack of support by each SG/C.

Pros: Communicate any formal statement(s) of support in context with draft recommendations.
Cons: SG/C positions likely to be formalized after initial report, during public comment.
Personal comment from Chuck:  The attached approach does not specifically address this so I believe that we could deal with this once we get to that point; if I am correct, we do not need to resolve this now.

Proposal 2: Limit initial report to three fundamental questions (privacy, data, users/purposes), adding a new second initial report on remaining fundamental questions (accuracy and gated access) prior to the required initial report at conclusion of Phase 1 to address (at minimum) all 11 charter questions.

Pros:

*         Allows WG to make incremental progress by focusing on fewer questions and possible requirements

*         There are only so many issues we can work on at once, and to stick with the big 3 provides a focus and direction.

*         Allows additional/earlier opportunity for public comment

*         It may be premature to consider accuracy and gated access when we have not yet established if there is a basis for collecting registration data in the first place.
Cons:

*         Delays deliberation on inter-dependent questions

*         May impede attempts to balance privacy, access, and accuracy issues as requested by board and charter

*         Adds overhead for WG and community (additional workload associated with running two vs. three public comment periods (both from a staff as well as WG perspective as well as impact on the overall timeline)

*         There is a risk of public comment fatigue so the WG will need to give consideration to whether there are any downsides to having three public comment periods on the same topic vs. two.

*         There's a reason the charter was written as is and to change it unwinds the charter without the benefit of the thoughtful work and deliberations that went into it.

Personal note from Chuck:  I tried to include the pros and cons from various people both in yesterday's meeting and on the list since then.  If I missed some, please communicate them.  Also, I encourage others to suggest additional pros and cons on the list.
Thanks to those who have begun to share their views on these proposals and expand upon possible pros/cons. You are all encouraged to continue exchanging views to reach agreement on a possible approach for deliberation that can lead this WG to consensus agreement on all of the questions we must answer during Phase 1.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160615/de6603b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Possible approach to consensus in deliberation of possible requirements 13-Jun 16 v5.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 31225 bytes
Desc: Possible approach to consensus in deliberation of possible requirements 13-Jun 16 v5.docx
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160615/de6603b5/Possibleapproachtoconsensusindeliberationofpossiblerequirements13-Jun16v5.docx>