[gnso-rds-pdp-wg] Recordings, Attendance & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 30 May 2017 at 16:00 UTC
Michelle DeSmyter
michelle.desmyter at icann.org
Tue May 30 18:31:39 UTC 2017
Dear All,
Please find the attendance of the call attached to this email and the MP3 recording below for the Next-Gen RDS PDP Working group call held on Tuesday, 30 May 2017 at 16:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-30may17-en.mp3
AC recording: https://participate.icann.org/p4pshwjvr6e/
The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page:
http://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group-2Dactivities_calendar-23nov&d=DwMF-g&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=PDd_FX3f4MVgkEIi9GHvVoUhbecsvLhgsyXrxgtbL10DTBs0i1jYiBM_uTSDzgqG&m=GJMkY4Fbi9sry9Z53DaSWJm-mHxMfFxg7MEVDf2JU90&s=FI3QJYH6DWWCDQir6NDMSjPkzdqfTTUmf9Ua-AYpc14&e=>
** Please let me know if your name has been left off the list **
Mailing list archives:http://mm.icann.org/pipermail/gnso-rds-pdp-wg/
Wiki page: https://community.icann.org/x/IMPRAw
Thank you.
Kind regards,
Michelle
———————————————
AC Chat Next-Gen RDS PDP WG Tuesday, 30 May 2017
Michelle DeSmyter:Dear All, Welcome to the Next-Gen RDS PDP Working Group call on Tuesday, 30 May 2017 at 16:00 UTC.
Michelle DeSmyter:Meeting agenda page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_IMPRAw&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=gu_xEc0jIs-PVSa5yroc8eEfOjJfVo3EC4pHM_zlePM&s=ufGTX1fqLWMXlb4Z0cB1qHkIpQD-8ArT4lIrL9BJxd8&e=
Chuck Gomes:Hello all
Lisa Phifer:Document currently displayed: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078622_AnnotatedResults-2DPoll-2Dfrom-2D17MayCall.pdf&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=gu_xEc0jIs-PVSa5yroc8eEfOjJfVo3EC4pHM_zlePM&s=x5hsuUZWzQ4oP4DhClgm3vt5pODGKY08o9xRa_CBudc&e=
Lisa Phifer:Q3 starts on page 4
Juan Manuel Rojas:Good morning/afternoon/evening
Rod Rasmussen:In now - looks like I have a bad link that still works for getting "close" to logging into this meeting. Odd
Benny Samuelsen / Nordreg AB:could someone close the Poll 2 window
Benny Samuelsen / Nordreg AB:thanks
Stephanie Perrin:apologies for being late.
Lisa Phifer:If anyone does not support option A) please raise hand
Lisa Phifer:Q3) option a) is A minimum set of "thin data" elements must be accessible by unauthenticated RDS users.
Greg Shatan 2:@Stephanie, Huzzah! Let's set a new Canadian holiday.
Lisa Phifer:Agreement #20 was discussed for the past few weeks, and is: "gTLD registration 'thin data' must be accessible without requestor identification, authentication, or stated purpose."
Lisa Phifer:Charter question on data elements is intended to address what data elements are needed
Lisa Phifer:The EWG defined a "minimum public data set" in its answers to the Data Elements charter question
Lisa Phifer:The EWG did not deal with "thin data" as a category but today's thin data elements are in the EWG's minimum public data set
Greg Shatan 2:But none of us know what it means....
Bill Fanelli:Substitute "as yet to be defined" for minimum.
Michael Hammer:Regardless of whether we leave it in or take it out, we are going to have to cross that bridge.
Stephanie Perrin:Thanks and sorry Lisa, I dont pay enough attention to how we number things....
Greg Shatan 2:"defined" would be better than "minimum."
Benny Samuelsen / Nordreg AB:Suggestion: A minimum set of "thin data" elements, agreed on as a minimum standard, must be accessible by unauthenticated RDS users
Stephanie Perrin:Yes it would be better, I agree with greg
steve metalitz:+1 Greg and Stephanie (another rare entry!)
Michael Hammer:Does "defined" allow additional data elements beyond "defined"?
Greg Shatan 2:Defined set can always be redefined, by the same process.
Lisa Phifer:Proposed alternative: A defined set of "thin data" elements must be accessible by unauthenticated RDS users.
steve metalitz:"At least a defined set..." ?
Stephanie Perrin:Bearing in mind that we have not described the mechanism by which we make the data elements accessible
Lisa Phifer:Proposed alternative redux: At least a defined set of "thin data" elements must be accessible by unauthenticated RDS users.
Michael Hammer:I could live with this...
Greg Shatan 2:I suggest reading "A Framework and Standardized Methodology for Developing Minimum Clinical Datasets" by Swenson-Ranallo, Adam & Sainfort.
Greg Shatan 2:"The term "minimum dataset" or MDS is a commonly used, but poorly defined, term...
Lisa Phifer:Q5 starts on page 8
Lisa Phifer:I think people are reading "stated purpose" differently - 1) must a purpose be stated in policy, vs. 2) must a purpose be supplied with each query
Volker Greimann:the purposes for the requester must be aligned with the purpose of the collection/provision
Lisa Phifer:Note that we already agreed to these concepts:
Lisa Phifer:WG Agreement #2: Every "thin data" element should have at least one legitimate purpose.WG Agreement #3: Every existing "thin data" element does have at least one legitimate purpose for collection.
Lisa Phifer:Do we need to re-poll or do we have sufficient agreement?
Lisa Phifer:Proposed WG Agreement (to be confirmed by poll): "To deter misuse and promote accountability, RDS policy must state purpose(s) for public access to "thin data."
Michael Hammer:deter is not the same as prevent. Probably closer to mitigate.
Lisa Phifer:Requestors could be presented with terms of service, for example, without having to state purpose on query
steve metalitz:Can math majors confirm that 19-4 does not = 16?
steve metalitz:(on page 6)
Lisa Phifer:Ok steve, I double checked my math but you found one!
steve metalitz:I figured there were not arithmetic majors on the call.....
Lisa Phifer:@Steve, I happen to be a math major myself, but apparently one with increasingly poor eyesight :-)
Stephanie Perrin:I will never forget the blessed relief of dropping stats at Christmas in first year.....
Stephanie Perrin:(although I will admit to regretting not having finished it occasionally. Still, there is some pain not worth enduring,.......)
Lisa Phifer:If I recall, this was to discourage tiered access - those who pay more get more access (faster, broader)
Rod Rasmussen:@Michele - I prefer red wine as the best way to give yourself a headache. You're guaranteed one if you're drinking it while reviewing ICANN policy docs. ;-b
Michael Hammer:Would that be QoS (Quality of Service)?
Lisa Phifer:Note this is not yet policy - it is stating a goal for policy yet to be defined
Volker Greimann:How about "non-discriminatory access for all permissable uses"
Stephanie Perrin:you are a lot geekier than me Michele.....
Stephanie Perrin:and I like Volker's formulation....
Michele Neylon:we're still talking about thin data
Michele Neylon:so I don't see the aggregation as an issue
Michele Neylon:only for thin
Michele Neylon:I do with thick :)
Michael Hammer:Who decides what are "permissable uses"?
Lisa Phifer:Volker's proposal: "RDS access to "thin data" must be non-discriminatory access for all permissable uses" (for consistency with other agreements that should be legitimate purposes not permissible uses)
Stephanie Perrin:I am not sure that we do need it, once we have said that we must provide unauthenticated (non-identified) access to thin data. I agree with Lisa that it seems likely in the EWG that we were trying to make sure access was not tiered on the basis of $$ or power.
Lisa Phifer:Red X if no principle is needed
Lisa Phifer:Green check if some principle is needed
Stephanie Perrin:Let the records show Steve and I agree, this is a red letter day indeed!
Michael Hammer:I think a broad principle is needed but we shouldn't get in the weeds.
Rod Rasmussen:And does such a principle cause *problems* if included or is it just a confirmation of one of ICANN's AOC's?
Michael Hammer:RDS access to "thin data" must be non-discriminatory.
Stephanie Perrin:Having said this, I could live with Volker's language.
Michael Hammer:How do we know their "purpose"?
Stephanie Perrin:Non-discriminatory is a pretty big word. One has to be clear in policy that one can take action to deter misfeasance
Lisa Phifer:Proposed alternative redux: RDS access to "thin data" must be non-discriminatory
Michael Hammer:misfeasance?
Michael Hammer:I'd leave that to lawwyers and torts.
Lisa Phifer:Another: RDS policies for access to "thin data" must be non-discriminatory (i.e., create a level playing field for all requestors)
Lisa Phifer:Chuck with or without ie?
Lisa Phifer:Green check if you support: RDS policies for access to "thin data" must be non-discriminatory
Lisa Phifer:Red X if you do not support the above
Stephanie Perrin:for all permissible purposes
Lisa Phifer:@Stephanie, does for all legitimate purposes work? For consistency with other agreements
Michael Hammer:I have a problem with that modification.
Lisa Phifer:Green check if you support: RDS policies for access to "thin data" must be non-discriminatory for all permissible purposes
Michael Hammer:Putting a red X for the modification.
Nathalie Coupet:But, is it really necessary to add 'permissible puroses, if you cannot verify that such purposes are legitimate?
steve metalitz:are we re-polling with Stephane's modification?
Nathalie Coupet:purposes
Michael Hammer:Exactly what Nathalie wrote.
Lisa Phifer:Green check if you support: RDS policies for access to "thin data" must be non-discriminatory for all legitimate purposes.
Lisa Phifer:You can state terms of service with purposes that are allowed/disallowed and take steps to enforce ToS, just as WHOIS does today
Volker Greimann:But if we figure out their purpose, we then have a handle, in case it is abusive or illegitimate
Volker Greimann:who is King Canoot?
Stephanie Perrin:Exactly as Volker says
steve metalitz:@Volker, Canute
Benny Samuelsen / Nordreg AB:sound drops
Michael Hammer:https://en.wikipedia.org/wiki/King_Canute_and_the_waves
Volker Greimann:IP addresses are personal data now
Bill Fanelli:Legitimate or permissable - we should use whichever term we can define
Volker Greimann:depending on how the data is used, this may become personal data as well
Stephanie Perrin:I am confident that there are some jurisdictions that will want to know the purpose. I am confident that an investigation into a data aggregation operation that is criminal in nature would inquire as to how the aggregator got the data, some of which can only come from ICANN accredited providers.
Michael Hammer:Then the jurisdiction should investigate the purpose.
Stephanie Perrin:Sure, the point is that there is merit in ICANN attempting to do the right thing
Lisa Phifer:Suggest we poll on the statement as last revised
Benny Samuelsen / Nordreg AB:Have to leave this meating, conflicting meeting coming up. Have fun...
Nathalie Coupet:I have a sore throat
Nathalie Coupet:Can't talk sorry
Nathalie Coupet:I can type
Nathalie Coupet:I thought it would be best to include this principle as soon as possible, since it is central to the GDRP, and not wait until later
Tom Undernehr:I was in support of Natalie's recommendation
Lisa Phifer:Perhaps propose a principle on proportionality to the WG list for discussion
steve metalitz:@Nathalie, how does this apply to thin data?
Nathalie Coupet:Data that is not absolutely necessary for a query shpould not be shared
Nathalie Coupet:Data has to be useful for the query
Nathalie Coupet:efficient
Michael Hammer:not sharing and efficient are orthongonal issues
Nathalie Coupet:What I meant, that only the data needed should be shared.
Lisa Phifer:@Rod, is your goal to provide an overview of existing policy that would support this proposed requirement?
steve metalitz:@Rod how is it handled at ICANN's lookup facility, https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.icann.org_en-3F&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=gu_xEc0jIs-PVSa5yroc8eEfOjJfVo3EC4pHM_zlePM&s=hHc5Z1osunsHeaOeGQ_Nx6_fOhtBGMYY0aIYERi2XgU&e=
Rod Rasmussen:@Lisa - perhaps - it depends on what the "existing policy" actually consists of - you may have seen the write-up I did of relevant secstions of the RAA, RA, and ICANN Compliance reports, but the "ground truth" of what ICANN compliance is actually testing to/enforcing is murky at best. If there's good documentation that seems to cover this well, great. We may want to tweak something that exists and bring it into the light though to help guide implementations down the road.
Rod Rasmussen:@Steve - great question! I'll add that to my research regime.
Lisa Phifer:@Rod, my point was that we're not yet developing policy or implementation guidance on this requirement, but you're gathering current info to help us understand the proposed requirement, correct?
Rod Rasmussen:Yes, but it ties into the current job of defining "reasonable access" while taking into account that data providers can use measures to protect their systems. It's an open question now, but that "meta principle" probably then has a pointer to whatever we decide on is guidance in this area.
Lisa Phifer:@Rod, we still need to return to that proposed WG agreement to finalize it, once you deliver your summary - let's be sure to keep this tied to the proposed WG agreement when you email the WG list. Thanks!
Stephanie Perrin:WE could certainly work on better questions and send them to the leadership team. Also happy to comment on which ones we should cull.
Lisa Phifer:If we contract legal analysis on those questions now, we will have a chance at getting responses by fall, prior to trying to answer the foundational question in our first initial report
Lisa Phifer:It does not preclude further legal analysis on additional questions later
Stephanie Perrin:REsponses by fall? that seems awfully slow...
steve metalitz:Have to drop off now, thanks all!
Michele Neylon:I need to drop
Michele Neylon:see you
Lisa Phifer:@Stephanie, 2-3 months to select a legal team, contract with them, set SOW, and complete the work is pretty short actually
Lisa Phifer:Please response to poll on screen now regarding ICANN59 F2F meeting date
Kiran Malancharuvil:Is there a "submit" button?
Lisa Phifer:Yes = changing to Wednesday would affect you negatively
Lisa Phifer:No = keeping F2F on Tuesday would be ok for you
Amr Elsadr:Missing a comma.
Marika Konings:Say no - if you can participate on Wednesday - say yes, if you cannot participate on Wednesday :-)
Amr Elsadr:"Should this change be made, would this affect your ability to participate in the meeting..."
Michael Hammer:Dropping off.
Rod Rasmussen:I'm even more confused now. :-(
Marika Konings:We'll send out a doodle poll after this meeting with a better phrased question. Sorry about the confusion :-(
Rod Rasmussen:Thanks!
Nathalie Coupet:thank you! bye
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170530/607b8597/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 30 May 2017 Sheet1.pdf
Type: application/pdf
Size: 33034 bytes
Desc: Attendance RDS PDP 30 May 2017 Sheet1.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170530/607b8597/AttendanceRDSPDP30May2017Sheet1-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list