RE: Candidate numbering scheme
I would agree, the shorter number scheme definatly makes readability
> -----Original Message-----
> From: Adam Shostack [SMTP:firstname.lastname@example.org]
> Sent: Friday, May 14, 1999 7:29 AM
> To: Bill Hill; email@example.com
> Subject: Re: Candidate numbering scheme
> I agree with Dave that shorter numbers are more usable by people.
> I'll also agree with Bill that if we have substantial discussion of a
> candidate, we can point to it in the references. I think we should
> move ahead to working with some of the CVE sub-lists, either the easy
> or the hard ones, to get closer to release.
> On Fri, May 14, 1999 at 08:32:25AM -0400, Bill Hill wrote:
> | I agree with Steve's points.
> | I've been an advocate of minimalism where the core CVE is concerned, but
> | I can see a lot of value in being able to map between candidate
> | info/threads/etc. and the CVE. It seems to me (for all the reasons that
> | Steve mentioned) that the proposed candidate numbering system still
> | requires that the CVE maintain references to candidate numbers in some
> | cases.
> | I suggest adding this information as an explicit reference(s). Not sure
> | if this would mean something in the CMEX, or the CVE proper.
> | I strongly suggest keeping this or any kind of data out of the CVE
> | number itself. During our many design discussions we've been tempted to
> | put "stuff" in there, and we've always found it introduces unwanted
> | complications, inconsistencies, etc. We've always (at least so far :-)
> | found better ways of handling the problem, and I think our focus on
> | keeping the CVE number and data simple and "pure" has helped make as
> | much progress as we have already, and will help us really push forward.
> | Of course, this is all IMHO :-)
> | Bill
> | "Steven M. Christey" wrote:
> | <SNIP>
> | >
> | > There is a third problem which I believe is the most significant.
> | > Multiple candidates will be proposed that wind up being part of the
> | > same CVE vulnerability (let's say they are duplicates, or they're both
> | > subsumed by them), or split into multiple CVE vulnerabilities. There
> | > won't be a one-to-one relationship between the candidate number and
> | > the CVE number, so the CAN- portion will be different than the CVE-
> | > portion. This would require a "lookup" capability to go from the
> | > candidate number to the real associated number. I.e., we would
> | > *still* have to maintain a mapping from candidate numbers to the CVE
> | > numbers.
> | >
> | > None of these problems is significant if the candidate number is never
> | > really public, and only for use within the Input Forum. They might be
> | > relatively minor compared with some of the benefits, e.g. "early
> | > tracking" of new vulnerability information, and allowing Input Forum
> | > members (e.g. vendors) to use candidate numbers in advisories that
> | > they post for new vulnerabilities.
> | >
> | > The question is: how important is it to the members of this group that
> | > we should have such "external candidate numbers"? Russ' perspective
> | > is clear since he is concerned with numbering vulnerabilities as early
> | > as possible, and I believe Andre would agree since he expressed
> | > concerns with getting numbers for advisories for new vulnerabilities.
> | > A second question is: assuming we have external candidate numbers, do
> | > they *have* to be the same as the CVE number? To reduce confusion,
> | > sure, but there won't always be a one-to-one relationship as I
> | > indicated earlier.
> | >
> | > I think that such a radical change to the CVE name requires a decision
> | > before release. Any commitments we make to a numbering scheme will
> | > have to be adhered to once the CVE is public.
> | >
> | > - Steve
> | --
> | ----------------------------------------------------------------------
> | William Hill V:703-883-6416
> | INFOSEC Engineer F:703-883-1397
> | The MITRE Corporation firstname.lastname@example.org
> | 1820 Dolley Madison Blvd. M/S W422 email@example.com
> | McLean, VA 22102-3481