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

[kirk_hall at trendmicro.com]

Gerv, be aware that the changes this ballot (and you) want to make *may* offer good things to some people - it's too soon to tell if that's true - but they *will* definitely impose new and unwelcome burdens on others (the renumbering of the documents in particular).  So the objections to this ballot are not churlish or reactionary, they are real and it would be nice if they were treated seriously and not dismissed.  

The (mythical) motto of the US Army Corps of Engineers is said to be "Keep Busy!" as they straighten meandering rivers, then later they have to build levies to stop the resulting floods, and then they restore the meandering rivers again to help the environment.  I think this working group is marching to its own drummer, but as you may have noticed from some comments, not everyone thinks these changes are useful or welcome.  I get the feeling that the working group is not taking these comments into consideration.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Sunday, November 08, 2015 12:11 PM
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 08/11/15 19:59, kirk_hall at trendmicro.com wrote:
> 1.  I'm puzzled by the phrase " official canonical version".  

I merely mean "the place everyone is supposed to give as an answer to the question: "where do I get an official copy of the latest EV guidelines?". Currently, the answer to that is "download the .doc or .pdf from the website." Those are the official canonical versions.

There may be other conversions or versions floating around, but they are not canonical - i.e. you should not rely on them being complete or up-to-date, because the CAB Forum does not guarantee that any other copies anyone else might be providing will be complete or up-to-date. We maintain the canonical version, and we maintain it on our website in two particular formats.

> 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).

No. Again, as was gone over in the meeting: people want the _ability_ to merge and make their own unofficial merges; it is no part of the plan to merge the official versions. Exactly how they do that merge, and deal with section number clashes, is up to them. I proposed 3 possible ways, just to put your mind at rest that those ways exist and the people who want to do this are not faced with a technical impossibility.

> 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?

<sigh> My suggested notation was a suggested notation that the people making these unofficial merged versions may or may not choose to use. If you don't like it, when you make a merged version for Trend Micro, then use a different mechanism. Or, if you don't want to make a merged version, stop worrying about the (trivial) problems faced by people who do :-)

> 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.

Because such a table would not be machine-readable. The point of the conversion to RFC 3647 format is that it makes it _possible_ for humans to ask machines to merge the documents into unofficial versions which may be useful to those humans. That would not be possible with a table, or if the documents remain mastered in .doc rather than Markdown.

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>