<div dir="ltr">Tim Hollebeek read the antitrust statement.<br><br>Attendance: Amanda Mendieta, Andrea Holland, Aneta Wojtczak, Ben Wilson, Clint Wilson, Dimitris Zacharopoulos, Enrico Entschew, Inigo Barreira, Janet Hines, Johnny Reading, Kati Davids, Michelle Coon, Natalia Kotliarsky, Nico Carpenter, Paul van Brouwershaven, Rebecca Kelley, Ryan Dickson, Ryan Sleevi, Shelley Brewer, Tim Hollebeek, Trevoli Ponds-White, Tyler Myers, Wendy Brown, Wayne Thayer<br><br>** Minute Takers:<br>Wayne Thayer agreed to take minutes. Corey Bonnell is up next time.<br><br>** Agenda:<br>CRL Validity Interval Ballot<br>Certificate Profiles<br><br>** CRL Validity Interval Ballot<br>Wayne said that he had incorporated some feedback including moving ‘validity period’ to the definitions section and that Ryan had subsequently moved the logic for computing time differences into the 1.6.4 Conventions section of the BRs.<br><br>Ryan Sleevi said the ballot is in good shape and noted that 366 days is the SHOULD and 367 days is the MUST, rather than 13 months/398 days as in Wayne’s original draft.<br><br>Tim said that Corey had expressed some concern over the convention of computing time differences impacting other time periods in the document.<br><br>Ryan said that it would, for example, impact the 90 days that CAs have to inform root programs of a delayed audit, but that was already questionable since ballot SC31. Ryan said that he did check for other impacted dates and others should review this as well.<br><br>Tim said that he would review but is likely to be comfortable with the ballot.<br><br>Wayne asked Trev and Kati to speak up if they are not willing to endorse this version. Dimitris also offered to endorse. Trev said she would review and Kati said that she would still endorse.<br><br>Dimitris said that his team feels that the inclusive part should not be included because the nextUpdate signals when the next CRL will be published.<br><br>Ryan said that this was discussed on the Mozilla list. Publishing at the half-second, for example, meets the requirement.<br><br>Tim said that consistency in time intervals throughout the document is also important for clarity.<br><br>** Certificate Profiles<br>Tim asked if there are any comments after the face-to-face presentation.<br><br>Ryan asked about phase-in periods. Are folks happy with how this is handled in the current draft? If so, Ryan will update the document with a phase-in period for everything that is a change rather than a clarification.<br><br>Tim said that he and Aneta had planned to work on an alternate approach to phase-ins prior to the face-to-face but have not yet done so.<br><br>Tim asked for 2 more weeks to propose their approach<br><br>Tim said that the goals are to create something simple with only one or two transition dates.<br><br>Ryan said that he is proposing one transition date from old to new profile, with fields that include a transition period clearly marked. There won’t be a bunch of different dates. Ryan said that this is consistent with the “effective date” approach taken for other ballots.<br><br>Tim said that his goal is to have a few transitions as possible. One would be great. The concern is around changes viewed as clarifications that may affect some CAs immediately. Tim would prefer the entire ballot to become effective at some future date.<br><br>Ryan said that he’d like to hear which clarifications could cause issues. He gave the example of banning underscores in DNS names and asked what clarifications in this ballot are similarly ambiguous?<br><br>Tim said that underscores are a great example because there were different interpretations that led to different conclusions. Tim referenced <a href="https://www.netmeister.org/blog/hostnames.html">https://www.netmeister.org/blog/hostnames.html</a>) Having an immediate effective date for clarifications means that anything clearly required before remains required until the new requirement goes into effect, so having clarifications go into effect immediately does not provide any advantage. Having immediate effective dates for clarifications has worked poorly with other ballots, and we should standardize on entire ballots always having future effective dates.<br><br>Ryan said that these arguments make sense in the abstract, but don’t apply to this ballot.<br><br>Tim said that the work involved in confirming that clarifications in this particular ballot are not controversial should be avoided. Having one effective date for everything in the ballot would be the simplest thing to do.<br><br>Ryan said that we need to understand, under Tim’s proposal, how we will make the requirements clear in the period of time between the ballot going into effect and the BRs being updated, and the effective date of the changes.<br><br>Tim said that he understands the concerns about making the document usable during the transition period.<br><br>Wayne asked if Tim plans to propose how to do this. Tim said yes.<br><br>Enrico asked about the qcStatements extension as mentioned in the face-to-face presentation. Ryan and Tim confirmed that the qcStatements extension would be permitted in the new profiles.<br><br>The call ended.</div>