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,
Product Vulnerability Response Team
firstname.lastname@example.org - 816-914-4225
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,
- 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
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.