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.
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. My understanding of your goals, although understandably limited here, is that something might be suited as: - Ballot 190 [with whatever short-term fixes were accumulated since the passage of BRs 1.4.1] - [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. - [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. - [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. - [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. 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. 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. 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. On Tue, May 16, 2017 at 12:13 PM, Jeremy Rowley <[email protected]> wrote: > That’s fine. How would you like it broken up? I could break it up by > validation method or by issue statement. > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Tuesday, May 16, 2017 10:06 AM > *To:* Jeremy Rowley <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]> > *Subject:* Re: [cabfpub] Domain validation > > > > > > > > On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley < > [email protected]> wrote: > > 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. > > > > 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). > > > > 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. > > > > 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. > > > > 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 > https://github.com/sleevi/cabforum-docs/pull/2 > > > > 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 :) >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
