[gnso-rds-pdp-wg] Attendance, Recordings & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 25 July 2017 at 16:00 UTC
Julie Bisland
julie.bisland at icann.org
Tue Jul 25 20:24:16 UTC 2017
Dear All,
Please find the attendance of the call attached to this email, and the Adobe Connect chat, MP3 & Adobe Connect recordings below for the Next-Gen RDS PDP Working group call held on Tuesday, 25 July 2017 at 16:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-25jul17-en.mp3
AC recording: https://participate.icann.org/p6h8pfhjw5q/<https://participate.icann.org/p6h8pfhjw5q/?OWASP_CSRFTOKEN=e2259dfccc4b8e6813510a4843eee224bf8223df4c80f2ea947f132a6e41e51a>
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 agenda page: https://community.icann.org/x/TmfwAw
Thank you.
Kind regards,
Julie
———————————————
AC Chat Next-Gen RDS PDP WG Tuesday, 25 July 2017
Julie Bisland:Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday, 25 July 2017 at 16:00 UTC
Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_TmfwAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=6i8jqbCVk7h2K6VcksCYSyYBD2wU4XanD0PwrrevGL4&s=TDEQOTHo-B2HwS_pe7Gu3-MHgYh19o_qp5bVhdcHGic&e=
Andrew Sullivan:unfortunately I have to be mobile today because of an appointment at 13:30
Andrew Sullivan:so I may not be able to participate as well as I might like
Lisa Phifer:Handout to be displayed in today's call: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086734_RDSPDP-2DHandout-2DFor25JulyCall.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=6i8jqbCVk7h2K6VcksCYSyYBD2wU4XanD0PwrrevGL4&s=swsxUMzKvn-oT_CZMVaaZvMdx4T4V9hyRZxvl9-z3OY&e=
Sam Lanfranco:Hello all, sorry I missed the surveymonkey poll. Too much rain on the farm - fish swimming in the field!
Volker Greimann:me too. did the poll have quorum?
Lisa Phifer:19 respondents to this week's poll which is a decent turnout but not as strong as last week
Maxim Alzoba (FAITID):Hello all
jonathan matkowsky:Sorry I am late.
steve metalitz:Agree with both key concepts
Volker Greimann:syntax may be limiting
Lisa Phifer:Raise your hand if you disagree with possible key concept i)
Sam Lanfranco:I agree with Mark's points!
Scott Hollenbeck (Verisign):What would happen if an ICANN-described syntax definition disagrees with an IETF-specified protocol syntax definition?
Andrew Sullivan:I think that syntax means protocol, so I must have the wrong understanding. what is meant?
Volker Greimann:This defeats privacy services
Julie Bisland:Andrew: line is cutting in and out
Kal Feher:I heard him fine
Andrew Sullivan:ugh. I hate adobe connect
Sam Lanfranco:He asked if this puts ICANN in the position of creating protocols
Andrew Sullivan:I'll send to the list, but I'm opposed to this (i)
Volker Greimann:I disagree with the notion of including a minimal identifyer requirement as it removes the option to use privacy services
Kal Feher:when we use "syntax" in the text, we might be using it incorrectly for the purposes of this PDP
Andrew Sullivan:im on The mobile client so audio is often bad. in transit
Andrew Sullivan:yes
Andrew Sullivan:I think just specifying that syntax is defined by protocol docs & icann can define semantics
steve metalitz:@Volker, if the registered name holder is the privacy/proxy customer (sometimes called "beneficial registrant"), do you think that information should not be collected at all (leaving to one side whether and when it should be disclosed)?
Kal Feher:why does this group care at all about syntax?
Maxim Alzoba (FAITID):@steve, what do we do in situations with person having a formal ID issued for Pravacy Proxy :) ?
Andrew Sullivan:I doubt audio will come back, but see suggestions above
Volker Greimann:@Steve: correct, as the registrar may not even have this data
Maxim Alzoba (FAITID):when talking about syntax we need to have an example to better understand the idea why do we talk about it
steve metalitz:@Volker, but on PPSAI IRT call two hours ago, weren't you saying that this information should be included in the registrar's data escrow?
Lisa Phifer:@Maxim, see country code and email address, both of which have syntax requirements in the RAA
Volker Greimann:for affiliated registrars it is. for independant services, it is not
Andrew Sullivan:I'm sorry, but I do not believe the ICANN community has the relevant skill to develop protocol syntax
Maxim Alzoba (FAITID):@Lisa, as I understand postal address is for communication and if the mail delivered , why adding additional requirements?
Rod Rasmussen:On the "syntax" issue, as a matter of policy, we could/should be looking at stating what standards should be used, for example for phone numbers or e-mail addresses. These exist and should be used for universal ability to make various contacs happen.
Andrew Sullivan:just kick it to the protocol documents
Andrew Sullivan:I'm ok with Rod's suggestion that the group select some
Maxim Alzoba (FAITID):the same with e-mail. if it is deliverable, why adding definitions?
Andrew Sullivan:specific protocols
Scott Hollenbeck (Verisign):Agreed - reference existing standards. DO NOT produce new syntax requirements.
Kris Seeburn:agreed as well
Lisa Phifer:Note the key concept does not say policy must define syntax - it says it must include one, which could be done by reference to an accepted standards for that type of data
Scott Hollenbeck (Verisign):@Lisa: it also doesn't say that it can't define syntax.
Andrew Sullivan:@lisa sure. I want that 2 b a constraint
Kal Feher:@lisa but the policy may well outlive a technical standard
Rod Rasmussen:You can even abstract this in policy to the level of "must use a universally accepted protoocol for contacdt elements" and leave it to the implementators.
Lisa Phifer:Proposed alternative: RDS policy must include a definition for every gTLD registration data element including a semantic definition.
Kal Feher:I'm ok with Rod's suggestion
Kal Feher:@Greg some of those technical contraints have caused considerable heartache because they were developed without an understanding of current implementation challenges
Lisa Phifer:Another alternative: RDS policy must include a definition for every gTLD registration data element including semantic definition and (by reference to appropropriate standards) a syntax definition
Andrew Sullivan:I disagree w/ Greg
David Cake:The existing RDAP Operational Profile is worth considering as an example of the sort of technical specifications ICANN does now.
David Cake:https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en
Andrew Sullivan:no, can't talk
Andrew Sullivan:external refs ok
Greg Aaron:No, syntax is not alayws defined by protocol docs
Kris Seeburn:that could work
Kal Feher:@chuck, agree. similar to what Rod suggested IMO
Lisa Phifer:Trying again - Another alternative: RDS policy must include a definition for every gTLD registration data element including semantic definition and (by reference to appropropriate standards) a syntax definition
Andrew Sullivan:I understand Greg's position but imo that's still policy
Andrew Sullivan:ok with Lisa's suggestion
Kal Feher:@lisa I'm fine with that
Greg Aaron:Example: registry contract says that "Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats."
Greg Aaron:(registry 2013 RAA, I mean).
Greg Aaron:That is a syntax requriement not spelled out in technical areas such as IETF docs
Lisa Phifer:alternative: RDS policy must include a definition for every gTLD registration data element including semantic definition and (by reference to appropropriate standards) a syntax definition
Lisa Phifer:appropriate standards allow for policy to address what those are for each element
Lisa Phifer:Proposed WG agrement to be tested by poll is therefore: RDS policy must include a definition for every gTLD registration data element including both a semantic definition and (by reference to appropropriate standards) a syntax definition
Benny / Nordreg AB:Might be reading this wrong but for me it looks like we MUST add a syntax definition
Maxim Alzoba (FAITID):II wonder if unique ROID is enough? (instead of plain name)
Volker Greimann:that makes sense
Maxim Alzoba (FAITID):btw - replacing name with Registrant ID ROID - helps with privacy protection
jonathan matkowsky:i want to apologize in advance that I have to leave the meeting early. I hope everyone has a great day/evening. I will review the upcoming poll and participate that way as a follow-up to this meeting.
Kris Seeburn:very true ...one cannot transfer without and email.....a valid one at east which is registered....
Volker Greimann:Email is not common amongst people under 20 anymore
Volker Greimann:communcation standards change, so limiting us to a potentially outdated means could spell problems for the future
Michael Hammer:@Volker, that is an opinion, not a fact.
steve metalitz:@Volker, maybe those under 20s who lack e-mail are also not registering gTLD domain names.....
Maxim Alzoba (FAITID):we might start with eradication of fax (seems to be bit outdated technology)
Volker Greimann:https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjZp7e-8qTVAhVH1RQKHc5mD28QFggqMAE&url=https%3A%2F%2Fwww.inc.com%2Fjohn-brandon%2Ffurther-proof-that-email-is-dying-a-slow-and-agonizing-death-3-new-trends.html&usg=AFQjCNEO-_TqK8QtipXCuXo8YWe-mEFMnA
Volker Greimann:https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjZp7e-8qTVAhVH1RQKHc5mD28QFggkMAA&url=https%3A%2F%2Ftechcrunch.com%2F2016%2F03%2F24%2Femail-is-dying-among-mobiles-youngest-users%2F&usg=AFQjCNFTC2pl_LSs913mEYrfBWiwhq_PmQ
Volker Greimann:https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjZp7e-8qTVAhVH1RQKHc5mD28QFggzMAM&url=https%3A%2F%2Fmartechtoday.com%2Femail-2017-dying-platform-still-worthy-investment-196318&usg=AFQjCNEJoGPdBsK8Ezhs6E7mswaQls2VlA
Lisa Phifer:Possible alternative for v) At minimum, an email address enabling contact with the <who?> must be collected and included in the RDS.
Volker Greimann:need more?
Volker Greimann:I can quote articles on the topic all day
Greg Aaron:It might be interesting to have an optional field where contacts can list an alternate electronic contact address on a service other than email (like a Facebook address). But email address should be required.
Volker Greimann:if it is an opinion Mike, it is not mine per se
Kris Seeburn:the technical or admin would be the ones who would need to have the email...
Andrew Sullivan:It is not true that people who don't regularly use email don't have an email address, though
Tapani Tarvainen:Yes. It's reasonable to assume ISPs/registrars will have email and provide such for their customers long enough that requiring email for RDS won't cause serious problems.
Andrew Sullivan:you can't actually join most social networks without an email address, because it's the universal TOFU bootstrap
Andrew Sullivan:or else you use OAuth, and your identity there is TOFU bootstrapped by email
Andrew Sullivan:I think there must be a requirement for _some_ contact method that is not proprietary (i.e. that does not require joining that proprietary protocol in order to use it)
Andrew Sullivan:telephones, email, and XMPP (ha! Remember that?) are open standards and so it's not necessary to use a proprietary interface
Andrew Sullivan:Facebook IDs do not meet this criterion, because to contact someone via Facebook I need to join Facebook
Maxim Alzoba (FAITID):lots of nice one time use free e-mailers, so the contact is lost right after the registration
Vicky Sheckler:apologies but i need to step off early today
Greg Aaron:Email accounts are free. No impediment to getting one.
Volker Greimann:other than having no use for it, Aaron.
Greg Aaron:My first name is Greg, Greiman.
Volker Greimann:why would I want for example a paypal account if I never want to use it?
Volker Greimann:Oops, sorry
Ayden Férdeline:+1 Volker
Andrew Sullivan:There is an important difference with paypal: such accounts are entirely proprietary
Andrew Sullivan:The domain name registrant is registering a name whose meaning is created by reference to public infrastructure on the Internet
Tapani Tarvainen:Many registrars already provide proxy email addresses. I'd expect them to provide such linked to non-email contacts it their customers want it.
Greg Aaron:Of course, the alternative is to requre registars to validate registrations not by email, but by perhaps ten different means.
Volker Greimann:Andres: ok, an instant messaging account then
Lisa Phifer:@Marc, on vi, is the issue "may" (as is must provide an option to collect....) or is the issue that an alternative must be collected (mandatory to collect?)
Andrew Sullivan:therefore, the kind of contact must somehow be part of that public, non-proprietary infrastructure
Andrew Sullivan:I'd be fine if we said telephone or SIP or email or XMPP
Andrew Sullivan:if we include Skype ID, Facebook ID, Twitter handle, or Slack contact I'd be quite uncomfortable
Andrew Sullivan:(if people want to provide those, no objection. But they're not enough)
Volker Greimann:@Marc: I think we might want to revisit all other policies for compatibility atthe end and revoke those that are superseded or contradicted.
Volker Greimann:But that is a discussion for way, way down the road
Andrew Sullivan:I think therefore it's "at least one standards-based non-proprietary contact method more than one is preferred. Multiple alternative contact methods of any sort are acceptable in addition to the first mandatory one."
Andrew Sullivan:something like that
Lisa Phifer:Alternative for vi) might be "Data enabling one alternative method of contact must also be collected and included in the RDS."
Greg Aaron:We could require registrar s to support registrant communications via Facebook, LinkedIn, Vkontakte, Chinese mobile chat apps, etc. Or, you could require registrants to provvide an email address. :-)
steve metalitz:@MArc, hasn't it been noted that if e-mail address is not collected that domain name could never be transferred? These policies are all inter-related, it seems.
Andrew Sullivan:Part of Greg's point, of course, is that it is possible that joining Facebook and WeiChat is not going to be allowed
Lisa Phifer:Green check if requiring one alternative to email as a contact?
Maxim Alzoba (FAITID):sometimes people just loose phones, forget e-mails e.t.c
Maxim Alzoba (FAITID):*lose
Abdeldjalil Bachar Bong:2 mails will be a good idea here we don't need social media accounts
Andrew Sullivan:how come there's no 😖 emoji in the thing
Ayden Férdeline:I do not think the RDS should contain any contact details.
Ayden Férdeline:Sorry, no audio
Andrew Sullivan:@Ayden why not?
Tapani Tarvainen:I'm fine with alternate contact as optional. Not sure about making it mandatory.
Abdeldjalil Bachar Bong:2 emails it will be fine here we don't need social media accounts
steve metalitz:Confused about what was the question.
Justin Mack:FWIW, I believe RDAP supports multiple optional contact mechanisms (such as XMPP)
Lisa Phifer:@Greg, possible alternative: vi) In addition to email address, data enabling one alternative method of contact must be colleted and included in the RDS.
Lisa Phifer:Yes, iv) is the first, v) is the second
Maxim Alzoba (FAITID):we need to find persons fluent in RDAP first :) (including LEA officers)
steve metalitz:As noted in my comments on poll, multiple contact means should be collected in order to maximize contactability. This does NOT mean all these means would be displayed. But redundancy in what is collected is a valuable feature.
Greg Aaron:I don;t mind an optional electronic contact field (which you could fill in with your twitter handle or Facebook account or whatever).. But email must be required.
Lisa Phifer:Raise hand if you disagree with iv) Data enabling at least one way to contact the registrant must be collected and included in the RDS.
Greg Aaron:+1 to Andrew's comment.
Tapani Tarvainen:+1 Andrew
Kris Seeburn:+1 andrew
steve metalitz:+1 to Andrew that at least one non-proprietary means is essential (and should be mandatory).
Maxim Alzoba (FAITID):we already have a postal address
Tapani Tarvainen:"standards-based" is not enough, some standards are proprietary
Lisa Phifer:Proposed agreement: At least one element enabling contact must be based on an open standard and not a proprietary communication method (Andrew?)
Andrew Sullivan:@Lisa: WFM
Maxim Alzoba (FAITID):a registrar can confirm that the person was contactable, but not that he/she will be contactable
Andrew Sullivan:The purpose of the contact is partly to be able to solve problems related to operation of a domain. The registrant is ultimately responsible for that operation, and therefore the buck has to stop there, and therefore we need to be able to reach a registrant
Benny / Nordreg AB:I fear we will get more crappy data registrants forget to update by adding to many contactable ways
Lisa Phifer:As noted in last week's call, alternative facilitates overcoming failure in primary method
Andrew Sullivan:I'm totally cool with multiple contact methods
Andrew Sullivan:and I think it will make operations better, and therefore we should support it
Andrew Sullivan:but we really do need to have some mechanism for every registrant that doesn't require everyone in the world to be able to use a potentially commercially-fragmented system
Andrew Sullivan:which is what all of Facebook and Skype and WeiChat and so on are
Benny / Nordreg AB:I am not saying that it's a bad things but the experience are that people do not updated these things before its to late, when they are no contactable
Andrew Sullivan:But I really like the language that Lisa already suggested for another poll, so I'm good
Andrew Sullivan:I have grave doubts about "original registration date"
Lisa Phifer:@Andrew, will include that variant
Andrew Sullivan:I think it's going to create data problems
Benny / Nordreg AB:Why?
Michael Hammer:Yes
Lisa Phifer:See slide 6 for brief descriptions of contacts, including Admin
Andrew Sullivan:Because for the largest existing registries it will be impossible to provide accurately
Andrew Sullivan:so unless we have a 0 day (which nobody will ever remember), it will be garbage data
Benny / Nordreg AB:True that are not a reliable source
Andrew Sullivan:I liked very much the roles stuff in the EWG report. I thought that was excellent (and note, also totally consistent with the EPP data model. Good work, ScottH!)
Kris Seeburn:yes its helpful
Lisa Phifer:You have a contact, then you assign it to roles for each domain name
Andrew Sullivan:It's not actually true that today you need to provide such different contacts today
Lisa Phifer:That was EWG, in a nutshell
Andrew Sullivan:in fact the underlying data model is that you create a single contact, and then associate it with the domain name via ROID (in EPP)
Andrew Sullivan:The fact that you have to do this in most registration user interfaces is just a mistake in implementation
steve metalitz:Can we map the "roles" against the full range of reasons for contactabilty? Once all these are sorted it may become more apparent how many "roles" are needed and how they should be defined.
Lisa Phifer:@Andrew, existing contacts cannot be applied to a new registration in today's WHOIS, correct?
Andrew Sullivan:@Lisa: no, actually. If you do whois yitter.info, you will discover that my contact info (which I just realised is all out of date! oops) is all the same contact ROID
Andrew Sullivan:it _displays_ as separate contact info
Lisa Phifer:But only within one registry?
Andrew Sullivan:but that's a problem with the display not the underlying data
Andrew Sullivan:yeah, nobody shares contact data cross-registry
Tapani Tarvainen:I may be paranoid here, but a clarification for 29 might be needed: it could be read to imply it must be public that a proxy service is being used, i.e., a "hidden proxy" (where it's not apparent it's a proxy) would be disallowed.
Andrew Sullivan:RDAP makes it possible
Andrew Sullivan:but I don't think most registries would feel comfortable with the consequences
Maxim Alzoba (FAITID):@Lisa, all registries have ROIDs unique to them, so it is not reusable
Andrew Sullivan:though it'd be nice to use that functionality
Andrew Sullivan:@Maxim: nonsense
Andrew Sullivan:ROIDs are unique by registry too
Lisa Phifer:I think we may be able to untangle some underyling key concepts for discussion, such as allowing contacts to be tied to roles
Andrew Sullivan:so you could refer to a ROID in another registry, no problem
Maxim Alzoba (FAITID):registries have to use their own ROIDs
Lisa Phifer:And whether reuse of contacts across domain name registrations must be supported by the RDS
Rod Rasmussen:@Steve - that's pretty much what we did within the EWG. There may be some of that material still avaialble if staff hasn't already published that for the PDP WG.
Maxim Alzoba (FAITID):for example in CL&D it is said so
Andrew Sullivan:@Maxim: if they do, that's an implementation mistake in a contract
Lisa Phifer:And whether reuse of contacts must be supported across registries or portable across registries (just some examples)
Andrew Sullivan:there's no reason why that has to be true technically
steve metalitz:+1 to Rod, let's look at the full range of reasons for contact and potential "roles" to the extent EWG did so.
Maxim Alzoba (FAITID):@Andrew, usage of not own unique objects dangerous - you might refer to empty/deleted object
Rod Rasmussen:I think this cross registry issue is HUGE and we shoudl be addressing it. As a contact, I want ONE AND ONLY ONE thing to update across all my domains regardless of TLDs - I don't care at all about TLD's, I care about making my life easy to administer all my domains. We should put a checkmark by this to discuss.
Andrew Sullivan:Rather than doing as Greg A suggested and subsuming one under another, why not make the distinctions?
Tapani Tarvainen:I like the roles approach.
Andrew Sullivan:I agree with Rod
Maxim Alzoba (FAITID):and if you create a time stamped copy - it is uniqe to that reqgistry again
Kris Seeburn:i like the roles as well
Andrew Sullivan:Don't make copies. These are online registries
Andrew Sullivan:follow references and incorporate the answer
Andrew Sullivan:whois can't do that but RDAP can
Maxim Alzoba (FAITID):should we use ALL role for those who does not have multiple contacts?
Maxim Alzoba (FAITID):@Andrew, we have seen disapearing objects in other systems
Lisa Phifer:IMPORTANT: Action item: WG members may suggest alternative wording for key concepts v) and vi) by 18.00 UTC on-list for inclusion in this week's poll. Staff to include those permutations in this week's poll testing vi) and vi)
Rod Rasmussen:See "validators" in the EWG for where/how contacts are created. Registrars connect contacts to domains and enter those relationships at the appropriate registries.
Andrew Sullivan:If another system makes an object disappear, the registration is presumably out of conformance
Maxim Alzoba (FAITID):@Andrew, but it means that Registry will have to check it's validity each ... minutes ... it is not process driven approach
Rod Rasmussen:Registrars can of course be validatos of contacts. The key is one object I control as a contact and then the actions of registrars and registries are to manitain the proper associations with domain names.
Andrew Sullivan:@Maxim: I strongly agree that there may be consequences that need thinking
Andrew Sullivan:and I understand the existing business models that cause this to be problematic and maybe the business realities don't make this reasonable
Maxim Alzoba (FAITID):@Rod, in some cases Registries have to act as Registrars (100 names + names like nic.TLD)
Rod Rasmussen:@Andrew - yes - we covered that a bit in the EWG report as well - would create a status issue for the domain when the contact object disappears or no longer compies with needed provision of elelments.
Andrew Sullivan:but I think we ought to discuss and understand the trade-off (there's some in the EWG report as Rod notes)
Rod Rasmussen:Registreis can assume the validator/registrar role too - would be a good candidate actually given their business expertise.
Maxim Alzoba (FAITID):bye all, need to drop the call, it was a good one
Julie Bisland:The next GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 01 August 2017 at 16:00 UTC for 90 minutes.
Benjamin Akinmoyeje (Nigeria):Thank you
steve metalitz:Can we include all the EWG roles, not just the existing labels?
Sam Lanfranco:Adios
Andrew Sullivan:bye all
Kris Seeburn:bye all
Lisa Phifer:@Steve, what do you want to include?
Rod Rasmussen:TTFN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170725/3102ae4f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 25 July.pdf
Type: application/pdf
Size: 336712 bytes
Desc: Attendance RDS PDP 25 July.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170725/3102ae4f/AttendanceRDSPDP25July-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list