[gnso-rds-pdp-wg] Notes, action items and WG agreements from today's meeting

Tue Jan 10 18:44:06 UTC 2017

Dear All,

Please find below the notes and action items from today’s meeting. If you were not able to attend and/or speak during the meeting, please make sure to share your comments with the mailing list.

Best regards,

Marika

Notes RDS PDP WG 10/1/2017:

These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/C4xlAw.

1. Roll call / SOI

·         Attendance will be taken from Adobe Connect

·         Please remember to state your name for transcription purposes and do not forget to mute your line when not speaking.

·         Please remember to update your SOI, if/when needed

·         Request to add RDS review to AOB in view of letter that has been sent by GNSO to not limit scope. Concern about impact on resources and potential duplication. Note that GNSO Council proposes just a slight broadening and is not intended to overtake the work of this PDP.

Action item #1: GNSO Council members encouraged to take concerns back to the GNSO Council concerning broadening the scope of the RDS Review.

Action item #2: WG members to encourage respective groups to provide input on this topic to staff/ICANN Board.

2. Review poll results: FinalResults-Poll-on-Purpose-from-21DecCall.pdf
      a. Review of conclusions & comments/clarifications

·         See summary report shared on mailing list

·         Starting with thin data is just as a starting point, thick data will follow later. Is there any harm done by starting with narrow focus? None identified.

·         Is there no illegitimate use of RDS information? Of course, it may differ from jurisdiction to jurisdiction.

·         Comment 10 suggests that there is public data, but that is still a topic that is open for discussion. Need to separate display from collecting. Is a separate decision point whether something that is collected needs to be displayed. Q1 in the poll noted that this statement is NOT intended to imply authentication, disclosure, or access control for thin data - all topics to be deliberated upon later. Some data may be inherently public as they are available through other sources.

·         Q1. The WG should continue deliberation on the purpose(s) of "thin data." (88%)

WG Agreement #1: The WG should continue deliberation on the purpose(s) of "thin data."

·         Q2. Every "thin data" element should have at least one legitimate purpose. (88%)

·         Having identified legitimate purposes will not tie the WG's hands on policy which will be discussed in phase 2 such as display, access, etc. Just because a purpose is legitimate does not automatically imply public access. WG will deliberate at a later stage on access and/or public display.

WG Agreement #2: Every "thin data" element should have at least one legitimate purpose.

·         Q3. Every existing "thin data" element does have at least one legitimate purpose for collection. (88% *)

·         Who collects is also part of a later discussion. Don't get hung up on term 'collection' at this stage.

·         Scope of PDP is RDS policy in its entirety. Not be limited to how things are done today, these may change as a result of this PDP.

·         Distinguish between data that is collected at the request of ICANN (as a result of policy and/or contractual requirements) and data that is collected by a registrar to run its business. The latter is out of scope for this effort.

WG Agreement #3: Every existing "thin data" element does have at least one legitimate purpose for collection.

4. EWG-identified purposes apply to at least one "thin data" element. (91%)

·         See handout in which additional purposes have been added based on the comments that were submitted.

WG Agreement #4: EWG-identified purposes apply to at least one "thin data" element.

      b. Add results to "Key Concepts Deliberation Working Draft" Section 2.1.2

·         Results from this poll will be added to key concepts deliberation workiing draft to keep record of conclusions that are being reached (see above WG agreements).

Action item #3: Staff to add WG agreements discussed during today's meeting to key concepts deliberation working draft

3. Continue deliberation with Users/Purposes Charter Question 2.2 for thin data only, starting with collection only:
      2.2.1 For what specific (legitimate?) purposes should gTLD registration thin data elements be collected?

·         See handout: 10JanMeeting-PurposesForThinData-Handout-v2.pdf. Note that use cases listed are those developed by the RDS PDP WG.

·         Domain name control as a possible purpose: are name servers needed for this purpose? It is necessary for something, but maybe not domain name control.

Proposed WG Agreement #1 (to be confirmed via poll): Domain name control is a legitimate purpose for thin data collection.

·         Technical Issue Resolution as a possible purpose: status and expiration may also be relevant. Same set as elements for control may also be needed for resolution. May be difficult to decide which related data elements for this item. There will be an opportunity to update these elements down the road and/or combining some of the purposes if deemed appropriate.

·         Any elements in domain name control that shouldn't be included in technical issue resolution? No, duplicate elements for technicol resolution. Consider combining them? Might be helpful to keep them separate to be able to corrolate with EWG work (who did keep the two separate).

Proposed WG Agreement #2 (to be confirmed via poll): Technical Issue Resolution is a legitimate purpose for thin data collection.

·         Domain Name Certification as a possible purpose: should it be considered not a valid purpose of data - it is not ICANN's responsibility to support this industry as there are many other means to perform this action? Isn't that an argument for almost any use? Yes, would be appropriate to ask those questions as it is a clean slate approach. Are certificates and DNS-based validation of them required for secure, stable operation of the Internet? If only data elements needed are domain name and name servers, which are publicly available, it may not be needed.

·         To move forward WG will need a draft statement that we can survey for support for each "purpose" – aim to structure next poll accordingly.

4. Confirm action items and proposed decision points.