[mile] WGLC: Review of draft-ietf-mile-template-03

[<[e-mail]>]

Hi Brian & MILE members,

Thank you very much for setting up the template, I think this has been and will continue to be helpful to draft editors and implementers!

I have a few comments on the draft.  If others on the list have comments, please chime in TODAY as the WGLC is supposed to end.  THANK YOU!



Section 2:
In #1, it is not entirely clear that IODEF can represent incomplete information about an incident.  The terms used these days are indicators and observables.  It is not necessary to use those terms, but leaving this open to use cases covered in IODEF and RID where we are just sharing information that could help prevent an attack after that was detected at another site is useful.  Having some way to include this could be important for people to understand the full set of use cases for IODEF.  The IODEF and RID RFCs have examples and text descriptions (sharing reduced information sets), like the watch-lists to demonstrate this.

Bulleted section:
Can you extend the non-exhaustive list to include representing information about incidents that are not covered by the base IODEF specification?  We want to leave this open for extensions like the anti-phishing where indicator information is represented in the extension.  The information might not be in another schema or about an entity, so I don't want people to get confused.

Bottom of Page 4: Typo:
RecordPattern@type>,
Should be:
RecordPattern@type,

This list does not include "restriction'.  I know it is not currently listed as one that can be extended, but I suspect that may change in and RFC5070-bis from comments I have heard on difficulties with the limited set... or it may get solved with an extension that enables additional ways to mark data.  I am not sure there is a way to do this, but if we added something that said updated versions of IODEF may change this list so that folks not as familiar with following references to the updates and then understanding that the change is possible with new versions of IODEF.

The end of section 3 talks about the use of formatid, I think we should explore that on list a bit more, separate from this document.  It should probably be in the context of updated IODEF guidance as a table or way to register formatids could be very helpful since they are 'negotiated out-of-band' per RFC5070, but could be really useful to reduce context in exchanges.

Appendix: A2: Do you want to reference the requirements for IODEF RFC?  It is informational, but could be helpful.  RFC3067

Appendix B:  How do we get new enumerated Type extensions and new attribute values into the schema?  Do we also need a table where these get added so that they can be included in the current schema version, then where there are updates, if they have been useful, we pull them into the new IODEF schema version?  We may need to set that up here?  Any thoughts? Or is this handled some other way?  I had a table created for RID to serve this purpose.  DO we want to do the same thing here?  Sorry I didn't catch it sooner.

Appendix C:  Suggest changing the last sentence of the second paragraph to cover incomplete incident information when you are exchanging indicator information via IODEF:
From: "If a Test element is present, it
   indicates that an IODEF Document contains test data, not a reference
   to a real incident."
To: "If a Test element is present, it
   indicates that an IODEF Document contains test data, not a reference or information
   about a real incident."

Appendix C: The test marker is interesting and could be useful, we may want to talk about that more with a revision of IODEF to see if people want to see something like that added since this is just an example.

Thank you for all of your hard work on these documents!

Best regards,
Kathleen