<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Dear All,<o:p></o:p></span></p>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Please find the attendance of the call attached to this email</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">,
and the Adobe Connect chat, <span style="color:black">MP3</span> & Adobe Connect
<span style="color:black">recording</span>s<span style="color:black"> below for the Next-Gen RDS PDP Working group call held on Tuesday,
</span>25<span style="color:black"> July 2017 at 16:00 UTC.<o:p></o:p></span></span></p>
<p style="line-height:15.6pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">MP3: </span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#111111"><a href="http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-25jul17-en.mp3">http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-25jul17-en.mp3</a><o:p></o:p></span></p>
<p style="line-height:15.6pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">AC recording:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><a href="https://participate.icann.org/p6h8pfhjw5q/?OWASP_CSRFTOKEN=e2259dfccc4b8e6813510a4843eee224bf8223df4c80f2ea947f132a6e41e51a"><b><span style="color:black;background:white">https://participate.icann.org/p6h8pfhjw5q/</span></b></a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page:</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<a href="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=">
<span style="color:purple">http://gnso.icann.org/en/group-activities/calendar</span></a><span style="color:black"><o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">** Please let me know if your name has been left off the list **<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Mailing list archives:</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><a href="http://mm.icann.org/pipermail/gnso-rds-pdp-wg/"><span style="color:purple">http://mm.icann.org/pipermail/gnso-rds-pdp-wg/</span></a><span style="color:black"><o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Wiki
</span></b><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">agenda
<span style="color:black">page: </span> <a href="https://community.icann.org/x/TmfwAw">
<span style="font-weight:normal">https://community.icann.org/x/TmfwAw</span></a><o:p></o:p></span></b></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Thank you.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">Kind regards,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Julie
<span style="color:black"><o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">———————————————<o:p></o:p></span></p>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><b><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">AC Chat Next-Gen RDS PDP WG Tuesday,
</span></u></b><b><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">25<span style="color:black"> July 2017<o:p></o:p></span></span></u></b></p>
<p class="MsoPlainText"> Julie Bisland:Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday, 25 July 2017 at 16:00 UTC
<o:p></o:p></p>
<p class="MsoPlainText"> Julie Bisland:Agenda wiki page: <a href="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">
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</a>=
<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:unfortunately I have to be mobile today because of an appointment at 13:30<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:so I may not be able to participate as well as I might like
<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Handout to be displayed in today's call: <a href="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">
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</a>=
<o:p></o:p></p>
<p class="MsoPlainText"> Sam Lanfranco:Hello all, sorry I missed the surveymonkey poll. Too much rain on the farm - fish swimming in the field!<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:me too. did the poll have quorum?<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:19 respondents to this week's poll which is a decent turnout but not as strong as last week<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):Hello all<o:p></o:p></p>
<p class="MsoPlainText"> jonathan matkowsky:Sorry I am late.<o:p></o:p></p>
<p class="MsoPlainText"> steve metalitz:Agree with both key concepts <o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:syntax may be limiting<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Raise your hand if you disagree with possible key concept i)<o:p></o:p></p>
<p class="MsoPlainText"> Sam Lanfranco:I agree with Mark's points!<o:p></o:p></p>
<p class="MsoPlainText"> Scott Hollenbeck (Verisign):What would happen if an ICANN-described syntax definition disagrees with an IETF-specified protocol syntax definition?<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I think that syntax means protocol, so I must have the wrong understanding. what is meant?<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:This defeats privacy services<o:p></o:p></p>
<p class="MsoPlainText"> Julie Bisland:Andrew: line is cutting in and out<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:I heard him fine<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:ugh. I hate adobe connect<o:p></o:p></p>
<p class="MsoPlainText"> Sam Lanfranco:He asked if this puts ICANN in the position of creating protocols<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I'll send to the list, but I'm opposed to this (i)<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:I disagree with the notion of including a minimal identifyer requirement as it removes the option to use privacy services<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:when we use "syntax" in the text, we might be using it incorrectly for the purposes of this PDP<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:im on The mobile client so audio is often bad. in transit
<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:yes<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I think just specifying that syntax is defined by protocol docs & icann can define semantics
<o:p></o:p></p>
<p class="MsoPlainText"> 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)? <o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:why does this group care at all about syntax?<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@steve, what do we do in situations with person having a formal ID issued for Pravacy Proxy :) ?<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I doubt audio will come back, but see suggestions above
<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:@Steve: correct, as the registrar may not even have this data<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):when talking about syntax we need to have an example to better understand the idea why do we talk about it<o:p></o:p></p>
<p class="MsoPlainText"> 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?<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:@Maxim, see country code and email address, both of which have syntax requirements in the RAA<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:for affiliated registrars it is. for independant services, it is not<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I'm sorry, but I do not believe the ICANN community has the relevant skill to develop protocol syntax
<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Lisa, as I understand postal address is for communication and if the mail delivered , why adding additional requirements?
<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:just kick it to the protocol documents<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I'm ok with Rod's suggestion that the group select some<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):the same with e-mail. if it is deliverable, why adding definitions?<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:specific protocols <o:p></o:p></p>
<p class="MsoPlainText"> Scott Hollenbeck (Verisign):Agreed - reference existing standards. DO NOT produce new syntax requirements.<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:agreed as well <o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Scott Hollenbeck (Verisign):@Lisa: it also doesn't say that it can't define syntax.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@lisa sure. I want that 2 b a constraint
<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:@lisa but the policy may well outlive a technical standard<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Proposed alternative: RDS policy must include a definition for every gTLD registration data element including a semantic definition.<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:I'm ok with Rod's suggestion<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:@Greg some of those technical contraints have caused considerable heartache because they were developed without an understanding of current implementation challenges<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I disagree w/ Greg <o:p></o:p></p>
<p class="MsoPlainText"> David Cake:The existing RDAP Operational Profile is worth considering as an example of the sort of technical specifications ICANN does now.
<o:p></o:p></p>
<p class="MsoPlainText"> David Cake:https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:no, can't talk<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:external refs ok<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:No, syntax is not alayws defined by protocol docs<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:that could work<o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:@chuck, agree. similar to what Rod suggested IMO<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I understand Greg's position but imo that's still policy
<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:ok with Lisa's suggestion <o:p></o:p></p>
<p class="MsoPlainText"> Kal Feher:@lisa I'm fine with that<o:p></o:p></p>
<p class="MsoPlainText"> 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."<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:(registry 2013 RAA, I mean). <o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:That is a syntax requriement not spelled out in technical areas such as IETF docs
<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:appropriate standards allow for policy to address what those are for each element<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Benny / Nordreg AB:Might be reading this wrong but for me it looks like we MUST add a syntax definition<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):II wonder if unique ROID is enough? (instead of plain name)<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:that makes sense<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):btw - replacing name with Registrant ID ROID - helps with privacy protection
<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:very true ...one cannot transfer without and email.....a valid one at east which is registered....<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:Email is not common amongst people under 20 anymore<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:communcation standards change, so limiting us to a potentially outdated means could spell problems for the future<o:p></o:p></p>
<p class="MsoPlainText"> Michael Hammer:@Volker, that is an opinion, not a fact.<o:p></o:p></p>
<p class="MsoPlainText"> steve metalitz:@Volker, maybe those under 20s who lack e-mail are also not registering gTLD domain names.....<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):we might start with eradication of fax (seems to be bit outdated technology)<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Possible alternative for v) At minimum, an email address enabling contact with the <who?> must be collected and included in the RDS.<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:need more?<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:I can quote articles on the topic all day<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:if it is an opinion Mike, it is not mine per se<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:the technical or admin would be the ones who would need to have the email...<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:It is not true that people who don't regularly use email don't have an email address, though<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:you can't actually join most social networks without an email address, because it's the universal TOFU bootstrap<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:or else you use OAuth, and your identity there is TOFU bootstrapped by email<o:p></o:p></p>
<p class="MsoPlainText"> 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)<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:telephones, email, and XMPP (ha! Remember that?) are open standards and so it's not necessary to use a proprietary interface<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:Facebook IDs do not meet this criterion, because to contact someone via Facebook I need to join Facebook<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):lots of nice one time use free e-mailers, so the contact is lost right after the registration<o:p></o:p></p>
<p class="MsoPlainText"> Vicky Sheckler:apologies but i need to step off early today<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:Email accounts are free. No impediment to getting one.<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:other than having no use for it, Aaron.<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:My first name is Greg, Greiman.<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:why would I want for example a paypal account if I never want to use it?
<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:Oops, sorry<o:p></o:p></p>
<p class="MsoPlainText"> Ayden Férdeline:+1 Volker<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:There is an important difference with paypal: such accounts are entirely proprietary<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:The domain name registrant is registering a name whose meaning is created by reference to public infrastructure on the Internet<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:Of course, the alternative is to requre registars to validate registrations not by email, but by perhaps ten different means.
<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:Andres: ok, an instant messaging account then<o:p></o:p></p>
<p class="MsoPlainText"> 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?)<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:therefore, the kind of contact must somehow be part of that public, non-proprietary infrastructure<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I'd be fine if we said telephone or SIP or email or XMPP<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:if we include Skype ID, Facebook ID, Twitter handle, or Slack contact I'd be quite uncomfortable<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:(if people want to provide those, no objection. But they're not enough)<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Volker Greimann:But that is a discussion for way, way down the road<o:p></o:p></p>
<p class="MsoPlainText"> 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."<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:something like that<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Alternative for vi) might be "Data enabling one alternative method of contact must also be collected and included in the RDS."<o:p></o:p></p>
<p class="MsoPlainText"> 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. :-)<o:p></o:p></p>
<p class="MsoPlainText"> 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.
<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Green check if requiring one alternative to email as a contact?<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):sometimes people just loose phones, forget e-mails e.t.c<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):*lose<o:p></o:p></p>
<p class="MsoPlainText"> Abdeldjalil Bachar Bong:2 mails will be a good idea here we don't need social media accounts
<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:how come there's no 😖 emoji in the thing<o:p></o:p></p>
<p class="MsoPlainText"> Ayden Férdeline:I do not think the RDS should contain any contact details.<o:p></o:p></p>
<p class="MsoPlainText"> Ayden Férdeline:Sorry, no audio<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@Ayden why not?<o:p></o:p></p>
<p class="MsoPlainText"> Tapani Tarvainen:I'm fine with alternate contact as optional. Not sure about making it mandatory.<o:p></o:p></p>
<p class="MsoPlainText"> Abdeldjalil Bachar Bong:2 emails it will be fine here we don't need social media accounts
<o:p></o:p></p>
<p class="MsoPlainText"> steve metalitz:Confused about what was the question.
<o:p></o:p></p>
<p class="MsoPlainText"> Justin Mack:FWIW, I believe RDAP supports multiple optional contact mechanisms (such as XMPP)<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Yes, iv) is the first, v) is the second<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):we need to find persons fluent in RDAP first :) (including LEA officers)<o:p></o:p></p>
<p class="MsoPlainText"> 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. <o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Greg Aaron:+1 to Andrew's comment.<o:p></o:p></p>
<p class="MsoPlainText"> Tapani Tarvainen:+1 Andrew<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:+1 andrew<o:p></o:p></p>
<p class="MsoPlainText"> steve metalitz:+1 to Andrew that at least one non-proprietary means is essential (and should be mandatory).
<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):we already have a postal address<o:p></o:p></p>
<p class="MsoPlainText"> Tapani Tarvainen:"standards-based" is not enough, some standards are proprietary<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:Proposed agreement: At least one element enabling contact must be based on an open standard and not a proprietary communication method (Andrew?)<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@Lisa: WFM<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):a registrar can confirm that the person was contactable, but not that he/she will be contactable<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Benny / Nordreg AB:I fear we will get more crappy data registrants forget to update by adding to many contactable ways<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:As noted in last week's call, alternative facilitates overcoming failure in primary method<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I'm totally cool with multiple contact methods<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:and I think it will make operations better, and therefore we should support it<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:which is what all of Facebook and Skype and WeiChat and so on are<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:But I really like the language that Lisa already suggested for another poll, so I'm good<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I have grave doubts about "original registration date"<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:@Andrew, will include that variant<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I think it's going to create data problems<o:p></o:p></p>
<p class="MsoPlainText"> Benny / Nordreg AB:Why?<o:p></o:p></p>
<p class="MsoPlainText"> Michael Hammer:Yes<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:See slide 6 for brief descriptions of contacts, including Admin<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:Because for the largest existing registries it will be impossible to provide accurately<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:so unless we have a 0 day (which nobody will ever remember), it will be garbage data<o:p></o:p></p>
<p class="MsoPlainText"> Benny / Nordreg AB:True that are not a reliable source<o:p></o:p></p>
<p class="MsoPlainText"> 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!)<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:yes its helpful<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:You have a contact, then you assign it to roles for each domain name<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:It's not actually true that today you need to provide such different contacts today<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:That was EWG, in a nutshell<o:p></o:p></p>
<p class="MsoPlainText"> 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)<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:The fact that you have to do this in most registration user interfaces is just a mistake in implementation<o:p></o:p></p>
<p class="MsoPlainText"> 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.
<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:@Andrew, existing contacts cannot be applied to a new registration in today's WHOIS, correct?<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:it _displays_ as separate contact info<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:But only within one registry?<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:but that's a problem with the display not the underlying data<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:yeah, nobody shares contact data cross-registry<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:RDAP makes it possible<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:but I don't think most registries would feel comfortable with the consequences<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Lisa, all registries have ROIDs unique to them, so it is not reusable<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:though it'd be nice to use that functionality<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@Maxim: nonsense<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:ROIDs are unique by registry too<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:so you could refer to a ROID in another registry, no problem<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):registries have to use their own ROIDs<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:And whether reuse of contacts across domain name registrations must be supported by the RDS<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):for example in CL&D it is said so<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@Maxim: if they do, that's an implementation mistake in a contract<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:And whether reuse of contacts must be supported across registries or portable across registries (just some examples)<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:there's no reason why that has to be true technically<o:p></o:p></p>
<p class="MsoPlainText"> 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.
<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Andrew, usage of not own unique objects dangerous - you might refer to empty/deleted object<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:Rather than doing as Greg A suggested and subsuming one under another, why not make the distinctions?<o:p></o:p></p>
<p class="MsoPlainText"> Tapani Tarvainen:I like the roles approach.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:I agree with Rod<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):and if you create a time stamped copy - it is uniqe to that reqgistry again
<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:i like the roles as well<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:Don't make copies. These are online registries<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:follow references and incorporate the answer<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:whois can't do that but RDAP can<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):should we use ALL role for those who does not have multiple contacts?<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Andrew, we have seen disapearing objects in other systems
<o:p></o:p></p>
<p class="MsoPlainText"> 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)<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:If another system makes an object disappear, the registration is presumably out of conformance<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Andrew, but it means that Registry will have to check it's validity each ... minutes ... it is not process driven approach<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:@Maxim: I strongly agree that there may be consequences that need thinking<o:p></o:p></p>
<p class="MsoPlainText"> 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<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):@Rod, in some cases Registries have to act as Registrars (100 names + names like nic.TLD)<o:p></o:p></p>
<p class="MsoPlainText"> 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.<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:but I think we ought to discuss and understand the trade-off (there's some in the EWG report as Rod notes)<o:p></o:p></p>
<p class="MsoPlainText"> Rod Rasmussen:Registreis can assume the validator/registrar role too - would be a good candidate actually given their business expertise.<o:p></o:p></p>
<p class="MsoPlainText"> Maxim Alzoba (FAITID):bye all, need to drop the call, it was a good one<o:p></o:p></p>
<p class="MsoPlainText"> 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.
<o:p></o:p></p>
<p class="MsoPlainText"> Benjamin Akinmoyeje (Nigeria):Thank you <o:p></o:p></p>
<p class="MsoPlainText"> steve metalitz:Can we include all the EWG roles, not just the existing labels?
<o:p></o:p></p>
<p class="MsoPlainText"> Sam Lanfranco:Adios<o:p></o:p></p>
<p class="MsoPlainText"> Andrew Sullivan:bye all<o:p></o:p></p>
<p class="MsoPlainText"> Kris Seeburn:bye all<o:p></o:p></p>
<p class="MsoPlainText"> Lisa Phifer:@Steve, what do you want to include?<o:p></o:p></p>
<p class="MsoPlainText"> Rod Rasmussen:TTFN<o:p></o:p></p>
<p class="MsoNoSpacing" style="margin:0in;margin-bottom:.0001pt"><b><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"><o:p><span style="text-decoration:none"> </span></o:p></span></u></b></p>
</div>
</div>
</div>
</body>
</html>