[gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1

[Greg Aaron]

Dear Chuck:

Thanks.  "Functional requirements" might come before "implementation options".  In a traditional business process, one creates a new product by writing what are called the "business requirements."  These are the high-level requirements - what goals the product should accomplish.  That's rather like what Phase 1 of our WG is to do - decide what the major goals (i.e. fundamental policies) need to be.  Traditional business process is then to write "functional specifications" -- specific things that must be done in order to accomplish the business requirements.  That is what is supposed to happen in our Phase 2.  Implementation is about even finer executional details, and that is what Phase 3 is about.  In ICANN lingo, "implementation" can have a specific meaning (and is sometimes treated as a policy-making afterthought, and some is put into the hands of ICANN staff).

One way to categorize an item on the list is to ask if it has any pre-conditions or assumptions in it.  If so, state what those are and focus on them; they may be the kind of fundamental policy questions we are looking for, and we can set aside the original item for later.  I gave an example below.

Collecting statements from here and there is part of the task, but the real value comes in distilling the raw material down to fundamental problem and policy statements.  Which the doc is short on night now, so we need to think about how the WG will do that eval.  The doc's also short of raw material from all the summarized docs.

All best,
--Greg



From: Gomes, Chuck [mailto:cgomes at verisign.com]
Sent: Thursday, May 19, 2016 12:56 PM
To: Greg Aaron <gca at icginc.com>; 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

Thank you very much Greg for your thoughtful review and analysis of draft 1 of possible requirements.  For my better understanding, are you equating IMPLEMENTATION OPTIONS and FUNCTIONAL REQUIREMENTS or are the same thing?

How easy do you think it would be to categorize the current list of possible requirements into 1) POLICY REQUIREMENTS and 2) FUNCTIONAL REQUIREMENTS?  What do you think would be the best way to accomplish that?

Chuck

From: Greg Aaron [mailto:gca at icginc.com]
Sent: Thursday, May 19, 2016 11:15 AM
To: Gomes, Chuck; Lisa Phifer; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: RE: [gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1

Dear Chuck et al:

Many of the items in this document are not possible POLICY REQUIREMENTS that we are supposed to wrestle with in Phase 1.  Rather, they are possible IMPLEMENTATION OPTIONS or FUNCTIONAL REQUIREMENTS -ways to carry out possible policies that the WG may or may not arrive upon.  There is a huge difference between policy requirements and functional requirements, and not distinguishing between them here is a problem.

My understanding of Phase 1 Task 8 was that it is to identify policy requirements -- i.e. focus on fundamental problems we are trying to solve.  According to the charter, Phase 1 is about policy "at a high level.  The charter then says: "In Phase 2, the PDP WG should design detailed policies to satisfy all requirements established  in Phase 1. ... In Phase 3,  the PDP WG should dive more deeply into each policy group to create any  necessary implementation and coexistence guidance."

An example of a policy question is: who needs or deserves access to what, and the follow-on question is therefore do we need some sort of tiered access system.  It would be premature for Task 8 to identify ways to carry out policies, before we've settled on the policies we want.  I also note that it is impossible to come up with a list of all the possible functional requirements until we first decide what policy requirements we want.

Instead, this document is based primarily on very detailed executional ideas from the EWG.  While the Board recommended that the EWG Final Report should be a starting point for this PDP, it was made clear that the EWG was not policy development.  And as many pointed out, the EWG jumped to very detailed implementation conclusions without solidly grounding them in fundamental policy, and without presenting any other possible policy or implementation  options.

For example, most of the items in the gated access section (pages 5-10) are very detailed functional or implementation requirements created by the EWG. An example is:
"[GA-D1-R19] - To meet the needs of authenticated users with permissible purposes, the gTLD registration directory must provide a Reverse Query service that searches public and gated data elements for a specified value and returns a list of all domain names that reference that value."
That is not a policy requirement.  It is a derived conclusion, a way to execute on some possible policy requirements.  GA-D1-R19 is built to carry out some set policies: required tiered access, a centralized system like the EWG recommended, and a driving need for a reverse query service.  We are very far from conclusions about any of those things.

This points out a fundamental issue for me -there are clear dependencies among the charter questions that can help us order discussions.  For example, User/Purposes and Privacy seem to be major drivers of possible policies.  Data Elements clearly depends a lot on the answers to the User/Purposes and Privacy questions.

In conclusion: I suggest that greater discernment and focus on fundamentals is needed in this Task 8 exercise.  The current kitchen-sink approach puts the cart before the horse, and heaps in items that should not be discussed until Phase 2 or Phase 3.

All best,
--Greg

**********************************
Greg Aaron
Vice-President, Product Management
iThreat Cyber Group / Cybertoolbelt.com
mobile: +1.215.858.2257
**********************************
The information contained in this message is privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

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 Gomes, Chuck
Sent: Wednesday, May 18, 2016 10:30 AM
To: Lisa Phifer <lisa at corecom.com<mailto:lisa at corecom.com>>; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] RDS PDP WG initial list of possible requirements draft 1
Importance: High

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,

Chuck

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

Dear all,

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:

https://community.icann.org/download/attachments/59639539/RDS%20PDP%20List%20of%20Possible%20Requirements%20Draft%2017%20May.docx

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.

Best regards,
Lisa

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...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160519/9607773d/attachment.html>