History serves up lessons that if you ignore them, you are asking for problems. When we started CVE in 1999 we felt there was no way it was possible to get to 10,000 CVEs a year. That was the consensus then of all involved. Fast forward a decade and we had run into the problem. Today we are in a position where we have to correct the problem/situation we once thought inconceivable. Do we really want to be shortsighted and ignore what we have actively seen occur to us in the past? Absurd it is not, conservative, yes.
As a vendor that has to deal with this across many different product lines, many different research and development databases across differing security technologies, we really do not want to find ourselves in this situation again. This type of effort, changing a format that is so integral to all we do, is not free. The level of QA needed is staggering. Each and every one of those areas, be it a customer product or internal development or research resources has to be verified that it will not have an issue with the format change. This is not like having one database, this is very extensive and the costs to make this change and validate it will be too.
As for the limitations of MITRE, in the earlier days not all that long ago, they would not have thought they could handle the level of vulnerabilities they are today. Things change and evolve and their ability to so will as well if there is a need. The CVE format changes should not be viewed by today's limitations of the implementation of the CVE team. We are not trying to address today's issues as much as we are the future issues. And there are other pressures on the CVE effort as well with the global vulnerability identification work that is just starting. I am not linking the two today but I am also not going to vote to put us in a situation where that will not be possible if that is what is decided.
Sorry but I politely disagree with your opinion based on today's reality. This impacts the community as a whole. This change will cause problems in areas we have no idea of today. Unexpected consequences is also historically relevant here. I want CVE positioned for the future moving forward and I do not what to be here again. It is too expensive and too disruptive and does little to assist the image and adoption of the CVE. Let's not be shortsighted and do what's the right thing for the future of CVE.
From: security curmudgeon <email@example.com>
Date: Thursday, April 18, 2013 11:43 AM
To: Kent Landfield <Kent_Landfield@McAfee.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Re: CVE ID Syntax Vote - results and next steps