RE: CVE ID语法投票,结果和下一步

我也添加一个选项B没有前导零,包括各种各样的过渡少于四位数,第一年是可用的(或更多)如果CVE标识符开始在1000年。直到9000个CVE工具成功一步步前进给大家更多的过渡时间。这将允许更多的时间取决于cf的最终数量。而选择与填充没有这样的转变,和任何数量的数字同意都包含在每个CVE从一开始(在2014年)。问候,哈罗德- - - - - - - - - - -从原始信息:owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve-editorial-board-list@lists.mitre.org]代表安全乖戾的人发送:周四,4月18日,2013下午6:05:Kent_Landfield@McAfee.com Cc: cve-editorial-board-list@lists.mitre.org主题:Re: CVE ID语法投票结果和下一步的重要性:高在星期四,2013年4月18日,Kent_Landfield@McAfee.com写道::同意。::我可以看到改变投票如果数字的位数扩展。我回答说,我认为哈罗德是在目标与他的想法:评估选择a。正如前面提到的,这是对我好。#我没有投票的数字在我投票标准方法用于显示它。可选,如果选择B是重做删除所有零之后,与我也会没事的,因为它将承担一个标准的显示格式(各种各样的)。:哈罗德写道:::我同意重新使用相同的选择可能会导致:或多或少相同的结果。但在审查理由:投票,那些投票支持选项B大多关心:避免再次需要改变(“未来防”),而那些:投票给选项似乎主要关心变量如果都改变正如上面提到的,一个是7位数,而6,和B没有前导零。我真的好奇的人们会如何投票。:使用他的逻辑,我们可以让它领先10 +数字,不垫:0。然后将被限制在一个静态的长度,但我们只会:必须使用我们所需要的东西。 It could grow as needed and we would have the : future proofing that is a major reason stated by those who voted for : Options B. The end user would see a CVE ID that is reasonable from a : readability perspective, software would have a static length that we can : grow into. An approach like this could potentially go a long way to : getting to a consensus majority. : : Thoughts? Overall I like it. We're addressing the problems with the proposed solutions, and building on them, rather than coming up with additional. It would be great if every member would weigh in on the above, not as an official vote, but just to see if either has more benefit, or to add other options and ideas.