[Infrastructure] Reviving SC26 (Pandoc-Friendly Formatting)

Tim Hollebeek tim.hollebeek at digicert.com
Mon Mar 9 14:08:56 MST 2020


People always get this wrong.

 

Section 2.4(10) merely states that a ballot must include information about and a link to ballots that may conflict.  Providing provisions to avoid conflict is optional.

 

It’s a good idea to include provisions for all scenarios, but I think it’s very important everyone accurately understands what our Bylaws actually require.

 

-Tim

 

From: Infrastructure <infrastructure-bounces at cabforum.org> On Behalf Of Wayne Thayer
Sent: Monday, March 2, 2020 10:32 AM
To: Ryan Sleevi <sleevi at google.com>
Cc: infrastructure at cabforum.org
Subject: Re: [Infrastructure] Reviving SC26 (Pandoc-Friendly Formatting)

 

Yep, waiting until SC25 and SC27 complete their review periods seems like the best approach. We might also want to ask members to hold off on any other ballots so we can get SC26 completed.

 

On Mon, Mar 2, 2020 at 8:02 AM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Our Bylaws ( Section 2.4(10) ) require that you basically provide versions for every scenario if they're modifying the same section:

1) SC25 is excluded during IP review, SC27 is included

2) SC25 is included, SC27 is excluded during IP review

3) SC25 is excluded during IP review, SC27 is excluded during IP review

4) SC25 is included, SC27 is included

 

You're absolutely correct that the 'simple' answer is to wait until those ballots are finalized and start the discussion then.

 

*Other* ballots would have to consider both "with" and "without" SC26, if and only if they affect the same section as a section affected by SC26. That's far, far more manageable. And it's why I've been holding off on ballots, since you're close here.

 

On Mon, Mar 2, 2020 at 9:34 AM Jos Purvis (jopurvis) <jopurvis at cisco.com <mailto:jopurvis at cisco.com> > wrote:

That’s a good question. I could include “here’s what we’d vote on if SC25 and SC27 are included”, but then we also need to include “here’s 25 but not 27” and “here’s 27 but not 25”. Also, it occurred to me we could time the discussion period to coincide with the end of the review periods for them, but really it would have to restart after those review periods finish. This is one of the problems with a large ballot like this: it kind of has to hold up everything in order to go through, because it isn’t atomic to a single section of the bylaws.

 

What would be the best approach? 

 

 

-- 
Jos Purvis ( <mailto:jopurvis at cisco.com> jopurvis at cisco.com)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 <tel:(919)%20991-9114>  919.991.9114 (desk)

 

 

From: Wayne Thayer <wthayer at gmail.com <mailto:wthayer at gmail.com> >
Date: Sunday, March 1, 2020 at 10:16 AM
To: "Jos Purvis (jopurvis)" <jopurvis at cisco.com <mailto:jopurvis at cisco.com> >
Cc: "infrastructure at cabforum.org <mailto:infrastructure at cabforum.org> " <infrastructure at cabforum.org <mailto:infrastructure at cabforum.org> >
Subject: Re: [Infrastructure] Reviving SC26 (Pandoc-Friendly Formatting)

 

Jos - how will we handle the changes in ballots SC25 and SC27 that are not included in this ballot (they're still in the review period)?

 

On Fri, Feb 28, 2020 at 1:27 PM Jos Purvis (jopurvis) <jopurvis at cisco.com <mailto:jopurvis at cisco.com> > wrote:

I’d like to revive SC26 ASAP so we can finally pull it over the line. I’ve made what I think are the correct changes to the ballot below (and the attachments) to make it (a) up to date, and (b) conformant with what we discussed at the F2F in Bratislava. However, I’m well aware that I may have misremembered something from that week, so if this doesn’t look right or needs tweaking, please let me know. Thanks!

 

 

-- 
Jos Purvis ( <mailto:jopurvis at cisco.com> jopurvis at cisco.com)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 <tel:(919)%20991-9114>  919.991.9114 (desk)

 

The following is the ballot to update the BRs with formatting changes to make them Pandoc-friendly for changing our automation methods. I’m just looking for two endorsers at this point; I’ll add the timeline once we formally open the ballot.

 

BALLOT SC26: Pandoc-Friendly Markdown Formatting Changes

 

The following ballot is proposed by Jos Purvis of Cisco Systems and has been endorsed by XXX and YYY.

 

Purpose: This ballot modifies the formatting of the Baseline Requirements in order to make the presentation of content consistent and aligned with “vanilla” Markdown. This will permit the use of pandoc as a format-translation tool to automatically produce a PDF, DOCX, and HTML version of the Baseline Requirements document with each update and allow the Forum to use the Markdown-formatted version as the canonical version of the Baseline Requirements. This ballot does NOT declare any version canonical: it merely paves the way to the possibility of doing so in the future by making the document formatting cleaner. In addition, the ballot is not intended to change the meaning of the Baseline Requirements at all—much effort has been spent in ensuring the meaning and wording of the Requirements has not changed in reformatting the presentation elements.

 

Changes: The changes involved in the ballot are small formatting changes but large in number. As a result, rather than listing the changes individually, members are requested to review the redline of the ballot to see the differences. The pull request containing the set of changes to be implemented can be seen here:

https://github.com/cabforum/documents/compare/SC26-pandoc-friendly 

More specifically, the set of changes to the Baseline Requirements document being proposed in this ballot is shown in this commit:

            https://github.com/cabforum/documents/commit/a79e22a6ff828f184797fc19ad6dcc404f80f7c1 

 

In addition to the above changes, some template files are being added to Github that will assist in formatting but not change any BR content (commits 5386bf0 and 810196a). A copy of the resulting formatting changes in each document format can be seen in the attached documents (ref. BR-26.pdf, BR-26.html, BR-26.docx). These changed versions can be compared to the current versions of the document found at https://github.com/cabforum/documents.

 

 

 

-- 
Jos Purvis ( <mailto:jopurvis at cisco.com> jopurvis at cisco.com)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | +1 <tel:(919)%20991-9114>  919.991.9114 (desk)

 

_______________________________________________
Infrastructure mailing list
Infrastructure at cabforum.org <mailto:Infrastructure at cabforum.org> 
http://cabforum.org/mailman/listinfo/infrastructure

_______________________________________________
Infrastructure mailing list
Infrastructure at cabforum.org <mailto:Infrastructure at cabforum.org> 
http://cabforum.org/mailman/listinfo/infrastructure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200309/f7ab13b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200309/f7ab13b0/attachment-0001.p7s>


More information about the Infrastructure mailing list