The next GNSO Next-Gen RDS PDP Working Group teleconference is scheduled for Wednesday, 18 May at 05:00 UTC for 90 minutes.
22:00 PDT (Tuesday), 01:00 EDT, 06:00 London, 07:00 CEST
For other times: http://tinyurl.com/zywx6dn
- Roll Call / SOI
- Work plan - next steps (communication to GNSO Council, posting on wiki)
- Introduction to draft possible requirements document and discussion of next steps
- Planning for Helsinki meeting (Cross Community Session - Monday 17.00 - 18.30, F2F meeting - Tuesday 8.00 - 12.00)
- Next steps / confirmation of next meeting (Tuesday 24 May at 16.00 UTC)
Apologies: Andrew Sullivan, Sana Ali, Michele Neylon, Jennifer Gore Standiford, Steve Metalitz, Rod Rasmussen, Marc Anderson, Gregory Mounier, Alan Greenberg
On audio only:none
- Reminder to state names before speaking for transcription purposes
- Please remember to mute your microphones when not speaking
- Remember to keep your SOIs up to date
- Work plan now considerd adopted
- As per the WG charter, work plan will be communicated to the GNSO Council
- Work Plan has been posted on the wiki (https://community.icann.org/x/oIxlAw)
- Staff will update the Work Plan on an ongoing basis to update dates and mark items that have been completed
- It is the expectation that the WG will come back to the WP from time to time to ensure that work is still on track and/or make any updates as needed
- WG is currently at step 8 of the work plan
- 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.
- WG must consider how to use the Cross Community Session in the most effective manner
- Objective is to allow discussion of issues that are of broad interest with all those in attendance and feed into WG deliberations
- It will be important that ahead of this meeting the WG inform attendees of background materials to prep for the Cross-Community Session. The intent is that as little as possible of those sessions are one-way presentations.
- Suggestions are welcome as to how to best structure the Cross Community Session to be interactive and gather useful input
- WG session will be 4 hour meeting. It will be a regular WG meeting with remote participation for those not in attendance. In addition, non-WG members can also participate as guests.
- Tuesday 24 May at 16.00 UTC
- RDS PDP WG Draft Outline of a Work Plan (as approved on 13 May)
- RDS PDP List of Possible Requirements Draft 17 May.docx (drafted by leadership team, 17 May)