<div dir="ltr">I think the comparison to software development scheduling is apt - as this is effectively encouraging a "waterfall" model. It means that necessary improvements may take up to 3 additional months to be implemented, which means it may take up to 3 additional months for Subscribers and Relying Parties needs can be effectively met.<div><br></div><div>The issue here is also one without data, and I suppose it comes as no surprise that I'm generally not sympathetic to claims without evidence. </div><div><br></div><div>For example, if you examine our five most recent ballots for the Baseline Requirements, you'll find that of 224, 223, 219, 220, and 218, only two (220 and 218) provided a more restrictive interpretation, and those two both included defined transition dates relative to the risk and goal.</div><div><br></div><div>Perhaps you'd be able to take what you believe is a representative sample - if you don't believe the past calendar year's worth of changes is representative - to demonstrate and explain the value. To be honest, based on the above methodology, I don't see the problem as stated or presented being fair or accurate, and I see substantial downside compared to the alternatives discussed, so I'm hoping you can help better illustrate the problem that is worth solving relative to those tradeoffs.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 1:26 PM Richard Smith <<a href="mailto:rich@comodoca.com">rich@comodoca.com</a>> wrote:<br></div><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_5713641925506600507WordSection1"><p class="MsoNormal">Dates/time between freezing the version and publication can be debated.  I think this addresses the same problem as the alternate proposal in a better way.  CAs don’t have to try to keep track of arbitrary dates.  We will know well ahead of time what to expect and when to expect it.  It also makes life significantly easier for the maintainers of the documents and the web site administrators because they won’t have to push out new publications on an arbitrary and random basis.  I think this would solve a host of problems just like version control and development scheduling in software does.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Regards,<u></u><u></u></p><p class="MsoNormal">Rich<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> <br><b>Sent:</b> Wednesday, October 17, 2018 3:11 AM<br><b>To:</b> Richard Smith <<a href="mailto:rich@comodoca.com" target="_blank">rich@comodoca.com</a>>; <a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a><br><b>Subject:</b> Re: [Servercert-wg] Proposal to address ballot effective date problem<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Could you specifically explain the benefits you see for such a fixed schedule? It seems the only real element of the discussion today that this is addresses is that it allows for as little as two weeks from the adoption of a ballot to enforcement.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It seems like the alternative proposal offered - to set a common fixed expectation - is more beneficial to the CAs and the auditors tasked with actually performing those assessments (as opposed to developing the criteria). That is, ballots that complete the IP review will be consistently brought into force 30 days later, unless there is a specific consideration mentioned in the ballot.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I can't help but feel your proposal is optimizing for a different problem, one which wasn't discussed, and so I fear I may be missing what you believe the additional value compared to the other proposal.<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Wed, Oct 17, 2018 at 3:01 AM Richard Smith via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></p></div><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">As discussed at the Shanghai F2F today, there is a lot of confusion around ballot effective date and the current procedure is difficult to follow.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">To fix the problem I propose that we move to a quarterly release schedule for both BR and EVG using the following method:<u></u><u></u></p><ol start="1" type="1"><li class="MsoNormal" style="margin-bottom:8.0pt">Dates of publication:<u></u><u></u></li></ol><ol start="1" type="1"><ol start="1" type="a"><li class="MsoNormal" style="margin-bottom:8.0pt">February 1: Will include ballots which complete IPR review between October 16 and January 15<u></u><u></u></li><li class="MsoNormal" style="margin-bottom:8.0pt">May 1: Ballots which complete IPR review between January 16 and April 15 <u></u><u></u></li><li class="MsoNormal" style="margin-bottom:8.0pt">August 1: Ballots which complete IPR review between April 16 and July 15<u></u><u></u></li><li class="MsoNormal" style="margin-bottom:8.0pt">November 1: ballots which complete IPR review between July 16 and October 15<u></u><u></u></li></ol></ol><p class="m_5713641925506600507m7208692369044278908msonormal" style="margin-bottom:8.0pt">Ballot effective date will be the date upon which the BR or EVG containing it is published unless otherwise specified in the ballot itself and voted upon accordingly.  We need to keep the ability to specify an alternate date in the ballot in order to address critical items more quickly if necessary and also to allow additional time for some items if that is deemed necessary.<u></u><u></u></p><p class="m_5713641925506600507m7208692369044278908msonormal" style="margin-bottom:8.0pt"> <u></u><u></u></p><p class="m_5713641925506600507m7208692369044278908msonormal" style="margin-bottom:8.0pt">I also think this type of scheduled publication will help our associates at WebTrust and ETSI to track changes and get them incorporated into their audit criteria more smoothly.<u></u><u></u></p><p class="m_5713641925506600507m7208692369044278908msonormal" style="margin-bottom:8.0pt"> <u></u><u></u></p><p class="MsoNormal">Regards,<u></u><u></u></p><p class="MsoNormal"><b>Rich Smith</b><u></u><u></u></p><p class="MsoNormal"><i><span style="font-size:10.0pt">Senior Compliance Manager</span></i><u></u><u></u></p><p class="MsoNormal"><span style="font-size:9.0pt;color:#00a46b">ComodoCA.com</span><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div><p class="MsoNormal">_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="http://cabforum.org/mailman/listinfo/servercert-wg" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></p></blockquote></div></div></div></blockquote></div>