|
|
I think Bill’s second vote should be considered valid.
Ideally, procedures for handling such situations should be documented before voting. “Would a more complete discussion of issuance strategies prior to the voting period have affected the way you voted?” No.
A more comprehensive discussion and review of the reasons people gave for voting in the 1st and 2nd rounds though likely would change my vote.
Most important is the question of whether you would have voted differently if Option A was 7 digits, specifically, or if you would have voted differently given some other number of fixed digits in the ID field you would have deemed desirable. I *might* have voted differently if the length was 7 digits (although I think this is an excessive length).
I definitely would vote differently *now* if the length was 6 digits.
My change, from previous votes *for* the variable length option, is due in large part to review of the all of the excellent reasons other board members have given when submitting their votes during the 2 rounds of voting. I think 6 digits is ideal. Consider:
If we had held a vote simply for Fixed Length (including all fixed length proposals … 5, 6, 7, 8, 9) vs. Variable Length (exactly as described in the two rounds of voting), Fixed Length would likely win, and then we would have a second vote to determine
the number of digits in the Fixed Length. Thanks and regards, CA
Technologies
Product Vulnerability Response Team wilja22@ca.com - 816-914-4225 From: owner-cve-editorial-board-list@lists.mitre.org
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Boyle, Stephen V. -----Original Message----- Folks, Thank you very much for your time, attention and patience as we get the
CVE ID Syntax change sorted out. The second vote closed as scheduled at 11:59 EDT on May 22nd, 2013.
We reached a voting quorum (18 voters from a pool of 23 eligible voters), and we reached a majority on the selection of Option B, with 3 votes cast for the revised “8 digit fixed length” Option A and 15 votes for Option B. Before we declare the vote final and binding, there are a couple of items that we feel should be addressed. Everyone has worked hard to shape the revised ID syntax and we expect it to be ”the” permanent ID syntax for CVE far into the future. (You may note that we are saying “expect it to be …” The last time we did this, we said “we’ll never need more than 9,999 Identifiers in a year.”) As such, we want to make sure that we have fully answered all questions and fully addressed all concerns to the satisfaction of the Board. -------------------------------------------------- - Bill Wall’s re-vote During the second round vote, Bill Wall changed his vote from Option B, for which he voted mistakenly, to the revised Option A. While the sentiment of the comments during the vote was to accept Bill’s re-vote as valid, because it was during the vote we did not hear from everyone on the Board. While Bill’s changed vote has no effect on the outcome of the second round vote, we want to ensure that we have fully allowed for comments from the Board. As such, we believe that the feeling of the Board to date is that Bill’s (second) vote for the revised Option A is valid. If there is any dissent with the proposed formal acceptance of Bill’s re-vote, Board members should please post your thoughts and reasons to this list. -------------------------------------------------- - Issuance strategies for revised ID syntax identifiers Several questions have been raised about how we would specifically propose to issue IDs based on the new ID syntax. For example, would Option B IDs begin being issued as CVE-2014-0001 or CVE-2014-1000? Internally we have been referring to this topic as “issuance strategies.” Our thoughts on said issuance strategies have so far been to delay any proposals and discussion until after the vote, on the presumption that Board members may have different opinions depending on which option is ultimately chosen. However, comments made during the voting period have raised questions in our minds as to whether that presumption on our part is valid. The question we would like to put to the Board is: “Would a more complete discussion of issuance strategies prior to the voting period have affected the way you voted?” As above, please post your thoughts and responses to this list. -------------------------------------------------- - 8 digit fixed ID field length of the revised Option A This issue has caused us the most concern. During the voting period there were several comments about the length of the revised Option A ID field, including: - 8 digits was not reflective of pre-vote fixed length discussions (Our explanation for how 8 digits came to be proposed is appended.) - Fewer digits may have caused more Board members to vote for Option A - There was not sufficient discussion of the length of the fixed field prior to the vote on the reformulated Option A - There should be a re-vote with a further-revised Option A
As noted above, we want to make sure that the permanent selection of the revised CVE ID Syntax is in accordance with the Board’s consensus opinion. To that end, we want to hear from the Board members, particularly those with concerns about the revised Option A. Most important is the question of whether you would have voted differently if Option A was 7 digits, specifically, or if you would have voted differently given some other number of fixed digits in the ID field you would have deemed desirable. -------------------------------------------------- We recognize that the clock is ticking, but we want to ensure the consensus of the Board in the selection of the new CVE ID syntax. Please let us know your thoughts on the above. A timely response will be most welcome. Steve Boyle ************************************************************** MITRE rationale for proposing an 8 digit (revised) fixed-length identifier. What follows is our summary of the salient points as we interpreted and/or understood them regarding the length of the fixed-length identifier field option. This set of thoughts is what led MITRE to propose 8 digits as the length for the revised Option A. Please note that this is a summary, rather than an exhaustive view. If we misunderstood or otherwise misconstrued comments, we apologize and solicit corrections. Notable points (in rough time order): - A brief review of the discussion leading up to the first round of voting seemed to indicate satisfaction with the 6-digit fixed length ID proposal.
- During the first round of voting, some Board members noted that they would have changed their vote to Option A if the identifier field provided more than 6 digits. This would have had a material effect on results of the vote (a tie between Option A and Option B), since some of the Board members who voted for option B could have instead voted for Option A. - In the discussion after the first round vote, there were a number of posts to the list about the preferred or acceptable length of Option A. The posts discussed options that included a preference for six digits up to 12 or more depending on the formatting. - While it was explicitly proposed that the display of Option A might not have to be padded with leading zeros (to prevent transcription, readability, etc. errors), MITRE felt that an extended fixed length field that did not require padding with leading zeros was so close to Option B as to be non-differentiable. - A poll was called, in which Board members were asked whether they preferred fixed or variable length, and if they preferred fixed length, what number of digits would be sufficient in the ID field. We noted (belatedly) that the poll called for “sufficient” length as opposed to a preferred length. We do not know if this affected the outcome of the poll. - While not everyone responded to the poll, of the Board members who preferred a fixed length identifier field: - Three named 9 digits as sufficient - Three named 6 digits as sufficient - One named either 6 or 7 as sufficient - Based on our assessment and judgment of the above, we selected and proposed 8 digits as a reasonable compromise. Our thinking was that while it wasn’t 9 digits, 8 still provided an enormous pool of identifiers; 6 digits had been deemed insufficient, and 7 digits still caused some concern about the available address space. Also, the selection of 8 digits was thought to provide opportunities for humans to “chunk” the identifier field into two sets of four digits. |