[Infrastructure] Reviving SC26 (Pandoc-Friendly Formatting)

[Jos Purvis (jopurvis)]

Sure! I'll have a look. I think you're right--it's pretty much just the addition of Appendix C and then a little bit in the middle of the document, and I think I did those as atomic changes, so would it work to say, "if SC27 is not adopted, then commits xyzpdq1 and xyzpdq2 will be redacted" and have that suffice?

--
Jos Purvis (jopurvis at cisco.com<mailto:jopurvis at cisco.com>)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | Controls & Trust Verification


From: Ryan Sleevi <sleevi at google.com>
Date: Thursday, 12 March, 2020 at 16:50
To: "Jos Purvis (jopurvis)" <jopurvis at cisco.com>
Cc: "infrastructure at cabforum.org" <infrastructure at cabforum.org>, Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [Infrastructure] Reviving SC26 (Pandoc-Friendly Formatting)

I *think* we might be able to say that if SC27 is not adopted, the modifications to section X and Appendix Y (I think it's only two sections) would not apply. Smithing is needed for the ballot text (to make sure the text is included in the ballot about what doesn't apply), but that could expedite things.

Do you want to try that?

On Thu, Mar 12, 2020 at 4:25 PM Jos Purvis (jopurvis) <jopurvis at cisco.com<mailto:jopurvis at cisco.com>> wrote:
OK! After yesterday's bug-ironing on Github, it looks like maybe we're there. Just to check, it looks like the guidance for the ballot would be this:
<snip!>
If SC29 passes, this ballot is unaffected, as they do not modify the same document (BRs vs. NCSSR)
If SC27 ends its review period without IPR exception and is accepted into master, then this ballot will implement the following changes:
            https://github.com/cabforum/documents/compare/4f3f38d..8b70d19 (modulo document date and version number)
</snip!>
Since we figured out yesterday that there are some changes that will supersede the SC27 content, I'll time this ballot's discussion period to start after the IPR for SC27—otherwise we have to prepare a separate commit that implements only the non-SC27 fixes (which I can do, but would prefer not to have to 😊 ).

Sound good?

--
Jos Purvis (jopurvis at cisco.com<mailto:jopurvis at cisco.com>)
.:|:.:|:. cisco systems  | Cryptographic Services
PGP: 0xFD802FEE07D19105  | Controls & Trust Verification


From: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>
Date: Wednesday, 11 March, 2020 at 12:35
To: "Jos Purvis (jopurvis)" <jopurvis at cisco.com<mailto:jopurvis at cisco.com>>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>, "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,

I updated to a PR with https://github.com/cabforum/documents/pull/165 and left several (hopefully minor) comments. There was still one area that accidentally reverted part of SC24, regarding underscores.

That said, as far as I could tell, your ballot didn't/doesn't conflict with SC27 - that is, you do not modify the same sections (3.2.2.4, Appendix C). Is that right? If so, we may be able to revert that change* and kick off this discussion

* If we do go the revert route, let's sync up on Slack, just to make sure that if/when SC26 is accepted and merged upstream, it doesn't accidentally revert SC27 from upstream. Because https://github.com/cabforum/documents/pull/165/commits/549dcc6dc40898e9862fd49f2a5b70f7206b1793 was something you hand-merged, it just requires a few extra steps to do cleanly :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20200312/f420cb68/attachment.html>