[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CVE ID Syntax change - Round two vote results and comments



 

 

-----Original Message-----
From: Boyle, Stephen V.
Sent: Thursday, May 23, 2013 3:27 PM
To: Boyle, Stephen V.
Subject: CVE ID Syntax change - Round two vote results and comments

 

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.


Page Last Updated or Reviewed: October 03, 2014