[gnso-rds-pdp-wg] Attendance, mp3 & AC recording GNSO Next-Gen RDS PDP WG call 17 May 2017 at 05:00 UTC
Nathalie Peregrine
nathalie.peregrine at icann.org
Wed May 17 08:03:31 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 Wednesday, 17 May 2017 at 05:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-17may17-en.mp3<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailer.samanage.com_wf_click-3Fupn-3DNrFWbrBstcrPWP369qgbqlXiSKeL20xnUXzI03ZqpsvgRhF8anYZT-2D2Fu85DJG3jGxkUremi-2D2BfaLM1BDCVwj-2D2BMJkNJQXY90hVSe26XyrkvLK4-2D3D-5FbE-2D2FoTL3xpeyRVrNxqAJXQ5-2D2Fc3sJwLoyf3pmXa1IzazbYz4-2D2Bd8qa-2D2FJrWpKIptw4WpH-2D2Bv8N5ihUeILy8hhfEZ0k6OieCmGDkoU70IAQv3trcfxXtX-2D2Fhd24YsmyQp3NfZxV31qsIoSxEQ7NTVGcmRDBW7rOASOzkff5omc3A312aJ5wC9bvbyLTK-2D2BKSpSUrB1hS2Yxqj92D-2D2FpxL6BiQIO87YZPwzSJmxDYVrcUp3ore-2D2BLATbbKj-2D2FA2JSPek8GhdDlHpnLG60gLB4f6btTcQEUmSqmOt8tiJk-2D2BBuGwHuFSPcFEr-2D2BW8bLwoXTuqS19bHeXTQ9OdAaOdluL5eCIDWnt3ZKPxQ6B4bsSlLY0rMZKPFy4bMe85zei4E-2D2B-2D2Bs93sPBP9nZX3lL-2D2Bl3-2D2Bfbk9Xgr0ZzE5V1uBawR4dakyse0Ij3jmFc0lwpiLqEhIX9xcLxX4ajNeATl8XrDFYmbZnVrFBk5d9bTvT-2D2Fdq1AhxZLaa4k7-2D2BOBa2iDgaRlynkbLWYf06G2j3p&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=PDd_FX3f4MVgkEIi9GHvVoUhbecsvLhgsyXrxgtbL10DTBs0i1jYiBM_uTSDzgqG&m=pv6I3s2IsrZa3ooSQr3tDN09hkKXw0U6YnjmnfLKdf4&s=qLubtGjl1hfd_rZb6zSyA1owTAyV_VZZFIw0jZUyXq0&e=>
AC recording: https://participate.icann.org/p1vpciiph1u/
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/HMPRAw
Thank you.
Kind regards,
Michelle
———————————————
AC Chat Next-Gen RDS PDP WG Wednesday, 17 May 2017
Michelle DeSmyter:Dear all, Welcome to the GNSO Next-Gen RDS PDP Working Group call on Wednesday,17 May 2017 at 05:00 UTC.
Michelle DeSmyter:Meeting agenda page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_HMPRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Eog9BciBokalwuPa-TgTeJMKfTibesj552YwyZJEn7Q&s=F7m-9N-dE2LFnSWJO_X_l63uB2Xs9RYclgE_VSqwJlQ&e=
Chuck Gomes:Greetings all
Benny Samuelsen / Nordreg AB:Morning
Stephanie Perrin:not hearing anything, is it me or are we just extra quiet tonight?
Lisa Phifer:All waiting for call to start
Jim Galvin (Afilias):@stephanie - extra quiet :-)
Maxim Alzoba (FAITID):Hello All
Vaibhav Aggarwal(NCSG)(New Delhi):Good Morning Team
andrew sullivan:I'm on. I'm in an airline lounge at HKG and will avoid talking. Also I'll have to drop in about an hour
andrew sullivan:(oh, and of course hello all :-) )
Benny Samuelsen / Nordreg AB:No sound here?
andrew sullivan:sound working for me
Michelle DeSmyter:Hi Benny, I will send you a private chat, if you are in need of a dialout
andrew sullivan:my experience is that the Adobe near-malware regularly wrecks audio on my machine, and if I kill the browser and restart it often that clears things
Benny Samuelsen / Nordreg AB:Will try restart sounds like hungry lions
Maxim Alzoba (FAITID):Question: it there an agenda of the tutotial / slidedeck going to be shared in advance?
Maxim Alzoba (FAITID):thanks
Benny Samuelsen / Nordreg AB:restart curred it
Lisa Phifer:Document displayed now: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078620_DataOfRecord-2DProposal.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Eog9BciBokalwuPa-TgTeJMKfTibesj552YwyZJEn7Q&s=9XRNW4qaGX6_qoazJfJzRlezpdM5x6htqRiSJgvJ1_I&e=
Lisa Phifer:Proposal in document: "2) A purpose of RDS is to facilitate dissemination of gTLD registration data of record, such as domain names and their domain contacts and name servers, in accordance with applicable policy.”
Lisa Phifer:Proposed Definition: "the data set at a given time relevant to a given registration object that expresses the data provided in the then-current registration for that object.”
Maxim Alzoba (FAITID):it was an attemt for+
David Cake:Thank you everyone
Lisa Phifer:Handout now being displayed: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078620_Charter-2520Question-25205-2520-2D-2520Handout-2520-2D-2520For17MayCall-2520v2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Eog9BciBokalwuPa-TgTeJMKfTibesj552YwyZJEn7Q&s=fE2iSBIH_bgrfx10m5V763WkQY2MiDmnbCpzRp5rIk0&e=
Lisa Phifer:Poll results summarized starting on slide 2
Maxim Alzoba (FAITID):it is minimal, identify themselfs -> without identification
Stephanie Perrin:themselves is the plural of itself. Perhaps add, "inquirers, be they human or entities"
Amr Elsadr:"gTLD registration "thin data" should be accessible without inquirers requiring identification"
andrew sullivan:There is no reason to suppose there is a "person" at the end of this at all
Jim Galvin (Afilias):SUGGESTION: gTLD registration "thin data" should be accessible without identification or stated purpose.
andrew sullivan:for instance, a mail system could use the RDS to detect new registrations
Amr Elsadr:"gTLD registration "thin data" should be accessible without inquirers requiring identification or stating their purpose"
andrew sullivan:(Registrations that are less than a day old are more suspicious as mail sources.)
Jim Galvin (Afilias):"without inquirer identification or stated purpose"
Lisa Phifer:gTLD registration "thin data" should be accessible without requiring identification of inquirers or statement of purpose?
Amr Elsadr:Proposed change "gTLD registration "thin data" should be accessible without inquirer identification or stating purpose".
Lisa Phifer:Note that we are developing requirements to guide policy development; these are not yet policies
Maxim Alzoba (FAITID)::)
Lisa Phifer:This is a proposed revision to the agreement of 2 May
Lisa Phifer:Does it make sense to combine option e) with this revised statement?
Lisa Phifer:For example, Proposed change "gTLD registration "thin data" should be accessible without inquirer identification, authentication, or stating purpose".
Greg Shatan 2:What's the point of changing "requestor" to "inquirer"?
Lisa Phifer:@Greg, inquirer was the term used in the 2 May agreement, but requestor is the term used in our charter - we should pick one
Maxim Alzoba (FAITID):removal of word identification and replacement to identificating
andrew sullivan:I don't care whether we call it requestor or inquirer, myself
Maxim Alzoba (FAITID):so we do describe process and not actor
Greg Shatan 2:Agree with Lisa that we need to be consistent. It says requester in. a lot of other places.
Greg Shatan 2:Requester and inquirer both identify the actor.
Amr Elsadr:@Andrew: Did you mean "without identifying inquirers"?
Stephanie Perrin:no we can't create words Chuck. we have enough problems...
Maxim Alzoba (FAITID):Identifying
Greg Shatan 2:Whatever we use it should be consistent across all uses.
Stephanie Perrin:nope
Patrick Lenihan:They are equivalent words.
Lisa Phifer:Is there a reason to introduce the new term "inquirer"
Benny Samuelsen / Nordreg AB:I would say requestor clearly define it is a request
Greg Shatan 2:Would a state actor be a "National Inquirer"?
Maxim Alzoba (FAITID):replacement of themself to requestors is good enough
Rod Rasmussen:LOL
Greg Shatan 2:Let's stick with requestor(s).
Lisa Phifer:Proposed change "gTLD registration "thin data" should be accessible without inquirer (or requestor) identification, authentication, or stating purpose".
Greg Shatan 2::-)
andrew sullivan:Then a theoretical example actor in our examples can be a Notional Inquirer :)
Greg Shatan 2:Oooh.
Alex Deacon:lets stick with requestor (v. inquirer)
Patrick Lenihan:Requestors is a stronger word.
Greg Shatan 2:Querier?
andrew sullivan:(It's not even the middle of the night for me -- I'm in HKG! -- but apparently I'm still giddy.)
Greg Shatan 2:"Clinical giddiness" is an actual diagnosis.
Lisa Phifer:Here's the current Proposed change "gTLD registration "thin data" should be accessible without requestor identification, authentication, or stating purpose".
Greg Shatan 2:That would be "the other Greg" (unless I am the other Greg).
Jim Galvin (Afilias):"stating purpose" --> "stated purpose" ??
Lisa Phifer:I hate to raise it but should should be must
Greg Shatan 2:I must agree with Lisa.
Tapani Tarvainen:should must be must
Stephanie Perrin:I thought we had agreed on must, should does not get us anywhere really...
andrew sullivan:I think we agreed about must, yes
David Cake:It is worth noting that a fully authenticated query can still satisfy the RFC definition of anonymity.
andrew sullivan:@David: see my note to the list, but that's only maybe true.
Lisa Phifer:Revamped Proposed change "gTLD registration "thin data" must be accessible without requestor identification, authentication, or stated purpose".
Jim Galvin (Afilias):@chuck - yes, all should be nouns - identification, authentication, or stated purpose
andrew sullivan:I think this is good enough
Jim Galvin (Afilias):I think this is good enough
andrew sullivan:since it doesn't actually use the word "anonymous"
andrew sullivan:fortunately :)
Lisa Phifer:Greg A has suggested in his poll response: "Access to thin registration data must be provided to anonymous requestors."
Jim Galvin (Afilias):and we don't ask for anything extra from the requestor
Stephanie Perrin:and therefore avoids explaining the lengths one might have to go to to make things anonymous...
Jim Galvin (Afilias):"anonymous" is a red herring
andrew sullivan:@Lisa: yes, and I think that creates a new definitional problem that we get around with the current words
andrew sullivan:because the current proposal says what the requestor does _not_ have to give, rather than trying to create an attribute of the requestor
Maxim Alzoba (FAITID):I think we'd better leave the process description and to avoid word anonymous at this stage
Alex Deacon:I think Lisa's "revamped" change covers things well - including anonymity.
andrew sullivan:agree
David Cake:In this statement, no we do not have to talk about anonymity. I suspect we will have to continue this conversation later in hte PDP though
Stephanie Perrin:Why do we need to define anonymous now? Thick data for LEA we may need to define anonymous and untraceable and a whole slew of things but we are only on thin data now, right?
Maxim Alzoba (FAITID):the defined process might be equal , but I do not think we need anonymity to be mentioned ...
Maxim Alzoba (FAITID):*equal to anonymity
David Cake:Nota ble that RFC definition does not necessarily match what many of us regard as true anonymity.
Farzaneh Badii:it's fun!
Tapani Tarvainen:I like herrings but not red ones.
Rod Rasmussen:Regular Herrings are tasty
Greg Shatan 2:I like matjes herrings.
David Cake:Whether or not true anonymity is possible, the use of privacy enhancing technology to complicate de-anonymisation is well outside current discussion.
Rod Rasmussen:Big +1 to Andrew/Jim
Greg Shatan 2:+2
Maxim Alzoba (FAITID):most probably yes
Rod Rasmussen:WRT Thin data? Probably not - with gated data, absolutely, so we don't get out of jail, but we can punt for now.
Stephanie Perrin:I was going to say no, but agree with Rod we need to later.
Tapani Tarvainen:+1 Rod & Steph
Maxim Alzoba (FAITID):so we might need to define it later (since we say that there is no authentification required for thin data)
andrew sullivan:We _will_ need to define it at some point
andrew sullivan:We do not right now, I agree with David
Maxim Alzoba (FAITID):+1 @Andrew
andrew sullivan:(sorry, I keep dropping, so I'm having a hard time following some of the voice questions.)
Alex Deacon:lts leverage an existing definition - no need to define something new.
Alex Deacon:s/its/lets
Lisa Phifer:@Alex, are you suggesting we adopt an existing definition
andrew sullivan:Once we want to say "you get access to $data if you have $credential" then we'll need to say what $credential means, and that will require some sort of def of authentication of $credential
Lisa Phifer:Proposed WG Agreement (to test with poll): "gTLD registration "thin data" must be accessible without requestor identification, authentication, or stated purpose".
Amr Elsadr:Proposed Statement: "gTLD registration "thin data" must be accessible without requestor identification, authentication, or stated purpose".
Alex Deacon:for authentication yes
David Cake:+1 to Andrew
Stephanie Perrin:ONe would hope we are going to use existing definitions....the question is which one.
andrew sullivan:and yes, it's not like there are no bodies out there who can tell us what authentication and authorization is :)
andrew sullivan:Given that any new RDS that can do credential-based stuff is going to use OpenID and OAuth, we should follow those defs
Lisa Phifer:slide 6 has the IETF definition for authentication
Maxim Alzoba (FAITID):side note ... GDPR might be a good reason for THIN data to exist after may 2018 , hypothetically for current THICK Registiries
andrew sullivan:"The IETF definition for authentication" is somewhat more complicated, but we don't need to explore that rathole today :)
Sara Bockey:i need to drop. thanks all. good discussion
Benny Samuelsen / Nordreg AB:Problem, we havent clearly defined the thin data
Greg Shatan 2:Can we restate the question?
Lisa Phifer:@Greg, do you agree with Proposed WG Agreement (to test with poll): "gTLD registration "thin data" must be accessible without requestor identification, authentication, or stated purpose".
Greg Shatan 2:Thanks, I've green checked.
andrew sullivan:sorry, was trying to clear checkmark :)
marksv:sorry
Lisa Phifer:yes chuck for those two proposed agreements
Amr Elsadr:I believe so, Chuck.
Stephanie Perrin:actually Benny, since we have said early according to policy, that policy may remove some data elements from the thin dtta
Greg Shatan 2:"sloppy hand" is a new one....
David Cake:+1 to Andrews popint about using a defn of authentication that aligns with the technology that will be used to implement it.
Lisa Phifer:Slide 7 corresponds to the next agenda item d)
Maxim Alzoba (FAITID):at which slide are we now?
Amr Elsadr:@Maxim: Agenda item 4(d) is on slide 7. We're about to get to that now.
Amr Elsadr:@Maxim: But Greg and Stephanie are still discussing the proposed statement for the poll on requestor identification, authentication and purpose statement.
Lisa Phifer:Note slide 1: We still need to finish deliberating on purpose and data elements to agree upon required "thin data" elements and their purpose
marksv:Now we know how Greg reads his fortune cookies
Lisa Phifer:Everyone jump to slide 7
andrew sullivan:I'm afraid I have to drop because I have to go find an airplane
andrew sullivan:apologies & bye all
marksv:bye
Maxim Alzoba (FAITID):new profession " CAPTCHA recognition operator" :)
Greg Shatan 2: Need to drop as well. Bye all. I am not a robot.
Lisa Phifer:Comments from those who agreed and disagreed revolved around what reasonable and unreasonable restrictions might be
Benny Samuelsen / Nordreg AB:Greg going to read fortune cookies?
Maxim Alzoba (FAITID):I think legitimate is well defined in laws
Greg Shatan 2:... in bed.
Stephanie Perrin:How would that apply here though Maxim?
Maxim Alzoba (FAITID):I mean we do not need to define it here
Lisa Phifer:"legitimate purposes" were identified when we deliberated on purpose, we still need to go back to that list
Maxim Alzoba (FAITID):the reason is -> we discuss future policy -> it comes with a contract ... most our contracts have provision of prohibition of illegal activities
marksv:what sort of gaming? I don't have that context
Maxim Alzoba (FAITID):100k requests per minute is a danger to infrastructure
Maxim Alzoba (FAITID):of small parties
Lisa Phifer:This clause from the RAA may be somewhat relevant: 3.3.5 In providing query-based public access to registration data as required by Subsections 3.3.1 and 3.3.4, Registrar shall not impose terms and conditions on use of the data provided, except as permitted by any Specification or Policy established by ICANN. Unless and until ICANN establishes a different Consensus Policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, postal mail, facsimile or other means of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations
Maxim Alzoba (FAITID):and 1M per minute equal a DDoS
Rod Rasmussen:gaming may not be the best word - but putting artificial restrictions on access in the name of "systems protection" that really provide unreasonable limits on data access.
Stephanie Perrin:I distinctly recall Michele saying he did not want to be restricted from rate limiting, but perhaps I have miscontrued that....
Rod Rasmussen:For example, after my IP address (which could be a gateway!) hits 100 queries in a day, I no longer get access. Seen these before.
Maxim Alzoba (FAITID):Registries and Registrars need means to protect infrastructure
Rod Rasmussen:This issue conflates the concepts of "reasonable access" with "systems protection" - what do those mean?
Rod Rasmussen:@Maxim - absolutely agree they need protection.
Jim Galvin (Afilias):perhaps rather than saying something about rate-limiting per se, we need an SLA about the level of access that must be supported.
Tim Chen:+1
Tim Chen:rate limiting already happens today, without any new language or permission needed. I'm more concerned about the opposite. as per Rod and Jim.
Maxim Alzoba (FAITID):@Jim, Do we have evidence that we need it (SLA)?
marksv:I'm hearing examples of legit efforts to protect infra -not really any examples of rate limiting as a means to block or obfuscate access
Maxim Alzoba (FAITID):I mean the way to test load is to put additional load ...
Lisa Phifer:Note Jim's comment: perhaps rather than saying something about rate-limiting per se, we need an SLA about the level of access that must be supported.
Rod Rasmussen:Time for a cage match!
Jim Galvin (Afilias):@maxim - maybe not. just making suggestions.
Stephanie Perrin:my rationale is that we have just agreed a statement that is silent on it and demands access. I think we have to qualify it somehow without getting into detail.
Lisa Phifer:Red if you oppose statement in Q3: There must be no RDS policies that prevent RDS operators from applying operational controls such as rate limiting and CAPTCHA, provided that they do not unreasonably restrict legitimate access.
marksv:ha
Rod Rasmussen:Mortal Kombat
Maxim Alzoba (FAITID):we could declare strong non-opposition
Stephanie Perrin:we are still punting the concepts of legitimate and "unreasonably restrict" down the road
Vaibhav Aggarwal:+1 ROD
Stephanie Perrin:plus there appears to have been no enforcement of the bulk data acccess rules in the RAA, right?
Maxim Alzoba (FAITID):I think refrerence to "reasonable " will lead to situation where unhappy party can complain that the access is not provided without proper reasoning .. and it is good
Vaibhav Aggarwal:I volunteeer
Vaibhav Aggarwal:Yes as we can out some research and specific case examples to draw conclusions
Vaibhav Aggarwal:also basis on the different geographies
Lisa Phifer:Chuck, to clarify - you are not asking for a policy that states what is reasonable, but rather what reasonable means in this statement?
Vaibhav Aggarwal:I will be happy to commit to Rod's time zone
Vaibhav Aggarwal::-)
Vaibhav Aggarwal:Sure
Stephanie Perrin:the term is unreasonably restrict, right?
Maxim Alzoba (FAITID):holywar style e-mail flaim ?
Stephanie Perrin:which is different than reasonable access
Vaibhav Aggarwal::-)
Rod Rasmussen:Probably - we'll see
Vaibhav Aggarwal:We could come up with Questions in the due course
Stephanie Perrin:if you find that attempts to restrict access at the moment are IP address related, does that go back to our previous commitment ?
Rod Rasmussen:@Vaibhav - see private chat question I sent you
Amr Elsadr:Next week's tutorial webinar will take place immediately following the WG call for one hour.
Maxim Alzoba (FAITID):bye all
Jim Galvin (Afilias):bye - thanks all
Amr Elsadr:Thanks all. Bye.
Patrick Lenihan:Thanks to Each and All!
Stephanie Perrin:Bye!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170517/43539501/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RDS Attendance 17 May 2017.pdf
Type: application/pdf
Size: 84497 bytes
Desc: RDS Attendance 17 May 2017.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170517/43539501/RDSAttendance17May2017-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list