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

From: <[email-masked]>
Date: Wed, 2 May 2012 09:55:40 -0400

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

---

From: Brian Trammell <[email-masked]>
Date: Wed, 9 May 2012 16:00:36 +0200

hi, Kathleen,

Thanks for your comments! I've incorporated these into the -04 working revision, which I'll submit shortly. Comments/questions inline.

> 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…

I've added a note (as with one on types, as per Sean's comments) that the list is current but may change in the future, check documents that update 5070.

> 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…

Couple of issues here that I can see, that follow from how the IODEF extension mechanism works.

1. IODEF basically defines the contents of an extension attribute, AdditionalData, and RecordItem to be free-form; so there's nowhere in IODEF to note a specific extension is in use, other than in the inclusion of schemas/namespaces in the XML document itself.

2. Since IODEF extensions need to use extension attributes and AdditionalData/RecordItem, pulling them into a new IODEF schema version, at which point I presume we'd want to take them out of AdditionalData and incorporate them as "first class members" of the document (whether by joining the enumeration or being directly contained without an AdditionalData in the way) would cause them to be non-interoperable with previous versions of IODEF. 

Not sure what the solution to these is, but I think the right place to address them is probably in any update to IODEF itself, not in the template.

Best regards,

Brian (author hat)

---

From: <[email-masked]>
Date: Wed, 9 May 2012 16:58:38 -0400

Hi Brian,

Thank you, the updated document looks good.  I do agree that the questions should be handled in an updated version of RCF5070.  Being able to add enumerations to existing attributes via a table could be very useful, but should be handled separately.  We should add this to Rosella's list for discussion on the mailing list to see what people think.

Thank you,
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2012 10:01 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: WGLC: Review of draft-ietf-mile-template-03

hi, Kathleen,

Best regards,

Brian (author hat)