<div dir="ltr">So, first and foremost, it's unclear whether you're proposing this as a 'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to break the problems out, or to solve the problems themselves.<div><br></div><div>I certainly am biased towards approaching this like most organizations approach code reviews - attempt to solve the smallest possible problem, provided it's solved comprehensively. This is why, for example, I broke out validation and reuse into separate draft ballots - because they are separable problems, even if closely related.</div><div><br></div><div>My understanding of your goals, although understandably limited here, is that something might be suited as:</div><div><br></div><div>- Ballot 190 [with whatever short-term fixes were accumulated since the passage of BRs 1.4.1]</div><div>- [Solve the language use issue - 'confirming control' vs 'validation' vs 'authenticate']. This would be as a singular ballot, and seemingly is independent from these other issues.</div><div>- [Solve the random value language]. This too seems solely limited to Section 2, so it doesn't seem to need to entail the other bits.</div><div>- [Solve the wildcard / subdomain issue]. This seems to be independent of any of the other aspects, but is also tricky and subtle enough to be worth its own discussion.</div><div>- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if the simple goal is to clarify the reuse. As you know, there's a broader spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the individual restrictions per method, and we even have requirements like those in 4.1.2, that we want to make sure are entirely self-consistent.</div><div><br></div><div>That's just a thought, based on the understanding of the issues. It seems like each of these can be broken into separate ballots. They're potentially issues, but I don't know that trying to solve them 'all in one go' would be the best way to resolve them, considering they don't seem interdependent on eachother (that is, reuse is not tied to wildcard validation, AFAICT), and some may be either more subtle or thornier to sort out.</div><div><br></div><div>Regardless, _each_ of these would have to be reviewed in the full context of the BRs to make sure we don't end up with any conflicts from other sections (again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still potentially conflicting), and to figure out the best way to resolve those issues.</div><div><br></div><div>I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's something we could discuss independent of any of the other perceived issues.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 12:13 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</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="blue" vlink="purple"><div class="m_-941032598202645497WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">That’s fine.  How would you like it broken up? I could break it up by validation method or by issue statement. <u></u><u></u></span></p><p class="MsoNormal"><a name="m_-941032598202645497__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></a></p><span></span><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Tuesday, May 16, 2017 10:06 AM<br><b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><span class=""><br><b>Subject:</b> Re: [cabfpub] Domain validation<u></u><u></u></span></span></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><u></u><u></u></p><div><div class="h5"><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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">1) The document is presented as a ballot because I based the revisions on 190.  If there are discrete sub-components someone doesn’t like, I don’t mind breaking it up into chunks.  </span><u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The problem is not about 'not liking'. It's about a tremendous amount of text that tries to solve a whole host of issues, all at once, and without clear identification of the goals or related changes. This makes it incredibly difficult to review, and all the more likely of a Ballot 193/197 problem being introduced. Further, the approach to creating the ballot creates issues like recently discovered by Ben in Ballot 198, in which the 'proposed text' and the 'redlined version' actually substantially differed from what was actually adopted (more on that for another thread).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It's not that I disagree with your goals - I think you've captured some very useful things to do. I'm just not sure there's any reasonable hope that we'd be confident it was appropriately reviewed, especially in light of the substantive discussion re: Ballot 190 that still needs adoption, and because of that, makes it very hard to consider voting in favor. This is, for what it's worth, notably similar to some of the subordinate CA discussions.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">While that comes across negative (and almost certainly would be reflected in a vote, should it come to that), I'm incredibly thrilled that someone such as yourself has taken a comprehensive look at it, and I'm thrilled that you've found and identified issues. Just the means of attempting to fix them is perhaps less than ideal, and much like I'd send back an overly complex code review back to the submitter as "overly complex; simplify", I'm trying to figure out if there's a way to tease out the issues or look at incrementalist approaches here.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This is why even with a 'small' change (the OCSP profile), which only removes a few lines of text, I tried to extensively annotate the reasonings behind each change, the dependencies, and their relationship - see <a href="https://github.com/sleevi/cabforum-docs/pull/2" target="_blank">https://github.com/sleevi/<wbr>cabforum-docs/pull/2</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I'm also not sure I'd agree with some of your problem statements, so that's where helping identify what you see as the problem can sort out an appropriate solution :)<u></u><u></u></p></div></div></div></div></div></div></div></div></blockquote></div><br></div>