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

[Karnika Seth]

Dear all,

I express my inability to join as I am travelling

Regards

Karnika Seth
On Wednesday 18 May 2016, Lisa Phifer <lisa at corecom.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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/20160518/3e1094db/attachment.html>