On 12/3/2018 5:28 μμ, Tim Hollebeek wrote: > > Well, the clock can be extended by posting a new version (with version > number). And there is no requirement that the new version have any > differences. So you can keep a ballot alive indefinitely if the > proposer is paying attention. The 21 days is just to kill abandoned > ballots. > > > > IETF is March 17-23^rd . If Ryan and I can’t get IETF to approve some > version of the errata in a timely manner, I suggest we go forward > without them. It’s been long enough. I’ll let everyone know how the > discussion in London goes. > > > > Also there appears to be some bad math on the end time of the > discussion period in the original version of the ballot. That alone > might be a good reason for posting a new version 😊 > > > > -Tim >
With the new rules, you can trigger the voting period with the final text even at March 28th (at the latest). I don't think the "Discussion end time" makes a difference since the Bylaws are very clear on the 7+ days for discussion :) Thanks, Dimitris. > > > *From:*Public [mailto:[email protected]] *On Behalf Of > *Dimitris Zacharopoulos via Public > *Sent:* Monday, March 12, 2018 3:26 AM > *To:* [email protected] > *Subject:* Re: [cabfpub] Ballot 219: Clarify handling of CAA Record > Sets with no "issue"/"issuewild" property tag > > > > On 7/3/2018 9:02 μμ, Corey Bonnell via Public wrote: > > Hello, > > Several weeks ago, after receiving feedback from several Forum > members, I submitted an IETF erratum > (https://www.rfc-editor.org/errata_search.php?eid=5244 > > <https://clicktime.symantec.com/a/1/_dfjzFBLFWWu3TtSSb258nrvIo9PjiZ6EINdAY3hg5U=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata_search.php%3Feid%3D5244>) > for this clarification so that we may potentially be able to > directly include the erratum text in the Baseline Requirements as > was done for erratum 5065. However, there has been no response > from the IETF in regard to getting this erratum approved, so we > would like to proceed with Ballot 219 to clarify this in the > Baseline Requirements in the short term. We will continue to > pursue getting the RFC language clarified, but that appears that > it will take quite some time. > > > > The wording of the ballot below is the same as the version sent in > late January with the exception of a slight change to > “future-proof” the language based on a suggestion by Gerv and the > BR version has been bumped up to the latest version. > > > > We would like to begin the discussion period for this ballot. We > would highly appreciate any feedback and comments that anyone has > before bringing this ballot to a vote. > > > > I’d be happy to create a redline, but I’m unsure of our current > preferred process for doing so. If Github > (https://github.com/cabforum/documents > > <https://clicktime.symantec.com/a/1/4cnBDQ-JMP2wxqhzMSjmi4KjTQs01n3y_Yi08QrgHwc=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments>) > is the current preferred method, I’d like to point out that the > “master” branch is currently out of date (it’s currently 1.5.4, > whereas the current adopted version is 1.5.6). > > > > Ballot 219: Clarify handling of CAA Record Sets with no > "issue"/"issuewild" property tag > > > > Purpose of this ballot: > > > > RFC 6844 contains an ambiguity in regard to the correct processing > of a non-empty CAA Resource Record Set that does not contain any > issue property tag (and also does not contain any issuewild > property tag in the case of a Wildcard Domain Name). It is > ambiguous if a CA must not issue when such a CAA Resource Record > Set is encountered, or if such a Resource Record Set is implicit > permission to issue. > > > > Given that the intent of the RFC is clear (such a CAA Resource > Record Set is implicit permission to issue), we are proposing the > following change to allow for CAA processing consistent with the > intent of the RFC. > > > > The following motion has been proposed by Corey Bonnell of > Trustwave and endorsed by Tim Hollebeek of Digicert and Mads Egil > Henriksveen of Buypass. > > > > -- MOTION BEGINS -- > > This ballot modifies the “Baseline Requirements for the Issuance > and Management of Publicly-Trusted Certificates” as follows, based > upon Version 1.5.6: > > > > In section 3.2.2.8, add this sentence: > > CAs MAY treat a non-empty CAA Resource Record Set that does not > contain any issue property tags (and also does not contain any > issuewild property tags when performing CAA processing for a > Wildcard Domain Name) as permission to issue, provided that no > records in the CAA Resource Record Set otherwise prohibit issuance. > > > > to the end of this paragraph: > > When processing CAA records, CAs MUST process the issue, > issuewild, and iodef property tags as specified in RFC 6844, > although they are not required to act on the contents of the iodef > property tag. Additional property tags MAY be supported, but MUST > NOT conflict with or supersede the mandatory property tags set out > in this document. CAs MUST respect the critical flag and not issue > a certificate if they encounter an unrecognized property with this > flag set. > > > > -- MOTION ENDS – > > > > The procedure for approval of this ballot is as follows: > > Discussion (7+ days) > > Start Time: 2018-03-07 19:00:00 UTC > > End Time: Not Before 2017-03-10 19:00:00 UTC > > > > Vote for approval (7 days) > > Start Time: TBD > > End Time: TBD > > > > > > *Corey Bonnell* > > Senior Software Engineer > > t: +1 412.395.2233 > > > > *Trustwave** *| SMART SECURITY ON DEMAND > www.trustwave.com > > <https://clicktime.symantec.com/a/1/esxpAFsW4yzcLvuyiRSGLU5XqPMaJtsgbNP3BtI0wzo=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=http%3A%2F%2Fwww.trustwave.com%2F> > > > > > _______________________________________________ > > Public mailing list > > [email protected] <mailto:[email protected]> > > https://cabforum.org/mailman/listinfo/public > > <https://clicktime.symantec.com/a/1/h9_RPGffXzOThunxElSFYzMNZr0CZoId1LZqkKjybKs=?d=gJpjg_n3FbpDyP_Ng3Qhe1LcnmYhQB4WE5LK78ISpw3j19Wq2r4pzz1Q_JpCK1TW3j64DgExJBMOH6mDAYlvmPTcGAuyf5Y8waQuHacRiIEs2uhKFS_1IJveDOA4uuQP03rNr54M8lHPxgXVfbCoyC7tbhs1wODAPB4oElC0yD7Y1sOTUyWU8_az0Q39LNkkzA_4nn4M8oGDMafbkF91UfOKWMneObWs2ieTRV5EWFQY2rkfVFWjjOHEhDvwUXNn9HujUGGYwoz7zh43EI9_11FmTcPdzdDsgZprK0jRWiCSoy0Clm2vQO9xO1eNz89LEACC-I7NqQ3PbWj9oDXxuPq7D1GRsDS-GS_xqdNAhPRwsCEsgAL9bz3lVIrn1_Kj_oCKDupWFBvkU2Hy_PTtNaP5rvZmjpr1FVUhrQddRr7fNo8dDXcqOLDO8LgrCi5SpAsTkHOoj5rIrp1CjBfFkzMqJIpxgMGzC0c%3D&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic> > > > I would like to note that according to section 2.3 (c) of the Bylaws, > the proposers of this ballot have 21 calendar days (starting on March > 7th 2018) to start the voting period, otherwise the ballot > automatically fails. If my calculations are correct, the final day to > start the voting is March 28th. > > > Thank you, > Dimitris. >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
