<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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:1675567934;
mso-list-type:hybrid;
mso-list-template-ids:2120642428 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0: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="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="MsoPlainText" style="mso-list:l0 level1 lfo1">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></li><li class="MsoPlainText" style="mso-list:l0 level1 lfo1">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></li><li class="MsoPlainText" style="mso-list:l0 level1 lfo1">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></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">jgould@Verisign.com<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 <http://verisigninc.com/> <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" <gtld-tech-bounces@icann.org on behalf of gtld-tech@icann.org> 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 <gtld-tech-bounces@icann.org> 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: gtld-tech@icann.org<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>