回复：CVE ID语法投票 - 结果和下一步

假设已经发行的CVE不会进行修订以符合新格式。到目前为止，我对提案的理解是，一旦采用新选项，所有先前发行的CVE都将更改为新格式。2013年4月18日在星期四，22:34:07 -0400“ Booth，Harold” 写道：>我还将在没有领先零的选项B中添加，包括少于四位数，如果CVE标识符从1000开始，则第一年（或更多）可以进行各种过渡。直到第9000届CVE工具将成功>成功地为每个人提供更多的过渡时间。根据最终创建的CVE数量，这可能会允许更多的时间。>虽然有一个带有填充的选项A没有这样的过渡，并且>从>“开始”（2014年？）中，每个CVE都包含了任何数量的数字数字。>>问候，>>  - >  -  harold >> ------原始消息----->来自：所有者 -  cve-editorial-editorial-board-list@lists.mitre.org> [[mailto：所有者cve-editorial-board-list@lists.mitre.org]代表安全> curmudgeon发送：2013年4月18日，星期四下午6:05至：> kent_landfield@mcafee.com cc：cve-editorial-board-list@lists@lists.mitre.mitre.org>主题：re：re：cve ID Syntax投票 - 结果和下一步>重要性：高>>在2013年4月18日，kent_landfield@mcafee.com上写：>>：同意。>：>：我可以看到如果数字的数量延长了，我可以将投票更改为a。>：我回答说，我相信哈罗德（Harold）的想法是：>：重新评估选项A。>>如前所述，这对我来说很好。我没有在> A中投票赞成数字＃。>>选项，如果重做选项B以删除所有尾随的零，那对我来说也很好，因为它将带有标准的显示格式（>“> s”）。>>：Harold写道：>：>：我同意使用相同选项的revote可能会导致>：或多或少相同的结果。但是，在审查了>：投票的推理之后，那些投票选项B的人主要关注>：避免需要再次进行更改（“未来证明”），而那些>：投票选择选项的人似乎主要关注变量>>如果两者都如上所述更改，其中A为6个数字为6，>和B根本没有领先的零。我真的很好奇人们如何投票。 > > : Using his logic, we could make it 10+ digits and not pad it with leading > : zeros. Then it would be capped at a static length but we would only > : have to use what we need. 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. >