<div dir="ltr">Jeremy,<div><br></div><div>I think the trend has been to try to keep revisions simple - so that we don't introduce any unintentional scope. Could you expand on the reasoning for coupling these? As we saw with Ballot 193/197, it seems like it makes it more error prone.</div><div><br></div><div>You posed it as a ballot, so it makes it hard to comment on line items (Using word to "track changes" is not a very publicly accountable or managable process), but I'm hoping to better understand.</div><div><br></div><div>Could you</div><div>1) Highlight what you believe are inconsistencies in the existing language?</div><div>2) Highlight why you believe there are differences between subdomains and authorized domain names?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 4:41 PM, Jeremy Rowley via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6086402278758611437WordSection1"><p class="MsoNormal">While working on implementing the methods defined by ballot 169, we noticed a lot of inconsistencies in the language and process. This made some of the methods confusing, especially on how they applied to reuse of information and verification of subdomains/wildcards.  Attached is a proposal that we think clarifies the process and tightens up the language. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">A couple of notes:<u></u><u></u></p><ol style="margin-top:0in" start="1" type="1"><li class="m_-6086402278758611437MsoListParagraph" style="margin-left:0in">The proposal doesn’t intend to substantially change any of the methods. However, this is DigiCert’s interpretation of the requirements. Given the previous language, disagreement on the interpretation is likely and will highlight the need for a clarifying ballot.<u></u><u></u></li><li class="m_-6086402278758611437MsoListParagraph" style="margin-left:0in">This method doesn’t necessarily replace 190. If longer discussion is needed (because there are lots of changes), then this could be a subsequent revision to the validation methods and include more stringent controls (like reverifying WHOIS information within 30 days and restricting sub-domain methods). For now, I tried to keep the process and reuse the same.<u></u><u></u></li><li class="m_-6086402278758611437MsoListParagraph" style="margin-left:0in">The proposal separates out sub domain reuse, reuse of documentation, and splits the longer methods into discrete steps.  There are lots of redundant sections. This is intentional. The goal is to (eventually) talk about each method discretely and decide what requirements are tied to document reuse and sub-domain validation. <u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Look forward to your comments. <span class="HOEnZb"><font color="#888888"><u></u><u></u></font></span></p><span class="HOEnZb"><font color="#888888"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Jeremy<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></font></span></div></div><br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>