Re: [mile] Working Group Last Call for IODEF Guidance

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Chris:  you had also volunteered to review the draft.  Can you let us know if you have any comments on the latest revision?  Would like to conclude the WGLC as the deadline was May 1st ☺

Meanwhile, thanks to Adam and Roman for providing your comments!

                Nancy

From: mile <[e-mail]> on behalf of Panos Kampanakis <[e-mail]>
Date: Thursday, May 11, 2017 at 6:26 AM
To: Roman Danyliw <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mile] Working Group Last Call for IODEF Guidance

Thank you for all the comments Roman.

We made all the changes you suggested and expanded some of the text that were not clear. The new version will be posted soon.


The only objection I had was on your comment (3). The xml:lang attribute in the iodef document is optional in the text in https://tools.ietf.org/html/rfc7970#section-3.1 but I see that in the XML schema it is not optional. Hmm, maybe this should be errata for RFC7090?

Panos



From: mile [mailto:[e-mail]] On Behalf Of Roman Danyliw
Sent: Wednesday, April 19, 2017 3:14 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [mile] Working Group Last Call for IODEF Guidance

Hello!

Here are a few suggestions from reviewing draft-ietf-mile-iodef-guidance-09.

(1) Results of XML validation on all XML examples and snippets:
** The second xml snippet in Appendix A is missing the HashData@scope attribute.  Replace both instances of '<HashData>' with '<HashData scope="file-contents">'.
** All the examples in Appendix B #1 - 5 are valid XML

(2) The abstract notes IODEF v2 [RFC7970]; but Section 2 and 6 note [RFC5070] and [RFC7970].  This raised confusion for me on which version of IODEF this draft is providing implementation guidance?  The provided examples and Section 3.1 are [RFC7970] specific.

(3) Section 3.1.  This write-up is a bit imprecise.  The parent IODEF-Document technically needs an Incident class (as noted), a version attributed (as noted), but also an xml:lang attributed (not referenced).

(4) Section 3.3, page 5, "An IndicatorData class depicts a threat indicator ... to describe ... that an exploit happened".  I'd recommend replacing 'exploit' with a 'successful attack'.  IndicatorData is shared as a watch-and-warning product for an event that did occur or not.  The use of an exploit doesn't seem material.

(5) Section 4, page 6, The sentence "When defining the IODEF use strategy practitioners need to ..." doesn't parse.  Perhaps, "IODEF implementers need to ..."

(6) Section 4.1, page 6.  I don't understand the recommendation made by the sentence, "Practitioners SHOULD only support external enumerations that are expected to be used in IODEF documents for their use-cases."

(7) Section 4.1, page 6. I'd recommend updating the sentence 'The Enumeration Reference Format specifies a format to ..." with 'The Enumeration Reference Format specifies a means to use external enumeration specifications that could define an enumeration format, specific enumeration values, or both".

(8) Section 4.2, page 6.  I'd recommend updating the sentence "Many class attributes and their values can be extended using the "ext-*" prefix." to "Many attributes with enumerated values can be extended using ...".

(9) Section 4.4, page 7. Include a reference to RFC6545 and expand the acronym RID given that this is the first reference to RID in the document.

(10) Section 4.4, page 7.  I'd recommend updating the sentence "The enforcement of the disclosure guidelines goes beyond IODEF." with "The enforcement of the disclosure guidelines is out of scope for IODEF".

(11) Section 5.1, page 7. and Section 5.3, page 11, s/CERT/Computer Security Incident Response Teams/.

(12) Section 5.2, page 8.  The opening sentence, "Various vendors organized and executed an exercise where multiple threat indicators were exchanged using IODEF" left me wanting a deeper explanation of the background on this section.  What exercise?  what vendors?  When?  Is this section an implementation report?

(12) Section 5.2, page 8.  I'm confused by the intent of this section.  It reads like an implementation report more suitable for draft-ietf-mile-implementreport-10.

(13) Section 5.2, page 8. Typo.  I'd recommend updating the text "The threat information shared included incidents like DDoS attacks.  Malware and Spear-Phishing" to read as follows: "The threat information shared included indicators from DDoS attacks; and Malware and Spear-Phishing incidents".

(14) Section 5.3, page 11.  I'm confused by the title of this section.  "*More* use cases".  The 'more' suggests that other use cases were explicitly enumerated elsewhere.

(15) Section 5.3, page 11.  Additional use cases could include “Satisfying regulatory or statutory requirements for incident reporting”

(16) Globally.  Replace "practitioners' with 'implementers'.

Roman

From: mile [mailto:[e-mail]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:29 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [mile] Working Group Last Call for IODEF Guidance

Colleagues,

We are doing another WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-mile-iodef-guidance

Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Regards, Nancy