Subject: [mile] review of draft-ietf-mile-template-00

From: <[email-masked]>
Date: Wed, 15 Feb 2012 17:08:05 -0500

Hi Brian,

The document looks like it is close, I have some editorial recommendations:

Title:  Since the extensions can apply to IODEF or a lightweight IODEF yet-to-be defined, the title and abstract should reflect that capability.  The title and abstract read as if IODEF is lightweight and the extensions will be lightweight, which is not necessarily the case.

The WG has not begun work on the charter objective to provide IODEF guidance for making IODEF lightweight or deciding what that means.  The template extension should apply to both use cases as IODEF could be big complex documents right now (and later where appropriate) or lightweight with the current model or through the guidance or a reduced schema.  As such, removing references to MILE would be helpful as the WG name will go away at some point in time and we will be left with draft and specification names.

Introduction: Can you reword the first sentence?  It is very long and a little tough to follow.  Is it accurate?  I think we are defining IODEF guidance somewhere else?

2nd paragraph, recommend rewording the first sentence from:
"Additionally, IODEF extensions via class extension through
   AdditionalData and RecordItem elements, a"

TO: "Additionally, IODEF extensions through the
   AdditionalData and RecordItem elements nested in the extensible IODEF classes, a"

Section 2, #2, last line:
Recommend changing from:
"then extension is not necessary."
T: "then the extension is not necessary."

The next line, the word includes should be include (refers to a single list).
"A non-exhaustive list of good candidate extensions to IODEF includes:"

#1 in the list, can you reword this and possibly make it two sentences?  I think it would be easier to read.

Security considerations:
I don't think you need MILE in this description.  The extensions are to IODEF and then to a lightweight version of IODEF that may be another specification or a guidance document, but we have not done that yet.

A.4: References MILE extension documents, this should reference IODEF extension documents.

A.6:  I think this should match IODEF's security considerations as these concerns described are addressed in the transport documents.  IODEF also points out that the formats are for exchanges and not storage.  Storage security considerations about the data inside the formats should be out-of-scope.  If extension authors try to cover that content, they won't be able to get right as the tools used for storage will be different and implementers should refer to the appropriate specifications.

Thank you!
Kathleen

---

From: Brian Trammell <[email-masked]>
Date: Thu, 16 Feb 2012 09:59:30 +0100

Hi, Kathleen,

Thanks for the review. I've incorporated all of these into -01; specific comments thereon inline.

As WGLC is closed, I will post the -01 revision shortly.

> Introduction: Can you reword the first sentence?  It is very long and a little tough to follow.  Is it accurate?  I think we are defining IODEF guidance somewhere else?

Split in three; now:

     In the five years since the specification of IODEF 
     [RFC5070], the threat environment has evolved, as has
     the practice of cooperative network defense. These trends, along with
     experience gained through implementation and deployment, have indicated the
     need to extend IODEF. This document provides guidelines for defining these 
     extensions...

> #1 in the list, can you reword this and possibly make it two sentences?  I think it would be easier to read.

These are aspects of the same concept. I've shuffled it a bit, though:

  1. Leveraging existing work in describing aspects of incidents 
     to make IODEF more expressive, by standardized reference to 
     external information bases about incidents and incident-related
     information

> A.4: References MILE extension documents, this should reference IODEF extension documents.

Good point. Indeed, I've also changed the footer title to "IODEF extension guidelines".

> A.6:  I think this should match IODEF's security considerations as these concerns described are addressed in the transport documents.  IODEF also points out that the formats are for exchanges and n…

I've referenced security considerations on 5070 already on a previous comment; I'll also remove the reference to storage.

Best regards,

Brian (author hat)