[cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Sun Nov 8 19:59:32 UTC 2015


Responding to your questions.



1.  I'm puzzled by the phrase " official canonical version".  We have never had an official canonical version of any of our guidelines or requirements before -- we just have ballots, then update the guidelines or requirements as needed (to date, in both .doc and .pdf format), and we publish them here for everyone inside and outside of the Forum to use: https://cabforum.org/documents/ .  But we never declared any .doc or .pdf as the "canonical version" of anything -- that wouldn't have meant anything.



Is this new phrase "canonical version" in the ballot supposed to mean something new?  If yes, what?  If it's not supposed to mean anything new, let's drop it so there are no misunderstandings later.



My biggest issue on question 1 is whether it is wise to designate an particular application (in this case, GitHub) as the application the Forum *must* use for maintaining updated versions of our guidelines and requirements.  What if a new and better application (in the future "HubHub") comes along?  Will we need a new ballot to move from GitHub to HubHub?  Or what if we find GitHub doesn't work very well for us?  Will we need a ballot to stop using GitHub?



This seems like a foolish technical requirement for us to establish by a formal ballot, and I suggest the ballot authors drop it and go ahead and use GitHub for the time being.  I'm not sure we need anyone (the Chair or anyone else) specifying how we keep documents -- I'd rather let the people actually working on updating our documents choose what application they want to use.  (While many Forum members may be using GitHub today for code writing purposes, I wonder what percentage of the Forum members have no practical familiarity with the GitHub application – it would have been interesting to ask that question.)



2.  On converting the EVGL and Network Security requirements to an RFC 3647 format -- I wasn’t the one, but one or two people were enthusiastic about merging the BRs, the EVGL, and the Network Security guidelines into a single document once they were all in 3647 format.  If that's one of the goals of this ballot -- to make merger possible -- then the Working Group will have to avoid a number clash between the three documents (otherwise, you could have multiple Sections 3.2, etc. with the same numbers -- confusion).  But as soon as you do that, you have to worry about leaving “numbering room" in each document so you can add provisions later - for example, the BRs Section 3.2 on authentication stop today at Sec. 3.2.6 -- do you reserve 3.2.7 - 3.2.10 for future expansion of the BRs?



Where do you start the (new) numbering for current Section 11 of the EVGL covering authentication during the conversion?  You will have to put "3.2" at the front to fit the RFC 3647 format -- so will old EVGL Sec. Section 11.2.2 (4)(A)(iii)1.a. become new Section 3.2.11.2.2 (4)(A)(iii)1.a?  A lot of people will have to change forms and checklists, with no particular gain.



As to your other suggestion – that the numbers can clash and be the same in the different documents, and just use notations such as [EV]3.2.1 versus [BR]3.2.1 – how is this really useful to anyone?  What’s the point of the conversion in that case?



If there are people dying to know where the provisions of the current EVGL and Network Security guidelines would fit in the RFC 3547 format, why don’t you just add a basic table in each document, for example “EVGL Section 11 = RFC  3647 Section 3.2”.  That could be completed in an hour.



I wish these Ballots had come forward first as pre-ballots so we could have discussed issues like these in greater detail.





-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Sunday, November 08, 2015 1:10 AM
To: Kirk Hall (RD-US); CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub



On 05/11/15 03:07, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> wrote:

> I am perfectly satisfied if you and others want to use GitHub as the

> official canonical version for CABF documents for the next several

> months so we can all see how this will work.  But do you have to

> specify GitHub in your Ballot?  Why not take that out so we don’t ever

> have to vote to use another app instead?



So your view is that it's fine for e.g. the Chairperson to decide the official canonical location for the CAB Forum document repository, rather than it being decided by ballot?



If that's not what you are saying, I'm not sure what your proposal is.



> But here’s a specific question on how this is going to work.  On

> authentication, RFC 3647 puts most everything in to Section 3.2, and

> in the BRs we already have a Sec. 3.2.1 through 3.2.6 for DV and OV

> authentication.  How will you number (renumber) the EV Guidelines to

> an RFC 3647 format?  Will you start at Sec. 3.2.7?  But then you will

> never be able to add a Sec. 3.2.7 to the BRs, because it will be taken

> by the EVGL.



Are you concerned about numbering in the documents when they are separate, or the numbering in some non-canonical combined version of the documents?



In the former case, there is no problem with two separate documents both having a section 3.2.3, for example.



In the latter case, it's up to the merging script. You could either combine all sections marked 3.2.3 into one larger section 3.2.3, or you could label them 3.2.3 (a), 3.2.3 (b), and so on, or you could label them 3.2.3 (BR), 3.2.3 (EV)... It's up to you, and it's outside the scope of this ballot. The work this ballot enables merely makes it technically possible to produce merged documents, it doesn't mandate it or tell you how to organize it.



Gerv

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151108/1517dc24/attachment-0003.html>


More information about the Public mailing list