[gnso-rds-pdp-wg] Recordings, attendance & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 23 May 2017 at 16:00 UTC
Michelle DeSmyter
michelle.desmyter at icann.org
Tue May 23 19:19:09 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, 23 May 2017 at 16:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-23may17-en.mp3
AC recording: https://participate.icann.org/p27egiiqojz/
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/HsPRAw
Thank you.
Kind regards,
Michelle
———————————————
AC Chat Next-Gen RDS PDP WG Tuesday, 23 May 2017
Michelle DeSmyter:Dear all, Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday, 23 May 2017 at 16:00 UTC.
Michelle DeSmyter:Meeting agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_HsPRAw&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=TAJytA_m3RTdMZwYBN397M76WBCc-vbOQik6Zvb7ytA&e=
Benny Samuelsen / Nordreg AB:could someone say something
Benny Samuelsen / Nordreg AB:so I can test if I have sound
Volker Greimann:Houston, We can hear you loud and clear!
Benny Samuelsen / Nordreg AB:ok thanks not working again
Benny Samuelsen / Nordreg AB:will restrart
Chuck Gomes:I had to wait 2-3 minutes for an operator. Did others have the same problem?
Chuck Gomes:Great slide.
Maxim Alzoba (FAITID):Hello All
Michael Hammer:Similar problem Chuck.
Lisa Phifer:Displayed on screen now: 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=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=j7fPhB1wzZ6tPmKz9a-_etm_KpdaJfr9qMaajGkV35c&e=
Viviane Vinagre:Hello! It's my first RDS meeting, and I wanna say I'm sorry for just participating now, but the time zone was a mess
Michael Hammer:Welcome Viviane.
Viviane Vinagre:Thank you Michael!
Alex Deacon:Hi. Sorry for joining late...
Volker Greimann:I qam very much opposed to this purpose definition. The "facilitation of dissememination of registration data" cannot be a purpose for the collection or processing of personal data under the GDPR as the dissemination would itself need a legitimate purpose, which it cannot have.
steve metalitz:Couldn't there be more than one such data set meeting this definition? E.g., the data held by registry may be different than data held by registrar.
Maxim Alzoba (FAITID):due to GDPR we might see more THIN registries ...
Volker Greimann:due to GDPR we may see more blank whois details
Michele Neylon:I'm not dialled in yet - I will be shortly
Michele Neylon:stuck on another call
Michael Hammer:If you have more than one data set and they conflict, which one is the one that should be used? That's really what we are trying to address.
Volker Greimann:Ultimately, Whois cannot be relied upon legally as it may be out of date, false, stolen, proxied, etc
Alex Deacon:@ volker - what dose that mean "can't be relied upon legally"? (i'm not a lawyer)
Maxim Alzoba (FAITID):could we "information provided during the last update/create interaction"?
Maxim Alzoba (FAITID):*use
Maxim Alzoba (FAITID):so we reffer to the fact that we provide only what we have
Michael Hammer:What percentage of domains have implemented DNSSEC?
Maxim Alzoba (FAITID):3%?
Michael Hammer:That sounds about right.
Viviane Vinagre:I'm just listening today, trying to undestand the debate to cotribute later in the mail lists or in the next call,
steve metalitz:@Andrew, this seems like a roundabout way of saying "authoritative" -- since it ultimately comes down to whether it is "accurate" or "official" as yojust said.
steve metalitz:*you just*
Alan Greenberg:The "data of record" says more to me than "then current".
Benny Samuelsen / Nordreg AB:But domains are not owned
Volker Greimann:Whois does not give you that chain though
Maxim Alzoba (FAITID):last recorded data ?
Volker Greimann:Maxim +1
Alan Greenberg:Hand up in error
Andrew Sullivan:@Steve: I agree that it is a round-about way of saying authoritative. The problem with that term is that some people think that "authoritative" means "true": that the "authoritative data" somehow proves that the address in the data is the _right_ address
Benny Samuelsen / Nordreg AB:+ 1 Andrew
Andrew Sullivan:(or the registrant identity, or the name servers, or whatever)
Viviane Vinagre:+1 Andrew
Andrew Sullivan:that's not what "authoritative" means to Internet geeks, but it apparently is what it means for law geeks
Alan Greenberg:How do we say this is the "official" data without having a word in quotation marks??
Lisa Phifer:Note Maxim's Proposed alternative: "information provided during the last update/create interaction"
steve metalitz:+1 Scott, there is more than one "data of record" as so defined, so we need to disambiguate if we want to identify the data that should be relied upon.
Kal Feher:it is probably important to remember that some of the thin data is actually derived (expiry dates, updated dates) and some is supplied (NS records, which could be both incorrect according to the registrant's wishes, yet still accurate to what is in the TLD zone file)
Andrew Sullivan:Maybe the idea here is better expressed as, "The data you would get for each datum if you were to ask the source of that datum"
Lisa Phifer:@Scott, you are not asking us to pick the storage location but to give a definition that disambiguates what is "data of record" correct?
Michael Hammer:Longer than several weeks.
Lisa Phifer:We have two proposed alternatives in chat:
Lisa Phifer:Proposed alternative: "information provided during the last update/create interaction"
Scott Hollenbeck (Verisign):@Lisa, No, it's not about storage location. It's about origin.
Lisa Phifer:Another proposed alternative: "The data you would get for each datum if you were to ask the source of that datum"
Scott Hollenbeck (Verisign):AKA "provenance" as others are saying now.
Michael Hammer:Some domain names might be considered works of art (re provenance discussion)
Maxim Alzoba (FAITID):last know data provided by registrant
Maxim Alzoba (FAITID):*known
Lisa Phifer:Does "provenance" reflect proof of origin and integrity?
Michael Hammer:Not all of the data is provided by the registrant.
Carlton Samuels:Not to be a pedant but the word 'information" conveys an interpretaive element that could be useful to affirm. So to be comprehensive say 'data and information...'
Alan Greenberg:"then-current currentl definitive data element"
Andrew Sullivan:The reason we use provenance to confirm a work of art is what it is purported to be is because its a proxy: the idea is that if you can track who held the art all the way along, you can somehow prove to yourself that it's the real work of art by the artist
Maxim Alzoba (FAITID):as I understand the source of information is the registrant...
Andrew Sullivan:@Maxim: not always
Andrew Sullivan:the expiration date comes from the registry or maybe registrar
Carlton Samuels:@Lisa: provenance can reflect integrity, yes. It is part of the trust element that comes with interpretation
Michael Hammer:pehaps something along the lines of "controlling source(s)"
Andrew Sullivan:the object IDs come from the registry
Scott Hollenbeck (Verisign):+1 Alan
Volker Greimann:I would not make any assumption of correctness
Lisa Phifer:Proposed alternative: "definitive information"
Volker Greimann:"How about most current data"?
Scott Hollenbeck (Verisign):Shoot, I threw "definitive" out there a few weeks ago!
Andrew Sullivan:I forget the objection to "definitive" but I certainly don't object to it
Elaine Pruis:definitive is as problematic as authoritative
Maxim Alzoba (FAITID):@Andrew, yes , there could be a Registry as a Registrant, or URS or some court provided data
Carlton Samuels:definitive as a qualifier for information could work yes. +1 to Alan
Lisa Phifer:Are we looking for proof that the data is the data as provided by the point of origin for that data element?
Andrew Sullivan:No, for any given datum there is one canonical source for it
Andrew Sullivan:but each datum in the data could come from a different such source.
Lisa Phifer:@andrew for each data element, is there not a canonical source?
Andrew Sullivan:yes, for each element there is a canonical source
Scott Hollenbeck (Verisign):@Lisa: yes, and there is just one
Carlton Samuels:"Data we can take as authoritative" = definitive
Michael Hammer:taken or "considered as authoritative"?
Kal Feher:it might also be useful to ask ourselves what we _want_ to know. do you want to know what is in the registry? do you want to know what the registrar thinks the truth should be? it feels like we are reverse engineering a purpose to fit over an imperfectly distributed data set. and thosse imperfections undermine our purposes.
Alan Greenberg:I am fine with "data of record" but I am not sure it is a well understood term in the wider world.
Lisa Phifer:It sounds like we may want proof that each data element matches the data supplied by the canonical source (regardless of where it is obtained from)
Adam Lanier:+1 Stephanie
steve metalitz:@Stephanie, I don;t think the Thick Whois PDP report said registry data is likely to be more accurate, only that it is authoritative in case of divergence.
Michele Neylon:that hurt
Andrew Sullivan:Greg's argument depends on his claim that a registration object is just a data set
Stephanie Perrin:Yes Steve, I am sorry I was trying to abbreviate.
Maxim Alzoba (FAITID):by setting the data the way it was set?
Andrew Sullivan:It's true that registrations are just data, then he's right, but then we don't need to talk about "data of record" at all. But I think he is mistaken about this claim
Andrew Sullivan:Note that RDAP talks in terms of "objects": https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7485&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=bYQqj4xf6ExwthZx0okOkHNhKFvqwiN5PKsCV8jI5K8&e=
Michael Hammer:What if the registrant wanted me to have a SQL injection?
Kal Feher:consider the situation where an NS record is different between the registry and registrar. which is correct? the registry RDS system may accurately represent what is in the zone file. the registrar 's RDS may accurately represent the registrant's desire. which is correct/accurate/authoritative?
Michael Hammer:There are (should) alaways constraints.
Greg Shatan:The registrant's desire is not the right yardstick.
Lisa Phifer:How about DoR = Data set that, at a given time, can be proven to match the data supplied at the origin for each data element
Greg Shatan:It should be the data the registrant is required to provide.
Andrew Sullivan:@Kal: what you're trying to find out is what is "in the system", not what someone intended
Stephanie Perrin:I like it
Jim Galvin (Afilias):@greg - sure, I get the point you're making. wfm
Scott Hollenbeck (Verisign):Getting better, Lisa.
Kal Feher:@andrew, which system?
Jim Galvin (Afilias):@lisa - yes
Stephanie Perrin:It includes the time element, the derivation of the data]
Stephanie Perrin:YEs
Andrew Sullivan:We can't use "proven" unless we want to go for something kind of loose, since whois is a completely unauthenticated protocol
Vicky Sheckler:agree w/ scott - getting closer
Andrew Sullivan:there's no way to be sure you're getting the connection you ought to
Andrew Sullivan:but ig's closer
Andrew Sullivan:I agree
Andrew Sullivan:I like the poll plan
Jim Galvin (Afilias):proven -->> asserted
Greg Shatan:Getting there, though it's narrow and doesn't deal with the upstream source for that data, which creates a GIGO problem.
Jim Galvin (Afilias):asserted -->> purported ?
Greg Shatan:But if this is about "fidelity", then it's pretty good.
Michael Hammer:What we are really talking about is registry vs registrar, not whether the information supplied by the registrant is accurate.
David Cake:I find Lisa's definition gets back to mixing questions of source of data, thus potentially confusing.
Lisa Phifer:@David, origin not source
Vicky Sheckler:not purported - too nebulous
Stephanie Perrin:This is why we should park this. Determining the likely quality of the data (and ergo who should be responsible for that data quality) comes later. Asserted works.
Lisa Phifer:If I can get the data from anywhere, but I have assurance that it matches the data supplied at the origin, that may be what we want
David Cake:I have no idea how we prove that data in the system is correct, without using the system.
Jim Galvin (Afilias):Data set that, at a given time, is asserted to match the data acquired at its point of origin
Scott Hollenbeck (Verisign):@Jim: I like that
Lisa Phifer:@David cryptographic integrity might be applied
Kal Feher:remember that there are two seperate systems here at least. the registrar and the registry. they can and do disagree. if NS records disagree then the registry version is likely what you are interested in. if expiry date is different, then you probably want to pay your Registrar when they think you owe the money. so you'd opt for their version of the truth
Maxim Alzoba (FAITID):@Kal, Registry can act as a Registrant, and sometimes without Registrar
Lisa Phifer:Displayed on screen now: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_64078622_RDSPDP-2DHandout-2DFor23MayCall.pdf&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=qLg7TW610xrqOUYfbVos8xHFJ8_ieP7LrcVLxhfGUSA&e=
Maxim Alzoba (FAITID):for example nic.TLD for new gTLDs
Kal Feher:@maxim, true. I was just showing one complication with the assumption that there exists a single system with a single coherent answer for thin data. your scenario should be reasonably simple to keep accurate -for all interpretations of accurate
steve metalitz:doen't rough consensus #20 answer 5.1 and make the other questions moot?
Lisa Phifer:On page 3 of handout, reviewing charter subquestions 5.1 thru 5.4
Volker Greimann:Question: Why would we still need the "Whois Server" field?
Jim Galvin (Afilias):@steve -not necessarily
Lisa Phifer:@Steve, the goal is to use that WG agreement to provide answers to these questions or determine what still needs to be answered
Jim Galvin (Afilias):@ steve - depends on what quality of identity you want - could be you have a "click wall" requiring people to at least assert who they are via an email address, for example.
Andrew Sullivan:@volker: I suggested before that what is needed is a "referral" field
Andrew Sullivan:that's true in any referral-based sstem
Maxim Alzoba (FAITID):As I understand, in Netherlands an IP address could be seen as a personal data ... so if a person is so wise to use his own noe dns server in registrations ... who knows where it lead us
steve metalitz:@Jim would that be consistent with rough #20, isn't requiring that assertion be asking for "requestor identification"?
Maxim Alzoba (FAITID):*leads
Volker Greimann:if someone wants it all, then he will have to answer a lot of captcha's
Lisa Phifer:@Michael, the levels of access referred to public, non-public, gated - but not methods of access that might be required
Maxim Alzoba (FAITID):@Volker, are you suggesting few captchas a time?
Volker Greimann:one captcha per query, one query per domain
Lisa Phifer:I abbreviated the subquestion a little but it actually says "(e.g., public, non-public, multi-tiered)"
Jim Galvin (Afilias):@steve - I agree that in our discussion we have answered the questions as shown. I was simply observing that we could have answered them differently and giving an example of how they could have been different. Thus, it is important to consider all the questions. The answer to 5.1 does not automatically answer the request, although it probably provides a strong hint.
Alan Greenberg:Is this a 90 minute meeting or are we overtime?
Nathalie Coupet:90 MINUTES
Maxim Alzoba (FAITID):in cases where LEAs violate privacy law - it is still a violation , unfortunately
Tim Chen:why is it every time LEAs get mentioned people assume they are violating privacy laws?
Nathalie Coupet:not if it is in the fight against a protected category in teh law
Nathalie Coupet:to defend a protected category I mean
Vicky Sheckler:@maxim - privacy law generally applies to personal data about natural persons. thin data in general does not implicate that type of data
Greg Shatan:I don't think any of 45 should apply to thin data.
Tim Chen:why do people keep invoking 'legally' or the law when it is off topic to the point we are discussion. I think we all understand your views at this point.
Lisa Phifer:Policy may state purpose(s) for data element access. That purpose could be implicit or explicit in a given query.
Greg Shatan:Maybe yes and no should not be the only two answers.
Lisa Phifer:@Steve, this WG need not agree to these principles - we can phrase any principles we think are appropriate and necessary in addition to WG agreements thus far
Maxim Alzoba (FAITID):if LEA access any kind of data following the procedures of access, then there are no questions
Lisa Phifer:Any objection to principle #44 - put red X in AC
Maxim Alzoba (FAITID):less then 300 jurisdictions
Lisa Phifer:Clarification: Any objection to principle #41 put red X in AC
Maxim Alzoba (FAITID):unfortunatey EU is powerfull enough to punish almost all of us
Andrew Sullivan:surely if a jurisdiction says no data may be published, then within in that jurisdiction in fact no data may be published?
Maxim Alzoba (FAITID):@Andrew, I think we need an example, until then it is hypothetical
Vicky Sheckler:+1 metalitz
Lisa Phifer:Proposed revision to 41. A minimum set of data elements must be accessible by unauthenticated RDS users.
Vicky Sheckler:like metaltiz' suggestion later
Vicky Sheckler:better
Alan Greenberg:Need to leave now. Thanks all.
Alex Deacon:not sure we can know what is the "most stringent applicable privacy regime" is. I'd prefer we drop it.
Maxim Alzoba (FAITID):applicable may be
Volker Greimann:Yes Greg, that is the intent of the phrase
Volker Greimann:since if you are in compliance with the most stringent regime, you are in compliance with all of them
Nathalie Coupet:But you impose undue restrictions to everyone else
Nathalie Coupet:You can still be liable for that
Michael Hammer:@Volker, what if a jurisdiction says all data elements MUST be public?
Volker Greimann:then that clearly is not the most stringent regime
Michael Hammer:For example, on the notion that a domain registration is akin to purchasing real estate?
Benny Samuelsen / Nordreg AB:No no no its not
Volker Greimann:well, the real estate register is only semi public
Volker Greimann:there is no internet lookup
Rod Rasmussen:Going to audio only
Michael Hammer:Not necessarily true. I can look up real estate records on the internet by address, owner name or other fields.
Volker Greimann:you have to physically mosey over to the local court that holds the register, apply for review of a certain piece of land in writing and then look at that.
Volker Greimann:maybe in the US.
Volker Greimann:not over here
Stephanie Perrin:ditto in Canada
Stephanie Perrin:There are important distinctions that we must keep in mind, between data being available, public and contained in a searchable public directory.
Volker Greimann:but the US have a weird relationship with data privacy anyway, see public arrest records
Michael Hammer:http://carroll.mfcdsoftware.com/re/re-search.php - from the auditors office in Carroll county Ohio
Stephanie Perrin:These are distinctions that the DPAs have pointed ouit in their correspondence with ICANN
Alex Deacon:maybe one day we will be able to query the public real estate blockchain....
Michael Hammer:this is true across much of the United sTates.
Volker Greimann:see my comment above!
Michael Hammer:you call it weird, others call it normal and appropriate.
Greg Shatan:There are also rigid interpretations of some jurisdictions' policies.
Volker Greimann:I think it is a good thing that there are certain hurdles to certain data. No one should be able to googly my name and see what the conditions for my land purchase were, what mortgage I have on it, etc.
Nathalie Coupet:I agree. It goes too far sometimes
Lisa Phifer:Proposed revision to 41. A minimum set of data elements must be accessible by unauthenticated RDS users.
Volker Greimann:Me
Lisa Phifer:Red X if you do not support that proposed revision
Alex Deacon:Also let not assume the future RDS will be full of personal registrations. it will contain commercial registrations also that are not subject to "stringent privacy regimes".
Volker Greimann:We need a limitation at least on the most stringent applicable law
Volker Greimann:/me waves, points to chat
Greg Shatan:Volker is just being very private...
Vicky Sheckler:generally, thin data doesn't include personal data about natural persons
Volker Greimann:We cannot take out the reservation of barriers put in place by data priacy regimes that may be applicable.
Michele Neylon:+1 Stephanie
Greg Shatan:Can't they consent?
Michele Neylon:To every possible usage of data??
Volker Greimann:I have no problems with limiting it to those privacy regimes that would apply to a data set.
steve metalitz:@Stephanie, can you identify which is "the most stringent privacy regime," so that it would be clearer to what regime the uamended #41 would subject thin data access?
Maxim Alzoba (FAITID):I suggest we find at least one example of such jurisdiction
Volker Greimann:For example, there is no reason to assume that for an american customer data living in the US, registering through an american registrar with all data stored in the US European data protection laws would apply
Lisa Phifer:I should point out that 41 refers to minimum set of data elements and not "thin data" - the EWG's minimum public data set included more than today's thin data elements
Maxim Alzoba (FAITID):or see it as a hypothetical reason
Vicky Sheckler:@stephanie and volker - no - it raises questions about hypothetical what-ifs. if that is the case that this is just a hypothetical, then it shoudln't be included. ICANN alsready has a conflict of laws procedures to deal with such unlikely edge cases
Michael Hammer:I would assrt that there is a minimum set of data elements required for the system to function.
Volker Greimann:the other question that raises though is the technical complexity this diffwerentiation would bring with it.
Lisa Phifer:NOTE: Newcomer tutorial will start when WG call ends; agenda and slides posted at https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_jBXfAw&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=kQuayJ_jdlu68e5ukETU-U843bPSuVedj_pBv7RCHjI&e=
Volker Greimann:Vicky: I disagree. If there is even a hypothetical effect then it NEEDS to be included
Vicky Sheckler:again - as I understand it, right now we are talking about thin data only.
steve metalitz:@tim those examples don't involve thin data, do they?
Volker Greimann:only if we can exclude any effect then it can be excluded
Vicky Sheckler:@volker, not when it is not grounded in any current or proposed privacy or data protection laws
Maxim Alzoba (FAITID):possibly - if the person used own DNS servier installed at home and aded coordinates to GEO databases ...
Maxim Alzoba (FAITID):*added
Volker Greimann:Vicky: That goes without saying
Lisa Phifer:DOmains having names servers is a different issue than whether names servers are published in RDS
Volker Greimann:but any potential effect of such laws and regulations needs to be taken into consideration and included
Maxim Alzoba (FAITID):it is an example - of possibly intended behaviour of the registrant to be able to claim that his personal data was abused
Alex Deacon:@volker - specific laws sure - but not sure how this can be done with hypothetical laws.
Maxim Alzoba (FAITID):@Michele, I did not mean to troll you :)
Alex Deacon:@greg +1
Michael Hammer:@Greg +1
Vicky Sheckler:thx. bye
Nathalie Coupet:Bye
Lisa Phifer:NOTE: Newcomer tutorial will start when WG call ends; agenda and slides posted at https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_jBXfAw&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=kQuayJ_jdlu68e5ukETU-U843bPSuVedj_pBv7RCHjI&e=
Volker Greimann:Alex: certain clauses in laws are subject to interpretation. Hypothetical means in this context that an effect cannot be excluded as it falls within a credible interpretation of said law.
Michele Neylon:Maxim :)
Michele Neylon:ok gotta go
Greg Shatan:All clauses in laws are subject to interpretation.
Alex Deacon:thanks and bye!
Patrick Lenihan:Thanks to Each and All!
Maxim Alzoba (FAITID):bye all
Viviane Vinagre:Thank you all
Viviane Vinagre:amazing discussion
Andrew Sullivan:bye all
Viviane Vinagre:I'm going to join
Michelle DeSmyter:Please standby for the Newcomer Tutorial
Viviane Vinagre:I have a friend that is willing to join
Viviane Vinagre:he's a member from NCUC
Lisa Phifer:All WG members and observers are welcome to join this tutorial. Those who are not members may listen to the recording
Lisa Phifer:This is to help us focus limited Q&A time on WG member/observer questions
Lisa Phifer:Thanks for standing by
Lisa Phifer:Presenters will be advancing slides during the tutorial for recording purposes
Lisa Phifer:All, if you have questions as we go along, feel free to type QUESTION: in chat. However, we will probably answer most questions at the end of the tutorial.
Geoffrey Noakes (Symantec):Lisa, where may I get a copy of the deck being presented?
Lisa Phifer:Deck posted at https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_jBXfAw&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=8_WhWIPqsLT6TmF1Zmyci866vcPSFO4VShFqESGe_5iHWGlBLwwwehFBfjrsjWv9&m=Suur11MKw9OUJoiOXK4V-fKrvP1OnUBKm0b-fUa98tQ&s=kQuayJ_jdlu68e5ukETU-U843bPSuVedj_pBv7RCHjI&e=
Geoffrey Noakes (Symantec):Thanks Lisa
Amr Elsadr:https://community.icann.org/x/rjJ-Ag
Lisa Phifer:Although we are approaching the end of our 60 minute tutorial slot, we will stay on for Q&A for those who have questions
Eric Rokobauer - Endurance:No questions - but thank you for going over this with us!
Sara Bockey:thank you!
Adam Lanier:Thanks Lisa, Marika and Amr!
Amr Elsadr:Thank you all for attending. We hope the tutorial was helpful.
Ankur Raheja:Thanks
Louise Marie Hurel:thanks you all
tim O'Brien:thanks folks, appreciate the background on a highly frustrating topic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170523/2ced8adb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 23 May 2017 Sheet1.pdf
Type: application/pdf
Size: 24600 bytes
Desc: Attendance RDS PDP 23 May 2017 Sheet1.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170523/2ced8adb/AttendanceRDSPDP23May2017Sheet1-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list