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

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 19 Apr 2017 17:34:17 +0000

For completeness, below is Adam’s review shared offline. We are planning to fix all his comments in the final iteration.

~~~~~~
Hi All,

Here's my review. The draft is generally well written and sufficiently organized. While I have not implemented IODEF, upon reading the draft I felt as though there was enough information there to give appropriate, but not overly-prescriptive guidance to an implementer.

I also found some language improvements/nits. Some are stylistic and may have already been raised, so please take them only as suggestions. Generally speaking, the draft seems ready to me.

Abstract: Second to last sentence seems incomplete. Should the end of that sentence read: "...and use-cases of how IODEF is being used." (Adding "used").

Page 3: First full paragraph, second sentence. Proposed text: "...IODEF implementers to decide dwhich are important."

Page 3: First full paragraph, fourth sentence: Proposed text: "...in rare circumstances."

Page 4: Second paragraph of Section 3.2, first sentence. Strike "has", so that it reads "...if we have DDos as...".

Page 5: First full paragraph. Proposed text: "...IndicatorData class and its included classes..." Or whatever makes sense.

Page 5: First paragraph of section 3.3, last sentence... Strike the 's' at the end of "fulfills"

Page 5: Third paragraph of section 3.3, first sentence. Proposed text: "...Method, and RecoveryTime..."

Page 6: First paragraph, section 4.1, second to last sentence. Proposed text: "...representations into an IANA registry."

Page 6: First paragraph, section 4.2, third sentence. Proposed text: "Additional classes..."

Page 6: Third paragraph, section 4.2. Proposed text: "...or importing them in an IODEF document..."

Page 6: Last sentence on that page of section 4.3. Proposed text: "...in order to form a group of indicators that..."

Page 7: Last sentence of first (partial) paragraph. Proposed text: "...grouping more than one indicator or observable."

Page 9: Paragraph after step 5. I think DDoS had already been defined, so you could remove "Distributed Denial of Service"

That's it.
Kind regards,
Adam
~~~~~~

From: mile [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:29 PM
To: [email-masked]
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

---

From: Adam Montville <[email-masked]>
Date: Wed, 19 Apr 2017 18:27:07 +0000

Thanks for forwarding this on. I had not intended to comment off-list.

Kind regards,

Adam

On Wed, Apr 19, 2017 at 12:34 PM Panos Kampanakis (pkampana) <
[email-masked]> wrote:

> For completeness, below is Adam’s review shared offline. We are planning
> to fix all his comments in the final iteration.
>
>
>
> ~~~~~~
>
> Hi All,
>
>
>
> Here's my review. The draft is generally well written and sufficiently
> organized. While I have not implemented IODEF, upon reading the draft I
> felt as though there was enough information there to give appropriate, but
> not overly-prescriptive guidance to an implementer.
>
>
>
> I also found some language improvements/nits. Some are stylistic and may
> have already been raised, so please take them only as suggestions.
> Generally speaking, the draft seems ready to me.
>
>
>
> Abstract: Second to last sentence seems incomplete. Should the end of that
> sentence read: "...and use-cases of how IODEF is being used." (Adding
> "used").
>
>
>
> Page 3: First full paragraph, second sentence. Proposed text: "...IODEF
> implementers to decide dwhich are important."
>
>
>
> Page 4: Second paragraph of Section 3.2, first sentence. Strike "has", so
> that it reads "...if we have DDos as...".
>
>
>
> Page 5: First full paragraph. Proposed text: "...IndicatorData class and
> its included classes..." Or whatever makes sense.
>
>
>
> Page 6: First paragraph, section 4.1, second to last sentence. Proposed
> text: "...representations into an IANA registry."
>
>
>
> Page 6: Last sentence on that page of section 4.3. Proposed text: "...in
> order to form a group of indicators that..."
>
>
>
> Page 7: Last sentence of first (partial) paragraph. Proposed text:
> "...grouping more than one indicator or observable."
>
>
>
> Page 9: Paragraph after step 5. I think DDoS had already been defined, so
> you could remove "Distributed Denial of Service"
>
>
>
> That's it.
>
> Kind regards,
>
> Adam
>
> ~~~~~~
>
>
>
>
>
> *From:* mile [mailto:[email-masked]] *On Behalf Of *Nancy
> Cam-Winget (ncamwing)
> *Sent:* Tuesday, March 28, 2017 7:29 PM
> *To:* [email-masked]
> *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
>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 19 Apr 2017 19:14:28 +0000

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

Colleagues,

Regards, Nancy