Managed Incident Lightweight Exchange (MILE) Working Group Meeting
IETF 82
Date: November 16, 2011
Location: Taipei, Taiwan
WG Chairs: Kathleen Moriarty and Brian Trammell

Note well explained.

Agenda Review/Bashing
Background provided by Brian  as WG co-chair on INCH and why we are here to extend IODEF, RID.  Charter exists and we moved to a working group about 2 weeks ago.

Other documents need to go to list for inclusion in the WG.

•	Need a draft for IODEF-guidance.  Supposed to go to last call in March of 2012, a bit aggressive.
•	RFC6045-bis and RFC6046-bis will be updated to reflect working group name.
•	Template document supposed to go to last call next month and IANA draft.
•	Take’s Cybersecurity information document is intended to go to last call in December
•	Data marker draft needs to be updated, not ready yet to generate discussion needed to determine if the draft will be adopted by the working group
•	Forensics draft also has editors, but not posted yet.


Presentation on “IODEF Extension to Support Structured Cybersecurity Information” by Takeshi Takahashi: 
https://datatracker.ietf.org/doc/draft-takahashi-mile-sci/

Overview of draft and then outstanding issues
Extension to IODEF to enable adding structured cyber security information to embed relevant information on an incident (attack pattern, vulnerability, weakness, event record, PlatformID, Score, Verification, Remediation).  We already have XML specifications that support these types of structured information and are using them in this extension.

Slide 4, table for IANA, future proof and would like it maintained by the IANA registry.   Reviewed some of the standards in the slide (CVE, etc.)

Three outstanding issues:
1.  Applicable specifications for each class:
Want to limit applicability of the included specifications.  Example: Specifications can only be used for a specified purpose, CVE only used for vulnerability, CAEPEC on Attack patterns.
Chris Inacio: OCIL is used as an interface to ask about OVAL queries and is probably not that useful for IODEF.  If user interaction is necessary, than it may makes sense.  OVAL is used to assess the state, designed to be pretty automated and don’t need interaction, when you need to ask the user something, you use OCIL to complete that request.  Is that what we want to exchange?
Take: Thinks we want to include it because user scenario may be needed.
Paul Hoffman: If things are needed for immediate user interaction, we should think seriously if we want to include them.  Maybe sent to an audit function, fooled him when he was first reading it.  There can be interactive mode, so we need to call out that they should not be used when documents are automated and batched.
Jabber (Kent Landfield): OCIL results of previous queries may need to be used and passed upstream, so this should be included.

2. Guideline for the IANA Expert Review
We are using an IANA table and need an expert review for this.  This is Take’s understanding of what people want.
David Black offered to work offline to help get this right
Expert review are needed for what specifications make sense and what don’t
For an expert review does there has to be a public spec available for the process?
It was stated that it is a high bar to waiting for 3 implementations before we get to expert review.  David Black, Sean Turner both stated that 2 is the typical for the IETF and 3 is too high.

Kent on list said make sure any spec included in this extension to IODEF is useful to this community

(Expert review Guideline discussion) Sean Turner: IANA – can just pick an expert reviewer.  The reviewer can ask for guidance.  Not clear on whether or not a guidance document is needed for this review process.  David Black: What should the editor look for in a good specification for this.  Sean: no guidelines provided in IPSec, 
Brian Trammell: IPFix does have a process getting formalized.  End result: When the expert does need help, help them.  Let the reviewer figure out where the issues exist to determine guidance when needed.


3. Verification Remediation Class
Name seems to be confusing.  Would like both verification and remediation classes, no objections stated.
Jabber: this change makes it more clear

Brian Trammell (As contributor): IODEF-XMLReg draft 
Discussion between Brian and David Black on list
Want a new boiler plate item that says any schema that says IODEF-, gets the IODEF- expert review.
Proposal to combine this document with the template for extensions.  Both are relevant to IODEF extensions.  Issue is template is informational and the registry is intended standards track.  If the IODEF extension template went to standards track and added this text into the IANA section, the problem is addressed.
David Black: Template can be an informative annex
Sean Turner is OK with the approach.
	A new draft will be posted to reflect the WG agreement.
Hum: Yes, approved as a WG item



Kathleen Moriarty (As contributor): GRC Report Exchange
Called for additional editors on document
Who wants this: Legal XML (LI-XML)/OASIS, GRC-XML (risk), and ITU-T communities
Draft prompted by a need for a common method of information interchange; This is a generalization of RID, RFC6045-bis for the secure exchange of XML schema documents.  Simple now, needs a lot of review to ensure use cases from target communities are sufficiently addressed.
Three basic classes, but we want to determine with the WG what the right approach is: GRCPolicy, RequestStatus, ReportSchema
https://datatracker.ietf.org/doc/draft-moriarty-mile-grc-exchange/

Hum: Was weak, Brian wants to take this to the list to see if people are interested in adopting this draft to meet the charter for a generalized version of RID.



The draft on Data Markers is not complete enough to discuss, we will wait for an update to decide if it will be adopted.



Alessandro Vesely (provided slides, was remote): MARF extension to IODEF: 
http://tools.ietf.org/html/draft-vesely-mile-mail-abuse-00

Slides were provided and should be referenced.  Kathleen, Brian & notes from Allesandro via jabber used to provide an overview.

Individual submission – marf extension to iodef iodef (Mail abuse incidents use case).  This extension would provide an alternative method to share incident information on mail abuse to the one provided by MARF.  Using email to report email abuse may be problematic, therefore having a method to send a report via IODEF and RID could be helpful.  This method supports anonymous reporting and also allows all incidents to be centralized for processing and tracking or connecting to other incidents, etc.

People who are interested should collaborate with Alessandro on the personal draft; please discuss on the mile list so interest and support can be gauged.
Paul Hoffman: sometimes people hit the spam button so often they are blocked, you may have received this not through email, but want it counted for statistical reasons.  Could participate without having to identify yourself.  It is great for what IODEF is trying to do.
Use case: ISP can send messages to their clients using IODEF.

The first slide is the current working version and how you translate from ARF representation to the IODEF extension.  See slide and draft for details.

Note: Many remote participants were connected via jabber and Meetecho.

Working group meeting was concluded.

Please continue to post comments to all documents on the MILE mailing list.  

Thank you!
Kathleen