[gnso-rds-pdp-wg] Recordings, Attendance & AC Chat from Next-Gen RDS PDP WG call on Wednesday, 20 September 2017 05:00 UTC
Michelle DeSmyter
michelle.desmyter at icann.org
Wed Sep 20 11:34:41 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, 20 September 2017 at 05:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-20sep17-en.mp3
AC recording: https://participate.icann.org/p1uztwksanb/
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/ZGfwAw
Thank you.
Kind regards,
Michelle
———————————————
AC Chat Next-Gen RDS PDP WG Wednesday, 20 September 2017
Michelle DeSmyter:Dear All, Welcome to the GNSO Next-Gen RDS PDP Working Group call on Wednesday, 20 September 2017 05:00 UTC
Michelle DeSmyter:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ZGfwAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=hXYfwaTTBHNUX7tqPHvau4gcosTDirJ48Mn2LXHq69E&s=NXV7v17iTRT0Oi_8_cOBR_SpAANstL3WoETWnKA-WRo&e=
andrew sullivan:I am even less coherent than usual, because I got up at 05:00 today (well, now yesterday) and have been active ever since, so my apologies if I make less sese than my normal "fool on the loose" setting.
Amr Elsadr:Thanks for making it to the call, Andrew.
andrew sullivan:Oh, I wasn't saying that to indicate martyrdom. I'm now too wired to sleep :)
Amr Elsadr::-)
Lisa Phifer:Annotated Poll Results: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086756_AnnotatedResults-2DPoll-2Dfrom-2D12SeptCall.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=hXYfwaTTBHNUX7tqPHvau4gcosTDirJ48Mn2LXHq69E&s=TTWj_Q0s2PDPJnW-d3RFaC0lz7vijj_0mWGiOijxAkk&e=
Susan Kawaguchi:Sure no problem Chuck
Kal Feher:I can scroll fine.
Lisa Phifer:From Q2 - WG Agreement: The RDS must support Registrant Postal Address data elements: Registrant Street Address, City, State/Province, and Postal Code.
Lisa Phifer:From Q3 - WG Agreement: The RDS must support Registrant Phone + Registrant Phone Ext (extension) data elements.
Lisa Phifer:Action Item Response: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086756_Volunteer-2520Team-2520on-2520Action-2520Item-2520regarding-2520Original-2520Registration-2520Date-2520-2D-252018-2520Sep-2520Update.docx&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=hXYfwaTTBHNUX7tqPHvau4gcosTDirJ48Mn2LXHq69E&s=kjWURAkErIMWzzDVW8lPiZRb52S2VPk-r__FbHsGWWs&e=
Maxim Alzoba (FAITID):Hello All
Lisa Phifer:Posted on wiki with meeting materials
Maxim Alzoba (FAITID):it gives accuracy of 20 years
Maxim Alzoba (FAITID):for old regisries
Kal Feher:would the history of a domain name apply to all variants?
andrew sullivan:@Kal: I think that doesn't need to happen
andrew sullivan:because the variants are themselves different doman names
Kal Feher:canonically they should be the same. but only the initial registration would be tracked
Kal Feher:they arent actually different domains. in many registries
andrew sullivan:@Kal: what do you mean "canonically the same"? They're _not_ canonically the same. They're different entries in zone files
andrew sullivan:so by definition they're different domains in that strict sense
Kal Feher:zone file yes. registries no
Maxim Alzoba (FAITID):@Kal, it depends on particular TLDs, some Registries "couple" domains in different TLDs, some do not
Maxim Alzoba (FAITID):so it is more legal then technical
Maxim Alzoba (FAITID):*than
andrew sullivan:One can couple all one wants. But the domains are in themselves different, and that's the distinction we're depending on
Maxim Alzoba (FAITID):so it is not easy to technicaly implement it
Lisa Phifer:Handout: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086756_RDSPDP-2DHandout-2DFor20SeptCall-2Dv2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=hXYfwaTTBHNUX7tqPHvau4gcosTDirJ48Mn2LXHq69E&s=XzQJ6WW4bkE0x3rGWIgYE7zTSUron2gWdv9z66rl40E&e=
andrew sullivan:It ought to be trivial to implement, no matter which way you implemented variants
andrew sullivan:because you _have to_ have a way to distinguish the names once it's time to generate a zone fle
andrew sullivan:so if you can do that, you can distinguish them for these purposes too
Kal Feher:well domain name objects are not the same as entries in a zone file. you may have a primary domain name with several variants which are active and many others which are not active. they would all canonicalise to the same set of code points tho.
andrew sullivan:The idea that these "canonicalize to the same set of code points" is not even wrong, no matter how frequently people have implemented that
Kal Feher:tracking the orignially registered domain could become problematic in that circumstance
Kannan Ganapathy:develop some policy for domain zone.
andrew sullivan:It is probably necessary in some cases to have a "fundamental" registration that is the source of everythign
Kannan Ganapathy:Agreed , it technically tough .
andrew sullivan:but following that thread backwards should not be even a little bit difficult for any moderately competent database developer
andrew sullivan:I can think of 10 ways to do it
Kannan Ganapathy:@andrew . yha , that is the wright way.
Lisa Phifer:MPDS = Minimum Public Data Set (formerly thin data)
Kal Feher:bearing in mind some combinations can have many thousands of variants. it isnt as trivial as you imagine. you'd need to check a newly registered domain against all its possible variants for past registrations.
andrew sullivan:@Kal: disk space is very close to free these days. That is not a thing to generate on the fly: store it.
andrew sullivan:then it's a trivial lookup
andrew sullivan:I am perfectly aware of how big the combinatorial problem is. (I was one of the principal authors on the Variant Issues Projects texts)
Alex Deacon:yep
Lisa Phifer:Slide 2 shows WG agreements thus far, on MPDS only
Lisa Phifer:Slides 3-5 describe each of the purposes previously discussed, the WG agreement about that purpose for collection of MPDS only, and use cases
Maxim Alzoba (FAITID):@andrew , I think the issue is that there is no semantyc diference between variants of the name and those which look like variants , but are not due to TLD policies
Kal Feher:@andrew perhaps. but I have to live with it in real life and make it perform. tracking all possible combinations of a name, including spanning changes of lgr over time, seems like a either a performance or accuracy problem for the future or both.
andrew sullivan:@Maxim: I _know_ why variants are a problem. But people seem to be inventing a problem that doesn't exist here. If you have a variant it has a different name for DNS purposes. That means it is a different string for lookup purposes, which means that the RDS can access that string too
Lisa Phifer:We are now on slide 6 - consolidating previous WG agreements on purposes for MPDS collection with WG agreements on MPDS access
andrew sullivan:Therefore, it's a separate name for these purposes. In cases where it's entirely generated, then the answer ought to be easy anyway.
Kal Feher:@andrew. just because it is a diff name in DNS, doesnt mean it is a different object in the registry. variants are not objects in the registry. and RDDS queries the registry, not the zone file
andrew sullivan:I think that any registry model that does not distinguish among associated domain names that potentially end up in the DNS is either not doing its job or is improperly described
andrew sullivan:If you _can_ generate the entries for the DNS from the "base name" using an algorithm, then in fact the registry is the combination of the database and the algorithm
andrew sullivan:if you _can't_ generate such entries, then your registry is a bad foundation for the zone file and it's hard to know how it's the "registry" at all.
Lisa Phifer:@Stephanie, which purposes do you see as within ICANN's mission and remit? And therefore purposes for collection of MPDS
andrew sullivan:I think Stephanie is making a subtle point here
andrew sullivan:which is that just because the _disclosure_ of data for a given purpose is valid and even acceptable does not mean that it's a reason to collect the data in the first place.
Lisa Phifer:@Stephanie, do you agree that all of these listed purposes are legitimate purposes for access to the Min Public Data Set?
Sara Bockey:I think Stephanie and Andrew are correct. The purpose of collection is for domain registration.
Kal Feher:@andrew this is probably the difference between the innards of a registry vs how outsiders perceive it. variants exist in the registry, otherwise there's no way of determining what's active and what isnt and in the rare case where they have different delegations, that would also not work. however they are not domain name objects. If we pursue this counter idea, there might need to be a more detailed discussion IMO.
Tim Chen:The ICANN remit goes beyond simply operating DNS
Tim Chen:It's mission and values talk all about stable and secure operation of DNS
andrew sullivan:@Kal: if they exist in the registry, then you can count them.
Tim Chen:Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet.
Fabricio Vayra:the purpose limitation principle states that personal data collected for one purpose should not be used for a new, incompatible, purpose.
Tim Chen:and so forth
Fabricio Vayra:so we need to include in the purpose what the data will be used for later
andrew sullivan:@Kal: anyway, I think that this is a good topic to discuss on the list.
andrew sullivan:I don't think that ICANN is responsible for the global interoperability of the Internet
andrew sullivan:people should read the Mission carefully :)
Kal Feher:@andrew, that would make them permanent and you'd have to convert them if ever registered. so we will def need some detailed discussion in the future.
andrew sullivan:@Kal: I'm suggesting detailed discussion now, on the list
andrew sullivan:We've been kicking cans down the road for too long. Let's nail down the details
Lisa Phifer:Does anyone disagree with the listed purposes as legitimate purposes for ACCESS?
Lisa Phifer:to the MPDS that is
Sara Marcolla (EC3):There is to consider as well on the impact of the EU GDPR when discussing the purpose of data collection.
Kal Feher:@andrew. this might be my ignorance of the pdp showing, but wont technical implementation be in a different work track?
andrew sullivan:@Kal: probably, but I think it is the height of folly to propose a policy that obviously can't be implemented.
Stephanie Perrin:We had two precise versions of the purpose of WHOIS in a previous WHOIS exercise. I can find them.....
Kal Feher:ok. I'm game
Fabricio Vayra:+1 Lisa
Fabricio Vayra:Rec.50; Art.5(1)(b)Personal data may only be collected for specified, explicit and legitimate purposes and must not be further processed in a manner that is incompatible with those purposes.
Fabricio Vayra:So I fear that if we limit to just to register a domain, we can't later provide access for these legitimate purposes that we've all agreed are legitimate
Lisa Phifer:@Kal, the PDP process can include implementation guidance in phase 3 of this PDP, but there would be a follow-on IRT after new policy is adopted to begin implement it
Rod Rasmussen:Hmmm - what does "incompatible" mean in this case? That seems pretty key to me. For example, is enforcing IP rights to a trade name "incompatible" with establishing ownership/control of a domain name? Sounds like a legal opion needed there.
Fabricio Vayra:Rod - Exactly
David Cake:I very much agree with Stephanies point that purposes for access are not necessarily purposes for collection, and I would prefer to deal with these issues sooner than later. I do feel this issue needs to be resolved in phase 1.
Alex Deacon:Agree with fab's comments. If we don't specify the purpose for collection up front we may not be able to access the data for these legit purposes later on. Concerning....
David Cake:Can anyone give an example pf use of legitimately collected data that was found to be incompatible?
Lisa Phifer:Slide 2 lists the purposes - green check if you agree those are purposes for access to the MPDS?
Kal Feher:@lisa ok thanks. I think that is what I understood to be the case. but agree with Andrew that discussing this topic now does seem to be expedient, especially if we discover that a policy idea is problematic
andrew sullivan:I'm torn on this question. I always hated the "individual use" one, for instance
Marc Anderson:I'm putting disagree because I'm not sure it's that simple. I think we need to consider who has access for these purposes and under what circumstances. I don't think all these purposes would apply to unlimited public access.
andrew sullivan:+1 Marc
andrew sullivan:@David: sure. Every spam harvest is an example
Marc Anderson:I don't have voice... I put my reason in chat above
Fabricio Vayra:If we don't specify the purpose, then how is the data subject to give "consent to the processing of his or her personal data for one or more specific purpose?s
Amr Elsadr:Marc's reason for disagreeing as per his comment in the AC chat above: I'm putting disagree because I'm not sure it's that simple. I think we need to consider who has access for these purposes and under what circumstances. I don't think all these purposes would apply to unlimited public access.
Stephanie Perrin:Found it, dates from 2006 The first formulation was:The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, issues related to the configuration of the records associated with the domain name within a [Domain Name System] name server.This purpose, limited in scope, was supported by the Registries, the Registrars, and the Noncommercial Users Constituency.The second formulation was:The purpose of the gTLD Whois service is to provide information sufficient to contact a responsible party or parties for a particular gTLD domain name who can resolve, or reliably pass on data to a party who can resolve, technical, legal or other issues related to the registration or use of a domain name.This purpose, clearly broader in scope, was supported by the Intellectual Property Constituency, the Internet Service Providers and Connectivity Providers, and the Business Constitue
Fabricio Vayra:See Art. 6 GDPR 1.a
Stephanie Perrin:Retrieved from https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_issues_whois-2Dprivacy_prelim-2Dtf-2Drpt-2D18jan06.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=hXYfwaTTBHNUX7tqPHvau4gcosTDirJ48Mn2LXHq69E&s=8BkC9Qx7tFwQ19TGl7A1VcGmAJgREFLavj7eTn5ZI_0&e=
Amr Elsadr:Marc's reason for disagreeing as per his comment in the AC chat: I'm putting disagree because I'm not sure it's that simple. I think we need to consider who has access for these purposes and under what circumstances. I don't think all these purposes would apply to unlimited public access.
Lisa Phifer:@Stephanie, yes, no consensus could be reached at that time
Kal Feher:just to be clear that I interpret the "public" part of minimum public data set as no restriction on reading (volume restrictions excluded). so I don't feel the need to restrict the reasons why someone may read a public data item
andrew sullivan:I'm depressed to realise that I participated in that round of The Whois is Broken
David Cake 2:@andrew ah, obviously spam is an example,
Sara Marcolla (EC3):c
David Cake 2:a few examples of less obvious cases would be helpful
Maxim Alzoba (FAITID):quite many members are not here, so I am not sure we can decide now
andrew sullivan:@David: LE data collection that would not be sanctioned by a court is another example. (I'm setting aside the "we don't have time for that" part of the argument -- this is just cases that couldn't possibly get a warrant)
andrew sullivan:Also, "drop registration harvesting"
andrew sullivan:Just off the top of my head
Tim Chen:Susan can you repeat the question that we are voting on? I'm not sure I'm clear on it. And only see 4 votes including yours. I'm not clear that Chuck is capturing your question correctly. It's late and I'm not following as well as I would like.
Stephanie Perrin:Expiry date was an element where I objected. I may have been the only one
Kal Feher:not convinced that having a purpose for public data is useful. we are trying to apply reasons for consuming data we've agreed should be freely available. what are we doing to do with this particular pupose? purposes for non-public data makes plenty of sense to me
Sam Lanfranco:I agree (if I understand it right) with (a) MPDS data collection requires an agreed purpose, and (b) the MPDS is accessible to all without being gated
Lisa Phifer:Slide 2 lists the purposes - green check if you agree those are purposes for access to the MPDS?
Lisa Phifer:Red X if you disagree, green check if you agree those are purposes for access to the MPDS
Tim Chen:I agree that the list (cannot recall the full list offhand) is for access. But I do not agree that these are, in parallel, not reasons for collection. I think they could be reasons for collection as well.
Lisa Phifer:The MPDS is a defined set of data elements, but not the only data elements that may be relevant to each purpose
Fabricio Vayra:Aren't we talking about thin data aka minimum public data set?
Sara Bockey:I need to drop. Thanks all - great discussion!
Maxim Alzoba (FAITID):puproses are to be used in the consents and adding legal actions by third parties looks bit wild
David Cake 2:a purpose for public data is useful where an enforcement mechanism exists for unauthorized use. but we do not have that, and it's to see how we could have one for anyone not a contracted party.
Marc Anderson:Agree with Andrew... he's really hitting on my concern as well.
andrew sullivan:Hmm, not sure I want to try this out with my voice, but what about this as a way to frame the question:
Stephanie Perrin:I think that is a good way to describe it. It is three dimensional. When it comes to public disclosure we are doing a cost benefit analysis, and deciding these elements are necessary for so many legitimate purposes closely related to ICANN's core mission, that we let them be public.
Lisa Phifer:Those who have concerns, do you have an alternative formulation to state the purpose(s) of providing access to the MPDS
David Cake 2:thoroughly agreeing with Andrew and Stephanie
andrew sullivan:"Is _at least one_ of these purposes the reason for collecting or disclosing (or both) a data elementa as a public element?" If the answer to that is yes
andrew sullivan:then we don't need to worry further about purposes, because the data needs to be public
Stephanie Perrin:I tis not just that enumerating all purposes for disclosure, it is not necessary under the law. We do not have to anticipate every potential purpose of further compatible processing, under EU law.
Lisa Phifer:@Andrew, doesn't there need to be rationale for making it public? Just one purpose isn't in itself rationale
andrew sullivan:@Lisa: if the purpose requires public access, then that single purpose is enough
Alex Deacon:Unless I'm in a dream state now I'm pretty sure we had this exact conversation many months ago.
andrew sullivan:the obvious example of this is NS records
andrew sullivan:and I think Alex is quite right
Lisa Phifer:@Andrew, but you have to give an explanation of why is must be public
Stephanie Perrin:Exactly Chuck, we should never have been figuring purpose in the context of disclosure for all these third party purposes.
Stephanie Perrin:We did, Alex. I am sure I have been nauseatingly repetitive.
Fabricio Vayra:How about we agree that this is thin data = not personal information, which privacy law doesn't apply to in the first place and therefore a urpose requirement doesn't apply to either
Fabricio Vayra:and just say it's public
Stephanie Perrin:It is still personal information. I asked Canatacci to confirm that in Copenhagen.
Fabricio Vayra:It is NOT PII
Sam Lanfranco:The "ghost" of "form follows function" follows this discussion. Andrew's point "one reason" is necessary and sufficient to make it public, without restricted access. It should be (is?) that direct and simple
Fabricio Vayra:we decided that ages ago
Stephanie Perrin:It certainly is. You can decide what you like.
David Cake 2:we do not, however, then give out unrestricted bulk NS record data
Tapani Tarvainen:+1 Stephanie. Of course it is PII, even though there is good reason why it must be public.
Maxim Alzoba (FAITID):Chuck's audio seems to fade
andrew sullivan:@David: at the volume with which any botnet on the Internet can harvest NS records for every known domain, I think the "not in bulk" restriction is a fig leaf
Fabricio Vayra:well, if it's PII, then the data subject needs to provide informed consent, and to do so, we need to be specific about purposes, so we're back at the start
Kal Feher:@david I think bulk access should be discussed in a different context. if we agree its public then anyone can look up at least one record then we can apply greater restrictions on bulk access without undermining this agreement
Stephanie Perrin:Old hand
Alex Deacon:wishful thinking....
andrew sullivan:If you are registering a domain name and adding NS records, then you had better be providing informed consent that people might look it up
David Cake 2:@andrew true, but 'can you do this legitimately' still matters even if illegitimate means exist.
Lisa Phifer:@Susan, are you saying MDPS is made publicly accessible because it is necessary to create and maintain a domain name registration? (regardless of whether its PII)
Stephanie Perrin:Yes but they are not the purposes listed.
andrew sullivan:@David: there is literally no way to tell the difference between someone doing real lookups and someone walking a zone, if they only do a single lookup
Stephanie Perrin:The purposes to display the mpds are, as Andrew eloquently argued months ago, to make sure the domain works and stays functioning.
Tim Chen:sorry, stepped away. +1 Fabricio. PII is not defined. It is just interpreted. Our interetations differ.
Kal Feher:@David I still don't understand why it is important to have purposes for public data. is the nameserver police or the whois police going to check if your consumption of freely available data meets one of our purposes? purposes in this context simply don't appear to be useful
andrew sullivan:I knew we'd agreed on the simpler thing before! Lisa for the win again
Stephanie Perrin:It is certainly not displayed to facilitate academic research, eg.
Fabricio Vayra:@Stephanie, you're correct that if we don't tell the data subject that we will publish to facilitate academic research, we can't. So if we think that's a purpose, we need to state it up front
Sam Lanfranco:Once a purpose is given for collection, and for access...that is it. Making a long list of purposes is futile if the MPDS is simply public.
Kal Feher:@Sam agree.
Stephanie Perrin:Fab, I think you are contorting the concept of purpose here.
Marc Anderson:Agreement #23 states that RDS policy must state purpose(s) for public access to the "minimum public data set."
Fabricio Vayra:I'm providing my understanding of the concept of purpose (founded on my reading and that of other professionals who have written on the subject)
Stephanie Perrin:No, you have been trying to get agreement to a bunch of purposes which are acceptable for disclosure, and turn them into purposes for collection. That is the problem
Fabricio Vayra:+1 Marc
Stephanie Perrin:There is not.
Kal Feher:I'm ready to move on
Marc Anderson:we've already agreed that we must define the purpose(s) for access to the public data set... we just haven't done that yet. The stumbling block today is that we've been trying to map the wrong purpose(s)
Stephanie Perrin:correct, Marc
Kal Feher:@marc, I think we do need a reason to publish data. I don't think we need every reason and we don't need to agree that we have all the correct reasons. just one for each data element
andrew sullivan:I think that's right too
Marc Anderson:Agreed Kal
Sam Lanfranco:Re: Marc, a minimum of stated purposes means that there must be some agreed purposes but that does not need to be exhaustive (both for collection and access)
Stephanie Perrin:May I suggest that if we are going to start to figure out purposes for collection we should read the Article 29WP opinion on purpose....recently done for the purposes of informing GDPR discussions.
David Cake 2:good summary lisa
Kal Feher:agree with Lisa
Lisa Phifer:There must be at least one purpose for collecting the MPDS and that purpose must include justification for making MPDS public
andrew sullivan:(friendly amendment: for each element?)
Kal Feher:yes. each element
Lisa Phifer:@Andrew, each element in the MPDS?
Marc Anderson:Agree with what Lisa is saying but also reminder that agreement #23 is that Policy must state what that purpose is.
andrew sullivan:@Lisa: the idea is that the reason for each need not be the same
Sam Lanfranco:Is the wording "that purpose must include justification for making MPDS public" or "is sufficient for making MPDS public"?
andrew sullivan:but each one must have a reason and one that makes it public
Marc Anderson:Agree with Andrew, should be per element as not all elements will have the same purpose
Stephanie Perrin:yes agree with that
andrew sullivan:Oh, I am so ready to move on to that, yes
Lisa Phifer:Andrew, Marc, we previously polled on purposes for each data element but ended up stuck. Look back and see how we could get beyond where we were at that level of granularity?
Lisa Phifer:It was the last call before Joburg
Stephanie Perrin:If a data commissioner is investigating collection, they will look for the purpose of each element. Otherwise, it does not pass the data limitation principle.
hanan khatib:yes move one
andrew sullivan:I think my point is that, for the items in the MPDS, if one thinks that _any_ of the possible reasons (1) applies and (2) requires the element being public, then that is a reason to include it
Stephanie Perrin:I think Canatacci went through the stages of analysis in Copenhagen.
Tim Chen:I'm unclear on how this new statement is any different than what we already agreed to, but I'm not going to stand in the way of moving on. IF we have to justify why an MPDS data element is public, than we need to remove the word 'public' from the base definition. I'd also love to know how everyone is defining 'public' bc I'm not convinced it is consistent.
Lisa Phifer:There must be at least one purpose for collecting each data element in the MPDS and that purpose must be sufficient for making the MPDS public
Lisa Phifer:Above is the reworded proposed WG Agreement to be polled on
Maxim Alzoba (FAITID):+1 Lisa
Sam Lanfranco:As I understand it "public" means ungated.
andrew sullivan:I'm good with that, yes
andrew sullivan:yes, ungated &c &c
Kal Feher:@sam. that is my expectation
Lisa Phifer:@Sam public means accessible without requestor identification, authentication, or stated purpose (see agreement 20)
Tim Chen:@Lisa is that supposed to end as "...must be sufficient for making the MPDS element public"?
Lisa Phifer:@Tim, you mean it should read: There must be at least one purpose for collecting each data element in the MPDS and that purpose must be sufficient for making that MPDS dta element public
Tim Chen:thought so, but just lobbing that in there
Tim Chen:if no one else agrees, disregard my comment
Tapani Tarvainen:This is a good time for me. :-)
Maxim Alzoba (FAITID):5AM utc is better than 3AM UTC
Benny Samuelsen / Nordreg AB:sorry
Lisa Phifer:One additonal action item: Staff to distribute drafting team output on Original Registration Date to WG mailnig list; all WG members invited to review and comment
Kal Feher:so weird not being on this call at 2am.
Benny Samuelsen / Nordreg AB:perfect meeting time... midday here :-)
Benny Samuelsen / Nordreg AB:Bangkok at the moment
Maxim Alzoba (FAITID):As I understand there is a huge issue of ICANN not thinking to be the controller under GDPR
Sara Marcolla (EC3):It would be beneficial to have a GDPR agenda point sometime in the future
Maxim Alzoba (FAITID):bye all
Kal Feher:bye
Susan Kawaguchi:bye all
David Cake 2:thanks all
andrew sullivan:bye
Benny Samuelsen / Nordreg AB:bye
Sam Lanfranco:good early morning from dark sky Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170920/be02951a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 20 Sep 2017 Sheet1.pdf
Type: application/pdf
Size: 22203 bytes
Desc: Attendance RDS PDP 20 Sep 2017 Sheet1.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170920/be02951a/AttendanceRDSPDP20Sep2017Sheet1-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list