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

帕斯卡,无论新选项,我们不打算重编号的老id——这将是破坏性的。所以预计将是一个“语法1.0版”(2013年和前)和“语法2.0”(2014年之后)。这个话题不涉及太深,然而,当我们计划详细介绍过渡策略选择后一个选项。——史蒂夫。> - - - - - - - - - - - >从原始信息: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. >>