<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:11.0pt;
font-family:"Calibri",sans-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.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:11.0pt;
font-family:"Calibri",sans-serif;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
--></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=MsoNormal>I’m not sure there are other valid cases (in fact I suspect there are not), but Wayne mentioned on the validation WG call that he’s concerned that this change could be very disruptive if not handled carefully, and I’m sympathetic to that concern. Especially since on the same call he also pointed out the same flaw that Dimitris did …<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m certainly not going to rule out the idea that there might be reasonable improvements to the ballot that other people will think of that we had not! After all, we already have an existence proof …<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><a name="_MailEndCompose"><o:p> </o:p></a></p><span style='mso-bookmark:_MailEndCompose'></span><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Monday, January 8, 2018 9:34 AM<br><b>To:</b> Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Cc:</b> Dimitris Zacharopoulos <jimmy@it.auth.gr>; CA/Browser Forum Public Discussion List <public@cabforum.org>; Rich Smith <richard.smith@comodo.com><br><b>Subject:</b> Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I'm not sure that's a good approach - namely, "making reasonable improvements to #1" is, I think, a question of whether there are _other_ cases beyond the one identified (in which WHOIS is not available).<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thus, I think framing it as 'reasonable improvements' may be implying there are other valid cases for #1, which I don't think has been provided. If we framed it as "If we remove #1, are there any other valid cases beyond the no-WHOIS TLDs that may be impacted"?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For concrete examples, I don't think the .no case is a good one :)<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 8, 2018 at 11:29 AM, Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I think you and Ryan are on the right track.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I’ve expressed before an interest in explicitly allowing RDAP in addition to WHOIS (I don’t support the idea of making the requirement more generic because security analysis is much more difficult for generic requirements).<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It wouldn’t be a bad thing if at the same time we added explicit requirements around the acceptable ways to directly contact a domain registrar. Like Rich, I want to see the details so I can determine whether the requirements make sense.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I was asked on Thursday to split 218 into two ballots, since it seems #1 will take a little more work than #5. #5 seems uncontroversial, but I keep getting requests for a longer timeline (possibly phased, with strong requirements to eliminate the egregious problems early) for #1.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Should we have two ballots so we can eliminate #5 early, while making reasonable improvements to #1?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>BTW, for those who have asked, the ballot 217 “you have the time you need” discussion requirements was the reason I wasn’t overly concerned about when I posted the ballot.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'>-Tim<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="m_-4947428814533930303__MailEndCompose"> </a><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I wonder, then, if it would resolve your concerns about the removal of 3.2.2.4.1 to update the Domain Contact method - the issues I highlighted on variability notwithstanding. That is, it sounds like we're in agreement that 3.2.2.4.1, as worded, is entirely ambiguous as to the level of assurance provided. The methods of contacting in 3.2.2.4.2/.3 are acceptable, the only question is how we determine the information. We allow WHOIS, for example, but as worded, it would preclude RDAP or other forms, and would preclude the cases (such as .gov) in which direct registry contact is required. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as provided by the Domain Registrar or, for TLDs in which the Registry provides information, the Registry. Acceptable methods of determination include the WHOIS record of the Base Domain Name, within a DNS SOA record [Note: This includes the hierarchal tree walking, by virtue of 3.2.2.4's recursion], or through direct contact with the applicable Domain Name Registrar or Domain Name Registry.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This can then be separately expanded to RDAP, or be moved more formally in to a section within 3.2 as to acceptable methods for the determination of the Domain Contact (e.g. moving the normative requirements for validation outside of the definition).<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>That seems like it would resolve the issues, right?<o:p></o:p></p></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>