Subject: [mile] Updated presentation from Side meeting

From: <[email-masked]>
Date: Wed, 27 Jul 2011 09:34:17 -0400

Hello,

Thank you to those of you that were able to attend or dial into the MILE Side meeting on Monday night.  During the meeting, we provided an overview of prior work and discussed the planned direction for future work, specifically:
  o  the extension template (review provided by Brian), 
  o  the list of extensions in which interest in development was expressed, and 
  o  the generalization of RID for use outside of the incident space.

Dr. Katherine Goodier also presented on further research into the data markings and privacy options for IODEF/RID as a result of work she has done in coordination with NATO and others.  The presentation was sent to the list and is a very nice review of the considerations for privacy in this space, where regulations from over a hundred countries were considered.  Please take a look at her slides and provide comments/questions to the list if you have any.  Katherine and Guas will be working to develop a draft in this space to the list with the goal of having it out well in advance of the next meeting so that review can occur on the mailing list.

FYI - Although the IETF has 3 meetings a year, most of the work is done on the mailing list, so your participation on this list is appreciated and helps significantly with the progress of this work.  Others who have volunteered to work on extensions are encouraged to use the template provided to begin development of their draft documents as soon as possible to allow time for the mailing list to contribute thoughts to improve the extensions.  The mailing list review will help to ensure the community agrees on new extensions to increase their usefulness.

The attached is an updated version of the overview presentation previously sent to the list per some comments I received.

Thank you and best regards,
Kathleen

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 28 Jul 2011 07:18:03 -0400

Hi Kathleen,

Sorry I missed the meetings Monday.

I am very interested in working on extensions to IODEF for standardized 
names and descriptive information about the ICT items involved in an 
incident.

My first thoughts on an overall list for these are:

the CPE(s) involved - what was attacked/leveraged in the incident
the CVE(s) used, or the CWE(s) used - what holes/entry points were used
the CVSS/CWSS score(s) of the CVE(s)/CWE(s) - not sure if this helps?
the CAPEC(s) used in the incident,
the OVAL definition(s) for indicating a system that could be compromised 
in the same way as those in the incident,
the OVAL definition(s) for identifying systems that have been
compromised by the incident.

Eventually maybe the MAEC patterns and the the CEE events can be added 
too, but I don't think those types of information are ready for that yet.

Any thoughts from others?

Bob Martin
MITRE Corporation
Making Security Measurable
http://msm.mitre.org/

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 28 Jul 2011 10:56:30 -0400

So, maybe we could extend the IODEF as described in Figure 1 of the attached
txt file. (correct me if I'm wrong)

We could define Incident.EventData.AdditionalData elements and describe them
by using CPE, CVE/CWE, CVSS/CWSS, and CAPEC.
Regarding OVAL, we might define Incident.AdditionalData element, but I am
not sure at this moment, thus is not described in the figure yet.

I would like to tackle CAPEC first since I believe Kent would like to tackle
CVE and CAPEC.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin, Robert A.
Sent: Thursday, July 28, 2011 8:18 AM
To: [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

Hi Kathleen,

the CPE(s) involved - what was attacked/leveraged in the incident the CVE(s)
used, or the CWE(s) used - what holes/entry points were used the CVSS/CWSS
score(s) of the CVE(s)/CWE(s) - not sure if this helps?
the CAPEC(s) used in the incident,
the OVAL definition(s) for indicating a system that could be compromised in
the same way as those in the incident, the OVAL definition(s) for
identifying systems that have been compromised by the incident.

Eventually maybe the MAEC patterns and the the CEE events can be added too,
but I don't think those types of information are ready for that yet.

Bob Martin
MITRE Corporation

On 7/27/11 9:34 AM, [email-masked] wrote:
> Hello,
>
> Thank you to those of you that were able to attend or dial into the MILE
Side meeting on Monday night.  During the meeting, we provided an overview
of prior work and discussed the planned direction for future work,
specifically:
> Dr. Katherine Goodier also presented on further research into the data
markings and privacy options for IODEF/RID as a result of work she has done
in coordination with NATO and others.  The presentation was sent to the list
and is a very nice review of the considerations for privacy in this space,
where regulations from over a hundred countries were considered.  Please
take a look at her slides and provide comments/questions to the list if you
have any.  Katherine and Guas will be working to develop a draft in this
space to the list with the goal of having it out well in advance of the next
meeting so that review can occur on the mailing list.
>
> FYI - Although the IETF has 3 meetings a year, most of the work is done on
the mailing list, so your participation on this list is appreciated and
helps significantly with the progress of this work.  Others who have
volunteered to work on extensions are encouraged to use the template
provided to begin development of their draft documents as soon as possible
to allow time for the mailing list to contribute thoughts to improve the
extensions.  The mailing list review will help to ensure the community
agrees on new extensions to increase their usefulness.
>
> The attached is an updated version of the overview presentation previously
sent to the list per some comments I received.
> Thank you and best regards,
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Wes Young <[email-masked]>
Date: Thu, 28 Jul 2011 11:08:03 -0400

http://tools.ietf.org/html/rfc5070#section-3.19

i've been sticking other "XML like" records under this (icsg1.1 data, etc...).

pretty easy to do, just generate the "other standards" xml (or json or whatever), embed it there. turns iodef into a sharing platform for other data-types w/o having to extend it too much.

> I would like to tackle CAPEC first since I believe Kent would like to tackle

- --
Wes
claimid.com/wesyoung
[email-masked]

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 28 Jul 2011 11:26:33 -0400

Hi Wes,

Thank you for the comment. I agree and like it.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes
Young
Sent: Thursday, July 28, 2011 12:08 PM
To: [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

i've been sticking other "XML like" records under this (icsg1.1 data,
etc...).

pretty easy to do, just generate the "other standards" xml (or json or
whatever), embed it there. turns iodef into a sharing platform for other
data-types w/o having to extend it too much.

On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:

> So, maybe we could extend the IODEF as described in Figure 1 of the 
> attached txt file. (correct me if I'm wrong)
> 
> We could define Incident.EventData.AdditionalData elements and 
> describe them by using CPE, CVE/CWE, CVSS/CWSS, and CAPEC.
> Regarding OVAL, we might define Incident.AdditionalData element, but I 
> am not sure at this moment, thus is not described in the figure yet.
> 
> I would like to tackle CAPEC first since I believe Kent would like to 
> tackle CVE and CAPEC.

- --
Wes
claimid.com/wesyoung
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 13:46:55 -0500

Hi all,

In thinking about it, I really don't care which we tackle first. My earlier statements in another forum were focused on looking at the uses,  vulnerability identification (CVE) and affected systems (CPE). Reality is we should be able to do these in a reasonable timeframe so the order appears less important to me.  The key here is to get a reasonably complete set agreed to and documented before the next IETF meeting.

So how does the group here want to approach this?  Address each individually one at a time ?

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Takeshi Takahashi <[email-masked]<mailto:[email-masked]>>
Date: Thu, 28 Jul 2011 09:56:30 -0500
To: Bob Martin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Youki Kadobayashi' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mile] Updated presentation from Side meeting

Take

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Martin, Robert A.
Sent: Thursday, July 28, 2011 8:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

Hi Kathleen,

Bob Martin
MITRE Corporation

On 7/27/11 9:34 AM, [email-masked]<mailto:[email-masked]> wrote:
Hello,

    o  the list of extensions in which interest in development was
expressed, and

Thank you and best regards,
Kathleen
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 28 Jul 2011 16:51:55 -0400

I'm flexible here.
Just let me know how you would like to proceed.
I'll respect your leadership.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 3:47 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

Hi all,

In thinking about it, I really don't care which we tackle first. My earlier
statements in another forum were focused on looking at the uses,
vulnerability identification (CVE) and affected systems (CPE). Reality is we
should be able to do these in a reasonable timeframe so the order appears
less important to me.  The key here is to get a reasonably complete set
agreed to and documented before the next IETF meeting.

So how does the group here want to approach this?  Address each individually
one at a time ?

Thanks.

Kent Landfield

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Takeshi Takahashi
<[email-masked]<mailto:[email-masked]>>
Date: Thu, 28 Jul 2011 09:56:30 -0500
To: Bob Martin <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield
<[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>, 'Youki Kadobayashi'
<[email-masked]<mailto:[email-masked]>>
Subject: RE: [mile] Updated presentation from Side meeting

Take

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Martin, Robert A.
Sent: Thursday, July 28, 2011 8:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

Hi Kathleen,

Bob Martin
MITRE Corporation

On 7/27/11 9:34 AM,
[email-masked]<mailto:[email-masked]> wrote:
Hello,

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 16:28:30 -0500

I think this approach makes more sense. One of the things I think could
be helpful is to have a number of SHOULD statements further describing
the possible types of other documents that would be expected to ride
under the AdditionalData elements of each class (not just EventData).
What I'm thinking of looks like this (very unpolished):

"The Method Class:AdditionalData class SHOULD contain data elements that
describe the methods, tools or techniques employed to cause the
incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the
method such as CVSS, CWSS, or CCE."

"The Expectation Class[...] SHOULD contain data elements which describe
configuration changes, detection heuristics, or [* (legal
authorization?)] to assist in executing or implementing the requested
action, such as XCCDF, OCIL, OVAL, etc"

This could go towards encouraging better or at least more consistent use
of "boundary objects" in the substance of incident reports. I could also
go on about greater automation and such but that's probably out of scope
for this e-mail.

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Young
Sent: Thursday, July 28, 2011 11:08 AM
To: [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

* PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM

--
Wes
claimid.com/wesyoung
[email-masked]

* Wes Young <[email-masked]>
* 0xDDB6E946 - Unverified(L)
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 28 Jul 2011 19:21:56 -0400

Thank you for the email, Tom.

So, here is what the draft needs to describe (if I understand Wes and Tom
correctly).

The draft should define ext-dtype (an attribute of AdditionalData Class) to
identify the information type, rather than defining new class under
AdditionalData.
Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,
ext-cvss, ext-cwss,
In this way, we could keep the change minimal and could easily embed various
structured information (CVE etc.) in the
EventData.Record.RecordData.AdditionalData field.
Then "should" statement should be carefully placed in the text of relevant
class.

I'll prepare some draft so that we could discuss and advance further.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 28, 2011 6:28 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

I think this approach makes more sense. One of the things I think could be
helpful is to have a number of SHOULD statements further describing the
possible types of other documents that would be expected to ride under the
AdditionalData elements of each class (not just EventData).
What I'm thinking of looks like this (very unpolished):

"The Method Class:AdditionalData class SHOULD contain data elements that
describe the methods, tools or techniques employed to cause the incident,
such as CAPEC, CWE, CVE, CVRF, or metadata concerning the method such as
CVSS, CWSS, or CCE."

"The Expectation Class[...] SHOULD contain data elements which describe
configuration changes, detection heuristics, or [* (legal authorization?)]
to assist in executing or implementing the requested action, such as XCCDF,
OCIL, OVAL, etc"

This could go towards encouraging better or at least more consistent use of
"boundary objects" in the substance of incident reports. I could also go on
about greater automation and such but that's probably out of scope for this
e-mail.

 - Tom Millar, US-CERT

-----Original Message-----

--
Wes
claimid.com/wesyoung
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 21:13:48 -0500

I like where this is headed.

Thanks Takeshi.  I look forward to your draft. It will give us something real to discuss. I appreciate you jumping in and getting this started.

One question that I am not clear on. What do we envision as the actual set of deliverables?  From and SCAP related perspective, are we looking at a single draft covering all the extensions?

Kent

Kent Landfield

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Takeshi Takahashi <[email-masked]<mailto:[email-masked]>>
Date: Thu, 28 Jul 2011 18:21:56 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] Updated presentation from Side meeting

Take

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
[email-masked]<mailto:[email-masked]>
Sent: Thursday, July 28, 2011 6:28 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

- Tom Millar, US-CERT

[email-masked]<mailto:[email-masked]>
BB: [email-masked]<mailto:[email-masked]> / 202-631-1915
24x7: [email-masked]<mailto:[email-masked]> / 888-282-0870
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wes
Young
Sent: Thursday, July 28, 2011 11:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

--
Wes
claimid.com/wesyoung
[email-masked]<mailto:[email-masked]>

* Wes Young <[email-masked]<mailto:[email-masked]>>

---

From: "Martin, Robert A." <[email-masked]>
Date: Fri, 29 Jul 2011 08:10:19 -0400

I also like how this is evolving.

I think, as Tom's suggestions pointed, that any and all of the useful 
types of information that can help with understanding, diagnosing, and 
getting ahead of an incident should be added but for now we should focus 
on those the most established and well articulated.

This can be the compliance/patch/configuration/platform information 
related to the SCAP use case, or event signature/attack pattern/traffic 
characteristics from events, or the vulnerability/threat 
characterization space.

I look forward to Taki's draft to see how he suggests positioning these 
concepts.

Bob

On 7/28/11 10:13 PM, [email-masked] wrote:
> From: Takeshi Takahashi<[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> * Wes Young<[email-masked]<mailto:[email-masked]>>
> .

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 29 Jul 2011 09:20:44 -0400

Thank you, Kent, for the email.
Let me work on this for a while, then come back to you later.

IMHO, we could have several separate drafts; maybe we could discuss this at
a later stage when we get some texts.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 11:14 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

Thanks Takeshi.  I look forward to your draft. It will give us something
real to discuss. I appreciate you jumping in and getting this started.

One question that I am not clear on. What do we envision as the actual set
of deliverables?  From and SCAP related perspective, are we looking at a
single draft covering all the extensions?

Kent

Kent Landfield

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Takeshi Takahashi
<[email-masked]<mailto:[email-masked]>>
Date: Thu, 28 Jul 2011 18:21:56 -0500
To: "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] Updated presentation from Side meeting

The draft should define ext-dtype (an attribute of AdditionalData Class) to
identify the information type, rather than defining new class under
AdditionalData.
Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,
ext-cvss, ext-cwss, In this way, we could keep the change minimal and could
easily embed various structured information (CVE etc.) in the
EventData.Record.RecordData.AdditionalData field.
Then "should" statement should be carefully placed in the text of relevant
class.

Take

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of
[email-masked]<mailto:[email-masked]>
Sent: Thursday, July 28, 2011 6:28 PM
To: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

- Tom Millar, US-CERT

[email-masked]<mailto:[email-masked]>
BB: [email-masked]<mailto:[email-masked]> / 202-631-1915
24x7: [email-masked]<mailto:[email-masked]> / 888-282-0870 -----Original
Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Wes Young
Sent: Thursday, July 28, 2011 11:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Updated presentation from Side meeting

So, maybe we could extend the IODEF as described in Figure 1 of the attached
txt file. (correct me if I'm wrong) We could define
Incident.EventData.AdditionalData elements and describe them by using CPE,
CVE/CWE, CVSS/CWSS, and CAPEC.
Regarding OVAL, we might define Incident.AdditionalData element, but I

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 29 Jul 2011 09:20:56 -0400

Thank you, Bob, for the email.
I also like Tom's suggestion very much.
Let me work on the "draft" of the draft for a while, then come back to you
later.

Take

-----Original Message-----
From: Martin, Robert A. [mailto:[email-masked]] 
Sent: Friday, July 29, 2011 9:10 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];

I think, as Tom's suggestions pointed, that any and all of the useful types
of information that can help with understanding, diagnosing, and getting
ahead of an incident should be added but for now we should focus on those
the most established and well articulated.

This can be the compliance/patch/configuration/platform information related
to the SCAP use case, or event signature/attack pattern/traffic
characteristics from events, or the vulnerability/threat characterization
space.

Bob

> From: Takeshi 
> Takahashi<[email-masked]<mailto:[email-masked]
> o.jp>>
> To: 
> "[email-masked]<mailto:[email-masked]>"<Thomas.M
> [email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:we
> [email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]
> rg>>
> So, here is what the draft needs to describe (if I understand Wes and 
> Tom correctly).
>
> The draft should define ext-dtype (an attribute of AdditionalData 
> Class) to identify the information type, rather than defining new 
> class under AdditionalData.
> ext-cvss, ext-cwss, In this way, we could keep the change minimal and 
> could easily embed various structured information (CVE etc.) in the 
> Then "should" statement should be carefully placed in the text of 
> relevant class.
>
> I think this approach makes more sense. One of the things I think 
> could be helpful is to have a number of SHOULD statements further 
> describing the possible types of other documents that would be 
> expected to ride under the AdditionalData elements of each class (not just
EventData).
> "The Method Class:AdditionalData class SHOULD contain data elements 
> that describe the methods, tools or techniques employed to cause the 
> "The Expectation Class[...] SHOULD contain data elements which 
> describe configuration changes, detection heuristics, or [* (legal 
> This could go towards encouraging better or at least more consistent 
> use of "boundary objects" in the substance of incident reports. I 
> could also go on about greater automation and such but that's probably 
> out of scope for this e-mail.
>
>
> - Tom Millar, US-CERT
>
> whatever), embed it there. turns iodef into a sharing platform for 
> other data-types w/o having to extend it too much.
>
> attached txt file. (correct me if I'm wrong) We could define 
> Incident.EventData.AdditionalData elements and describe them by using 
> CPE, CVE/CWE, CVSS/CWSS, and CAPEC.

---

From: <[email-masked]>
Date: Fri, 29 Jul 2011 09:31:28 -0400

Thank you, the approach sounds good, especially since it is in use today by at least the Research and Education ISAC.  Do others have opinions on the proposal here?  

Thanks for writing the first draft Take!

Best regards,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Takeshi Takahashi [[email-masked]]
Sent: Friday, July 29, 2011 9:20 AM
To: 'Martin, Robert A.'; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] Updated presentation from Side meeting

Take

-----Original Message-----
From: Martin, Robert A. [mailto:[email-masked]]
Sent: Friday, July 29, 2011 9:10 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];

Bob

EventData).