<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<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:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Times New Roman",serif;
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:62266767;
mso-list-template-ids:1446045996;}
@list l1
{mso-list-id:1675567934;
mso-list-type:hybrid;
mso-list-template-ids:2120642428 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D">Good Morning,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Times New Roman",serif;color:#1F497D">I think I am in agreement with most people on this, that option 3 (or C, whatever it is called) is the best short term solution “</span>define a "convention" that allows
the <city> and <cc> elements to contain placeholder values, such as: <city>-</city> and <cc>XX</cc> which pose no data protection issues<span style="font-family:"Times New Roman",serif;color:#1F497D">”.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Times New Roman",serif;color:#1F497D">Though I want to stress that I believe this is just the quick/short term solution and that I believe that the correct way to resolve this is to “update” RFC 5733. At minimum
to make city and cc optional but we should really look at what is needed for improving data privacy/protection on the whole. I also believe this work is extremely important and would like to see this as one of the items that the REGEXT group picks up and starts
working immediately.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D">Roger<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt">From:</span></b><span style="font-size:11.0pt"> gtld-tech <gtld-tech-bounces@icann.org>
<b>On Behalf Of </b>Gould, James via gtld-tech<br>
<b>Sent:</b> Thursday, February 28, 2019 7:51 AM<br>
<b>To:</b> Hollenbeck, Scott <shollenbeck@verisign.com>; gavin.brown@centralnic.com; gtld-tech@icann.org<br>
<b>Subject:</b> Re: [gtld-tech] EPDP recommendations and EPP<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText">Scott,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">There are a few issues that we need to address, which include:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">Technical Contact – Only 3 optional fields of Name, Phone, and Email are defined in EPDP Team Recommendation #7. Is the collection of the additional RFC 5733 disallowed?
<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">Registrant Contact – All of the Registrant data fields are defined as optional in EPDP Team Recommendation #7. This means that both Technical Contacts and Registrant Contacts
would need to get around the required <contact:name>, <contact:city>, and <contact:cc> elements in RFC 5733. <o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">Contacts Don’t Have a Type – Contacts are created without a type in RFC 5733, where type is based on the link from the domain name. Since a Contact is an object, it could
be a Registrant and Technical contact for a single domain or for many domains. Who would apply the policy for what fields are set or not set (client, server, or both)? My recommendation is for the client to apply the policy, since the client has the relationship
with the registrant. <o:p></o:p></span></li></ol>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">To meet the policy, my recommendation is to support RFC 5733 with placeholder values for the <contact:name>, <contact:city>, and <contact:cc> elements to indicate non-existence, to have the servers be flexible to the contact fields set
by the client, and to have the clients implement the policy related to what fields of a contact are set based on the type of the contact. This is not a perfect solution, but it would allow implementing the policy without a great amount of dependencies and
complexity (e.g., parallel contact mappings, adding typing to contacts, adding link type rules, and raising the issue of inconsistent server policies).
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I agree with your proposal of option 3, with the additional placeholder text for the required <contact:name> element, the server accepting a flexible number of contact fields (empty or placeholder) for all contacts, and the client implementing
the policy. <o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">—<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">JG<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">James Gould<o:p></o:p></p>
<p class="MsoPlainText">Distinguished Engineer<o:p></o:p></p>
<p class="MsoPlainText"><a href="mailto:jgould@Verisign.com">jgould@Verisign.com</a><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">703-948-3271<o:p></o:p></p>
<p class="MsoPlainText">12061 Bluemont Way<o:p></o:p></p>
<p class="MsoPlainText">Reston, VA 20190<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Verisign.com <<a href="http://verisigninc.com/">http://verisigninc.com/</a>>
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On 2/28/19, 7:53 AM, "gtld-tech on behalf of Hollenbeck, Scott via gtld-tech" <<a href="mailto:gtld-tech-bounces@icann.org%20on%20behalf%20of%20gtld-tech@icann.org">gtld-tech-bounces@icann.org on behalf of gtld-tech@icann.org</a>> wrote:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> > -----Original Message-----<o:p></o:p></p>
<p class="MsoPlainText"> > From: gtld-tech <<a href="mailto:gtld-tech-bounces@icann.org">gtld-tech-bounces@icann.org</a>> On Behalf Of Gavin Brown<o:p></o:p></p>
<p class="MsoPlainText"> > Sent: Wednesday, February 27, 2019 4:41 AM<o:p></o:p></p>
<p class="MsoPlainText"> > To: <a href="mailto:gtld-tech@icann.org">gtld-tech@icann.org</a><o:p></o:p></p>
<p class="MsoPlainText"> > Subject: [EXTERNAL] [gtld-tech] EPDP recommendations and EPP<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > Hi all,<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > The EPDP final report says that, if a domain name has a technical contact<o:p></o:p></p>
<p class="MsoPlainText"> > (whose information is different from the registrant's), the only data that<o:p></o:p></p>
<p class="MsoPlainText"> > registrars should send to registries are the technical contact's name, email<o:p></o:p></p>
<p class="MsoPlainText"> > address, and phone number (if any).<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > Assuming that technical contacts should still be created and managed as RFC<o:p></o:p></p>
<p class="MsoPlainText"> > 5733 contact objects, and also assuming that this recommendation is adopted<o:p></o:p></p>
<p class="MsoPlainText"> > without change, it poses a challenge, because the RFC requires all contact<o:p></o:p></p>
<p class="MsoPlainText"> > objects to have <city> and <cc> elements.<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > I've been thinking about how this could be resolved, here are some ideas (in<o:p></o:p></p>
<p class="MsoPlainText"> > descending order of nastiness):<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > * write a new RFC which updates RFC 5733 to make the <city> and <cc><o:p></o:p></p>
<p class="MsoPlainText"> > elements optional<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > * write a new EPP extension which makes the technical contact's name,<o:p></o:p></p>
<p class="MsoPlainText"> > email address, and phone number directly attributes of the the domain<o:p></o:p></p>
<p class="MsoPlainText"> > name rather than a contact object<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > * define a "convention" that allows the <city> and <cc> elements to contain<o:p></o:p></p>
<p class="MsoPlainText"> > placeholder values, such as: <city>-</city> and <cc>XX</cc> which pose no<o:p></o:p></p>
<p class="MsoPlainText"> > data protection issues.<o:p></o:p></p>
<p class="MsoPlainText"> ><o:p></o:p></p>
<p class="MsoPlainText"> > Any thoughts?<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"> I tend to prefer the last option. It doesn't have any dependencies on pushing documents through the IETF, and it doesn't get us into developing policy-specific specifications.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"> Scott<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
</div>
</body>
</html>