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

谢谢史蒂夫,这是我最重大的改变对这个问题的看法。我认为这是可以预料到的过渡策略将影响格式选票,得票最严厉的过渡增加的破坏性更小的(“自私”)选项。不指定他们让人们考虑他们最害怕的人。转型在2015年而不是2014年,如果真实,可以选择一个更接受组织大规模投资。丑陋的但是功能强大的“B计划”将是2015年开始分配id在新格式如果我们在2014年耗尽id。在我看来,没有比开始更丑陋的数在1000和影响的选择格式为了平滑过渡,并有机会不会需要。考虑到这一切所需的属性的列表,我倾向于选择一个或用前导零变异而不是选项B,我投了票。越来越多的数字字符追逐消失减少风险,以换取一个常数增加支付的所有费用。在缺乏追溯应用程序,我不认为格式更改需要这样一个问题,只要他们不过于频繁地发生。选择一个有一个可接受的风险。 Option D (7 characters, as named by Art) should make the most risk averse, comfortable. Pascal On Fri, 19 Apr 2013 09:58:53 -0400 "Christey, Steven M."  wrote: > Pascal, regardless of the new option, we did not plan to renumber any of the > old IDs - that would be too disruptive. So the expectation is that will be a > "syntax version 1.0" (for 2013 and earlier) and a "syntax 2.0" (for 2014 and > later). This topic was not covered too deeply, however, as we had planned to > cover transition strategies in more detail AFTER selection of an option. > > - Steve > > > >-----Original Message----- > >From: owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve -> > editorial-board-list@lists.mitre.org]代表帕斯卡贝> >发送:4月19日,星期五,2013年17点> >:展位,哈罗德> > Cc: cve-editorial-board-list > >主题:Re: CVE ID语法投票结果和下一步> > > >,假设已经发行的cf不会修改符合> > > >新格式。我建议目前的理解是,一旦> > new > >选项将被采纳,发行的所有先前cf将改变> > new > >格式。> > > >在星期四,2013年4月18日22:34:07 -0400 > >“展位,哈罗德”< harold.booth@nist.gov >写道:> > > > >我也添加一个选项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. > >> >