[gnso-rds-pdp-wg] Recordings, Attendance & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 06 June 2017 at 16:00 UTC

Michelle DeSmyter michelle.desmyter at icann.org
Tue Jun 6 19:36:54 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, 06 June 2017 at 16:00 UTC.

MP3: https://audio.icann.org/gnso/gnso-nextgen-rds-pdp-06jun17-en.mp3

AC recording: https://participate.icann.org/p6sxtd7tffa/

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/IsPRAw



Thank you.

Kind regards,

Michelle



———————————————



AC Chat Next-Gen RDS PDP WG Tuesday, 06 June 2017

 Michelle DeSmyter:Dear All, Welcome to the Next-Gen RDS PDP Working Group call on Tuesday, 06 June 2017 at 16:00 UTC.
  Michelle DeSmyter:Agenda meeting page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_IsPRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=rPqD8E1biXblps9v4qbDoT_pZ1h5Tk0-ljod6POMRvs&e=
  Maxim Alzoba (FAITID):hello all
  Michelle DeSmyter:Dear All Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday, 06 June 2017 at 16:00 UTC.
  Michelle DeSmyter:Meeting agenda page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_IsPRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=rPqD8E1biXblps9v4qbDoT_pZ1h5Tk0-ljod6POMRvs&e=
  Chuck Gomes:Hello all
  Jonathan Matkowsky:I can't hear so I will try to dial in on the phone
  Lisa Phifer:We'll be starting in about a minute
  andrew sullivan:I hope Adobe is sufficiently embarrassed by the slide that is currently displayed.
  Jonathan Matkowsky:lol
  Volker Greimann:Update: I have been selected as WHOIS2 Review Team Member
  Lisa Phifer:Annotated Results: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078626_AnnotatedResults-2DPoll-2Dfrom-2D30MayCall-2Dv2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=ggRU84s-fr3s8kTqK0kJ2oBHGc-uHwoNOpjDNUXvDqY&e=
  Lisa Phifer:Q2 is on slides 2-3
  Lisa Phifer:Q3 is on slides 4-5
  Lisa Phifer:Note that this the Board-initiated Policy Development Process (PDP) to define the purpose of collecting, maintaining and providing access to generic Top-Level Domain (gTLD) registration data and consider safeguards for protecting that data, determining if and why a next-generation Registration Directory Service (RDS) is needed to replace WHOIS
  andrew sullivan:Given that we've agreed that for this data there's going to be no control, this whole discussion about purpose seems like angels on a pinhead
  Michael Hammer:Thin data is being collected and disseminated to meet the following goals and purposes...
  Lisa Phifer:@Jonathan, I think you are responding to the EWG principle and not the proposed agreement
  Lisa Phifer:Proposed WG Agreement: RDS policy must state purpose(s) for public access to "thin data.”
  Vicky Sheckler:agree w/ chuck on this one
  Jonathan Matkowsky:@Lisa, you are right.
  Jonathan Matkowsky:I think that's why I didn't disagree, actually.
  Jonathan Matkowsky:I am good with this
  Michael Hammer:I agree with Jim.
  Lisa Phifer:As we move to the next charter question, we'll review WG agreements already made on specific purposes for collection
  Roger Carney:I think Jim is on the right track
  Greg Shatan:To clarify, I wasn't stating that the registrant had to state the purpose for which their data could be accessed. Rather that the registrant's knowledge of the purpose for collection and/or access may limit the purpose for which the data will be accessed down the road.
  Lisa Phifer:Q4 is on slides 6-7
  Lisa Phifer:Proposed alternative: RDS policies for access to "thin data" must be non-discriminatory (i.e., RDS policies must not be designed to give anyone preferential access).
  Sam Lanfranco npoc/ncsg:For me "non-discriminatory" means "no gates"
  Tim OBrien:hello all, appologies for the tardyness - client meeting went long
  andrew sullivan:I think we don't need it,
  Greg Shatan:What is the practical purpose for, or problem with, this statement?
  Lisa Phifer:In last week's poll results, 10 people said the principle wasn't needed.
  andrew sullivan:I just don't see what it adds.
  Bill Fanelli:We provide discriminatory access to unauthenicated users on our web site all the time.  Primarily we detect that they are bots performing scraping and at least throttle them.
  andrew sullivan:It's a wheel that does no work
  andrew sullivan:@Bill: we already have excluded from the discussion technical defenses of services
  andrew sullivan:which is what that is
  Michael Hammer:Does one need to be authenticated in order for there to be QoS (Quality of Service) or discrimated service? The answer is no.
  Michael Hammer:If a registrar had their paid customers cookied and gave them preferential service, would that be acceptable absent such a statement of principle?
  Michael Hammer:Just throwing out examples of why a non-discrimination statement may be appropriate.
  steve metalitz:@Jim if this is not in scope, why are we awaiting report back from Rod and VA on preventing CAPTCHA/rate limiting from being applied to discriminate?
  Lisa Phifer:As a reminder, the Proposed alternative: RDS policies for access to "thin data" must be non-discriminatory (i.e., RDS policies must not be designed to give anyone preferential access).
  steve metalitz:Agenda item 2(c)
  Jim Galvin (Afilias):@michael - I still count those as operational issues.
  andrew sullivan:I hope very much that this WG does not think that user interface design is anywhere remotely close to the remit of this group
  Maxim Alzoba (FAITID):be back in 10 mij
  Jim Galvin (Afilias):@steve - I missed last week. That action isn't clear to me either but I figured I would wait for the report and then see where there that takes us.
  Jim Galvin (Afilias):@steve - i see CAPTCHA/rate-limiting as an operational issue and I separate that from discrimination.  YMMV
  Lisa Phifer:Repeating for easy reference: Proposed alternative: RDS policies for access to "thin data" must be non-discriminatory (i.e., RDS policies must not be designed to give anyone preferential access).
  Jonathan Matkowsky:@Lisa - that proposed alternative makes sense
  Michael Hammer:What Lisa proposes matches where I'm coming from.
  Greg Shatan:That has a "net neutrality" ring to it....
  Jim Galvin (Afilias):@lisa - I would prefer that we replace non-discriminatory with the more specific phrase directly
  Bill Fanelli:Since it is about being non-preferential, then perhaps say that instead of non-discriminatory.
  Jonathan Matkowsky:@Steve - Excellent point.
  Lisa Phifer:Another possible alternative might be: RDS policies must not be designed to give anyone preferential access to gTLD registration data.
  Jim Galvin (Afilias):@lisa - and now my question is what effect does this have on "bulk access"?  (not necessary for you to answer, more for discussion)
  Lisa Phifer:@Andrew, because everyone gets unauthenticated access, does that prevent giving a select few preferrential access that IS authenticated?
  Bill Fanelli:@Andrew - very good point
  Jonathan Matkowsky:After what Andrew said, that makes sense, and I am not comfortable with the alternative proposal for that reason
  andrew sullivan:@Lisa: I hope not, which is what I'm confused about :)
  Lisa Phifer:The EWG actually did intend this principle to stop provision of preferrential (faster better) access to some but not others who also have legit access to the same data for the same purpose
  Lisa Phifer:But I should also note this EWG principle wasn't specific to thin data or public access
  Jonathan Matkowsky:@Jim Exactly, the POLICY has to be non-discriminatory.
  Greg Shatan:A-HA!
  Jonathan Matkowsky:But you can't discriminate if you are not authenticating
  Stephanie Perrin:Unfortunately I think we have focused on legitimate purposes as a policy means to authorize or not  what I see as legitimate operational concerns.
  andrew sullivan:I think it would be madness to make a requirement that everyone has to get the same level of access.
  Volker Greimann:again with the bad actors
  Volker Greimann:who do you mean?
  Lisa Phifer:@Andrew, why
  Volker Greimann:Nick Cage?
  Bill Fanelli:@Lisa - Did the EWG care if the access was authenticated vs unauthenticated?
  andrew sullivan:The _whole point_ of authentication may be to ensure higher-quality access.  For instance, I know mail admins who would cheerfully authenticate and make queries for small subsets of the RDS data as long as they could be sure of a high-rate connection
  Lisa Phifer:@Bill, unauthenticated access was provided to the minimum public data set, but authenticated access was required to gated data and allowed to all data in the EWG recommendatinons
  andrew sullivan:as opposed to one that is rate limited
  andrew sullivan:I know one colleague who used this very example during the WEIRDS discussions that produced RDAP
  Bill Fanelli:@Lisa - Would allowing a different class of access to thin data to an authenticated be counter to what the EWG was trying to ensure?
  Lisa Phifer:@bill, I think so  yes, but that is my recollection of where the principle came from and there could be other interpretations
  steve metalitz:@Lisa, that suggests that non-discrmination does not apply here where "permissible purpose" for access does not apply
  Lisa Phifer:Displayed now on screen: slide 2 of Handout: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078626_RDSPDP-2DHandout-2DFor6JuneCall.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=iBHaqUVB2PCwulQa5AdwMl_Mzi5INlktlAdzg7YZTJY&e=
  Lisa Phifer:@Steve, in EWG report, all access is based on purpose (including unauthenticated access to the min public data set), so I think the question for this WG is whether preferrential access should be allowed to thin data or not
  andrew sullivan:I agree with Jim, and I think I've said this more than once in more and less detail on the list.
  steve metalitz:@Lisa, isn't the questoin for this WG whether to follow EWG on that point ("all access is based on purpose")?
  andrew sullivan:I think, though, that you can say, "Let's suppose there _were_ things in thin data that needed the principle, does it change what we'd do?"
  Lisa Phifer:@Steve, agree this WG has still to develop agreements on purposes for access - my point however was that to address the proposed agreement discussed under the previous agenda item, this WG needs to focus on whether or not preferrential treatment should be allowed by policy
  andrew sullivan:The answer here is in any case no, so the point is that _regardless of_ whether you think there's PII here it makes no difference
  andrew sullivan:because we'd do the same thing regardless
  Jonathan Matkowsky:@greg - it's like in con law, where we would be asking whether we can satisfy the compelling interest standard when there's no protected class
  Greg Shatan:It's not that I can't, it's that doing so implies agreement that the Principle of Proportionality applies.
  Lisa Phifer:If public access to "thin data" can be shown to be proportional, isn't that useful for all, including those in jurisdictions where elements are not PII AND those who may be in juridictions that treat some elements as PII?
  Greg Shatan:A public directory does not make this a "public act."
  Luc Seufer:The processing of personal data should be designed to serve mankind. The right to the protection of personal data is not an absolute right; it must be considered in relation to its function in society and be balanced against other fundamental rights, in accordance with the principle of proportionality. This Regulation respects all fundamental rights and observes the freedoms and principles recognised in the Charter as enshrined in the Treaties, in particular the respect for private and family life, home and communications, the protection of personal data, freedom of thought, conscience and religion, freedom of expression and information, freedom to conduct a business, the right to an effective remedy and to a fair trial, and cultural, religious and linguistic diversity.
  Vicky Sheckler:apologies - i need to run
  Luc Seufer:REGULATION (EU) 2016/679
  Lisa Phifer:To Stephanie's point:  If public access to "thin data" can be shown to be proportional, isn't that useful for all, including those in jurisdictions where elements are not PII AND those who may be in juridictions that treat some elements as PII?
  Greg Shatan:The argument may be raised that the PoP will be applied to thin data. That doesn't mean that it will be a winning argument.
  Michael Hammer:If the thin data information is publicly available anyways in the functioning of the internet (DNS), then it isn't a function of proportionality, it is a function of operational functionality.
  Greg Shatan:@Luc, we're not talking about personal data here.
  Volker Greimann:As the principle of proportionality is a general principle of EU law in general, not just data protection, it will apply
  Greg Shatan:@Lisa, that assumes that there are jurisdictions that will treat any part of thin data as personal data.
  Greg Shatan:But what does it apply to, Volker?
  Lisa Phifer:@Greg, no my point is that IF any jurisdiction treats a data element in thin data as PII, now or in the future, then having passed the test is useful
  Lisa Phifer:And doesn't hurt those in other jurisdictions
  Greg Shatan:Thin data is not supplied by the registrant.
  Stephanie Perrin:Is the domain linked to an individual in the registrars records?
  Stephanie Perrin:I believe the answer to that is yes
  andrew sullivan:Some thin data is provided by the registrant.  The registrant provides the domain name and possibly the nameservers
  Greg Shatan:@Lisa, the "IF" is exactly the issue.
  Alex Deacon:but not all registrations are associated with individuals.    some are.  some are not.
  andrew sullivan:but it doesn't matter, as we already determined, because we do the same thing _regardless_ of whether this principle applies
  andrew sullivan:so it does not matter
  Stephanie Perrin:It does not have to be supplied by the registrant.  My phone number is assigned by the telephonecompany, still my personal data
  Stephanie Perrin:The point is important Andrew, I am afraid, this is why I cannot let it go.
  Greg Shatan:As long as it doesn't matter @Andrew, I'm happy.  Let's just see if it matters.
  Stephanie Perrin:The result, as you point out, is the same.
  andrew sullivan:@Stephanie: why is it important?  If it literally has no effect on what you do, who cares why one is doing it?
  Lisa Phifer:This is in current RAA RDDS example: DNSSEC: signedDelegation
  Lisa Phifer:Additional fields defined in RAA now include Registrar Abuse Contact Email and phone number, DNSSEC, and URL of the ICANN WHOIS Data Problem Reporting System
  Stephanie Perrin:The concept of personal data as it relates to RDS data refers to the data set that the registrar holds about the registration.  If we start picking certain data elements out of a collection of data and label them as not personal information, we are destroying the concept.  SO take expiration data, that is directly related to the choices I have made with respect to the registation, it relates to me.
  Lisa Phifer:See either RAA itself, or DE-D06-R08 in our possible requirements list
  Stephanie Perrin:I recommend we include the question in our questions to the lawyers.
  andrew sullivan:The example there is an example of a thin response I obtained while in Copenhagen
  andrew sullivan:and it's of a domain name that I registered
  Lisa Phifer:The example given comes from Andrew Sullivan's domain name, but the RAA defines additional fields today
  andrew sullivan:the additional fields come from the registrar and are part of the thick resoonse, AFAICT
  Alan Greenberg:NNoting that thin data has evolved is a good footnote.
  Alan Greenberg:but no need for any more
  Lisa Phifer:@Andrew, are all 4 additional elements "thick" and where is this specified? Thanks
  steve metalitz:So are we proposing that certain data elements  now considered to be thin data be REMOVED  from (unauthenticated) public access?
  Adam Lanier:Apologies, I have another meeting to get to
  andrew sullivan:I don't know how "thick" and "thin" are defined in the registry agreements.  All I know is what I get out of whois :)
  andrew sullivan:The reason it is out there, as I just said in my comment, is because when I am troubleshooting I need to understand these things
  Greg Shatan:The argument about expiration date seems like a real stretch to me.
  Volker Greimann:expiration data is a cause for targetted spam. It also causes consumer confusion when a domain is in renew grace as the registry considers it as renewed and updates the expiration data accordingly while the registrar can still delete it.
  Lisa Phifer:@Steve, this WG can identify some elements are not required - whether they'd be deprecated and if so how would come in future phases of the PDP, should the PDP move to defining a next gen policy and system
  andrew sullivan:If a name is expired, that is information that helps me troubleshoot the problem
  Greg Shatan:I don't recall the "Overwhelming Need" test being cited anywhere else.
  Volker Greimann:is there an overwhelming need to have that data?
  Greg Shatan:This is why the Principle of Proportionality creates a problem.
  Volker Greimann:not because it might be personal data, but because of its use in abuse
  Greg Shatan:@Volker, why do you ask?
  Susan Kawaguchi:The statuses are choices also so if we use that as a criteria to determine what is in the Thin record then we would be elminating much of this data
  Jim Galvin (Afilias):@andrew - I think a distinction I would make is whether the operational information needed is about the critical infrastructure versus the domain name itself.
  Jim Galvin (Afilias):@andrew - this might be fuzzy but while I agree that NS information needs to be there, I'm not sure yet that I agree the status information needs to be there.
  Volker Greimann:I ask because if we can shut down some abuse vectors by eliminating expiration data from being public, what are the counterarrguments.
  Jim Galvin (Afilias):@andrew - in the status case, you
  Jim Galvin (Afilias):@andrew - in the status case, you're dealing with the name itself, not global shared infrastructure.  Am I making a useful distinction?
  andrew sullivan:sure, but the operation of the name itself is related to that status
  Susan Kawaguchi:earlier in the chat Alex pointed out that 59% of the registrations in the NORC study were determined to be legal persons and not natural persons. in my opinion this argument does not relate to a majority of the registrations
  Lisa Phifer:So "thin data" elements in this context does not mean today's thin data but rather the set of data elements to be made available without authentication, accessible publicly to all
  andrew sullivan:and if I'm trying to understand why all my emails are bouncing, I don't only care about the global infrastructure
  Greg Shatan:@Volker, I'll need to see the arguments first.
  andrew sullivan:if a website has suddenly stopped working, I don't only care about the global infrastructure
  Jim Galvin (Afilias):@andrew - but as critical infrastructure you're name is your problem.  why should the global shared infrastructure help you
  andrew sullivan:if I am interacting with you, your name is also _my_ problem
  andrew sullivan:I don't know whether the problem is at your end or mine
  Lisa Phifer:If so, the question is are there any data elements in thin data today that shouldn't be public, and are they any new data element required as public not already in thin data today
  Jim Galvin (Afilias):@andrew - and for your email you contact your registrar and get what you need.  why does the global infrastructure have to help you?
  andrew sullivan:but if I can lookup your name in RDS and see it's expired, then I know why mail to you is bouncing
  andrew sullivan:the "global infrastructure" has to help me because that's how distributed administration works
  Tim OBrien:+1 andrew
  Stephanie Perrin:That would  be a valid reason for releasing it Andrew
  Jim Galvin (Afilias):the global infrastructure does help you - it tells you the registrar of record.  call and ask if they'll give you the information.
  Bill Fanelli:+1 andrew
  Stephanie Perrin:exactly as Jim says....
  Jim Galvin (Afilias):if you're a customer trying to reach a web site that doesn't work, that's a problem for the down web site, not the global infrastructure
  andrew sullivan:The "global infrastructure" is in this case an informational tool that allows distributed operation of the Internet
  andrew sullivan:the model of "talk to a guy" to solve the problem does not scale, which is why we abandoned the hosts.txt file
  Michael Hammer:Jim, it depends on why it isn't working. Look at all the sites were down when Dyn got attacked by the Marai botnet.
  Volker Greimann:Susan: Actually, it was a third.
  Jim Galvin (Afilias):the point I'm stuck on is why the global infrastructure has to care about the fact that a web site is down.  contact the owner of the web site and deal with it.  the RDS gives you a pointer to get that information.
  Michael Hammer:The webservers were up. You cold hit them if you knew the IP Address. DNS wasn't working properly for a swath of nameservers.
  Lisa Phifer:NORC REgistrant Identification Study Report: https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_issues_whois_registrant-2Didentification-2Dsummary-2D23may13-2Den.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=Nvq6O-9s3b3F2aSD9hqpRgcNuTJ0wlJr9jJS-vfeg4A&e=
  Greg Shatan:Agree with Susan on all counts.  We can't treat every registrant as a natural person, any more than we should treat every Internet user as a child.
  Lisa Phifer:For those unfamiliar with that study, it attempts to answer questions such as "what percentage of domain names are registered by legal vs natural persons?" and "what percentage of domain names are used for commerical purposes?" (noting that the party using a domain name isn't always the registrant)
  andrew sullivan:@Jim: actually, thin data does not give you that pointer
  andrew sullivan:Hand down in interests of time
  Jim Galvin (Afilias):thin data gives you the registrar of record - call and ask
  andrew sullivan:Are you seriously suggesting that the answer to keeping the Internet going is to re-centralize troubleshooting by calling people?
  andrew sullivan:I think that didn't work when the Internet was orders of magnitude smaller than it is now
  Alex Deacon:@jim - as andrew mentioned earlier calling registrars doesn't scale.   Sounds costly also....
  steve metalitz:waiting to hear registrars volunteer to respond to phone inquiries if expiration date etc. is removed from public access
  Lisa Phifer:Proposed WG agreements (to be tested by poll): DNSSEC should be added as a "thin data "element accessible without authentication.
  Alan Greenberg:A previous PDP has decided that thin data will cease to exist in the near future. SO what is in thin data by the time we finish is a non-sequitor. Thin data is what it is and we need to decide whether or not we can publish each element and under what circumstances.
  Susan Kawaguchi:@ Jim when there is a domain name issue arises and you are running a billion dollar business calling the registrar at anytime of day or night to trouble shoot and verify a status or expiration date is not feasible.
  Lisa Phifer:Proposed WG agreement (to be tested by poll): Expiration Data should be removed as a "thin data" element to be made accessible without authentication.
  Jim Galvin (Afilias):regarding calling registrar - we are all technically savvy.  i simply have seen no evidence to suggest that random Internet user cares about RDS.  That is a very serious comment.
  steve metalitz:The "category" of thin data will disappear except to the extent this WG revives it -- I think that was Alan's point.
  Jim Galvin (Afilias):regarding calling registrar - so I'm further thinking that folks who want more access will simply arrange to get - by being an authenticated user.
  Lisa Phifer:The poll will note there was both support and disagreement for those two proposed WG agreements during this call.
  Alan Greenberg:The distinctionbetween thin and thick (that is, what today the registrar stores vs what the registrar stores, will go away when there are no registries that only store "thin" data.
  andrew sullivan:I guess I will learn from this not to put my hand down when we are coming up to the end of the meeting, because I'd orginally put up my hand to respond to Stephanie's earlier remarks
  Lisa Phifer:@Alan, I think this WG is using "thin data" not to refer to location of data storage, but to a set of data elements to be made publicly accessible, without authentication.
  andrew sullivan:It doesn't relate to a file _at all_.  There is no "file" here
  Susan Kawaguchi:@ Jim but even if the average internet user does not use RDS it is still critical to management of domain names
  Stephanie Perrin:I am using "file" in a virtual sense Andrew.  Does it relate to my domain?
  Lisa Phifer:Update on ICANN59 sessions:
  Lisa Phifer:Cross-Community Session Agenda: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ygffAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=90C7eLNb4l0ggeNiU6ZYK7hDf2MdrKJ1gL2bLG7qioA&e=  Abstract: https://urldefense.proofpoint.com/v2/url?u=http-3A__sched.co_B3oo&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=-6IcooZ2GPvI08-FD9pinC0t9GBBzGNndMU865xiGbQ&e=  Adobe Connect https://participate.icann.org/jnb59-ballroom1
  andrew sullivan:@Stephanie: I know how you're using it, but I think your description of this is deeply flawed.  Registration does not work the way you appear to think it works
  Lisa Phifer:WG F2F Session Agenda: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_lATfAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=wUa2zF6IimjisfBbhmymLUt8rMST8QJbo9T13PumGkI&e=  Abstract: https://urldefense.proofpoint.com/v2/url?u=http-3A__sched.co_B49L&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=C7TtRuJ8TPsm9F56XJpyaF-0GjXZ0C5QmJ8TxYnyz2o&e=  Adobe Connect https://participate.icann.org/jnb59-ballroom
  Stephanie Perrin:As I always used to say when we were fighting over whether an ip address was PI, if it is good enough for the FBI to use it to arrest me, it is my PI.
  Jonathan Matkowsky:@Stephanie That is a scare tactic, honestly.
  Jonathan Matkowsky:IP addresses have nothing to do with thin whois data
  Marika Konings:https://schedule.icann.org/grid/
  Lisa Phifer:See above for ICANN 59 links - also posted on wiki landing page
  andrew sullivan:The expiration date of a domain is not in fact good enough for anyone to arrest you
  Lisa Phifer:WG F2F Session is Wednesday: Agenda: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_lATfAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=wUa2zF6IimjisfBbhmymLUt8rMST8QJbo9T13PumGkI&e=  Abstract: https://urldefense.proofpoint.com/v2/url?u=http-3A__sched.co_B49L&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=C7TtRuJ8TPsm9F56XJpyaF-0GjXZ0C5QmJ8TxYnyz2o&e=  Adobe Connect https://participate.icann.org/jnb59-ballroom
  Stephanie Perrin:Of course not, that statement was an analogy to an earlier argument.
  Lisa Phifer:Cross Community Session is Monday: Agenda: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ygffAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=90C7eLNb4l0ggeNiU6ZYK7hDf2MdrKJ1gL2bLG7qioA&e=  Abstract: https://urldefense.proofpoint.com/v2/url?u=http-3A__sched.co_B3oo&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=_-YcWK6V4CqWbfYGRWzyJ6xfuAislGcThQX4eO-QU50&s=-6IcooZ2GPvI08-FD9pinC0t9GBBzGNndMU865xiGbQ&e=  Adobe Connect https://participate.icann.org/jnb59-ballroom1
  andrew sullivan:thanks all & bye
  Fabricio Vayra:Thanks, Chuck
  Jonathan Matkowsky:@stephanie But it suggests that the same principles apply, which they don't--at all, honestly.
  Luc Seufer:++
  Jonathan Matkowsky:Take care
  Maxim Alzoba (FAITID) 2:bye all

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170606/a2d93662/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 06 June 2017 Sheet1.pdf
Type: application/pdf
Size: 23615 bytes
Desc: Attendance RDS PDP 06 June 2017 Sheet1.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170606/a2d93662/AttendanceRDSPDP06June2017Sheet1-0001.pdf>


More information about the gnso-rds-pdp-wg mailing list