Re: [mile] comments on the draft-ietf-mile-rolie-vuln-00 draft

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Take,

Thank you for the review, I've responded below.


  1.  That is a good idea, thank you. I will make the content id a shared requirement.
  2.  I plan on either releasing an update to this document or creating a new extension on it. I will add a sentence on that in the VDO section.
  3.  Thanks for catching this. I need to add a requirement to use a "rolie:format" element that will point to the CVE XML/JSON Schema. That will identify the entry as a CVE document.
  4.  My intention is that the entry would still have an information-type of "vulnerability" even if you are using plain text VDO. I will clarify this in the document.
  5.  Examples are a good idea. I have examples in the other ROLIE extensions already, I just need to create some for the vulnerability entries.
  6.  The intent is that such a link MUST be supported by the implementation, but it does not need to actually appear in a vulnerability entry. I'll add a sentence clarifying this requirement.
  7.  Generally, if there are new vulnerability formats in the future, it would be possible to simply publish a new document with requirements and guidance for that format. They can reference this document for the information-type.
  8.  Given the current level of requirements in the document, I think it would be best to publish as standards track. However, I'd be willing to talk about it if the chairs/AD have any issues.

Thanks for the editorial comments as well, I've accepted all of your edits.


Thanks again for the review!

Stephen

  1.

________________________________
From: mile <[e-mail]> on behalf of Takeshi Takahashi <[e-mail]>
Sent: Sunday, April 7, 2019 2:41 AM
To: [e-mail]
Subject: [mile] comments on the draft-ietf-mile-rolie-vuln-00 draft


Hi Stephen,



I have read the draft-ietf-mile-rolie-vuln-00 draft and I generally like the draft.

Here are some comments.



  1.  “There must be one rolie:property with the name attribute equal to urn…content-id” seems to be a common requirements for both XML CVE and JSON CVE. Currently, it is written as a XML CVE requirement and as a JSON CVE requirement, but it could be written as a common requirement.
  2.  Regarding VDO, it is not a spec yet. How will you cope with VDO once it becomes a spec (approved by NIST)?
  3.  According to the current text, I could not find any field that indicates that the content is “cve”. By looking at the information-type, we can see the content is a vulnerability information. But we cannot know the content is a cve note or not until we see the content itself. Is my understanding correct? Where can we know that the content is a cve note or not?
  4.  According to the current text, I understood that we will treat a VDO as a plain text at this moment. Then, do we indicate that the content is a vulnerability information or not? It seems to be that we do not indicate so according to the current text. Is that so?
  5.  Section 4 is concisely represented. I like it. However, having some examples will help readers to understand the content properly. How about adding some examples in its appendix or in this section?
  6.  According to section5.1, we MUST send a severity information when sending a vulnerability note. That means, we cannot send an early vulnerability information without a score, correct? Just a clarification.
  7.  I guess you will make this vulnerability rolie extensible enough. Can you add some sentences how we could cope with the other vulnerability notes that may emerge in the future?
  8.  Is it going to be an informational RFC? It has several definitive parts. So, I am just asking your intention.



Editorial comments are not important at this stage, but it won’t harm to list here.



“support Vulnerability use cases” -> “support vulnerability use cases”.

“a automated and efficient fashion” -> “an automated and efficient fashion”.

“a XML” -> “an XML”

In the reference, vdo cannot be a normative reference at this moment, due to its document status.



Thank you, and kind regards,

Take