From turners@ieca.com Mon Jun 3 10:37:09 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4284421F8B07 for ; Mon, 3 Jun 2013 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xF8B0xAi3UD for ; Mon, 3 Jun 2013 10:36:55 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.44.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97021F8E41 for ; Mon, 3 Jun 2013 10:30:29 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id F368E820635DE; Mon, 3 Jun 2013 12:30:28 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id E6FD8820635B8 for ; Mon, 3 Jun 2013 12:30:28 -0500 (CDT) Received: from [173.73.135.101] (port=50068 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UjYaS-0001AY-Ju for mile@ietf.org; Mon, 03 Jun 2013 12:30:28 -0500 Message-ID: <51ACD2B4.1060205@ieca.com> Date: Mon, 03 Jun 2013 13:30:28 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mile@ietf.org" References: <5181BBA3.1040604@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:50068 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:37:09 -0000 Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: > Hi, > > Sorry for the delay in updating the charter. There is a lot of activity in this space right now as you all know. I took Sean's suggested content and updated it to reflect some of the activity and drivers for additional work in MILE. Several people have mentioned an interest in submitting extensions based on their current work, some in virtualized environments, some for indicator specific formats, some industry specific extensions, etc. There is also work developing by other groups who have mentioned that they will transition their work to an international standards body once it is mature, so room has been left in the charter to accommodate that work. The need for guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport option to enable interoperable interfaces between products. The guidance may be use case specific where tighter security is needed (RID +HTTP/TLS with the object level security options enab led) or w here ease of access is the driver (ROLIE) with no client requirements necessary (can use a browser). > > We will follow up with the mile stones, here the the re-write: > > > > The Managed Incident Lightweight Exchange (MILE) working group > develops standards to support computer and network security > incident management; an incident is an unplanned event that > occurs in an information technology (IT) infrastructure. An > incident could be a benign configuration issue, IT incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for organizations to > collaborate. This collaboration effort may take several forms > including joint analysis, information dissemination, and/or a > coordinated operational response. Examples of the response may > include filing a report, notifying the source of the incident, > requesting that a third party resolve/mitigate the incident, > sharing select indicators of compromise, or requesting that the > source be located. By sharing indicators of compromise associated > with an incident or possible threat, the information becomes a > proactive defense for others that may include mitigation options. > The Incident Object Description Exchange Format (IODEF) defines > an information framework to represent computer and network > security incidents; IODEF is defined in RFC 5070 and > has been extended by RFC 5091 to support phishing reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a protocol to > facilitate sharing computer and network security incidents; > RID is defined in RFC 6545, and RID over HTTPS is defined in RFC > 6546. > > > > The MILE WG is focused on two areas, IODEF the data format and > extensions to represent incident and indicator data and RID, > the policy and transport for structured data. With respect to > IODEF, the working group will: > > - Revise the IODEF document to incorporate enhancements and > extensions based on operational experience; use by Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support industry specific > extensions, use case specific content, and representations to > associate information related to represented threats (system, > threat actors, campaigns, etc.). The value of information > sharing has been demonstrated and highlighted at an increasing > rate through the success of the Information Sharing and > Analysis Centers (ISACs) and the recent cyber security Executive > Order in the US. International groups, such as the Multinational > Association for Collaborative Cyber Situational Awareness (CCSA) > have been running experiments to determine what data is useful to > exchange between industries and nations to effectively mitigate > threats. The work of these and other groups have identified or > are working to develop data representations relevant to their use > cases that may compliment/extend IODEF or be useful to exchange > using RID and related transport protocols. > > - Provide guidance on the implementation and use of IODEF to aid > implementers in developing interoperable specifications. > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST architectural style. > This mechanism will allow CSIRTS to be more dynamic and agile in > collaborating with a broader, and varying constituency. > > - Provide guidance on the implementation and use of RID transports > based on use cases. The guidance document will show the relationship > between transport options (RID + RID transport and IODEF/RID + ROLIE) > and may identify the need for additional transport bindings. > > - RID may require modifications to address data provenance, additional > policy options, or other changes now that there are multiple > interoperable implementations of RFC6545 and RFC6546. With the > RID implementations in the open source community, increased use and > experimentation may demonstrate the need for a revision. > > > > > > > Thank you! > Kathleen > > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Sean Turner [turners@ieca.com] > Sent: Wednesday, May 01, 2013 9:04 PM > To: mile@ietf.org > Subject: [mile] re-charter re-boot > > Hi, > > I'd like to propose a significant re-write of the proposed charter. I > think there's too much history that's not really needed any more and > there's some repetition that's unneeded. I also think it's a little > open ended wrt what's actually going to get done. Based on recent > experience, I have a strong feeling that the current charter wouldn't > get through the process. > > I'm proposing four sections: intro, iodef-related work, rid-related > work, milestones. > > The intro should: > > - explain what the WG does: develop standards to do foo. > - summarize what foo is. > - highlight existing RFCs that are part of the space: > IODEF: 5070/5091/6848 & RID: 6545/6546. > > Then we talk about what drafts the WG will produce for the two topic areas. > > How about this (or something like this): > > > > The Managed Incident Lightweight Exchange (MILE) working group > develops standards to support computer and network security > incident management; an incident is an unplanned event that > occurs in an information technology (IT) infrastructure. An > incident could be a benign configuration issue, IT incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for organizations to > collaborate. This collaboration effort may take several forms > including joint analysis, information dissemination, and/or a > coordinated operational response. Examples of the response may > include filing a report, notifying the source of the incident, > requesting that a third party resolve/mitigate the incident, > sharing indicators of compromise, or requesting that the source > be located. The Incident Object Description Exchange Format > (IODEF) defines an information framework to represent computer > and network security incidents; IODEF is defined in RFC 5070 and > has been extended by RFC 5091 to support phishing reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a protocol to > facilitate sharing computer and network security incidents; > RID is defined in RFC 6545, and RID over HTTPS is defined in RFC > 6546. > > > > This working group does two things IODEF and RID; we should be clear > about that and then list the actual documents we're going to produce > that relate to each one. For the list of deliverables it looks like > there's three 5070bis, a reference/guidance draft, and a > resource-oriented indicator exchange? > > Questions: > > Are the GRC and Forensic drafts dead-dead? I assume they'd not be > included in the milestone list. > > Is there going to only be one 5070bis draft or will there be a 5070bis + > other optional extension drafts? I assume it's just a 5070bis based on > the milestones but thought I'd ask. > > Are we only extending IODEF based on use or is there something else we > need to consider? > > How about something along the lines of (need some help filling in the > blanks): > > > > With respect to IODEF, the working group will: > > - Revise the IODEF document to incorporate enhancements and > extensions based on operational experience; use by Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support x, y, z (need to have > some idea what's missing) base on a, b, c (need to know a bit > more about why stuff is missing did something new pop up?). > > - Provide guidance on the implementation and use of IODEF to aid > implementers in developing interoperable specifications. > > > > For RID: > > Are we also doing defining guidance for RID as well or is that > incorporated in the IODEF guidance? > > Is RID itself going to be untouched and we're just producing a new > "transport"? > > Is it just for indicators or is it for the whole incident? Or has > "indicators" over taken "incident"? > > > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST architectural style. > This mechanism will allow CSIRTS to be more dynamic and agile in > collaborating with a broader, and varying constituency. > > > > > > These looked fine, but I'd like some actual dates for the TBDs ;) > > > > spt > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From Kent_Landfield@mcafee.com Mon Jun 3 11:16:33 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7239A21F9631 for ; Mon, 3 Jun 2013 11:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i9K39iqaDpn for ; Mon, 3 Jun 2013 11:16:19 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6E21E8089 for ; Mon, 3 Jun 2013 11:13:10 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 0f4a_48aa_12b63bf6_4e5c_4624_bebf_6915dc5d419b; Mon, 03 Jun 2013 13:13:09 -0500 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 3 Jun 2013 14:10:01 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.136]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 14:10:01 -0400 From: To: , Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gA== Date: Mon, 3 Jun 2013 18:10:00 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF273329@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <51ACD2B4.1060205@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF273329MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:16:33 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF273329MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have no problem with the revised charter as is but I think there is somet= hing missing. It would be good to have as a milestone a document that desc= ribed use cases for these protocols. I rather see this separated out since= we are in a situation now of addressing the transport (RID) , the data mod= el for exchange (IODEF) and query/reporting capabilities (ROLIE). We need = to tie the three together and a document such as this would help lay a foun= dation for usage in multiple areas. FWIW=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in= this space right now as you all know. I took Sean's suggested content and= updated it to reflect some of the activity and drivers for additional work= in MILE. Several people have mentioned an interest in submitting extensio= ns based on their current work, some in virtualized environments, some for = indicator specific formats, some industry specific extensions, etc. There = is also work developing by other groups who have mentioned that they will t= ransition their work to an international standards body once it is mature, = so room has been left in the charter to accommodate that work. The need fo= r guidance on the transport options has surfaced so that implementers under= stand when they may choose a specific transport option to enable interopera= ble interfaces between products. The guidance may be use case specific whe= re tighter security is needed (RID +HTTP/TLS with the object level security= options enab led) or w here ease of access is the driver (ROLIE) with no client requirements neces= sary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@iet= f.org] On Behalf Of Sean Turner [turners@ieca= .com] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more and there's some repetition that's unneeded. I also think it's a little open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-related work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be clear about that and then list the actual documents we're going to produce that relate to each one. For the list of deliverables it looks like there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF273329MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I have no problem with the revised charter as is but I think there is = something missing.  It would be good to have as a milestone a document= that described use cases for these protocols.  I rather see this sepa= rated out since we are in a situation now of addressing the transport (RID) , the data model for exchange (IODEF) an= d query/reporting capabilities (ROLIE).  We need to tie the three toge= ther and a document such as this would help lay a foundation for usage in m= ultiple areas.

FWIW=85

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Sean Turner <turners@ieca.com>
Date: Monday, June 3, 2013 12:30 PM=
To: "mile@ietf.org" <mile@i= etf.org>
Subject: Re: [mile] re-charter re-b= oot

Comments from anybody else?

spt

On 5/25/13 9:11 AM, Moriarty, Kathleen wrote:
Hi,

Sorry for the delay in updating the charter.  There is a lot= of activity in this space right now as you all know.  I took Sea= n's suggested content and updated it to reflect some of the activity and dr= ivers for additional work in MILE.  Several people have mentioned an interest in submitting extensions based on their current work= , some in virtualized environments, some for indicator specific formats, so= me industry specific extensions, etc.  There is also work develop= ing by other groups who have mentioned that they will transition their work to an international standards body once it= is mature, so room has been left in the charter to accommodate that work.&= nbsp; The need for guidance on the transport options has surfaced so t= hat implementers understand when they may choose a specific transport option to enable interoperable interfaces betw= een products.  The guidance may be use case specific where tighte= r security is needed (RID +HTTP/TLS with the object level security opti= ons enab
led) or w
here ease of access is the driver (ROLIE) with no client requirements = necessary (can use a browser).

We will follow up with the mile stones, here the the re-write:

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response = may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing select indicators of compromise, or requesting that the
source be located. By sharing indicators of compromise associated
with an incident or possible threat, the information becomes a
proactive defense for others that may include mitigation options.
The Incident Object Description Exchange Format (IODEF) defines
an information framework to represent computer and network
security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</intro>

The MILE WG is focused on two areas, IODEF the data format and
extensions to represent incident and indicator data and RID,
the policy and transport for structured data.  With respect = to
IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support industry specific
extensions, use case specific content, and representations to
associate information related to represented threats (system,
threat actors, campaigns, etc.).  The value of information
sharing has been demonstrated and highlighted at an increasing
rate through the success of the Information Sharing and
Analysis Centers (ISACs) and the recent cyber security Executive
Order in the US.  International groups, such as the Multinat= ional
Association for Collaborative Cyber Situational Awareness (CCSA)
have been running experiments to determine what data is useful to
exchange between industries and nations to effectively mitigate
threats.  The work of these and other groups have identified= or
are working to develop data representations relevant to their use
cases that may compliment/extend IODEF or be useful to exchange
using RID and related transport protocols.

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

- Provide guidance on the implementation and use of RID transports
based on use cases.  The guidance document will show the rel= ationship
between transport options (RID + RID transport and IODEF/RID += ROLIE)
and may identify the need for additional transport bindings.

- RID may require modifications to address data provenance, additional=
policy options, or other changes now that there are multiple
interoperable implementations of RFC6545 and RFC6546.  With = the
RID implementations in the open source community, increased use and
experimentation may demonstrate the need for a revision.

<milestones>

</milestones>


Thank you!
Kathleen

________________________________________
Sent: Wednesday, May 01, 2013 9:04 PM
Subject: [mile] re-charter re-boot

Hi,

I'd like to propose a significant re-write of the proposed charter.&nb= sp; I
think there's too much history that's not really needed any more and
there's some repetition that's unneeded.  I also think it's = a little
open ended wrt what's actually going to get done. Based on recent
experience, I have a strong feeling that the current charter wouldn't<= /div>
get through the process.

I'm proposing four sections: intro, iodef-related work, rid-related
work, milestones.

The intro should:

- explain what the WG does: develop standards to do foo.
- summarize what foo is.
- highlight existing RFCs that are part of the space:
     IODEF: 5070/5091/6848 & RID: 6545/6546.

Then we talk about what drafts the WG will produce for the two topic a= reas.

How about this (or something like this):

<intro>

The Managed Incident Lightweight Exchange (MILE) working group
develops standards to support computer and network security
incident management; an incident is an unplanned event that
occurs in an information technology (IT) infrastructure. An
incident could be a benign configuration issue, IT incident, an
infraction to a service level agreement (SLA), a system
compromise, socially engineered phishing attack, or a
denial-of-service (DoS) attack, etc.  When an incident is
detected, or suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms
including joint analysis, information dissemination, and/or a
coordinated operational response.  Examples of the response = may
include filing a report, notifying the source of the incident,
requesting that a third party resolve/mitigate the incident,
sharing indicators of compromise, or requesting that the source
be located. The Incident Object Description Exchange Format
(IODEF) defines an information framework to represent computer
and network security incidents; IODEF is defined in RFC 5070 and
has been extended by RFC 5091 to support phishing reports; RFC
6484 provides a template for defining extensions to IODEF.
Real-time Inter-network Defense (RID) defines a protocol to
facilitate sharing computer and network security incidents;
RID is defined in RFC 6545, and RID over HTTPS is defined in RFC
6546.

</into>

This working group does two things IODEF and RID; we should be clear
about that and then list the actual documents we're going to produce
that relate to each one.  For the list of deliverables it lo= oks like
there's three 5070bis, a reference/guidance draft, and a
resource-oriented indicator exchange?

Questions:

Are the GRC and Forensic drafts dead-dead?  I assume they'd = not be
included in the milestone list.

Is there going to only be one 5070bis draft or will there be a 5070bis= +
other optional extension drafts?  I assume it's just a 5070b= is based on
the milestones but thought I'd ask.

Are we only extending IODEF based on use or is there something else we=
need to consider?

How about something along the lines of (need some help filling in the<= /div>
blanks):

<iodef>

With respect to IODEF, the working group will:

- Revise the IODEF document to incorporate enhancements and
extensions based on operational experience; use by Computer
Security Incident Response Teams (CSIRTs) and others has
exposed the need to extend IODEF to support x, y, z (need to have
some idea what's missing) base on a, b, c (need to know a bit
more about why stuff is missing did something new pop up?).

- Provide guidance on the implementation and use of IODEF to aid
implementers in developing interoperable specifications.

</iodef>

For RID:

Are we also doing defining guidance for RID as well or is that
incorporated in the IODEF guidance?

Is RID itself going to be untouched and we're just producing a new
"transport"?

Is it just for indicators or is it for the whole incident?  = Or has
"indicators" over taken "incident"?

<rid>

With respect to RID, the working group will:

- Define a resource-oriented approach to cyber security
information sharing that follows the REST architectural style.
This mechanism will allow CSIRTS to be more dynamic and agile in
collaborating with a broader, and varying constituency.

</rid>

<milestones>

These looked fine, but I'd like some actual dates for the TBDs ;)

</milestones>

spt
_______________________________________________
mile mailing list

_______________________________________________
mile mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF273329MIVEXAMER1N1corpn_-- From chatlga2000@yahoo.com Mon Jun 3 13:09:26 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6E21E8097 for ; Mon, 3 Jun 2013 13:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QRlnmiaBBmI for ; Mon, 3 Jun 2013 13:09:10 -0700 (PDT) Received: from nm25-vm2.bullet.mail.ne1.yahoo.com (nm25-vm2.bullet.mail.ne1.yahoo.com [98.138.91.213]) by ietfa.amsl.com (Postfix) with ESMTP id D2ACD21E8090 for ; Mon, 3 Jun 2013 13:00:12 -0700 (PDT) Received: from [98.138.226.178] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 20:00:12 -0000 Received: from [98.138.89.232] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 20:00:11 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 20:00:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 955781.81315.bm@omp1047.mail.ne1.yahoo.com Received: (qmail 96718 invoked by uid 60001); 3 Jun 2013 20:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370289611; bh=DpDIPLXRgJ61OCCt433QK+cuYiWvVdNSJiJw7ohD6rI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RZaZbkZkiMnTcAKvCC5NQOLsg3rLzvv/XBzAV6VYn/sw+KgopEon6JLgspuzZ5UBu6jIFUfWSvZb486TcRJAjY66Z6rxHsCNReFmkrYZ7ENtpsUi2DaJBZSZHKnwz3fWJmTaTDcxjT311bsaQ7ykP7+ZArpZjth19LH9Udn7lhA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=bgAz38HVWe/uwsIm+T649rQDfEPzEI7BrlYom1fkDaKb5QHIkSckYqGN6CQQGQuhnoqoNukKfUb+7e4bd4lEyYA/GYdy7+BoROEMr1vF6YDPsZG87fHYRH5alFApTFzRlB7POdFmNdpaB+DJOnSwPapF3q9utyflgDu9TZneBMQ=; X-YMail-OSG: 13ZYO8cVM1lHTWR3nNKYTZlzlnDUgtZp_5e6xXYKaahD8wX HHh1Z.7pKj_hNYI4TDB2q Received: from [71.22.243.36] by web121603.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 13:00:11 PDT X-Rocket-MIMEInfo: 002.001, SSB0aGluayB0aGUgZG9jdW1lbnQgcmVhZHMgcHJldHR5IHdlbGwuwqAgSG93ZXZlciwgcGVyaGFwcyBpdCBjb3VsZCByZWZlcmVuY2UgdG8gdW5leHBlY3RlZMKgIGZ1dHVyZSBjeWJlciBzZWN1cml0eSBpbmNpZGVudHMgLHdoZXJlYXMsIHJlYWwtbGlmZSBpbmNpZGVudHMgY29sbGVjdGl2ZWx5IGNvaW5jaWRlLsKgwqAgSSB3b3VsZCBsaWtlIHRvIHRoaW5rIHRoYXQgYXMgdGhlIENsb3VkIGV2b2x2ZXMsIHNlY3VyaXR5IGNvbmNlcm5zIHdpbGwgYmUgbW9yZSBwcmV2YWxlbnQuDQoNCkMuIEhlbnJ5IEFkYW0BMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.145.547 Message-ID: <1370289611.95184.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 13:00:11 -0700 (PDT) From: "C. Henry Adams & BIE" To: mile@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1682663710-215353360-1370289611=:95184" Subject: Re: [mile] mile Digest, Vol 26, Issue 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:09:26 -0000 ---1682663710-215353360-1370289611=:95184 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the document reads pretty well.=A0 However, perhaps it could refere= nce to unexpected=A0 future cyber security incidents ,whereas, real-life in= cidents collectively coincide.=A0=A0 I would like to think that as the Clou= d evolves, security concerns will be more prevalent. C. Henry Adams =0A --- On Mon, 6/3/13, mile-request@ietf.org wrote: From: mile-request@ietf.org Subject: mile Digest, Vol 26, Issue 1 To: mile@ietf.org Date: Monday, June 3, 2013, 2:16 PM If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.=A0 To do so, go to=20 https://www.ietf.org/mailman/listinfo/mile Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.=A0 You can set this option globally for all the list digests you receive at this point. Send mile mailing list submissions to =A0=A0=A0 mile@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =A0=A0=A0 https://www.ietf.org/mailman/listinfo/mile or, via email, send a message with subject or body 'help' to =A0=A0=A0 mile-request@ietf.org You can reach the person managing the list at =A0=A0=A0 mile-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mile digest..." Today's Topics: =A0=A0=A01. Re: re-charter re-boot (Sean Turner) =A0=A0=A02. Re: re-charter re-boot (Kent_Landfield@McAfee.com) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ---1682663710-215353360-1370289611=:95184 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the document reads pretty well. = However, perhaps it could reference to unexpected  future cyber secur= ity incidents ,whereas, real-life incidents collectively coincide. &nb= sp; I would like to think that as the Cloud evolves, security concerns will= be more prevalent.

C. Henry Adams
=0A

--- On Mon, 6/3/= 13, mile-request@ietf.org <mile-request@ietf.org> wrote:

From: mile-request@ietf.org <mile-request= @ietf.org>
Subject: mile Digest, Vol 26, Issue 1
To: mile@ietf.org=
Date: Monday, June 3, 2013, 2:16 PM

If = you have received this digest without all the individual message
attachm= ents you will need to update your digest options in your list
subscripti= on.  To do so, go to

https://www.ietf.org/mailman/listinfo/mile<= /a>

Click the 'Unsubscribe or edit options' button, log in, and set = "Get
MIME or Plain Text Digests?" to MIME.  You can set this option=
globally for all the list digests you receive at this point.


Send mile mailing list submissions to
    mile@ietf.org

To subscribe or unsubsc= ribe via the World Wide Web, visit
    https://www.ietf.org= /mailman/listinfo/mile
or, via email, send a message with subject or= body 'help' to
    mile-request@ietf.or= g

You can reach the person managing the list at
  &= nbsp; mile-owner@ietf.org

When replying, please edi= t your Subject line so it is more specific
than "Re: Contents of mile di= gest..."
Today's Topics:

 &nb= sp; 1. Re: re-charter re-boot (Sean Turner)
   2. Re= : re-charter re-boot (Kent_Landfield@McAfee.com)
=
_______________________________________________mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/list= info/mile
---1682663710-215353360-1370289611=:95184-- From chatlga2000@yahoo.com Mon Jun 3 14:08:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8FA21F9695 for ; Mon, 3 Jun 2013 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAYBlZlGlllG for ; Mon, 3 Jun 2013 14:08:04 -0700 (PDT) Received: from nm14-vm6.bullet.mail.ne1.yahoo.com (nm14-vm6.bullet.mail.ne1.yahoo.com [98.138.91.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7D21E805A for ; Mon, 3 Jun 2013 14:01:16 -0700 (PDT) Received: from [98.138.90.52] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 21:01:15 -0000 Received: from [98.138.89.246] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 21:01:15 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 03 Jun 2013 21:01:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 486748.27611.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 16904 invoked by uid 60001); 3 Jun 2013 21:01:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370293275; bh=lRTsd77EIrMNfgzCsvHFA3ddWNg6dRaL0OJ0ok/lj94=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yAyjC+7cLBLiSLcKummoNpR30sA4LP/z/D+LGCYDF9Mwr5sL+yzG3TuZxFQ8G1YNla060CXWPA30a+QvzYDHlxpfD9u4zabU/N1HZI4zSswcIZVetJqirssLXNlzmGr4dhBhQPVFwgaJJgFmt/trOTZb+7TIn9LPuz+exMOROcQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V+8AdSCfL+0sCAduwgZLBHTk4fkZPs+7iRsr4FeyTehUFzfmaO3sXGSYhZBmc3Q1+IvvwgMokydBVNg3s30HcskTGVW3Pc5LRW7s6jJXR6h238Fg1W5PYL8gcCuHs/IIqXyNPMF6QGvfXBzzQzaLysNzhigZkN/xYf1R+0mGYoQ=; X-YMail-OSG: E9CQXp0VM1mKk5usq40hBY.lm7RKllG96B7nYDZiLpwiTAz 8I69.qtM9.fWtglB4OtmB Received: from [71.22.243.36] by web121606.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 14:01:15 PDT X-Rocket-MIMEInfo: 002.001, SnVzdCB0aGlua2luZyBvdXQgbG91ZCBoZXJlLsKgIExldCdzIHNheSBhIEJhZCBQZXJzb24gb3IgQmFkIFRlYW0gb2YgUGVvcGxlIG1hbmFnZSB0byBhdHRhY2sgYSBDbG91ZCB0aGF0IG1haW50YWlucyB0aGUgc2FmZXR5IG9mIGEgQ29tbXVuaXR5IHNvbWV3aGVyZSBpbiBhIHJ1cmFsIGFyZWEuDQoNCkluIGRvaW5nIHNvLCB0aGUgcGVyc29uIG9yIHBlcnNvbnMgbWFuYWdlIHRvIGRpc3J1cHQgdGhlIGxpdmVzIGluIHJlYWwtdGltZSBvciByZWFsIGxpZmUuDQoNCkhvdyB3b3VsZCBzaGFyaW5nIGN5YmVyIHMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.145.547 Message-ID: <1370293275.14147.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 14:01:15 -0700 (PDT) From: "C. Henry Adams & BIE" To: mile@ietf.org, mile-request@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-1566641603-1370293275=:14147" Cc: David Misell Subject: Re: [mile] mile Digest, Vol 26, Issue 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:08:20 -0000 --1458340343-1566641603-1370293275=:14147 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Just thinking out loud here.=A0 Let's say a Bad Person or Bad Team of Peopl= e manage to attack a Cloud that maintains the safety of a Community somewhe= re in a rural area. In doing so, the person or persons manage to disrupt the lives in real-time= or real life. How would sharing cyber security info with other cyber security professiona= ls make our work here abstract?=A0 How could we lose visibility utilizing f= uture tools made of a protocol that has obviously already evolved and will = continue to evolve?=A0=20 C. Henry Adams =0A --- On Mon, 6/3/13, David Misell wrote: From: David Misell Subject: Re: [mile] mile Digest, Vol 26, Issue 1 To: "C. Henry Adams & BIE" Date: Monday, June 3, 2013, 4:34 PM I disagree we become more abstracted and lose visibility as cloud services = are adopted Sent from my iPad On 3 Jun 2013, at 21:00, "C. Henry Adams & BIE" wro= te: I think the document reads pretty well.=A0 However, perhaps it could refere= nce to unexpected=A0 future cyber security incidents ,whereas, real-life in= cidents collectively coincide.=A0=A0 I would like to think that as the Clou= d evolves, security concerns will be more prevalent. C. Henry Adams =0A --- On Mon, 6/3/13, mile-request@ietf.org wrote: From: mile-request@ietf.org Subject: mile Digest, Vol 26, Issue 1 To: mile@ietf.org Date: Monday, June 3, 2013, 2:16 PM If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.=A0 To do so, go to=20 https://www.ietf.org/mailman/listinfo/mile Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.=A0 You can set this option globally for all the list digests you receive at this point. Send mile mailing list submissions=0A to =A0=A0=A0 mile@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =A0=A0=A0 https://www.ietf.org/mailman/listinfo/mile or, via email, send a message with subject or body 'help' to =A0=A0=A0 mile-request@ietf.org You can reach the person managing the list at =A0=A0=A0 mile-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mile digest..." Today's Topics: =A0=A0=A01. Re: re-charter re-boot (Sean Turner) =A0=A0=A02. Re: re-charter=0A re-boot (Kent_Landfield@McAfee.com) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --1458340343-1566641603-1370293275=:14147 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Just thinking out loud here.  Let's say = a Bad Person or Bad Team of People manage to attack a Cloud that maintains = the safety of a Community somewhere in a rural area.

In doing so, th= e person or persons manage to disrupt the lives in real-time or real life.<= br>
How would sharing cyber security info with other cyber security prof= essionals make our work here abstract?  How could we lose visibility u= tilizing future tools made of a protocol that has obviously already evolved= and will continue to evolve? 

C. Henry Adams
=0A

--= - On Mon, 6/3/13, David Misell <david.misell@btinternet.com> wrote:

From: David Misell <david.m= isell@btinternet.com>
Subject: Re: [mile] mile Digest, Vol 26, Issue = 1
To: "C. Henry Adams & BIE" <chatlga2000@yahoo.com>
Date: = Monday, June 3, 2013, 4:34 PM

I = disagree we become more abstracted and lose visibility as cloud services ar= e adopted

Sent from my iPad

On 3 Jun 2013, at 21:00, "= C. Henry Adams & BIE" <chatlga2000@yahoo.com> wrote:

I think the document read= s pretty well.  However, perhaps it could reference to unexpected  future= cyber security incidents ,whereas, real-life incidents collectively coinci= de.   I would like to think that as the Cloud evolves, security c= oncerns will be more prevalent.

C. Henry Adams
=0A

--- On = Mon, 6/3/13, mile-re= quest@ietf.org <mile-request@ietf.org> wrote:

= From: mile-request@ie= tf.org <mile-req= uest@ietf.org>
Subject: mile Digest, Vol 26, Issue 1
To: mile@ietf.org
Date: Monday, June 3, 2= 013, 2:16 PM

If you have received this digest without = all the individual message
attachments you will need to update your dige= st options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/mile

Click the = 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain= Text Digests?" to MIME.  You can set this option
globally for all = the list digests you receive at this point.



Send mile mailin= g list submissions=0A to
    mile@iet= f.org

To subscribe or unsubscribe via the World Wide Web, visit<= br>    https://www.ietf.org/mailman/listinfo/= mile
or, via email, send a message with subject or body 'help' to    mile-request@ietf.org

Yo= u can reach the person managing the list at
    mile-owner@ietf.org

When replying, please edit your S= ubject line so it is more specific
than "Re: Contents of mile digest..."=
Today's Topics:

&nbs= p;  1. Re: re-charter re-boot (Sean Turner)
   = 2. Re: re-charter=0A re-boot (Kent_Landfield@McAfee.com= )
______________________= _________________________
mile mailing list
mile@= ietf.org
https://www.ietf.org/mailman/listinfo/mile
___________________________________________= ____
mile mailing list
mile@ietf.org
https://= www.ietf.org/mailman/listinfo/mile
<= /div>
--1458340343-1566641603-1370293275=:14147-- From turners@ieca.com Tue Jun 4 07:04:38 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A121F8233 for ; Tue, 4 Jun 2013 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.06 X-Spam-Level: X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgwho401O1rc for ; Tue, 4 Jun 2013 07:04:23 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.155.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2DF21F9C18 for ; Tue, 4 Jun 2013 05:30:00 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id EDC4F3C24E06; Tue, 4 Jun 2013 07:29:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id ADB373C24D3C for ; Tue, 4 Jun 2013 07:29:59 -0500 (CDT) Received: from [173.73.135.101] (port=54950 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UjqND-000524-3C; Tue, 04 Jun 2013 07:29:59 -0500 Message-ID: <51ADDDC6.2040504@ieca.com> Date: Tue, 04 Jun 2013 08:29:58 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: <3CBA099FBA0AB843895D72474092B8CF273329@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF273329@MIVEXAMER1N1.corp.nai.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:54950 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 14:04:38 -0000 Is that you volunteering to write such a draft ;) spt On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com wrote: > I have no problem with the revised charter as is but I think there is > something missing. It would be good to have as a milestone a document > that described use cases for these protocols. I rather see this > separated out since we are in a situation now of addressing the > transport (RID) , the data model for exchange (IODEF) and > query/reporting capabilities (ROLIE). We need to tie the three together > and a document such as this would help lay a foundation for usage in > multiple areas. > > FWIW… > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: Sean Turner > > Date: Monday, June 3, 2013 12:30 PM > To: "mile@ietf.org " > > Subject: Re: [mile] re-charter re-boot > > Comments from anybody else? > > spt > > On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: > > Hi, > > Sorry for the delay in updating the charter. There is a lot of > activity in this space right now as you all know. I took Sean's > suggested content and updated it to reflect some of the activity > and drivers for additional work in MILE. Several people have > mentioned an interest in submitting extensions based on their > current work, some in virtualized environments, some for > indicator specific formats, some industry specific extensions, > etc. There is also work developing by other groups who have > mentioned that they will transition their work to an > international standards body once it is mature, so room has been > left in the charter to accommodate that work. The need for > guidance on the transport options has surfaced so that > implementers understand when they may choose a specific > transport option to enable interoperable interfaces between > products. The guidance may be use case specific where tighter > security is needed (RID +HTTP/TLS with the object level security > options enab > > led) or w > here ease of access is the driver (ROLIE) with no client > requirements necessary (can use a browser). > > > We will follow up with the mile stones, here the the re-write: > > > > The Managed Incident Lightweight Exchange (MILE) working group > develops standards to support computer and network security > incident management; an incident is an unplanned event that > occurs in an information technology (IT) infrastructure. An > incident could be a benign configuration issue, IT incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for organizations to > collaborate. This collaboration effort may take several forms > including joint analysis, information dissemination, and/or a > coordinated operational response. Examples of the response may > include filing a report, notifying the source of the incident, > requesting that a third party resolve/mitigate the incident, > sharing select indicators of compromise, or requesting that the > source be located. By sharing indicators of compromise associated > with an incident or possible threat, the information becomes a > proactive defense for others that may include mitigation options. > The Incident Object Description Exchange Format (IODEF) defines > an information framework to represent computer and network > security incidents; IODEF is defined in RFC 5070 and > has been extended by RFC 5091 to support phishing reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a protocol to > facilitate sharing computer and network security incidents; > RID is defined in RFC 6545, and RID over HTTPS is defined in RFC > 6546. > > > > The MILE WG is focused on two areas, IODEF the data format and > extensions to represent incident and indicator data and RID, > the policy and transport for structured data. With respect to > IODEF, the working group will: > > - Revise the IODEF document to incorporate enhancements and > extensions based on operational experience; use by Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support industry specific > extensions, use case specific content, and representations to > associate information related to represented threats (system, > threat actors, campaigns, etc.). The value of information > sharing has been demonstrated and highlighted at an increasing > rate through the success of the Information Sharing and > Analysis Centers (ISACs) and the recent cyber security Executive > Order in the US. International groups, such as the Multinational > Association for Collaborative Cyber Situational Awareness (CCSA) > have been running experiments to determine what data is useful to > exchange between industries and nations to effectively mitigate > threats. The work of these and other groups have identified or > are working to develop data representations relevant to their use > cases that may compliment/extend IODEF or be useful to exchange > using RID and related transport protocols. > > - Provide guidance on the implementation and use of IODEF to aid > implementers in developing interoperable specifications. > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST architectural style. > This mechanism will allow CSIRTS to be more dynamic and agile in > collaborating with a broader, and varying constituency. > > - Provide guidance on the implementation and use of RID transports > based on use cases. The guidance document will show the > relationship > between transport options (RID + RID transport and IODEF/RID + > ROLIE) > and may identify the need for additional transport bindings. > > - RID may require modifications to address data provenance, > additional > policy options, or other changes now that there are multiple > interoperable implementations of RFC6545 and RFC6546. With the > RID implementations in the open source community, increased use and > experimentation may demonstrate the need for a revision. > > > > > > > Thank you! > Kathleen > > ________________________________________ > From: mile-bounces@ietf.org > [mile-bounces@ietf.org ] On Behalf > Of Sean Turner [turners@ieca.com ] > Sent: Wednesday, May 01, 2013 9:04 PM > To: mile@ietf.org > Subject: [mile] re-charter re-boot > > Hi, > > I'd like to propose a significant re-write of the proposed > charter. I > think there's too much history that's not really needed any more and > there's some repetition that's unneeded. I also think it's a little > open ended wrt what's actually going to get done. Based on recent > experience, I have a strong feeling that the current charter > wouldn't > get through the process. > > I'm proposing four sections: intro, iodef-related work, rid-related > work, milestones. > > The intro should: > > - explain what the WG does: develop standards to do foo. > - summarize what foo is. > - highlight existing RFCs that are part of the space: > IODEF: 5070/5091/6848 & RID: 6545/6546. > > Then we talk about what drafts the WG will produce for the two > topic areas. > > How about this (or something like this): > > > > The Managed Incident Lightweight Exchange (MILE) working group > develops standards to support computer and network security > incident management; an incident is an unplanned event that > occurs in an information technology (IT) infrastructure. An > incident could be a benign configuration issue, IT incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for organizations to > collaborate. This collaboration effort may take several forms > including joint analysis, information dissemination, and/or a > coordinated operational response. Examples of the response may > include filing a report, notifying the source of the incident, > requesting that a third party resolve/mitigate the incident, > sharing indicators of compromise, or requesting that the source > be located. The Incident Object Description Exchange Format > (IODEF) defines an information framework to represent computer > and network security incidents; IODEF is defined in RFC 5070 and > has been extended by RFC 5091 to support phishing reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a protocol to > facilitate sharing computer and network security incidents; > RID is defined in RFC 6545, and RID over HTTPS is defined in RFC > 6546. > > > > This working group does two things IODEF and RID; we should be clear > about that and then list the actual documents we're going to produce > that relate to each one. For the list of deliverables it looks like > there's three 5070bis, a reference/guidance draft, and a > resource-oriented indicator exchange? > > Questions: > > Are the GRC and Forensic drafts dead-dead? I assume they'd not be > included in the milestone list. > > Is there going to only be one 5070bis draft or will there be a > 5070bis + > other optional extension drafts? I assume it's just a 5070bis > based on > the milestones but thought I'd ask. > > Are we only extending IODEF based on use or is there something > else we > need to consider? > > How about something along the lines of (need some help filling > in the > blanks): > > > > With respect to IODEF, the working group will: > > - Revise the IODEF document to incorporate enhancements and > extensions based on operational experience; use by Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support x, y, z (need to have > some idea what's missing) base on a, b, c (need to know a bit > more about why stuff is missing did something new pop up?). > > - Provide guidance on the implementation and use of IODEF to aid > implementers in developing interoperable specifications. > > > > For RID: > > Are we also doing defining guidance for RID as well or is that > incorporated in the IODEF guidance? > > Is RID itself going to be untouched and we're just producing a new > "transport"? > > Is it just for indicators or is it for the whole incident? Or has > "indicators" over taken "incident"? > > > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST architectural style. > This mechanism will allow CSIRTS to be more dynamic and agile in > collaborating with a broader, and varying constituency. > > > > > > These looked fine, but I'd like some actual dates for the TBDs ;) > > > > spt > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From Kent_Landfield@mcafee.com Tue Jun 4 10:10:28 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC721F9AF8 for ; Tue, 4 Jun 2013 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmKM5JiJT713 for ; Tue, 4 Jun 2013 10:10:24 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 817F221F9BF2 for ; Tue, 4 Jun 2013 08:00:15 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 1f9f_dd84_96f10710_074b_47d1_b48e_380d9902797d; Tue, 04 Jun 2013 10:00:14 -0500 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Jun 2013 10:59:17 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.136]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 10:59:17 -0400 From: To: Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gIABhycA///V4wA= Date: Tue, 4 Jun 2013 14:59:16 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <51ADDDC6.2040504@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF278501MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:10:28 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF278501MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable :-) Something told me you would ask that=85. ;-) Let me see if I can find someone to help with it. Volunteers? I could use = some help I am sure. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Tuesday, June 4, 2013 7:29 AM To: Kent Landfield > Cc: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot Is that you volunteering to write such a draft ;) spt On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com wrote: I have no problem with the revised charter as is but I think there is something missing. It would be good to have as a milestone a document that described use cases for these protocols. I rather see this separated out since we are in a situation now of addressing the transport (RID) , the data model for exchange (IODEF) and query/reporting capabilities (ROLIE). We need to tie the three together and a document such as this would help lay a foundation for usage in multiple areas. FWIW=85 *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org " > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in this space right now as you all know. I took Sean's suggested content and updated it to reflect some of the activity and drivers for additional work in MILE. Several people have mentioned an interest in submitting extensions based on their current work, some in virtualized environments, some for indicator specific formats, some industry specific extensions, etc. There is also work developing by other groups who have mentioned that they will transition their work to an international standards body once it is mature, so room has been left in the charter to accommodate that work. The need for guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport option to enable interoperable interfaces between products. The guidance may be use case specific where tighter security is needed (RID +HTTP/TLS with the object level security options enab led) or w here ease of access is the driver (ROLIE) with no client requirements necessary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use an= d experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org ] On Behalf Of Sean Turner [turners@ieca.com ] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more a= nd there's some repetition that's unneeded. I also think it's a litt= le open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-relate= d work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be cle= ar about that and then list the actual documents we're going to produ= ce that relate to each one. For the list of deliverables it looks li= ke there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF278501MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
:-) Something told me you would ask that=85.  ;-)

Let me see if I can find someone to help with it. Volunteers?  I = could use some help I am sure.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Sean Turner <turners@ieca.com>
Date: Tuesday, June 4, 2013 7:29 AM=
To: Kent Landfield <Kent_Landfield@McAfee.com>
Cc: "mile@ietf.org" <mile@i= etf.org>
Subject: Re: [mile] re-charter re-b= oot

Is that you volunteering to write such a draft ;)

spt

On 6/3/13 2:10 PM, Kent_L= andfield@McAfee.com wrote:
I have no problem with the revised charter as is but I think there is<= /div>
something missing.  It would be good to have as a milestone = a document
that described use cases for these protocols.  I rather see = this
separated out since we are in a situation now of addressing the
transport (RID) , the data model for exchange (IODEF) and
query/reporting capabilities (ROLIE).  We need to tie the th= ree together
and a document such as this would help lay a foundation for usage in
multiple areas.

FWIW=85

*Kent Landfield*

*McAfee | An Intel Company*
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
*Web: *www.mcafee.com <http://ww= w.mcafee.com/>

Date: Monday, June 3, 2013 12:30 PM
Subject: Re: [mile] re-charter re-boot

     Comments from anybody else?

     spt

     On 5/25/13 9:11 AM, Moriarty, Kathleen wrote:=

         Hi,

         Sorry for the delay i= n updating the charter.  There is a lot of
         activity in this spac= e right now as you all know.  I took Sean's
         suggested content and= updated it to reflect some of the activity
         and drivers for addit= ional work in MILE.  Several people have
         mentioned an interest= in submitting extensions based on their
         current work, some in= virtualized environments, some for
         indicator specific fo= rmats, some industry specific extensions,
         etc.  There= is also work developing by other groups who have
         mentioned that they w= ill transition their work to an
         international standar= ds body once it is mature, so room has been
         left in the charter t= o accommodate that work.  The need for
         guidance on the trans= port options has surfaced so that
         implementers understa= nd when they may choose a specific
         transport option to e= nable interoperable interfaces between
         products.  = The guidance may be use case specific where tighter
         security is needed (R= ID +HTTP/TLS with the object level security
         options enab

     led) or w
     here ease of access is the driver (ROLIE) wit= h no client
     requirements necessary (can use a browser).


         We will follow up wit= h the mile stones, here the the re-write:

         <intro>

         The Managed Incident = Lightweight Exchange (MILE) working group
         develops standards to= support computer and network security
         incident management; = an incident is an unplanned event that
         occurs in an informat= ion technology (IT) infrastructure. An
         incident could be a b= enign configuration issue, IT incident, an
         infraction to a servi= ce level agreement (SLA), a system
         compromise, socially = engineered phishing attack, or a
         denial-of-service (Do= S) attack, etc.  When an incident is
         detected, or suspecte= d, there may be a need for organizations to
         collaborate. This col= laboration effort may take several forms
         including joint analy= sis, information dissemination, and/or a
         coordinated operation= al response.  Examples of the response may
         include filing a repo= rt, notifying the source of the incident,
         requesting that a thi= rd party resolve/mitigate the incident,
         sharing select indica= tors of compromise, or requesting that the
         source be located. By= sharing indicators of compromise associated
         with an incident or p= ossible threat, the information becomes a
         proactive defense for= others that may include mitigation options.
         The Incident Object D= escription Exchange Format (IODEF) defines
         an information framew= ork to represent computer and network
         security incidents; I= ODEF is defined in RFC 5070 and
         has been extended by = RFC 5091 to support phishing reports; RFC
         6484 provides a templ= ate for defining extensions to IODEF.
         Real-time Inter-netwo= rk Defense (RID) defines a protocol to
         facilitate sharing co= mputer and network security incidents;
         RID is defined in RFC= 6545, and RID over HTTPS is defined in RFC
         6546.

         </intro>

         The MILE WG is focuse= d on two areas, IODEF the data format and
         extensions to represe= nt incident and indicator data and RID,
         the policy and transp= ort for structured data.  With respect to
         IODEF, the working gr= oup will:

         - Revise the IODEF do= cument to incorporate enhancements and
         extensions based on o= perational experience; use by Computer
         Security Incident Res= ponse Teams (CSIRTs) and others has
         exposed the need to e= xtend IODEF to support industry specific
         extensions, use case = specific content, and representations to
         associate information= related to represented threats (system,
         threat actors, campai= gns, etc.).  The value of information
         sharing has been demo= nstrated and highlighted at an increasing
         rate through the succ= ess of the Information Sharing and
         Analysis Centers (ISA= Cs) and the recent cyber security Executive
         Order in the US. = ; International groups, such as the Multinational
         Association for Colla= borative Cyber Situational Awareness (CCSA)
         have been running exp= eriments to determine what data is useful to
         exchange between indu= stries and nations to effectively mitigate
         threats.  T= he work of these and other groups have identified or
         are working to develo= p data representations relevant to their use
         cases that may compli= ment/extend IODEF or be useful to exchange
         using RID and related= transport protocols.

         - Provide guidance on= the implementation and use of IODEF to aid
         implementers in devel= oping interoperable specifications.

         With respect to RID, = the working group will:

         - Define a resource-o= riented approach to cyber security
         information sharing t= hat follows the REST architectural style.
         This mechanism will a= llow CSIRTS to be more dynamic and agile in
         collaborating with a = broader, and varying constituency.

         - Provide guidance on= the implementation and use of RID transports
         based on use cases.&n= bsp; The guidance document will show the
         relationship
         between transport opt= ions (RID + RID transport and IODEF/RID +
         ROLIE)
         and may identify the = need for additional transport bindings.

         - RID may require mod= ifications to address data provenance,
         additional
         policy options, or ot= her changes now that there are multiple
         interoperable impleme= ntations of RFC6545 and RFC6546.  With the
         RID implementations i= n the open source community, increased use and
         experimentation may d= emonstrate the need for a revision.

         <milestones>

         </milestones>


         Thank you!
         Kathleen

         _____________________= ___________________
         Of Sean Turner [turners@ieca.com <mailto:turners@ieca.com>]
         Sent: Wednesday, May = 01, 2013 9:04 PM
         To: mile@ietf.org <mail= to:mile@ietf.org>
         Subject: [mile] re-ch= arter re-boot

         Hi,

         I'd like to propose a= significant re-write of the proposed
         charter.  I=
         think there's too muc= h history that's not really needed any more and
         there's some repetiti= on that's unneeded.  I also think it's a little
         open ended wrt what's= actually going to get done. Based on recent
         experience, I have a = strong feeling that the current charter
         wouldn't
         get through the proce= ss.

         I'm proposing four se= ctions: intro, iodef-related work, rid-related
         work, milestones.

         The intro should:

         - explain what the WG= does: develop standards to do foo.
         - summarize what foo = is.
         - highlight existing = RFCs that are part of the space:
           &nbs= p;   IODEF: 5070/5091/6848 & RID: 6545/6546.

         Then we talk about wh= at drafts the WG will produce for the two
         topic areas.

         How about this (or so= mething like this):

         <intro>

         The Managed Incident = Lightweight Exchange (MILE) working group
         develops standards to= support computer and network security
         incident management; = an incident is an unplanned event that
         occurs in an informat= ion technology (IT) infrastructure. An
         incident could be a b= enign configuration issue, IT incident, an
         infraction to a servi= ce level agreement (SLA), a system
         compromise, socially = engineered phishing attack, or a
         denial-of-service (Do= S) attack, etc.  When an incident is
         detected, or suspecte= d, there may be a need for organizations to
         collaborate. This col= laboration effort may take several forms
         including joint analy= sis, information dissemination, and/or a
         coordinated operation= al response.  Examples of the response may
         include filing a repo= rt, notifying the source of the incident,
         requesting that a thi= rd party resolve/mitigate the incident,
         sharing indicators of= compromise, or requesting that the source
         be located. The Incid= ent Object Description Exchange Format
         (IODEF) defines an in= formation framework to represent computer
         and network security = incidents; IODEF is defined in RFC 5070 and
         has been extended by = RFC 5091 to support phishing reports; RFC
         6484 provides a templ= ate for defining extensions to IODEF.
         Real-time Inter-netwo= rk Defense (RID) defines a protocol to
         facilitate sharing co= mputer and network security incidents;
         RID is defined in RFC= 6545, and RID over HTTPS is defined in RFC
         6546.

         </into>

         This working group do= es two things IODEF and RID; we should be clear
         about that and then l= ist the actual documents we're going to produce
         that relate to each o= ne.  For the list of deliverables it looks like
         there's three 5070bis= , a reference/guidance draft, and a
         resource-oriented ind= icator exchange?

         Questions:

         Are the GRC and Foren= sic drafts dead-dead?  I assume they'd not be
         included in the miles= tone list.

         Is there going to onl= y be one 5070bis draft or will there be a
         5070bis +
         other optional extens= ion drafts?  I assume it's just a 5070bis
         based on
         the milestones but th= ought I'd ask.

         Are we only extending= IODEF based on use or is there something
         else we
         need to consider?

         How about something a= long the lines of (need some help filling
         in the
         blanks):

         <iodef>

         With respect to IODEF= , the working group will:

         - Revise the IODEF do= cument to incorporate enhancements and
         extensions based on o= perational experience; use by Computer
         Security Incident Res= ponse Teams (CSIRTs) and others has
         exposed the need to e= xtend IODEF to support x, y, z (need to have
         some idea what's miss= ing) base on a, b, c (need to know a bit
         more about why stuff = is missing did something new pop up?).

         - Provide guidance on= the implementation and use of IODEF to aid
         implementers in devel= oping interoperable specifications.

         </iodef>

         For RID:

         Are we also doing def= ining guidance for RID as well or is that
         incorporated in the I= ODEF guidance?

         Is RID itself going t= o be untouched and we're just producing a new
         "transport"= ?

         Is it just for indica= tors or is it for the whole incident?  Or has
         "indicators"= ; over taken "incident"?

         <rid>

         With respect to RID, = the working group will:

         - Define a resource-o= riented approach to cyber security
         information sharing t= hat follows the REST architectural style.
         This mechanism will a= llow CSIRTS to be more dynamic and agile in
         collaborating with a = broader, and varying constituency.

         </rid>

         <milestones>

         These looked fine, bu= t I'd like some actual dates for the TBDs ;)

         </milestones>

         spt
         _____________________= __________________________
         mile mailing list

     _____________________________________________= __
     mile mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF278501MIVEXAMER1N1corpn_-- From ewb25@georgetown.edu Tue Jun 4 12:57:01 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88E21F95D7 for ; Tue, 4 Jun 2013 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILa-mrIQ8qy2 for ; Tue, 4 Jun 2013 12:56:56 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 555DB21F9C18 for ; Tue, 4 Jun 2013 12:28:13 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id hv16so471997qab.20 for ; Tue, 04 Jun 2013 12:28:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qsSUcvXI0Y1rj70Hm/dEJdJYnOIjMA4YCUPmA9D+PlA=; b=TpWAcjBDLED51DQCly3RvfIgNdK/WUSN2r4AzQq5nK9CwtnjuAF9WbLRP0lWC9oxrS uweKJp+fqU368q7jHhnxAFgg+0+rTM9m1CPjyVl7K86SGn7qXWQQaqH8ZvSrjiI37q2L h3j5JiIvR0+TOWbfit4DiAqMxhLqu4hUaJ2bOiAUypJA0nPnAJRrZSDQvra+VWF8i3zf LvfVDbZFmciVvfp4Bkf49yy7KTv2LuiaoL1NvxSViZmlK4ByfQgmyOZXn6Z9MQ/CCzBH 4IqB31c/y4rivuVUST7CZV7ZZJjhbSLfryO/2/LRDF8KIwhV9QtvfbhpvRIets9/WJxN MDEQ== X-Received: by 10.224.73.134 with SMTP id q6mr25221723qaj.63.1370374093357; Tue, 04 Jun 2013 12:28:13 -0700 (PDT) Received: from [141.161.20.235] ([141.161.20.235]) by mx.google.com with ESMTPSA id j3sm68357328qav.1.2013.06.04.12.28.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 12:28:12 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Eric Burger In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> Date: Tue, 4 Jun 2013 15:28:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <624747ED-9458-449A-821E-D3A037E748EE@standardstrack.com> References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> To: Landfield Kent , Turner Sean X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkjRxcSWliy/xONl8AYestwzdeMnDPkCXjrkJ1TqmJgfspr6/ecJA9caRehNemToygv7uM3 X-Mailman-Approved-At: Tue, 04 Jun 2013 12:58:09 -0700 Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:57:01 -0000 It will take more than a week :-) On Jun 4, 2013, at 10:59 AM, kent_landfield@mcafee.com wrote: > :-) Something told me you would ask that=85. ;-) >=20 > Let me see if I can find someone to help with it. Volunteers? I could = use some help I am sure. >=20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com >=20 > From: Sean Turner > Date: Tuesday, June 4, 2013 7:29 AM > To: Kent Landfield > Cc: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot >=20 >> Is that you volunteering to write such a draft ;) >>=20 >> spt >>=20 >> On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com wrote: >>> I have no problem with the revised charter as is but I think there = is >>> something missing. It would be good to have as a milestone a = document >>> that described use cases for these protocols. I rather see this >>> separated out since we are in a situation now of addressing the >>> transport (RID) , the data model for exchange (IODEF) and >>> query/reporting capabilities (ROLIE). We need to tie the three = together >>> and a document such as this would help lay a foundation for usage in >>> multiple areas. >>>=20 >>> FWIW=85 >>>=20 >>> *Kent Landfield* >>>=20 >>> *McAfee | An Intel Company* >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> *Web: *www.mcafee.com >>>=20 >>> From: Sean Turner > >>> Date: Monday, June 3, 2013 12:30 PM >>> To: "mile@ietf.org " >> > >>> Subject: Re: [mile] re-charter re-boot >>>=20 >>> Comments from anybody else? >>>=20 >>> spt >>>=20 >>> On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: >>>=20 >>> Hi, >>>=20 >>> Sorry for the delay in updating the charter. There is a lot = of >>> activity in this space right now as you all know. I took = Sean's >>> suggested content and updated it to reflect some of the = activity >>> and drivers for additional work in MILE. Several people have >>> mentioned an interest in submitting extensions based on their >>> current work, some in virtualized environments, some for >>> indicator specific formats, some industry specific extensions, >>> etc. There is also work developing by other groups who have >>> mentioned that they will transition their work to an >>> international standards body once it is mature, so room has = been >>> left in the charter to accommodate that work. The need for >>> guidance on the transport options has surfaced so that >>> implementers understand when they may choose a specific >>> transport option to enable interoperable interfaces between >>> products. The guidance may be use case specific where tighter >>> security is needed (RID +HTTP/TLS with the object level = security >>> options enab >>>=20 >>> led) or w >>> here ease of access is the driver (ROLIE) with no client >>> requirements necessary (can use a browser). >>>=20 >>>=20 >>> We will follow up with the mile stones, here the the re-write: >>>=20 >>> >>>=20 >>> The Managed Incident Lightweight Exchange (MILE) working group >>> develops standards to support computer and network security >>> incident management; an incident is an unplanned event that >>> occurs in an information technology (IT) infrastructure. An >>> incident could be a benign configuration issue, IT incident, = an >>> infraction to a service level agreement (SLA), a system >>> compromise, socially engineered phishing attack, or a >>> denial-of-service (DoS) attack, etc. When an incident is >>> detected, or suspected, there may be a need for organizations = to >>> collaborate. This collaboration effort may take several forms >>> including joint analysis, information dissemination, and/or a >>> coordinated operational response. Examples of the response = may >>> include filing a report, notifying the source of the incident, >>> requesting that a third party resolve/mitigate the incident, >>> sharing select indicators of compromise, or requesting that = the >>> source be located. By sharing indicators of compromise = associated >>> with an incident or possible threat, the information becomes a >>> proactive defense for others that may include mitigation = options. >>> The Incident Object Description Exchange Format (IODEF) = defines >>> an information framework to represent computer and network >>> security incidents; IODEF is defined in RFC 5070 and >>> has been extended by RFC 5091 to support phishing reports; RFC >>> 6484 provides a template for defining extensions to IODEF. >>> Real-time Inter-network Defense (RID) defines a protocol to >>> facilitate sharing computer and network security incidents; >>> RID is defined in RFC 6545, and RID over HTTPS is defined in = RFC >>> 6546. >>>=20 >>> >>>=20 >>> The MILE WG is focused on two areas, IODEF the data format and >>> extensions to represent incident and indicator data and RID, >>> the policy and transport for structured data. With respect to >>> IODEF, the working group will: >>>=20 >>> - Revise the IODEF document to incorporate enhancements and >>> extensions based on operational experience; use by Computer >>> Security Incident Response Teams (CSIRTs) and others has >>> exposed the need to extend IODEF to support industry specific >>> extensions, use case specific content, and representations to >>> associate information related to represented threats (system, >>> threat actors, campaigns, etc.). The value of information >>> sharing has been demonstrated and highlighted at an increasing >>> rate through the success of the Information Sharing and >>> Analysis Centers (ISACs) and the recent cyber security = Executive >>> Order in the US. International groups, such as the = Multinational >>> Association for Collaborative Cyber Situational Awareness = (CCSA) >>> have been running experiments to determine what data is useful = to >>> exchange between industries and nations to effectively = mitigate >>> threats. The work of these and other groups have identified = or >>> are working to develop data representations relevant to their = use >>> cases that may compliment/extend IODEF or be useful to = exchange >>> using RID and related transport protocols. >>>=20 >>> - Provide guidance on the implementation and use of IODEF to = aid >>> implementers in developing interoperable specifications. >>>=20 >>> With respect to RID, the working group will: >>>=20 >>> - Define a resource-oriented approach to cyber security >>> information sharing that follows the REST architectural style. >>> This mechanism will allow CSIRTS to be more dynamic and agile = in >>> collaborating with a broader, and varying constituency. >>>=20 >>> - Provide guidance on the implementation and use of RID = transports >>> based on use cases. The guidance document will show the >>> relationship >>> between transport options (RID + RID transport and IODEF/RID + >>> ROLIE) >>> and may identify the need for additional transport bindings. >>>=20 >>> - RID may require modifications to address data provenance, >>> additional >>> policy options, or other changes now that there are multiple >>> interoperable implementations of RFC6545 and RFC6546. With = the >>> RID implementations in the open source community, increased = use and >>> experimentation may demonstrate the need for a revision. >>>=20 >>> >>>=20 >>> >>>=20 >>>=20 >>> Thank you! >>> Kathleen >>>=20 >>> ________________________________________ >>> From: mile-bounces@ietf.org >>> [mile-bounces@ietf.org ] On = Behalf >>> Of Sean Turner [turners@ieca.com ] >>> Sent: Wednesday, May 01, 2013 9:04 PM >>> To: mile@ietf.org >>> Subject: [mile] re-charter re-boot >>>=20 >>> Hi, >>>=20 >>> I'd like to propose a significant re-write of the proposed >>> charter. I >>> think there's too much history that's not really needed any = more and >>> there's some repetition that's unneeded. I also think it's a = little >>> open ended wrt what's actually going to get done. Based on = recent >>> experience, I have a strong feeling that the current charter >>> wouldn't >>> get through the process. >>>=20 >>> I'm proposing four sections: intro, iodef-related work, = rid-related >>> work, milestones. >>>=20 >>> The intro should: >>>=20 >>> - explain what the WG does: develop standards to do foo. >>> - summarize what foo is. >>> - highlight existing RFCs that are part of the space: >>> IODEF: 5070/5091/6848 & RID: 6545/6546. >>>=20 >>> Then we talk about what drafts the WG will produce for the two >>> topic areas. >>>=20 >>> How about this (or something like this): >>>=20 >>> >>>=20 >>> The Managed Incident Lightweight Exchange (MILE) working group >>> develops standards to support computer and network security >>> incident management; an incident is an unplanned event that >>> occurs in an information technology (IT) infrastructure. An >>> incident could be a benign configuration issue, IT incident, = an >>> infraction to a service level agreement (SLA), a system >>> compromise, socially engineered phishing attack, or a >>> denial-of-service (DoS) attack, etc. When an incident is >>> detected, or suspected, there may be a need for organizations = to >>> collaborate. This collaboration effort may take several forms >>> including joint analysis, information dissemination, and/or a >>> coordinated operational response. Examples of the response = may >>> include filing a report, notifying the source of the incident, >>> requesting that a third party resolve/mitigate the incident, >>> sharing indicators of compromise, or requesting that the = source >>> be located. The Incident Object Description Exchange Format >>> (IODEF) defines an information framework to represent computer >>> and network security incidents; IODEF is defined in RFC 5070 = and >>> has been extended by RFC 5091 to support phishing reports; RFC >>> 6484 provides a template for defining extensions to IODEF. >>> Real-time Inter-network Defense (RID) defines a protocol to >>> facilitate sharing computer and network security incidents; >>> RID is defined in RFC 6545, and RID over HTTPS is defined in = RFC >>> 6546. >>>=20 >>> >>>=20 >>> This working group does two things IODEF and RID; we should be = clear >>> about that and then list the actual documents we're going to = produce >>> that relate to each one. For the list of deliverables it = looks like >>> there's three 5070bis, a reference/guidance draft, and a >>> resource-oriented indicator exchange? >>>=20 >>> Questions: >>>=20 >>> Are the GRC and Forensic drafts dead-dead? I assume they'd = not be >>> included in the milestone list. >>>=20 >>> Is there going to only be one 5070bis draft or will there be a >>> 5070bis + >>> other optional extension drafts? I assume it's just a 5070bis >>> based on >>> the milestones but thought I'd ask. >>>=20 >>> Are we only extending IODEF based on use or is there something >>> else we >>> need to consider? >>>=20 >>> How about something along the lines of (need some help filling >>> in the >>> blanks): >>>=20 >>> >>>=20 >>> With respect to IODEF, the working group will: >>>=20 >>> - Revise the IODEF document to incorporate enhancements and >>> extensions based on operational experience; use by Computer >>> Security Incident Response Teams (CSIRTs) and others has >>> exposed the need to extend IODEF to support x, y, z (need to = have >>> some idea what's missing) base on a, b, c (need to know a bit >>> more about why stuff is missing did something new pop up?). >>>=20 >>> - Provide guidance on the implementation and use of IODEF to = aid >>> implementers in developing interoperable specifications. >>>=20 >>> >>>=20 >>> For RID: >>>=20 >>> Are we also doing defining guidance for RID as well or is that >>> incorporated in the IODEF guidance? >>>=20 >>> Is RID itself going to be untouched and we're just producing a = new >>> "transport"? >>>=20 >>> Is it just for indicators or is it for the whole incident? Or = has >>> "indicators" over taken "incident"? >>>=20 >>> >>>=20 >>> With respect to RID, the working group will: >>>=20 >>> - Define a resource-oriented approach to cyber security >>> information sharing that follows the REST architectural style. >>> This mechanism will allow CSIRTS to be more dynamic and agile = in >>> collaborating with a broader, and varying constituency. >>>=20 >>> >>>=20 >>> >>>=20 >>> These looked fine, but I'd like some actual dates for the TBDs = ;) >>>=20 >>> >>>=20 >>> spt >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Tue Jun 4 14:41:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9898E21F92C5 for ; Tue, 4 Jun 2013 14:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XubNfSVQNsgq for ; Tue, 4 Jun 2013 14:41:54 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.7.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3EA21F843F for ; Tue, 4 Jun 2013 13:41:03 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 8F7F63F377193; Tue, 4 Jun 2013 15:40:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 77CA03F3770FF for ; Tue, 4 Jun 2013 15:40:53 -0500 (CDT) Received: from [173.73.135.101] (port=55596 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ujy2M-0001fs-0O; Tue, 04 Jun 2013 15:40:58 -0500 Message-ID: <51AE50D9.1090408@ieca.com> Date: Tue, 04 Jun 2013 16:40:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:55596 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 17 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:41:59 -0000 Well unless I'm hearing any violent objections I think adding it would make sense actually. It's also an easy for somebody who is using this technology to get their feet wet in the WG. spt On 6/4/13 10:59 AM, Kent_Landfield@McAfee.com wrote: > :-) Something told me you would ask that…. ;-) > > Let me see if I can find someone to help with it. Volunteers? I could > use some help I am sure. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: Sean Turner > > Date: Tuesday, June 4, 2013 7:29 AM > To: Kent Landfield > > Cc: "mile@ietf.org " > > Subject: Re: [mile] re-charter re-boot > > Is that you volunteering to write such a draft ;) > > spt > > On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com > wrote: > > I have no problem with the revised charter as is but I think > there is > something missing. It would be good to have as a milestone a > document > that described use cases for these protocols. I rather see this > separated out since we are in a situation now of addressing the > transport (RID) , the data model for exchange (IODEF) and > query/reporting capabilities (ROLIE). We need to tie the three > together > and a document such as this would help lay a foundation for usage in > multiple areas. > > FWIW… > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: Sean Turner > > > Date: Monday, June 3, 2013 12:30 PM > To: "mile@ietf.org > " > > > Subject: Re: [mile] re-charter re-boot > > Comments from anybody else? > > spt > > On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: > > Hi, > > Sorry for the delay in updating the charter. There is > a lot of > activity in this space right now as you all know. I > took Sean's > suggested content and updated it to reflect some of > the activity > and drivers for additional work in MILE. Several > people have > mentioned an interest in submitting extensions based > on their > current work, some in virtualized environments, some for > indicator specific formats, some industry specific > extensions, > etc. There is also work developing by other groups > who have > mentioned that they will transition their work to an > international standards body once it is mature, so > room has been > left in the charter to accommodate that work. The > need for > guidance on the transport options has surfaced so that > implementers understand when they may choose a specific > transport option to enable interoperable interfaces > between > products. The guidance may be use case specific where > tighter > security is needed (RID +HTTP/TLS with the object > level security > options enab > > led) or w > here ease of access is the driver (ROLIE) with no client > requirements necessary (can use a browser). > > > We will follow up with the mile stones, here the the > re-write: > > > > The Managed Incident Lightweight Exchange (MILE) > working group > develops standards to support computer and network > security > incident management; an incident is an unplanned event > that > occurs in an information technology (IT) > infrastructure. An > incident could be a benign configuration issue, IT > incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for > organizations to > collaborate. This collaboration effort may take > several forms > including joint analysis, information dissemination, > and/or a > coordinated operational response. Examples of the > response may > include filing a report, notifying the source of the > incident, > requesting that a third party resolve/mitigate the > incident, > sharing select indicators of compromise, or requesting > that the > source be located. By sharing indicators of compromise > associated > with an incident or possible threat, the information > becomes a > proactive defense for others that may include > mitigation options. > The Incident Object Description Exchange Format > (IODEF) defines > an information framework to represent computer and network > security incidents; IODEF is defined in RFC 5070 and > has been extended by RFC 5091 to support phishing > reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a > protocol to > facilitate sharing computer and network security > incidents; > RID is defined in RFC 6545, and RID over HTTPS is > defined in RFC > 6546. > > > > The MILE WG is focused on two areas, IODEF the data > format and > extensions to represent incident and indicator data > and RID, > the policy and transport for structured data. With > respect to > IODEF, the working group will: > > - Revise the IODEF document to incorporate > enhancements and > extensions based on operational experience; use by > Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support industry > specific > extensions, use case specific content, and > representations to > associate information related to represented threats > (system, > threat actors, campaigns, etc.). The value of information > sharing has been demonstrated and highlighted at an > increasing > rate through the success of the Information Sharing and > Analysis Centers (ISACs) and the recent cyber security > Executive > Order in the US. International groups, such as the > Multinational > Association for Collaborative Cyber Situational > Awareness (CCSA) > have been running experiments to determine what data > is useful to > exchange between industries and nations to effectively > mitigate > threats. The work of these and other groups have > identified or > are working to develop data representations relevant > to their use > cases that may compliment/extend IODEF or be useful to > exchange > using RID and related transport protocols. > > - Provide guidance on the implementation and use of > IODEF to aid > implementers in developing interoperable specifications. > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST > architectural style. > This mechanism will allow CSIRTS to be more dynamic > and agile in > collaborating with a broader, and varying constituency. > > - Provide guidance on the implementation and use of > RID transports > based on use cases. The guidance document will show the > relationship > between transport options (RID + RID transport and > IODEF/RID + > ROLIE) > and may identify the need for additional transport > bindings. > > - RID may require modifications to address data > provenance, > additional > policy options, or other changes now that there are > multiple > interoperable implementations of RFC6545 and > RFC6546. With the > RID implementations in the open source community, > increased use and > experimentation may demonstrate the need for a revision. > > > > > > > Thank you! > Kathleen > > ________________________________________ > From: mile-bounces@ietf.org > > [mile-bounces@ietf.org > ] On Behalf > Of Sean Turner [turners@ieca.com > ] > Sent: Wednesday, May 01, 2013 9:04 PM > To: mile@ietf.org > > Subject: [mile] re-charter re-boot > > Hi, > > I'd like to propose a significant re-write of the proposed > charter. I > think there's too much history that's not really > needed any more and > there's some repetition that's unneeded. I also think > it's a little > open ended wrt what's actually going to get done. > Based on recent > experience, I have a strong feeling that the current > charter > wouldn't > get through the process. > > I'm proposing four sections: intro, iodef-related > work, rid-related > work, milestones. > > The intro should: > > - explain what the WG does: develop standards to do foo. > - summarize what foo is. > - highlight existing RFCs that are part of the space: > IODEF: 5070/5091/6848 & RID: 6545/6546. > > Then we talk about what drafts the WG will produce for > the two > topic areas. > > How about this (or something like this): > > > > The Managed Incident Lightweight Exchange (MILE) > working group > develops standards to support computer and network > security > incident management; an incident is an unplanned event > that > occurs in an information technology (IT) > infrastructure. An > incident could be a benign configuration issue, IT > incident, an > infraction to a service level agreement (SLA), a system > compromise, socially engineered phishing attack, or a > denial-of-service (DoS) attack, etc. When an incident is > detected, or suspected, there may be a need for > organizations to > collaborate. This collaboration effort may take > several forms > including joint analysis, information dissemination, > and/or a > coordinated operational response. Examples of the > response may > include filing a report, notifying the source of the > incident, > requesting that a third party resolve/mitigate the > incident, > sharing indicators of compromise, or requesting that > the source > be located. The Incident Object Description Exchange > Format > (IODEF) defines an information framework to represent > computer > and network security incidents; IODEF is defined in > RFC 5070 and > has been extended by RFC 5091 to support phishing > reports; RFC > 6484 provides a template for defining extensions to IODEF. > Real-time Inter-network Defense (RID) defines a > protocol to > facilitate sharing computer and network security > incidents; > RID is defined in RFC 6545, and RID over HTTPS is > defined in RFC > 6546. > > > > This working group does two things IODEF and RID; we > should be clear > about that and then list the actual documents we're > going to produce > that relate to each one. For the list of deliverables > it looks like > there's three 5070bis, a reference/guidance draft, and a > resource-oriented indicator exchange? > > Questions: > > Are the GRC and Forensic drafts dead-dead? I assume > they'd not be > included in the milestone list. > > Is there going to only be one 5070bis draft or will > there be a > 5070bis + > other optional extension drafts? I assume it's just a > 5070bis > based on > the milestones but thought I'd ask. > > Are we only extending IODEF based on use or is there > something > else we > need to consider? > > How about something along the lines of (need some help > filling > in the > blanks): > > > > With respect to IODEF, the working group will: > > - Revise the IODEF document to incorporate > enhancements and > extensions based on operational experience; use by > Computer > Security Incident Response Teams (CSIRTs) and others has > exposed the need to extend IODEF to support x, y, z > (need to have > some idea what's missing) base on a, b, c (need to > know a bit > more about why stuff is missing did something new pop > up?). > > - Provide guidance on the implementation and use of > IODEF to aid > implementers in developing interoperable specifications. > > > > For RID: > > Are we also doing defining guidance for RID as well or > is that > incorporated in the IODEF guidance? > > Is RID itself going to be untouched and we're just > producing a new > "transport"? > > Is it just for indicators or is it for the whole > incident? Or has > "indicators" over taken "incident"? > > > > With respect to RID, the working group will: > > - Define a resource-oriented approach to cyber security > information sharing that follows the REST > architectural style. > This mechanism will allow CSIRTS to be more dynamic > and agile in > collaborating with a broader, and varying constituency. > > > > > > These looked fine, but I'd like some actual dates for > the TBDs ;) > > > > spt > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From pkampana@cisco.com Tue Jun 4 15:24:31 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6321F99CA for ; Tue, 4 Jun 2013 15:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhhne4p2gvid for ; Tue, 4 Jun 2013 15:24:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3821F99D3 for ; Tue, 4 Jun 2013 15:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52912; q=dns/txt; s=iport; t=1370384651; x=1371594251; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QjEXJUMrfz5+ewuLkwHimQ6EgkCNSAczDI97P2813F8=; b=L5rhP7OrXtSQd0wFFYY2DZniJfAoxY+yfL4Gb4YJSq1p0RBnWD3FrxxM soqiLEnk/jDBLp3S/0ixj9qsuhGAxLVLnACV3aUZZerJuQBLlNwjEXFMr 8NZeuZD4c0CKeUYmCcv/gdKXIIZ5q+fQNQkrmX/bt+8P/EtslGQpul1NZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAElorlGtJV2b/2dsb2JhbABQBwOCRUQwvyl9FnSCIwEBAQQBAQEXExwlBBcCAQgHCgMBAQELFgEGBycLFAkIAQEEARIIDId5DL1hjWiBCyABDAoBEYJpYQOTbZUSgw+CJw X-IronPort-AV: E=Sophos;i="4.87,802,1363132800"; d="scan'208,217";a="218824286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jun 2013 22:24:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r54MO9qX014623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 22:24:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 17:24:09 -0500 From: "Panos Kampanakis (pkampana)" To: "Kent_Landfield@McAfee.com" , "turners@ieca.com" , "mile@ietf.org" Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gP/+FmCg Date: Tue, 4 Jun 2013 22:24:09 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753C6F74@xmb-rcd-x10.cisco.com> References: <51ACD2B4.1060205@ieca.com> <3CBA099FBA0AB843895D72474092B8CF273329@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF273329@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.113] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753C6F74xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:24:31 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753C6F74xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The charter looks good to me. Kent, A clarification. Would the doc you are suggesting be different of what Kath= leen had in the charter "Provide guidance on the implementation and use of = RID transports based on use cases. The guidance document will show the relationship betwe= en transport options (RID + RID transport and IODEF/RID + ROLIE) and may id= entify the need for additional transport bindings." Or did you have somethi= ng similar in mind? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, June 03, 2013 2:10 PM To: turners@ieca.com; mile@ietf.org Subject: Re: [mile] re-charter re-boot I have no problem with the revised charter as is but I think there is somet= hing missing. It would be good to have as a milestone a document that desc= ribed use cases for these protocols. I rather see this separated out since= we are in a situation now of addressing the transport (RID) , the data mod= el for exchange (IODEF) and query/reporting capabilities (ROLIE). We need = to tie the three together and a document such as this would help lay a foun= dation for usage in multiple areas. FWIW... Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in= this space right now as you all know. I took Sean's suggested content and= updated it to reflect some of the activity and drivers for additional work= in MILE. Several people have mentioned an interest in submitting extensio= ns based on their current work, some in virtualized environments, some for = indicator specific formats, some industry specific extensions, etc. There = is also work developing by other groups who have mentioned that they will t= ransition their work to an international standards body once it is mature, = so room has been left in the charter to accommodate that work. The need fo= r guidance on the transport options has surfaced so that implementers under= stand when they may choose a specific transport option to enable interopera= ble interfaces between products. The guidance may be use case specific whe= re tighter security is needed (RID +HTTP/TLS with the object level security= options enab led) or w here ease of access is the driver (ROLIE) with no client requirements neces= sary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@iet= f.org] On Behalf Of Sean Turner [turners@ieca= .com] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more and there's some repetition that's unneeded. I also think it's a little open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-related work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be clear about that and then list the actual documents we're going to produce that relate to each one. For the list of deliverables it looks like there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_1C9F17D1873AFA47A969C4DD98F98A753C6F74xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The charter looks good to= me.

 <= /p>

Kent,

A clarification. Would th= e doc you are suggesting be different of what Kathleen had in the charter &= #8220;Provide guidance on the implementation and use of RID transports

based on use cases. = ; The guidance document will show the relationship between transport o= ptions (RID + RID transport and IODEF/RID + ROLIE) and may identify= the need for additional transport bindings.” Or did you have something similar in mind?

 <= /p>

Rgs,

Panos

 <= /p>

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, June 03, 2013 2:10 PM
To: turners@ieca.com; mile@ietf.org
Subject: Re: [mile] re-charter re-boot

 

I have no problem with t= he revised charter as is but I think there is something missing.  It w= ould be good to have as a milestone a document that described use cases for= these protocols.  I rather see this separated out since we are in a situation now of addressing the transport (RID) , th= e data model for exchange (IODEF) and query/reporting capabilities (ROLIE).=  We need to tie the three together and a document such as this would = help lay a foundation for usage in multiple areas.

 =

FWIW…

 =

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096  Mobile: +1.817.637.8026
Web: www.mcafee.com

 =

From: Sean Turner <turners@ieca.com>
Date: Monday, June 3, 2013 12:30 PM
To: "mile@ietf.org" &= lt;mile@ietf.org>
Subject: Re: [mile] re-charter re-boot

 =

Comments from anybody el= se?

 =

spt

 =

On 5/25/13 9:11 AM, Mori= arty, Kathleen wrote:

Hi,

 =

Sorry for the delay in u= pdating the charter.  There is a lot of activity in this space ri= ght now as you all know.  I took Sean's suggested content and upd= ated it to reflect some of the activity and drivers for additional work in MILE.  Several people have mentioned an inter= est in submitting extensions based on their current work, some in virtualiz= ed environments, some for indicator specific formats, some industry specifi= c extensions, etc.  There is also work developing by other groups who have mentioned that they will transition their work to= an international standards body once it is mature, so room has been left i= n the charter to accommodate that work.  The need for guidance on= the transport options has surfaced so that implementers understand when they may choose a specific transport option t= o enable interoperable interfaces between products.  The guidance= may be use case specific where tighter security is needed (RID +HTTP/T= LS with the object level security options enab

led) or w

here ease of access is t= he driver (ROLIE) with no client requirements necessary (can use a browser)= .

 =

We will follow up with t= he mile stones, here the the re-write:

 =

<intro>=

 =

The Managed Incident Lig= htweight Exchange (MILE) working group

develops standards to su= pport computer and network security

incident management; an = incident is an unplanned event that

occurs in an information= technology (IT) infrastructure. An

incident could be a beni= gn configuration issue, IT incident, an

infraction to a service = level agreement (SLA), a system

compromise, socially eng= ineered phishing attack, or a

denial-of-service (DoS) = attack, etc.  When an incident is

detected, or suspected, = there may be a need for organizations to

collaborate. This collab= oration effort may take several forms

including joint analysis= , information dissemination, and/or a

coordinated operational = response.  Examples of the response may

include filing a report,= notifying the source of the incident,

requesting that a third = party resolve/mitigate the incident,

sharing select indicator= s of compromise, or requesting that the

source be located. By sh= aring indicators of compromise associated

with an incident or poss= ible threat, the information becomes a

proactive defense for ot= hers that may include mitigation options.

The Incident Object Desc= ription Exchange Format (IODEF) defines

an information framework= to represent computer and network

security incidents; IODE= F is defined in RFC 5070 and

has been extended by RFC= 5091 to support phishing reports; RFC

6484 provides a template= for defining extensions to IODEF.

Real-time Inter-network = Defense (RID) defines a protocol to

facilitate sharing compu= ter and network security incidents;

RID is defined in RFC 65= 45, and RID over HTTPS is defined in RFC

6546.<= /p>

 =

</intro>

 =

The MILE WG is focused o= n two areas, IODEF the data format and

extensions to represent = incident and indicator data and RID,

the policy and transport= for structured data.  With respect to

IODEF, the working group= will:

 =

- Revise the IODEF docum= ent to incorporate enhancements and

extensions based on oper= ational experience; use by Computer

Security Incident Respon= se Teams (CSIRTs) and others has

exposed the need to exte= nd IODEF to support industry specific

extensions, use case spe= cific content, and representations to

associate information re= lated to represented threats (system,

threat actors, campaigns= , etc.).  The value of information

sharing has been demonst= rated and highlighted at an increasing

rate through the success= of the Information Sharing and

Analysis Centers (ISACs)= and the recent cyber security Executive

Order in the US. &n= bsp;International groups, such as the Multinational

Association for Collabor= ative Cyber Situational Awareness (CCSA)

have been running experi= ments to determine what data is useful to

exchange between industr= ies and nations to effectively mitigate

threats.  The = work of these and other groups have identified or

are working to develop d= ata representations relevant to their use

cases that may complimen= t/extend IODEF or be useful to exchange

using RID and related tr= ansport protocols.

 =

- Provide guidance on th= e implementation and use of IODEF to aid

implementers in developi= ng interoperable specifications.

 =

With respect to RID, the= working group will:

 =

- Define a resource-orie= nted approach to cyber security

information sharing that= follows the REST architectural style.

This mechanism will allo= w CSIRTS to be more dynamic and agile in

collaborating with a bro= ader, and varying constituency.

 =

- Provide guidance on th= e implementation and use of RID transports

based on use cases. = ; The guidance document will show the relationship

between transport option= s (RID + RID transport and IODEF/RID + ROLIE)

and may identify the nee= d for additional transport bindings.

 =

- RID may require modifi= cations to address data provenance, additional

policy options, or other= changes now that there are multiple

interoperable implementa= tions of RFC6545 and RFC6546.  With the

RID implementations in t= he open source community, increased use and

experimentation may demo= nstrate the need for a revision.

 =

<milestones><= /o:p>

 =

</milestones>=

 =

 =

Thank you!

Kathleen

 =

________________________= ________________

Sent: Wednesday, May 01,= 2013 9:04 PM

Subject: [mile] re-chart= er re-boot

 =

Hi,

 =

I'd like to propose a si= gnificant re-write of the proposed charter.  I<= /p>

think there's too much h= istory that's not really needed any more and

there's some repetition = that's unneeded.  I also think it's a little

open ended wrt what's ac= tually going to get done. Based on recent

experience, I have a str= ong feeling that the current charter wouldn't

get through the process.=

 =

I'm proposing four secti= ons: intro, iodef-related work, rid-related

work, milestones.

 =

The intro should:

 =

- explain what the WG do= es: develop standards to do foo.

- summarize what foo is.=

- highlight existing RFC= s that are part of the space:

    = IODEF: 5070/5091/6848 & RID: 6545/6546.

 =

Then we talk about what = drafts the WG will produce for the two topic areas.

 =

How about this (or somet= hing like this):

 =

<intro>=

 =

The Managed Incident Lig= htweight Exchange (MILE) working group

develops standards to su= pport computer and network security

incident management; an = incident is an unplanned event that

occurs in an information= technology (IT) infrastructure. An

incident could be a beni= gn configuration issue, IT incident, an

infraction to a service = level agreement (SLA), a system

compromise, socially eng= ineered phishing attack, or a

denial-of-service (DoS) = attack, etc.  When an incident is

detected, or suspected, = there may be a need for organizations to

collaborate. This collab= oration effort may take several forms

including joint analysis= , information dissemination, and/or a

coordinated operational = response.  Examples of the response may

include filing a report,= notifying the source of the incident,

requesting that a third = party resolve/mitigate the incident,

sharing indicators of co= mpromise, or requesting that the source

be located. The Incident= Object Description Exchange Format

(IODEF) defines an infor= mation framework to represent computer

and network security inc= idents; IODEF is defined in RFC 5070 and

has been extended by RFC= 5091 to support phishing reports; RFC

6484 provides a template= for defining extensions to IODEF.

Real-time Inter-network = Defense (RID) defines a protocol to

facilitate sharing compu= ter and network security incidents;

RID is defined in RFC 65= 45, and RID over HTTPS is defined in RFC

6546.<= /p>

 =

</into>=

 =

This working group does = two things IODEF and RID; we should be clear

about that and then list= the actual documents we're going to produce

that relate to each one.=   For the list of deliverables it looks like

there's three 5070bis, a= reference/guidance draft, and a

resource-oriented indica= tor exchange?

 =

Questions:

 =

Are the GRC and Forensic= drafts dead-dead?  I assume they'd not be

included in the mileston= e list.

 =

Is there going to only b= e one 5070bis draft or will there be a 5070bis +

other optional extension= drafts?  I assume it's just a 5070bis based on=

the milestones but thoug= ht I'd ask.

 =

Are we only extending IO= DEF based on use or is there something else we

need to consider?

 =

How about something alon= g the lines of (need some help filling in the

blanks):

 =

<iodef>=

 =

With respect to IODEF, t= he working group will:

 =

- Revise the IODEF docum= ent to incorporate enhancements and

extensions based on oper= ational experience; use by Computer

Security Incident Respon= se Teams (CSIRTs) and others has

exposed the need to exte= nd IODEF to support x, y, z (need to have

some idea what's missing= ) base on a, b, c (need to know a bit

more about why stuff is = missing did something new pop up?).

 =

- Provide guidance on th= e implementation and use of IODEF to aid

implementers in developi= ng interoperable specifications.

 =

</iodef>

 =

For RID:

 =

Are we also doing defini= ng guidance for RID as well or is that

incorporated in the IODE= F guidance?

 =

Is RID itself going to b= e untouched and we're just producing a new

"transport"?

 =

Is it just for indicator= s or is it for the whole incident?  Or has

"indicators" o= ver taken "incident"?

 =

<rid>

 =

With respect to RID, the= working group will:

 =

- Define a resource-orie= nted approach to cyber security

information sharing that= follows the REST architectural style.

This mechanism will allo= w CSIRTS to be more dynamic and agile in

collaborating with a bro= ader, and varying constituency.

 =

</rid><= /span>

 =

<milestones><= /o:p>

 =

These looked fine, but I= 'd like some actual dates for the TBDs ;)

 =

</milestones>=

 =

spt

________________________= _______________________

mile mailing list

 =

________________________= _______________________

mile mailing list

 =

--_000_1C9F17D1873AFA47A969C4DD98F98A753C6F74xmbrcdx10ciscocom_-- From Kent_Landfield@mcafee.com Tue Jun 4 16:15:28 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7522B21F9695 for ; Tue, 4 Jun 2013 16:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgOuMTgj81tO for ; Tue, 4 Jun 2013 16:15:24 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 98DB021F961B for ; Tue, 4 Jun 2013 16:15:20 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 1f99_b514_1de98e60_67f3_44f9_8c7a_f79279e01816; Tue, 04 Jun 2013 18:15:10 -0500 Received: from MIVEXEMEA1N2.corp.nai.org (10.48.48.32) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 4 Jun 2013 19:14:52 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N2.corp.nai.org ([169.254.2.69]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 19:14:52 -0400 From: To: , , Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gP/+FmCggAPRHwA= Date: Tue, 4 Jun 2013 23:14:51 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF27B988@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753C6F74@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF27B988MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:15:28 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF27B988MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Panos, I was expecting that to be more of a proper use of the specifications and s= pecification integration document and not an overview of the higher level u= ses cases of the area these protocols are supporting. If I am wrong then I= would love to hear it. If someone has volunteered to be the author for th= at mile(stone) could they please clarify? If what I am considering is alre= ady covered then I am good. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Panos Kampanakis (pkampana)" > Date: Tuesday, June 4, 2013 5:24 PM To: Kent Landfield >, Sean Turner >, "mile@ietf.= org" > Subject: RE: [mile] re-charter re-boot The charter looks good to me. Kent, A clarification. Would the doc you are suggesting be different of what Kath= leen had in the charter =93Provide guidance on the implementation and use o= f RID transports based on use cases. The guidance document will show the relationship betwe= en transport options (RID + RID transport and IODEF/RID + ROLIE) and may id= entify the need for additional transport bindings.=94 Or did you have somet= hing similar in mind? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, June 03, 2013 2:10 PM To: turners@ieca.com; mile@ietf.org Subject: Re: [mile] re-charter re-boot I have no problem with the revised charter as is but I think there is somet= hing missing. It would be good to have as a milestone a document that desc= ribed use cases for these protocols. I rather see this separated out since= we are in a situation now of addressing the transport (RID) , the data mod= el for exchange (IODEF) and query/reporting capabilities (ROLIE). We need = to tie the three together and a document such as this would help lay a foun= dation for usage in multiple areas. FWIW=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in= this space right now as you all know. I took Sean's suggested content and= updated it to reflect some of the activity and drivers for additional work= in MILE. Several people have mentioned an interest in submitting extensio= ns based on their current work, some in virtualized environments, some for = indicator specific formats, some industry specific extensions, etc. There = is also work developing by other groups who have mentioned that they will t= ransition their work to an international standards body once it is mature, = so room has been left in the charter to accommodate that work. The need fo= r guidance on the transport options has surfaced so that implementers under= stand when they may choose a specific transport option to enable interopera= ble interfaces between products. The guidance may be use case specific whe= re tighter security is needed (RID +HTTP/TLS with the object level security= options enab led) or w here ease of access is the driver (ROLIE) with no client requirements neces= sary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@iet= f.org] On Behalf Of Sean Turner [turners@ieca= .com] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more and there's some repetition that's unneeded. I also think it's a little open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-related work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be clear about that and then list the actual documents we're going to produce that relate to each one. For the list of deliverables it looks like there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF27B988MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C25324126F548429D706828E170ED14@McAfee.com> Content-Transfer-Encoding: quoted-printable

From: "Panos Kampanakis (pkamp= ana)" <pkampana@cisco.com= >
Date: Tuesday, June 4, 2013 5:24 PM=
To: Kent Landfield <Kent_Landfield@McAfee.com>, Sean Tu= rner <turners@ieca.com>, &quo= t;mile@ietf.org" <mile@ietf.org>
Subject: RE: [mile] re-charter re-b= oot

The charter looks good to me.=

 

Kent,

A clarification. Would the doc you= are suggesting be different of what Kathleen had in the charter =93= Provide guidance on the implementation and use of RID transports

based on use cases. = ; The guidance document will show the relationship between transport o= ptions (RID + RID transport and IODEF/RID + ROLIE) and may identify= the need for additional transport bindings.=94 Or did you have something similar in mind?

 

Rgs,

Panos

 

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Monday, June 03, 2013 2:10 PM
To: turners@ieca.com; mile@ietf.org
Subject: Re: [mile] re-charter re-boot

 

I have no problem with t= he revised charter as is but I think there is something missing.  It w= ould be good to have as a milestone a document that described use cases for= these protocols.  I rather see this separated out since we are in a situation now of addressing the transport (RID) , th= e data model for exchange (IODEF) and query/reporting capabilities (ROLIE).=  We need to tie the three together and a document such as this would = help lay a foundation for usage in multiple areas.

 =

FWIW=85

 =

Kent Landfield

McAfee | An Intel = Company
Direct: +1.972.963.7096  Mobile: +1.817.637.8026
Web: <= /strong>www.mcafee.com

 =

From: Sean Turner <turne= rs@ieca.com>
Date: Monday, June 3, 2013 12:30 PM
To: "mile@ietf.org" &= lt;mile@ietf.org>
Subject: Re: [mile] re-charter re-boot

 =

Comments from anybody el= se?

 =

spt

 =

On 5/25/13 9:11 AM, Mori= arty, Kathleen wrote:

Hi,

 =

Sorry for the delay in u= pdating the charter.  There is a lot of activity in this space ri= ght now as you all know.  I took Sean's suggested content and upd= ated it to reflect some of the activity and drivers for additional work in MILE.  Several people have mentioned an inter= est in submitting extensions based on their current work, some in virtualiz= ed environments, some for indicator specific formats, some industry specifi= c extensions, etc.  There is also work developing by other groups who have mentioned that they will transition their work to= an international standards body once it is mature, so room has been left i= n the charter to accommodate that work.  The need for guidance on= the transport options has surfaced so that implementers understand when they may choose a specific transport option t= o enable interoperable interfaces between products.  The guidance= may be use case specific where tighter security is needed (RID +HTTP/T= LS with the object level security options enab

led) or w

here ease of access is t= he driver (ROLIE) with no client requirements necessary (can use a browser)= .

 =

We will follow up with t= he mile stones, here the the re-write:

 =

<intro>=

 =

The Managed Incident Lig= htweight Exchange (MILE) working group

develops standards to su= pport computer and network security

incident management; an = incident is an unplanned event that

occurs in an information= technology (IT) infrastructure. An

incident could be a beni= gn configuration issue, IT incident, an

infraction to a service = level agreement (SLA), a system

compromise, socially eng= ineered phishing attack, or a

denial-of-service (DoS) = attack, etc.  When an incident is

detected, or suspected, = there may be a need for organizations to

collaborate. This collab= oration effort may take several forms

including joint analysis= , information dissemination, and/or a

coordinated operational = response.  Examples of the response may

include filing a report,= notifying the source of the incident,

requesting that a third = party resolve/mitigate the incident,

sharing select indicator= s of compromise, or requesting that the

source be located. By sh= aring indicators of compromise associated

with an incident or poss= ible threat, the information becomes a

proactive defense for ot= hers that may include mitigation options.

The Incident Object Desc= ription Exchange Format (IODEF) defines

an information framework= to represent computer and network

security incidents; IODE= F is defined in RFC 5070 and

has been extended by RFC= 5091 to support phishing reports; RFC

6484 provides a template= for defining extensions to IODEF.

Real-time Inter-network = Defense (RID) defines a protocol to

facilitate sharing compu= ter and network security incidents;

RID is defined in RFC 65= 45, and RID over HTTPS is defined in RFC

6546.<= /p>

 =

</intro>

 =

The MILE WG is focused o= n two areas, IODEF the data format and

extensions to represent = incident and indicator data and RID,

the policy and transport= for structured data.  With respect to

IODEF, the working group= will:

 =

- Revise the IODEF docum= ent to incorporate enhancements and

extensions based on oper= ational experience; use by Computer

Security Incident Respon= se Teams (CSIRTs) and others has

exposed the need to exte= nd IODEF to support industry specific

extensions, use case spe= cific content, and representations to

associate information re= lated to represented threats (system,

threat actors, campaigns= , etc.).  The value of information

sharing has been demonst= rated and highlighted at an increasing

rate through the success= of the Information Sharing and

Analysis Centers (ISACs)= and the recent cyber security Executive

Order in the US. &n= bsp;International groups, such as the Multinational

Association for Collabor= ative Cyber Situational Awareness (CCSA)

have been running experi= ments to determine what data is useful to

exchange between industr= ies and nations to effectively mitigate

threats.  The = work of these and other groups have identified or

are working to develop d= ata representations relevant to their use

cases that may complimen= t/extend IODEF or be useful to exchange

using RID and related tr= ansport protocols.

 =

- Provide guidance on th= e implementation and use of IODEF to aid

implementers in developi= ng interoperable specifications.

 =

With respect to RID, the= working group will:

 =

- Define a resource-orie= nted approach to cyber security

information sharing that= follows the REST architectural style.

This mechanism will allo= w CSIRTS to be more dynamic and agile in

collaborating with a bro= ader, and varying constituency.

 =

- Provide guidance on th= e implementation and use of RID transports

based on use cases. = ; The guidance document will show the relationship

between transport option= s (RID + RID transport and IODEF/RID + ROLIE)

and may identify the nee= d for additional transport bindings.

 =

- RID may require modifi= cations to address data provenance, additional

policy options, or other= changes now that there are multiple

interoperable implementa= tions of RFC6545 and RFC6546.  With the

RID implementations in t= he open source community, increased use and

experimentation may demo= nstrate the need for a revision.

 =

<milestones><= /o:p>

 =

</milestones>=

 =

 =

Thank you!

Kathleen

 =

________________________= ________________

Sent: Wednesday, May 01,= 2013 9:04 PM

Subject: [mile] re-chart= er re-boot

 =

Hi,

 =

I'd like to propose a si= gnificant re-write of the proposed charter.  I<= /p>

think there's too much h= istory that's not really needed any more and

there's some repetition = that's unneeded.  I also think it's a little

open ended wrt what's ac= tually going to get done. Based on recent

experience, I have a str= ong feeling that the current charter wouldn't

get through the process.=

 =

I'm proposing four secti= ons: intro, iodef-related work, rid-related

work, milestones.

 =

The intro should:

 =

- explain what the WG do= es: develop standards to do foo.

- summarize what foo is.=

- highlight existing RFC= s that are part of the space:

    = IODEF: 5070/5091/6848 & RID: 6545/6546.

 =

Then we talk about what = drafts the WG will produce for the two topic areas.

 =

How about this (or somet= hing like this):

 =

<intro>=

 =

The Managed Incident Lig= htweight Exchange (MILE) working group

develops standards to su= pport computer and network security

incident management; an = incident is an unplanned event that

occurs in an information= technology (IT) infrastructure. An

incident could be a beni= gn configuration issue, IT incident, an

infraction to a service = level agreement (SLA), a system

compromise, socially eng= ineered phishing attack, or a

denial-of-service (DoS) = attack, etc.  When an incident is

detected, or suspected, = there may be a need for organizations to

collaborate. This collab= oration effort may take several forms

including joint analysis= , information dissemination, and/or a

coordinated operational = response.  Examples of the response may

include filing a report,= notifying the source of the incident,

requesting that a third = party resolve/mitigate the incident,

sharing indicators of co= mpromise, or requesting that the source

be located. The Incident= Object Description Exchange Format

(IODEF) defines an infor= mation framework to represent computer

and network security inc= idents; IODEF is defined in RFC 5070 and

has been extended by RFC= 5091 to support phishing reports; RFC

6484 provides a template= for defining extensions to IODEF.

Real-time Inter-network = Defense (RID) defines a protocol to

facilitate sharing compu= ter and network security incidents;

RID is defined in RFC 65= 45, and RID over HTTPS is defined in RFC

6546.<= /p>

 =

</into>=

 =

This working group does = two things IODEF and RID; we should be clear

about that and then list= the actual documents we're going to produce

that relate to each one.=   For the list of deliverables it looks like

there's three 5070bis, a= reference/guidance draft, and a

resource-oriented indica= tor exchange?

 =

Questions:

 =

Are the GRC and Forensic= drafts dead-dead?  I assume they'd not be

included in the mileston= e list.

 =

Is there going to only b= e one 5070bis draft or will there be a 5070bis +

other optional extension= drafts?  I assume it's just a 5070bis based on=

the milestones but thoug= ht I'd ask.

 =

Are we only extending IO= DEF based on use or is there something else we

need to consider?

 =

How about something alon= g the lines of (need some help filling in the

blanks):

 =

<iodef>=

 =

With respect to IODEF, t= he working group will:

 =

- Revise the IODEF docum= ent to incorporate enhancements and

extensions based on oper= ational experience; use by Computer

Security Incident Respon= se Teams (CSIRTs) and others has

exposed the need to exte= nd IODEF to support x, y, z (need to have

some idea what's missing= ) base on a, b, c (need to know a bit

more about why stuff is = missing did something new pop up?).

 =

- Provide guidance on th= e implementation and use of IODEF to aid

implementers in developi= ng interoperable specifications.

 =

</iodef>

 =

For RID:

 =

Are we also doing defini= ng guidance for RID as well or is that

incorporated in the IODE= F guidance?

 =

Is RID itself going to b= e untouched and we're just producing a new

"transport"?

 =

Is it just for indicator= s or is it for the whole incident?  Or has

"indicators" o= ver taken "incident"?

 =

<rid>

 =

With respect to RID, the= working group will:

 =

- Define a resource-orie= nted approach to cyber security

information sharing that= follows the REST architectural style.

This mechanism will allo= w CSIRTS to be more dynamic and agile in

collaborating with a bro= ader, and varying constituency.

 =

</rid><= /span>

 =

<milestones><= /o:p>

 =

These looked fine, but I= 'd like some actual dates for the TBDs ;)

 =

</milestones>=

 =

spt

________________________= _______________________

mile mailing list

 =

________________________= _______________________

mile mailing list

 =

--_000_3CBA099FBA0AB843895D72474092B8CF27B988MIVEXAMER1N1corpn_-- From eburger@standardstrack.com Tue Jun 4 17:17:57 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C75521F9A1F for ; Tue, 4 Jun 2013 17:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrfthchpFmBz for ; Tue, 4 Jun 2013 17:17:50 -0700 (PDT) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 7608821F99EF for ; Tue, 4 Jun 2013 17:17:49 -0700 (PDT) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo203.cox.net (InterMail vM.8.01.05.09 201-2260-151-124-20120717) with ESMTP id <20130605001748.YYJY32441.eastrmfepo203.cox.net@eastrmimpo109> for ; Tue, 4 Jun 2013 20:17:48 -0400 Received: from [192.168.15.185] ([68.100.196.226]) by eastrmimpo109 with cox id kQHm1l00c4tZXYL01QHnuN; Tue, 04 Jun 2013 20:17:47 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020206.51AE83AC.006D,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=Dv2IDhD+ c=1 sm=1 a=LRAQgwvtMCh7If29pmo3fQ==:17 a=LVt4adaPwu8A:10 a=jRG3T-manTQA:10 a=bfLuiRfvAAAA:8 a=t4cpZhVfoXkA:10 a=SyYMxH9GAAAA:8 a=AUd_NHdVAAAA:8 a=o4D-YMODAAAA:8 a=48vgC7mUAAAA:8 a=ZdxPNSakWusLO5hPzuMA:9 a=pILNOxqGKmIA:10 a=XT4B79g8RrEA:10 a=hz29XmwHSwYA:10 a=YbOTLnh8yesA:10 a=JfD0Fch1gWkA:10 a=De4saq_zUVgA:10 a=lZB815dzVvQA:10 a=GzShEoVyDsv8N6ez:21 a=xP1B2W0iDdyIGeFo:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Rph6jCT_A9-MY9y7koIA:9 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=hYXcVy-54cCYMS_M:21 a=LRAQgwvtMCh7If29pmo3fQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (PLAIN) smtp.auth=ewburger@cox.net From: Eric Burger Content-Type: multipart/alternative; boundary="Apple-Mail=_20EA5441-CFFC-4155-9526-849E9A972AC3" Message-Id: <1513DCD0-0332-4FA9-8DC2-7090384D6425@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Tue, 4 Jun 2013 20:17:47 -0400 References: <3CBA099FBA0AB843895D72474092B8CF27B988@MIVEXAMER1N1.corp.nai.org> To: "mile@ietf.org IETF" In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF27B988@MIVEXAMER1N1.corp.nai.org> X-Mailer: Apple Mail (2.1503) Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 00:17:57 -0000 --Apple-Mail=_20EA5441-CFFC-4155-9526-849E9A972AC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What is really missing, but I am not sure it belongs as a work group = document, is a requirements document for the protocol and markup itself. = The only thing I could find was RFC 3067. However, those were = requirements for a specific network operator with specific needs. On Jun 4, 2013, at 7:14 PM, kent_landfield@mcafee.com wrote: > Hi Panos, >=20 > I was expecting that to be more of a proper use of the specifications = and specification integration document and not an overview of the higher = level uses cases of the area these protocols are supporting. If I am = wrong then I would love to hear it. If someone has volunteered to be = the author for that mile(stone) could they please clarify? If what I am = considering is already covered then I am good. ;-) >=20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com >=20 > From: "Panos Kampanakis (pkampana)" > Date: Tuesday, June 4, 2013 5:24 PM > To: Kent Landfield , Sean Turner = , "mile@ietf.org" > Subject: RE: [mile] re-charter re-boot >=20 >> The charter looks good to me. >> =20 >> Kent, >> A clarification. Would the doc you are suggesting be different of = what Kathleen had in the charter =93Provide guidance on the = implementation and use of RID transports >> based on use cases. The guidance document will show the relationship = between transport options (RID + RID transport and IODEF/RID + ROLIE) = and may identify the need for additional transport bindings.=94 Or did = you have something similar in mind? >> =20 >> Rgs, >> Panos >> =20 >> =20 >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Kent_Landfield@McAfee.com >> Sent: Monday, June 03, 2013 2:10 PM >> To: turners@ieca.com; mile@ietf.org >> Subject: Re: [mile] re-charter re-boot >> =20 >> I have no problem with the revised charter as is but I think there is = something missing. It would be good to have as a milestone a document = that described use cases for these protocols. I rather see this = separated out since we are in a situation now of addressing the = transport (RID) , the data model for exchange (IODEF) and = query/reporting capabilities (ROLIE). We need to tie the three together = and a document such as this would help lay a foundation for usage in = multiple areas. >> =20 >> FWIW=85 >> =20 >> Kent Landfield >>=20 >> McAfee | An Intel Company >> Direct: +1.972.963.7096=20 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >> =20 >> From: Sean Turner >> Date: Monday, June 3, 2013 12:30 PM >> To: "mile@ietf.org" >> Subject: Re: [mile] re-charter re-boot >> =20 >>> Comments from anybody else? >>> =20 >>> spt >>> =20 >>> On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: >>>> Hi, >>>> =20 >>>> Sorry for the delay in updating the charter. There is a lot of = activity in this space right now as you all know. I took Sean's = suggested content and updated it to reflect some of the activity and = drivers for additional work in MILE. Several people have mentioned an = interest in submitting extensions based on their current work, some in = virtualized environments, some for indicator specific formats, some = industry specific extensions, etc. There is also work developing by = other groups who have mentioned that they will transition their work to = an international standards body once it is mature, so room has been left = in the charter to accommodate that work. The need for guidance on the = transport options has surfaced so that implementers understand when they = may choose a specific transport option to enable interoperable = interfaces between products. The guidance may be use case specific = where tighter security is needed (RID +HTTP/TLS with the object level = security options enab >>> led) or w >>> here ease of access is the driver (ROLIE) with no client = requirements necessary (can use a browser). >>>> =20 >>>> We will follow up with the mile stones, here the the re-write: >>>> =20 >>>> >>>> =20 >>>> The Managed Incident Lightweight Exchange (MILE) working group >>>> develops standards to support computer and network security >>>> incident management; an incident is an unplanned event that >>>> occurs in an information technology (IT) infrastructure. An >>>> incident could be a benign configuration issue, IT incident, an >>>> infraction to a service level agreement (SLA), a system >>>> compromise, socially engineered phishing attack, or a >>>> denial-of-service (DoS) attack, etc. When an incident is >>>> detected, or suspected, there may be a need for organizations to >>>> collaborate. This collaboration effort may take several forms >>>> including joint analysis, information dissemination, and/or a >>>> coordinated operational response. Examples of the response may >>>> include filing a report, notifying the source of the incident, >>>> requesting that a third party resolve/mitigate the incident, >>>> sharing select indicators of compromise, or requesting that the >>>> source be located. By sharing indicators of compromise associated >>>> with an incident or possible threat, the information becomes a >>>> proactive defense for others that may include mitigation options. >>>> The Incident Object Description Exchange Format (IODEF) defines >>>> an information framework to represent computer and network >>>> security incidents; IODEF is defined in RFC 5070 and >>>> has been extended by RFC 5091 to support phishing reports; RFC >>>> 6484 provides a template for defining extensions to IODEF. >>>> Real-time Inter-network Defense (RID) defines a protocol to >>>> facilitate sharing computer and network security incidents; >>>> RID is defined in RFC 6545, and RID over HTTPS is defined in RFC >>>> 6546. >>>> =20 >>>> >>>> =20 >>>> The MILE WG is focused on two areas, IODEF the data format and >>>> extensions to represent incident and indicator data and RID, >>>> the policy and transport for structured data. With respect to >>>> IODEF, the working group will: >>>> =20 >>>> - Revise the IODEF document to incorporate enhancements and >>>> extensions based on operational experience; use by Computer >>>> Security Incident Response Teams (CSIRTs) and others has >>>> exposed the need to extend IODEF to support industry specific >>>> extensions, use case specific content, and representations to >>>> associate information related to represented threats (system, >>>> threat actors, campaigns, etc.). The value of information >>>> sharing has been demonstrated and highlighted at an increasing >>>> rate through the success of the Information Sharing and >>>> Analysis Centers (ISACs) and the recent cyber security Executive >>>> Order in the US. International groups, such as the Multinational >>>> Association for Collaborative Cyber Situational Awareness (CCSA) >>>> have been running experiments to determine what data is useful to >>>> exchange between industries and nations to effectively mitigate >>>> threats. The work of these and other groups have identified or >>>> are working to develop data representations relevant to their use >>>> cases that may compliment/extend IODEF or be useful to exchange >>>> using RID and related transport protocols. >>>> =20 >>>> - Provide guidance on the implementation and use of IODEF to aid >>>> implementers in developing interoperable specifications. >>>> =20 >>>> With respect to RID, the working group will: >>>> =20 >>>> - Define a resource-oriented approach to cyber security >>>> information sharing that follows the REST architectural style. >>>> This mechanism will allow CSIRTS to be more dynamic and agile in >>>> collaborating with a broader, and varying constituency. >>>> =20 >>>> - Provide guidance on the implementation and use of RID transports >>>> based on use cases. The guidance document will show the = relationship >>>> between transport options (RID + RID transport and IODEF/RID + = ROLIE) >>>> and may identify the need for additional transport bindings. >>>> =20 >>>> - RID may require modifications to address data provenance, = additional >>>> policy options, or other changes now that there are multiple >>>> interoperable implementations of RFC6545 and RFC6546. With the >>>> RID implementations in the open source community, increased use and >>>> experimentation may demonstrate the need for a revision. >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> =20 >>>> Thank you! >>>> Kathleen >>>> =20 >>>> ________________________________________ >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Sean Turner [turners@ieca.com] >>>> Sent: Wednesday, May 01, 2013 9:04 PM >>>> To: mile@ietf.org >>>> Subject: [mile] re-charter re-boot >>>> =20 >>>> Hi, >>>> =20 >>>> I'd like to propose a significant re-write of the proposed charter. = I >>>> think there's too much history that's not really needed any more = and >>>> there's some repetition that's unneeded. I also think it's a = little >>>> open ended wrt what's actually going to get done. Based on recent >>>> experience, I have a strong feeling that the current charter = wouldn't >>>> get through the process. >>>> =20 >>>> I'm proposing four sections: intro, iodef-related work, rid-related >>>> work, milestones. >>>> =20 >>>> The intro should: >>>> =20 >>>> - explain what the WG does: develop standards to do foo. >>>> - summarize what foo is. >>>> - highlight existing RFCs that are part of the space: >>>> IODEF: 5070/5091/6848 & RID: 6545/6546. >>>> =20 >>>> Then we talk about what drafts the WG will produce for the two = topic areas. >>>> =20 >>>> How about this (or something like this): >>>> =20 >>>> >>>> =20 >>>> The Managed Incident Lightweight Exchange (MILE) working group >>>> develops standards to support computer and network security >>>> incident management; an incident is an unplanned event that >>>> occurs in an information technology (IT) infrastructure. An >>>> incident could be a benign configuration issue, IT incident, an >>>> infraction to a service level agreement (SLA), a system >>>> compromise, socially engineered phishing attack, or a >>>> denial-of-service (DoS) attack, etc. When an incident is >>>> detected, or suspected, there may be a need for organizations to >>>> collaborate. This collaboration effort may take several forms >>>> including joint analysis, information dissemination, and/or a >>>> coordinated operational response. Examples of the response may >>>> include filing a report, notifying the source of the incident, >>>> requesting that a third party resolve/mitigate the incident, >>>> sharing indicators of compromise, or requesting that the source >>>> be located. The Incident Object Description Exchange Format >>>> (IODEF) defines an information framework to represent computer >>>> and network security incidents; IODEF is defined in RFC 5070 and >>>> has been extended by RFC 5091 to support phishing reports; RFC >>>> 6484 provides a template for defining extensions to IODEF. >>>> Real-time Inter-network Defense (RID) defines a protocol to >>>> facilitate sharing computer and network security incidents; >>>> RID is defined in RFC 6545, and RID over HTTPS is defined in RFC >>>> 6546. >>>> =20 >>>> >>>> =20 >>>> This working group does two things IODEF and RID; we should be = clear >>>> about that and then list the actual documents we're going to = produce >>>> that relate to each one. For the list of deliverables it looks = like >>>> there's three 5070bis, a reference/guidance draft, and a >>>> resource-oriented indicator exchange? >>>> =20 >>>> Questions: >>>> =20 >>>> Are the GRC and Forensic drafts dead-dead? I assume they'd not be >>>> included in the milestone list. >>>> =20 >>>> Is there going to only be one 5070bis draft or will there be a = 5070bis + >>>> other optional extension drafts? I assume it's just a 5070bis = based on >>>> the milestones but thought I'd ask. >>>> =20 >>>> Are we only extending IODEF based on use or is there something else = we >>>> need to consider? >>>> =20 >>>> How about something along the lines of (need some help filling in = the >>>> blanks): >>>> =20 >>>> >>>> =20 >>>> With respect to IODEF, the working group will: >>>> =20 >>>> - Revise the IODEF document to incorporate enhancements and >>>> extensions based on operational experience; use by Computer >>>> Security Incident Response Teams (CSIRTs) and others has >>>> exposed the need to extend IODEF to support x, y, z (need to have >>>> some idea what's missing) base on a, b, c (need to know a bit >>>> more about why stuff is missing did something new pop up?). >>>> =20 >>>> - Provide guidance on the implementation and use of IODEF to aid >>>> implementers in developing interoperable specifications. >>>> =20 >>>> >>>> =20 >>>> For RID: >>>> =20 >>>> Are we also doing defining guidance for RID as well or is that >>>> incorporated in the IODEF guidance? >>>> =20 >>>> Is RID itself going to be untouched and we're just producing a new >>>> "transport"? >>>> =20 >>>> Is it just for indicators or is it for the whole incident? Or has >>>> "indicators" over taken "incident"? >>>> =20 >>>> >>>> =20 >>>> With respect to RID, the working group will: >>>> =20 >>>> - Define a resource-oriented approach to cyber security >>>> information sharing that follows the REST architectural style. >>>> This mechanism will allow CSIRTS to be more dynamic and agile in >>>> collaborating with a broader, and varying constituency. >>>> =20 >>>> >>>> =20 >>>> >>>> =20 >>>> These looked fine, but I'd like some actual dates for the TBDs ;) >>>> =20 >>>> >>>> =20 >>>> spt >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> =20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_20EA5441-CFFC-4155-9526-849E9A972AC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 What is really missing, but I = am not sure it belongs as a work group document, is a = requirements document for the protocol and markup itself. = The only thing I could find was RFC 3067. However, those were = requirements for a specific network operator with specific = needs.


Hi Panos,

I was expecting that to be more of a proper use of the = specifications and specification integration document and not an = overview of the higher level uses cases of the area these protocols are = supporting.  If I am wrong then I would love to hear it.  If someone has volunteered to be the author for that mile(stone) could = they please clarify?  If what I am considering is already covered = then I am good. ;-)

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: 
From: "Panos Kampanakis = (pkampana)" <pkampana@cisco.com>
Date: Tuesday, June 4, 2013 5:24 = PM
To: Kent Landfield <Kent_Landfield@McAfee.com>= ;, Sean Turner <turners@ieca.com>, "mile@ietf.org" <mile@ietf.org>
Subject: RE: [mile] re-charter = re-boot

The charter looks good to = me.
 
A clarification. Would the doc you are suggesting be = different of what Kathleen had in the charter =93Provide guidance on the implementation and use of RID = transports
based on use cases.  The guidance document will = show the relationship between transport options (RID + RID transport and = IODEF/RID + ROLIE) and may identify the need for additional transport = bindings.=94 Or did you have something similar in mind?
Rgs,
 
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, June 03, 2013 2:10 PM
To: turners@ieca.com; mile@ietf.org
Subject: Re: [mile] re-charter re-boot
 
I have no problem with = the revised charter as is but I think there is something missing. =  It would be good to have as a milestone a document that described = use cases for these protocols.  I rather see this separated out since we are in a situation now of addressing the transport (RID) , = the data model for exchange (IODEF) and query/reporting capabilities = (ROLIE).  We need to tie the three together and a document such as = this would help lay a foundation for usage in multiple areas.
 
FWIW=85
 
Kent = Landfield

McAfee | An = Intel Company
Direct: = +1.972.963.7096 
Mobile: +1.817.637.8026
www.mcafee.com
 
From: Sean Turner <turners@ieca.com>
Date: Monday, June 3, 2013 12:30 PM
To: "mile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] re-charter re-boot
 
Comments from anybody = else?
 
spt
=
 
On 5/25/13 9:11 AM, = Moriarty, Kathleen wrote:
Hi,
=
 
Sorry for the delay in = updating the charter.  There is a lot of activity in this = space right now as you all know.  I took Sean's suggested = content and updated it to reflect some of the activity and drivers for additional work in MILE.  Several people have mentioned an = interest in submitting extensions based on their current work, some in = virtualized environments, some for indicator specific formats, some = industry specific extensions, etc.  There is also work = developing by other groups who have mentioned that they will transition their work = to an international standards body once it is mature, so room has been = left in the charter to accommodate that work.  The need for = guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport = option to enable interoperable interfaces between = products.  The guidance may be use case specific where tighter = security is needed (RID +HTTP/TLS with the object level security options = enab
led) or = w
here ease of access is = the driver (ROLIE) with no client requirements necessary (can use a = browser).
 
We will follow up with = the mile stones, here the the re-write:
 
<intro>
 
The Managed Incident = Lightweight Exchange (MILE) working group
develops standards to = support computer and network security
incident management; an = incident is an unplanned event that
occurs in an information = technology (IT) infrastructure. An
incident could be a = benign configuration issue, IT incident, an
infraction to a service = level agreement (SLA), a system
compromise, socially = engineered phishing attack, or a
denial-of-service (DoS) = attack, etc.  When an incident is
detected, or suspected, = there may be a need for organizations to
collaborate. This = collaboration effort may take several forms
including joint analysis, = information dissemination, and/or a
coordinated operational = response.  Examples of the response = may
include filing a report, = notifying the source of the incident,
requesting that a third = party resolve/mitigate the incident,
sharing select indicators = of compromise, or requesting that the
source be located. By = sharing indicators of compromise associated
with an incident or = possible threat, the information becomes a
proactive defense for = others that may include mitigation options.
The Incident Object = Description Exchange Format (IODEF) defines
an information framework = to represent computer and network
security incidents; IODEF = is defined in RFC 5070 and
has been extended by RFC = 5091 to support phishing reports; RFC
6484 provides a template = for defining extensions to IODEF.
Real-time Inter-network = Defense (RID) defines a protocol to
facilitate sharing = computer and network security incidents;
RID is defined in RFC = 6545, and RID over HTTPS is defined in RFC
6546.
 
</intro>
 
The MILE WG is focused on = two areas, IODEF the data format and
extensions to represent = incident and indicator data and RID,
the policy and transport = for structured data.  With respect to
IODEF, the working group = will:
 
- Revise the IODEF = document to incorporate enhancements and
extensions based on = operational experience; use by Computer
Security Incident = Response Teams (CSIRTs) and others has
exposed the need to = extend IODEF to support industry specific
extensions, use case = specific content, and representations to
associate information = related to represented threats (system,
threat actors, campaigns, = etc.).  The value of information
sharing has been = demonstrated and highlighted at an increasing
rate through the success = of the Information Sharing and
Analysis Centers (ISACs) = and the recent cyber security Executive
Order in the = US.  International groups, such as the = Multinational
Association for = Collaborative Cyber Situational Awareness (CCSA)
have been running = experiments to determine what data is useful to
exchange between = industries and nations to effectively mitigate
threats.  The = work of these and other groups have identified = or
are working to develop = data representations relevant to their use
cases that may = compliment/extend IODEF or be useful to exchange
using RID and related = transport protocols.
 
- Provide guidance on the = implementation and use of IODEF to aid
implementers in = developing interoperable specifications.
 
With respect to RID, the = working group will:
 
- Define a = resource-oriented approach to cyber security
information sharing that = follows the REST architectural style.
This mechanism will allow = CSIRTS to be more dynamic and agile in
collaborating with a = broader, and varying constituency.
 
- Provide guidance on the = implementation and use of RID transports
based on use = cases.  The guidance document will show the = relationship
between transport options = (RID + RID transport and IODEF/RID + ROLIE)
and may identify the need = for additional transport bindings.
 
- RID may require = modifications to address data provenance, = additional
policy options, or other = changes now that there are multiple
interoperable = implementations of RFC6545 and RFC6546.  With = the
RID implementations in = the open source community, increased use and
experimentation may = demonstrate the need for a revision.
 
<milestones>
 
</milestones>
 
 
Thank = you!
Kathleen
 
________________________________________
From: mile-bounces@ietf.org [mile-bounces@ietf.org] On = Behalf Of Sean Turner [turners@ieca.com]
Sent: Wednesday, May 01, = 2013 9:04 PM
Subject: [mile] = re-charter re-boot
 
Hi,
=
 
I'd like to propose a = significant re-write of the proposed = charter.  I
think there's too much = history that's not really needed any more and
there's some repetition = that's unneeded.  I also think it's a = little
open ended wrt what's = actually going to get done. Based on recent
experience, I have a = strong feeling that the current charter wouldn't
get through the = process.
 
I'm proposing four = sections: intro, iodef-related work, rid-related
work, = milestones.
 
The intro = should:
 
- explain what the WG = does: develop standards to do foo.
- summarize what foo = is.
- highlight existing RFCs = that are part of the space:
     = IODEF: 5070/5091/6848 & RID: 6545/6546.
 
Then we talk about what = drafts the WG will produce for the two topic = areas.
 
How about this (or = something like this):
 
<intro>
 
The Managed Incident = Lightweight Exchange (MILE) working group
develops standards to = support computer and network security
incident management; an = incident is an unplanned event that
occurs in an information = technology (IT) infrastructure. An
incident could be a = benign configuration issue, IT incident, an
infraction to a service = level agreement (SLA), a system
compromise, socially = engineered phishing attack, or a
denial-of-service (DoS) = attack, etc.  When an incident is
detected, or suspected, = there may be a need for organizations to
collaborate. This = collaboration effort may take several forms
including joint analysis, = information dissemination, and/or a
coordinated operational = response.  Examples of the response = may
include filing a report, = notifying the source of the incident,
requesting that a third = party resolve/mitigate the incident,
sharing indicators of = compromise, or requesting that the source
be located. The Incident = Object Description Exchange Format
(IODEF) defines an = information framework to represent computer
and network security = incidents; IODEF is defined in RFC 5070 and
has been extended by RFC = 5091 to support phishing reports; RFC
6484 provides a template = for defining extensions to IODEF.
Real-time Inter-network = Defense (RID) defines a protocol to
facilitate sharing = computer and network security incidents;
RID is defined in RFC = 6545, and RID over HTTPS is defined in RFC
6546.
 
</into>
 
This working group does = two things IODEF and RID; we should be clear
about that and then list = the actual documents we're going to produce
that relate to each = one.  For the list of deliverables it looks = like
there's three 5070bis, a = reference/guidance draft, and a
resource-oriented = indicator exchange?
 
Questions:
 
Are the GRC and Forensic = drafts dead-dead?  I assume they'd not = be
included in the milestone = list.
 
Is there going to only be = one 5070bis draft or will there be a 5070bis +
other optional extension = drafts?  I assume it's just a 5070bis based = on
the milestones but = thought I'd ask.
 
Are we only extending = IODEF based on use or is there something else we
need to = consider?
 
How about something along = the lines of (need some help filling in the
blanks):
 
<iodef>
 
With respect to IODEF, = the working group will:
 
- Revise the IODEF = document to incorporate enhancements and
extensions based on = operational experience; use by Computer
Security Incident = Response Teams (CSIRTs) and others has
exposed the need to = extend IODEF to support x, y, z (need to have
some idea what's missing) = base on a, b, c (need to know a bit
more about why stuff is = missing did something new pop up?).
 
- Provide guidance on the = implementation and use of IODEF to aid
implementers in = developing interoperable specifications.
 
</iodef>
 
For = RID:
 
Are we also doing = defining guidance for RID as well or is that
incorporated in the IODEF = guidance?
 
Is RID itself going to be = untouched and we're just producing a new
"transport"?
 
Is it just for indicators = or is it for the whole incident?  Or = has
"indicators" over taken = "incident"?
 
<rid>
 
With respect to RID, the = working group will:
 
- Define a = resource-oriented approach to cyber security
information sharing that = follows the REST architectural style.
This mechanism will allow = CSIRTS to be more dynamic and agile in
collaborating with a = broader, and varying constituency.
 
</rid>
 
<milestones>
 
These looked fine, but = I'd like some actual dates for the TBDs ;)
 
</milestones>
 
spt
=
_______________________________________________
mile mailing = list
 
_______________________________________________
mile mailing = list
 
_______________________________________________
mile mailing = list
mile@ietf.org
https://www.ietf.org/m= ailman/listinfo/mile

= --Apple-Mail=_20EA5441-CFFC-4155-9526-849E9A972AC3-- From pkampana@cisco.com Thu Jun 6 08:32:38 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8186D21F941F for ; Thu, 6 Jun 2013 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mAiUkp8UWgL for ; Thu, 6 Jun 2013 08:32:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6349221F99C2 for ; Thu, 6 Jun 2013 08:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19249; q=dns/txt; s=iport; t=1370532752; x=1371742352; h=from:to:subject:date:message-id:mime-version; bh=8Hn+c8o2pqA8ymJywBKHTyMcsniddbFOKz5xCbKobFw=; b=DQMOx57ww4SbcuZshRAaCm67cvBQS14fyJxel93IltfywkPdzMS/oAYw L50LMQvi5zbx/PINftYHmFV6KyfZNSrDaYNQDaIYaTHMN94Ozrp9WtR4e V+a97tpY37n3jc7drC+2t0mRWaRE4miFLuXq+EdPFpaUmD7BlDuKzvhJX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFABOrsFGtJV2a/2dsb2JhbABZgkVEMK1NiTWIRXgWdIIjAQEBBC1eAQgRBAEBCx05FAkJAQQBEgiIBQy7Qo8BDSoDgnhhA5hokBeDD4In X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208,217";a="219609632" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jun 2013 15:32:27 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56FWQtf022211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 15:32:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 10:32:26 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" , "Adam Montville (amontville@tripwire.com)" Thread-Topic: Request for draft reviews - review of IODEF Enumeration Reference Thread-Index: Ac5iywbBL2OPl7oFTvaNQKS+LaneQQ== Date: Thu, 6 Jun 2013 15:32:26 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.113] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753C880Axmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:32:38 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753C880Axmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, I think this is close to being done. I had reviewed in the past and the reg= istry format is as we had all agreed. I did a fresh review and had some minor nits and suggestions, and some conf= usion for the IANA considerations section. - maybe rephrase "but one that seems the most appropriate at this point is = to..." to "but the most appropriate at this point is to..." - "especially enumerations such as CEE, CVE, CCE" maybe put informative references for CEE, CVE and CCE? - "Where id_type is an IANA-registered type having the form..." I am propos= ing to rephrase the paragraph a little to avoid the "And where..." "The format of the ReferenceName MUST follow the form of id_type:version:id where id_type is an IANA-registered type having the form The version is an IANA-registered type having the form The id is the actual enumeration identifier string." - In section "4 IANA Considerations", it is not very clear to me what each= paragraph is trying to convey. It this section trying to describe the IANA= registry or the format of a registry update request? To me it seems it is = mostly the former with some info on the latter. Should the "Name of the Registry: "Enumeration Reference Type Identifiers""= be in the "Fields to record in the registry: "? Does the paragraph "The registry is intended to enable enumeration value ad= ditions..." describe what the IANA registry represents or should it be in t= he registry request for a new value? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank yo= u to all of the editors for making the requested changes! The current list= of drafts up for review (including those that will be a part of the WG aft= er the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/ Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the list= . It would be helpful if we can iterate on most of them prior to the next = meeting. A couple of the drafts are very close to being done. The list of= current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up soon on the charter update as well. Thank you all in advance! Kathleen --_000_1C9F17D1873AFA47A969C4DD98F98A753C880Axmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adam,

 <= /p>

I think this is close to = being done. I had reviewed in the past and the registry format is as we had= all agreed.

I did a fresh review and = had some minor nits and suggestions, and some confusion for the IANA consid= erations section.

 <= /p> 

- maybe rephrase “but one that seems the most appropriate at this point is t=
o...” to “but the most appropriate at this point is to...”
 
- “especially enumerations such as
   CEE, CVE, CCE” maybe put informative references for CEE, CVE and=
 CCE?
 
- “Where id_type is an IANA-registered type having the form...” I am proposing to rephrase the paragraph a littl=
e to avoid the “And where…”
“T=
he format of the ReferenceName MUST follow the form of

      id_type:ver=
sion:id


   where id_type is an IANA-regi=
stered type having the form


      <Abbrevi=
ation>


   The version is an IANA-regist=
ered type having the form


      <Version=
>


   The id is the actual enumerat=
ion identifier string.”


 


- In section “4  IANA Considerations&#=
8221;, it is not very clear to me what each paragraph is trying to convey. =
It this section trying to describe the IANA registry or the format of a reg=
istry update request? To me it seems it is mostly the former with some info=
 on the latter.  


Should the “Name of the Registry: "Enumeration Reference Type Identifier=
s"” be in the “Fields to record in the registry: ”? 


Does the paragraph “The registry is intended to enable enumeration value addi=
tions...” describe what the IANA re=
gistry represents or should it be in the registry request for a new value?<=
/span>


 <=
/p>

Rgs,

Panos

 <=
/p>

 <=
/p>

 <=
/p>





From: mile-bou=
nces@ietf.org [mailto:mile-bounces@ietf.org]
On Behalf Of Moriarty, Kathleen

Sent: Friday, May 17, 2013 2:13 PM

To: mile@ietf.org

Subject: [mile] Request for draft reviews






 




Greetings!






 






We have had a number of documents updat=
ed since the last meeting.  Thank you to all of the editors for making=
 the requested changes!  The current list of drafts up for review
 (including those that will be a part of the WG after the charter update) i=
nclude:






 






RFC5070-bis (IODEF Revision):







 






Draft on IODEF Guidance:






(input from experience, real use cases,=
 and draft review will be helpful)







 






Structured Cybersecurity Information dr=
aft (close to final):







 






IODEF Enumeration Reference Format:







 






Resource-Oriented Lightweight Indicator=
 Exchange (ROLIE):








 






Please take some time to review the dra=
fts and provide feedback to the list.  It would be helpful if we can i=
terate on most of them prior to the next meeting.  A couple of
 the drafts are very close to being done.  The list of current drafts =
and published RFCs can be found at the following link:






 






We will follow up soon on the charter u=
pdate as well.






 






Thank you all in advance!

Kathleen






 






 
--_000_1C9F17D1873AFA47A969C4DD98F98A753C880Axmbrcdx10ciscocom_-- From pkampana@cisco.com Thu Jun 6 10:29:14 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634D221F8F69 for ; Thu, 6 Jun 2013 10:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKWDqL94qK3q for ; Thu, 6 Jun 2013 10:29:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1921F99D1 for ; Thu, 6 Jun 2013 10:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12398; q=dns/txt; s=iport; t=1370539740; x=1371749340; h=from:to:subject:date:message-id:mime-version; bh=2vnm4joxMLXVEN8pR37ghMO25xzW8P6T/i5AoFt9Th8=; b=D1iqNxQxoNIYjnippn6RdmPbfKKJkaikS1tp74IBHZO2VQs2u6pU7zNI SUCbwr6K5rGVHJ4/XWyIIA98lnu8ILOnkEKjGlm+oj78hZb/FOXq6t6cV ixBMMnflAkv73WpEWDZQ6759G5CcgOzvuNajmhwuJZj2gAF190W16rAzj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAIbGsFGtJXHA/2dsb2JhbABZgkVEMK1NiTWIRXgWdIIjAQEBBC1eAQgRBAEBCx05FAkJAQQBEgiIBQy7c48BN4J7YQOYaJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208,217";a="219674832" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 17:28:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56HSjh3000756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:28:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:28:44 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" , "Takeshi Takahashi (takeshi_takahashi@nict.go.jp)" Thread-Topic: Request for draft reviews - review of SCI Thread-Index: Ac5i2z2CWaU7+XpfRwC8pzVeXfAwQw== Date: Thu, 6 Jun 2013 17:28:45 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753C89FE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.70] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753C89FExmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of SCI X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:29:14 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753C89FExmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Take, I have reviewed this a few times and it is ready to go, in my mind. All my= concerns have been addressed in previous iterations. The only thing I would do is to make sure that the XML in the appendix is s= yntactically correct. Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank yo= u to all of the editors for making the requested changes! The current list= of drafts up for review (including those that will be a part of the WG aft= er the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/ Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the list= . It would be helpful if we can iterate on most of them prior to the next = meeting. A couple of the drafts are very close to being done. The list of= current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up soon on the charter update as well. Thank you all in advance! Kathleen --_000_1C9F17D1873AFA47A969C4DD98F98A753C89FExmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Take,

I have reviewed this a fe= w times and  it is ready to go, in my mind. All my concerns have been = addressed in previous iterations.

The only thing I would do= is to make sure that the XML in the appendix is syntactically correct.

Rgs,

Panos

 <= /p>

 <= /p>

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To: mile@ietf.org
Subject: [mile] Request for draft reviews

 

Greetings!

 

We have had a number of documents updat= ed since the last meeting.  Thank you to all of the editors for making= the requested changes!  The current list of drafts up for review (including those that will be a part of the WG after the charter update) i= nclude:

 

RFC5070-bis (IODEF Revision):

 

Draft on IODEF Guidance:

(input from experience, real use cases,= and draft review will be helpful)

 

Structured Cybersecurity Information dr= aft (close to final):

 

IODEF Enumeration Reference Format:

 

Resource-Oriented Lightweight Indicator= Exchange (ROLIE):

 

Please take some time to review the dra= fts and provide feedback to the list.  It would be helpful if we can i= terate on most of them prior to the next meeting.  A couple of the drafts are very close to being done.  The list of current drafts = and published RFCs can be found at the following link:

 

We will follow up soon on the charter u= pdate as well.

 

Thank you all in advance!
Kathleen

 

 

--_000_1C9F17D1873AFA47A969C4DD98F98A753C89FExmbrcdx10ciscocom_-- From turners@ieca.com Thu Jun 6 10:32:00 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75B521F9944 for ; Thu, 6 Jun 2013 10:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8c+7NvRGvbp for ; Thu, 6 Jun 2013 10:31:48 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.162.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3895121F9339 for ; Thu, 6 Jun 2013 10:31:48 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 73F4E46263BF7; Thu, 6 Jun 2013 12:31:24 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 62BEB46263BB3 for ; Thu, 6 Jun 2013 12:31:24 -0500 (CDT) Received: from [173.73.135.101] (port=58212 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Uke2N-00054G-AT; Thu, 06 Jun 2013 12:31:47 -0500 Message-ID: <51B0C782.40202@ieca.com> Date: Thu, 06 Jun 2013 13:31:46 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> <51AE50D9.1090408@ieca.com> In-Reply-To: <51AE50D9.1090408@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:58212 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 20 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:32:01 -0000 Kent and this dawned on me too last night ... don't let it being a WG item stop you or anybody really from writing an individual draft that could be considered for wg acceptance. My plan is to circle the wagons on Monday with the chairs with the use case draft as an item and start the re-chartering process. spt On 6/4/13 4:40 PM, Sean Turner wrote: > Well unless I'm hearing any violent objections I think adding it would > make sense actually. It's also an easy for somebody who is using this > technology to get their feet wet in the WG. > > spt > > On 6/4/13 10:59 AM, Kent_Landfield@McAfee.com wrote: >> :-) Something told me you would ask that…. ;-) >> >> Let me see if I can find someone to help with it. Volunteers? I could >> use some help I am sure. >> >> *Kent Landfield* >> >> *McAfee | An Intel Company* >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> *Web: *www.mcafee.com >> >> From: Sean Turner > >> Date: Tuesday, June 4, 2013 7:29 AM >> To: Kent Landfield > > >> Cc: "mile@ietf.org " > > >> Subject: Re: [mile] re-charter re-boot >> >> Is that you volunteering to write such a draft ;) >> >> spt >> >> On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com >> wrote: >> >> I have no problem with the revised charter as is but I think >> there is >> something missing. It would be good to have as a milestone a >> document >> that described use cases for these protocols. I rather see this >> separated out since we are in a situation now of addressing the >> transport (RID) , the data model for exchange (IODEF) and >> query/reporting capabilities (ROLIE). We need to tie the three >> together >> and a document such as this would help lay a foundation for >> usage in >> multiple areas. >> >> FWIW… >> >> *Kent Landfield* >> >> *McAfee | An Intel Company* >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> *Web: *www.mcafee.com >> >> From: Sean Turner >> > >> Date: Monday, June 3, 2013 12:30 PM >> To: "mile@ietf.org >> " >> > >> Subject: Re: [mile] re-charter re-boot >> >> Comments from anybody else? >> >> spt >> >> On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: >> >> Hi, >> >> Sorry for the delay in updating the charter. There is >> a lot of >> activity in this space right now as you all know. I >> took Sean's >> suggested content and updated it to reflect some of >> the activity >> and drivers for additional work in MILE. Several >> people have >> mentioned an interest in submitting extensions based >> on their >> current work, some in virtualized environments, some >> for >> indicator specific formats, some industry specific >> extensions, >> etc. There is also work developing by other groups >> who have >> mentioned that they will transition their work to an >> international standards body once it is mature, so >> room has been >> left in the charter to accommodate that work. The >> need for >> guidance on the transport options has surfaced so that >> implementers understand when they may choose a specific >> transport option to enable interoperable interfaces >> between >> products. The guidance may be use case specific where >> tighter >> security is needed (RID +HTTP/TLS with the object >> level security >> options enab >> >> led) or w >> here ease of access is the driver (ROLIE) with no client >> requirements necessary (can use a browser). >> >> >> We will follow up with the mile stones, here the the >> re-write: >> >> >> >> The Managed Incident Lightweight Exchange (MILE) >> working group >> develops standards to support computer and network >> security >> incident management; an incident is an unplanned event >> that >> occurs in an information technology (IT) >> infrastructure. An >> incident could be a benign configuration issue, IT >> incident, an >> infraction to a service level agreement (SLA), a system >> compromise, socially engineered phishing attack, or a >> denial-of-service (DoS) attack, etc. When an >> incident is >> detected, or suspected, there may be a need for >> organizations to >> collaborate. This collaboration effort may take >> several forms >> including joint analysis, information dissemination, >> and/or a >> coordinated operational response. Examples of the >> response may >> include filing a report, notifying the source of the >> incident, >> requesting that a third party resolve/mitigate the >> incident, >> sharing select indicators of compromise, or requesting >> that the >> source be located. By sharing indicators of compromise >> associated >> with an incident or possible threat, the information >> becomes a >> proactive defense for others that may include >> mitigation options. >> The Incident Object Description Exchange Format >> (IODEF) defines >> an information framework to represent computer and >> network >> security incidents; IODEF is defined in RFC 5070 and >> has been extended by RFC 5091 to support phishing >> reports; RFC >> 6484 provides a template for defining extensions to >> IODEF. >> Real-time Inter-network Defense (RID) defines a >> protocol to >> facilitate sharing computer and network security >> incidents; >> RID is defined in RFC 6545, and RID over HTTPS is >> defined in RFC >> 6546. >> >> >> >> The MILE WG is focused on two areas, IODEF the data >> format and >> extensions to represent incident and indicator data >> and RID, >> the policy and transport for structured data. With >> respect to >> IODEF, the working group will: >> >> - Revise the IODEF document to incorporate >> enhancements and >> extensions based on operational experience; use by >> Computer >> Security Incident Response Teams (CSIRTs) and others >> has >> exposed the need to extend IODEF to support industry >> specific >> extensions, use case specific content, and >> representations to >> associate information related to represented threats >> (system, >> threat actors, campaigns, etc.). The value of >> information >> sharing has been demonstrated and highlighted at an >> increasing >> rate through the success of the Information Sharing and >> Analysis Centers (ISACs) and the recent cyber security >> Executive >> Order in the US. International groups, such as the >> Multinational >> Association for Collaborative Cyber Situational >> Awareness (CCSA) >> have been running experiments to determine what data >> is useful to >> exchange between industries and nations to effectively >> mitigate >> threats. The work of these and other groups have >> identified or >> are working to develop data representations relevant >> to their use >> cases that may compliment/extend IODEF or be useful to >> exchange >> using RID and related transport protocols. >> >> - Provide guidance on the implementation and use of >> IODEF to aid >> implementers in developing interoperable >> specifications. >> >> With respect to RID, the working group will: >> >> - Define a resource-oriented approach to cyber security >> information sharing that follows the REST >> architectural style. >> This mechanism will allow CSIRTS to be more dynamic >> and agile in >> collaborating with a broader, and varying constituency. >> >> - Provide guidance on the implementation and use of >> RID transports >> based on use cases. The guidance document will show >> the >> relationship >> between transport options (RID + RID transport and >> IODEF/RID + >> ROLIE) >> and may identify the need for additional transport >> bindings. >> >> - RID may require modifications to address data >> provenance, >> additional >> policy options, or other changes now that there are >> multiple >> interoperable implementations of RFC6545 and >> RFC6546. With the >> RID implementations in the open source community, >> increased use and >> experimentation may demonstrate the need for a >> revision. >> >> >> >> >> >> >> Thank you! >> Kathleen >> >> ________________________________________ >> From: mile-bounces@ietf.org >> >> [mile-bounces@ietf.org >> ] On Behalf >> Of Sean Turner [turners@ieca.com >> ] >> Sent: Wednesday, May 01, 2013 9:04 PM >> To: mile@ietf.org >> >> Subject: [mile] re-charter re-boot >> >> Hi, >> >> I'd like to propose a significant re-write of the >> proposed >> charter. I >> think there's too much history that's not really >> needed any more and >> there's some repetition that's unneeded. I also think >> it's a little >> open ended wrt what's actually going to get done. >> Based on recent >> experience, I have a strong feeling that the current >> charter >> wouldn't >> get through the process. >> >> I'm proposing four sections: intro, iodef-related >> work, rid-related >> work, milestones. >> >> The intro should: >> >> - explain what the WG does: develop standards to do >> foo. >> - summarize what foo is. >> - highlight existing RFCs that are part of the space: >> IODEF: 5070/5091/6848 & RID: 6545/6546. >> >> Then we talk about what drafts the WG will produce for >> the two >> topic areas. >> >> How about this (or something like this): >> >> >> >> The Managed Incident Lightweight Exchange (MILE) >> working group >> develops standards to support computer and network >> security >> incident management; an incident is an unplanned event >> that >> occurs in an information technology (IT) >> infrastructure. An >> incident could be a benign configuration issue, IT >> incident, an >> infraction to a service level agreement (SLA), a system >> compromise, socially engineered phishing attack, or a >> denial-of-service (DoS) attack, etc. When an >> incident is >> detected, or suspected, there may be a need for >> organizations to >> collaborate. This collaboration effort may take >> several forms >> including joint analysis, information dissemination, >> and/or a >> coordinated operational response. Examples of the >> response may >> include filing a report, notifying the source of the >> incident, >> requesting that a third party resolve/mitigate the >> incident, >> sharing indicators of compromise, or requesting that >> the source >> be located. The Incident Object Description Exchange >> Format >> (IODEF) defines an information framework to represent >> computer >> and network security incidents; IODEF is defined in >> RFC 5070 and >> has been extended by RFC 5091 to support phishing >> reports; RFC >> 6484 provides a template for defining extensions to >> IODEF. >> Real-time Inter-network Defense (RID) defines a >> protocol to >> facilitate sharing computer and network security >> incidents; >> RID is defined in RFC 6545, and RID over HTTPS is >> defined in RFC >> 6546. >> >> >> >> This working group does two things IODEF and RID; we >> should be clear >> about that and then list the actual documents we're >> going to produce >> that relate to each one. For the list of deliverables >> it looks like >> there's three 5070bis, a reference/guidance draft, >> and a >> resource-oriented indicator exchange? >> >> Questions: >> >> Are the GRC and Forensic drafts dead-dead? I assume >> they'd not be >> included in the milestone list. >> >> Is there going to only be one 5070bis draft or will >> there be a >> 5070bis + >> other optional extension drafts? I assume it's just a >> 5070bis >> based on >> the milestones but thought I'd ask. >> >> Are we only extending IODEF based on use or is there >> something >> else we >> need to consider? >> >> How about something along the lines of (need some help >> filling >> in the >> blanks): >> >> >> >> With respect to IODEF, the working group will: >> >> - Revise the IODEF document to incorporate >> enhancements and >> extensions based on operational experience; use by >> Computer >> Security Incident Response Teams (CSIRTs) and others >> has >> exposed the need to extend IODEF to support x, y, z >> (need to have >> some idea what's missing) base on a, b, c (need to >> know a bit >> more about why stuff is missing did something new pop >> up?). >> >> - Provide guidance on the implementation and use of >> IODEF to aid >> implementers in developing interoperable >> specifications. >> >> >> >> For RID: >> >> Are we also doing defining guidance for RID as well or >> is that >> incorporated in the IODEF guidance? >> >> Is RID itself going to be untouched and we're just >> producing a new >> "transport"? >> >> Is it just for indicators or is it for the whole >> incident? Or has >> "indicators" over taken "incident"? >> >> >> >> With respect to RID, the working group will: >> >> - Define a resource-oriented approach to cyber security >> information sharing that follows the REST >> architectural style. >> This mechanism will allow CSIRTS to be more dynamic >> and agile in >> collaborating with a broader, and varying constituency. >> >> >> >> >> >> These looked fine, but I'd like some actual dates for >> the TBDs ;) >> >> >> >> spt >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From Adam.Montville@cisecurity.org Thu Jun 6 10:38:55 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3A21F8EC3 for ; Thu, 6 Jun 2013 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd2AVFDEzdue for ; Thu, 6 Jun 2013 10:38:50 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52221F9A1A for ; Thu, 6 Jun 2013 10:38:50 -0700 (PDT) Received: from [216.82.253.227:9771] by server-9.bemta-7.messagelabs.com id 78/2A-28694-929C0B15; Thu, 06 Jun 2013 17:38:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-170.messagelabs.com!1370540328!5754141!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 6251 invoked from network); 6 Jun 2013 17:38:48 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jun 2013 17:38:48 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 13:38:44 -0400 From: Adam Montville To: "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" , Adam Montville Thread-Topic: [mile] Request for draft reviews - review of IODEF Enumeration Reference Thread-Index: Ac5iywbBL2OPl7oFTvaNQKS+LaneQQAET99Q Date: Thu, 6 Jun 2013 17:38:42 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F2D3B@CISEXCHANGE1.msisac.org.local> References: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D66F2D3BCISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:38:55 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D66F2D3BCISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you! I'll make the changes you recommend. Also, are there good IANA-related RFCs I can look at to tighten this draft= up a bit? What I was intending for the IANA section is to convey both wh= at the registry contains and the format of each element therein. If there's a better way to do this, let's do it. Adam From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pa= nos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 8:33 AM To: Moriarty, Kathleen; mile@ietf.org; Adam Montville (amontville@tripwire= .com) Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeratio= n Reference Hi Adam, I think this is close to being done. I had reviewed in the past and the re= gistry format is as we had all agreed. I did a fresh review and had some minor nits and suggestions, and some con= fusion for the IANA considerations section. - maybe rephrase "but one that seems the most appropriate at this point is= to..." to "but the most appropriate at this point is to..." - "especially enumerations such as CEE, CVE, CCE" maybe put informative references for CEE, CVE and CCE? - "Where id_type is an IANA-registered type having the form..." I am propo= sing to rephrase the paragraph a little to avoid the "And where..." "The format of the ReferenceName MUST follow the form of id_type:version:id where id_type is an IANA-registered type having the form The version is an IANA-registered type having the form The id is the actual enumeration identifier string." - In section "4 IANA Considerations", it is not very clear to me what eac= h paragraph is trying to convey. It this section trying to describe the IA= NA registry or the format of a registry update request? To me it seems it = is mostly the former with some info on the latter. Should the "Name of the Registry: "Enumeration Reference Type Identifiers"= " be in the "Fields to record in the registry: "? Does the paragraph "The registry is intended to enable enumeration value a= dditions..." describe what the IANA registry represents or should it be in= the registry request for a new value? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bou= nces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank y= ou to all of the editors for making the requested changes! The current li= st of drafts up for review (including those that will be a part of the WG = after the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format= / Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the lis= t. It would be helpful if we can iterate on most of them prior to the nex= t meeting. A couple of the drafts are very close to being done. The list= of current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up soon on the charter update as well. Thank you all in advance! Kathleen ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. --_000_05BCCEB107AF88469B9F99783D47C1D66F2D3BCISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you!  I̵= 7;ll make the changes you recommend.

 

Also, are there good IA= NA-related RFCs I can look at to tighten this draft up a bit?  What I= was intending for the IANA section is to convey both what the registry contains and the format of each element therein.

 

If there’s a bett= er way to do this, let’s do it.

 

Adam<= /p>

 

From: mile-= bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 06, 2013 8:33 AM
To: Moriarty, Kathleen; mile@ietf.org; Adam Montville (amontville@t= ripwire.com)
Subject: Re: [mile] Request for draft reviews - review of IODEF Enu= meration Reference

 

Hi Adam,

 

I think this is close t= o being done. I had reviewed in the past and the registry format is as we = had all agreed.

I did a fresh review an= d had some minor nits and suggestions, and some confusion for the IANA con= siderations section.

 

- maybe rephrase “but one that seems the most appropriate at this point is=
 to...” to “but the most appropriate at this point is to...”=

 
- “especially enumerations such as
   CEE, CVE, CCE” maybe put informative references for CEE, CVE =
and CCE?
 
- “Where id_type is an IANA-registered type having the form...” I am proposing to rephrase the paragraph a =
little to avoid the “And where…”
= 
“The format of the ReferenceName MUST follow the form of=

      id_type:ve=
rsion:id
   where id_type is an IANA-reg=
istered type having the form
      <Abbrev=
iation>
   The version is an IANA-regis=
tered type having the form
      <Versio=
n>
   The id is the actual=20enume=
ration identifier string.”=

 
- In section “4  IANA ConsiderationsShould the “Name of the Registry: "Enumeration Reference Type Identif=
iers"” be in the “Fields to record in the registry: ”? 
Does the paragraph “The registry is intended to enable enumeration value a=
dditions...” describe what the IA=
NA registry represents or should it be in the registry request for a new v=
alue?

 

Rgs,<= /p>

Panos=

 

 

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To: mile@ietf.org
Subject: [mile] Request for draft reviews

 

Greetings!

 

We have had a number of documents upd= ated since the last meeting.  Thank you to all of the editors for mak= ing the requested changes!  The current list of drafts up for review (including those that will be a part of the WG after the charter update) = include:

 

RFC5070-bis (IODEF Revision):

 

Draft on IODEF Guidance:

(input from experience, real use case= s, and draft review will be helpful)

 

Structured Cybersecurity Information = draft (close to final):

 

IODEF Enumeration Reference Format:

 

Resource-Oriented Lightweight Indicat= or Exchange (ROLIE):

 

Please take some time to review the d= rafts and provide feedback to the list.  It would be helpful if we ca= n iterate on most of them prior to the next meeting.  A couple of the drafts are very close to being done.  The list of current drafts= and published RFCs can be found at the following link:<= /p>

 

We will follow up soon on the charter= update as well.

 

Thank you all in advance!
Kathleen

 

 


...


This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments.
--_000_05BCCEB107AF88469B9F99783D47C1D66F2D3BCISEXCHANGE1msisa_-- From Kent_Landfield@mcafee.com Thu Jun 6 10:39:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8661621F9A1A for ; Thu, 6 Jun 2013 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smSir4wumP7C for ; Thu, 6 Jun 2013 10:39:36 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 059AE21F8EC3 for ; Thu, 6 Jun 2013 10:39:35 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 419f_6fc2_9a07490c_3450_4961_a646_cb99f3b70ffe; Thu, 06 Jun 2013 12:39:30 -0500 Received: from MIVEXEMEA1N2.corp.nai.org (10.48.48.32) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 6 Jun 2013 13:36:15 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N2.corp.nai.org ([169.254.2.69]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 13:36:16 -0400 From: To: Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gIABhycA///V4wCAALNLgIAC784AgAABOwA= Date: Thu, 6 Jun 2013 17:36:15 +0000 Message-ID: <342874C7-5E2D-4645-BB12-FC1A20F4C0D8@McAfee.com> References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> <51AE50D9.1090408@ieca.com> <51B0C782.40202@ieca.com> In-Reply-To: <51B0C782.40202@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:39:40 -0000 VW5kZXJzdGFuZC4gU291bmRzIGdvb2QgdG8gbWUuDQoNCktlbnQgTGFuZGZpZWxkDQpNY0FmZWUg TGFicw0KS2VudF9MYW5kZmllbGRATWNBZmVlLmNvbQ0KKzEuODE3LjYzNy44MDI2IA0KDQpPbiBK dW4gNiwgMjAxMywgYXQgMTI6MzEgUE0sICJTZWFuIFR1cm5lciIgPHR1cm5lcnNAaWVjYS5jb20+ IHdyb3RlOg0KDQo+IEtlbnQgYW5kIHRoaXMgZGF3bmVkIG9uIG1lIHRvbyBsYXN0IG5pZ2h0IC4u LiBkb24ndCBsZXQgaXQgYmVpbmcgYSBXRyBpdGVtIHN0b3AgeW91IG9yIGFueWJvZHkgcmVhbGx5 IGZyb20gd3JpdGluZyBhbiBpbmRpdmlkdWFsIGRyYWZ0IHRoYXQgY291bGQgYmUgY29uc2lkZXJl ZCBmb3Igd2cgYWNjZXB0YW5jZS4NCj4gDQo+IE15IHBsYW4gaXMgdG8gY2lyY2xlIHRoZSB3YWdv bnMgb24gTW9uZGF5IHdpdGggdGhlIGNoYWlycyB3aXRoIHRoZSB1c2UgY2FzZSBkcmFmdCBhcyBh biBpdGVtIGFuZCBzdGFydCB0aGUgcmUtY2hhcnRlcmluZyBwcm9jZXNzLg0KPiANCj4gc3B0DQo+ IA0KPiBPbiA2LzQvMTMgNDo0MCBQTSwgU2VhbiBUdXJuZXIgd3JvdGU6DQo+PiBXZWxsIHVubGVz cyBJJ20gaGVhcmluZyBhbnkgdmlvbGVudCBvYmplY3Rpb25zIEkgdGhpbmsgYWRkaW5nIGl0IHdv dWxkDQo+PiBtYWtlIHNlbnNlIGFjdHVhbGx5LiAgSXQncyBhbHNvIGFuIGVhc3kgZm9yIHNvbWVi b2R5IHdobyBpcyB1c2luZyB0aGlzDQo+PiB0ZWNobm9sb2d5IHRvIGdldCB0aGVpciBmZWV0IHdl dCBpbiB0aGUgV0cuDQo+PiANCj4+IHNwdA0KPj4gDQo+PiBPbiA2LzQvMTMgMTA6NTkgQU0sIEtl bnRfTGFuZGZpZWxkQE1jQWZlZS5jb20gd3JvdGU6DQo+Pj4gOi0pIFNvbWV0aGluZyB0b2xkIG1l IHlvdSB3b3VsZCBhc2sgdGhhdOKApi4gIDstKQ0KPj4+IA0KPj4+IExldCBtZSBzZWUgaWYgSSBj YW4gZmluZCBzb21lb25lIHRvIGhlbHAgd2l0aCBpdC4gVm9sdW50ZWVycz8gIEkgY291bGQNCj4+ PiB1c2Ugc29tZSBoZWxwIEkgYW0gc3VyZS4NCj4+PiANCj4+PiAqS2VudCBMYW5kZmllbGQqDQo+ Pj4gDQo+Pj4gKk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnkqDQo+Pj4gRGlyZWN0OiArMS45NzIu OTYzLjcwOTYNCj4+PiBNb2JpbGU6ICsxLjgxNy42MzcuODAyNg0KPj4+ICpXZWI6ICp3d3cubWNh ZmVlLmNvbSA8aHR0cDovL3d3dy5tY2FmZWUuY29tLz4NCj4+PiANCj4+PiBGcm9tOiBTZWFuIFR1 cm5lciA8dHVybmVyc0BpZWNhLmNvbSA8bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20+Pg0KPj4+IERh dGU6IFR1ZXNkYXksIEp1bmUgNCwgMjAxMyA3OjI5IEFNDQo+Pj4gVG86IEtlbnQgTGFuZGZpZWxk IDxLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tDQo+Pj4gPG1haWx0bzpLZW50X0xhbmRmaWVsZEBN Y0FmZWUuY29tPj4NCj4+PiBDYzogIm1pbGVAaWV0Zi5vcmcgPG1haWx0bzptaWxlQGlldGYub3Jn PiIgPG1pbGVAaWV0Zi5vcmcNCj4+PiA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+Pg0KPj4+IFN1Ympl Y3Q6IFJlOiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290DQo+Pj4gDQo+Pj4gICAgSXMgdGhhdCB5 b3Ugdm9sdW50ZWVyaW5nIHRvIHdyaXRlIHN1Y2ggYSBkcmFmdCA7KQ0KPj4+IA0KPj4+ICAgIHNw dA0KPj4+IA0KPj4+ICAgIE9uIDYvMy8xMyAyOjEwIFBNLCBLZW50X0xhbmRmaWVsZEBNY0FmZWUu Y29tDQo+Pj4gICAgPG1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPiB3cm90ZToNCj4+ PiANCj4+PiAgICAgICAgSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgcmV2aXNlZCBjaGFydGVy IGFzIGlzIGJ1dCBJIHRoaW5rDQo+Pj4gICAgICAgIHRoZXJlIGlzDQo+Pj4gICAgICAgIHNvbWV0 aGluZyBtaXNzaW5nLiAgSXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGFzIGEgbWlsZXN0b25lIGEN Cj4+PiAgICAgICAgZG9jdW1lbnQNCj4+PiAgICAgICAgdGhhdCBkZXNjcmliZWQgdXNlIGNhc2Vz IGZvciB0aGVzZSBwcm90b2NvbHMuICBJIHJhdGhlciBzZWUgdGhpcw0KPj4+ICAgICAgICBzZXBh cmF0ZWQgb3V0IHNpbmNlIHdlIGFyZSBpbiBhIHNpdHVhdGlvbiBub3cgb2YgYWRkcmVzc2luZyB0 aGUNCj4+PiAgICAgICAgdHJhbnNwb3J0IChSSUQpICwgdGhlIGRhdGEgbW9kZWwgZm9yIGV4Y2hh bmdlIChJT0RFRikgYW5kDQo+Pj4gICAgICAgIHF1ZXJ5L3JlcG9ydGluZyBjYXBhYmlsaXRpZXMg KFJPTElFKS4gIFdlIG5lZWQgdG8gdGllIHRoZSB0aHJlZQ0KPj4+ICAgICAgICB0b2dldGhlcg0K Pj4+ICAgICAgICBhbmQgYSBkb2N1bWVudCBzdWNoIGFzIHRoaXMgd291bGQgaGVscCBsYXkgYSBm b3VuZGF0aW9uIGZvcg0KPj4+IHVzYWdlIGluDQo+Pj4gICAgICAgIG11bHRpcGxlIGFyZWFzLg0K Pj4+IA0KPj4+ICAgICAgICBGV0lX4oCmDQo+Pj4gDQo+Pj4gICAgICAgICpLZW50IExhbmRmaWVs ZCoNCj4+PiANCj4+PiAgICAgICAgKk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnkqDQo+Pj4gICAg ICAgIERpcmVjdDogKzEuOTcyLjk2My43MDk2DQo+Pj4gICAgICAgIE1vYmlsZTogKzEuODE3LjYz Ny44MDI2DQo+Pj4gICAgICAgICpXZWI6ICp3d3cubWNhZmVlLmNvbSA8aHR0cDovL3d3dy5tY2Fm ZWUuY29tLz4NCj4+PiANCj4+PiAgICAgICAgRnJvbTogU2VhbiBUdXJuZXIgPHR1cm5lcnNAaWVj YS5jb20gPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPg0KPj4+ICAgICAgICA8bWFpbHRvOnR1cm5l cnNAaWVjYS5jb20+Pg0KPj4+ICAgICAgICBEYXRlOiBNb25kYXksIEp1bmUgMywgMjAxMyAxMjoz MCBQTQ0KPj4+ICAgICAgICBUbzogIm1pbGVAaWV0Zi5vcmcgPG1haWx0bzptaWxlQGlldGYub3Jn Pg0KPj4+ICAgICAgICA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+IiA8bWlsZUBpZXRmLm9yZyA8bWFp bHRvOm1pbGVAaWV0Zi5vcmc+DQo+Pj4gICAgICAgIDxtYWlsdG86bWlsZUBpZXRmLm9yZz4+DQo+ Pj4gICAgICAgIFN1YmplY3Q6IFJlOiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290DQo+Pj4gDQo+ Pj4gICAgICAgICAgICAgIENvbW1lbnRzIGZyb20gYW55Ym9keSBlbHNlPw0KPj4+IA0KPj4+ICAg ICAgICAgICAgICBzcHQNCj4+PiANCj4+PiAgICAgICAgICAgICAgT24gNS8yNS8xMyA5OjExIEFN LCBNb3JpYXJ0eSwgS2F0aGxlZW4gd3JvdGU6DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICBI aSwNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIFNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gdXBk YXRpbmcgdGhlIGNoYXJ0ZXIuICBUaGVyZSBpcw0KPj4+ICAgICAgICBhIGxvdCBvZg0KPj4+ICAg ICAgICAgICAgICAgICAgYWN0aXZpdHkgaW4gdGhpcyBzcGFjZSByaWdodCBub3cgYXMgeW91IGFs bCBrbm93LiAgSQ0KPj4+ICAgICAgICB0b29rIFNlYW4ncw0KPj4+ICAgICAgICAgICAgICAgICAg c3VnZ2VzdGVkIGNvbnRlbnQgYW5kIHVwZGF0ZWQgaXQgdG8gcmVmbGVjdCBzb21lIG9mDQo+Pj4g ICAgICAgIHRoZSBhY3Rpdml0eQ0KPj4+ICAgICAgICAgICAgICAgICAgYW5kIGRyaXZlcnMgZm9y IGFkZGl0aW9uYWwgd29yayBpbiBNSUxFLiAgU2V2ZXJhbA0KPj4+ICAgICAgICBwZW9wbGUgaGF2 ZQ0KPj4+ICAgICAgICAgICAgICAgICAgbWVudGlvbmVkIGFuIGludGVyZXN0IGluIHN1Ym1pdHRp bmcgZXh0ZW5zaW9ucyBiYXNlZA0KPj4+ICAgICAgICBvbiB0aGVpcg0KPj4+ICAgICAgICAgICAg ICAgICAgY3VycmVudCB3b3JrLCBzb21lIGluIHZpcnR1YWxpemVkIGVudmlyb25tZW50cywgc29t ZQ0KPj4+IGZvcg0KPj4+ICAgICAgICAgICAgICAgICAgaW5kaWNhdG9yIHNwZWNpZmljIGZvcm1h dHMsIHNvbWUgaW5kdXN0cnkgc3BlY2lmaWMNCj4+PiAgICAgICAgZXh0ZW5zaW9ucywNCj4+PiAg ICAgICAgICAgICAgICAgIGV0Yy4gIFRoZXJlIGlzIGFsc28gd29yayBkZXZlbG9waW5nIGJ5IG90 aGVyIGdyb3Vwcw0KPj4+ICAgICAgICB3aG8gaGF2ZQ0KPj4+ICAgICAgICAgICAgICAgICAgbWVu dGlvbmVkIHRoYXQgdGhleSB3aWxsIHRyYW5zaXRpb24gdGhlaXIgd29yayB0byBhbg0KPj4+ICAg ICAgICAgICAgICAgICAgaW50ZXJuYXRpb25hbCBzdGFuZGFyZHMgYm9keSBvbmNlIGl0IGlzIG1h dHVyZSwgc28NCj4+PiAgICAgICAgcm9vbSBoYXMgYmVlbg0KPj4+ICAgICAgICAgICAgICAgICAg bGVmdCBpbiB0aGUgY2hhcnRlciB0byBhY2NvbW1vZGF0ZSB0aGF0IHdvcmsuICBUaGUNCj4+PiAg ICAgICAgbmVlZCBmb3INCj4+PiAgICAgICAgICAgICAgICAgIGd1aWRhbmNlIG9uIHRoZSB0cmFu c3BvcnQgb3B0aW9ucyBoYXMgc3VyZmFjZWQgc28gdGhhdA0KPj4+ICAgICAgICAgICAgICAgICAg aW1wbGVtZW50ZXJzIHVuZGVyc3RhbmQgd2hlbiB0aGV5IG1heSBjaG9vc2UgYSBzcGVjaWZpYw0K Pj4+ICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0IG9wdGlvbiB0byBlbmFibGUgaW50ZXJvcGVy YWJsZSBpbnRlcmZhY2VzDQo+Pj4gICAgICAgIGJldHdlZW4NCj4+PiAgICAgICAgICAgICAgICAg IHByb2R1Y3RzLiAgVGhlIGd1aWRhbmNlIG1heSBiZSB1c2UgY2FzZSBzcGVjaWZpYyB3aGVyZQ0K Pj4+ICAgICAgICB0aWdodGVyDQo+Pj4gICAgICAgICAgICAgICAgICBzZWN1cml0eSBpcyBuZWVk ZWQgKFJJRCArSFRUUC9UTFMgd2l0aCB0aGUgb2JqZWN0DQo+Pj4gICAgICAgIGxldmVsIHNlY3Vy aXR5DQo+Pj4gICAgICAgICAgICAgICAgICBvcHRpb25zIGVuYWINCj4+PiANCj4+PiAgICAgICAg ICAgICAgbGVkKSBvciB3DQo+Pj4gICAgICAgICAgICAgIGhlcmUgZWFzZSBvZiBhY2Nlc3MgaXMg dGhlIGRyaXZlciAoUk9MSUUpIHdpdGggbm8gY2xpZW50DQo+Pj4gICAgICAgICAgICAgIHJlcXVp cmVtZW50cyBuZWNlc3NhcnkgKGNhbiB1c2UgYSBicm93c2VyKS4NCj4+PiANCj4+PiANCj4+PiAg ICAgICAgICAgICAgICAgIFdlIHdpbGwgZm9sbG93IHVwIHdpdGggdGhlIG1pbGUgc3RvbmVzLCBo ZXJlIHRoZSB0aGUNCj4+PiAgICAgICAgcmUtd3JpdGU6DQo+Pj4gDQo+Pj4gICAgICAgICAgICAg ICAgICA8aW50cm8+DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICBUaGUgTWFuYWdlZCBJbmNp ZGVudCBMaWdodHdlaWdodCBFeGNoYW5nZSAoTUlMRSkNCj4+PiAgICAgICAgd29ya2luZyBncm91 cA0KPj4+ICAgICAgICAgICAgICAgICAgZGV2ZWxvcHMgc3RhbmRhcmRzIHRvIHN1cHBvcnQgY29t cHV0ZXIgYW5kIG5ldHdvcmsNCj4+PiAgICAgICAgc2VjdXJpdHkNCj4+PiAgICAgICAgICAgICAg ICAgIGluY2lkZW50IG1hbmFnZW1lbnQ7IGFuIGluY2lkZW50IGlzIGFuIHVucGxhbm5lZCBldmVu dA0KPj4+ICAgICAgICB0aGF0DQo+Pj4gICAgICAgICAgICAgICAgICBvY2N1cnMgaW4gYW4gaW5m b3JtYXRpb24gdGVjaG5vbG9neSAoSVQpDQo+Pj4gICAgICAgIGluZnJhc3RydWN0dXJlLiBBbg0K Pj4+ICAgICAgICAgICAgICAgICAgaW5jaWRlbnQgY291bGQgYmUgYSBiZW5pZ24gY29uZmlndXJh dGlvbiBpc3N1ZSwgSVQNCj4+PiAgICAgICAgaW5jaWRlbnQsIGFuDQo+Pj4gICAgICAgICAgICAg ICAgICBpbmZyYWN0aW9uIHRvIGEgc2VydmljZSBsZXZlbCBhZ3JlZW1lbnQgKFNMQSksIGEgc3lz dGVtDQo+Pj4gICAgICAgICAgICAgICAgICBjb21wcm9taXNlLCBzb2NpYWxseSBlbmdpbmVlcmVk IHBoaXNoaW5nIGF0dGFjaywgb3IgYQ0KPj4+ICAgICAgICAgICAgICAgICAgZGVuaWFsLW9mLXNl cnZpY2UgKERvUykgYXR0YWNrLCBldGMuICBXaGVuIGFuDQo+Pj4gaW5jaWRlbnQgaXMNCj4+PiAg ICAgICAgICAgICAgICAgIGRldGVjdGVkLCBvciBzdXNwZWN0ZWQsIHRoZXJlIG1heSBiZSBhIG5l ZWQgZm9yDQo+Pj4gICAgICAgIG9yZ2FuaXphdGlvbnMgdG8NCj4+PiAgICAgICAgICAgICAgICAg IGNvbGxhYm9yYXRlLiBUaGlzIGNvbGxhYm9yYXRpb24gZWZmb3J0IG1heSB0YWtlDQo+Pj4gICAg ICAgIHNldmVyYWwgZm9ybXMNCj4+PiAgICAgICAgICAgICAgICAgIGluY2x1ZGluZyBqb2ludCBh bmFseXNpcywgaW5mb3JtYXRpb24gZGlzc2VtaW5hdGlvbiwNCj4+PiAgICAgICAgYW5kL29yIGEN Cj4+PiAgICAgICAgICAgICAgICAgIGNvb3JkaW5hdGVkIG9wZXJhdGlvbmFsIHJlc3BvbnNlLiAg RXhhbXBsZXMgb2YgdGhlDQo+Pj4gICAgICAgIHJlc3BvbnNlIG1heQ0KPj4+ICAgICAgICAgICAg ICAgICAgaW5jbHVkZSBmaWxpbmcgYSByZXBvcnQsIG5vdGlmeWluZyB0aGUgc291cmNlIG9mIHRo ZQ0KPj4+ICAgICAgICBpbmNpZGVudCwNCj4+PiAgICAgICAgICAgICAgICAgIHJlcXVlc3Rpbmcg dGhhdCBhIHRoaXJkIHBhcnR5IHJlc29sdmUvbWl0aWdhdGUgdGhlDQo+Pj4gICAgICAgIGluY2lk ZW50LA0KPj4+ICAgICAgICAgICAgICAgICAgc2hhcmluZyBzZWxlY3QgaW5kaWNhdG9ycyBvZiBj b21wcm9taXNlLCBvciByZXF1ZXN0aW5nDQo+Pj4gICAgICAgIHRoYXQgdGhlDQo+Pj4gICAgICAg ICAgICAgICAgICBzb3VyY2UgYmUgbG9jYXRlZC4gQnkgc2hhcmluZyBpbmRpY2F0b3JzIG9mIGNv bXByb21pc2UNCj4+PiAgICAgICAgYXNzb2NpYXRlZA0KPj4+ICAgICAgICAgICAgICAgICAgd2l0 aCBhbiBpbmNpZGVudCBvciBwb3NzaWJsZSB0aHJlYXQsIHRoZSBpbmZvcm1hdGlvbg0KPj4+ICAg ICAgICBiZWNvbWVzIGENCj4+PiAgICAgICAgICAgICAgICAgIHByb2FjdGl2ZSBkZWZlbnNlIGZv ciBvdGhlcnMgdGhhdCBtYXkgaW5jbHVkZQ0KPj4+ICAgICAgICBtaXRpZ2F0aW9uIG9wdGlvbnMu DQo+Pj4gICAgICAgICAgICAgICAgICBUaGUgSW5jaWRlbnQgT2JqZWN0IERlc2NyaXB0aW9uIEV4 Y2hhbmdlIEZvcm1hdA0KPj4+ICAgICAgICAoSU9ERUYpIGRlZmluZXMNCj4+PiAgICAgICAgICAg ICAgICAgIGFuIGluZm9ybWF0aW9uIGZyYW1ld29yayB0byByZXByZXNlbnQgY29tcHV0ZXIgYW5k DQo+Pj4gbmV0d29yaw0KPj4+ICAgICAgICAgICAgICAgICAgc2VjdXJpdHkgaW5jaWRlbnRzOyBJ T0RFRiBpcyBkZWZpbmVkIGluIFJGQyA1MDcwIGFuZA0KPj4+ICAgICAgICAgICAgICAgICAgaGFz IGJlZW4gZXh0ZW5kZWQgYnkgUkZDIDUwOTEgdG8gc3VwcG9ydCBwaGlzaGluZw0KPj4+ICAgICAg ICByZXBvcnRzOyBSRkMNCj4+PiAgICAgICAgICAgICAgICAgIDY0ODQgcHJvdmlkZXMgYSB0ZW1w bGF0ZSBmb3IgZGVmaW5pbmcgZXh0ZW5zaW9ucyB0bw0KPj4+IElPREVGLg0KPj4+ICAgICAgICAg ICAgICAgICAgUmVhbC10aW1lIEludGVyLW5ldHdvcmsgRGVmZW5zZSAoUklEKSBkZWZpbmVzIGEN Cj4+PiAgICAgICAgcHJvdG9jb2wgdG8NCj4+PiAgICAgICAgICAgICAgICAgIGZhY2lsaXRhdGUg c2hhcmluZyBjb21wdXRlciBhbmQgbmV0d29yayBzZWN1cml0eQ0KPj4+ICAgICAgICBpbmNpZGVu dHM7DQo+Pj4gICAgICAgICAgICAgICAgICBSSUQgaXMgZGVmaW5lZCBpbiBSRkMgNjU0NSwgYW5k IFJJRCBvdmVyIEhUVFBTIGlzDQo+Pj4gICAgICAgIGRlZmluZWQgaW4gUkZDDQo+Pj4gICAgICAg ICAgICAgICAgICA2NTQ2Lg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgPC9pbnRybz4NCj4+ PiANCj4+PiAgICAgICAgICAgICAgICAgIFRoZSBNSUxFIFdHIGlzIGZvY3VzZWQgb24gdHdvIGFy ZWFzLCBJT0RFRiB0aGUgZGF0YQ0KPj4+ICAgICAgICBmb3JtYXQgYW5kDQo+Pj4gICAgICAgICAg ICAgICAgICBleHRlbnNpb25zIHRvIHJlcHJlc2VudCBpbmNpZGVudCBhbmQgaW5kaWNhdG9yIGRh dGENCj4+PiAgICAgICAgYW5kIFJJRCwNCj4+PiAgICAgICAgICAgICAgICAgIHRoZSBwb2xpY3kg YW5kIHRyYW5zcG9ydCBmb3Igc3RydWN0dXJlZCBkYXRhLiAgV2l0aA0KPj4+ICAgICAgICByZXNw ZWN0IHRvDQo+Pj4gICAgICAgICAgICAgICAgICBJT0RFRiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2ls bDoNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIC0gUmV2aXNlIHRoZSBJT0RFRiBkb2N1bWVu dCB0byBpbmNvcnBvcmF0ZQ0KPj4+ICAgICAgICBlbmhhbmNlbWVudHMgYW5kDQo+Pj4gICAgICAg ICAgICAgICAgICBleHRlbnNpb25zIGJhc2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2U7IHVz ZSBieQ0KPj4+ICAgICAgICBDb21wdXRlcg0KPj4+ICAgICAgICAgICAgICAgICAgU2VjdXJpdHkg SW5jaWRlbnQgUmVzcG9uc2UgVGVhbXMgKENTSVJUcykgYW5kIG90aGVycw0KPj4+IGhhcw0KPj4+ ICAgICAgICAgICAgICAgICAgZXhwb3NlZCB0aGUgbmVlZCB0byBleHRlbmQgSU9ERUYgdG8gc3Vw cG9ydCBpbmR1c3RyeQ0KPj4+ICAgICAgICBzcGVjaWZpYw0KPj4+ICAgICAgICAgICAgICAgICAg ZXh0ZW5zaW9ucywgdXNlIGNhc2Ugc3BlY2lmaWMgY29udGVudCwgYW5kDQo+Pj4gICAgICAgIHJl cHJlc2VudGF0aW9ucyB0bw0KPj4+ICAgICAgICAgICAgICAgICAgYXNzb2NpYXRlIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG8gcmVwcmVzZW50ZWQgdGhyZWF0cw0KPj4+ICAgICAgICAoc3lzdGVtLA0K Pj4+ICAgICAgICAgICAgICAgICAgdGhyZWF0IGFjdG9ycywgY2FtcGFpZ25zLCBldGMuKS4gIFRo ZSB2YWx1ZSBvZg0KPj4+IGluZm9ybWF0aW9uDQo+Pj4gICAgICAgICAgICAgICAgICBzaGFyaW5n IGhhcyBiZWVuIGRlbW9uc3RyYXRlZCBhbmQgaGlnaGxpZ2h0ZWQgYXQgYW4NCj4+PiAgICAgICAg aW5jcmVhc2luZw0KPj4+ICAgICAgICAgICAgICAgICAgcmF0ZSB0aHJvdWdoIHRoZSBzdWNjZXNz IG9mIHRoZSBJbmZvcm1hdGlvbiBTaGFyaW5nIGFuZA0KPj4+ICAgICAgICAgICAgICAgICAgQW5h bHlzaXMgQ2VudGVycyAoSVNBQ3MpIGFuZCB0aGUgcmVjZW50IGN5YmVyIHNlY3VyaXR5DQo+Pj4g ICAgICAgIEV4ZWN1dGl2ZQ0KPj4+ICAgICAgICAgICAgICAgICAgT3JkZXIgaW4gdGhlIFVTLiAg SW50ZXJuYXRpb25hbCBncm91cHMsIHN1Y2ggYXMgdGhlDQo+Pj4gICAgICAgIE11bHRpbmF0aW9u YWwNCj4+PiAgICAgICAgICAgICAgICAgIEFzc29jaWF0aW9uIGZvciBDb2xsYWJvcmF0aXZlIEN5 YmVyIFNpdHVhdGlvbmFsDQo+Pj4gICAgICAgIEF3YXJlbmVzcyAoQ0NTQSkNCj4+PiAgICAgICAg ICAgICAgICAgIGhhdmUgYmVlbiBydW5uaW5nIGV4cGVyaW1lbnRzIHRvIGRldGVybWluZSB3aGF0 IGRhdGENCj4+PiAgICAgICAgaXMgdXNlZnVsIHRvDQo+Pj4gICAgICAgICAgICAgICAgICBleGNo YW5nZSBiZXR3ZWVuIGluZHVzdHJpZXMgYW5kIG5hdGlvbnMgdG8gZWZmZWN0aXZlbHkNCj4+PiAg ICAgICAgbWl0aWdhdGUNCj4+PiAgICAgICAgICAgICAgICAgIHRocmVhdHMuICBUaGUgd29yayBv ZiB0aGVzZSBhbmQgb3RoZXIgZ3JvdXBzIGhhdmUNCj4+PiAgICAgICAgaWRlbnRpZmllZCBvcg0K Pj4+ICAgICAgICAgICAgICAgICAgYXJlIHdvcmtpbmcgdG8gZGV2ZWxvcCBkYXRhIHJlcHJlc2Vu dGF0aW9ucyByZWxldmFudA0KPj4+ICAgICAgICB0byB0aGVpciB1c2UNCj4+PiAgICAgICAgICAg ICAgICAgIGNhc2VzIHRoYXQgbWF5IGNvbXBsaW1lbnQvZXh0ZW5kIElPREVGIG9yIGJlIHVzZWZ1 bCB0bw0KPj4+ICAgICAgICBleGNoYW5nZQ0KPj4+ICAgICAgICAgICAgICAgICAgdXNpbmcgUklE IGFuZCByZWxhdGVkIHRyYW5zcG9ydCBwcm90b2NvbHMuDQo+Pj4gDQo+Pj4gICAgICAgICAgICAg ICAgICAtIFByb3ZpZGUgZ3VpZGFuY2Ugb24gdGhlIGltcGxlbWVudGF0aW9uIGFuZCB1c2Ugb2YN Cj4+PiAgICAgICAgSU9ERUYgdG8gYWlkDQo+Pj4gICAgICAgICAgICAgICAgICBpbXBsZW1lbnRl cnMgaW4gZGV2ZWxvcGluZyBpbnRlcm9wZXJhYmxlDQo+Pj4gc3BlY2lmaWNhdGlvbnMuDQo+Pj4g DQo+Pj4gICAgICAgICAgICAgICAgICBXaXRoIHJlc3BlY3QgdG8gUklELCB0aGUgd29ya2luZyBn cm91cCB3aWxsOg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgLSBEZWZpbmUgYSByZXNvdXJj ZS1vcmllbnRlZCBhcHByb2FjaCB0byBjeWJlciBzZWN1cml0eQ0KPj4+ICAgICAgICAgICAgICAg ICAgaW5mb3JtYXRpb24gc2hhcmluZyB0aGF0IGZvbGxvd3MgdGhlIFJFU1QNCj4+PiAgICAgICAg YXJjaGl0ZWN0dXJhbCBzdHlsZS4NCj4+PiAgICAgICAgICAgICAgICAgIFRoaXMgbWVjaGFuaXNt IHdpbGwgYWxsb3cgQ1NJUlRTIHRvIGJlIG1vcmUgZHluYW1pYw0KPj4+ICAgICAgICBhbmQgYWdp bGUgaW4NCj4+PiAgICAgICAgICAgICAgICAgIGNvbGxhYm9yYXRpbmcgd2l0aCBhIGJyb2FkZXIs IGFuZCB2YXJ5aW5nIGNvbnN0aXR1ZW5jeS4NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIC0g UHJvdmlkZSBndWlkYW5jZSBvbiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHVzZSBvZg0KPj4+ICAg ICAgICBSSUQgdHJhbnNwb3J0cw0KPj4+ICAgICAgICAgICAgICAgICAgYmFzZWQgb24gdXNlIGNh c2VzLiAgVGhlIGd1aWRhbmNlIGRvY3VtZW50IHdpbGwgc2hvdw0KPj4+IHRoZQ0KPj4+ICAgICAg ICAgICAgICAgICAgcmVsYXRpb25zaGlwDQo+Pj4gICAgICAgICAgICAgICAgICBiZXR3ZWVuIHRy YW5zcG9ydCBvcHRpb25zIChSSUQgKyBSSUQgdHJhbnNwb3J0IGFuZA0KPj4+ICAgICAgICBJT0RF Ri9SSUQgKw0KPj4+ICAgICAgICAgICAgICAgICAgUk9MSUUpDQo+Pj4gICAgICAgICAgICAgICAg ICBhbmQgbWF5IGlkZW50aWZ5IHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHRyYW5zcG9ydA0KPj4+ ICAgICAgICBiaW5kaW5ncy4NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIC0gUklEIG1heSBy ZXF1aXJlIG1vZGlmaWNhdGlvbnMgdG8gYWRkcmVzcyBkYXRhDQo+Pj4gICAgICAgIHByb3ZlbmFu Y2UsDQo+Pj4gICAgICAgICAgICAgICAgICBhZGRpdGlvbmFsDQo+Pj4gICAgICAgICAgICAgICAg ICBwb2xpY3kgb3B0aW9ucywgb3Igb3RoZXIgY2hhbmdlcyBub3cgdGhhdCB0aGVyZSBhcmUNCj4+ PiAgICAgICAgbXVsdGlwbGUNCj4+PiAgICAgICAgICAgICAgICAgIGludGVyb3BlcmFibGUgaW1w bGVtZW50YXRpb25zIG9mIFJGQzY1NDUgYW5kDQo+Pj4gICAgICAgIFJGQzY1NDYuICBXaXRoIHRo ZQ0KPj4+ICAgICAgICAgICAgICAgICAgUklEIGltcGxlbWVudGF0aW9ucyBpbiB0aGUgb3BlbiBz b3VyY2UgY29tbXVuaXR5LA0KPj4+ICAgICAgICBpbmNyZWFzZWQgdXNlIGFuZA0KPj4+ICAgICAg ICAgICAgICAgICAgZXhwZXJpbWVudGF0aW9uIG1heSBkZW1vbnN0cmF0ZSB0aGUgbmVlZCBmb3Ig YQ0KPj4+IHJldmlzaW9uLg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgPG1pbGVzdG9uZXM+ DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICA8L21pbGVzdG9uZXM+DQo+Pj4gDQo+Pj4gDQo+ Pj4gICAgICAgICAgICAgICAgICBUaGFuayB5b3UhDQo+Pj4gICAgICAgICAgICAgICAgICBLYXRo bGVlbg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+ICAgICAgICAgICAgICAgICAgRnJvbTogbWlsZS1ib3VuY2Vz QGlldGYub3JnDQo+Pj4gICAgICAgIDxtYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPiA8bWFp bHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZz4NCj4+PiAgICAgICAgICAgICAgICAgIFttaWxlLWJv dW5jZXNAaWV0Zi5vcmcgPG1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmc+DQo+Pj4gICAgICAg IDxtYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmDQo+Pj4gICAgICAgICAg ICAgICAgICBPZiBTZWFuIFR1cm5lciBbdHVybmVyc0BpZWNhLmNvbQ0KPj4+ICAgICAgICA8bWFp bHRvOnR1cm5lcnNAaWVjYS5jb20+IDxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT5dDQo+Pj4gICAg ICAgICAgICAgICAgICBTZW50OiBXZWRuZXNkYXksIE1heSAwMSwgMjAxMyA5OjA0IFBNDQo+Pj4g ICAgICAgICAgICAgICAgICBUbzogbWlsZUBpZXRmLm9yZyA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+ DQo+Pj4gICAgICAgIDxtYWlsdG86bWlsZUBpZXRmLm9yZz4NCj4+PiAgICAgICAgICAgICAgICAg IFN1YmplY3Q6IFttaWxlXSByZS1jaGFydGVyIHJlLWJvb3QNCj4+PiANCj4+PiAgICAgICAgICAg ICAgICAgIEhpLA0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgSSdkIGxpa2UgdG8gcHJvcG9z ZSBhIHNpZ25pZmljYW50IHJlLXdyaXRlIG9mIHRoZQ0KPj4+IHByb3Bvc2VkDQo+Pj4gICAgICAg ICAgICAgICAgICBjaGFydGVyLiAgSQ0KPj4+ICAgICAgICAgICAgICAgICAgdGhpbmsgdGhlcmUn cyB0b28gbXVjaCBoaXN0b3J5IHRoYXQncyBub3QgcmVhbGx5DQo+Pj4gICAgICAgIG5lZWRlZCBh bnkgbW9yZSBhbmQNCj4+PiAgICAgICAgICAgICAgICAgIHRoZXJlJ3Mgc29tZSByZXBldGl0aW9u IHRoYXQncyB1bm5lZWRlZC4gIEkgYWxzbyB0aGluaw0KPj4+ICAgICAgICBpdCdzIGEgbGl0dGxl DQo+Pj4gICAgICAgICAgICAgICAgICBvcGVuIGVuZGVkIHdydCB3aGF0J3MgYWN0dWFsbHkgZ29p bmcgdG8gZ2V0IGRvbmUuDQo+Pj4gICAgICAgIEJhc2VkIG9uIHJlY2VudA0KPj4+ICAgICAgICAg ICAgICAgICAgZXhwZXJpZW5jZSwgSSBoYXZlIGEgc3Ryb25nIGZlZWxpbmcgdGhhdCB0aGUgY3Vy cmVudA0KPj4+ICAgICAgICBjaGFydGVyDQo+Pj4gICAgICAgICAgICAgICAgICB3b3VsZG4ndA0K Pj4+ICAgICAgICAgICAgICAgICAgZ2V0IHRocm91Z2ggdGhlIHByb2Nlc3MuDQo+Pj4gDQo+Pj4g ICAgICAgICAgICAgICAgICBJJ20gcHJvcG9zaW5nIGZvdXIgc2VjdGlvbnM6IGludHJvLCBpb2Rl Zi1yZWxhdGVkDQo+Pj4gICAgICAgIHdvcmssIHJpZC1yZWxhdGVkDQo+Pj4gICAgICAgICAgICAg ICAgICB3b3JrLCBtaWxlc3RvbmVzLg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgVGhlIGlu dHJvIHNob3VsZDoNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIC0gZXhwbGFpbiB3aGF0IHRo ZSBXRyBkb2VzOiBkZXZlbG9wIHN0YW5kYXJkcyB0byBkbw0KPj4+IGZvby4NCj4+PiAgICAgICAg ICAgICAgICAgIC0gc3VtbWFyaXplIHdoYXQgZm9vIGlzLg0KPj4+ICAgICAgICAgICAgICAgICAg LSBoaWdobGlnaHQgZXhpc3RpbmcgUkZDcyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBzcGFjZToNCj4+ PiAgICAgICAgICAgICAgICAgICAgICAgIElPREVGOiA1MDcwLzUwOTEvNjg0OCAmIFJJRDogNjU0 NS82NTQ2Lg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgVGhlbiB3ZSB0YWxrIGFib3V0IHdo YXQgZHJhZnRzIHRoZSBXRyB3aWxsIHByb2R1Y2UgZm9yDQo+Pj4gICAgICAgIHRoZSB0d28NCj4+ PiAgICAgICAgICAgICAgICAgIHRvcGljIGFyZWFzLg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAg ICAgSG93IGFib3V0IHRoaXMgKG9yIHNvbWV0aGluZyBsaWtlIHRoaXMpOg0KPj4+IA0KPj4+ICAg ICAgICAgICAgICAgICAgPGludHJvPg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgVGhlIE1h bmFnZWQgSW5jaWRlbnQgTGlnaHR3ZWlnaHQgRXhjaGFuZ2UgKE1JTEUpDQo+Pj4gICAgICAgIHdv cmtpbmcgZ3JvdXANCj4+PiAgICAgICAgICAgICAgICAgIGRldmVsb3BzIHN0YW5kYXJkcyB0byBz dXBwb3J0IGNvbXB1dGVyIGFuZCBuZXR3b3JrDQo+Pj4gICAgICAgIHNlY3VyaXR5DQo+Pj4gICAg ICAgICAgICAgICAgICBpbmNpZGVudCBtYW5hZ2VtZW50OyBhbiBpbmNpZGVudCBpcyBhbiB1bnBs YW5uZWQgZXZlbnQNCj4+PiAgICAgICAgdGhhdA0KPj4+ICAgICAgICAgICAgICAgICAgb2NjdXJz IGluIGFuIGluZm9ybWF0aW9uIHRlY2hub2xvZ3kgKElUKQ0KPj4+ICAgICAgICBpbmZyYXN0cnVj dHVyZS4gQW4NCj4+PiAgICAgICAgICAgICAgICAgIGluY2lkZW50IGNvdWxkIGJlIGEgYmVuaWdu IGNvbmZpZ3VyYXRpb24gaXNzdWUsIElUDQo+Pj4gICAgICAgIGluY2lkZW50LCBhbg0KPj4+ICAg ICAgICAgICAgICAgICAgaW5mcmFjdGlvbiB0byBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IChT TEEpLCBhIHN5c3RlbQ0KPj4+ICAgICAgICAgICAgICAgICAgY29tcHJvbWlzZSwgc29jaWFsbHkg ZW5naW5lZXJlZCBwaGlzaGluZyBhdHRhY2ssIG9yIGENCj4+PiAgICAgICAgICAgICAgICAgIGRl bmlhbC1vZi1zZXJ2aWNlIChEb1MpIGF0dGFjaywgZXRjLiAgV2hlbiBhbg0KPj4+IGluY2lkZW50 IGlzDQo+Pj4gICAgICAgICAgICAgICAgICBkZXRlY3RlZCwgb3Igc3VzcGVjdGVkLCB0aGVyZSBt YXkgYmUgYSBuZWVkIGZvcg0KPj4+ICAgICAgICBvcmdhbml6YXRpb25zIHRvDQo+Pj4gICAgICAg ICAgICAgICAgICBjb2xsYWJvcmF0ZS4gVGhpcyBjb2xsYWJvcmF0aW9uIGVmZm9ydCBtYXkgdGFr ZQ0KPj4+ICAgICAgICBzZXZlcmFsIGZvcm1zDQo+Pj4gICAgICAgICAgICAgICAgICBpbmNsdWRp bmcgam9pbnQgYW5hbHlzaXMsIGluZm9ybWF0aW9uIGRpc3NlbWluYXRpb24sDQo+Pj4gICAgICAg IGFuZC9vciBhDQo+Pj4gICAgICAgICAgICAgICAgICBjb29yZGluYXRlZCBvcGVyYXRpb25hbCBy ZXNwb25zZS4gIEV4YW1wbGVzIG9mIHRoZQ0KPj4+ICAgICAgICByZXNwb25zZSBtYXkNCj4+PiAg ICAgICAgICAgICAgICAgIGluY2x1ZGUgZmlsaW5nIGEgcmVwb3J0LCBub3RpZnlpbmcgdGhlIHNv dXJjZSBvZiB0aGUNCj4+PiAgICAgICAgaW5jaWRlbnQsDQo+Pj4gICAgICAgICAgICAgICAgICBy ZXF1ZXN0aW5nIHRoYXQgYSB0aGlyZCBwYXJ0eSByZXNvbHZlL21pdGlnYXRlIHRoZQ0KPj4+ICAg ICAgICBpbmNpZGVudCwNCj4+PiAgICAgICAgICAgICAgICAgIHNoYXJpbmcgaW5kaWNhdG9ycyBv ZiBjb21wcm9taXNlLCBvciByZXF1ZXN0aW5nIHRoYXQNCj4+PiAgICAgICAgdGhlIHNvdXJjZQ0K Pj4+ICAgICAgICAgICAgICAgICAgYmUgbG9jYXRlZC4gVGhlIEluY2lkZW50IE9iamVjdCBEZXNj cmlwdGlvbiBFeGNoYW5nZQ0KPj4+ICAgICAgICBGb3JtYXQNCj4+PiAgICAgICAgICAgICAgICAg IChJT0RFRikgZGVmaW5lcyBhbiBpbmZvcm1hdGlvbiBmcmFtZXdvcmsgdG8gcmVwcmVzZW50DQo+ Pj4gICAgICAgIGNvbXB1dGVyDQo+Pj4gICAgICAgICAgICAgICAgICBhbmQgbmV0d29yayBzZWN1 cml0eSBpbmNpZGVudHM7IElPREVGIGlzIGRlZmluZWQgaW4NCj4+PiAgICAgICAgUkZDIDUwNzAg YW5kDQo+Pj4gICAgICAgICAgICAgICAgICBoYXMgYmVlbiBleHRlbmRlZCBieSBSRkMgNTA5MSB0 byBzdXBwb3J0IHBoaXNoaW5nDQo+Pj4gICAgICAgIHJlcG9ydHM7IFJGQw0KPj4+ICAgICAgICAg ICAgICAgICAgNjQ4NCBwcm92aWRlcyBhIHRlbXBsYXRlIGZvciBkZWZpbmluZyBleHRlbnNpb25z IHRvDQo+Pj4gSU9ERUYuDQo+Pj4gICAgICAgICAgICAgICAgICBSZWFsLXRpbWUgSW50ZXItbmV0 d29yayBEZWZlbnNlIChSSUQpIGRlZmluZXMgYQ0KPj4+ICAgICAgICBwcm90b2NvbCB0bw0KPj4+ ICAgICAgICAgICAgICAgICAgZmFjaWxpdGF0ZSBzaGFyaW5nIGNvbXB1dGVyIGFuZCBuZXR3b3Jr IHNlY3VyaXR5DQo+Pj4gICAgICAgIGluY2lkZW50czsNCj4+PiAgICAgICAgICAgICAgICAgIFJJ RCBpcyBkZWZpbmVkIGluIFJGQyA2NTQ1LCBhbmQgUklEIG92ZXIgSFRUUFMgaXMNCj4+PiAgICAg ICAgZGVmaW5lZCBpbiBSRkMNCj4+PiAgICAgICAgICAgICAgICAgIDY1NDYuDQo+Pj4gDQo+Pj4g ICAgICAgICAgICAgICAgICA8L2ludG8+DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICBUaGlz IHdvcmtpbmcgZ3JvdXAgZG9lcyB0d28gdGhpbmdzIElPREVGIGFuZCBSSUQ7IHdlDQo+Pj4gICAg ICAgIHNob3VsZCBiZSBjbGVhcg0KPj4+ICAgICAgICAgICAgICAgICAgYWJvdXQgdGhhdCBhbmQg dGhlbiBsaXN0IHRoZSBhY3R1YWwgZG9jdW1lbnRzIHdlJ3JlDQo+Pj4gICAgICAgIGdvaW5nIHRv IHByb2R1Y2UNCj4+PiAgICAgICAgICAgICAgICAgIHRoYXQgcmVsYXRlIHRvIGVhY2ggb25lLiAg Rm9yIHRoZSBsaXN0IG9mIGRlbGl2ZXJhYmxlcw0KPj4+ICAgICAgICBpdCBsb29rcyBsaWtlDQo+ Pj4gICAgICAgICAgICAgICAgICB0aGVyZSdzIHRocmVlIDUwNzBiaXMsIGEgcmVmZXJlbmNlL2d1 aWRhbmNlIGRyYWZ0LA0KPj4+IGFuZCBhDQo+Pj4gICAgICAgICAgICAgICAgICByZXNvdXJjZS1v cmllbnRlZCBpbmRpY2F0b3IgZXhjaGFuZ2U/DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICBR dWVzdGlvbnM6DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICBBcmUgdGhlIEdSQyBhbmQgRm9y ZW5zaWMgZHJhZnRzIGRlYWQtZGVhZD8gIEkgYXNzdW1lDQo+Pj4gICAgICAgIHRoZXknZCBub3Qg YmUNCj4+PiAgICAgICAgICAgICAgICAgIGluY2x1ZGVkIGluIHRoZSBtaWxlc3RvbmUgbGlzdC4N Cj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIElzIHRoZXJlIGdvaW5nIHRvIG9ubHkgYmUgb25l IDUwNzBiaXMgZHJhZnQgb3Igd2lsbA0KPj4+ICAgICAgICB0aGVyZSBiZSBhDQo+Pj4gICAgICAg ICAgICAgICAgICA1MDcwYmlzICsNCj4+PiAgICAgICAgICAgICAgICAgIG90aGVyIG9wdGlvbmFs IGV4dGVuc2lvbiBkcmFmdHM/ICBJIGFzc3VtZSBpdCdzIGp1c3QgYQ0KPj4+ICAgICAgICA1MDcw YmlzDQo+Pj4gICAgICAgICAgICAgICAgICBiYXNlZCBvbg0KPj4+ICAgICAgICAgICAgICAgICAg dGhlIG1pbGVzdG9uZXMgYnV0IHRob3VnaHQgSSdkIGFzay4NCj4+PiANCj4+PiAgICAgICAgICAg ICAgICAgIEFyZSB3ZSBvbmx5IGV4dGVuZGluZyBJT0RFRiBiYXNlZCBvbiB1c2Ugb3IgaXMgdGhl cmUNCj4+PiAgICAgICAgc29tZXRoaW5nDQo+Pj4gICAgICAgICAgICAgICAgICBlbHNlIHdlDQo+ Pj4gICAgICAgICAgICAgICAgICBuZWVkIHRvIGNvbnNpZGVyPw0KPj4+IA0KPj4+ICAgICAgICAg ICAgICAgICAgSG93IGFib3V0IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgKG5lZWQgc29t ZSBoZWxwDQo+Pj4gICAgICAgIGZpbGxpbmcNCj4+PiAgICAgICAgICAgICAgICAgIGluIHRoZQ0K Pj4+ICAgICAgICAgICAgICAgICAgYmxhbmtzKToNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAg IDxpb2RlZj4NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIFdpdGggcmVzcGVjdCB0byBJT0RF RiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbDoNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIC0g UmV2aXNlIHRoZSBJT0RFRiBkb2N1bWVudCB0byBpbmNvcnBvcmF0ZQ0KPj4+ICAgICAgICBlbmhh bmNlbWVudHMgYW5kDQo+Pj4gICAgICAgICAgICAgICAgICBleHRlbnNpb25zIGJhc2VkIG9uIG9w ZXJhdGlvbmFsIGV4cGVyaWVuY2U7IHVzZSBieQ0KPj4+ICAgICAgICBDb21wdXRlcg0KPj4+ICAg ICAgICAgICAgICAgICAgU2VjdXJpdHkgSW5jaWRlbnQgUmVzcG9uc2UgVGVhbXMgKENTSVJUcykg YW5kIG90aGVycw0KPj4+IGhhcw0KPj4+ICAgICAgICAgICAgICAgICAgZXhwb3NlZCB0aGUgbmVl ZCB0byBleHRlbmQgSU9ERUYgdG8gc3VwcG9ydCB4LCB5LCB6DQo+Pj4gICAgICAgIChuZWVkIHRv IGhhdmUNCj4+PiAgICAgICAgICAgICAgICAgIHNvbWUgaWRlYSB3aGF0J3MgbWlzc2luZykgYmFz ZSBvbiBhLCBiLCBjIChuZWVkIHRvDQo+Pj4gICAgICAgIGtub3cgYSBiaXQNCj4+PiAgICAgICAg ICAgICAgICAgIG1vcmUgYWJvdXQgd2h5IHN0dWZmIGlzIG1pc3NpbmcgZGlkIHNvbWV0aGluZyBu ZXcgcG9wDQo+Pj4gICAgICAgIHVwPykuDQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICAtIFBy b3ZpZGUgZ3VpZGFuY2Ugb24gdGhlIGltcGxlbWVudGF0aW9uIGFuZCB1c2Ugb2YNCj4+PiAgICAg ICAgSU9ERUYgdG8gYWlkDQo+Pj4gICAgICAgICAgICAgICAgICBpbXBsZW1lbnRlcnMgaW4gZGV2 ZWxvcGluZyBpbnRlcm9wZXJhYmxlDQo+Pj4gc3BlY2lmaWNhdGlvbnMuDQo+Pj4gDQo+Pj4gICAg ICAgICAgICAgICAgICA8L2lvZGVmPg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgRm9yIFJJ RDoNCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIEFyZSB3ZSBhbHNvIGRvaW5nIGRlZmluaW5n IGd1aWRhbmNlIGZvciBSSUQgYXMgd2VsbCBvcg0KPj4+ICAgICAgICBpcyB0aGF0DQo+Pj4gICAg ICAgICAgICAgICAgICBpbmNvcnBvcmF0ZWQgaW4gdGhlIElPREVGIGd1aWRhbmNlPw0KPj4+IA0K Pj4+ICAgICAgICAgICAgICAgICAgSXMgUklEIGl0c2VsZiBnb2luZyB0byBiZSB1bnRvdWNoZWQg YW5kIHdlJ3JlIGp1c3QNCj4+PiAgICAgICAgcHJvZHVjaW5nIGEgbmV3DQo+Pj4gICAgICAgICAg ICAgICAgICAidHJhbnNwb3J0Ij8NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIElzIGl0IGp1 c3QgZm9yIGluZGljYXRvcnMgb3IgaXMgaXQgZm9yIHRoZSB3aG9sZQ0KPj4+ICAgICAgICBpbmNp ZGVudD8gIE9yIGhhcw0KPj4+ICAgICAgICAgICAgICAgICAgImluZGljYXRvcnMiIG92ZXIgdGFr ZW4gImluY2lkZW50Ij8NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIDxyaWQ+DQo+Pj4gDQo+ Pj4gICAgICAgICAgICAgICAgICBXaXRoIHJlc3BlY3QgdG8gUklELCB0aGUgd29ya2luZyBncm91 cCB3aWxsOg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgLSBEZWZpbmUgYSByZXNvdXJjZS1v cmllbnRlZCBhcHByb2FjaCB0byBjeWJlciBzZWN1cml0eQ0KPj4+ICAgICAgICAgICAgICAgICAg aW5mb3JtYXRpb24gc2hhcmluZyB0aGF0IGZvbGxvd3MgdGhlIFJFU1QNCj4+PiAgICAgICAgYXJj aGl0ZWN0dXJhbCBzdHlsZS4NCj4+PiAgICAgICAgICAgICAgICAgIFRoaXMgbWVjaGFuaXNtIHdp bGwgYWxsb3cgQ1NJUlRTIHRvIGJlIG1vcmUgZHluYW1pYw0KPj4+ICAgICAgICBhbmQgYWdpbGUg aW4NCj4+PiAgICAgICAgICAgICAgICAgIGNvbGxhYm9yYXRpbmcgd2l0aCBhIGJyb2FkZXIsIGFu ZCB2YXJ5aW5nIGNvbnN0aXR1ZW5jeS4NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgIDwvcmlk Pg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgPG1pbGVzdG9uZXM+DQo+Pj4gDQo+Pj4gICAg ICAgICAgICAgICAgICBUaGVzZSBsb29rZWQgZmluZSwgYnV0IEknZCBsaWtlIHNvbWUgYWN0dWFs IGRhdGVzIGZvcg0KPj4+ICAgICAgICB0aGUgVEJEcyA7KQ0KPj4+IA0KPj4+ICAgICAgICAgICAg ICAgICAgPC9taWxlc3RvbmVzPg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAgICAgc3B0DQo+Pj4g ICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+ICAgICAgICAgICAgICAgICAgbWlsZSBtYWlsaW5nIGxpc3QNCj4+PiAgICAg ICAgbWlsZUBpZXRmLm9yZyA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+IDxtYWlsdG86bWlsZUBpZXRm Lm9yZz4NCj4+PiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t aWxlDQo+Pj4gDQo+Pj4gICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gICAgICAgICAgICAgIG1pbGUgbWFpbGluZyBsaXN0DQo+ Pj4gICAgICAgIG1pbGVAaWV0Zi5vcmcgPG1haWx0bzptaWxlQGlldGYub3JnPiA8bWFpbHRvOm1p bGVAaWV0Zi5vcmc+DQo+Pj4gICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlsZQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG1pbGUgbWFpbGluZyBsaXN0DQo+PiBtaWxlQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCj4+IA0K From pkampana@cisco.com Thu Jun 6 11:25:53 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC72921E809B for ; Thu, 6 Jun 2013 11:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5jVUJuYMR2r for ; Thu, 6 Jun 2013 11:25:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29E21E805E for ; Thu, 6 Jun 2013 11:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18960; q=dns/txt; s=iport; t=1370543144; x=1371752744; h=from:to:subject:date:message-id:mime-version; bh=vnR0tLxjQvDEsGhm4w3HKzXYzUXPbzHM/ETTAb6zPpU=; b=hvLUGTEvZ+MYLldXW5VZoOHfsPzuUUXMdvoyWwGLSiY7pM6+EcvTcBeg mORmubuY4qWfoRphNQ6yl0FUctYJ26opyyGU7V3VdOPX4fjOtIsLjcvkt ONLG67Y0XenTJfLCMoJO37sKC+o6+DpB7e6QhqsS/pAxyeLM64Lnxa4tk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFABvTsFGtJXHB/2dsb2JhbABZgkVEMK1NiTWIRXoWdIIjAQEBBC1eAQgRBAEBCx05FAkJAQQBEgiIBQy7dY8BN4J7YQOYaJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208,217";a="219516465" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 18:25:43 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r56IPhgd008596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 18:25:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 13:25:43 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" , "'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com)" Thread-Topic: Request for draft reviews - review of FC5070-bis Thread-Index: Ac5i4z6UXWFgBViZRm66bWD5p9F0Rw== Date: Thu, 6 Jun 2013 18:25:43 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.113] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753C8AC8xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of FC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:25:53 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753C8AC8xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Good starting point. Some comments and nits below from my first pass. There should be more when I review again. I remember sometime in the past there was a discussion about what is an in= cidents if that should be updated in the 5070. I see that in your draft an = incident is used as it was in 5070. I was just wondering if we had reached = a consensus on it. I also didn't see "uid" and "set id" definitions in the draft. I don't see the EMailDetails class described in the document. Nits: - Should "This document contains changes with respect to its predecessor RFC5070:" be bulleted? - The list in "This class will contain indicators from the list below " is not exactly below. The same for "the following included indicators are ones commonly used ". And the same = for me occurrences of "following" in this section - I am not sure if we want to keep the "

 <= /p>

Hi Paul,

 <= /p>

Good starting point. Some= comments and nits below from my first pass.

There should be more when= I review again.

 <= /p>

I remember sometime in th= e past there was a discussion  about what is an incidents if that shou= ld be updated in the 5070. I see that in your draft an incident is used as it was in 5070. I was just wondering if we had reached a consen= sus on it.

 <= /p> 

I also didn’t see “uid” and “set id” definitions in the draft.

 <= /p> 

I don’t see the EMailDetails class describe=
d in the document.

 <=
/p>

Nits:

- Should “This document contains changes with respect to its predecessor=



      RFC5070:=
” be bulleted?


- The list in “This class will contain indicators from

      the list be=
low ” is not exactly below. The sam=
e for “the


      following i=
ncluded indicators are ones commonly used ”. And the same for me occurrences of “following” in thi=
s section


- I am not sure if we want to keep the R=
20;<!-- CHANGE:” comments in the draft


- there are some XML complexType like “SoftwareType 


I aqlso see that you will have usecases-exa=
mples in this doc, so mayne I will remove mine from the guidance document.<=
o:p>


 


Rgs,

Panos

 <=
/p>

 <=
/p>

 <=
/p>





From: mile-bou=
nces@ietf.org [mailto:mile-bounces@ietf.org]
On Behalf Of Moriarty, Kathleen

Sent: Friday, May 17, 2013 2:13 PM

To: mile@ietf.org

Subject: [mile] Request for draft reviews






 




Greetings!






 






We have had a number of documents updat=
ed since the last meeting.  Thank you to all of the editors for making=
 the requested changes!  The current list of drafts up for review
 (including those that will be a part of the WG after the charter update) i=
nclude:






 






RFC5070-bis (IODEF Revision):







 






Draft on IODEF Guidance:






(input from experience, real use cases,=
 and draft review will be helpful)







 






Structured Cybersecurity Information dr=
aft (close to final):







 






IODEF Enumeration Reference Format:







 






Resource-Oriented Lightweight Indicator=
 Exchange (ROLIE):








 






Please take some time to review the dra=
fts and provide feedback to the list.  It would be helpful if we can i=
terate on most of them prior to the next meeting.  A couple of
 the drafts are very close to being done.  The list of current drafts =
and published RFCs can be found at the following link:






 






We will follow up soon on the charter u=
pdate as well.






 






Thank you all in advance!

Kathleen






 






 
--_000_1C9F17D1873AFA47A969C4DD98F98A753C8AC8xmbrcdx10ciscocom_-- From pkampana@cisco.com Thu Jun 6 12:41:52 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D63D21F9289 for ; Thu, 6 Jun 2013 12:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2ZgnOrdDsk3 for ; Thu, 6 Jun 2013 12:41:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9255A11E80FD for ; Thu, 6 Jun 2013 12:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25759; q=dns/txt; s=iport; t=1370547703; x=1371757303; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=z0jfjn0KiDoM1Os+Nkw5AbyGFRRDzZoBdvVyO16RA3U=; b=mS5FzL743K4E9MbAcDdUoyNb6w8EtfHCk6IkE/PeO4M+M7FFPSg7wASP iSF6nKk271iMb+OpzVTRT3AILXnFzbWS0vIcw49KeUUB9EFAk0hHerMpu 9n7rbwZ9fYrYOAbMDKTOdyQ1IrAQgyTyNq822ICdYO24TvhPdYgo9Ws3T 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAPnksFGtJXG+/2dsb2JhbABZgkVEMK1QiTWIRXoWdIIjAQEBBC1cAgEIEQQBAQsWBwcyFAkIAQEEARIIAYgEDLtZjwEGBwIoAQIEgnRhA5hokBeDD4In X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208,217";a="216771908" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 06 Jun 2013 19:41:41 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56JfejX018152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 19:41:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 14:41:40 -0500 From: "Panos Kampanakis (pkampana)" To: Adam Montville , "mile@ietf.org" , Adam Montville Thread-Topic: [mile] Request for draft reviews - review of IODEF Enumeration Reference Thread-Index: Ac5iywbBL2OPl7oFTvaNQKS+LaneQQAET99QAAROS4A= Date: Thu, 6 Jun 2013 19:41:39 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A753C8B6E@xmb-rcd-x10.cisco.com> References: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> <05BCCEB107AF88469B9F99783D47C1D66F2D3B@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F2D3B@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.113] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A753C8B6Exmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:41:52 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A753C8B6Exmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You probably have seen this http://www.ietf.org/rfc/rfc2434.txt but I am po= inting it out anyway From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Thursday, June 06, 2013 1:39 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org; Adam Mo= ntville Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration= Reference Thank you! I'll make the changes you recommend. Also, are there good IANA-related RFCs I can look at to tighten this draft = up a bit? What I was intending for the IANA section is to convey both what= the registry contains and the format of each element therein. If there's a better way to do this, let's do it. Adam From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 8:33 AM To: Moriarty, Kathleen; mile@ietf.org; Adam Montville= (amontville@tripwire.com) Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration= Reference Hi Adam, I think this is close to being done. I had reviewed in the past and the reg= istry format is as we had all agreed. I did a fresh review and had some minor nits and suggestions, and some conf= usion for the IANA considerations section. - maybe rephrase "but one that seems the most appropriate at this point is = to..." to "but the most appropriate at this point is to..." - "especially enumerations such as CEE, CVE, CCE" maybe put informative references for CEE, CVE and CCE? - "Where id_type is an IANA-registered type having the form..." I am propos= ing to rephrase the paragraph a little to avoid the "And where..." "The format of the ReferenceName MUST follow the form of id_type:version:id where id_type is an IANA-registered type having the form The version is an IANA-registered type having the form The id is the actual enumeration identifier string." - In section "4 IANA Considerations", it is not very clear to me what each= paragraph is trying to convey. It this section trying to describe the IANA= registry or the format of a registry update request? To me it seems it is = mostly the former with some info on the latter. Should the "Name of the Registry: "Enumeration Reference Type Identifiers""= be in the "Fields to record in the registry: "? Does the paragraph "The registry is intended to enable enumeration value ad= ditions..." describe what the IANA registry represents or should it be in t= he registry request for a new value? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank yo= u to all of the editors for making the requested changes! The current list= of drafts up for review (including those that will be a part of the WG aft= er the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/ Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the list= . It would be helpful if we can iterate on most of them prior to the next = meeting. A couple of the drafts are very close to being done. The list of= current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up soon on the charter update as well. Thank you all in advance! Kathleen ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. --_000_1C9F17D1873AFA47A969C4DD98F98A753C8B6Exmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You probably have seen th= is http://www.ietf.org/rfc/rfc= 2434.txt but I am pointing it out anyway

 <= /p>

 <= /p>

From: Adam Mon= tville [mailto:Adam.Montville@cisecurity.org]
Sent: Thursday, June 06, 2013 1:39 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org; = Adam Montville
Subject: RE: [mile] Request for draft reviews - review of IODEF Enum= eration Reference

 

Thank you!  I’= ll make the changes you recommend.

 <= /p>

Also, are there good IANA= -related RFCs I can look at to tighten this draft up a bit?  What I wa= s intending for the IANA section is to convey both what the registry contains and the format of each element therein.

 <= /p>

If there’s a better= way to do this, let’s do it.

 <= /p>

Adam

 <= /p>

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 06, 2013 8:33 AM
To: Moriarty, Kathleen; mile@ietf.o= rg; Adam Montville (amontvil= le@tripwire.com)
Subject: Re: [mile] Request for draft reviews - review of IODEF Enum= eration Reference

 

Hi Adam,

 <= /p>

I think this is close to = being done. I had reviewed in the past and the registry format is as we had= all agreed.

I did a fresh review and = had some minor nits and suggestions, and some confusion for the IANA consid= erations section.

 <= /p> 

- maybe rephrase “but one that seems the most appropriate at this point is t=
o...” to “but the most appropriate at this point is to...”
 
- “especially enumerations such as
   CEE, CVE, CCE” maybe put informative references for CEE, CVE and=
 CCE?
 
- “Where id_type is an IANA-registered type having the form...” I am proposing to rephrase the paragraph a littl=
e to avoid the “And where…”
“T=
he format of the ReferenceName MUST follow the form of

      id_type:ver=
sion:id


   where id_type is an IANA-regi=
stered type having the form


      <Abbrevi=
ation>


   The version is an IANA-regist=
ered type having the form


      <Version=
>


   The id is the actual enumerat=
ion identifier string.”


 


- In section “4  IANA Considerations&#=
8221;, it is not very clear to me what each paragraph is trying to convey. =
It this section trying to describe the IANA registry or the format of a reg=
istry update request? To me it seems it is mostly the former with some info=
 on the latter.  


Should the “Name of the Registry: "Enumeration Reference Type Identifier=
s"” be in the “Fields to record in the registry: ”? 


Does the paragraph “The registry is intended to enable enumeration value addi=
tions...” describe what the IANA re=
gistry represents or should it be in the registry request for a new value?<=
/span>


 <=
/p>

Rgs,

Panos

 <=
/p>

 <=
/p>

 <=
/p>





From:
mile-bounces@ietf.org [mailto:mile-bounces@ietf.org]
On Behalf Of Moriarty, Kathleen

Sent: Friday, May 17, 2013 2:13 PM

To: mile@ietf.org

Subject: [mile] Request for draft reviews






 




Greetings!






 






We have had a number of documents updat=
ed since the last meeting.  Thank you to all of the editors for making=
 the requested changes!  The current list of drafts up for review
 (including those that will be a part of the WG after the charter update) i=
nclude:






 






RFC5070-bis (IODEF Revision):







 






Draft on IODEF Guidance:






(input from experience, real use cases,=
 and draft review will be helpful)







 






Structured Cybersecurity Information dr=
aft (close to final):







 






IODEF Enumeration Reference Format:







 






Resource-Oriented Lightweight Indicator=
 Exchange (ROLIE):








 






Please take some time to review the dra=
fts and provide feedback to the list.  It would be helpful if we can i=
terate on most of them prior to the next meeting.  A couple of
 the drafts are very close to being done.  The list of current drafts =
and published RFCs can be found at the following link:






 






We will follow up soon on the charter u=
pdate as well.






 






Thank you all in advance!

Kathleen






 






 






...




This message and attachments may contain confidential information. If it ap=
pears that this message was sent to you by mistake, any retention, dissemin=
ation, distribution or copying of this message and attachments is strictly =
prohibited. Please notify the sender
 immediately and permanently delete the message and any attachments.
--_000_1C9F17D1873AFA47A969C4DD98F98A753C8B6Exmbrcdx10ciscocom_-- From takeshi_takahashi@nict.go.jp Thu Jun 6 16:45:50 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618C21F944C for ; Thu, 6 Jun 2013 16:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKaFXGcL-imb for ; Thu, 6 Jun 2013 16:45:45 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2B21F93D4 for ; Thu, 6 Jun 2013 16:45:44 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r56NjZil020113; Fri, 7 Jun 2013 08:45:35 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r56NjZ2T014693; Fri, 7 Jun 2013 08:45:35 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r56NjZdf014690; Fri, 7 Jun 2013 08:45:35 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id ECB4D16958; Fri, 7 Jun 2013 08:45:34 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail1.nict.go.jp (NICT Mail) with ESMTP id E6C8016956; Fri, 7 Jun 2013 08:45:34 +0900 (JST) From: "Takeshi Takahashi" To: "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , References: <1C9F17D1873AFA47A969C4DD98F98A753C89FE@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753C89FE@xmb-rcd-x10.cisco.com> Date: Fri, 7 Jun 2013 08:45:35 +0900 Message-ID: <003301ce630f$f0c33fb0$d249bf10$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHz3n4J3rHmxLifLlgha/2ehXPWR5jeYc8g Content-Language: ja Subject: Re: [mile] Request for draft reviews - review of SCI X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 23:45:50 -0000 Hi Panos, Thank you very much for reviewing the draft again. I'll check the XML/schema once again. Best regards, Take From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 Sent: Friday, June 7, 2013 2:29 AM To: Moriarty, Kathleen; mile@ietf.org; Takeshi Takahashi (takeshi_takahashi@nict.go.jp) Subject: RE: Request for draft reviews - review of SCI Hi Take, I have reviewed this a few times and=A0 it is ready to go, in my mind. = All my concerns have been addressed in previous iterations. The only thing I would do is to make sure that the XML in the appendix = is syntactically correct. Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! =A0 We have had a number of documents updated since the last meeting.=A0 = Thank you to all of the editors for making the requested changes!=A0 The current = list of drafts up for review (including those that will be a part of the WG = after the charter update) include: =A0 RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ =A0 Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be = helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ =A0 Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ =A0 IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-forma= t/ =A0 Resource-Oriented Lightweight Indicator Exchange (ROLIE):=20 http://datatracker.ietf.org/doc/draft-field-mile-rolie/ =A0 Please take some time to review the drafts and provide feedback to the list.=A0 It would be helpful if we can iterate on most of them prior to = the next meeting.=A0 A couple of the drafts are very close to being done.=A0 = The list of current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ =A0 We will follow up soon on the charter update as well. =A0 Thank you all in advance! Kathleen =A0 =A0 From daniel.piggott@switch2it.co.uk Thu Jun 6 15:01:49 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328E21F84D4 for ; Thu, 6 Jun 2013 15:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.839 X-Spam-Level: ** X-Spam-Status: No, score=2.839 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66RzOOncRHDE for ; Thu, 6 Jun 2013 15:01:43 -0700 (PDT) Received: from mail50.extendcp.co.uk (mail50.extendcp.co.uk [79.170.44.50]) by ietfa.amsl.com (Postfix) with ESMTP id A98B421F93BA for ; Thu, 6 Jun 2013 15:01:39 -0700 (PDT) Received: from switchtx.gotadsl.co.uk ([62.3.238.89] helo=88181134W) by mail50.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) id 1UkiFU-0002UR-Di; Thu, 06 Jun 2013 23:01:36 +0100 From: "Daniel Piggott" To: "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , , References: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> Date: Thu, 6 Jun 2013 22:56:48 +0100 Organization: Switch2IT Ltd Message-ID: <077201ce6300$bef266f0$3cd734d0$@piggott@switch2it.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0773_01CE6309.20B6CEF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5i40Efq7jEmbbOQliqLxTXBAUoFgAGxBJw Content-Language: en-gb X-Antivirus: avast! (VPS 130606-0, 06/06/2013), Outbound message X-Antivirus-Status: Clean X-Authenticated-As: daniel.piggott@switch2it.co.uk X-Mailman-Approved-At: Thu, 06 Jun 2013 23:16:19 -0700 Subject: Re: [mile] Request for draft reviews - review of FC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: daniel.piggott@switch2it.co.uk List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:01:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0773_01CE6309.20B6CEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Having looked through this draft and the example 11. Appendix III: An XML Example Would these be worth considering in the IODEF incident schema? An incident classification level or assurance level for each incident? Mac address of reporting device? A field for whether any device is virtual or physical? A hash of each incident raw data? Memory address space field (as you have PID)? NTP Time source of the incident device? In the example above in Appendix III below should the service IP protocol be 4? System category="target">
192.0.2.16/28
 80 And one last question, if the receiving node getting the alerts via IODEF goes offline From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 06 June 2013 19:26 To: Moriarty, Kathleen; mile@ietf.org; 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com) Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hi Paul, Good starting point. Some comments and nits below from my first pass. There should be more when I review again. I remember sometime in the past there was a discussion about what is an incidents if that should be updated in the 5070. I see that in your draft an incident is used as it was in 5070. I was just wondering if we had reached a consensus on it. I also didn't see "uid" and "set id" definitions in the draft. I don't see the EMailDetails class described in the document. Nits: - Should "This document contains changes with respect to its predecessor RFC5070:" be bulleted? - The list in "This class will contain indicators from the list below " is not exactly below. The same for "the following included indicators are ones commonly used ". And the same for me occurrences of "following" in this section - I am not sure if we want to keep the "

Structured = Cybersecurity Information draft (close to = final):

http://data= tracker.ietf.org/doc/draft-ietf-mile-sci/

 = 

Having looked through this =
draft and the example  11.  Appendix III: An XML =
Example

 =

Would = these be worth considering in the IODEF incident schema?

 

An incident classification level or assurance level for each = incident?

Mac address of reporting device?

A field for whether any device is virtual or = physical?

A hash of each incident raw data?

Memory address space field (as you have PID)?

NTP Time source of the incident device?

 

In the example above in Appendix III below should the service IP = protocol be 4?

 

System = category=3D"target">

          = <Node>

            = <Address = category=3D"ipv4-net">192.0.2.16/28</Address>

          = </Node>

          <Service = ip_protocol=3D"6">

            = <Port>80</Port>

          = </Service>

 

And one last question, if the receiving node getting the alerts via = IODEF goes offline

 

From:= Panos = Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: 06 = June 2013 19:26
To: Moriarty, Kathleen; mile@ietf.org; = 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com)
Subject: Re: = [mile] Request for draft reviews - review of = FC5070-bis

 

 

Hi Paul,

 

Good starting point. Some comments and nits below from my first = pass.

There should be more when I review again.

 

I remember sometime in the past there was a discussion  about = what is an incidents if that should be updated in the 5070. I see that = in your draft an incident is used as it was in 5070. I was just = wondering if we had reached a consensus on it.

 

I also didn’t see “uid” and “set id” definitions in the draft.

 

I don’t see the EMailDetails class described in the document.

 

Nits:

- Should “This =
document contains changes with respect to its =
predecessor

      RFC5070:” be bulleted?

- The list in “This class will contain indicators =
from
      the list below =
” is not exactly below. The same for “the
      =
following included indicators are ones commonly used ”. And the same for me occurrences of “following” =
in this section
- I am not sure if we want to keep the “<!-- CHANGE:” comments in the draft
- there are some XML complexType like “SoftwareType” that are described as classes in the comments IODEF schema, =
but these are not classes.
 
I aqlso see that you will have usecases-examples in this doc, so =
mayne I will remove mine from the guidance =
document.
 

Rgs,

Panos

 

 

 

From:= mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, = 2013 2:13 PM
To: mile@ietf.org
Subject: = [mile] Request for draft reviews

 

Greetings!<= o:p>

 =

We have = had a number of documents updated since the last meeting.  Thank = you to all of the editors for making the requested changes!  The = current list of drafts up for review (including those that will be a = part of the WG after the charter update) = include:

 =

RFC5070-bis= (IODEF Revision):

 =

Draft on = IODEF Guidance:

(input = from experience, real use cases, and draft review will be = helpful)

 =

Structured = Cybersecurity Information draft (close to = final):

=

 =

IODEF = Enumeration Reference Format:

 =

Resource-Or= iented Lightweight Indicator Exchange (ROLIE): =

 =

Please = take some time to review the drafts and provide feedback to the = list.  It would be helpful if we can iterate on most of them prior = to the next meeting.  A couple of the drafts are very close to = being done.  The list of current drafts and published RFCs can be = found at the following link:

 =

We will = follow up soon on the charter update as = well.

 =

Thank you = all in advance!
Kathleen

 =

 =

------=_NextPart_000_0773_01CE6309.20B6CEF0-- From takeshi_takahashi@nict.go.jp Thu Jun 6 23:30:54 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACCC21F939E for ; Thu, 6 Jun 2013 23:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yShX+san9+2c for ; Thu, 6 Jun 2013 23:30:50 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96F21F9349 for ; Thu, 6 Jun 2013 23:30:49 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r576Umfd019921 for ; Fri, 7 Jun 2013 15:30:48 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r576UllH012328 for ; Fri, 7 Jun 2013 15:30:47 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r576UlZE012325 for ; Fri, 7 Jun 2013 15:30:47 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 26E79169C0 for ; Fri, 7 Jun 2013 15:30:47 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 1ECFC1698D for ; Fri, 7 Jun 2013 15:30:47 +0900 (JST) From: "Takeshi Takahashi" To: Date: Fri, 7 Jun 2013 15:30:47 +0900 Message-ID: <002f01ce6348$8bd6ac20$a3840460$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0030_01CE6393.FBBEC950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5jSHu+R5zUlBdHQkSK5hZtB9ioVw== Content-Language: ja Subject: [mile] IODEF-SCI tools available / MTI schema X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:30:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01CE6393.FBBEC950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, We created simple tools that can generate, exchange, and parse (and = store and locate) IODEF-SCI documents. They are Java-based tools and are available online. https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools Regarding the MTI schema, I am sorry for not being able to report = anything back until now. It seems to be a bit difficult to embed the MMDEF itself inside the = draft. Thus I would like to propose to embed the attached schema. The schema is not MMDEF version 1.2, but is generated based on that. It should be able to suffice the purpose of MTI, I believe. The draft will clearly state that the MTI schema embedded in the draft = is generated based on the MMDEF version 1.2 (the draft attached already = states that). Take > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Friday, June 7, 2013 8:46 AM > To: 'Panos Kampanakis (pkampana)'; 'Moriarty, Kathleen'; = 'mile@ietf.org' > Subject: RE: Request for draft reviews - review of SCI >=20 > Hi Panos, >=20 > Thank you very much for reviewing the draft again. > I'll check the XML/schema once again. >=20 > Best regards, > Take >=20 >=20 >=20 > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Friday, June 7, 2013 2:29 AM > To: Moriarty, Kathleen; mile@ietf.org; Takeshi Takahashi > (takeshi_takahashi@nict.go.jp) > Subject: RE: Request for draft reviews - review of SCI >=20 > Hi Take, > I have reviewed this a few times and=A0 it is ready to go, in my mind. = All > my concerns have been addressed in previous iterations. > The only thing I would do is to make sure that the XML in the appendix = is > syntactically correct. > Rgs, > Panos >=20 >=20 >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Moriarty, Kathleen > Sent: Friday, May 17, 2013 2:13 PM > To: mile@ietf.org > Subject: [mile] Request for draft reviews >=20 > Greetings! >=20 > We have had a number of documents updated since the last meeting.=A0 = Thank > you to all of the editors for making the requested changes!=A0 The = current > list of drafts up for review (including those that will be a part of = the > WG after the charter update) include: >=20 > RFC5070-bis (IODEF Revision): > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >=20 > Draft on IODEF Guidance: > (input from experience, real use cases, and draft review will be = helpful) > http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ >=20 > Structured Cybersecurity Information draft (close to final): > http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ >=20 > IODEF Enumeration Reference Format: > http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-fo > rmat/ >=20 > Resource-Oriented Lightweight Indicator Exchange (ROLIE): > http://datatracker.ietf.org/doc/draft-field-mile-rolie/ >=20 > Please take some time to review the drafts and provide feedback to the > list.=A0 It would be helpful if we can iterate on most of them prior = to the > next meeting.=A0 A couple of the drafts are very close to being = done.=A0 The > list of current drafts and published RFCs can be found at the = following > link: > http://datatracker.ietf.org/wg/mile/ >=20 > We will follow up soon on the charter update as well. >=20 > Thank you all in advance! > Kathleen >=20 >=20 ------=_NextPart_000_0030_01CE6393.FBBEC950 Content-Type: application/octet-stream; name="MTIschema.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="MTIschema.xsd" ------=_NextPart_000_0030_01CE6393.FBBEC950 Content-Type: text/xml; name="iodef-sci-example.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iodef-sci-example.xml" 189493 2013-03-13T23:19:24+00:00 Incident report in company xx An identifier of a vulnerability is embedded N/A MMDEF Generation Script Test file generated using genMMDEF 2013-03-23T15:12:50.726000 6ce6f415d8475545be5ba114f208b0ff da39a3ee5e6b4b0d3255bfef95601890afd80709 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934 ca495991b7852b855 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715d c83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec 2f63b931bd47417a81a538327af927da3e 184 eicar_com.zip application/zip 44d88612fea8a8f36de82e1278abb02f 3395856ce81f2b7382dee72602f798b642f14140 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a 2c4538aabf651fd0f cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e5 65e68847223b8e6b85cb48f3afad842726d99239c9e3650 5c64b0dc9a061d9e507d833277ada336ab 68 1750191932 eicar.com eicar.com file[@id="6ce6f415d8475545be5ba114f208b0ff"] file[@id="44d88612fea8a8f36de82e1278abb02f"] 2013-03-23T15:12:50.744000 Example.com CSIRT example-com contact@csirt.example.com
192.0.2.200
57
192.0.2.16/28
 80 2001-09-14T08:19:01+00:00 Notification sent to constituency-contact@192.0.2.200 ------=_NextPart_000_0030_01CE6393.FBBEC950 Content-Type: application/pdf; name="draft-ietf-mile-sci-07_anotherSchema.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mile-sci-07_anotherSchema.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WXW/bOBB8969Y9KUJEH8laNP2LXWcwmiS5hId7g5NHyhqZbORRJWkUvvf d5aWP4vcFdfIcCzL5Ozs7Owy32jQG9JAXu2nLjv921Oa+s6APuA97XzrDOMCaj90Se8TLHpDw2NK 8s5y35COT+j05C0lZefganI5pr+sezDVlD4429T0y1fSo0Q9qJnyM3OYfO0MTyi57BxMqsCu4tA9 dyoPvw63fV1PRsnhyyVWlXFGPqjQ+Hd0F1SVKZd5SpzSD/+G8bFHl1icGy4ywfp/TLavK32WMz8D FpS7MkWh3PPw+vNuNL5Nfg/rnx59VJlN1SKW81l40fXZ5O43eRFdcAr/HtHxYHgCLDHu5QZx8ul8 fNHlOXzija0otw5mcY0OjYNv9CJl51k3zoQFmQo/lypgIZBavz4RNhP3dg2HvFuagrtem+7gdS/M A7Yev45bz1KEUjq0KSYz4ymzuim5ChQ5wahhxjSptMnk4af0K+tA5+y1M7UQofFcz1Q1ZbqI3HaI 3R/E/O4PKePcVEjIVHR7MaJXg9MBfcad3HyhYBGuheHKGT3jleefVIBUadH0u7+DowmGPaFzKFfa FAadt/I8UjGObM0uIvge9A9UO/uI7JaZalWrVHYtyObEZcpZJrNlU5MWa4vJEflGz0h5iiIZtKzr RgZ/X112U+Vj3uvlvU0B7uJYkEhR+ysu7XYt9kYRnvgmLU0ISyHzpihI2yVypZm+mzCTLHZqENMT b8U470c3dPomkou3b7fYiB13IkJGB9R2vK6cEXGWrlgupnE1RXHZYdVO6ET5B7EFqMEJ4wRGgOTX NjD2q0AWKI6mMrY9lWpBqvCWMgOxTdqsy/YzAbWvjZQyAaUCe4Ue7ODEr+tVLVSbFpRE+FkI9bt+ P1Oogkxjdj3pl551035sH99vcfr/rVLcsEXxURUmi+2skNrclE0pxLyZE3wbZn5HKamHCJAyNTUI cXZEjutCabkDiE29LVgKny5a3bbkCABYrExuSl4aG1maStUwQO2MEtEtNZ5/pu8RK2ckqleSw6ko pyokNHZpE0vGZRsa1atk2wspjVgRMaaOve+92Ag1svXCmeksSMXNGnrz+P5AYzLIXCQxB47Exoco hbgLXerFtOueyiTivrvX40o1YWad+OAMXREDSFqe3SNnu+XbnXPLropjDZlu9Ue0+JrXS0+XPFXF TvSbTW/dcoHuhksBEnedr8rT5n1/0PotCBzzxmsFxKk8d2VGQBDIyXkufDDkhIT4Ad5pceomxYbl CIyNuJUMsr8pGAMHmT8a/i7b8SXbo6JhWBkei6NW0gXms0x02G9hG7eST1SAhOhGHeflcsDgSc3r QwPp7lMY2Yzxp6xtFe2Jk0ROGRQwd7bcXU4lxADUq+Oo6fofsiPCXFFFb+9UG89rg/hPHrafbxSO kOEXII6Tzh94/QAMXfAfZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjEwODcKZW5kb2JqCjEyIDAg b2JqCjw8L0xlbmd0aCAxMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ2XUW/b NhDH3/0p7i0tkHiW1MRJ31w7HQwkXRYL2YBhDzR1krlIpEtSib1PvztaimW3XapIMGRL1I93fx7v zl9hNIxgxGdzldXgl/sxFG4wgl/pUwy+DqIwAJqLrOBTSoMuIYohzQe79yKIExiPLyGtBu/m2qPV 6M9mVuQejo/5b7Prz2eL6fybJ83xGZcQj6LkffrPILmC9Gbwju4qLcs6Q1ioal2qXGEGnxYzuFES tUPwuPEgHGTopFVLeqo0LFB6ZTR8GCKY/P3JIEpanF8hpLZ2Hm6wECXcWfOkHA12IHQGwiKs+VZG pGflV6b28CysFdpvaR5iMeVgNkZ+37ohDY8vwtSpWJZsDEwNyaR9S4qGpIz21mT1zmYY9jwB4gMP Y7qVoq2UNqUptr15TEwa6xL6MVmTZ1IsVal8f9qe9YF+XG/Id1YbZpgrrfp5TIyGxbSg3OTLBHbS 5sbCwltSsba0CtPtEq1DWVu2eq7pcSXCdN9jxa1tvOwz4QWk2zV+hD9vb2aTdPKqXecdVtJlTUvh HLo+Pu5ZOxr7OfFeyMc74XmH9WBdHLHYz7tSeFajX6QBXB6x2M+HutRo+8YGwNURi2NjIY1Vuuhl Fb0WjY5Y53TzDxSPGl0P3Xes6Ih1wWv5RNv1HtfG+l6s+Ig1Zr3Qqlx24/DnWMkR65Ju3mOFmerP auOedbqlnCe8sVvwBuaUwoipPeQoeBe5V1ltrLJOi3azUYZzlD9tMO01xrcspnHMp5RzHat+tlij pNwqmSxpA7xuVxv34zZHvMmmQxZrPpGP2jyXmBVBpx6cHavdQ1e7vEo5Qm1gHvIMxf8KK9FNjJzS 9hnzR6xoNOywCDbRgcdvT1coH3lTvaxtEODEwW0678SUNCFB8ur19CnYErfxGUUHtpAx+6pPM4Lb +fi/rDYOorjLevgIUwpWReFK1bYJiGY12VMuwp1q0LDGLSvpsB5YIkMv2KDT9UawOK/5mLT7OaJk dY85WqRg7JlhWta+9kS7QvZlV56esIt+AysO7UT+NhokrfaTmjof605gkmWUB3pVsJZ1sW9+jpuc ZpaU1kzXFRVqbowkV2wQodI5UA4Ka545djOxheWWL6ehR6OOkLay9gddj+pUeI2YOc5oSwQbEjdm p4AbuRK64K9McSvBfYKojC4ae4wthFb/NlFFnZ2xlDIYJM0aQzsY4swpX4dBw6arZWuNbnrNtsv0 xpQOUFM8sheulqsXGxpHqOcsLYpsy5PVB/0iy2MAc4pyRb6WW7C13mn00tWQUU1CO+UZqRt+8fGn tKmEXCmNZ2wC75oXd5oOmMxr/HH7xqpCSssMaHvg4GxnilNYUs+s/H4qpCXOGtKTsMrUDrTRZx1q UKdr56H6+gkpANALVQbSedw01Y9iJdxK0erSv4ByePSP4nqzVlzGfnT8dScKhPhvIl6ng9/p/A9f Vy95ZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagoxMDkzCmVuZG9iagoxNyAwIG9iago8PC9MZW5n dGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVk1zGzcMvetXYHxJMiO7 +mjqpDfHlhvPWFZirw+dTA4UF5IYc8kNyZWs/voCJFdaKXVSfcyuuOQD8PAA6DsMzoYw4He+yqr3 2/05LH1vAH/Rd9n73hvGDZAvsoIPBW16B8MRFIteOjeE0RjOz99BUfVe35iAzmA4vXJiEeD4dTO7 mlyfPlze/PAkv65xDqPBcPym+NYbv4fitveaVpVZWFeJoKw5oz2NCyt04INrZGgcwkaFlTIJnTZL h8KjT7/fvOoNxy1QaWVToQn+FVRC0hk8pb2lmCutwhaEKSGsGg8LIXlFBEIhMygqrYwySwJjGLmd o/MoG8enbI0u+ubP6Pnoj9bYzBAYgo3Orgi7z7/JXXxWPsBaOGXJVnouZFBrFRR2jCeDHe8xCKWx jH7uoi9p3UunanYB7OLIuw53fRA+R6DJAzpJpD2gjAcppWfwQOQh+EauXsLvMPMLMvqgAmxso0uY I30MLpRUQkOwgNU8hyGtWeM2QxETHrse071XJebMttk7pLkgOCPmGum4CMyx8rutxHVAU/qYiYTy 3+b3LLd56RDwE0ZZerBZKbn6BR0ghWEi9gSWpOVEeA6PCDKUf5GRFpqEwnGxozEOH38m60kETV1b F+gMLJ0wjRYONK5Rkw4yiq9RKmY+bI+52Rk0LTwxTvS0dUQSEeUeKW4nTZIxgxtwyKazN1yW1oEk B6KhWElEtFaVMhRrC9HUWslMnTV6G/MiylLxEmljR7onGxK9F27LJrIG5/sa5IP4LKmulsiqPxZt V0WCiq52dk1SKjviGZHXBTry0Gq7bEVYEHDYr0LjU6EccrewWttN0pU1mLmMG++vLw8E9XZwPoAv tMo3X+FIvXT+CbdUKI5UejJ9fChO+ukKd7N4fz/5/HhzP7ni+4ePF7e3u5u048AYPZg93ua9fLdH uZxNp5O7qwQ0vfj7JKXpZPapuJndXdyetFG2yWpjZfoomXMuTWKmdsi9Q/g2KbuwYTQcvo+h8s1B qGPi+qKO2U/NtmXbUicmWPoelg7pwy2FUf+kFBpErmK7y/lB1D8rUK5NHgq6IXdjvlLuWMmdnX9m h0QIQj5BTVeaZH2otQi86RB13WhDld2ZGxsUT1RMvt/2AdswWRWNIh5RXE2szXha2qpu6CFQqRK/ JLNcMeScpzWO4lAmqSSzhrncvVxhFdPSJiG3iVwRsRw6Lh/QJSobgycXMM6BWjgePZSjj3bDDsTm XVouQ9s2iuheO4PaHpV6UdeNY8v/cygKzZN4m4djp5A5rI7VfRTJgj9qDwRnj4YII3SHanQxB9AS RqFPxTdColZCDlVR9C9MyQ/bNEHKZA6rjEWE2s6gaeunn4hrq4nnQBo7UFn3A6P0KPA/FMhYjtqg ooz4vUQOoIhxkpiiVuqQWxXTPRz8HkkqxJNYCb9SfUAqY3129G9r8lwrbrUvvb58EiSl8VeCnBS9 z/T+F0bQRNVlbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjExMDkKZW5kb2JqCjIyIDAgb2JqCjw8 L0xlbmd0aCAyMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W0W7bRhB811fs WxJAli07rdO8ubFdCEjS1laBAoFRHI9L8Wryjr47Wla/vrNHUiKVGqgEWzZ13J2dmd3lE50tlnQm 7/5T17PTu0vahNkZ/YKfzexptkwHqP/QNf28xqEPtDyndTHr7lvS+QVdXn6gdT17u7KRveV4cu1V Een4tfr1+ub25P7T6rtv+tctZ3R+trx4t/57dvETrT/P3uLquuTAFKJvdWw956R3GfvAuvUm7sjY wvlaReMsFUqbykQVOUxPvXszW14MAV3DvjuvIsWSybNm88yegsl5QXRvrOb0zTi4CVQrXRrLJwgn gTyrXGUVz9PZXEVFWlnKmBrvNIcAsNmOtKubFsyEhRSDnPzScG4EJO7rY6k2uj6RK45K3AMOOHz+ 41DHrfMAGKIC2jkhsfMbZc0/XZStCcC6oeiAs3E+kqIRaRql2jjhZatsDHI+56C9QRlbQfvcVhb5 M2F2h0NB8FcO+PNUENtUfmCbs++rERqCqZtqRy3ES8rPEY49C9A/v3ymb/i1XJw90EmmhCgVo9KP 1OATJtozrJ3PER84CldVbhu6ZDsb1QtC5fTstMraSvkdcBdQJ3GOJMbmLVyz60OFhrUpjN6LyXXG eY7jwiGUFN77yoU3hiF2MVFo4CzPg1KdIyjyS0T9d4N3pOTEqSl2CaNllug5R2WqINHlaldmH6ov VgBXzj1Krrah4GoejgtTUW3CuLaDaSY1HYNRWrc1iIk8SrxP2TNrBqYNpBcHixiJV+3aCugNKDQZ 7IsT4o2uKxCCQVqOcD4aGNkUfZyuamhtYunamP6Xusq2TprgzmchCWZeTNx8ZR1ie5hLwTcsCons yTVW9FR5bazAURHGF3tzcqsuGXV1pBzMrJ0tzKb1+5YqXYiHVhRNS6QYt8ycUFutdsnKpPqCnlr4 QPJMAwguo8t0fuhdrSoYfsPSLjFp13l7UMsVcavQAVNs4xnTNs724yj1bsldeqjuW2txbRgXh2gi lqBIfu5aBWhBWOo6yh1sAMYHwIlXHmRHqZEyMUav7YTlkULvYa+bl8g2CM5rcaMRyH2ctZCZp7HP cioPfXqE7YC9NsAnqo25yGRMRe/yVgsXlrekK4WhGjp39fXEtB5GN45GEEbYuMvRnkekkEyzitOf UAXAo3RqH+Iqz1ONqrqW2S5E36W2WUWuBzATjpZgaXX19YrWshdkVND9oe5Pk6m++g5yIpH3JCfo 4f9tvsN4mPApinZtNRkV3SZiqiC09EZoG9kQotLkGMzSQ0Pzqk03fqS+eSIjHkTv8ofx4CsMY4AI BYeBJQnfoEboupu2/w1Wa3edSohiVc2hUVjDsie+yn8PND8a4nJoTph3Qtd8UrjnAiNK1vgfd6sO rWqaCneKLr10CRxL4ukgHeT3mUEfABFidNMoNVrJVZN2v8wR+LuVxSdrOO920zjWYMY0TP/DjnLD 3RhrR9ucMHJl4u4FkHld17Jj+x5PCZXPT0c2UFUKMdpir+wKmQINHguUuEqAj/ehbOmpOOs09NEL SJDsHRONIpSzGHnOcqfdXBoqY+xpCXB4hiP6Ogj68fC8V8bYfDw93W63C8OxWGAYnyY7/bV/VDz9 sl4h0g/nKdJaPSokLc2cGL1bLY4eIG9eGoPF9NrzJX37DSam9w+IeLOe/Y73v3lTmqNlbmRzdHJl YW0KZW5kb2JqCjIzIDAgb2JqCjEyNjAKZW5kb2JqCjI3IDAgb2JqCjw8L0xlbmd0aCAyOCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVW72/bRgz97r+C6JcmqKP4R9N02TDAi51C QJJ2jjIMSIPhLFH2LdJJuTvFdtf97yN1J1tyMwWBYYl8fHx8R/kZBsEQBvznP+O8dzo/h6XpDeAT /S97z71hHQD+I87ht4iCPsJwBFHac3lDGI3h/PwjRHnvKFQWtUJ7MtUitXB4hZ+ns6uTu8vwhyf+ usIFjAbD8XH0d2/8E0TXvaP6/l2JsUxlLKwsFNyKHC9aYDdRePy2Nxzv4/9AbSjyoo09DAYU5Z7P MUWNKka4n4c+amVteXF6ul6vA4k2DQq9PE24jb92lU5dJYcxKcuMGC0yhMtMGIPmAibWivjpi7As A0WejRpO0QrB1sHSgC1ggZALJZaYwGIL4eR2ApWRagmWAmebErUlli8S1/Awv7o8G40+PHaaFCo5 kGWOz5XUBLhLAJFlhX9aFsRWogFhIK00ldG+FeNQKFEquMO4Dj+HgB6PPrT5c7lwCtSdlovKElaR Am4sqoSSYycCfD1qMN4H46/HkFfG1kTWHf7c54vIKofC30y7G/MWFI3ZlIKGROSyxPSBikLBzNfS YN/Tl3mZYY7KujwQGkEVFnQjB6ltqrIsdE3joIwv7rHqObgxsb652EK8KgqDsF7JeHWYu0fuE0hR LVctrE4sZNJYpzC3KpW0UmS+lEJMdqagRznR3DYoDh+TPg8uQROT9t1RnUEAoYJYGGZ9oIeH0Rij fKE8AYmwAqSFpCDpWahdC3STO8ZNyc1Ly0ZRdQ2RSdswIrtmRfHEXq3KupuWaoVmSJlu3UTZGZol ZjCpxEIyELXqsUqhiTSH1qwI2h0CobaQo1DccSoV8S4qa2TiYk1clOgGJ81rares+z4YBUAHypt0 ymWibUn748+b6+kkmvj8iKCcl3lxEFdyGZNmx3h/1hQt5e5Z+XHWC6Lj7rxIMKPCn1Urj4++SIjG rjhFTBRgThNldnTXj8fs5lZqJBmt2xNczKfuYQPPvinRkCO/7N24b418VluQGKYXs+Y2a+IWx+B8 8Ah9MjzbPmFQD7E791zEoGWkN5s8C9605R635faLcaexl4rsGtMwlQV0Vm1VZuwqz4WW37hnpL1B iKF1muwVJpeSMsYN4V65BXbDsrOBroVaVrRdaRvd31zTFjJbOhAb1qQyu8E1p77m1HWQY0u5+xG4 g0z8UnK5zDLaa5ruvTQwZaXLgjdgobLtz01rbiF1diyPWbRN5AHojUKyyQ1M2MD799+7k+71riPE 972a9fXdo72W5eJnt/c3DVv6/suvu5iHBiqcPu7C76J5ePupeY3W4f8MgmD478nDJOMXXS1CO6O2 20lToZMxx0yQmSe0Vl5oFTx2SWU0th+rTNHSqotkjgfh8CqpOyv0QTQfJJqWdAuzEz1TSRPr39aR eBIrYVayD8ivjODgRwq9nem9Yv7vNww8fGHjnTHiLOr9Tn//AZWF1DZlbmRzdHJlYW0KZW5kb2Jq CjI4IDAgb2JqCjEwOTUKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nKVVXVObQBR951fc8aVaCw1Jq7bT6Yw1iTLjVxNsH2IfNnAJ W2GJu6vRqf737gKZZEOwmC6TYSD33HvuuR/cQstxoaWv8h6k1vvBPkyE1YJj9ZtYt5abG0B5C1L4 5iujA3Db4EdWgXOh3YH9/QPwU2vbYxI5Q2l3OYkkrB7votvr28Mjr/JPefo4hnbL7ez4v63OJ/BP rW319mnF6unLV3t+RgOcZlz6NMVfO28st/Mi6E/Lcd4+26MuioDTqaQZ06h6e7ewPxQChUiRyZfN S/dnKOMsrDWtxR2GIdWcSNIlkjTCr/MiJQluLonUtdjUyY+7hCEnY5pQ+bipk59IbpgSrpHGRxlT vJsJ3LtXpWiskQHtJ9msGapKcfgoJKavQK+Jv0GNqzIbHi8TIqOMN+RlyPgwxUCSF8dgLdh91oMX ZLxZky+jSykL9CvbvNaP17Qsdd6W+6rYKP/sQ63BCRUy4/Xz8b+FNyYSOY1osEG1Cp1SDKkB3rXN s6veL5bu+tOnkzuO4H4GjwU0VGpBkBAhFLS9N4f6MRWADxKZUOEgxIiqLQAyRoiyRM0fZRMQqLQG TFBvVeFoTh+cjuM6AMYCK8keMvM1BJnyLqSALALClsLJTEcyvgVzrk6xmB2zFHMSMKMyBgKhfJyi drv1kCZbjs4HSxbLSekvyFilRXJaMC145XxoGU89cNB5FgkuFPIkKIm46t1URQ4xVJSJhIJeoSgM Ty6uTrs6T0kog4yh9pZmPOe2muKC2VxSmMXIVHAO5J7QhIwTNElUJc3jKmJC8rtAqkKHQERZszyD RXusNo/RRctfYTPEojlrmtDwU3jonV+dwVBtKq9bae/rbd3f1zv2CAZklldzMRtDf+CdH2tp7GV4 BYgRcmQBVqEGeYVfhc5Xb4782M6z9skNiYmI6TtACSRxVkZILV3KVd/UndElmSDsaY893/qurr/s QVMNZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago3MjQKZW5kb2JqCjM3IDAgb2JqCjw8L0xlbmd0 aCAzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nMVWUXPaOBB+51fs5KXJtHGA XEsv90QL6TGTQArO9ObSPAh5betiS1SSodyv70q2sXGSez0TxsFI3+63++0nfkA/GEDfvao7z3sX yxEkpteHL/ROej96A78AqhvP4VNIiz7CYAhh3Cv3DWB4CaPRRwjz3ulMWtQS7flEs9hC95otJtPr 89Xn2bNvqusa1zDsDy7Pwn96l79DeNM7padvz1+53p698QtehBJJoRGGVzC2lvGnO2ZdbsAzZgzt G36o4cNUmPIxpMyATRFilWVqJ2QCtEuLdWHRBFWw1Qb5bHIFsJx+vZ8tp5MAYDq/v6XbGAx9KWLB mRVKvjEgIpSWHqAmXGYJYnBZx6WrWo51VJ0zCyoGBsbqgltiEAHfr1Eb5IUWdg9ClssIP2joh7R9 y7ICwaSqyCJYI/BUGZQQa5V7eMlyNBvGKdrDX7c3c/fxETJhLEYNkpB+8Ww8H4Nl6wzh++kKuYsH vwWD72egNJxstNgyiydBO/ThaQvNwEbjhjkelDdwJbe4d4Vdst2EWQZrZug7Amc1f1cot1Eq2wCV adbZ+cSCqnX0V5iCZdme7s/iRBSkgSlDOCTGudKRW2EVMEmsEibFv3XjKipgeIo5o1DfUvSxG6wO 6TIPjN4B/rTnpUoAM8xJAXB7vwpdT9yC4Eh9zWKS1OIunC3m4xuKtwqXs/mX/1VUFWXiVdM4ULSH phNwh2teGEtcG5y6RMHJEfOjuXydvmzzdTSkG0ra2eW9qSac+kmVJtUpTY2uVXIYZFj9ubi/mdTd gB2xxC3qJl9T8LQd1O3eMpFVovukbHqQL5MRLDFGjZJjXQLTYPnGzxfhUbiyqE1Gh7LuUkEDh4LK 67nSPe9g1TgifgFF5cKJO+j4G77kgW49V/lG+fmLu76XJBoTatpRlf3G0gob/KoU1L+/UStnD7nS rlBkMpNxOPYadpEypCwjxQsvk2rMu118ZUJddkdz4CsvrAFqnaHPLc+pO0cuuPcbS4FeNKMW/Je4 G6QdDQehX5CNRnQvG4DSuIPFp39kq4fB83HLQA1WK7pP3W1Vsm5maWu1qOqMyDYbALI040xQ2j9c 88kd33XiHxOvYh3U3iCRIzvBkt7qRIQ8oPN9a0AylSSEZsghIS1yGj3OZDslrelo8BAbrWg88o40 6snoiMPpTagI46tmdh6W15/f90f9R6hHtipDVyHMadQ4H/C/J1qKUo5IVkRI6WZCPnlrb7le+5Q7 GB79T7yZn4FIOD50kGC+xshrT5AwpMeputOAVPkdU77LmHXYz8fhmZMZFdsd9Rg21R6KtFXZ1id6 RLnSRz0AlQHWjud9w1mWKxlbK83Ko7LJtDnAL4MhuIQ/vPfwIXti9KMnFXRqkd6yoPMravpzQyUx 8Nr1cMcShNEjIU7D3ld6/QJSUiSXZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iagoxMDY2CmVuZG9i ago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0K eJy1VV1v2jAUfc+vuG+DFbIEttFV0yRaaBeJFgphm1b6YMJN4jWJqW1KK/XHzyZuwufWh80RCsI+ 55577r3mHhzbBUc/5h2k1rthCyJhOXChPpF1b7mrA2BeQQqnvjp0DG4D/NDKcS40mtBqHYOfWhUv k8gzlPUOJ6GE7eX1O93z+ujM29kx6xyn0HDcZtX/ZTU/gd+zKu/tpt2wAQYJkSHjafWN1fi42lHn 28XPQGeYSRpSFEBAsFAuCUeYm21F4EmgAjgGLE0xm+EMZEykonObBZ2UJLgbEKmzqMG3RZIhJ1Oa UPlUg+9I7jIUogYkm8HoSUhMIUiIECpmwDJJaKboNJGMVShMUAWSApYxZviAHMgDoQmZJmgfysJg tFIh+SKQC66EEgEhSxK2FBpojFHAo/redbSR1HPJvr6ejdQ/cOTo7tX4EkZzDLzOGvrzl3p9UnFs ++2kWr+BIVl2iCRwW8BG/tC7ugB8lPUSvAPDEDlmAe4CX0Qb4N/VlrYc6C0aKTOheVL6sSreRil8 XbjVzxAr12WMxnmaRaD6gtPpQuKqDPp4ntkJwLB7PfaG3Y7qM+2XrZkQUiSZBrIw74iCQNdXcwuS 4kax1FqFJTIH4WZPGmmTyggDSVkGejrcSRU2G6o0XUnrD3yvf9XuKU25ta8Ut61La/0X4srCHhDX zsph5joSKcYYJIPpjjKOc8YlzmxTvzKT0df+uNdREFgINUfFIIpFEK8FMdVUS6OLIQU4ZTIueltP fdmwxXRfjkc+XPX9XJjhKcLt8Vbv1dQmTRQLVTZyY2eac+3w0H0VYimVOudD7au/sHTONIGp1lon RxHHiCgmc3+9NLTJVVXmJ3IGjEPKuHbix2Wv0/bbB3pn7dr6j51TmL8lT3NSNsPwpCzPzfD87IPT cm5hU/K2tv0ZvFZyWaj92t2ms4rlkzui7pOY1gAlkMTeupu6j3PK1b/IoXUzIBHCsb4ku751rZ7f xwYwHWVuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKNzQ1CmVuZG9iago0NyAwIG9iago8PC9MZW5n dGggNDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1Vdtu2kAQffdXjPpSaILL JQlJVFUigaSWuAVMVTXkYbEH2Mb2kvUCiZSP76xtMHYgykM7VmTI7sycmTNzeIKyWYGyfpK34xtf B3WYhUYZbulvZjwZlegCJC/HhyubLp1DpQr21Ij9KlCtQb1+DrZvFKxAoQxQlZqSTRXkzeo1Wzel 4bX15iSxG5xAtVypFe0/Ru0C7LZRODFr9AD8XHoBSjbhHlcvxc9G9Sw6JqdG9gwcEYQ8VCGIKbAA 8Fkh/UMEoASoOZJvpbbxtQKHuxgos4NqLlyz4bpc0V3mNZligB76dAprrubAwFUvC9RhPz373icC ZUfhdKA0i4uhI/kEQ50MxgWHBS53mcJxEVY7QDlGCHmCgL7ITayV/m5mirQU8BAkOsInRC66FJ0p iGGD47EwhOGP3qjd1PUrxgMQAWGV4AsZYc6XniJOqgxhPceAkktgK8Y9NvHQfLfTm/YQslDJpaOW koCxEKbC88Q6KiGhkbyPSgfsKIPrNZdka69Je96NE0dodUcdGC7QsZq74/X67XupNC6UTfPLuFi6 hwFbRzQ/bB2H9sDq3urelHbd3zjiFCUGDr51zYAn/7xr32NqKqS/43nA8p5DR0gezLaO7/Yhbfve PeMzogpOLvOro+coQ7k9J3Lj8ZqzeKRjcjUSphRN+lJhxLS+HjftEmDQuhtZg1aTlkSTEe8K+MgC 7RiNIwXeBtAjpGOHzM9OKVmUlmY9nmFoKMWcxz65ktQk0MaFITp6b0HLRYU2LTu4KZ8Erde3rV63 0SZMMWcfBJfHpbH+C3C5iTmAsBFApBN8ymlBtbTl8awyVJLYTZAEYyGkQtdMmExrSsSC7ixDdBP6 yLYaEC6d+W5K7b2VBYArQZK4WSCSuHQn0lhbYemMhjZ0e/YmXZRlT5f12TEdcm83ColvXDK9/TjW Jg7fx5XwudI1Hxpk/UH4C6EDJLztzPRsJnFGch1fTkc7qZXo+Y1SbJSVOvGr02427MaBKdrRyP84 Q9vm5+BFvzDCxellKln3g5vr03K9/ABZyHls+yv4KOSUv/3Yz06jVDZ7ZCQsc34MqIB5Zk6pWs8L LumX8pDd99kM4UJrYss27uj5CzCshoNlbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjgzOQplbmRv YmoKNTIgMCBvYmoKPDwvTGVuZ3RoIDUzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CnicrVbbbts4EH3XV8zbJqijxHa76WWxgDd2WwNJnFpKW7TdB5oaWdxIpEtScQP043dIMZKtpEUf SsPwjXPmnMPhjL/CSTyEE/cIr7yKjpensDbRCbyh5zr6Gg39BggvvIJ/Utr0HIYjSPOoiRvCaAyn p88hraKDubSoJdqjqWa5hf6aL6az10fJ2fzBL2G9xhWMTobjw/S/aPwC0vPogL69KpnNla5eAnxC rUBpqJTGGGAiQWQorcgFalA5GJXbLdMImxADLM+RW8wO/4iG43tEWqs7sAXCbV1K1GwlSmHvBrAt BC9AGMCSrZRmFAhCQkIQQkl4Go/jEcSENfrzHivhSgu5fpyczARnVnluLp3BW9SUKXzuk+qxMTWR YQbO3icJMJnB2Rm9MZQQzaNcCS8g9Ug/hRgSVWHLw+qa21p7ec4n5rdW7I4+87LOsINq8sFW2IJQ hSVpc0kolJkzgwMPGFwgLljRgUDydnF9PoXLRQqrHazaUEZDKdBHLdl2yixro7iSlglpGo4+r8uW AwONLEN93EFp5CjITcjQklJzz5M4rpQtWmznW4+dcV92SJRMaKdbSSOMRcnJe9Fq2GjMKU1HiTJq ypxBrlUVjjFA9QQNmuwNTqnWHmQvEVUsiSvqiklyU3ZIlIkUWh+x0WpFgDt15880bosvhE1aobxk xvE0XIsV7vr5oBLJL7q0lfthrxwN8tptcAdgXZkRHVWRqoyU24JZeL9brV7pB2Q3Eimzz48m8ArH 6vO2R7AtUDoOwG6ZoAoucf9e9cUQg52qpVuRq7JUW+Oiul7x5OjR9WRP2vcWem99D3R/gtFEzy6v LyDZIJ9Pd6L/+rvd+tknwAQt/NtGJelyfvkG8Js96mJ/IWcn7kddU6zJE3j2ct+xPTdTf129kQV5 Z7dUdtZScdQWvYW+lXla1MmWs3fX8+VsSmfvtMYuHqFCJh26ryCCawHc2fiaYtWDluaSuWIJZTex lvGbKwqlQREIfTnYbVXDL4e9Dts5RtQWV+l8cTk5d8XvDf1Fcn1ejuvvILdjrHujqo1yPY4Q6Uaz 9Vrjmjpzs6P1ORSHkyPdqPh4cT6dpBM3NDxESS0NMsVr3xU9ReEK3vXpR2YZ4wSYOfVWNQdBbtFM 5E1XdzdT0I2jy2bc53ZkZmEKdl2nsfm4czwOCu87dJgO5C81CG+cbyu7g6cdJxT7gS55cx4tgPFD gMYXNRcidGxcR9EGLq6TtINBaVxNe+lOkaTjMhvGW20N+Qd8vdg9SUpiM3ZCA+rPHPdvoW3I9hWI HKSygwDybOR9TtkNo3tTiAGQalbGvSs4+7YRrrn+YH2+Ymuk/1GuGczS6B09/geG/sw5ZW5kc3Ry ZWFtCmVuZG9iago1MyAwIG9iagoxMDE5CmVuZG9iago1NyAwIG9iago8PC9MZW5ndGggNTggMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylVdtu2zgQfddXDPrSpLUVX9qm7S4WcGu3 NZDEqa1gH5p9oKWRzI1EuiQdJ0A/vkOK1sV2ii6WhiFb4hyeOXNm9B16YR969uOvcRGczc8h00EP PtM3C74HfbcB/CUu4ENEm95CfwBRGpRxfRgM4fz8LURFcDIVBpVA0x0rlhrYX9PZePKpu/g4PXji 1ydcwqDXH55G/wbDdxBdBCflA8EK1GsWI/AEheEpxwSWj7BYYzwdw+LL7OZiDEuEtcIUFSYdYCIB s8LT50F/2EDiIpZCc21QxI+NwFxmGWFqCQxWm4IJiO1XKoWxsUAELZc5FiEhDt7sEP9WnFLWZxpF Qle4vFlEgEJvFLogTQSJbcwMl8Kl4Yjd01660SLXzswG++wYYVWkDWy5WbnHdM/e0CBTn6mFWRBn /AN4SokoZMTqjFJATkdCgoay0UShrUMHuPFaeJRSx99IgTAVYSeQKlk0aXU8kt3rZSaN3Y52Df6T 5K/CYfg6JN2R3QnU2h8yqm7slHKqEBw+0CmOqJEHfpiK2KkeXqJZySQcJQm3WbJ8zAwDpLMrxRkk 5nGNFvbZQ5E/IxJRJXp9SoI6VnyJ2iWw3bGyoY4S90fSHwV4b3+1HTU1wDVVLpZFYU1lXcwMlAwh zhmheT2t0owLkAItWkGFr71QZ1mT8wlp2K5QoHUEu2c8ZyRym0RDz50IREobtYkNWTsBpiGVeS63 jn3dqy+7R9fLFqEfNXpz/fBi/gKjjJ5c3VzumqOO/vOvbvf2pBeGL25Pu99gzrauiP9UYYtoPr36 bOXo1sEHYW5+CJo0B4E70scDr3NmUqmKRtzRtR9n+5WLrAr7RfatkXhsfPLMzp037xvdYP3SKm20 4v42rFjp0rKSlgQzhsy7MejK6saJU+o9wHzy9WY6n4zJ91b/0v5QIBM20NmOgCsA6xc3PWhe7M9g dyx5uvQqjIxh8d01hdLLw1O7PVnQELCetR3fvz2FtkHrIhK12XU0nV2NLohTWarfJLfPS7vZ9v/J 1UZ5gtxI1NNeuUHVmBSSXkf7zBSupTKYhL5+dSb1G2yjqS+rxtabeNU4xFfTvmZ03fRn8EHSaNu1 ih3Vtf+rYeHeaVezaHdIjWVPOyKt3dShhzwnFJqdZY50LUqsHVme1lCHKLLgxqb8lHvtD1mspUXy xWoYOcsUZoyQ3ObSz68HDiZid4ysv+IdQAMsD/faaPKw5go1PLG+XbMMod+3DTuJgq/0+QlZNbVz ZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iago5MzkKZW5kb2JqCjYyIDAgb2JqCjw8L0xlbmd0aCA2 MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nLWWbVPTQBDH3+dT7PBGUBv7oFQZ x5lCC2am0NqE0RF8cU027UlzV++uFGb48O4laZKmoLzQdJiU5Hb3t09/+AVNtwVN+8nvYeK8mXRh pp0mnNHPzPnltNIDkN/CBI4DOvQeWm0IYieza0G7A93uewgSZ98TBpVA0+grFhuoX96oPzht+Cfe zpv8OsUptJutzkHw0+l8gGDo7NPTCVv3mWFHAN9RSZAKEqnQBfh2Puz3gh59C+YICTLBxQxkDGbO NeACExQG6KuZ48ELp9XZeKRLswSB2VfMZCYIPWNYeDNmxmYB4YJpDdf7PoaGSwFv3Y7buj4Al1y1 Dws4jFGhCLGGZ31yGWF8VJyAq8npybtmt/kDtpHrbI9n8Fxk8pb7+Rv7eMFMLFWyW9meAB5RaB5z VDaWlrFZM0prmdsAi2NyjlEdfnqfgq2R3QjU+jWs5zycQ5oOm0rFyAa4gCpauwbmh1JRXR7nEhEP mZFqUwKNt6i4uc9/r/OUIHpFHFS/k6++D5pC4LPg3pYFrVDaN4dENLilMk1wKZXJzxFj5SGEUmiu jbZ4TADeGaQH5NvIHVxPhGnZ3dSBHXp3ggQa5bfKE89gUgzImhvKDCJzv8ScgqLt3SWLvXzSyrCY TDHSoI1ahWalKF+0wUCluHq7EV46fIoiJhQoosPp8FUQsi3xP48uh32bq2FUPimwsgdbKZptmCwB TX1AYfsI7JZxasUCt0FqRa1sRiUR6m0sFwu5TrMoBeRV49Hr1RbYw1aA4nrI6/kHH7n1xeU5+EsM vX7F+uOnRuN6v+m6L68PGlcbKYMfhZkfTLyLM1uSRmm8Y1ZIyI5hCl2EfAZtWZbHJZjPqJbQPdoe 4lxYyoYEVqCy5s9Zpk9Z7a0EkxwpPl0ZTBuRbnSaGy30ZPDl0psM+nZ1qGJPaHfhoKp99c3+B+pd lp3QRuPAG130hsSUFfeZcP/rT0ve2ifIdiTaiku6ySQs0x2obL0xcvPWlUnkuztFWGlaomITU7ks Q5QqaK2LLQU4liQ+m8FmIqpMa7He55d+ABejIAN7107BAnbDaHbm/DWgAbZwa6M4uFtyhfqpSb0a sxnS/yJ2JQaB84U+vwGRIYTfZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago4MzgKZW5kb2JqCjY3 IDAgb2JqCjw8L0xlbmd0aCA2OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1V 32/bNhB+119x6MuSNVbsuJ2zbBjg1U4rIL9qK1vRpA+0dJK5SqJL0k0C9I/vHUUpkZ10eSgFQ7B4 99133x2PX6AfDqDPj38nZbA/G0Fugj68pV8efAkGzgD8Kynh75iMDmFwAHEW1H4DOBjCaHQIcRns RJVFXaHtTbTILGyu6HwyPe7N30RbO34d4wIO+oPhbvxfMPwd4pNgp95YG0zhZokV2KU0IKzVcrG2 CPSH9/ZoUxYIKO0SNaiM7LCE08t5DAvc/SUYDDfRZPYIliqltZiG5HHwW+MRs1lSCGPYJFHlSjGA C6IRQeS5xlwQgjNCw+7sOBM3E2HFEcBH1AqUhlJpDAE+nJ5MxvE4ZGyEEkUlq7wGpAhYYImV5WCU xSZ5I0oKyVvC+kRhbK1IPl9QKiS/p3q9M8fESlXBq3AYDq53oZvVDDPUWCW4QY8xpUoxO2ot4Gp2 /OZ1f9T/BF3Km9wez+C5lL1qtP6P+4OKuBInqrJCVlRLKFAYClK5PHwBOLU2mQ5nT9RQWv9qSVTM vsEqpXcNjJVZkyQuiRUmMpOJcLwql1KVes5fyYM/y5TQyIraY3Hn3ObkFk1AEAqxNNJYFuaG+tRt M3MmQGw9FH/1vP/gJhWgURCjfY0JSgoEKVpShzqX4lUtaHK3B9LC/N355cnEY600Z/0D+i1xCkDY KWRalQ+J7Xkktq2hoVC5s+jEBqOI6XJdEqmEf0oTX+sMV1otSOcHJeSqjkjzfyhqVlPyccb1t4an j8DycLp4S8EcX6u2zkZUJU7+cJymkr1F4YrfNKPTXEBq71auOV7clsUL388tsKfR9AXpYhIaD2g4 XQdPvUWqZTK74zPbfDXdBt1Moxkexup1YqmlUj4PmSoKdeNc76fdy96j62Un129d/GZ98/R/gFF7 T88uT5vWvPf+869e73qnH4a/Xu/2rtrT86l1m8ez6Owtq9W7d95ya8fGluND0tHkGWw7l8D2dSFz Pp2HR4+o/dS8WIp6JtXacwnbC6Cd23VuNBdn0/eX0Ww6oS5hxZ6Y150bpJl3m6PxJ0zse9mJ2vlF HJ2fjU+IUy3uM8n93OuE732CisVnQcIu5R6gBVGEG4Wa3q6kpjP0xLq6EDnCYMj9Mo2D9/R8B/0X g+NlbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjg2MQplbmRvYmoKNzIgMCBvYmoKPDwvTGVuZ3Ro IDczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVZtb9s2EP6uX3HolyVrrNhx t6TZMMCtk05AEme2sg1L+oGWTjYXkXRJuk6A/vgdKUqyHLcrDUOOePfwuedemE/QjwfQd5/wzER0 PD2FhYn68IG+i+hTNPAGEB6ZgHcpGZ3B4ATSIqr8BnAyhNPTM0hFdJBIi1qi7Y01KyzsrmQyvrjs zd4nL3bCusQ5nPQHw8P032j4FtKr6IDe/omaFzxjliuZjM8BJrdpMrkZXcUAs3Sa3HygHyMJPEdp yRI1qAKYhGyJ2SNwi+Lwh2gwrPFoWQVzBI0rpS3m5J4uuQFmrebztUWY/T65uxo7m7XBHDZLlPiZ cM06WxJWQNk60Hl/Zrxk8xIJ7p2yS5iyzZhZRkxymGKBGmWGgCUKcjNwfTdLW6ybSdo5DmyXEf3h 9o5ok5eEwu2yipOeYgerxuHFHhQluHUxk/nJz7UkPvysZMY4k0yJlXIADn6jgC0WGheM/L0Jmjic FSKklPyDWoHSIJR28f99fTUepSMvLIJAJrlcVGwJP0jgjiL2u7kxTCAwt8VsCBBG1rLs8ZYCofoK RB8OZpi5moA38TAePBxCN6ZG8h16DpOrHIvzNin308v3P/VP+x+hS3mX2/4Ivpdym6H/476VD5da yoi0jEvKJJTIjN3K/94q6/CuK45C+0tTN2hzbFDm9KzAUZo1yeIDWWHW9BpIH5bMA29qAONeN2Wf w/zZu83ILRkDIxRiarixTpwNcfTbjr0veVUEKPc2EP/FlSmjXmTE6Fhjhtx1Wo6WFDKujblsQLPn I+rn0J4Ba6Vd1N+g3xCnAwg7h0IrsU3sKCA529D5pVp4i87ZYKgXYLkWbra4r9LE13rDlVbU+mIr jS6zZ7GrQ4E595TCOaPtd7ViJgwtfKKzPF0aUg45kZlXPB7lOXcerHS67UtxJTmD3D6vfJ2/ehLl q1DSLXAzgnI0GU0GrCuTh6MoGy0/LgulRf07K9e562UujdVrX8OmW7uJbwsSRgnhyiyv2qIOI5R1 0LkubCVxqz87sVUN95J8M5TbwdvhsaNyPdwq2lTwuevYQpWl2vgI2gvndW/vet2h9aUD36wvQcpv YFTeFzd313XjtN6//tbrPRz04/jHh8PefdPcHxu36sJzevRa5xduzWDbcqQ7gPK2RZp8v4NtK8v+ K5sv3PB4e/5S7a9NtCWrpmalvSPVXFA+Ee6fCXJK2SMj0yU/ArTAynjn5IunFddovkbs/pYtEAZv nAIXafQHff4Dz1ioE2VuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKOTQ1CmVuZG9iago3NyAwIG9i ago8PC9MZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy1Vk1z2zYQ vfNX7K32jC1LVh2n6Umx5FQztuRI9LTTJAcIXEqoSYABQCv+99kFQX1VbnNoqdFQIhYP7+2+Xekr dDs96PIr3mWZXMyuYemSLnyg9zL5mvRCAMSbLOF9SkFvoXcJaZ40+3pw2Yfr67eQlsnJWHu0Gv35 0Ircw+E1ng5Ht+fzm/HfVuJ1iwu47Pb6p+lfSf8XSO+SE3o6r1COh+8AZqOPj+PZaNgBGE0e7+mW rhBKFFrpJZgc/Eo5EN5btag9An3xFOBEiac/Jb1+C0iX4CXhm00IA++FfHqgrcQfZCGcg88nc5Re GQ0/d/qd3udT6BDK5ZsWBb/58w216UM6nk4Gd8Rpns7Gkw8/SO6QF3P9L8jNsMRMCY54ld9Ag8pQ e5UrtHyYALvddshM6dzYMiyBN7BACq6M9ZgFqXva5r9NH++GHFM7zAgpYqxXqPGZDnO1XO0ezruf hSrEokCCe2/8CmZiPRRegNAZycnRopa4xcKCuGrv4P5xnsJkmrbHhVOOZJvXzmhRFbsoijJsY6bL BqvFUcdqZkrlWfNetoP8pjD8wZSVYQBGXRsQy6XFpaD9IQRdJ54fFVJ5/kRrwFgojWX9f9zfDQfp 4BUPReX/u4Niyg/oMaYyGebvNhHwaXZ7c9W97n6BfcqH3I4r+FHK26r9G/edeoSKSqO9UJoqCQUK 53fK/prLtrxbo5G0360iOu7Coc7o3oCjdjWlJQihcUCGlk2X6CBLt/4n3zt+vLF9BouXsK2ZIiAI hZg65TwnZ00cwzKzD043eYTip5H4r2xTblxBjC4sSlTcYBl6yhB5l87TG1D5cgbKx/aMWJVl1f9A f0OcDiDsDHJryl1iZxGJY2PnF2YZIvbOBke9AKu6JFKS38YSXx8CK2uo9cudMl5Rvu8JUnhjX3ji jMsq2iZH4SnlrSHYcKpdbLi3RsvC71Db1VJUPGB4lSvIPdWUZ1vsJoG8wqyoD1kkD77wyBxJU8Hq aFjo2IwnYVYqr0QB48FkAD6cmaGTNEWayK17e6HMpiZLWmvsoY0RNhU9IuJZFIryw9RiWBYoZ0bW wbJ70kJ3scewJBoYmDgyY1xYUoO4UAxF81nSNCR3UQ0mxseQrb4NKS5jYcwT1FVIDXvGVUJizMdu Bih7dWgbv+2JNePu5bOZCIFidigHclMUZu12svSGf9BQ1tSYL3BjgiDbALH4qyYqFU9iJdxKnQGS 1KJz8L9j9K1S5KfX/pZ8ehBLhN7VF4IcpclHen0HiA/Z62VuZHN0cmVhbQplbmRvYmoKNzggMCBv YmoKOTU1CmVuZG9iago4MiAwIG9iago8PC9MZW5ndGggODMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJy1Vl1T3EYQfL9fMW+GKu7MQQzk3ggfDlU2do6jkirMw7Ia3W0s7YrdFXD+ 9emRVkIiH2/RFSWVpO3tme5p8Uj7szntyy+ddTl5vzymdZjs00f8rSePk3nzAqWTLumXFV46ofkB rfJJu25OB4d0fHxCq3Kyc2Uje8txeu5VHuntcfXl/OJyenN29bcn6bjkBzrYnx/urv6cHP5Mq0+T HdxdbUygzOm6ZBspVKxNbjiQotz5UkU5EVvtMmPXuFspH42uC+VJFyoEcvnuu8n8sMMLrGtv4paM 1SYDJqCqyrvKGxW5RXvRG2XXTEp7Jwh+raz5oaJxNsyITgMQBatkz8UWm2YqKvJceQ5AbF7cIxPB G0ytw4XxrGMhu0bvslpzTyRhmRBqFvRf3TM/sW/Wo/R1rbxCZzmjuEG5TX1ATSSlaGNDVFZzR8vl eBVLU7N0w4eeTVHQRj0xafZRGUvaYZFvSrpE2c0azyqAfEKKG6baZuyLrWxUcghqzV3nlQUnkAuV 8yDmXXTaFVQHcP18e7OCLKH2PMAadjrjtWcWsuCRN1IYVaAhe9IkPGwusUdar2og4B0t4uUNX+5L xFZPxjsrJplhwcFRp/eXoXhtC3t9G9nqIKXFkc2UZ7pdfrw4p+hG7skgTeEqchV7QGIhCtKcocwE 3mMIvdwVhXtujCmNbb0oOKn1A6pHszl0WHXtnN50lZ0lldLK1T9JIlcDUcZSRNdXPKqlt01rGG4n tFUOCE+QZCRY78RxHf8l3Ui0WSIfGtFVQhAOmfKZ+QGq/XD2FUAVGe7aw3dZQliyKqbRlGAskTNN SIieZ+e/0znnMB7Tt53l1fm33Vesu+Xl2dH+Tx/uG2pGJj8Ep6W4gZET2oOxTaKkRUf3fU9CrTc9 07HZhJ3Gbcxc8VpMN2eNrRqToCkgGKKvdYR1QMa28sGkI41KtaUH+EgVQWIvo9b32/RAOzRBO+/r Cs7DbuJkKcRE9OrKtrZLFT1vWPaXxyXSRjKhpwhYXCOjttLxRySRUFEPBe/Jft0IVlXRxYlIiFhb myilmrVVUol09j3AuqSAdn5btQsssdKbBIWwlNBoQgnyio5KR3pwcZPsGHgYUL8D6wUjEdMIvyIN gnAY1C10xgAujeXG4BYp2vqyZFlkQrknc9Ml1CjLsBdgBvoeS0tPr09lIgOM4NtM6edyGCAweUCC XAeZvowDTAEZ//j8iaxCbyolYydE5FbQG4b2aqT8HZ60D74i8ef3b24c3Dez56S4tWwi35+1gaW2 r8Ulat3+YrPGz4dHJyf3NLbusl3d9s5zY4E+ZttkGPhVbx/YD75gw1TpnQxpIiZRrvqqF6NNcdwu rxZUe7swHPMFvm6qDIuXsljYsDAu43watJnOZ/upmAFV9BlSRPhmgXs5e2od7tpvDaLH+fCOVJYh nUWQ0Go64tt9L7kXb/aWIhq/oGtnuzH4f1v16gjp1YeD5u2V+q42KmzMHjEyvpi9+d/p4qUy8gn6 l+Puqwzj/OgeiBeryW/4/QXfPz3CZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iagoxMTQ5CmVuZG9i ago4NyAwIG9iago8PC9MZW5ndGggODggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0K eJyNVdty2zYQfddX7OTF9kwk69LEDt9U2c5oxk5TiWk7E+cBApciahKgAVCy/r67JHUjmbbQ2KJI 4uzZs2cXrzAcjGDIn/pbZr3rxQ2sXW8In+lv3XvtjcoXoP6SGfwa0ku3MBpDGPeqfSMYT+Dm5hbC rHc51x6tRt+/syL20Fzz3+7uH/rL2bz1pF4PuILxcDS5Cv/uTT5B+Ni7rB58W8wDKKwOFPo4yIUV mQvesjRwMsFMBMpEGPedVP3RYHh10Rt/PNm8wLVy3grtYWa0F9IHdC9GCwlaBG/AJwii8Imx7gJE FFl0Dh04lF4ZTXijyQmeicsNkZFFhtoPmvH+enrsCkC3YVnSBaWrkHmOOlJvXYiMFSbKQYaZAWlR eGLEb8UmTc1W6TXYKrEd3bIwn36ZcqhMaLHGoIag9UVkuI+w3xHAu7IYsPS2kL6wGMFstyLGS5SF VX4Hc02omegSYJmjVLGS5UP3rpk/B3S5kJQQeqFSF8D0yJXyqxmLVvRWoA4y59Hh+ZL95E7vPV+B JF4Uzh1VMHHQ5HlKlSmSyeD74mE2+XT78QfJJTwodyidPmTFV1A4jJp0aa12JzojJ9ai1/JLU9GS FRMivbjMkk2rNF8yNoGlKUZ9U/iKiok7iPCbrdBsvKQgh/TJT5FYpewmm3UxKv2LmtIte28KKSXE NjKaIlrIjD24it5wJ8rF1mQdjLaJkklTnXN6UmhYEeyK88VowC2AxxrS+unWp2/LkPdyYirdgdAR 5MUqVZJ/bMiGnO4ZFvOsykwJdGkwzXPaX8o0SwWPhP8Q4v7NU0N3GqMG2LMm/lSLZTVg4JfBpIIg vx2GwL8m3y5tKYDRlO2qcidslS/1PsPYUzwQqmfReX+21DhtwFKyrCAVKFJuzUYxHo0eAlRrTX2t cQsbkRbk4pDn3MpssKnJXkZ1RG5FfVCYRo6hLUpjoybZ4NjA1+0Wum6G/AOto4fX7bp25Ku8EulR Fm5CkoYcoKnwR0mnNIzrmF8NoRKn+7ccracO2ijSgfviw3hMfcGWPGPZ5LfA10JxdY97zomxmHfI ItNpEO0DkWmQrqSvqsCzr0j9ofyQKUr0+fKpPBjOvTnXkopHB+OjWid+i/yfYGUi9Bppjm6NfeG5 s7amyNntypOFCynpgORfMSW1q8Wg2wn8+Zm48OSlgDhYD97DRgmgM0+l+3PwDPOCDjh6xr/ZEM9X x7Pvf6RqkSYkbrB72tVIdZufWJUHPTmJDEUHHiuWoHypXiknxn5eEC86e8rx+mFcShaKF5EIl6j3 gB5EOoDzRTSpgA5+sr5/pQrA6OYHId6Hvd/p8w8SBd+PZW5kc3RyZWFtCmVuZG9iago4OCAwIG9i agoxMDAyCmVuZG9iago5MiAwIG9iago8PC9MZW5ndGggOTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJylVm1v2zYQ/u5fcVM/rAX8bmxJjXmF4ziF1zjJbBXdMAwDTZ0lzhSpkFRs //sd9RK/pF0LVIYhSLx77rl77kg9Qrfdg67/VXeeNjqLC4htowvv6R83Hhu9wgCqG0/hKiSjS+j1 IVw3Sr8e9AdwcXEJYdp4PVMOjULXujZs7eD8mt1fT29ay8nsxUp13eAK+t3e4E34b2PwFsLbxmt6 6xIEmyEXa8GZE1oBUxE8oRHrfbHItTHInUJrQa+LVx8XszbAWL35sdEb1EAizbRxTDkwaDOtrFgJ Kdy+drpGK2LFHEYw3WVoHAgLTgMqmxskE+YIr6ZkMBaW8iXrcZZJ4raSCBPJrEULjBxYlhmdGUGI sNbmzKuC8uU4ya5NC/2fC86XPge+UXorMYpTVHX8TwhbncsIpNigp8ierRDmhtyu2ZOI4ErSAqyN TmE6nzRhm2jYCBXJ/UlhiCZZUyIxKjQ6t2DzzNeqCVhwY1JSlVSRwWx8N67SMHuqkM3Rtg+8mLT6 jBwVTm3gN/K/Yhs0JZ/5LFxMm/DAcgkTwROSYyOKpQrrbrYM/brSFj6wNGOKbUiPwnkyW07um7DQ K6/SnBkn1AnsB+YSiagqrLkmFQwpfSjFLYtZhBweEuqBLMNy6W4cEu4yyRMU8CdLWZzz5IzWhGiN lSPGe1jkbqO3NXPyIJYQIk+UljreN+GKAisIDUtTlMc4k+ki7NyhW46bRT+Xgn1ikpojFabmQ0Wo e0cYsEJx6p0KIhKW59bWE7FGjFZe70IoKlWkee6b5qij3vqOomxVJHYwG8If81tY8gRTRt2/FkoU 8+UDTneO+p6eqmAhSX9kHaHlhuZHxUVToEQfiWJ6FOokUTbLMcqh345CWRpcfye6sXhCBQnlRySn jCf1XOKO5Jc0VAS6rOxpkyh52aTotRWWO4Kg2NRyT0yKyM8dqSyUdWVBbMl9tQeWO536Sa8HWmtZ dPFh2/nl3S6VHtTTHwW9djegnYDriHIeBR/Dm9Zl8O7XQ2m9y85GwyqIYyZGd8dSmiDGcRTkRg0F uvUwY9QNdkjoQ2WHQlPJWpaLlo9wUiYgE7Ig0FGQOJcNO53tdtveDtraxJ1+t9vrkCKlIEGVSOVT oH4lZhXv3Mtz+Xa2hXel/o02KUlLE+1GwWNOEng5AmDOUavkDk8McnUw+UwZy80a1DcW8GXxSh1u dbmrjoLC7p/ybZsiBJ2zqD+0Wv+P8DkCpc0RiQLVu7daL/FH33md8BuN/EBej8Pxl87Tr10FYAn1 vdeLbL2GXPu53YV72l69kKOgIlwIflTpE/OJps8I5eo6Pi/ToU19VI7/ilmsJB0+7zE+TnDsVk8k PuY0uXi6VC0y2sWPmuzVK3oR+BOR0+dERcWOAsl2AaRC3XOeG3ouuu2nfpFByDYsYTYRdFw6OgDb Z2Wmjwna0O2XVPjrgdGp3bv8mxCnYeN3+v0HkT3cSWVuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoK MTEwMgplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnic3VVRj5pAEH7nV0x56V1ynKJpvTPSxKrXmFxzVnlo0vRhXQalB4vCktJ/313A kxXo0TPXhy5REr7Zb2Znvg/20L02oSuv4k4DrbMcwCbWuvBJ/DbaXjOzAChuNICPtgi6AbMHtqvl +0zo9WEwuAE70C7mjGPEkBvTiLgcTtf8YTq7M1aTeQUp1h2uodc1+5f2D61/C/a9dlGGA5I+UJpE saUnbB0mzEFH73y4fKuZfTV41EljZxjjPkFGUUaUMAkRziNvnXAERgK0dIf/2qEO8t/SvdBBd5g9 MrLnyn5IYhETCW4vEvnB9VJ0LD0N/LyWZzJhyg0lW1apiGEbPacOd9wLGWlHFyBh2dYKWZvdbhgF hHvOC7dHKIOpLFftXQnIO6iw5dMpxRzBHKJhsPMxnYRCT4wfUAWzBasEjjIZvTEM68ylSMmyYEVD 2QyY+CSOm1TbvDLCnOrcZRjytL33R51nE0EfA9GiYh5FuXrVEqOa1p0Mt94tjXlwhVwZuhFTb/j1 8/10bI9PHCOs67GDdbv6H4x8hoVXO6TzaaOrngzb1qSNfDVvg3rL1gq2rPOiq+pkX0PHY84JfVyI Y4r389+r+V/rWCn3FdRMt6FXhWpLWZKfU8JJe6W/ROuV3BG6h1fpEl2M5El0lbgmb6tMhShrO9BQ Q3behU+4/Fw8U8Z/bu13vUyHNnkkWxJvvStADsS/VicBs3QnCmr02LcF2SCYt98F48zWvojrNwGk jO9lbmRzdHJlYW0KZW5kb2JqCjk4IDAgb2JqCjU2MgplbmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0 aCAxMDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztVk1vm0AQve+vmHJpIoUY sBqnlonkBqeylCqujdpKVQ9rPNjUsODdRSX/vstXKgKkiSy1lwxCiJ3Z92aGnScOYJybYORX9fQi MliOYCuIAR/VvSUHYhYBUD28CD64KugSTAtcn5T7TLCGMBpdghuRkzmTyBlK3eHUl/DY5nfO7EZf Xc9bnspucA2WYQ5P3Z9k+B7cW3Ly4JtkYjOmUvJgnUoERiO0tamU1Nsv1LLinTsayPtELeehQkWy rXb6lpjDJhKkQsXEiQxiRkNtcKViau9kkO/14igJMXMV2B9n6cIQI2QyX7YuatzJG123j7RGorYN X9KQIafrIAzkPVyHVIi+tnVZAVhCHWu63qy2+hZVJ6ov0UhXu2q1fdLb1wevwEOKzHvkqrfu4qDt 6kxlSX85VNL6MATxBn1deMH426dbZ+pOtRYIRAG787yUC1szNIhoVr+lbB2nbIOb5jHp4OboV1zj JfrI80q0JnAH77OYqkPZ2YGeHIp6FyGVfsyjv6TxzCSeIFp5cTFsx/OUpXafhE4FWCXodQ5+OeVc IQW8g6cLCzOp9+I1q3lCQnrAGwNyHMP/E6mWSn1FumeopOnFAlXav5apOt9XhXpVqJfwvLOKo+LS Pd1RsQvOACXQ8LzZLJhliVKb3jn4vqBbVH84PxTizCWf1fUbQsx9BWVuZHN0cmVhbQplbmRvYmoK MTAzIDAgb2JqCjUxNAplbmRvYmoKMTA3IDAgb2JqCjw8L0xlbmd0aCAxMDggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztU1Fv0zAQfvevOPzCJpE1SQUdVYM0lg5VGtroLIGEeHDT SxuWOKntjPDvcZpktE2jVZQX0M6KLOfO353vvm8F9pkDdrnqPUhIbzqAhSI2fDDfgqyIsw6AegsS eM9M0Dk4LrCQVPcccPswGJwDS8jJRGiUArXlSx5q2LXJjT++su4uJy1PbVc4A9d2+qfsO+m/BXZN Th59o16h5kOFqxxFgO9OXxKnvxNRBnCtZTTLNYLgCXr0LsNg4lPQPzNzWkOYALGgkCvzQxq8SOKc 9krEJ7Cw0FYn3tb1CjzNdJQKHh8E/hn5vUCljgOvuhSkSRZjwQzMb2flwhgTFLr87b5p+jd6YVne sbY1Ec+D25jrMJUJXMZcqa6Rd9kar0I61ixr+7X1AOpO1O1vqqVtZo06W/ro3aTlxqDqq8s0arv2 VjHlP3yuecOAKJ1jaKkgGn75eO1fsAvaAoEkEjdBkEvlUZtCwovmlItZmot5m9ut3BLDOtdwiiHK 8iV0G3hP3oMy1Xzc04G2nv8XJTdU+leVvCvk8YNJM8UslfpPtPz3lHyQkDeqfdbys5afkttrd00P xu/5kqtl9ApQA4/Pdkg8LjJTUCfzv97yBYLrfDOIY0Y+mfULOORye2VuZHN0cmVhbQplbmRvYmoK MTA4IDAgb2JqCjQ3NQplbmRvYmoKMTEyIDAgb2JqCjw8L0xlbmd0aCAxMTMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztU1FvmzAQfvevuPGyVhoNEHVpo1CpK+kUqVO31JomTXtw 4Ei8gSHYbPTfzwToQoFqWqRqDz0LWea7++58vm8L1okNVrnq3Y/JaDmBtSQWvNffmmyJvXOAevNj eEe10xnYDtCQVHE2OGOYTM6AxuRoIRRmApXpZSxU8NgWt9782ry7WnSQ2q5xBY5lj4/pdzI+B3pD jh6wWSGDKVMq46tcIQgWo2vMf6JQC88AdZ/qY+kitYdYG8eviT1uM0AutU+SKp4IFhmjC+3ToLNR GesncRphQTXZH7CCMMJY5yp/O28b3tkr03QPtFahrgufMeMh91lZJVxFTMqhbvXajrCiOtBMs33Z +gnqRtQPsF+tcdFp+mywqw+oxG2Own8ENaGbhHeh3kqW7JfHFGtGgScBhqb0+fTLhxvvkl4aHRKI ubj1/TyTrmEZELOiOeVileQiwKA9JD25MwzrXNMlhpiVNzHaxD15/ypTPZI9HaiQ/sb1yuQuRb9X JZUkMs3Es24NvVxYKHOQr32FJ/Q2QL4/Tocl+H8EvdR5Av6ven5uQe9V+6LnFz0fqOe9aXo+OZ86 u5Gl7AfbMLnhbwAVsOik/WgwL1LdpEE1fv3I1giO800zzin5pNdva4dl9mVuZHN0cmVhbQplbmRv YmoKMTEzIDAgb2JqCjQ3OAplbmRvYmoKMTE3IDAgb2JqCjw8L0xlbmd0aCAxMTggMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylVm1v4jgQ/s6vGOXL7uoO4rwBiSgrrrQrpHZvr81J J1Wrk+NMwLvkZWNT6L+/cXhpaOF6L0ZgYj/zzPjJzCQ/gPUcYOazm0Xese8GMFcdBp/oO+/86DgN AHaTyOGXmEBDcFyIs87WzgHXg8FgCHHeeT8rNNYF6u605pmGl2P26/Tqunt/OXu1sxvXmIDLHO9D /K3jhRDfdN7T6sjeqDRSYoE5H3941wncZsdhPYBJVWGRyg3MZhFMCvjj9gaysobLBYrvspjDLK+W mGOhuZZl8U7BbTwDURYEyqV+Ijq3v3cUL6QChcIgoarLR5miAl4AbrihObCLPbt8wU50jrenO/bU M/xbCsHrWhLz7S3pATlqnnLNQRaKHBp/jVDEZVjSUqyMB7L/XGoEveCafrBlp2COBdZcYwrJk7nY Mj8009cd0VrqBVzNLid38NBMXyGTS1REfCySgjIjD0aLCoXMpGiWIV8pveNKkA5R8YQ0IWzFa2XU MFG1pOoRuHUXP27yJTwiQcviwnJ6zAIsRJmS5YX1e3zdHVofx0cCjrYJM90pcGRM1ktuLLGwdkEB kIdCXViruogk6iyiwHiuIlqOChXJMsWsaxwfG2w3/qNZVwn5hikhTplvFBkutK4i216v17211yvr ue0y5tik3n2T711KCs0Lgdb4YD6aFYIShQSpVnVVKrywaqzKWpOSLVgLOJtCwXPCCSVr3dvdo54o c2vsDEM/9Eb2M/aI4q5hjmWOY1OZXeZ1HS92vcgJI9f/ibGIsZHdQrWNp6hELSuTPeND0NtYKdup OPKKF0+w2YzsNrRNMVEKlTK3v71szka2QjccS9RNWmSc8jm1QD9VdFae5rKwwD6is0/zjW5RL8r0 hYt2TNRbmvCpHLA2Sc/hcbU0VZfIJZW3qULME0xTTI9Zzh3NHC5NpVnmy6kp5HQbOKWHdQwk6CGV oonWXHz/wrXptS9gcE8VO5se5ZXJyyazUtOU/zw0YZv60ys/R57u+PqtuBqLnC/XvEbSkBv8Cci+ Mv9pWGcp/m3VnCRScvc0uSm3re3/BdZqSxQGM61JpnTV/D0lGEm2S/3xZ3sysvcXp6F8RalZj7ct /dO20Zt2fN8k1cje7Z/10+R6jEo37b71qFg1TXv/tGjCeF1nByZNxU2i5tWhD7he7ASR40YB6w3c PjON4Bl1mqVMvtHzVZ3epf0mRKNeX2A/850gHfqDIPCDBIOEO46fuWyYsCw7I2xDkqfB+C37kW1Q 5znUgjvjlHsh9xAD7Cd+wlLPDYIkwywM+oz6JuNZOmQDFo7sBv63bG7QH6OXMOH7bjjMhCMcP+RZ kvliGIb9LAld3x1w9B30+36YhJ5/lm8/BPfDIAydZDAM3GQYBE0gxtPza1LMv/MFVwv5M6AGvuy9 4LjaVLKml5Ez4+ELnyO945m3iKu48xt9/gIy7M0aZW5kc3RyZWFtCmVuZG9iagoxMTggMCBvYmoK MTA4OQplbmRvYmoKMTIyIDAgb2JqCjw8L0xlbmd0aCAxMjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJylVl1v2zYUffevEPyyFpgtfosKFKNt4nQGlq1LDOyhGIZL8tJWK1uupC1N fv0o2WkSp7KzjYIhmTzn8OryHlJfIjKmEWmv3d2uBvFVEi3qAYneh99i8GVAO0C0u9lV9G4eQDqi LJr7wZZHI8ajJNHRfDV4NVs3WK2xGZ1X4Jtov81+PZ9ejK7PZs9Gdu0CTcQI5a/nnwY8jeY/D159 F5fVS5CUTazXHCmXCaI32jhPpWBaEqeU04QkTjGCgkhiZEKle/3DgPJ+1ftmNfcCUkYdVxZTiyJx xFFupdPSM0N8mJZqx3QSJrZB9bAe84qblFPjRCJoApqC5JqzBHzKEgccs3j3Qr1aWZ3f4YRqEaDt Uz/Q5wWuYYUTzC1Uf9pyNb7LN1n8rb+fejm7nM5vNziBzaYI7CYv13FH/jbSQ97K9462g1HuTodC OK0VZR5Bg/ZcOdQMKUs0GEOYHx6IbuXk5Bg/i1vUgSwugU44T6WWYWk1DauZcM0cYsJU4CepNkow TwUVpFsVeliNSTVhiQTCqDE+cHWKUoSFpjpNfeJM6qhS3FuVSrQhbgbH68WKUB8AxitJvSO+C6Sd 6WAonSGsJtJJDyYQEwoCDJcMUis5RyW9YU4araWk2guUR0NREpXWImGMG43KaGmNCHkHD04LFpLm 0pTx1KbIlSRH9aRVwhBnUyCKupCq4FHNgxUSCD7gCsxLraD0USfYynI2oYkkNKUpZ1m87Xmpd8bB Oy/yzT3k97xZ5uvZum6gKLB6UOmnxn3c/2C0LC7NJ7RN3TNcYdFZul7mmx7MHipqgudPh7ZCaNC9 ux12JqaHXFqXf1X2QLK6GfykfYuPb1q14EPlRdidQ5lJKaRBaYBS4RnR7VY7/OOQVtyKHUjvsXCy BqoFNv8i3qNb2P+K91g4WZOvMNTIajNpD8oR4SPG51SeUHYiyTgRgpCwcT2geuvo8Tr31dPRign7 LRQ3UOElNnAODTwHZXFeOvSj2uYnV3DzPdBjyNumAfv5AzTtl8RTYBa/dS5v44FiXyYcUdgsS/ek 76xcB7EmqsrivorLargr6rJawDq/695vr6Dvib+0tp9+DWkssLVxdHY9u5pn8ePhp8QrXOR1U93+ BGsXjrxq9/d0CFUeZsGt1qjbWJ5i94SmK8iLid1O9MbWedWM8SGSLN4CnmRgF9aTzunfuG6e5zy7 KMqbZ8twfVs3uIrCwY+Lso16654uO5J1H05z+AxLCPXwY4RNBMV4ryCmXzd5hfWzWtq1jx9ggRET rUem88Fv4foHvwtx3GVuZHN0cmVhbQplbmRvYmoKMTIzIDAgb2JqCjk3MAplbmRvYmoKMTI3IDAg b2JqCjw8L0xlbmd0aCAxMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVW1v 2zYQ/u5fcdOXpmj06iZxDMldF9uZgDrrGg0bMAwFI50tLpKoiLRl79fvKMmJbWVFR8OQcLx77uFz x9MTOJYLjv51zzgf2F+uYCUHDtzSfzV4GriNA3SPOIefInIagetBtBy0cS54Q7i6GkGUD87CQmFV oDKnFVsqOF3hL9PZ3Ly/CXs73ZrjA3iOO3wb/T0YXkP0aXB2tO/fiQQnb98M3GF/k7Y/JkmFUkLM FK5EtQsMXm7em4zMxsS99izH8izPcXy789RYPZQbsdbnALUrMTBwg4UyJhdXvt1t9IN8e0/s7Mh6 v5MK8569NR+wVKxaISXpA7+G+62jFhpmf1L30vZG3zjr67Q1Qaw2PEbg5deyEkrEIguMy1f4ke9n UanJiCRtXl7J0YF9nzq+Pc9EfWKbbUuMFVNcFMBi/QiMh0zEj2YqpDLA/g5/oVKsTlx9e6aLO2WK HZl/5lKRpCeoP5gm3IhCESLUTEJZ4YaLtcx2kLMEoeYqBcoCUqwrEo9KUYvqEURdUDOZ5glclyTU nbAnGbfwZotgSq6wJ7pPdDHiOU6okV3TuTbd95EzGrvXY8d95zhj3d7PPr1glHHFS51ucicUX/K4 1UmSEKBEr35ESSqu1ljEO7Pj9+PBVepV9TDDSWkPjnxchp7gvh0WMU+I095GlmZ6TEW8zjv7hddM Ade1AD6WJRYJ30IYhuODSbOIQpBxijmjAO9yPzailEs6c6M7VVJsKJlsq9c4g1iegGywktrZtZxz qFMep0dziOAavqQoJsA0FpkSPQffSA1AHElwJDtT7WaXid7iCqlgSXfUByYJglJpOosFkdi7NrEa loZSJkryethBOJvNILy5v4UFy2pWYQezQMUSam2YbeOUFSuEuahyAvidupIXK7itxLokWmGRICbn p6Qoe4eU84Ln/B9K9yLOC7cXYTyLAl7mtv9hm2f77cAg4QygNhIJJQ+M36K5OTI+HE9zfyvHXQ6K LeR4KwMjVaoc23Zd11Y9tES1snXn238sPt03rsa+bdoxesdylCWL8SiSo1o2sU1Jvj7X1qbSPAM0 Of9/GGaoW1LLO8UlW2cqMJ7WLGt6wThUYNRc55c2bA/M8zLDiL42UBD3wPiCWXMpZcpLbZ4V69w4 /ezpSBrrquJtE+uuCQwNR6ZiZRxckIg9spQR2jmgApZZcLxoXnKCgv9Yf35m1DzexV+EOIsGv9Lv X98bOqxlbmRzdHJlYW0KZW5kb2JqCjEyOCAwIG9iago5MjMKZW5kb2JqCjEzMiAwIG9iago8PC9M ZW5ndGggMTMzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVVNj9owEL3nV4xy KSt1IQkCttXSA122QiqiH5F6qHowzkC8jQ04zjb019cJYeuEJCxq1TpCCZ6892aG52EHTtcFJ7uK O+VW79MI1rHlwDv9WVs7y81fgOJGOUx8/dINuB74K+uAc8Hrw2h0Az63OjOhUApU13eSrBRU12xx N72//vx2dhIp1j0uwXPc/pX/YPVfgf/e6hwCt2n8GkXCURLFNgIeSZTg2KYSicJgsrd7b65eWG7/ N+S2pyESYyUZzSBZvPMUiBnfRujvt5jte8MnXC4UIUehQBCuNTiJfhCJc1TkjihinwhpBN1kdOmR z0g6xl2CgprbNRoZnoi9DUozjO0Mp/MW60NZzTiSqHAjL4ZpuezbxTjFuG4o4VsDGegfwNf757Cb 5QNSFdvAmVhQmsh4bDu2iWnpZEsza8VWLMJjjtnzIhevaJdJgJP0GEvEcpOIAINyUUfv1GWRRxqS z2NFgu1Nkhjl/o5Dtv1HrTIljy0r7f3vNjWRZaUQpX27TBRCEud57xImdT5FbY8oY12G6VakTB9o s6gVSzEY227XK5XxDHoWtJ6gxlqrhVbGjwEx7FxYuG76NDSnMsaCgZFtiOmECSL3JZO5Jx0oc8Qh cc+SOOdJvMHwb9AMXO/PadhPNEiYqE6JdjiVtO+duuB5FLVHqQw1DJA9mb5tm90XqhisZb0vTIVM zIQe+lGEZ/5oSqI1Rcxn82lm6vOHxjT0wMvN7pPvJCR6IL0EVECiLpTXNN3qoxlDw/r6gawRvOE3 zTj1rY/6+gWbqphPZW5kc3RyZWFtCmVuZG9iagoxMzMgMCBvYmoKNTk2CmVuZG9iagoxMzcgMCBv YmoKPDwvTGVuZ3RoIDEzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1V30/b MBB+z19x6stAKm3TbpQhmFRCNkUCyqjFHqY9uMm18WicYDtT+O93dgy0peVhz3MUx/Z3/u7u8488 wqAXwsA+/psWQf9uDEsdDOAbvcvgMQidAfhPWsAFI6MTCIfAFkE7L4ThCMbjE2BFcJBIg0qiObpU fGFguyTTy/jr0SxK3iC+fMU5DAfh6JD9DkafgV0FB278rNGn3Bgl5rVBkLzA847IOlBraih8rIVC 6pqnivpkm2NzISRXT53+l8MPQTh6oTrrE5yWRbXChpG5hYfHr/Am6l0pXKBCmWJni83Za2Hto5Jy l8YatJDDsKFBLUoJc67b2DSlIZdtYJ6kv5flH8NdcUM+dS6q3RGTYjad7WBXWJBzz6LLWvmMvc22 u3VoH+9OatKzA4WQ0zStlT7vhNTjzXOvlvOylhkt6AaNX93Xtehv+u/vCWCXhAdrkA/tXS0MV0s0 /7VwWogCteFFtXbeMm6Q0fjbXf0miF1H2fI8s92tbV4bYizrYvug99+nE+tXAZdPM3e0mHPiiMrK euCrNaL3D1qbS5pjwS3waeiAcNgDmFQVykw0kNyfQsSpacWAWYWpWIi0zQUWpQKTIySTmwkwPl/h Bj/LhYbM3ZkZLoTEzFnTVVGnplYI5eJ1urHTQUiYYWrZ4SNd4b2NY87ysl7mbkrBJV+26+dJ/HwN dQWmdJxdAmiA+1y8KJUq/4gMNaQvaRGNEqgp75uSuibnBqb3kysgC4juY+AUrMKl0PQjwMwTGcUz kk496G5rOLmNoy5EUUxVbKtbW/1w1WzWheuJxa3pNEquLOkOJkqHUTrXCbuLISpVVSqndm9D2pBi bR1S85gg+6siiPEHnnPaZV1AA3zVg80SNxXtNQ17ys9bUhWG41/EGLPgOz1/Acc9FgZlbmRzdHJl YW0KZW5kb2JqCjEzOCAwIG9iago2ODQKZW5kb2JqCjE0MiAwIG9iago8PC9MZW5ndGggMTQzIDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicnZRdb5swFIbv+RVH2sVSaeFzWTLuspRO SFXGgO5m2oXjHQgrNtR2ou7fzxAWSKsmtLaQZfz6+D0PxzyAbTpgN70bKTOseA65NGz4qp/ceDCc VgDdQBl8SbVoAY4LaWYc9jngejCfLyBlxiTkCgVHNb0WJFPwtIXfroObabIKn6107QY34NqOd5X+ MbzPkN4ak/b9mjCUNaHo99qtUrVvWZTUSE1WKIFmJXKr2kgUe7IpUV69NxyvD5JoYZEVlKii4m1I H1YVY3qyVIrQe4iIavxDwHcMxUFH+G8dZ/KSY1iVRMpj2KP0Bwqp5/5Q6pifjusxZiiQU4S7OPTP ZnTcs6zrUp+jUzucitLvnHfGtXLm/k/YNRt3qwBmpq0XxuKk2B89HuCq4lmR7zpmA35ngRycXQYy 9HQehz5l+C16Gt6BRpLorzAGx9pavjX7hFai4Dkkf6VCdqEixgGQgpq8kMrMq71V7zZlZ0Na0W4j 12GShrE0t4qVZ2v1XaOchvF0PrPdsxy7HE4QfmwRBkHjGkhZb8krygrfVFbBHrmC4LEWKOXl69Xb uowUR9dUayLGuhLqhMes5REF+qZ5cEt4viM5vgJJPXRQdvstty2JkXyikqisEuzkj3XMunebknuy JXJbfABUGpL5pDA04UIjfqlufkbaGbiLXzpikBrfdf8HLTqpsWVuZHN0cmVhbQplbmRvYmoKMTQz IDAgb2JqCjUxOQplbmRvYmoKMTQ3IDAgb2JqCjw8L0xlbmd0aCAxNDggMCBSL0ZpbHRlciAvRmxh dGVEZWNvZGU+PgpzdHJlYW0KeJzVk12TmjAYhe/5Fe9ML+rOLEFwdlHvWsUOM52tBepNpxcxvmBa AmwStf77BvxYtK1bu71pGGTAw8nhOckjdIkL3frYX5mwnMiHTFldeGfOzHq03EYA+wsT8DYxoj64 HiSptXvPBa8Hvt+HRFidsNAoC9T2WNJUw/kIP4yDiR2Pwp/+2Y8JzsHrur2b5KvVG0Dy3uo0z2co FS+LYVvrkd7Na8vtPakiTFFiwRA+ReFeu9S6GjqOYrQiBVeaZOXaURUynnJGtTFVDqvQuTVend/F OrgwJdmTS7Wa50eP6WquHsI4CSNFllrkF+1e1Uo7jGz/fnB3VL6pqtpvniOMcqoUqiFMc6rTUgoj uvMOX3pPzM9oGtQIYMxZnYDKrdG0mT1QgaqiDFvUDt9RIRFcSySlzJzF0cHxSPeMadxG1XgOYVQK YW4O2SAoVgLlTnES57ny/uPa/Otr85vaZgG4DeU/7Wrd7srcOYtyU+QlXSjHvaau2SovTEtznnO9 BVosIPhelWolUV2sajfJs1Wd5rxI5yTJCaL+DlE0uY7RZrMhZhLFm7nr983KWaKgJpVMX4IpwqqU mhcZTEydVP8LUqdp64R/SWuwoxXH4F1D62xTHUApZa+9l7CKWSlrUvFWaWwt/YR+o0uqlvwWUAPN ydm2MsuQm0X4qx1Xj89TmiF4gy/GMUisj+b4AUVOznRlbmRzdHJlYW0KZW5kb2JqCjE0OCAwIG9i ago1MjcKZW5kb2JqCjE1MiAwIG9iago8PC9MZW5ndGggMTUzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnictVTbjtMwEH3PV4zEA7tSk+ai0m7fSjaLIvVGElgkxINrpolpbmu7DfD1 uGl62VBaVgJbkZV45sw5x+M8gWlYYG5ns9JM6wZ9iIVmwjv1xNqTZtUB0Cw0g7eRChqAZUO01HZ5 FtgO9PsDiDLtxs8l8hylfs/JUkJ7+LN770EPXf+3nWY84AJs03Juo2+acwfRWLupv39ELliRD09j 7dvXmuUcYwJcIsecInwI/CYykbIcdrtVVRlLxoU0Ch536UYIlbvLGpVlyihZpAhuSoRAMYSQFpzl sYrp2Xt8yzQA3EcPeoapNk7JTUmGoiQUT+hNu6MWvbBEypaqlFRC6pwhuEWWqZdHJKschQAvX2fI 64gDwXPSe4Z12L8gm1ZoZExyrGVflLyn8FyzVWsOQ9Ukg/8munEbwh9CYnZR947GC3XTSojL4s+e t620T0aeC/ZfHXhTOiNIT2p/moxDmmBG6g1d1UG93bfnPJqQtCIcYSQlZ4u1xNPWAJJ/BTchnFB1 29jP6/2yk3DVtxb5i555G8xlgGXBZWdLk9DVnMjt7X9uo6NsnLn++GU2CkpKI2fqwsbFRr3VFhaU pd0dzDX/ZiXmyiKkq1SBQP1bUm6xDcKY5PGaxPgvDGvRPCUidnQ7B5hzY9+vgtMjTLlepAeQ+Xoh pn4Y+YEwEpmlF+FebSN1P9D7b+7s4zFEZEUSIhLWAZRAUqOV5n0vGUfxJ9TPc+UWOOYXhehF2ns1 fwEU+qTKZW5kc3RyZWFtCmVuZG9iagoxNTMgMCBvYmoKNTYzCmVuZG9iagoxNTcgMCBvYmoKPDwv TGVuZ3RoIDE1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN2UX2+bMBTF3/kU V9rDUqlAIM3oeMtIMiFlTUdoVGnag+NciFdsqG2q7NvPgfxTqqbb1KfaAkv28fG5P5Afoet40N30 7Ui55SYB5Mrqwlfz5Naj5TUC2A6Uw5fUiK7B8yHNrHafB34PguAaUm51YqFRCtT2UJJMw2mLp8PR 2J5F8bOVbRvjAvyu17tIf1m9z5BOrE4zP6iqglGyKBCigiiFKoQ5SpaZSc1KcfHR6vs7uXflAEzn gwn0HW9T3hAzJthGp4zw2PeGcFQVoRgeMqy0rkLXLZ9I4XCmJTqlzN37b5MZXSEnzYK9PFjafWPq 9Q6mswrpPllzRAjTCgXM60KgJAtWMP0biFjCYFOK4ig0TIjIa5KjMWttTH3KGITHfNqC9pIEM5Qo KMJdEofn4u+3/BvJ/gnJBFVd6DejKFu790zw0wnBqOS80bwJQNq4vWd+geF3H0XDMXiO//fYDCP6 UDCllSPM28nLJ3dN6TJzW5vXaI3WGoViTchSZCyvZbsc7YzNraKoZNU2cgdeauNScqLPQm0zvUpU UVIdylHHsdW2usuzUXZwlKQHn6peFHuX23qhbuJZGifKWWlenLX7sFHacWIHftC35dV/fOKUPJAV USt2CajB/DAnR4zWFTO3xEsJftya/xV63k/jOEqt76b/AbFf3m9lbmRzdHJlYW0KZW5kb2JqCjE1 OCAwIG9iago1MDcKZW5kb2JqCjE2MiAwIG9iago8PC9MZW5ndGggMTYzIDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnicnVbbbttGEH3XVwz40gQ173YsEbJSVZJTAYnb2qxRIMjDmlxJ 25C7zO7q1q/v7JK0SclBgFIQBA7PnLmdHeobBF4Igfk0v1k58O+vYa0GAXzA73rwbRBaADQ/WQm/ pggaQhhBuhrUfiFEMVxfDyEtB2+WXFPJqXbnkqw0nF7L3+eLW/dhtjx70ly39AmiIIzfpv8M4hGk HwdvwtgDmFYV5Tk7wGMCUy70hkr4+9NHWBxIWRX07U+D6J1FI0e6YQoUzTQTHCopdiynCggHWoNB rMwd4xk+4Booz0ROczQA8tY5esgYxj3GXAAGBk4zqhSRrDiCpJWkynAYR8HRtCdH0KLhBAIVkZpl 24JIZDRcbVivoW2TQi4htc2TaE2yr4aGwOxheZ+iEdMzWI1doHlDtZKitJFbDqwzk+ypruXz/e3s KrgOvoAHSw1bhU2wkdmKUalgvxGKNkw5s90i8ggrURRir2D2uIDQC0BlG1qSizoFDYSWyK9s82so 42uYLRYNU+C9s5WJ7XpjclMUVEUzjJkREwILlNQ2smBKd7o+vZuCJk9YBdENlzb9KUWJOV/UN+1U 1cak2C0dm5XTEvm1JJqaRw3JVpEnVjB9NGM3HrlRpplvoy/EjN8fygJ22BUkv3GwbKeeINZ24/yV 3rpD5/2kJ4lxLeW5yLYmv54zehfEeFLuNFkABuDqxtlKnjCqVwnqgpQqQXPCVcJQLCvXxO3ha/v/ 83JVxn7giYhXvA8K/TZaV4nv7/d7bx97Qq79KAhCH6f+YPXgMuw04Rl1Jq03tqQ9UdVWViiuG6cW NXaxA+sAl3PgpERcppjUXjNLLxOlMwmHo8tRPPZfsD2Ke8ucspJOTGZuMHLDOI3iJBwl0eXPQZAE wdjvoLrOc3tOKiOlyXPSda5Gjxi/IvwIh8PY70K7FFOF50mZ0XfNpjb0zbTlKKi2klgRVtDcAX2s sFaSl4w7fo/Nf51u/InqjchPInRTmvLOmbaLDXbbglPZit5sDXNiX7ZGG/I7lZna8pzZdVDMiSaQ 13mjOpw+EKHPQkoeu2FPYPCAK2A5f5ZVtqNeybSkVll45+dizwtBcuV3BdlePW7Dg8vJxddE4AaX w7jfS9vNXgH9Tp+3dDwTXJuZSVEYLUpKtJDtuDBDwtm/dnmd1N863qGGJ4sX8dZLe+x3H/cd7+ka t588/oZb1e7++hbFIVEbk+YguMhlNNzFnhAtStTWJKsD/XJ2jMZ+Deh1oEmrZ1zsUESnzUL7LS74 s6E/HHFzl4ALna6FyVqJreytgmfoHerj3FxrDF+dqkPCqt2lS9CMZ38UeYEXeZE5ww3yVZaZ2Jo/ HM2oqCnCmVxdmxrtg1cy8l9LaezXNf24VE3kmmpb6lVkXwYp+Uo2RG3YBVB8PxbeSZKLQ8WwAPjO 9fkPsqYQR1+QcZEO/sTPfzTlxPBlbmRzdHJlYW0KZW5kb2JqCjE2MyAwIG9iagoxMDg0CmVuZG9i agoxNjcgMCBvYmoKPDwvTGVuZ3RoIDE2OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nJVWbY+jNhD+zq+Y8qV3asEYbneziCC1t7vXSFW73UXqh6qqHOMkvgXM2c7bv+/wkjYJJL2C EOB55pmxeWbMFwh8CkFz9ndeOuTlDpbGCeATXkvni0NbAPQ3XsKPGYImQEPIFk7nRyGM4O5uAlnp vJtVVuhKWO9Bs4WF82P268Pjk/f6cTaw9MeTmEMY0Oh99tmJ7iH72Xl3Yk9+UblI33/r0GhoRPMP ea6FMcCZFUul91NX1psPHmbkpvQ+9AM/9OktCScJ6aEN2VkMcghyNv4q9EZyAbL+q9bKKq6KqXvr DpGIfVbappMgIe3DSIyebMSEiUkrVcWKB2YZ5HZfi6m7K4vxSBKTXXiGy/i5YHahdDmCgtda8NnD 1F1ZW8eE8Fr4pbRa+EovSS55G1DvCS6RO+Z/4G440BkpSsm1Mmph462scrU18a6OcV1iU4cuGZvy 6cTOEbgke2NFeTqekKdCbc/GHnc4G8saLmBt6lN3Xij+5q2UsS6Qr8AruxL6PM/kG8+D5EVwpfNZ kwusmAFWgdhxoWsLC61KYFCoJXjemW/nNphWNzw2YzTisMhkKdIwCKgX3Hs0yugkpjQO6XdBGAeo oH8wI+7CcC3rZkYpg9/F3DMoK6FBbERlQbehkeEINiT5d7r/Q2uPTYAXUaO6B9oSR9oa5TlhemHb r9F564XUMV6AoMqMByTUDwjKcCELQUal3BwtQUN1heRiGn0i7RpfxiCqUWNqWlX7YsfKuhA+V2VC WsM1z7pi+MHZ2q4S0j1fQ9tOQZR6NPTCIKNhHE3i4ManYfTh5tYLbloh2VERHfGwuo9b14Xkbb0k 5DB4NV2ZpxgLc5WDAjgBGrFJKabS3K9m0lZpinUmmxT4uHSPHHJVMlk1mSekf74GV/PP2BFSxrla VzYh/fv11LuGvRXzJv8L3fvYATvO2qRmzTnuM+jTvV8WFflPVXUQvC5UFRmU1WgZk9E6HmvZR61w 0K4vNbaD5Xg0IW2gc3DykzQWt+mRLvxRVRa/O2yxAddabKRam2IPJcsFbKVdAfZvMGqtcUPG7X2r 9BuobYW9b9CY+yBthzu0f97Rex2DZ6QVbb3fhO1/RcbeGLb+lfwehAVW+GdLiDuKxL+H0e+Ixx/P bCkgiv5ExsfM+Q3PvwE5GFD4ZW5kc3RyZWFtCmVuZG9iagoxNjggMCBvYmoKODcxCmVuZG9iagox NzIgMCBvYmoKPDwvTGVuZ3RoIDE3MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nIWUXXPaSgyG7/kVGm5OMsd2bPOdyXROAoa6hTQFd9JOk4uNEbCJvSa76yT8+2qNkxA+Ts0wYGst PZJe6RFcxwPXfMrfOK2cjFswVxUXBvSdVx4rXnEAyp84hYuIDrXB8yGaVdbveeDXoNVqQ5RWjkKh UQrUdk+ymYbtK/zWC/r2pBvuWMqrj3fgu17tOLqv1DoQDStHG9azHtMY8RQ/+a7r2W7H9uqR2z71 Oqeu96/rnrru2cnbmeN/Kl5t1wWqWPKl5pn4dJlpPuMxMzegUGjQGb21eR7iTCjNdY4iXtl0o1ms //M6vuM6vuMXATc8fnj77OQzVzqTq1Bjuml6M7w/PDsJRcynxPD6jJ4U1eplcZ6Wzxt+kY9XdwDG OENJVKjI4DdfDR6ZLjOZUlJP+PGQ8fp73O/6nte5BbiQbCpQWjBxLKh+xRU8Z3KqYJZJyBUCF0CH FdUEQjE1ZcK9JQXD8phziQYThviEiapacNG9Aq9uGSdgQlowYjJegNfptJx35hKq1mk3DZSRj1T2 ENGCiMD6HJMpF3PyQ3dMTGHokCPFjdKI+4fgBJweJlNZLmOE0NSWuo0Sbo5+jMOb41MYIMXiMUxW 1NYXQp5EPWg2C+RtHQAYQgu+MJEzuSKVuo3dLBpuy6UsekysEv68Zh4hvzeoX0r+Xw70MI0XKB4y SiBaEFzZ+0NZfLu7x1jDhtIgeIkXTMwR+kWzq+s6m/gWnYsxvUO5mwNR76l9w/dN7S+Z1ChM2QvO zw6cJ0+otKQ7Ah3kxJhwgWuJXEuuqS909BB1eH55Dl2aH3pPFkOmYEJ5GPxSXKVM/GaJTyDWLvWI FfVu75I33XqDyEeZ5AS/suCr0fIYWWJr2gFQ7CObFhJJ+4HqMkNByr45Goe9m+Pqa6P30hvXFo3S U1FKs5XcvfGbW/GL2l04EEmWppgkpsVUQbXMpIZsBm9wB8v2f8ykJqXYHFXZcAPwTrmv4TvYQdg9 H98aY5DLbInMiGmJRDeQWb4smhtGNnUqpxZTTtVzmhx7xJJnJg9SRySUGU+QuKhVta2YoxGtsiJm GAQBhN3JAEqHlJFmU6bZtqThmvI3CiuwrEOBq3/zQ0RbND9HQ88xc2p24Gq9Z8iLGdKA/l6xLOHr eZ1QXaiuc3sUf8/RDEd3PcWHaPoO/KLzyHKqW/BC86T4XYJm9T1QbYfElVP7qJ0EQe0kDvrf5zO9 2G1eMOVmWAqlXte6JJ04I02JaTFMH8S5MxzkXtGOSdkVCdO7JWOzURgj9sAWTC0oQ9TAEge2gr4s aZUrOHD9vjL4tbrxGESV7/T5AxenJjVlbmRzdHJlYW0KZW5kb2JqCjE3MyAwIG9iago5OTMKZW5k b2JqCjE3NyAwIG9iago8PC9MZW5ndGggMTc4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCniclVXRcto6EH3nK3Z4ucmM62I7EJK3xJiEJlAudqZ3JuFBMQKrsSUqyWn993clO9wUcCfX DGNjtHvOnrMr/YCe60HPfJp7WnQ+L85hozo9uMHvpvOj49kF0NzSAq4TXDQEz4dk3anjPPADOD8f QlJ0TiZcU8mp/jSSZK1h/5p8HUXjT3E4Ofinucb0GfyeF5wm3zvBBST3nZPfFySZKLZKcAduXQeu KU0zB0b4OCW54LTCB/xB+ApmLkwpX9FciYw7p391vOBIvu4/03uI04wWBOZEavAuIdayTHUpqYKY pgJzRSummeBdB74FIabaS7LAVUWBYMSscuBrqsUzlVhJ78zF5f7gDfkR4ZRFM2D+so3WNZMm0dy1 pVy5prxMaEmcQ8b+JYyIJrraUnXI7VgF/5PwjBRUtVOVBFVPUPVbkedIl8rakXtSFQSTX+FzIp4Z Pi4ab27dQ6LGWWtst2sBtyRFAxgHU+/TSZIxuSvj6fSjVoxoSoumtIt3pXlnru9iQ/K1kAWufaUY uqaS8nSn4uNiHAZBcLEEuMsrTh24Qf7RqjYldGFGf9oKu6g/tS8TVlAQHHRG2/R6G5FLu1hpgv2M 1SAWGDAHvpR5Zej6e04YNv2+vzRFqlTIHJshqrlcu3An5KtRvntTMmx6xlE8rA2+SVSMb0z+NkYJ /aUNaWyVEldXEAquMIm0Ghpy1+Eczv2GJHKoSR6qj6yDI6wHwyGynlKSI69NPaLdJKMwiZKx9XdB N0xpWTVYQ6/BwsjW0f1CeElkdaxpMbYf+I1UnKUvZpSsdQj8ZgASUopsKIxtCzQemLhWyHdzMjyE HHjeYGkHYsWNFTGioZRS4HzcN51/58K4/M5+EjvKRoPI9QZnoEUb5gNnpkdNJaKUKYq2olyzNaNS 4Vw8LCZPpzCqOClYiu2e04217dCcEcOuwR6pIK6UpgUGj0ajGKOvttucpTYMX0azh6kdMCOHqck5 zDUlMs3MTu3tyRBezaNwWc8zhekkWUSogdwK2QxkN8T5RJwrrUn6gjuYNm5AxMuiabg2IezQ5UQp rH1H1uJZtvtEwmjZtPefiaBDa7Yp69cf4YGgYXQcMo5rzDglci3MjnFXD+jcHEZ53lh+DLkNLcZJ N/O788ygWPTZJE7q3QSbmKcVdghWp+G83/OPWPZuJ/R6+8yjD4oVvWLvQfRri4ejahyI/hOjTjZ/ Szaz0SRHlkozXeImKdZ4vKIiRK5UvWPiCc5FLjbVDqVNinlOtB2FdyZ1zVbE6a4VB30bmJAXkhGV MQdw0Enu/p7JVMDM+d5yPc7NvhD0zaEXJZ2/8fMvwb9iVWVuZHN0cmVhbQplbmRvYmoKMTc4IDAg b2JqCjk5OQplbmRvYmoKMTgyIDAgb2JqCjw8L0xlbmd0aCAxODMgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJyNVe9z2jgQ/e6/YqdfGubAh0kaaD6dz8Cdm18Ue8LNNZ0bYRZbRZZc SU7Lf39rG9oQTKbyMDL2at/bt0/yV+i7HvSrazcnufP7fAipcfrwF/1S56vj1QGwm5Ic/owpaATe AOK106zzYHAOw+EI4tw5C6VFLdH2xpqtLbwc4f14Mu1FQXj0ZjemuIRB3zvvxF+c8/cQ3zhn9PRT 8DD53ATEGcJtGM8nEChdKM0sV7ILbwKV50rCQykkarbkgtstMLmCyfdCmVKj6bx1vPN9xmfj8Yyy P3bedMGlkMHlM9D5tEENAz8KT4HMkWhYLlOYapbjN6U3dc75tEp6CvUIK4oarBmSgnCLQnThmmmU ECVMr5XEbl1PxEzGYK5yJpXZbIkVSXIKpZVwlChd0Y22xmJec42ix06dPbSVTi+y+EUheLJfbhV1 aUXpBPgpymS7S2RaFFz8YtsWyDYSjYGJLHNs3r7Sr0V7vxZ7DX8V7VCJ1wArgY4R74PwpkEcsye+ ggUT1Lyca6zFPGxf/eiWac4gYIYX+Hrr7gtaG2SYbAQ3FuqNxRLLnxBumExLliIxqxhQ6x5QGyoR Bm6/ttxRAzUX1b7yXhbw4N+8LllN43hX+caQgDlKe4r/c5KE0iZfFPizBv2ncF0Yu134WHJJ6BHd /nT/tdvsAN89hfk3E0umVxx1oy3EmGSSrCsgKjDha7qt6oK10mDpfYRJqammY8kCRYJLC35paavV i2ZaWZUoQRVVzB87V1DNP8T33EGb+HdhFDfwRGNWLsWexKjf73kkxxyfeNM9qhYLcuIS9XGelvb9 EwTj5ohq9V+QMS2wsnmW85Vt8eQpIavIOyS+//Jqg5Ca7fpNvpNIhi8Ftiq45mnZOOmZk8doEs2L +ulUaRKXBK0rISM/NVoeZyNxKWw896dxbaUPpdi+lIR6lSlt3oK/WtGBb3B/lsVsgybj1cwyOj/5 Qd13NUMqNpTGcltaBLWmP+uaXEWzFpPOjlLuBDCNs5RQ6d47F71Bz4O7clPy3jW3LGcJIV6rlEnk uxhvdNEbDd+/g1httmr38AMrmDzo6yyj1lzBb6M+XNC3dTCEd6PLwQHnSc64uALbFPaf3Rf2BzG0 bqrcL0UV37+oF/youwtINhDuobbVN5I8Y+DE+DSr9vH55WdKOYmdj3T9D+8YOltlbmRzdHJlYW0K ZW5kb2JqCjE4MyAwIG9iago4ODcKZW5kb2JqCjE4NyAwIG9iago8PC9MZW5ndGggMTg4IDAgUi9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicdZJhb5swEIa/8ytOmrS1GhBjQiD9lBbSNW2T ZYWom6Zpco1D3ICdgKmWfz9D3U3pVlvI6O5899x73gNyPUDdNietrMFdCEVjIfikv8LaW14fAOag FVxkOigCD0O2tp7veYB9CMMIsso6mQnFasGUk9RkreD1mn1OppdOGs/+8Zh1yR4AI88/zR4tfwzZ rXWirTdMKLglIl9zVuanHyzPf3HN6fmaMRtmgmp7ZwkQQnDFSL5vSa1pGkhq/sSMd1kSIW3IvkIY IDw01lV6rv/w6CXrtCK8POvr/vxTd/Jcy6Wy0sF/6bKNrEgDc16WpD6CW6WQsJ2mqLoG5BquZMU0 QA4po23N1cGGxXKZDOL0fTxYxGkyWKVOPL3LDBceBjBv65ocuvYZpPc2XLS8zLkoYOghG+YpvAt9 bOLvSbPRLiWFDUmslQzG0RstLjdSsDP46EEURYAjDCgK0RG+UUH1/blV39+kbRzKauUW8ulIhW+y 3XK4Ibl8IIcO4yjVgtREz6hRXLWKdVKklDNBGXRqZIxuhCxlcTCw0dgbOQFkZKtzVUSPd6sZjHPk Iwd5Y9wnNbZrsiPifyM8dFjOdsIbl/BGOULfcQl1H3cdPQ768K7OpmO2gSkgpfvqVU5/7XjNmrce 7fclKRj44Q+dcppZX/T+DQYC2tZlbmRzdHJlYW0KZW5kb2JqCjE4OCAwIG9iago1MDUKZW5kb2Jq CjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDkg MCBSCi9Gb250IDEwIDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjExIDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL0ZvbnQg MTUgMCBSCj4+Ci9Db250ZW50cyAxMiAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+ Ci9Db250ZW50cyAxNyAwIFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyNCAwIFIKL0ZvbnQgMjUgMCBSCj4+Ci9Db250ZW50 cyAyMiAwIFIKPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0V4dEdTdGF0ZSAyOSAwIFIKL0ZvbnQgMzAgMCBSCj4+Ci9Db250ZW50cyAyNyAwIFIK Pj4KZW5kb2JqCjMxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSAzNCAwIFIKL0ZvbnQgMzUgMCBSCj4+Ci9Db250ZW50cyAzMiAwIFIKPj4KZW5kb2Jq CjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAz OSAwIFIKL0ZvbnQgNDAgMCBSCj4+Ci9Db250ZW50cyAzNyAwIFIKPj4KZW5kb2JqCjQxIDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0NCAwIFIKL0Zv bnQgNDUgMCBSCj4+Ci9Db250ZW50cyA0MiAwIFIKPj4KZW5kb2JqCjQ2IDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0OSAwIFIKL0ZvbnQgNTAgMCBS Cj4+Ci9Db250ZW50cyA0NyAwIFIKPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250 ZW50cyA1MiAwIFIKPj4KZW5kb2JqCjU2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSA1OSAwIFIKL0ZvbnQgNjAgMCBSCj4+Ci9Db250ZW50cyA1NyAw IFIKPj4KZW5kb2JqCjYxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSA2NCAwIFIKL0ZvbnQgNjUgMCBSCj4+Ci9Db250ZW50cyA2MiAwIFIKPj4KZW5k b2JqCjY2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSA2OSAwIFIKL0ZvbnQgNzAgMCBSCj4+Ci9Db250ZW50cyA2NyAwIFIKPj4KZW5kb2JqCjcxIDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3NCAwIFIK L0ZvbnQgNzUgMCBSCj4+Ci9Db250ZW50cyA3MiAwIFIKPj4KZW5kb2JqCjc2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3OSAwIFIKL0ZvbnQgODAg MCBSCj4+Ci9Db250ZW50cyA3NyAwIFIKPj4KZW5kb2JqCjgxIDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA4NCAwIFIKL0ZvbnQgODUgMCBSCj4+Ci9D b250ZW50cyA4MiAwIFIKPj4KZW5kb2JqCjg2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA4OSAwIFIKL0ZvbnQgOTAgMCBSCj4+Ci9Db250ZW50cyA4 NyAwIFIKPj4KZW5kb2JqCjkxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSA5NCAwIFIKL0ZvbnQgOTUgMCBSCj4+Ci9Db250ZW50cyA5MiAwIFIKPj4K ZW5kb2JqCjk2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSA5OSAwIFIKL0ZvbnQgMTAwIDAgUgo+PgovQ29udGVudHMgOTcgMCBSCj4+CmVuZG9iagox MDEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEw NCAwIFIKL0ZvbnQgMTA1IDAgUgo+PgovQ29udGVudHMgMTAyIDAgUgo+PgplbmRvYmoKMTA2IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDkgMCBS Ci9Gb250IDExMCAwIFIKPj4KL0NvbnRlbnRzIDEwNyAwIFIKPj4KZW5kb2JqCjExMSAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE0IDAgUgovRm9u dCAxMTUgMCBSCj4+Ci9Db250ZW50cyAxMTIgMCBSCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExOSAwIFIKL0ZvbnQgMTIw IDAgUgo+PgovQ29udGVudHMgMTE3IDAgUgo+PgplbmRvYmoKMTIxIDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjQgMCBSCi9Gb250IDEyNSAwIFIK Pj4KL0NvbnRlbnRzIDEyMiAwIFIKPj4KZW5kb2JqCjEyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTI5IDAgUgovRm9udCAxMzAgMCBSCj4+Ci9D b250ZW50cyAxMjcgMCBSCj4+CmVuZG9iagoxMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEzNCAwIFIKL0ZvbnQgMTM1IDAgUgo+PgovQ29udGVu dHMgMTMyIDAgUgo+PgplbmRvYmoKMTM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSAxMzkgMCBSCi9Gb250IDE0MCAwIFIKPj4KL0NvbnRlbnRzIDEz NyAwIFIKPj4KZW5kb2JqCjE0MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTQ0IDAgUgovRm9udCAxNDUgMCBSCj4+Ci9Db250ZW50cyAxNDIgMCBS Cj4+CmVuZG9iagoxNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov RXh0R1N0YXRlIDE0OSAwIFIKL0ZvbnQgMTUwIDAgUgo+PgovQ29udGVudHMgMTQ3IDAgUgo+Pgpl bmRvYmoKMTUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSAxNTQgMCBSCi9Gb250IDE1NSAwIFIKPj4KL0NvbnRlbnRzIDE1MiAwIFIKPj4KZW5kb2Jq CjE1NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg MTU5IDAgUgovRm9udCAxNjAgMCBSCj4+Ci9Db250ZW50cyAxNTcgMCBSCj4+CmVuZG9iagoxNjEg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE2NCAw IFIKL0ZvbnQgMTY1IDAgUgo+PgovQ29udGVudHMgMTYyIDAgUgo+PgplbmRvYmoKMTY2IDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9G b250IDE3MCAwIFIKPj4KL0NvbnRlbnRzIDE2NyAwIFIKPj4KZW5kb2JqCjE3MSAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTc0IDAgUgovRm9udCAx NzUgMCBSCj4+Ci9Db250ZW50cyAxNzIgMCBSCj4+CmVuZG9iagoxNzYgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE3OSAwIFIKL0ZvbnQgMTgwIDAg Ugo+PgovQ29udGVudHMgMTc3IDAgUgo+PgplbmRvYmoKMTgxIDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxODQgMCBSCi9Gb250IDE4NSAwIFIKPj4K L0NvbnRlbnRzIDE4MiAwIFIKPj4KZW5kb2JqCjE4NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTg5IDAgUgovRm9udCAxOTAgMCBSCj4+Ci9Db250 ZW50cyAxODcgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjQg MCBSCjExIDAgUgoxNiAwIFIKMjEgMCBSCjI2IDAgUgozMSAwIFIKMzYgMCBSCjQxIDAgUgo0NiAw IFIKNTEgMCBSCjU2IDAgUgo2MSAwIFIKNjYgMCBSCjcxIDAgUgo3NiAwIFIKODEgMCBSCjg2IDAg Ugo5MSAwIFIKOTYgMCBSCjEwMSAwIFIKMTA2IDAgUgoxMTEgMCBSCjExNiAwIFIKMTIxIDAgUgox MjYgMCBSCjEzMSAwIFIKMTM2IDAgUgoxNDEgMCBSCjE0NiAwIFIKMTUxIDAgUgoxNTYgMCBSCjE2 MSAwIFIKMTY2IDAgUgoxNzEgMCBSCjE3NiAwIFIKMTgxIDAgUgoxODYgMCBSCl0gL0NvdW50IDM3 Cj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0 YSAxOTEgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5k b2JqCjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwvUjgKOCAwIFI+Pgpl bmRvYmoKMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTUgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKMTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjAgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjUgMCBvYmoKPDwvUjgK OCAwIFI+PgplbmRvYmoKMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzAgMCBvYmoKPDwv UjgKOCAwIFI+PgplbmRvYmoKMzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzUgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKMzkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDAgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDUg MCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNDkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK NTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKNTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTkgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKNjAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNjQgMCBvYmoKPDwvUjcKNyAwIFI+ PgplbmRvYmoKNjUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNjkgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKNzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNzQgMCBvYmoKPDwvUjcK NyAwIFI+PgplbmRvYmoKNzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNzkgMCBvYmoKPDwv UjcKNyAwIFI+PgplbmRvYmoKODAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKODQgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKODUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKODkgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKOTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKOTQg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKOTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK OTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTAwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjEwNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMDUgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKMTA5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjExMCAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iagoxMTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTE1IDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjExOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMjAgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEy NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMTMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjEzNCAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iagoxMzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTM5IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjE0MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNDQgMCBvYmoKPDwv UjcKNyAwIFI+PgplbmRvYmoKMTQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0OSAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTU0 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agoxNTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTYwIDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjE2NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNjUgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKMTY5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE3MCAwIG9iago8PC9S OAo4IDAgUj4+CmVuZG9iagoxNzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTc1IDAgb2Jq Cjw8L1I4CjggMCBSPj4KZW5kb2JqCjE3OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxODAg MCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTg0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2Jq CjE4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxODkgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKMTkwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFzZUZvbnQv Q291cmllci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTkxIDAgb2JqCjw8L1R5 cGUvTWV0YWRhdGEKL1N1YnR5cGUvWE1ML0xlbmd0aCAxMzU0Pj5zdHJlYW0KPD94cGFja2V0IGJl Z2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmls dGVycyBlc2M9IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4 bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxu czpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5z OmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0nZjNlYmMzMmYtZjlkZi0xMWVkLTAwMDAtMDEwMDhhZTdhNzAnIHhtbG5zOnBkZj0naHR0 cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQg OS4wNCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nZjNlYmMzMmYtZjlkZi0xMWVkLTAw MDAtMDEwMDhhZTdhNzAnIHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+ PHhtcDpNb2RpZnlEYXRlPjIwMTMtMDUtMjFUMDU6MDY6MTcrMDI6MDA8L3htcDpNb2RpZnlEYXRl Pgo8eG1wOkNyZWF0ZURhdGU+MjAxMy0wNS0yMVQwNTowNjoxNyswMjowMDwveG1wOkNyZWF0ZURh dGU+Cjx4bXA6Q3JlYXRvclRvb2w+R05VIEVuc2NyaXB0IDEuNi41LjkwPC94bXA6Q3JlYXRvclRv b2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdmM2ViYzMy Zi1mOWRmLTExZWQtMDAwMC0wMTAwOGFlN2E3MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6ZjNlYmMzMmYtZjlkZi0x MWVkLTAwMDAtMDEwMDhhZTdhNzAyMDEzLTA1LTIxVDA1OjA2OjE3KzAyOjAwJy8+CjxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSdmM2ViYzMyZi1mOWRmLTExZWQtMDAwMC0wMTAwOGFlN2E3MCcg eG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2Fw cGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVm YXVsdCc+RW5zY3JpcHQgT3V0cHV0PC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PC9yZGY6 RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0KZW5kb2JqCjIgMCBvYmoK PDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDQpCi9DcmVhdGlvbkRhdGUoRDoyMDEzMDUy MTA1MDYxNyswMicwMCcpCi9Nb2REYXRlKEQ6MjAxMzA1MjEwNTA2MTcrMDInMDAnKQovVGl0bGUo RW5zY3JpcHQgT3V0cHV0KQovQ3JlYXRvcihHTlUgRW5zY3JpcHQgMS42LjUuOTApPj5lbmRvYmoK eHJlZgowIDE5MgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNDE0NTAgMDAwMDAgbiAKMDAwMDA0 NTMwNyAwMDAwMCBuIAowMDAwMDQxMTIwIDAwMDAwIG4gCjAwMDAwMzUwNTYgMDAwMDAgbiAKMDAw MDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxMTcyIDAwMDAwIG4gCjAwMDAwNDE1MTYgMDAwMDAgbiAK MDAwMDA0MzgxMyAwMDAwMCBuIAowMDAwMDQxNTU3IDAwMDAwIG4gCjAwMDAwNDE1ODYgMDAwMDAg biAKMDAwMDAzNTIxNSAwMDAwMCBuIAowMDAwMDAxMTkyIDAwMDAwIG4gCjAwMDAwMDIzNTcgMDAw MDAgbiAKMDAwMDA0MTYxNiAwMDAwMCBuIAowMDAwMDQxNjQ2IDAwMDAwIG4gCjAwMDAwMzUzNzcg MDAwMDAgbiAKMDAwMDAwMjM3OCAwMDAwMCBuIAowMDAwMDAzNTU5IDAwMDAwIG4gCjAwMDAwNDE2 NzYgMDAwMDAgbiAKMDAwMDA0MTcwNiAwMDAwMCBuIAowMDAwMDM1NTM5IDAwMDAwIG4gCjAwMDAw MDM1ODAgMDAwMDAgbiAKMDAwMDAwNDkxMiAwMDAwMCBuIAowMDAwMDQxNzM2IDAwMDAwIG4gCjAw MDAwNDE3NjYgMDAwMDAgbiAKMDAwMDAzNTcwMSAwMDAwMCBuIAowMDAwMDA0OTMzIDAwMDAwIG4g CjAwMDAwMDYxMDAgMDAwMDAgbiAKMDAwMDA0MTc5NiAwMDAwMCBuIAowMDAwMDQxODI2IDAwMDAw IG4gCjAwMDAwMzU4NjMgMDAwMDAgbiAKMDAwMDAwNjEyMSAwMDAwMCBuIAowMDAwMDA2OTE3IDAw MDAwIG4gCjAwMDAwNDE4NTYgMDAwMDAgbiAKMDAwMDA0MTg4NiAwMDAwMCBuIAowMDAwMDM2MDI1 IDAwMDAwIG4gCjAwMDAwMDY5MzcgMDAwMDAgbiAKMDAwMDAwODA3NSAwMDAwMCBuIAowMDAwMDQx OTE2IDAwMDAwIG4gCjAwMDAwNDE5NDYgMDAwMDAgbiAKMDAwMDAzNjE4NyAwMDAwMCBuIAowMDAw MDA4MDk2IDAwMDAwIG4gCjAwMDAwMDg5MTMgMDAwMDAgbiAKMDAwMDA0MTk3NiAwMDAwMCBuIAow MDAwMDQyMDA2IDAwMDAwIG4gCjAwMDAwMzYzNDkgMDAwMDAgbiAKMDAwMDAwODkzMyAwMDAwMCBu IAowMDAwMDA5ODQ0IDAwMDAwIG4gCjAwMDAwNDIwMzYgMDAwMDAgbiAKMDAwMDA0MjA2NiAwMDAw MCBuIAowMDAwMDM2NTExIDAwMDAwIG4gCjAwMDAwMDk4NjQgMDAwMDAgbiAKMDAwMDAxMDk1NSAw MDAwMCBuIAowMDAwMDQyMDk2IDAwMDAwIG4gCjAwMDAwNDIxMjYgMDAwMDAgbiAKMDAwMDAzNjY3 MyAwMDAwMCBuIAowMDAwMDEwOTc2IDAwMDAwIG4gCjAwMDAwMTE5ODcgMDAwMDAgbiAKMDAwMDA0 MjE1NiAwMDAwMCBuIAowMDAwMDQyMTg2IDAwMDAwIG4gCjAwMDAwMzY4MzUgMDAwMDAgbiAKMDAw MDAxMjAwNyAwMDAwMCBuIAowMDAwMDEyOTE3IDAwMDAwIG4gCjAwMDAwNDIyMTYgMDAwMDAgbiAK MDAwMDA0MjI0NiAwMDAwMCBuIAowMDAwMDM2OTk3IDAwMDAwIG4gCjAwMDAwMTI5MzcgMDAwMDAg biAKMDAwMDAxMzg3MCAwMDAwMCBuIAowMDAwMDQyMjc2IDAwMDAwIG4gCjAwMDAwNDIzMDYgMDAw MDAgbiAKMDAwMDAzNzE1OSAwMDAwMCBuIAowMDAwMDEzODkwIDAwMDAwIG4gCjAwMDAwMTQ5MDcg MDAwMDAgbiAKMDAwMDA0MjMzNiAwMDAwMCBuIAowMDAwMDQyMzY2IDAwMDAwIG4gCjAwMDAwMzcz MjEgMDAwMDAgbiAKMDAwMDAxNDkyNyAwMDAwMCBuIAowMDAwMDE1OTU0IDAwMDAwIG4gCjAwMDAw NDIzOTYgMDAwMDAgbiAKMDAwMDA0MjQyNiAwMDAwMCBuIAowMDAwMDM3NDgzIDAwMDAwIG4gCjAw MDAwMTU5NzQgMDAwMDAgbiAKMDAwMDAxNzE5NSAwMDAwMCBuIAowMDAwMDQyNDU2IDAwMDAwIG4g CjAwMDAwNDI0ODYgMDAwMDAgbiAKMDAwMDAzNzY0NSAwMDAwMCBuIAowMDAwMDE3MjE2IDAwMDAw IG4gCjAwMDAwMTgyOTAgMDAwMDAgbiAKMDAwMDA0MjUxNiAwMDAwMCBuIAowMDAwMDQyNTQ2IDAw MDAwIG4gCjAwMDAwMzc4MDcgMDAwMDAgbiAKMDAwMDAxODMxMSAwMDAwMCBuIAowMDAwMDE5NDg1 IDAwMDAwIG4gCjAwMDAwNDI1NzYgMDAwMDAgbiAKMDAwMDA0MjYwNiAwMDAwMCBuIAowMDAwMDM3 OTY5IDAwMDAwIG4gCjAwMDAwMTk1MDYgMDAwMDAgbiAKMDAwMDAyMDE0MCAwMDAwMCBuIAowMDAw MDQyNjM2IDAwMDAwIG4gCjAwMDAwNDI2NjYgMDAwMDAgbiAKMDAwMDAzODEzMiAwMDAwMCBuIAow MDAwMDIwMTYwIDAwMDAwIG4gCjAwMDAwMjA3NDggMDAwMDAgbiAKMDAwMDA0MjY5NyAwMDAwMCBu IAowMDAwMDQyNzI4IDAwMDAwIG4gCjAwMDAwMzgyOTggMDAwMDAgbiAKMDAwMDAyMDc2OSAwMDAw MCBuIAowMDAwMDIxMzE4IDAwMDAwIG4gCjAwMDAwNDI3NTkgMDAwMDAgbiAKMDAwMDA0Mjc5MCAw MDAwMCBuIAowMDAwMDM4NDY0IDAwMDAwIG4gCjAwMDAwMjEzMzkgMDAwMDAgbiAKMDAwMDAyMTg5 MSAwMDAwMCBuIAowMDAwMDQyODIxIDAwMDAwIG4gCjAwMDAwNDI4NTIgMDAwMDAgbiAKMDAwMDAz ODYzMCAwMDAwMCBuIAowMDAwMDIxOTEyIDAwMDAwIG4gCjAwMDAwMjMwNzUgMDAwMDAgbiAKMDAw MDA0Mjg4MyAwMDAwMCBuIAowMDAwMDQyOTE0IDAwMDAwIG4gCjAwMDAwMzg3OTYgMDAwMDAgbiAK MDAwMDAyMzA5NyAwMDAwMCBuIAowMDAwMDI0MTQxIDAwMDAwIG4gCjAwMDAwNDI5NDUgMDAwMDAg biAKMDAwMDA0Mjk3NiAwMDAwMCBuIAowMDAwMDM4OTYyIDAwMDAwIG4gCjAwMDAwMjQxNjIgMDAw MDAgbiAKMDAwMDAyNTE1OSAwMDAwMCBuIAowMDAwMDQzMDA3IDAwMDAwIG4gCjAwMDAwNDMwMzgg MDAwMDAgbiAKMDAwMDAzOTEyOCAwMDAwMCBuIAowMDAwMDI1MTgwIDAwMDAwIG4gCjAwMDAwMjU4 NTAgMDAwMDAgbiAKMDAwMDA0MzA2OSAwMDAwMCBuIAowMDAwMDQzMTAwIDAwMDAwIG4gCjAwMDAw MzkyOTQgMDAwMDAgbiAKMDAwMDAyNTg3MSAwMDAwMCBuIAowMDAwMDI2NjI5IDAwMDAwIG4gCjAw MDAwNDMxMzEgMDAwMDAgbiAKMDAwMDA0MzE2MiAwMDAwMCBuIAowMDAwMDM5NDYwIDAwMDAwIG4g CjAwMDAwMjY2NTAgMDAwMDAgbiAKMDAwMDAyNzI0MyAwMDAwMCBuIAowMDAwMDQzMTkzIDAwMDAw IG4gCjAwMDAwNDMyMjQgMDAwMDAgbiAKMDAwMDAzOTYyNiAwMDAwMCBuIAowMDAwMDI3MjY0IDAw MDAwIG4gCjAwMDAwMjc4NjUgMDAwMDAgbiAKMDAwMDA0MzI1NSAwMDAwMCBuIAowMDAwMDQzMjg2 IDAwMDAwIG4gCjAwMDAwMzk3OTIgMDAwMDAgbiAKMDAwMDAyNzg4NiAwMDAwMCBuIAowMDAwMDI4 NTIzIDAwMDAwIG4gCjAwMDAwNDMzMTcgMDAwMDAgbiAKMDAwMDA0MzM0OCAwMDAwMCBuIAowMDAw MDM5OTU4IDAwMDAwIG4gCjAwMDAwMjg1NDQgMDAwMDAgbiAKMDAwMDAyOTEyNSAwMDAwMCBuIAow MDAwMDQzMzc5IDAwMDAwIG4gCjAwMDAwNDM0MTAgMDAwMDAgbiAKMDAwMDA0MDEyNCAwMDAwMCBu IAowMDAwMDI5MTQ2IDAwMDAwIG4gCjAwMDAwMzAzMDQgMDAwMDAgbiAKMDAwMDA0MzQ0MSAwMDAw MCBuIAowMDAwMDQzNDcyIDAwMDAwIG4gCjAwMDAwNDAyOTAgMDAwMDAgbiAKMDAwMDAzMDMyNiAw MDAwMCBuIAowMDAwMDMxMjcxIDAwMDAwIG4gCjAwMDAwNDM1MDMgMDAwMDAgbiAKMDAwMDA0MzUz NCAwMDAwMCBuIAowMDAwMDQwNDU2IDAwMDAwIG4gCjAwMDAwMzEyOTIgMDAwMDAgbiAKMDAwMDAz MjM1OSAwMDAwMCBuIAowMDAwMDQzNTY1IDAwMDAwIG4gCjAwMDAwNDM1OTYgMDAwMDAgbiAKMDAw MDA0MDYyMiAwMDAwMCBuIAowMDAwMDMyMzgwIDAwMDAwIG4gCjAwMDAwMzM0NTMgMDAwMDAgbiAK MDAwMDA0MzYyNyAwMDAwMCBuIAowMDAwMDQzNjU4IDAwMDAwIG4gCjAwMDAwNDA3ODggMDAwMDAg biAKMDAwMDAzMzQ3NCAwMDAwMCBuIAowMDAwMDM0NDM1IDAwMDAwIG4gCjAwMDAwNDM2ODkgMDAw MDAgbiAKMDAwMDA0MzcyMCAwMDAwMCBuIAowMDAwMDQwOTU0IDAwMDAwIG4gCjAwMDAwMzQ0NTYg MDAwMDAgbiAKMDAwMDAzNTAzNSAwMDAwMCBuIAowMDAwMDQzNzUxIDAwMDAwIG4gCjAwMDAwNDM3 ODIgMDAwMDAgbiAKMDAwMDA0Mzg3NSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE5MiAvUm9v dCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzwzNzcxNkYxMzBCQ0IwNkI5REQyMUM3MDk4OTM4MjA4 OT48Mzc3MTZGMTMwQkNCMDZCOUREMjFDNzA5ODkzODIwODk+XQo+PgpzdGFydHhyZWYKNDU0ODYK JSVFT0YK ------=_NextPart_000_0030_01CE6393.FBBEC950-- From takeshi_takahashi@nict.go.jp Fri Jun 7 02:20:09 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB521F965B for ; Fri, 7 Jun 2013 02:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrpxS2wDiZ55 for ; Fri, 7 Jun 2013 02:20:03 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE521F9632 for ; Fri, 7 Jun 2013 02:20:02 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r579K0dE021489 for ; Fri, 7 Jun 2013 18:20:00 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r579K0Jw028877 for ; Fri, 7 Jun 2013 18:20:00 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r579K0nl028869 for ; Fri, 7 Jun 2013 18:20:00 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 6F7721680B for ; Fri, 7 Jun 2013 18:20:00 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 6A659166E6 for ; Fri, 7 Jun 2013 18:20:00 +0900 (JST) From: "Takeshi Takahashi" To: References: <002f01ce6348$8bd6ac20$a3840460$@nict.go.jp> In-Reply-To: <002f01ce6348$8bd6ac20$a3840460$@nict.go.jp> Date: Fri, 7 Jun 2013 18:20:00 +0900 Message-ID: <005f01ce6360$2f9d20c0$8ed76240$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxIqVVB0H4jvXYkaje7AisEcourJjkekSw Content-Language: ja Subject: Re: [mile] IODEF-SCI tools available / MTI schema X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 09:20:09 -0000 My sentences were not clear, so let me rewrite the below sentence. > It seems to be a bit difficult to embed the MMDEF itself inside the = draft. It seems to be a bit difficult to copy & paste the MMDEF schema on the IODEF-SCI draft since the MMDEF is an evolving specification and the community is still very active. Kind regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Takeshi Takahashi > Sent: Friday, June 7, 2013 3:31 PM > To: mile@ietf.org > Subject: [mile] IODEF-SCI tools available / MTI schema >=20 > Hello all, >=20 > We created simple tools that can generate, exchange, and parse (and = store > and locate) IODEF-SCI documents. > They are Java-based tools and are available online. >=20 > https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools >=20 > Regarding the MTI schema, I am sorry for not being able to report = anything > back until now. > It seems to be a bit difficult to embed the MMDEF itself inside the = draft. > Thus I would like to propose to embed the attached schema. > The schema is not MMDEF version 1.2, but is generated based on that. > It should be able to suffice the purpose of MTI, I believe. > The draft will clearly state that the MTI schema embedded in the draft = is > generated based on the MMDEF version 1.2 (the draft attached already states > that). >=20 > Take >=20 >=20 >=20 > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Friday, June 7, 2013 8:46 AM > > To: 'Panos Kampanakis (pkampana)'; 'Moriarty, Kathleen'; = 'mile@ietf.org' > > Subject: RE: Request for draft reviews - review of SCI > > > > Hi Panos, > > > > Thank you very much for reviewing the draft again. > > I'll check the XML/schema once again. > > > > Best regards, > > Take > > > > > > > > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > > Sent: Friday, June 7, 2013 2:29 AM > > To: Moriarty, Kathleen; mile@ietf.org; Takeshi Takahashi > > (takeshi_takahashi@nict.go.jp) > > Subject: RE: Request for draft reviews - review of SCI > > > > Hi Take, > > I have reviewed this a few times and=A0 it is ready to go, in my = mind. > > All my concerns have been addressed in previous iterations. > > The only thing I would do is to make sure that the XML in the = appendix > > is syntactically correct. > > Rgs, > > Panos > > > > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Moriarty, Kathleen > > Sent: Friday, May 17, 2013 2:13 PM > > To: mile@ietf.org > > Subject: [mile] Request for draft reviews > > > > Greetings! > > > > We have had a number of documents updated since the last meeting. > > Thank you to all of the editors for making the requested changes!=A0 = The > > current list of drafts up for review (including those that will be a > > part of the WG after the charter update) include: > > > > RFC5070-bis (IODEF Revision): > > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ > > > > Draft on IODEF Guidance: > > (input from experience, real use cases, and draft review will be > > helpful) > > http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ > > > > Structured Cybersecurity Information draft (close to final): > > http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ > > > > IODEF Enumeration Reference Format: > > > http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-fo > > rmat/ > > > > Resource-Oriented Lightweight Indicator Exchange (ROLIE): > > http://datatracker.ietf.org/doc/draft-field-mile-rolie/ > > > > Please take some time to review the drafts and provide feedback to = the > > list.=A0 It would be helpful if we can iterate on most of them prior = to > > the next meeting.=A0 A couple of the drafts are very close to being > > done.=A0 The list of current drafts and published RFCs can be found = at > > the following > > link: > > http://datatracker.ietf.org/wg/mile/ > > > > We will follow up soon on the charter update as well. > > > > Thank you all in advance! > > Kathleen > > > > From david.waltermire@nist.gov Fri Jun 7 07:41:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F121F96EB for ; Fri, 7 Jun 2013 07:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgOkhHHbP7qX for ; Fri, 7 Jun 2013 07:41:00 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 52AB021F9928 for ; Fri, 7 Jun 2013 07:40:54 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Jun 2013 10:40:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 7 Jun 2013 10:40:51 -0400 From: "Waltermire, David A." To: Eric Burger , "mile@ietf.org IETF" Date: Fri, 7 Jun 2013 10:40:50 -0400 Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5hgiV83Xv96/NgRE6mJwUXUiaQ1ACCP9mg Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF27B988@MIVEXAMER1N1.corp.nai.org> <1513DCD0-0332-4FA9-8DC2-7090384D6425@standardstrack.com> In-Reply-To: <1513DCD0-0332-4FA9-8DC2-7090384D6425@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930C048394D5MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:41:08 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C048394D5MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Eric, I couldn't agree more. It hasn't been clear what the requirements are that the WG is trying to address. I think we need this higher-level requirements document to help crystalize what work the work group needs to accomplish for this re-chartering cycle. Absent that, I don't see how we can gauge what enhancements are in scope to make to IODEF and what other protocol modifications/additions are needed. Sincerely, Dave From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, June 04, 2013 8:18 PM To: mile@ietf.org IETF Subject: Re: [mile] re-charter re-boot What is really missing, but I am not sure it belongs as a work group document, is a requirements document for the protocol and markup itself. The only thing I could find was RFC 3067. However, those were requirements for a specific network operator with specific needs. On Jun 4, 2013, at 7:14 PM, kent_landfield@mcafee.com wrote: Hi Panos, I was expecting that to be more of a proper use of the specifications and specification integration document and not an overview of the higher level uses cases of the area these protocols are supporting. If I am wrong then I would love to hear it. If someone has volunteered to be the author for that mile(stone) could they please clarify? If what I am considering is already covered then I am good. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Panos Kampanakis (pkampana)" > Date: Tuesday, June 4, 2013 5:24 PM To: Kent Landfield >, Sean Turner >, "mile@ietf.org" > Subject: RE: [mile] re-charter re-boot The charter looks good to me. Kent, A clarification. Would the doc you are suggesting be different of what Kathleen had in the charter "Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings." Or did you have something similar in mind? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, June 03, 2013 2:10 PM To: turners@ieca.com; mile@ietf.org Subject: Re: [mile] re-charter re-boot I have no problem with the revised charter as is but I think there is something missing. It would be good to have as a milestone a document that described use cases for these protocols. I rather see this separated out since we are in a situation now of addressing the transport (RID) , the data model for exchange (IODEF) and query/reporting capabilities (ROLIE). We need to tie the three together and a document such as this would help lay a foundation for usage in multiple areas. FWIW... Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org" > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in this space right now as you all know. I took Sean's suggested content and updated it to reflect some of the activity and drivers for additional work in MILE. Several people have mentioned an interest in submitting extensions based on their current work, some in virtualized environments, some for indicator specific formats, some industry specific extensions, etc. There is also work developing by other groups who have mentioned that they will transition their work to an international standards body once it is mature, so room has been left in the charter to accommodate that work. The need for guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport option to enable interoperable interfaces between products. The guidance may be use case specific where tighter security is needed (RID +HTTP/TLS with the object level security options enab led) or w here ease of access is the driver (ROLIE) with no client requirements necessary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Sean Turner [turners@ieca.com] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more and there's some repetition that's unneeded. I also think it's a little open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-related work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be clear about that and then list the actual documents we're going to produce that relate to each one. For the list of deliverables it looks like there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_D7A0423E5E193F40BE6E94126930C4930C048394D5MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFu O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVyaWMsPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5JIGNvdWxkbiYjODIxNzt0IGFncmVlIG1vcmUuIEl0IGhhc24mIzgyMTc7 dCBiZWVuIGNsZWFyIHdoYXQgdGhlIHJlcXVpcmVtZW50cyBhcmUgdGhhdCB0aGUgV0cgaXMgdHJ5 aW5nIHRvIGFkZHJlc3MuIEkgdGhpbmsgd2UgbmVlZCB0aGlzIGhpZ2hlci1sZXZlbCByZXF1aXJl bWVudHMgZG9jdW1lbnQgdG8gaGVscCBjcnlzdGFsaXplIHdoYXQgd29yayB0aGUgd29yayBncm91 cCBuZWVkcyB0byBhY2NvbXBsaXNoIGZvciB0aGlzIHJlLWNoYXJ0ZXJpbmcgY3ljbGUuIEFic2Vu dCB0aGF0LCBJIGRvbiYjODIxNzt0IHNlZSBob3cgd2UgY2FuIGdhdWdlIHdoYXQgZW5oYW5jZW1l bnRzIGFyZSBpbiBzY29wZSB0byBtYWtlIHRvIElPREVGIGFuZCB3aGF0IG90aGVyIHByb3RvY29s IG1vZGlmaWNhdGlvbnMvYWRkaXRpb25zIGFyZSBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5T aW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG1pbGUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxm IE9mIDwvYj5FcmljIEJ1cmdlcjxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAwNCwgMjAx MyA4OjE4IFBNPGJyPjxiPlRvOjwvYj4gbWlsZUBpZXRmLm9yZyBJRVRGPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW21pbGVdIHJlLWNoYXJ0ZXIgcmUtYm9vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPldoYXQgaXMgcmVhbGx5IG1pc3NpbmcsIGJ1dCBJIGFtIG5vdCBzdXJlIGl0 IGJlbG9uZ3MgYXMgYSB3b3JrIGdyb3VwIGRvY3VtZW50LCBpcyBhIDxpPnJlcXVpcmVtZW50czwv aT4mbmJzcDtkb2N1bWVudCBmb3IgdGhlIHByb3RvY29sIGFuZCBtYXJrdXAgaXRzZWxmLiBUaGUg b25seSB0aGluZyBJIGNvdWxkIGZpbmQgd2FzIFJGQyAzMDY3LiBIb3dldmVyLCB0aG9zZSB3ZXJl IHJlcXVpcmVtZW50cyBmb3IgYSBzcGVjaWZpYyBuZXR3b3JrIG9wZXJhdG9yIHdpdGggc3BlY2lm aWMgbmVlZHMuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBKdW4gNCwgMjAxMywg YXQgNzoxNCBQTSwgPGEgaHJlZj0ibWFpbHRvOmtlbnRfbGFuZGZpZWxkQG1jYWZlZS5jb20iPmtl bnRfbGFuZGZpZWxkQG1jYWZlZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIFBhbm9zLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkkgd2FzIGV4cGVjdGluZyB0aGF0IHRvIGJlIG1vcmUgb2YgYSBwcm9wZXIg dXNlIG9mIHRoZSBzcGVjaWZpY2F0aW9ucyBhbmQgc3BlY2lmaWNhdGlvbiBpbnRlZ3JhdGlvbiBk b2N1bWVudCBhbmQgbm90IGFuIG92ZXJ2aWV3IG9mIHRoZSBoaWdoZXIgbGV2ZWwgdXNlcyBjYXNl cyBvZiB0aGUgYXJlYSB0aGVzZSBwcm90b2NvbHMgYXJlIHN1cHBvcnRpbmcuICZuYnNwO0lmIEkg YW0gd3JvbmcgdGhlbiBJIHdvdWxkIGxvdmUgdG8gaGVhciBpdC4gJm5ic3A7SWYgc29tZW9uZSBo YXMgdm9sdW50ZWVyZWQgdG8gYmUgdGhlIGF1dGhvciBmb3IgdGhhdCBtaWxlKHN0b25lKSBjb3Vs ZCB0aGV5IHBsZWFzZSBjbGFyaWZ5PyAmbmJzcDtJZiB3aGF0IEkgYW0gY29uc2lkZXJpbmcgaXMg YWxyZWFkeSBjb3ZlcmVkIHRoZW4gSSBhbSBnb29kLiA7LSk8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+S2VudCBMYW5kZmll bGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcxJz48YnI+PGJyPjxzdHJvbmc+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5NY0FmZWUgfCBBbiBJ bnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25nPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1z cGFuPkRpcmVjdDogKzEuOTcyLjk2My43MDk2Jm5ic3A7PC9zcGFuPjxicj48c3BhbiBjbGFzcz1h cHBsZS1zdHlsZS1zcGFuPk1vYmlsZTogKzEuODE3LjYzNy44MDI2PC9zcGFuPjxicj48c3Ryb25n PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+V2ViOiZuYnNw Ozwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxhIGhyZWY9Imh0 dHA6Ly93d3cubWNhZmVlLmNvbS8iPnd3dy5tY2FmZWUuY29tPC9hPjwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZxdW90O1Bh bm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBrYW1w YW5hQGNpc2NvLmNvbSI+cGthbXBhbmFAY2lzY28uY29tPC9hPiZndDs8YnI+PGI+RGF0ZTogPC9i PlR1ZXNkYXksIEp1bmUgNCwgMjAxMyA1OjI0IFBNPGJyPjxiPlRvOiA8L2I+S2VudCBMYW5kZmll bGQgJmx0OzxhIGhyZWY9Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIj5LZW50X0xh bmRmaWVsZEBNY0FmZWUuY29tPC9hPiZndDssIFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWls dG86dHVybmVyc0BpZWNhLmNvbSI+dHVybmVyc0BpZWNhLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPiZndDs8YnI+PGI+ U3ViamVjdDogPC9iPlJFOiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj QjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0 O21hcmdpbi1yaWdodDowaW4nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF Ij48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5UaGUgY2hhcnRlciBsb29rcyBnb29kIHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPktlbnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QSBjbGFyaWZpY2F0aW9uLiBX b3VsZCB0aGUgZG9jIHlvdSBhcmUgc3VnZ2VzdGluZyBiZSBkaWZmZXJlbnQgb2Ygd2hhdCBLYXRo bGVlbiBoYWQgaW4gdGhlIGNoYXJ0ZXIgJiM4MjIwOzwvc3Bhbj5Qcm92aWRlIGd1aWRhbmNlIG9u IHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdXNlIG9mIFJJRCB0cmFuc3BvcnRzPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YmFzZWQgb24gdXNlIGNhc2VzLiZuYnNw OyZuYnNwO1RoZSBndWlkYW5jZSBkb2N1bWVudCB3aWxsIHNob3cgdGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRyYW5zcG9ydCBvcHRpb25zIChSSUQgKyBSSUQgdHJhbnNwb3J0IGFuZCBJT0RFRi9S SUQgKyBST0xJRSkgYW5kIG1heSBpZGVudGlmeSB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCB0cmFu c3BvcnQgYmluZGluZ3MuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mIzgyMjE7IE9yIGRpZCB5b3Ug aGF2ZSBzb21ldGhpbmcgc2ltaWxhciBpbiBtaW5kPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlJncyw8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QYW5vczwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86bWls ZS1ib3VuY2VzQGlldGYub3JnIj5taWxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJt YWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3Jn PC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmllbGRA TWNBZmVlLmNvbSI+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTwvYT48YnI+PGI+U2VudDo8L2I+ IE1vbmRheSwgSnVuZSAwMywgMjAxMyAyOjEwIFBNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+OyA8YSBocmVmPSJtYWls dG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGhhdmUgbm8gcHJvYmxlbSB3 aXRoIHRoZSByZXZpc2VkIGNoYXJ0ZXIgYXMgaXMgYnV0IEkgdGhpbmsgdGhlcmUgaXMgc29tZXRo aW5nIG1pc3NpbmcuICZuYnNwO0l0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhcyBhIG1pbGVzdG9u ZSBhIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVkIHVzZSBjYXNlcyBmb3IgdGhlc2UgcHJvdG9jb2xz LiAmbmJzcDtJIHJhdGhlciBzZWUgdGhpcyBzZXBhcmF0ZWQgb3V0IHNpbmNlIHdlIGFyZSBpbiBh IHNpdHVhdGlvbiBub3cgb2YgYWRkcmVzc2luZyB0aGUgdHJhbnNwb3J0IChSSUQpICwgdGhlIGRh dGEgbW9kZWwgZm9yIGV4Y2hhbmdlIChJT0RFRikgYW5kIHF1ZXJ5L3JlcG9ydGluZyBjYXBhYmls aXRpZXMgKFJPTElFKS4gJm5ic3A7V2UgbmVlZCB0byB0aWUgdGhlIHRocmVlIHRvZ2V0aGVyIGFu ZCBhIGRvY3VtZW50IHN1Y2ggYXMgdGhpcyB3b3VsZCBoZWxwIGxheSBhIGZvdW5kYXRpb24gZm9y IHVzYWdlIGluIG11bHRpcGxlIGFyZWFzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5GV0lXJiM4MjMwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzYwNkE3MSc+S2VudCBMYW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj NjA2QTcxJz48YnI+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5NY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25nPjxi cj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdDogKzEuOTcyLjk2My43MDk2Jm5i c3A7PC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPk1vYmlsZTogKzEuODE3 LjYzNy44MDI2PC9zcGFuPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+V2ViOiZuYnNwOzwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz1h cHBsZS1zdHlsZS1zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNvbS8iPnd3dy5tY2Fm ZWUuY29tPC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5TZWFuIFR1cm5lciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+Jmd0Ozxicj48 Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdW5lIDMsIDIwMTMgMTI6MzAgUE08YnI+PGI+VG86IDwvYj4m cXVvdDs8YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPiZn dDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Db21tZW50cyBm cm9tIGFueWJvZHkgZWxzZT88bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+c3B0PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIDUvMjUvMTMgOToxMSBBTSwgTW9yaWFydHks IEthdGhsZWVuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxibG9ja3F1b3RlIHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSw8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U29y cnkgZm9yIHRoZSBkZWxheSBpbiB1cGRhdGluZyB0aGUgY2hhcnRlci4mbmJzcDsmbmJzcDtUaGVy ZSBpcyBhIGxvdCBvZiBhY3Rpdml0eSBpbiB0aGlzIHNwYWNlIHJpZ2h0IG5vdyBhcyB5b3UgYWxs IGtub3cuJm5ic3A7Jm5ic3A7SSB0b29rIFNlYW4ncyBzdWdnZXN0ZWQgY29udGVudCBhbmQgdXBk YXRlZCBpdCB0byByZWZsZWN0IHNvbWUgb2YgdGhlIGFjdGl2aXR5IGFuZCBkcml2ZXJzIGZvciBh ZGRpdGlvbmFsIHdvcmsgaW4gTUlMRS4mbmJzcDsmbmJzcDtTZXZlcmFsIHBlb3BsZSBoYXZlIG1l bnRpb25lZCBhbiBpbnRlcmVzdCBpbiBzdWJtaXR0aW5nIGV4dGVuc2lvbnMgYmFzZWQgb24gdGhl aXIgY3VycmVudCB3b3JrLCBzb21lIGluIHZpcnR1YWxpemVkIGVudmlyb25tZW50cywgc29tZSBm b3IgaW5kaWNhdG9yIHNwZWNpZmljIGZvcm1hdHMsIHNvbWUgaW5kdXN0cnkgc3BlY2lmaWMgZXh0 ZW5zaW9ucywgZXRjLiZuYnNwOyZuYnNwO1RoZXJlIGlzIGFsc28gd29yayBkZXZlbG9waW5nIGJ5 IG90aGVyIGdyb3VwcyB3aG8gaGF2ZSBtZW50aW9uZWQgdGhhdCB0aGV5IHdpbGwgdHJhbnNpdGlv biB0aGVpciB3b3JrIHRvIGFuIGludGVybmF0aW9uYWwgc3RhbmRhcmRzIGJvZHkgb25jZSBpdCBp cyBtYXR1cmUsIHNvIHJvb20gaGFzIGJlZW4gbGVmdCBpbiB0aGUgY2hhcnRlciB0byBhY2NvbW1v ZGF0ZSB0aGF0IHdvcmsuJm5ic3A7Jm5ic3A7VGhlIG5lZWQgZm9yIGd1aWRhbmNlIG9uIHRoZSB0 cmFuc3BvcnQgb3B0aW9ucyBoYXMgc3VyZmFjZWQgc28gdGhhdCBpbXBsZW1lbnRlcnMgdW5kZXJz dGFuZCB3aGVuIHRoZXkgbWF5IGNob29zZSBhIHNwZWNpZmljIHRyYW5zcG9ydCBvcHRpb24gdG8g ZW5hYmxlIGludGVyb3BlcmFibGUgaW50ZXJmYWNlcyBiZXR3ZWVuIHByb2R1Y3RzLiZuYnNwOyZu YnNwO1RoZSBndWlkYW5jZSBtYXkgYmUgdXNlIGNhc2Ugc3BlY2lmaWMgd2hlcmUgdGlnaHRlciBz ZWN1cml0eSBpcyBuZWVkZWQgKFJJRCArSFRUUC9UTFMgd2l0aCB0aGUgb2JqZWN0IGxldmVsIHNl Y3VyaXR5IG9wdGlvbnMgZW5hYjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmxlZCkgb3IgdzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aGVyZSBlYXNlIG9mIGFjY2Vz cyBpcyB0aGUgZHJpdmVyIChST0xJRSkgd2l0aCBubyBjbGllbnQgcmVxdWlyZW1lbnRzIG5lY2Vz c2FyeSAoY2FuIHVzZSBhIGJyb3dzZXIpLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxibG9j a3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPldlIHdpbGwgZm9sbG93IHVwIHdpdGggdGhlIG1pbGUgc3RvbmVzLCBoZXJlIHRoZSB0aGUg cmUtd3JpdGU6PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPiZsdDtpbnRybyZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIE1hbmFnZWQgSW5jaWRlbnQgTGlnaHR3 ZWlnaHQgRXhjaGFuZ2UgKE1JTEUpIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRldmVsb3BzIHN0YW5kYXJkcyB0byBz dXBwb3J0IGNvbXB1dGVyIGFuZCBuZXR3b3JrIHNlY3VyaXR5PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmNpZGVudCBtYW5hZ2VtZW50OyBh biBpbmNpZGVudCBpcyBhbiB1bnBsYW5uZWQgZXZlbnQgdGhhdDxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+b2NjdXJzIGluIGFuIGluZm9ybWF0 aW9uIHRlY2hub2xvZ3kgKElUKSBpbmZyYXN0cnVjdHVyZS4gQW48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluY2lkZW50IGNvdWxkIGJlIGEg YmVuaWduIGNvbmZpZ3VyYXRpb24gaXNzdWUsIElUIGluY2lkZW50LCBhbjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5mcmFjdGlvbiB0byBh IHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IChTTEEpLCBhIHN5c3RlbTxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29tcHJvbWlzZSwgc29jaWFs bHkgZW5naW5lZXJlZCBwaGlzaGluZyBhdHRhY2ssIG9yIGE8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRlbmlhbC1vZi1zZXJ2aWNlIChEb1Mp IGF0dGFjaywgZXRjLiZuYnNwOyZuYnNwO1doZW4gYW4gaW5jaWRlbnQgaXM8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRldGVjdGVkLCBvciBz dXNwZWN0ZWQsIHRoZXJlIG1heSBiZSBhIG5lZWQgZm9yIG9yZ2FuaXphdGlvbnMgdG88bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNvbGxhYm9y YXRlLiBUaGlzIGNvbGxhYm9yYXRpb24gZWZmb3J0IG1heSB0YWtlIHNldmVyYWwgZm9ybXM8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluY2x1 ZGluZyBqb2ludCBhbmFseXNpcywgaW5mb3JtYXRpb24gZGlzc2VtaW5hdGlvbiwgYW5kL29yIGE8 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNv b3JkaW5hdGVkIG9wZXJhdGlvbmFsIHJlc3BvbnNlLiZuYnNwOyZuYnNwO0V4YW1wbGVzIG9mIHRo ZSByZXNwb25zZSBtYXk8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPmluY2x1ZGUgZmlsaW5nIGEgcmVwb3J0LCBub3RpZnlpbmcgdGhlIHNvdXJj ZSBvZiB0aGUgaW5jaWRlbnQsPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5yZXF1ZXN0aW5nIHRoYXQgYSB0aGlyZCBwYXJ0eSByZXNvbHZlL21p dGlnYXRlIHRoZSBpbmNpZGVudCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPnNoYXJpbmcgc2VsZWN0IGluZGljYXRvcnMgb2YgY29tcHJvbWlz ZSwgb3IgcmVxdWVzdGluZyB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c291cmNlIGJlIGxvY2F0ZWQuIEJ5IHNoYXJpbmcgaW5k aWNhdG9ycyBvZiBjb21wcm9taXNlIGFzc29jaWF0ZWQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPndpdGggYW4gaW5jaWRlbnQgb3IgcG9zc2li bGUgdGhyZWF0LCB0aGUgaW5mb3JtYXRpb24gYmVjb21lcyBhPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5wcm9hY3RpdmUgZGVmZW5zZSBmb3Ig b3RoZXJzIHRoYXQgbWF5IGluY2x1ZGUgbWl0aWdhdGlvbiBvcHRpb25zLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIEluY2lkZW50IE9i amVjdCBEZXNjcmlwdGlvbiBFeGNoYW5nZSBGb3JtYXQgKElPREVGKSBkZWZpbmVzPG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hbiBpbmZvcm1h dGlvbiBmcmFtZXdvcmsgdG8gcmVwcmVzZW50IGNvbXB1dGVyIGFuZCBuZXR3b3JrPG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zZWN1cml0eSBp bmNpZGVudHM7IElPREVGIGlzIGRlZmluZWQgaW4gUkZDIDUwNzAgYW5kPG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5oYXMgYmVlbiBleHRlbmRl ZCBieSBSRkMgNTA5MSB0byBzdXBwb3J0IHBoaXNoaW5nIHJlcG9ydHM7IFJGQzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+NjQ4NCBwcm92aWRl cyBhIHRlbXBsYXRlIGZvciBkZWZpbmluZyBleHRlbnNpb25zIHRvIElPREVGLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UmVhbC10aW1lIElu dGVyLW5ldHdvcmsgRGVmZW5zZSAoUklEKSBkZWZpbmVzIGEgcHJvdG9jb2wgdG88bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmZhY2lsaXRhdGUg c2hhcmluZyBjb21wdXRlciBhbmQgbmV0d29yayBzZWN1cml0eSBpbmNpZGVudHM7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SSUQgaXMgZGVm aW5lZCBpbiBSRkMgNjU0NSwgYW5kIFJJRCBvdmVyIEhUVFBTIGlzIGRlZmluZWQgaW4gUkZDPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD42NTQ2 LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4mbHQ7L2ludHJvJmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgTUlMRSBXRyBpcyBmb2N1c2VkIG9uIHR3byBhcmVh cywgSU9ERUYgdGhlIGRhdGEgZm9ybWF0IGFuZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXh0ZW5zaW9ucyB0byByZXByZXNlbnQgaW5jaWRl bnQgYW5kIGluZGljYXRvciBkYXRhIGFuZCBSSUQsPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGUgcG9saWN5IGFuZCB0cmFuc3BvcnQgZm9y IHN0cnVjdHVyZWQgZGF0YS4mbmJzcDsmbmJzcDtXaXRoIHJlc3BlY3QgdG88bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklPREVGLCB0aGUgd29y a2luZyBncm91cCB3aWxsOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4tIFJldmlzZSB0aGUgSU9ERUYgZG9jdW1lbnQgdG8gaW5jb3Jw b3JhdGUgZW5oYW5jZW1lbnRzIGFuZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXh0ZW5zaW9ucyBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBl cmllbmNlOyB1c2UgYnkgQ29tcHV0ZXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlY3VyaXR5IEluY2lkZW50IFJlc3BvbnNlIFRlYW1zIChD U0lSVHMpIGFuZCBvdGhlcnMgaGFzPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5leHBvc2VkIHRoZSBuZWVkIHRvIGV4dGVuZCBJT0RFRiB0byBz dXBwb3J0IGluZHVzdHJ5IHNwZWNpZmljPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5leHRlbnNpb25zLCB1c2UgY2FzZSBzcGVjaWZpYyBjb250 ZW50LCBhbmQgcmVwcmVzZW50YXRpb25zIHRvPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hc3NvY2lhdGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0 byByZXByZXNlbnRlZCB0aHJlYXRzIChzeXN0ZW0sPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aHJlYXQgYWN0b3JzLCBjYW1wYWlnbnMsIGV0 Yy4pLiZuYnNwOyZuYnNwO1RoZSB2YWx1ZSBvZiBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c2hhcmluZyBoYXMgYmVlbiBk ZW1vbnN0cmF0ZWQgYW5kIGhpZ2hsaWdodGVkIGF0IGFuIGluY3JlYXNpbmc8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnJhdGUgdGhyb3VnaCB0 aGUgc3VjY2VzcyBvZiB0aGUgSW5mb3JtYXRpb24gU2hhcmluZyBhbmQ8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFuYWx5c2lzIENlbnRlcnMg KElTQUNzKSBhbmQgdGhlIHJlY2VudCBjeWJlciBzZWN1cml0eSBFeGVjdXRpdmU8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9yZGVyIGluIHRo ZSBVUy4mbmJzcDsmbmJzcDtJbnRlcm5hdGlvbmFsIGdyb3Vwcywgc3VjaCBhcyB0aGUgTXVsdGlu YXRpb25hbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+QXNzb2NpYXRpb24gZm9yIENvbGxhYm9yYXRpdmUgQ3liZXIgU2l0dWF0aW9uYWwgQXdh cmVuZXNzIChDQ1NBKTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+aGF2ZSBiZWVuIHJ1bm5pbmcgZXhwZXJpbWVudHMgdG8gZGV0ZXJtaW5lIHdo YXQgZGF0YSBpcyB1c2VmdWwgdG88bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmV4Y2hhbmdlIGJldHdlZW4gaW5kdXN0cmllcyBhbmQgbmF0aW9u cyB0byBlZmZlY3RpdmVseSBtaXRpZ2F0ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhyZWF0cy4mbmJzcDsmbmJzcDtUaGUgd29yayBvZiB0 aGVzZSBhbmQgb3RoZXIgZ3JvdXBzIGhhdmUgaWRlbnRpZmllZCBvcjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YXJlIHdvcmtpbmcgdG8gZGV2 ZWxvcCBkYXRhIHJlcHJlc2VudGF0aW9ucyByZWxldmFudCB0byB0aGVpciB1c2U8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNhc2VzIHRoYXQg bWF5IGNvbXBsaW1lbnQvZXh0ZW5kIElPREVGIG9yIGJlIHVzZWZ1bCB0byBleGNoYW5nZTxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dXNpbmcg UklEIGFuZCByZWxhdGVkIHRyYW5zcG9ydCBwcm90b2NvbHMuPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gUHJvdmlkZSBndWlkYW5j ZSBvbiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHVzZSBvZiBJT0RFRiB0byBhaWQ8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmltcGxlbWVudGVy cyBpbiBkZXZlbG9waW5nIGludGVyb3BlcmFibGUgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldpdGggcmVz cGVjdCB0byBSSUQsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGw6PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gRGVmaW5lIGEgcmVzb3Vy Y2Utb3JpZW50ZWQgYXBwcm9hY2ggdG8gY3liZXIgc2VjdXJpdHk8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmluZm9ybWF0aW9uIHNoYXJpbmcg dGhhdCBmb2xsb3dzIHRoZSBSRVNUIGFyY2hpdGVjdHVyYWwgc3R5bGUuPG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGlzIG1lY2hhbmlzbSB3 aWxsIGFsbG93IENTSVJUUyB0byBiZSBtb3JlIGR5bmFtaWMgYW5kIGFnaWxlIGluPG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jb2xsYWJvcmF0 aW5nIHdpdGggYSBicm9hZGVyLCBhbmQgdmFyeWluZyBjb25zdGl0dWVuY3kuPG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gUHJvdmlk ZSBndWlkYW5jZSBvbiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHVzZSBvZiBSSUQgdHJhbnNwb3J0 czxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ YmFzZWQgb24gdXNlIGNhc2VzLiZuYnNwOyZuYnNwO1RoZSBndWlkYW5jZSBkb2N1bWVudCB3aWxs IHNob3cgdGhlIHJlbGF0aW9uc2hpcDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+YmV0d2VlbiB0cmFuc3BvcnQgb3B0aW9ucyAoUklEICsgUklE IHRyYW5zcG9ydCBhbmQgSU9ERUYvUklEICsgUk9MSUUpPG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5hbmQgbWF5IGlkZW50aWZ5IHRoZSBuZWVk IGZvciBhZGRpdGlvbmFsIHRyYW5zcG9ydCBiaW5kaW5ncy48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBSSUQgbWF5IHJlcXVpcmUg bW9kaWZpY2F0aW9ucyB0byBhZGRyZXNzIGRhdGEgcHJvdmVuYW5jZSwgYWRkaXRpb25hbDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+cG9saWN5 IG9wdGlvbnMsIG9yIG90aGVyIGNoYW5nZXMgbm93IHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBvZiBSRkM2NTQ1IGFuZCBSRkM2NTQ2LiZuYnNwOyZu YnNwO1dpdGggdGhlPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5SSUQgaW1wbGVtZW50YXRpb25zIGluIHRoZSBvcGVuIHNvdXJjZSBjb21tdW5p dHksIGluY3JlYXNlZCB1c2UgYW5kPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5leHBlcmltZW50YXRpb24gbWF5IGRlbW9uc3RyYXRlIHRoZSBu ZWVkIGZvciBhIHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbHQ7bWlsZXN0b25lcyZndDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmx0Oy9taWxlc3Rv bmVzJmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkthdGhsZWVuPG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkZyb206IDxhIGhyZWY9Im1haWx0bzptaWxlLWJvdW5jZXNAaWV0 Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBT ZWFuIFR1cm5lciBbPGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVj YS5jb208L2E+XTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+U2VudDogV2VkbmVzZGF5LCBNYXkgMDEsIDIwMTMgOTowNCBQTTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VG86IDxhIGhyZWY9 Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogW21pbGVdIHJl LWNoYXJ0ZXIgcmUtYm9vdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5IaSw8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSdkIGxpa2UgdG8gcHJvcG9zZSBhIHNpZ25pZmlj YW50IHJlLXdyaXRlIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyLiZuYnNwOyZuYnNwO0k8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoaW5rIHRo ZXJlJ3MgdG9vIG11Y2ggaGlzdG9yeSB0aGF0J3Mgbm90IHJlYWxseSBuZWVkZWQgYW55IG1vcmUg YW5kPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD50aGVyZSdzIHNvbWUgcmVwZXRpdGlvbiB0aGF0J3MgdW5uZWVkZWQuJm5ic3A7Jm5ic3A7SSBh bHNvIHRoaW5rIGl0J3MgYSBsaXR0bGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPm9wZW4gZW5kZWQgd3J0IHdoYXQncyBhY3R1YWxseSBnb2lu ZyB0byBnZXQgZG9uZS4gQmFzZWQgb24gcmVjZW50PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5leHBlcmllbmNlLCBJIGhhdmUgYSBzdHJvbmcg ZmVlbGluZyB0aGF0IHRoZSBjdXJyZW50IGNoYXJ0ZXIgd291bGRuJ3Q8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmdldCB0aHJvdWdoIHRoZSBw cm9jZXNzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5JJ20gcHJvcG9zaW5nIGZvdXIgc2VjdGlvbnM6IGludHJvLCBpb2RlZi1yZWxh dGVkIHdvcmssIHJpZC1yZWxhdGVkPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD53b3JrLCBtaWxlc3RvbmVzLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgaW50cm8gc2hvdWxk OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4tIGV4cGxhaW4gd2hhdCB0aGUgV0cgZG9lczogZGV2ZWxvcCBzdGFuZGFyZHMgdG8gZG8g Zm9vLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+LSBzdW1tYXJpemUgd2hhdCBmb28gaXMuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tIGhpZ2hsaWdodCBleGlzdGluZyBSRkNzIHRoYXQg YXJlIHBhcnQgb2YgdGhlIHNwYWNlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElPREVGOiA1MDcw LzUwOTEvNjg0OCAmYW1wOyBSSUQ6IDY1NDUvNjU0Ni48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlbiB3ZSB0YWxrIGFib3V0IHdo YXQgZHJhZnRzIHRoZSBXRyB3aWxsIHByb2R1Y2UgZm9yIHRoZSB0d28gdG9waWMgYXJlYXMuPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkhvdyBhYm91dCB0aGlzIChvciBzb21ldGhpbmcgbGlrZSB0aGlzKTo8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmx0O2ludHJvJmd0 OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5UaGUgTWFuYWdlZCBJbmNpZGVudCBMaWdodHdlaWdodCBFeGNoYW5nZSAoTUlMRSkgd29y a2luZyBncm91cDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+ZGV2ZWxvcHMgc3RhbmRhcmRzIHRvIHN1cHBvcnQgY29tcHV0ZXIgYW5kIG5ldHdv cmsgc2VjdXJpdHk8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPmluY2lkZW50IG1hbmFnZW1lbnQ7IGFuIGluY2lkZW50IGlzIGFuIHVucGxhbm5l ZCBldmVudCB0aGF0PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5vY2N1cnMgaW4gYW4gaW5mb3JtYXRpb24gdGVjaG5vbG9neSAoSVQpIGluZnJh c3RydWN0dXJlLiBBbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+aW5jaWRlbnQgY291bGQgYmUgYSBiZW5pZ24gY29uZmlndXJhdGlvbiBpc3N1 ZSwgSVQgaW5jaWRlbnQsIGFuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5pbmZyYWN0aW9uIHRvIGEgc2VydmljZSBsZXZlbCBhZ3JlZW1lbnQg KFNMQSksIGEgc3lzdGVtPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5jb21wcm9taXNlLCBzb2NpYWxseSBlbmdpbmVlcmVkIHBoaXNoaW5nIGF0 dGFjaywgb3IgYTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+ZGVuaWFsLW9mLXNlcnZpY2UgKERvUykgYXR0YWNrLCBldGMuJm5ic3A7Jm5ic3A7 V2hlbiBhbiBpbmNpZGVudCBpczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+ZGV0ZWN0ZWQsIG9yIHN1c3BlY3RlZCwgdGhlcmUgbWF5IGJlIGEg bmVlZCBmb3Igb3JnYW5pemF0aW9ucyB0bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29sbGFib3JhdGUuIFRoaXMgY29sbGFib3JhdGlvbiBl ZmZvcnQgbWF5IHRha2Ugc2V2ZXJhbCBmb3JtczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5jbHVkaW5nIGpvaW50IGFuYWx5c2lzLCBpbmZv cm1hdGlvbiBkaXNzZW1pbmF0aW9uLCBhbmQvb3IgYTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29vcmRpbmF0ZWQgb3BlcmF0aW9uYWwgcmVz cG9uc2UuJm5ic3A7Jm5ic3A7RXhhbXBsZXMgb2YgdGhlIHJlc3BvbnNlIG1heTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5jbHVkZSBmaWxp bmcgYSByZXBvcnQsIG5vdGlmeWluZyB0aGUgc291cmNlIG9mIHRoZSBpbmNpZGVudCw8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnJlcXVlc3Rp bmcgdGhhdCBhIHRoaXJkIHBhcnR5IHJlc29sdmUvbWl0aWdhdGUgdGhlIGluY2lkZW50LDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c2hhcmlu ZyBpbmRpY2F0b3JzIG9mIGNvbXByb21pc2UsIG9yIHJlcXVlc3RpbmcgdGhhdCB0aGUgc291cmNl PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5i ZSBsb2NhdGVkLiBUaGUgSW5jaWRlbnQgT2JqZWN0IERlc2NyaXB0aW9uIEV4Y2hhbmdlIEZvcm1h dDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ KElPREVGKSBkZWZpbmVzIGFuIGluZm9ybWF0aW9uIGZyYW1ld29yayB0byByZXByZXNlbnQgY29t cHV0ZXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPmFuZCBuZXR3b3JrIHNlY3VyaXR5IGluY2lkZW50czsgSU9ERUYgaXMgZGVmaW5lZCBpbiBS RkMgNTA3MCBhbmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPmhhcyBiZWVuIGV4dGVuZGVkIGJ5IFJGQyA1MDkxIHRvIHN1cHBvcnQgcGhpc2hp bmcgcmVwb3J0czsgUkZDPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD42NDg0IHByb3ZpZGVzIGEgdGVtcGxhdGUgZm9yIGRlZmluaW5nIGV4dGVu c2lvbnMgdG8gSU9ERUYuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5SZWFsLXRpbWUgSW50ZXItbmV0d29yayBEZWZlbnNlIChSSUQpIGRlZmlu ZXMgYSBwcm90b2NvbCB0bzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+ZmFjaWxpdGF0ZSBzaGFyaW5nIGNvbXB1dGVyIGFuZCBuZXR3b3JrIHNl Y3VyaXR5IGluY2lkZW50czs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlJJRCBpcyBkZWZpbmVkIGluIFJGQyA2NTQ1LCBhbmQgUklEIG92ZXIg SFRUUFMgaXMgZGVmaW5lZCBpbiBSRkM8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjY1NDYuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDsvaW50byZndDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyB3b3Jr aW5nIGdyb3VwIGRvZXMgdHdvIHRoaW5ncyBJT0RFRiBhbmQgUklEOyB3ZSBzaG91bGQgYmUgY2xl YXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PmFib3V0IHRoYXQgYW5kIHRoZW4gbGlzdCB0aGUgYWN0dWFsIGRvY3VtZW50cyB3ZSdyZSBnb2lu ZyB0byBwcm9kdWNlPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD50aGF0IHJlbGF0ZSB0byBlYWNoIG9uZS4mbmJzcDsmbmJzcDtGb3IgdGhlIGxp c3Qgb2YgZGVsaXZlcmFibGVzIGl0IGxvb2tzIGxpa2U8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZXJlJ3MgdGhyZWUgNTA3MGJpcywgYSBy ZWZlcmVuY2UvZ3VpZGFuY2UgZHJhZnQsIGFuZCBhPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5yZXNvdXJjZS1vcmllbnRlZCBpbmRpY2F0b3Ig ZXhjaGFuZ2U/PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXJlIHRoZSBHUkMgYW5kIEZvcmVuc2ljIGRyYWZ0 cyBkZWFkLWRlYWQ/Jm5ic3A7Jm5ic3A7SSBhc3N1bWUgdGhleSdkIG5vdCBiZTxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW5jbHVkZWQgaW4g dGhlIG1pbGVzdG9uZSBsaXN0LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JcyB0aGVyZSBnb2luZyB0byBvbmx5IGJlIG9uZSA1MDcw YmlzIGRyYWZ0IG9yIHdpbGwgdGhlcmUgYmUgYSA1MDcwYmlzICs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm90aGVyIG9wdGlvbmFsIGV4dGVu c2lvbiBkcmFmdHM/Jm5ic3A7Jm5ic3A7SSBhc3N1bWUgaXQncyBqdXN0IGEgNTA3MGJpcyBiYXNl ZCBvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+dGhlIG1pbGVzdG9uZXMgYnV0IHRob3VnaHQgSSdkIGFzay48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXJlIHdlIG9ubHkgZXh0 ZW5kaW5nIElPREVGIGJhc2VkIG9uIHVzZSBvciBpcyB0aGVyZSBzb21ldGhpbmcgZWxzZSB3ZTxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bmVl ZCB0byBjb25zaWRlcj88bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+SG93IGFib3V0IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Yg KG5lZWQgc29tZSBoZWxwIGZpbGxpbmcgaW4gdGhlPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ibGFua3MpOjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbHQ7aW9kZWYmZ3Q7PG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PldpdGggcmVzcGVjdCB0byBJT0RFRiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbDo8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBSZXZp c2UgdGhlIElPREVGIGRvY3VtZW50IHRvIGluY29ycG9yYXRlIGVuaGFuY2VtZW50cyBhbmQ8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmV4dGVu c2lvbnMgYmFzZWQgb24gb3BlcmF0aW9uYWwgZXhwZXJpZW5jZTsgdXNlIGJ5IENvbXB1dGVyPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TZWN1 cml0eSBJbmNpZGVudCBSZXNwb25zZSBUZWFtcyAoQ1NJUlRzKSBhbmQgb3RoZXJzIGhhczxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXhwb3Nl ZCB0aGUgbmVlZCB0byBleHRlbmQgSU9ERUYgdG8gc3VwcG9ydCB4LCB5LCB6IChuZWVkIHRvIGhh dmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PnNvbWUgaWRlYSB3aGF0J3MgbWlzc2luZykgYmFzZSBvbiBhLCBiLCBjIChuZWVkIHRvIGtub3cg YSBiaXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPm1vcmUgYWJvdXQgd2h5IHN0dWZmIGlzIG1pc3NpbmcgZGlkIHNvbWV0aGluZyBuZXcgcG9w IHVwPykuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPi0gUHJvdmlkZSBndWlkYW5jZSBvbiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHVz ZSBvZiBJT0RFRiB0byBhaWQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPmltcGxlbWVudGVycyBpbiBkZXZlbG9waW5nIGludGVyb3BlcmFibGUg c3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDsvaW9kZWYmZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZvciBSSUQ6PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFyZSB3ZSBh bHNvIGRvaW5nIGRlZmluaW5nIGd1aWRhbmNlIGZvciBSSUQgYXMgd2VsbCBvciBpcyB0aGF0PG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmNv cnBvcmF0ZWQgaW4gdGhlIElPREVGIGd1aWRhbmNlPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JcyBSSUQgaXRzZWxmIGdvaW5nIHRv IGJlIHVudG91Y2hlZCBhbmQgd2UncmUganVzdCBwcm9kdWNpbmcgYSBuZXc8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90O3RyYW5zcG9y dCZxdW90Oz88bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+SXMgaXQganVzdCBmb3IgaW5kaWNhdG9ycyBvciBpcyBpdCBmb3IgdGhlIHdo b2xlIGluY2lkZW50PyZuYnNwOyZuYnNwO09yIGhhczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7aW5kaWNhdG9ycyZxdW90OyBvdmVy IHRha2VuICZxdW90O2luY2lkZW50JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbHQ7cmlkJmd0OzxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XaXRoIHJlc3Bl Y3QgdG8gUklELCB0aGUgd29ya2luZyBncm91cCB3aWxsOjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9k aXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tIERlZmluZSBhIHJlc291cmNl LW9yaWVudGVkIGFwcHJvYWNoIHRvIGN5YmVyIHNlY3VyaXR5PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbmZvcm1hdGlvbiBzaGFyaW5nIHRo YXQgZm9sbG93cyB0aGUgUkVTVCBhcmNoaXRlY3R1cmFsIHN0eWxlLjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyBtZWNoYW5pc20gd2ls bCBhbGxvdyBDU0lSVFMgdG8gYmUgbW9yZSBkeW5hbWljIGFuZCBhZ2lsZSBpbjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Y29sbGFib3JhdGlu ZyB3aXRoIGEgYnJvYWRlciwgYW5kIHZhcnlpbmcgY29uc3RpdHVlbmN5LjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbHQ7L3JpZCZn dDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jmx0O21pbGVzdG9uZXMmZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZXNlIGxvb2tlZCBmaW5lLCBidXQgSSdkIGxp a2Ugc29tZSBhY3R1YWwgZGF0ZXMgZm9yIHRoZSBUQkRzIDspPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDsvbWlsZXN0b25lcyZn dDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+c3B0PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bWls ZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+bWlsZSBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5taWxlIG1haWxpbmcgbGlzdDxicj48YSBocmVm PSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9k eT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930C048394D5MBCLUSTERxcha_-- From kathleen.moriarty@emc.com Fri Jun 7 07:45:25 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8321F9744 for ; Fri, 7 Jun 2013 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8P67aWRnYBN for ; Fri, 7 Jun 2013 07:45:19 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C008621F96E4 for ; Fri, 7 Jun 2013 07:45:17 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r57EjDAl014445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 10:45:15 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 7 Jun 2013 10:44:58 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r57EivhS016628; Fri, 7 Jun 2013 10:44:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Fri, 7 Jun 2013 10:44:57 -0400 From: "Moriarty, Kathleen" To: "Kent_Landfield@McAfee.com" Date: Fri, 7 Jun 2013 10:44:54 -0400 Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5jjZQk4+YYnqZEQ1SfWE0dhzyZGw== Message-ID: <8BD71AD4-9545-4EE1-8015-79A6957DB5E6@emc.com> References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> <51AE50D9.1090408@ieca.com> <51B0C782.40202@ieca.com> <342874C7-5E2D-4645-BB12-FC1A20F4C0D8@McAfee.com> In-Reply-To: <342874C7-5E2D-4645-BB12-FC1A20F4C0D8@McAfee.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:45:26 -0000 SGksDQoNClRoZSBpbnRlbnQgb2YgdGhlIHRleHQgdGhhdCBQYW5vcyBwb2ludGVkIG91dCB3YXMg dGhlIHNhbWUgYXMgd2hhdCBLZW50IGRlc2NyaWJlZC4gIERvZXMgdGhlIHRleHQgbmVlZCB0byBi ZSBhZGp1c3RlZD8gIEFueSBzdWdnZXN0aW9ucz8NCg0KRllJLSBJIGFtIG9mZiB0aGlzIHdlZWsg YW5kIG1heSBub3QgcmVzcG9uZCB1bnRpbCBNb25kYXkuDQoNClRoYW5rcywNCkthdGhsZWVuDQoN ClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSnVuIDYsIDIwMTMsIGF0IDE6NDAgUE0sICJLZW50 X0xhbmRmaWVsZEBNY0FmZWUuY29tIiA8S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbT4gd3JvdGU6 DQoNCj4gVW5kZXJzdGFuZC4gU291bmRzIGdvb2QgdG8gbWUuDQo+DQo+IEtlbnQgTGFuZGZpZWxk DQo+IE1jQWZlZSBMYWJzDQo+IEtlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20NCj4gKzEuODE3LjYz Ny44MDI2DQo+DQo+IE9uIEp1biA2LCAyMDEzLCBhdCAxMjozMSBQTSwgIlNlYW4gVHVybmVyIiA8 dHVybmVyc0BpZWNhLmNvbT4gd3JvdGU6DQo+DQo+PiBLZW50IGFuZCB0aGlzIGRhd25lZCBvbiBt ZSB0b28gbGFzdCBuaWdodCAuLi4gZG9uJ3QgbGV0IGl0IGJlaW5nIGEgV0cgaXRlbSBzdG9wIHlv dSBvciBhbnlib2R5IHJlYWxseSBmcm9tIHdyaXRpbmcgYW4gaW5kaXZpZHVhbCBkcmFmdCB0aGF0 IGNvdWxkIGJlIGNvbnNpZGVyZWQgZm9yIHdnIGFjY2VwdGFuY2UuDQo+Pg0KPj4gTXkgcGxhbiBp cyB0byBjaXJjbGUgdGhlIHdhZ29ucyBvbiBNb25kYXkgd2l0aCB0aGUgY2hhaXJzIHdpdGggdGhl IHVzZSBjYXNlIGRyYWZ0IGFzIGFuIGl0ZW0gYW5kIHN0YXJ0IHRoZSByZS1jaGFydGVyaW5nIHBy b2Nlc3MuDQo+Pg0KPj4gc3B0DQo+Pg0KPj4gT24gNi80LzEzIDQ6NDAgUE0sIFNlYW4gVHVybmVy IHdyb3RlOg0KPj4+IFdlbGwgdW5sZXNzIEknbSBoZWFyaW5nIGFueSB2aW9sZW50IG9iamVjdGlv bnMgSSB0aGluayBhZGRpbmcgaXQgd291bGQNCj4+PiBtYWtlIHNlbnNlIGFjdHVhbGx5LiAgSXQn cyBhbHNvIGFuIGVhc3kgZm9yIHNvbWVib2R5IHdobyBpcyB1c2luZyB0aGlzDQo+Pj4gdGVjaG5v bG9neSB0byBnZXQgdGhlaXIgZmVldCB3ZXQgaW4gdGhlIFdHLg0KPj4+DQo+Pj4gc3B0DQo+Pj4N Cj4+PiBPbiA2LzQvMTMgMTA6NTkgQU0sIEtlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20gd3JvdGU6 DQo+Pj4+IDotKSBTb21ldGhpbmcgdG9sZCBtZSB5b3Ugd291bGQgYXNrIHRoYXTigKYuICA7LSkN Cj4+Pj4NCj4+Pj4gTGV0IG1lIHNlZSBpZiBJIGNhbiBmaW5kIHNvbWVvbmUgdG8gaGVscCB3aXRo IGl0LiBWb2x1bnRlZXJzPyAgSSBjb3VsZA0KPj4+PiB1c2Ugc29tZSBoZWxwIEkgYW0gc3VyZS4N Cj4+Pj4NCj4+Pj4gKktlbnQgTGFuZGZpZWxkKg0KPj4+Pg0KPj4+PiAqTWNBZmVlIHwgQW4gSW50 ZWwgQ29tcGFueSoNCj4+Pj4gRGlyZWN0OiArMS45NzIuOTYzLjcwOTYNCj4+Pj4gTW9iaWxlOiAr MS44MTcuNjM3LjgwMjYNCj4+Pj4gKldlYjogKnd3dy5tY2FmZWUuY29tIDxodHRwOi8vd3d3Lm1j YWZlZS5jb20vPg0KPj4+Pg0KPj4+PiBGcm9tOiBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNv bSA8bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20+Pg0KPj4+PiBEYXRlOiBUdWVzZGF5LCBKdW5lIDQs IDIwMTMgNzoyOSBBTQ0KPj4+PiBUbzogS2VudCBMYW5kZmllbGQgPEtlbnRfTGFuZGZpZWxkQE1j QWZlZS5jb20NCj4+Pj4gPG1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPj4NCj4+Pj4g Q2M6ICJtaWxlQGlldGYub3JnIDxtYWlsdG86bWlsZUBpZXRmLm9yZz4iIDxtaWxlQGlldGYub3Jn DQo+Pj4+IDxtYWlsdG86bWlsZUBpZXRmLm9yZz4+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbbWlsZV0g cmUtY2hhcnRlciByZS1ib290DQo+Pj4+DQo+Pj4+ICAgSXMgdGhhdCB5b3Ugdm9sdW50ZWVyaW5n IHRvIHdyaXRlIHN1Y2ggYSBkcmFmdCA7KQ0KPj4+Pg0KPj4+PiAgIHNwdA0KPj4+Pg0KPj4+PiAg IE9uIDYvMy8xMyAyOjEwIFBNLCBLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tDQo+Pj4+ICAgPG1h aWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4gICAgICAg SSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgcmV2aXNlZCBjaGFydGVyIGFzIGlzIGJ1dCBJIHRo aW5rDQo+Pj4+ICAgICAgIHRoZXJlIGlzDQo+Pj4+ICAgICAgIHNvbWV0aGluZyBtaXNzaW5nLiAg SXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGFzIGEgbWlsZXN0b25lIGENCj4+Pj4gICAgICAgZG9j dW1lbnQNCj4+Pj4gICAgICAgdGhhdCBkZXNjcmliZWQgdXNlIGNhc2VzIGZvciB0aGVzZSBwcm90 b2NvbHMuICBJIHJhdGhlciBzZWUgdGhpcw0KPj4+PiAgICAgICBzZXBhcmF0ZWQgb3V0IHNpbmNl IHdlIGFyZSBpbiBhIHNpdHVhdGlvbiBub3cgb2YgYWRkcmVzc2luZyB0aGUNCj4+Pj4gICAgICAg dHJhbnNwb3J0IChSSUQpICwgdGhlIGRhdGEgbW9kZWwgZm9yIGV4Y2hhbmdlIChJT0RFRikgYW5k DQo+Pj4+ICAgICAgIHF1ZXJ5L3JlcG9ydGluZyBjYXBhYmlsaXRpZXMgKFJPTElFKS4gIFdlIG5l ZWQgdG8gdGllIHRoZSB0aHJlZQ0KPj4+PiAgICAgICB0b2dldGhlcg0KPj4+PiAgICAgICBhbmQg YSBkb2N1bWVudCBzdWNoIGFzIHRoaXMgd291bGQgaGVscCBsYXkgYSBmb3VuZGF0aW9uIGZvcg0K Pj4+PiB1c2FnZSBpbg0KPj4+PiAgICAgICBtdWx0aXBsZSBhcmVhcy4NCj4+Pj4NCj4+Pj4gICAg ICAgRldJV+KApg0KPj4+Pg0KPj4+PiAgICAgICAqS2VudCBMYW5kZmllbGQqDQo+Pj4+DQo+Pj4+ ICAgICAgICpNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55Kg0KPj4+PiAgICAgICBEaXJlY3Q6ICsx Ljk3Mi45NjMuNzA5Ng0KPj4+PiAgICAgICBNb2JpbGU6ICsxLjgxNy42MzcuODAyNg0KPj4+PiAg ICAgICAqV2ViOiAqd3d3Lm1jYWZlZS5jb20gPGh0dHA6Ly93d3cubWNhZmVlLmNvbS8+DQo+Pj4+ DQo+Pj4+ICAgICAgIEZyb206IFNlYW4gVHVybmVyIDx0dXJuZXJzQGllY2EuY29tIDxtYWlsdG86 dHVybmVyc0BpZWNhLmNvbT4NCj4+Pj4gICAgICAgPG1haWx0bzp0dXJuZXJzQGllY2EuY29tPj4N Cj4+Pj4gICAgICAgRGF0ZTogTW9uZGF5LCBKdW5lIDMsIDIwMTMgMTI6MzAgUE0NCj4+Pj4gICAg ICAgVG86ICJtaWxlQGlldGYub3JnIDxtYWlsdG86bWlsZUBpZXRmLm9yZz4NCj4+Pj4gICAgICAg PG1haWx0bzptaWxlQGlldGYub3JnPiIgPG1pbGVAaWV0Zi5vcmcgPG1haWx0bzptaWxlQGlldGYu b3JnPg0KPj4+PiAgICAgICA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+Pg0KPj4+PiAgICAgICBTdWJq ZWN0OiBSZTogW21pbGVdIHJlLWNoYXJ0ZXIgcmUtYm9vdA0KPj4+Pg0KPj4+PiAgICAgICAgICAg ICBDb21tZW50cyBmcm9tIGFueWJvZHkgZWxzZT8NCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgc3B0 DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgIE9uIDUvMjUvMTMgOToxMSBBTSwgTW9yaWFydHksIEth dGhsZWVuIHdyb3RlOg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgSGksDQo+Pj4+DQo+Pj4+ ICAgICAgICAgICAgICAgICBTb3JyeSBmb3IgdGhlIGRlbGF5IGluIHVwZGF0aW5nIHRoZSBjaGFy dGVyLiAgVGhlcmUgaXMNCj4+Pj4gICAgICAgYSBsb3Qgb2YNCj4+Pj4gICAgICAgICAgICAgICAg IGFjdGl2aXR5IGluIHRoaXMgc3BhY2UgcmlnaHQgbm93IGFzIHlvdSBhbGwga25vdy4gIEkNCj4+ Pj4gICAgICAgdG9vayBTZWFuJ3MNCj4+Pj4gICAgICAgICAgICAgICAgIHN1Z2dlc3RlZCBjb250 ZW50IGFuZCB1cGRhdGVkIGl0IHRvIHJlZmxlY3Qgc29tZSBvZg0KPj4+PiAgICAgICB0aGUgYWN0 aXZpdHkNCj4+Pj4gICAgICAgICAgICAgICAgIGFuZCBkcml2ZXJzIGZvciBhZGRpdGlvbmFsIHdv cmsgaW4gTUlMRS4gIFNldmVyYWwNCj4+Pj4gICAgICAgcGVvcGxlIGhhdmUNCj4+Pj4gICAgICAg ICAgICAgICAgIG1lbnRpb25lZCBhbiBpbnRlcmVzdCBpbiBzdWJtaXR0aW5nIGV4dGVuc2lvbnMg YmFzZWQNCj4+Pj4gICAgICAgb24gdGhlaXINCj4+Pj4gICAgICAgICAgICAgICAgIGN1cnJlbnQg d29yaywgc29tZSBpbiB2aXJ0dWFsaXplZCBlbnZpcm9ubWVudHMsIHNvbWUNCj4+Pj4gZm9yDQo+ Pj4+ICAgICAgICAgICAgICAgICBpbmRpY2F0b3Igc3BlY2lmaWMgZm9ybWF0cywgc29tZSBpbmR1 c3RyeSBzcGVjaWZpYw0KPj4+PiAgICAgICBleHRlbnNpb25zLA0KPj4+PiAgICAgICAgICAgICAg ICAgZXRjLiAgVGhlcmUgaXMgYWxzbyB3b3JrIGRldmVsb3BpbmcgYnkgb3RoZXIgZ3JvdXBzDQo+ Pj4+ICAgICAgIHdobyBoYXZlDQo+Pj4+ICAgICAgICAgICAgICAgICBtZW50aW9uZWQgdGhhdCB0 aGV5IHdpbGwgdHJhbnNpdGlvbiB0aGVpciB3b3JrIHRvIGFuDQo+Pj4+ICAgICAgICAgICAgICAg ICBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkcyBib2R5IG9uY2UgaXQgaXMgbWF0dXJlLCBzbw0KPj4+ PiAgICAgICByb29tIGhhcyBiZWVuDQo+Pj4+ICAgICAgICAgICAgICAgICBsZWZ0IGluIHRoZSBj aGFydGVyIHRvIGFjY29tbW9kYXRlIHRoYXQgd29yay4gIFRoZQ0KPj4+PiAgICAgICBuZWVkIGZv cg0KPj4+PiAgICAgICAgICAgICAgICAgZ3VpZGFuY2Ugb24gdGhlIHRyYW5zcG9ydCBvcHRpb25z IGhhcyBzdXJmYWNlZCBzbyB0aGF0DQo+Pj4+ICAgICAgICAgICAgICAgICBpbXBsZW1lbnRlcnMg dW5kZXJzdGFuZCB3aGVuIHRoZXkgbWF5IGNob29zZSBhIHNwZWNpZmljDQo+Pj4+ICAgICAgICAg ICAgICAgICB0cmFuc3BvcnQgb3B0aW9uIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmxlIGludGVyZmFj ZXMNCj4+Pj4gICAgICAgYmV0d2Vlbg0KPj4+PiAgICAgICAgICAgICAgICAgcHJvZHVjdHMuICBU aGUgZ3VpZGFuY2UgbWF5IGJlIHVzZSBjYXNlIHNwZWNpZmljIHdoZXJlDQo+Pj4+ICAgICAgIHRp Z2h0ZXINCj4+Pj4gICAgICAgICAgICAgICAgIHNlY3VyaXR5IGlzIG5lZWRlZCAoUklEICtIVFRQ L1RMUyB3aXRoIHRoZSBvYmplY3QNCj4+Pj4gICAgICAgbGV2ZWwgc2VjdXJpdHkNCj4+Pj4gICAg ICAgICAgICAgICAgIG9wdGlvbnMgZW5hYg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICBsZWQpIG9y IHcNCj4+Pj4gICAgICAgICAgICAgaGVyZSBlYXNlIG9mIGFjY2VzcyBpcyB0aGUgZHJpdmVyIChS T0xJRSkgd2l0aCBubyBjbGllbnQNCj4+Pj4gICAgICAgICAgICAgcmVxdWlyZW1lbnRzIG5lY2Vz c2FyeSAoY2FuIHVzZSBhIGJyb3dzZXIpLg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAg ICAgV2Ugd2lsbCBmb2xsb3cgdXAgd2l0aCB0aGUgbWlsZSBzdG9uZXMsIGhlcmUgdGhlIHRoZQ0K Pj4+PiAgICAgICByZS13cml0ZToNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIDxpbnRybz4N Cj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIFRoZSBNYW5hZ2VkIEluY2lkZW50IExpZ2h0d2Vp Z2h0IEV4Y2hhbmdlIChNSUxFKQ0KPj4+PiAgICAgICB3b3JraW5nIGdyb3VwDQo+Pj4+ICAgICAg ICAgICAgICAgICBkZXZlbG9wcyBzdGFuZGFyZHMgdG8gc3VwcG9ydCBjb21wdXRlciBhbmQgbmV0 d29yaw0KPj4+PiAgICAgICBzZWN1cml0eQ0KPj4+PiAgICAgICAgICAgICAgICAgaW5jaWRlbnQg bWFuYWdlbWVudDsgYW4gaW5jaWRlbnQgaXMgYW4gdW5wbGFubmVkIGV2ZW50DQo+Pj4+ICAgICAg IHRoYXQNCj4+Pj4gICAgICAgICAgICAgICAgIG9jY3VycyBpbiBhbiBpbmZvcm1hdGlvbiB0ZWNo bm9sb2d5IChJVCkNCj4+Pj4gICAgICAgaW5mcmFzdHJ1Y3R1cmUuIEFuDQo+Pj4+ICAgICAgICAg ICAgICAgICBpbmNpZGVudCBjb3VsZCBiZSBhIGJlbmlnbiBjb25maWd1cmF0aW9uIGlzc3VlLCBJ VA0KPj4+PiAgICAgICBpbmNpZGVudCwgYW4NCj4+Pj4gICAgICAgICAgICAgICAgIGluZnJhY3Rp b24gdG8gYSBzZXJ2aWNlIGxldmVsIGFncmVlbWVudCAoU0xBKSwgYSBzeXN0ZW0NCj4+Pj4gICAg ICAgICAgICAgICAgIGNvbXByb21pc2UsIHNvY2lhbGx5IGVuZ2luZWVyZWQgcGhpc2hpbmcgYXR0 YWNrLCBvciBhDQo+Pj4+ICAgICAgICAgICAgICAgICBkZW5pYWwtb2Ytc2VydmljZSAoRG9TKSBh dHRhY2ssIGV0Yy4gIFdoZW4gYW4NCj4+Pj4gaW5jaWRlbnQgaXMNCj4+Pj4gICAgICAgICAgICAg ICAgIGRldGVjdGVkLCBvciBzdXNwZWN0ZWQsIHRoZXJlIG1heSBiZSBhIG5lZWQgZm9yDQo+Pj4+ ICAgICAgIG9yZ2FuaXphdGlvbnMgdG8NCj4+Pj4gICAgICAgICAgICAgICAgIGNvbGxhYm9yYXRl LiBUaGlzIGNvbGxhYm9yYXRpb24gZWZmb3J0IG1heSB0YWtlDQo+Pj4+ICAgICAgIHNldmVyYWwg Zm9ybXMNCj4+Pj4gICAgICAgICAgICAgICAgIGluY2x1ZGluZyBqb2ludCBhbmFseXNpcywgaW5m b3JtYXRpb24gZGlzc2VtaW5hdGlvbiwNCj4+Pj4gICAgICAgYW5kL29yIGENCj4+Pj4gICAgICAg ICAgICAgICAgIGNvb3JkaW5hdGVkIG9wZXJhdGlvbmFsIHJlc3BvbnNlLiAgRXhhbXBsZXMgb2Yg dGhlDQo+Pj4+ICAgICAgIHJlc3BvbnNlIG1heQ0KPj4+PiAgICAgICAgICAgICAgICAgaW5jbHVk ZSBmaWxpbmcgYSByZXBvcnQsIG5vdGlmeWluZyB0aGUgc291cmNlIG9mIHRoZQ0KPj4+PiAgICAg ICBpbmNpZGVudCwNCj4+Pj4gICAgICAgICAgICAgICAgIHJlcXVlc3RpbmcgdGhhdCBhIHRoaXJk IHBhcnR5IHJlc29sdmUvbWl0aWdhdGUgdGhlDQo+Pj4+ICAgICAgIGluY2lkZW50LA0KPj4+PiAg ICAgICAgICAgICAgICAgc2hhcmluZyBzZWxlY3QgaW5kaWNhdG9ycyBvZiBjb21wcm9taXNlLCBv ciByZXF1ZXN0aW5nDQo+Pj4+ICAgICAgIHRoYXQgdGhlDQo+Pj4+ICAgICAgICAgICAgICAgICBz b3VyY2UgYmUgbG9jYXRlZC4gQnkgc2hhcmluZyBpbmRpY2F0b3JzIG9mIGNvbXByb21pc2UNCj4+ Pj4gICAgICAgYXNzb2NpYXRlZA0KPj4+PiAgICAgICAgICAgICAgICAgd2l0aCBhbiBpbmNpZGVu dCBvciBwb3NzaWJsZSB0aHJlYXQsIHRoZSBpbmZvcm1hdGlvbg0KPj4+PiAgICAgICBiZWNvbWVz IGENCj4+Pj4gICAgICAgICAgICAgICAgIHByb2FjdGl2ZSBkZWZlbnNlIGZvciBvdGhlcnMgdGhh dCBtYXkgaW5jbHVkZQ0KPj4+PiAgICAgICBtaXRpZ2F0aW9uIG9wdGlvbnMuDQo+Pj4+ICAgICAg ICAgICAgICAgICBUaGUgSW5jaWRlbnQgT2JqZWN0IERlc2NyaXB0aW9uIEV4Y2hhbmdlIEZvcm1h dA0KPj4+PiAgICAgICAoSU9ERUYpIGRlZmluZXMNCj4+Pj4gICAgICAgICAgICAgICAgIGFuIGlu Zm9ybWF0aW9uIGZyYW1ld29yayB0byByZXByZXNlbnQgY29tcHV0ZXIgYW5kDQo+Pj4+IG5ldHdv cmsNCj4+Pj4gICAgICAgICAgICAgICAgIHNlY3VyaXR5IGluY2lkZW50czsgSU9ERUYgaXMgZGVm aW5lZCBpbiBSRkMgNTA3MCBhbmQNCj4+Pj4gICAgICAgICAgICAgICAgIGhhcyBiZWVuIGV4dGVu ZGVkIGJ5IFJGQyA1MDkxIHRvIHN1cHBvcnQgcGhpc2hpbmcNCj4+Pj4gICAgICAgcmVwb3J0czsg UkZDDQo+Pj4+ICAgICAgICAgICAgICAgICA2NDg0IHByb3ZpZGVzIGEgdGVtcGxhdGUgZm9yIGRl ZmluaW5nIGV4dGVuc2lvbnMgdG8NCj4+Pj4gSU9ERUYuDQo+Pj4+ICAgICAgICAgICAgICAgICBS ZWFsLXRpbWUgSW50ZXItbmV0d29yayBEZWZlbnNlIChSSUQpIGRlZmluZXMgYQ0KPj4+PiAgICAg ICBwcm90b2NvbCB0bw0KPj4+PiAgICAgICAgICAgICAgICAgZmFjaWxpdGF0ZSBzaGFyaW5nIGNv bXB1dGVyIGFuZCBuZXR3b3JrIHNlY3VyaXR5DQo+Pj4+ICAgICAgIGluY2lkZW50czsNCj4+Pj4g ICAgICAgICAgICAgICAgIFJJRCBpcyBkZWZpbmVkIGluIFJGQyA2NTQ1LCBhbmQgUklEIG92ZXIg SFRUUFMgaXMNCj4+Pj4gICAgICAgZGVmaW5lZCBpbiBSRkMNCj4+Pj4gICAgICAgICAgICAgICAg IDY1NDYuDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICA8L2ludHJvPg0KPj4+Pg0KPj4+PiAg ICAgICAgICAgICAgICAgVGhlIE1JTEUgV0cgaXMgZm9jdXNlZCBvbiB0d28gYXJlYXMsIElPREVG IHRoZSBkYXRhDQo+Pj4+ICAgICAgIGZvcm1hdCBhbmQNCj4+Pj4gICAgICAgICAgICAgICAgIGV4 dGVuc2lvbnMgdG8gcmVwcmVzZW50IGluY2lkZW50IGFuZCBpbmRpY2F0b3IgZGF0YQ0KPj4+PiAg ICAgICBhbmQgUklELA0KPj4+PiAgICAgICAgICAgICAgICAgdGhlIHBvbGljeSBhbmQgdHJhbnNw b3J0IGZvciBzdHJ1Y3R1cmVkIGRhdGEuICBXaXRoDQo+Pj4+ICAgICAgIHJlc3BlY3QgdG8NCj4+ Pj4gICAgICAgICAgICAgICAgIElPREVGLCB0aGUgd29ya2luZyBncm91cCB3aWxsOg0KPj4+Pg0K Pj4+PiAgICAgICAgICAgICAgICAgLSBSZXZpc2UgdGhlIElPREVGIGRvY3VtZW50IHRvIGluY29y cG9yYXRlDQo+Pj4+ICAgICAgIGVuaGFuY2VtZW50cyBhbmQNCj4+Pj4gICAgICAgICAgICAgICAg IGV4dGVuc2lvbnMgYmFzZWQgb24gb3BlcmF0aW9uYWwgZXhwZXJpZW5jZTsgdXNlIGJ5DQo+Pj4+ ICAgICAgIENvbXB1dGVyDQo+Pj4+ICAgICAgICAgICAgICAgICBTZWN1cml0eSBJbmNpZGVudCBS ZXNwb25zZSBUZWFtcyAoQ1NJUlRzKSBhbmQgb3RoZXJzDQo+Pj4+IGhhcw0KPj4+PiAgICAgICAg ICAgICAgICAgZXhwb3NlZCB0aGUgbmVlZCB0byBleHRlbmQgSU9ERUYgdG8gc3VwcG9ydCBpbmR1 c3RyeQ0KPj4+PiAgICAgICBzcGVjaWZpYw0KPj4+PiAgICAgICAgICAgICAgICAgZXh0ZW5zaW9u cywgdXNlIGNhc2Ugc3BlY2lmaWMgY29udGVudCwgYW5kDQo+Pj4+ICAgICAgIHJlcHJlc2VudGF0 aW9ucyB0bw0KPj4+PiAgICAgICAgICAgICAgICAgYXNzb2NpYXRlIGluZm9ybWF0aW9uIHJlbGF0 ZWQgdG8gcmVwcmVzZW50ZWQgdGhyZWF0cw0KPj4+PiAgICAgICAoc3lzdGVtLA0KPj4+PiAgICAg ICAgICAgICAgICAgdGhyZWF0IGFjdG9ycywgY2FtcGFpZ25zLCBldGMuKS4gIFRoZSB2YWx1ZSBv Zg0KPj4+PiBpbmZvcm1hdGlvbg0KPj4+PiAgICAgICAgICAgICAgICAgc2hhcmluZyBoYXMgYmVl biBkZW1vbnN0cmF0ZWQgYW5kIGhpZ2hsaWdodGVkIGF0IGFuDQo+Pj4+ICAgICAgIGluY3JlYXNp bmcNCj4+Pj4gICAgICAgICAgICAgICAgIHJhdGUgdGhyb3VnaCB0aGUgc3VjY2VzcyBvZiB0aGUg SW5mb3JtYXRpb24gU2hhcmluZyBhbmQNCj4+Pj4gICAgICAgICAgICAgICAgIEFuYWx5c2lzIENl bnRlcnMgKElTQUNzKSBhbmQgdGhlIHJlY2VudCBjeWJlciBzZWN1cml0eQ0KPj4+PiAgICAgICBF eGVjdXRpdmUNCj4+Pj4gICAgICAgICAgICAgICAgIE9yZGVyIGluIHRoZSBVUy4gIEludGVybmF0 aW9uYWwgZ3JvdXBzLCBzdWNoIGFzIHRoZQ0KPj4+PiAgICAgICBNdWx0aW5hdGlvbmFsDQo+Pj4+ ICAgICAgICAgICAgICAgICBBc3NvY2lhdGlvbiBmb3IgQ29sbGFib3JhdGl2ZSBDeWJlciBTaXR1 YXRpb25hbA0KPj4+PiAgICAgICBBd2FyZW5lc3MgKENDU0EpDQo+Pj4+ICAgICAgICAgICAgICAg ICBoYXZlIGJlZW4gcnVubmluZyBleHBlcmltZW50cyB0byBkZXRlcm1pbmUgd2hhdCBkYXRhDQo+ Pj4+ICAgICAgIGlzIHVzZWZ1bCB0bw0KPj4+PiAgICAgICAgICAgICAgICAgZXhjaGFuZ2UgYmV0 d2VlbiBpbmR1c3RyaWVzIGFuZCBuYXRpb25zIHRvIGVmZmVjdGl2ZWx5DQo+Pj4+ICAgICAgIG1p dGlnYXRlDQo+Pj4+ICAgICAgICAgICAgICAgICB0aHJlYXRzLiAgVGhlIHdvcmsgb2YgdGhlc2Ug YW5kIG90aGVyIGdyb3VwcyBoYXZlDQo+Pj4+ICAgICAgIGlkZW50aWZpZWQgb3INCj4+Pj4gICAg ICAgICAgICAgICAgIGFyZSB3b3JraW5nIHRvIGRldmVsb3AgZGF0YSByZXByZXNlbnRhdGlvbnMg cmVsZXZhbnQNCj4+Pj4gICAgICAgdG8gdGhlaXIgdXNlDQo+Pj4+ICAgICAgICAgICAgICAgICBj YXNlcyB0aGF0IG1heSBjb21wbGltZW50L2V4dGVuZCBJT0RFRiBvciBiZSB1c2VmdWwgdG8NCj4+ Pj4gICAgICAgZXhjaGFuZ2UNCj4+Pj4gICAgICAgICAgICAgICAgIHVzaW5nIFJJRCBhbmQgcmVs YXRlZCB0cmFuc3BvcnQgcHJvdG9jb2xzLg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgLSBQ cm92aWRlIGd1aWRhbmNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdXNlIG9mDQo+Pj4+ICAg ICAgIElPREVGIHRvIGFpZA0KPj4+PiAgICAgICAgICAgICAgICAgaW1wbGVtZW50ZXJzIGluIGRl dmVsb3BpbmcgaW50ZXJvcGVyYWJsZQ0KPj4+PiBzcGVjaWZpY2F0aW9ucy4NCj4+Pj4NCj4+Pj4g ICAgICAgICAgICAgICAgIFdpdGggcmVzcGVjdCB0byBSSUQsIHRoZSB3b3JraW5nIGdyb3VwIHdp bGw6DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICAtIERlZmluZSBhIHJlc291cmNlLW9yaWVu dGVkIGFwcHJvYWNoIHRvIGN5YmVyIHNlY3VyaXR5DQo+Pj4+ICAgICAgICAgICAgICAgICBpbmZv cm1hdGlvbiBzaGFyaW5nIHRoYXQgZm9sbG93cyB0aGUgUkVTVA0KPj4+PiAgICAgICBhcmNoaXRl Y3R1cmFsIHN0eWxlLg0KPj4+PiAgICAgICAgICAgICAgICAgVGhpcyBtZWNoYW5pc20gd2lsbCBh bGxvdyBDU0lSVFMgdG8gYmUgbW9yZSBkeW5hbWljDQo+Pj4+ICAgICAgIGFuZCBhZ2lsZSBpbg0K Pj4+PiAgICAgICAgICAgICAgICAgY29sbGFib3JhdGluZyB3aXRoIGEgYnJvYWRlciwgYW5kIHZh cnlpbmcgY29uc3RpdHVlbmN5Lg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgLSBQcm92aWRl IGd1aWRhbmNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdXNlIG9mDQo+Pj4+ICAgICAgIFJJ RCB0cmFuc3BvcnRzDQo+Pj4+ICAgICAgICAgICAgICAgICBiYXNlZCBvbiB1c2UgY2FzZXMuICBU aGUgZ3VpZGFuY2UgZG9jdW1lbnQgd2lsbCBzaG93DQo+Pj4+IHRoZQ0KPj4+PiAgICAgICAgICAg ICAgICAgcmVsYXRpb25zaGlwDQo+Pj4+ICAgICAgICAgICAgICAgICBiZXR3ZWVuIHRyYW5zcG9y dCBvcHRpb25zIChSSUQgKyBSSUQgdHJhbnNwb3J0IGFuZA0KPj4+PiAgICAgICBJT0RFRi9SSUQg Kw0KPj4+PiAgICAgICAgICAgICAgICAgUk9MSUUpDQo+Pj4+ICAgICAgICAgICAgICAgICBhbmQg bWF5IGlkZW50aWZ5IHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHRyYW5zcG9ydA0KPj4+PiAgICAg ICBiaW5kaW5ncy4NCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIC0gUklEIG1heSByZXF1aXJl IG1vZGlmaWNhdGlvbnMgdG8gYWRkcmVzcyBkYXRhDQo+Pj4+ICAgICAgIHByb3ZlbmFuY2UsDQo+ Pj4+ICAgICAgICAgICAgICAgICBhZGRpdGlvbmFsDQo+Pj4+ICAgICAgICAgICAgICAgICBwb2xp Y3kgb3B0aW9ucywgb3Igb3RoZXIgY2hhbmdlcyBub3cgdGhhdCB0aGVyZSBhcmUNCj4+Pj4gICAg ICAgbXVsdGlwbGUNCj4+Pj4gICAgICAgICAgICAgICAgIGludGVyb3BlcmFibGUgaW1wbGVtZW50 YXRpb25zIG9mIFJGQzY1NDUgYW5kDQo+Pj4+ICAgICAgIFJGQzY1NDYuICBXaXRoIHRoZQ0KPj4+ PiAgICAgICAgICAgICAgICAgUklEIGltcGxlbWVudGF0aW9ucyBpbiB0aGUgb3BlbiBzb3VyY2Ug Y29tbXVuaXR5LA0KPj4+PiAgICAgICBpbmNyZWFzZWQgdXNlIGFuZA0KPj4+PiAgICAgICAgICAg ICAgICAgZXhwZXJpbWVudGF0aW9uIG1heSBkZW1vbnN0cmF0ZSB0aGUgbmVlZCBmb3IgYQ0KPj4+ PiByZXZpc2lvbi4NCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIDxtaWxlc3RvbmVzPg0KPj4+ Pg0KPj4+PiAgICAgICAgICAgICAgICAgPC9taWxlc3RvbmVzPg0KPj4+Pg0KPj4+Pg0KPj4+PiAg ICAgICAgICAgICAgICAgVGhhbmsgeW91IQ0KPj4+PiAgICAgICAgICAgICAgICAgS2F0aGxlZW4N Cj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gICAgICAgICAgICAgICAgIEZyb206IG1pbGUtYm91bmNlc0BpZXRm Lm9yZw0KPj4+PiAgICAgICA8bWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZz4gPG1haWx0bzpt aWxlLWJvdW5jZXNAaWV0Zi5vcmc+DQo+Pj4+ICAgICAgICAgICAgICAgICBbbWlsZS1ib3VuY2Vz QGlldGYub3JnIDxtYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPg0KPj4+PiAgICAgICA8bWFp bHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPj4+PiAgICAgICAgICAgICAg ICAgT2YgU2VhbiBUdXJuZXIgW3R1cm5lcnNAaWVjYS5jb20NCj4+Pj4gICAgICAgPG1haWx0bzp0 dXJuZXJzQGllY2EuY29tPiA8bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20+XQ0KPj4+PiAgICAgICAg ICAgICAgICAgU2VudDogV2VkbmVzZGF5LCBNYXkgMDEsIDIwMTMgOTowNCBQTQ0KPj4+PiAgICAg ICAgICAgICAgICAgVG86IG1pbGVAaWV0Zi5vcmcgPG1haWx0bzptaWxlQGlldGYub3JnPg0KPj4+ PiAgICAgICA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQo+Pj4+ICAgICAgICAgICAgICAgICBTdWJq ZWN0OiBbbWlsZV0gcmUtY2hhcnRlciByZS1ib290DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAg ICBIaSwNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIEknZCBsaWtlIHRvIHByb3Bvc2UgYSBz aWduaWZpY2FudCByZS13cml0ZSBvZiB0aGUNCj4+Pj4gcHJvcG9zZWQNCj4+Pj4gICAgICAgICAg ICAgICAgIGNoYXJ0ZXIuICBJDQo+Pj4+ICAgICAgICAgICAgICAgICB0aGluayB0aGVyZSdzIHRv byBtdWNoIGhpc3RvcnkgdGhhdCdzIG5vdCByZWFsbHkNCj4+Pj4gICAgICAgbmVlZGVkIGFueSBt b3JlIGFuZA0KPj4+PiAgICAgICAgICAgICAgICAgdGhlcmUncyBzb21lIHJlcGV0aXRpb24gdGhh dCdzIHVubmVlZGVkLiAgSSBhbHNvIHRoaW5rDQo+Pj4+ICAgICAgIGl0J3MgYSBsaXR0bGUNCj4+ Pj4gICAgICAgICAgICAgICAgIG9wZW4gZW5kZWQgd3J0IHdoYXQncyBhY3R1YWxseSBnb2luZyB0 byBnZXQgZG9uZS4NCj4+Pj4gICAgICAgQmFzZWQgb24gcmVjZW50DQo+Pj4+ICAgICAgICAgICAg ICAgICBleHBlcmllbmNlLCBJIGhhdmUgYSBzdHJvbmcgZmVlbGluZyB0aGF0IHRoZSBjdXJyZW50 DQo+Pj4+ICAgICAgIGNoYXJ0ZXINCj4+Pj4gICAgICAgICAgICAgICAgIHdvdWxkbid0DQo+Pj4+ ICAgICAgICAgICAgICAgICBnZXQgdGhyb3VnaCB0aGUgcHJvY2Vzcy4NCj4+Pj4NCj4+Pj4gICAg ICAgICAgICAgICAgIEknbSBwcm9wb3NpbmcgZm91ciBzZWN0aW9uczogaW50cm8sIGlvZGVmLXJl bGF0ZWQNCj4+Pj4gICAgICAgd29yaywgcmlkLXJlbGF0ZWQNCj4+Pj4gICAgICAgICAgICAgICAg IHdvcmssIG1pbGVzdG9uZXMuDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBUaGUgaW50cm8g c2hvdWxkOg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgLSBleHBsYWluIHdoYXQgdGhlIFdH IGRvZXM6IGRldmVsb3Agc3RhbmRhcmRzIHRvIGRvDQo+Pj4+IGZvby4NCj4+Pj4gICAgICAgICAg ICAgICAgIC0gc3VtbWFyaXplIHdoYXQgZm9vIGlzLg0KPj4+PiAgICAgICAgICAgICAgICAgLSBo aWdobGlnaHQgZXhpc3RpbmcgUkZDcyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBzcGFjZToNCj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgIElPREVGOiA1MDcwLzUwOTEvNjg0OCAmIFJJRDogNjU0NS82 NTQ2Lg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgVGhlbiB3ZSB0YWxrIGFib3V0IHdoYXQg ZHJhZnRzIHRoZSBXRyB3aWxsIHByb2R1Y2UgZm9yDQo+Pj4+ICAgICAgIHRoZSB0d28NCj4+Pj4g ICAgICAgICAgICAgICAgIHRvcGljIGFyZWFzLg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAg SG93IGFib3V0IHRoaXMgKG9yIHNvbWV0aGluZyBsaWtlIHRoaXMpOg0KPj4+Pg0KPj4+PiAgICAg ICAgICAgICAgICAgPGludHJvPg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgVGhlIE1hbmFn ZWQgSW5jaWRlbnQgTGlnaHR3ZWlnaHQgRXhjaGFuZ2UgKE1JTEUpDQo+Pj4+ICAgICAgIHdvcmtp bmcgZ3JvdXANCj4+Pj4gICAgICAgICAgICAgICAgIGRldmVsb3BzIHN0YW5kYXJkcyB0byBzdXBw b3J0IGNvbXB1dGVyIGFuZCBuZXR3b3JrDQo+Pj4+ICAgICAgIHNlY3VyaXR5DQo+Pj4+ICAgICAg ICAgICAgICAgICBpbmNpZGVudCBtYW5hZ2VtZW50OyBhbiBpbmNpZGVudCBpcyBhbiB1bnBsYW5u ZWQgZXZlbnQNCj4+Pj4gICAgICAgdGhhdA0KPj4+PiAgICAgICAgICAgICAgICAgb2NjdXJzIGlu IGFuIGluZm9ybWF0aW9uIHRlY2hub2xvZ3kgKElUKQ0KPj4+PiAgICAgICBpbmZyYXN0cnVjdHVy ZS4gQW4NCj4+Pj4gICAgICAgICAgICAgICAgIGluY2lkZW50IGNvdWxkIGJlIGEgYmVuaWduIGNv bmZpZ3VyYXRpb24gaXNzdWUsIElUDQo+Pj4+ICAgICAgIGluY2lkZW50LCBhbg0KPj4+PiAgICAg ICAgICAgICAgICAgaW5mcmFjdGlvbiB0byBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IChTTEEp LCBhIHN5c3RlbQ0KPj4+PiAgICAgICAgICAgICAgICAgY29tcHJvbWlzZSwgc29jaWFsbHkgZW5n aW5lZXJlZCBwaGlzaGluZyBhdHRhY2ssIG9yIGENCj4+Pj4gICAgICAgICAgICAgICAgIGRlbmlh bC1vZi1zZXJ2aWNlIChEb1MpIGF0dGFjaywgZXRjLiAgV2hlbiBhbg0KPj4+PiBpbmNpZGVudCBp cw0KPj4+PiAgICAgICAgICAgICAgICAgZGV0ZWN0ZWQsIG9yIHN1c3BlY3RlZCwgdGhlcmUgbWF5 IGJlIGEgbmVlZCBmb3INCj4+Pj4gICAgICAgb3JnYW5pemF0aW9ucyB0bw0KPj4+PiAgICAgICAg ICAgICAgICAgY29sbGFib3JhdGUuIFRoaXMgY29sbGFib3JhdGlvbiBlZmZvcnQgbWF5IHRha2UN Cj4+Pj4gICAgICAgc2V2ZXJhbCBmb3Jtcw0KPj4+PiAgICAgICAgICAgICAgICAgaW5jbHVkaW5n IGpvaW50IGFuYWx5c2lzLCBpbmZvcm1hdGlvbiBkaXNzZW1pbmF0aW9uLA0KPj4+PiAgICAgICBh bmQvb3IgYQ0KPj4+PiAgICAgICAgICAgICAgICAgY29vcmRpbmF0ZWQgb3BlcmF0aW9uYWwgcmVz cG9uc2UuICBFeGFtcGxlcyBvZiB0aGUNCj4+Pj4gICAgICAgcmVzcG9uc2UgbWF5DQo+Pj4+ICAg ICAgICAgICAgICAgICBpbmNsdWRlIGZpbGluZyBhIHJlcG9ydCwgbm90aWZ5aW5nIHRoZSBzb3Vy Y2Ugb2YgdGhlDQo+Pj4+ICAgICAgIGluY2lkZW50LA0KPj4+PiAgICAgICAgICAgICAgICAgcmVx dWVzdGluZyB0aGF0IGEgdGhpcmQgcGFydHkgcmVzb2x2ZS9taXRpZ2F0ZSB0aGUNCj4+Pj4gICAg ICAgaW5jaWRlbnQsDQo+Pj4+ICAgICAgICAgICAgICAgICBzaGFyaW5nIGluZGljYXRvcnMgb2Yg Y29tcHJvbWlzZSwgb3IgcmVxdWVzdGluZyB0aGF0DQo+Pj4+ICAgICAgIHRoZSBzb3VyY2UNCj4+ Pj4gICAgICAgICAgICAgICAgIGJlIGxvY2F0ZWQuIFRoZSBJbmNpZGVudCBPYmplY3QgRGVzY3Jp cHRpb24gRXhjaGFuZ2UNCj4+Pj4gICAgICAgRm9ybWF0DQo+Pj4+ICAgICAgICAgICAgICAgICAo SU9ERUYpIGRlZmluZXMgYW4gaW5mb3JtYXRpb24gZnJhbWV3b3JrIHRvIHJlcHJlc2VudA0KPj4+ PiAgICAgICBjb21wdXRlcg0KPj4+PiAgICAgICAgICAgICAgICAgYW5kIG5ldHdvcmsgc2VjdXJp dHkgaW5jaWRlbnRzOyBJT0RFRiBpcyBkZWZpbmVkIGluDQo+Pj4+ICAgICAgIFJGQyA1MDcwIGFu ZA0KPj4+PiAgICAgICAgICAgICAgICAgaGFzIGJlZW4gZXh0ZW5kZWQgYnkgUkZDIDUwOTEgdG8g c3VwcG9ydCBwaGlzaGluZw0KPj4+PiAgICAgICByZXBvcnRzOyBSRkMNCj4+Pj4gICAgICAgICAg ICAgICAgIDY0ODQgcHJvdmlkZXMgYSB0ZW1wbGF0ZSBmb3IgZGVmaW5pbmcgZXh0ZW5zaW9ucyB0 bw0KPj4+PiBJT0RFRi4NCj4+Pj4gICAgICAgICAgICAgICAgIFJlYWwtdGltZSBJbnRlci1uZXR3 b3JrIERlZmVuc2UgKFJJRCkgZGVmaW5lcyBhDQo+Pj4+ICAgICAgIHByb3RvY29sIHRvDQo+Pj4+ ICAgICAgICAgICAgICAgICBmYWNpbGl0YXRlIHNoYXJpbmcgY29tcHV0ZXIgYW5kIG5ldHdvcmsg c2VjdXJpdHkNCj4+Pj4gICAgICAgaW5jaWRlbnRzOw0KPj4+PiAgICAgICAgICAgICAgICAgUklE IGlzIGRlZmluZWQgaW4gUkZDIDY1NDUsIGFuZCBSSUQgb3ZlciBIVFRQUyBpcw0KPj4+PiAgICAg ICBkZWZpbmVkIGluIFJGQw0KPj4+PiAgICAgICAgICAgICAgICAgNjU0Ni4NCj4+Pj4NCj4+Pj4g ICAgICAgICAgICAgICAgIDwvaW50bz4NCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIFRoaXMg d29ya2luZyBncm91cCBkb2VzIHR3byB0aGluZ3MgSU9ERUYgYW5kIFJJRDsgd2UNCj4+Pj4gICAg ICAgc2hvdWxkIGJlIGNsZWFyDQo+Pj4+ICAgICAgICAgICAgICAgICBhYm91dCB0aGF0IGFuZCB0 aGVuIGxpc3QgdGhlIGFjdHVhbCBkb2N1bWVudHMgd2UncmUNCj4+Pj4gICAgICAgZ29pbmcgdG8g cHJvZHVjZQ0KPj4+PiAgICAgICAgICAgICAgICAgdGhhdCByZWxhdGUgdG8gZWFjaCBvbmUuICBG b3IgdGhlIGxpc3Qgb2YgZGVsaXZlcmFibGVzDQo+Pj4+ICAgICAgIGl0IGxvb2tzIGxpa2UNCj4+ Pj4gICAgICAgICAgICAgICAgIHRoZXJlJ3MgdGhyZWUgNTA3MGJpcywgYSByZWZlcmVuY2UvZ3Vp ZGFuY2UgZHJhZnQsDQo+Pj4+IGFuZCBhDQo+Pj4+ICAgICAgICAgICAgICAgICByZXNvdXJjZS1v cmllbnRlZCBpbmRpY2F0b3IgZXhjaGFuZ2U/DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBR dWVzdGlvbnM6DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBBcmUgdGhlIEdSQyBhbmQgRm9y ZW5zaWMgZHJhZnRzIGRlYWQtZGVhZD8gIEkgYXNzdW1lDQo+Pj4+ICAgICAgIHRoZXknZCBub3Qg YmUNCj4+Pj4gICAgICAgICAgICAgICAgIGluY2x1ZGVkIGluIHRoZSBtaWxlc3RvbmUgbGlzdC4N Cj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIElzIHRoZXJlIGdvaW5nIHRvIG9ubHkgYmUgb25l IDUwNzBiaXMgZHJhZnQgb3Igd2lsbA0KPj4+PiAgICAgICB0aGVyZSBiZSBhDQo+Pj4+ICAgICAg ICAgICAgICAgICA1MDcwYmlzICsNCj4+Pj4gICAgICAgICAgICAgICAgIG90aGVyIG9wdGlvbmFs IGV4dGVuc2lvbiBkcmFmdHM/ICBJIGFzc3VtZSBpdCdzIGp1c3QgYQ0KPj4+PiAgICAgICA1MDcw YmlzDQo+Pj4+ICAgICAgICAgICAgICAgICBiYXNlZCBvbg0KPj4+PiAgICAgICAgICAgICAgICAg dGhlIG1pbGVzdG9uZXMgYnV0IHRob3VnaHQgSSdkIGFzay4NCj4+Pj4NCj4+Pj4gICAgICAgICAg ICAgICAgIEFyZSB3ZSBvbmx5IGV4dGVuZGluZyBJT0RFRiBiYXNlZCBvbiB1c2Ugb3IgaXMgdGhl cmUNCj4+Pj4gICAgICAgc29tZXRoaW5nDQo+Pj4+ICAgICAgICAgICAgICAgICBlbHNlIHdlDQo+ Pj4+ICAgICAgICAgICAgICAgICBuZWVkIHRvIGNvbnNpZGVyPw0KPj4+Pg0KPj4+PiAgICAgICAg ICAgICAgICAgSG93IGFib3V0IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgKG5lZWQgc29t ZSBoZWxwDQo+Pj4+ICAgICAgIGZpbGxpbmcNCj4+Pj4gICAgICAgICAgICAgICAgIGluIHRoZQ0K Pj4+PiAgICAgICAgICAgICAgICAgYmxhbmtzKToNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAg IDxpb2RlZj4NCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIFdpdGggcmVzcGVjdCB0byBJT0RF RiwgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbDoNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIC0g UmV2aXNlIHRoZSBJT0RFRiBkb2N1bWVudCB0byBpbmNvcnBvcmF0ZQ0KPj4+PiAgICAgICBlbmhh bmNlbWVudHMgYW5kDQo+Pj4+ICAgICAgICAgICAgICAgICBleHRlbnNpb25zIGJhc2VkIG9uIG9w ZXJhdGlvbmFsIGV4cGVyaWVuY2U7IHVzZSBieQ0KPj4+PiAgICAgICBDb21wdXRlcg0KPj4+PiAg ICAgICAgICAgICAgICAgU2VjdXJpdHkgSW5jaWRlbnQgUmVzcG9uc2UgVGVhbXMgKENTSVJUcykg YW5kIG90aGVycw0KPj4+PiBoYXMNCj4+Pj4gICAgICAgICAgICAgICAgIGV4cG9zZWQgdGhlIG5l ZWQgdG8gZXh0ZW5kIElPREVGIHRvIHN1cHBvcnQgeCwgeSwgeg0KPj4+PiAgICAgICAobmVlZCB0 byBoYXZlDQo+Pj4+ICAgICAgICAgICAgICAgICBzb21lIGlkZWEgd2hhdCdzIG1pc3NpbmcpIGJh c2Ugb24gYSwgYiwgYyAobmVlZCB0bw0KPj4+PiAgICAgICBrbm93IGEgYml0DQo+Pj4+ICAgICAg ICAgICAgICAgICBtb3JlIGFib3V0IHdoeSBzdHVmZiBpcyBtaXNzaW5nIGRpZCBzb21ldGhpbmcg bmV3IHBvcA0KPj4+PiAgICAgICB1cD8pLg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgLSBQ cm92aWRlIGd1aWRhbmNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdXNlIG9mDQo+Pj4+ICAg ICAgIElPREVGIHRvIGFpZA0KPj4+PiAgICAgICAgICAgICAgICAgaW1wbGVtZW50ZXJzIGluIGRl dmVsb3BpbmcgaW50ZXJvcGVyYWJsZQ0KPj4+PiBzcGVjaWZpY2F0aW9ucy4NCj4+Pj4NCj4+Pj4g ICAgICAgICAgICAgICAgIDwvaW9kZWY+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBGb3Ig UklEOg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgQXJlIHdlIGFsc28gZG9pbmcgZGVmaW5p bmcgZ3VpZGFuY2UgZm9yIFJJRCBhcyB3ZWxsIG9yDQo+Pj4+ICAgICAgIGlzIHRoYXQNCj4+Pj4g ICAgICAgICAgICAgICAgIGluY29ycG9yYXRlZCBpbiB0aGUgSU9ERUYgZ3VpZGFuY2U/DQo+Pj4+ DQo+Pj4+ICAgICAgICAgICAgICAgICBJcyBSSUQgaXRzZWxmIGdvaW5nIHRvIGJlIHVudG91Y2hl ZCBhbmQgd2UncmUganVzdA0KPj4+PiAgICAgICBwcm9kdWNpbmcgYSBuZXcNCj4+Pj4gICAgICAg ICAgICAgICAgICJ0cmFuc3BvcnQiPw0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgSXMgaXQg anVzdCBmb3IgaW5kaWNhdG9ycyBvciBpcyBpdCBmb3IgdGhlIHdob2xlDQo+Pj4+ICAgICAgIGlu Y2lkZW50PyAgT3IgaGFzDQo+Pj4+ICAgICAgICAgICAgICAgICAiaW5kaWNhdG9ycyIgb3ZlciB0 YWtlbiAiaW5jaWRlbnQiPw0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgPHJpZD4NCj4+Pj4N Cj4+Pj4gICAgICAgICAgICAgICAgIFdpdGggcmVzcGVjdCB0byBSSUQsIHRoZSB3b3JraW5nIGdy b3VwIHdpbGw6DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICAtIERlZmluZSBhIHJlc291cmNl LW9yaWVudGVkIGFwcHJvYWNoIHRvIGN5YmVyIHNlY3VyaXR5DQo+Pj4+ICAgICAgICAgICAgICAg ICBpbmZvcm1hdGlvbiBzaGFyaW5nIHRoYXQgZm9sbG93cyB0aGUgUkVTVA0KPj4+PiAgICAgICBh cmNoaXRlY3R1cmFsIHN0eWxlLg0KPj4+PiAgICAgICAgICAgICAgICAgVGhpcyBtZWNoYW5pc20g d2lsbCBhbGxvdyBDU0lSVFMgdG8gYmUgbW9yZSBkeW5hbWljDQo+Pj4+ICAgICAgIGFuZCBhZ2ls ZSBpbg0KPj4+PiAgICAgICAgICAgICAgICAgY29sbGFib3JhdGluZyB3aXRoIGEgYnJvYWRlciwg YW5kIHZhcnlpbmcgY29uc3RpdHVlbmN5Lg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgPC9y aWQ+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICA8bWlsZXN0b25lcz4NCj4+Pj4NCj4+Pj4g ICAgICAgICAgICAgICAgIFRoZXNlIGxvb2tlZCBmaW5lLCBidXQgSSdkIGxpa2Ugc29tZSBhY3R1 YWwgZGF0ZXMgZm9yDQo+Pj4+ICAgICAgIHRoZSBUQkRzIDspDQo+Pj4+DQo+Pj4+ICAgICAgICAg ICAgICAgICA8L21pbGVzdG9uZXM+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBzcHQNCj4+ Pj4gICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+ICAgICAgICAgICAgICAgICBtaWxlIG1haWxpbmcgbGlzdA0KPj4+PiAg ICAgICBtaWxlQGlldGYub3JnIDxtYWlsdG86bWlsZUBpZXRmLm9yZz4gPG1haWx0bzptaWxlQGll dGYub3JnPg0KPj4+PiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pbGUNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gICAgICAgICAgICAgbWlsZSBtYWlsaW5nIGxpc3QN Cj4+Pj4gICAgICAgbWlsZUBpZXRmLm9yZyA8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+IDxtYWlsdG86 bWlsZUBpZXRmLm9yZz4NCj4+Pj4gICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taWxlDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBtaWxlIG1haWxpbmcgbGlzdA0KPj4+IG1pbGVAaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWlsZSBtYWlsaW5nIGxpc3QN Cj4gbWlsZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pbGUNCg== From Kent_Landfield@mcafee.com Fri Jun 7 11:08:24 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5221F9690 for ; Fri, 7 Jun 2013 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuPdw14Alp1A for ; Fri, 7 Jun 2013 11:08:18 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBE21F8FCB for ; Fri, 7 Jun 2013 11:08:14 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 504d_f18d_10e4eadc_a438_4367_873e_75c3f1f08c91; Fri, 07 Jun 2013 13:08:12 -0500 Received: from MIVEXAPP2N2.corp.nai.org (10.48.48.72) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 7 Jun 2013 14:07:43 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAPP2N2.corp.nai.org ([169.254.3.200]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 14:07:43 -0400 From: To: Thread-Topic: [mile] re-charter re-boot Thread-Index: Ac5G0bzmoF5GzR1lQvyX/lnNGrB0XwSdmgtoAdZa/wD//7c4gIABhycA///V4wCAALNLgIAC784AgAABOwCAAWJ7AP//5NaA Date: Fri, 7 Jun 2013 18:07:42 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF28A3A3@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <8BD71AD4-9545-4EE1-8015-79A6957DB5E6@emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF28A3A3MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: mile@ietf.org Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:08:24 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF28A3A3MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The revised draft charter states * Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. I was looking at an overview document that described an architectural view = of the problem and how MILE protocols could be integrated to support the va= rious community uses. In retrospect, if this is what you envisioned, we cou= ld incorporate this into the document. Guidance of implementation targeted= at RID does not sound like what I was thinking about. I volunteer to be a= part of the document's development if it makes sense to incorporate the la= rger perspective. If not, we can make it a separate document. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kathleen Moriarty > Date: Friday, June 7, 2013 9:44 AM To: Kent Landfield > Cc: Sean Turner >, "mile@ietf.org= " > Subject: Re: [mile] re-charter re-boot Hi, The intent of the text that Panos pointed out was the same as what Kent des= cribed. Does the text need to be adjusted? Any suggestions? FYI- I am off this week and may not respond until Monday. Thanks, Kathleen Sent from my iPhone On Jun 6, 2013, at 1:40 PM, "Kent_Landfield@McAfee.com" = > wrote: Understand. Sounds good to me. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026 On Jun 6, 2013, at 12:31 PM, "Sean Turner" > wrote: Kent and this dawned on me too last night ... don't let it being a WG item = stop you or anybody really from writing an individual draft that could be c= onsidered for wg acceptance. My plan is to circle the wagons on Monday with the chairs with the use case= draft as an item and start the re-chartering process. spt On 6/4/13 4:40 PM, Sean Turner wrote: Well unless I'm hearing any violent objections I think adding it would make sense actually. It's also an easy for somebody who is using this technology to get their feet wet in the WG. spt On 6/4/13 10:59 AM, Kent_Landfield@McAfee.com wrote: :-) Something told me you would ask that=85. ;-) Let me see if I can find someone to help with it. Volunteers? I could use some help I am sure. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com From: Sean Turner > Date: Tuesday, June 4, 2013 7:29 AM To: Kent Landfield > Cc: "mile@ietf.org " > Subject: Re: [mile] re-charter re-boot Is that you volunteering to write such a draft ;) spt On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com wrote: I have no problem with the revised charter as is but I think there is something missing. It would be good to have as a milestone a document that described use cases for these protocols. I rather see this separated out since we are in a situation now of addressing the transport (RID) , the data model for exchange (IODEF) and query/reporting capabilities (ROLIE). We need to tie the three together and a document such as this would help lay a foundation for usage in multiple areas. FWIW=85 *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com From: Sean Turner > Date: Monday, June 3, 2013 12:30 PM To: "mile@ietf.org " > Subject: Re: [mile] re-charter re-boot Comments from anybody else? spt On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: Hi, Sorry for the delay in updating the charter. There is a lot of activity in this space right now as you all know. I took Sean's suggested content and updated it to reflect some of the activity and drivers for additional work in MILE. Several people have mentioned an interest in submitting extensions based on their current work, some in virtualized environments, some for indicator specific formats, some industry specific extensions, etc. There is also work developing by other groups who have mentioned that they will transition their work to an international standards body once it is mature, so room has been left in the charter to accommodate that work. The need for guidance on the transport options has surfaced so that implementers understand when they may choose a specific transport option to enable interoperable interfaces between products. The guidance may be use case specific where tighter security is needed (RID +HTTP/TLS with the object level security options enab led) or w here ease of access is the driver (ROLIE) with no client requirements necessary (can use a browser). We will follow up with the mile stones, here the the re-write: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF the data format and extensions to represent incident and indicator data and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Association for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org ] On Behalf Of Sean Turner [turners@ieca.com ] Sent: Wednesday, May 01, 2013 9:04 PM To: mile@ietf.org Subject: [mile] re-charter re-boot Hi, I'd like to propose a significant re-write of the proposed charter. I think there's too much history that's not really needed any more and there's some repetition that's unneeded. I also think it's a little open ended wrt what's actually going to get done. Based on recent experience, I have a strong feeling that the current charter wouldn't get through the process. I'm proposing four sections: intro, iodef-related work, rid-related work, milestones. The intro should: - explain what the WG does: develop standards to do foo. - summarize what foo is. - highlight existing RFCs that are part of the space: IODEF: 5070/5091/6848 & RID: 6545/6546. Then we talk about what drafts the WG will produce for the two topic areas. How about this (or something like this): The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing indicators of compromise, or requesting that the source be located. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. This working group does two things IODEF and RID; we should be clear about that and then list the actual documents we're going to produce that relate to each one. For the list of deliverables it looks like there's three 5070bis, a reference/guidance draft, and a resource-oriented indicator exchange? Questions: Are the GRC and Forensic drafts dead-dead? I assume they'd not be included in the milestone list. Is there going to only be one 5070bis draft or will there be a 5070bis + other optional extension drafts? I assume it's just a 5070bis based on the milestones but thought I'd ask. Are we only extending IODEF based on use or is there something else we need to consider? How about something along the lines of (need some help filling in the blanks): With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience; use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support x, y, z (need to have some idea what's missing) base on a, b, c (need to know a bit more about why stuff is missing did something new pop up?). - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. For RID: Are we also doing defining guidance for RID as well or is that incorporated in the IODEF guidance? Is RID itself going to be untouched and we're just producing a new "transport"? Is it just for indicators or is it for the whole incident? Or has "indicators" over taken "incident"? With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. These looked fine, but I'd like some actual dates for the TBDs ;) spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_3CBA099FBA0AB843895D72474092B8CF28A3A3MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: <563A276D3729E04A85680F5D401F814A@McAfee.com> Content-Transfer-Encoding: quoted-printable
The revised dra= ft charter states
  • Provide guidance = on the implementation and use of RID transports
    based on use case= s.  The guidance document will show the relationship
    between transport= options (RID + RID transport and IODEF/RID + ROLIE)
    and may identify = the need for additional transport bindings.
I was looking at an overview document th= at described an architectural view of the problem and how MILE protocols co= uld be integrated to support the various community uses. In retrospect, if = this is what you envisioned, we could incorporate this into the document.  Guidance of implementation targe= ted at RID does not sound like what I was thinking about.  I volunteer= to be a part of the document's development if it makes sense to incorporat= e the larger perspective. If not, we can make it a separate document.

Kent L= andfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Moriarty>, Kathleen Mo= riarty <kathleen.moriarty@e= mc.com>
Date: Friday, June 7, 2013 9:44 AM<= br> To: Kent Landfield <Kent_Landfield@McAfee.com>
Cc: Sean Turner <turners@ieca.com>, "mile@ietf.org" <mil= e@ietf.org>
Subject: Re: [mile] re-charter re-b= oot

Hi,

The intent of the text that Panos pointed out was the same as what Ken= t described.  Does the text need to be adjusted?  Any s= uggestions?

FYI- I am off this week and may not respond until Monday.

Thanks,
Kathleen

Sent from my iPhone

On Jun 6, 2013, at 1:40 PM, "Kent_Landfield@McAfee.com" <Kent_Landfield@McAfee.com> wrote:

Understand. Sounds good to me.

Kent Landfield
McAfee Labs
+1.817.637.8026

On Jun 6, 2013, at 12:31 PM, "Sean Turner" <turners@ieca.com> wrote:

Kent and this dawned on me too last night ... don't let it being a WG = item stop you or anybody really from writing an individual draft that could= be considered for wg acceptance.

My plan is to circle the wagons on Monday with the chairs with the use= case draft as an item and start the re-chartering process.

spt

On 6/4/13 4:40 PM, Sean Turner wrote:
Well unless I'm hearing any violent objections I think adding it would=
make sense actually.  It's also an easy for somebody who is = using this
technology to get their feet wet in the WG.

spt

On 6/4/13 10:59 AM, Kent_= Landfield@McAfee.com wrote:
:-) Something told me you would ask that=85.  ;-)

Let me see if I can find someone to help with it. Volunteers? &nb= sp;I could
use some help I am sure.

*Kent Landfield*

*McAfee | An Intel Company*
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
*Web: *www.mcafee.com <http://ww= w.mcafee.com/>

Date: Tuesday, June 4, 2013 7:29 AM
To: Kent Landfield <Ke= nt_Landfield@McAfee.com
Subject: Re: [mile] re-charter re-boot

   Is that you volunteering to write such a draft ;)

   spt

   On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com

       I have no problem with the revise= d charter as is but I think
       there is
       something missing.  It = would be good to have as a milestone a
       document
       that described use cases for thes= e protocols.  I rather see this
       separated out since we are in a s= ituation now of addressing the
       transport (RID) , the data model = for exchange (IODEF) and
       query/reporting capabilities (ROL= IE).  We need to tie the three
       together
       and a document such as this would= help lay a foundation for
usage in
       multiple areas.

       FWIW=85

       *Kent Landfield*

       *McAfee | An Intel Company*
       Direct: +1.972.963.7096
       Mobile: +1.817.637.8026
       *Web: *www.mcafee.com <http://www.mcafee.com/>

       From: Sean Turner <turners@ieca.com <mailto:turners@ieca.com>
       Date: Monday, June 3, 2013 12:30 = PM
       <mailto:mile@ietf.org>>
       Subject: Re: [mile] re-charter re= -boot

           &nbs= p; Comments from anybody else?

           &nbs= p; spt

           &nbs= p; On 5/25/13 9:11 AM, Moriarty, Kathleen wrote:

           &nbs= p;     Hi,

           &nbs= p;     Sorry for the delay in updating the charter.&nbs= p; There is
       a lot of
           &nbs= p;     activity in this space right now as you all know= .  I
       took Sean's
           &nbs= p;     suggested content and updated it to reflect some= of
       the activity
           &nbs= p;     and drivers for additional work in MILE. &n= bsp;Several
       people have
           &nbs= p;     mentioned an interest in submitting extensions b= ased
       on their
           &nbs= p;     current work, some in virtualized environments, = some
for
           &nbs= p;     indicator specific formats, some industry specif= ic
       extensions,
           &nbs= p;     etc.  There is also work developing by= other groups
       who have
           &nbs= p;     mentioned that they will transition their work t= o an
           &nbs= p;     international standards body once it is mature, = so
       room has been
           &nbs= p;     left in the charter to accommodate that work.&nb= sp; The
       need for
           &nbs= p;     guidance on the transport options has surfaced s= o that
           &nbs= p;     implementers understand when they may choose a s= pecific
           &nbs= p;     transport option to enable interoperable interfa= ces
       between
           &nbs= p;     products.  The guidance may be use cas= e specific where
       tighter
           &nbs= p;     security is needed (RID +HTTP/TLS with the o= bject
       level security
           &nbs= p;     options enab

           &nbs= p; led) or w
           &nbs= p; here ease of access is the driver (ROLIE) with no client
           &nbs= p; requirements necessary (can use a browser).


           &nbs= p;     We will follow up with the mile stones, here the= the
       re-write:

           &nbs= p;     <intro>

           &nbs= p;     The Managed Incident Lightweight Exchange (MILE)=
       working group
           &nbs= p;     develops standards to support computer and netwo= rk
       security
           &nbs= p;     incident management; an incident is an unplanned= event
       that
           &nbs= p;     occurs in an information technology (IT)
       infrastructure. An
           &nbs= p;     incident could be a benign configuration issue, = IT
       incident, an
           &nbs= p;     infraction to a service level agreement (SLA), a= system
           &nbs= p;     compromise, socially engineered phishing attack,= or a
           &nbs= p;     denial-of-service (DoS) attack, etc.  = When an
incident is
           &nbs= p;     detected, or suspected, there may be a need for<= /div>
       organizations to
           &nbs= p;     collaborate. This collaboration effort may take<= /div>
       several forms
           &nbs= p;     including joint analysis, information disseminat= ion,
       and/or a
           &nbs= p;     coordinated operational response.  Exa= mples of the
       response may
           &nbs= p;     include filing a report, notifying the source of= the
       incident,
           &nbs= p;     requesting that a third party resolve/mitigate t= he
       incident,
           &nbs= p;     sharing select indicators of compromise, or requ= esting
       that the
           &nbs= p;     source be located. By sharing indicators of comp= romise
       associated
           &nbs= p;     with an incident or possible threat, the informa= tion
       becomes a
           &nbs= p;     proactive defense for others that may include
       mitigation options.
           &nbs= p;     The Incident Object Description Exchange Format<= /div>
       (IODEF) defines
           &nbs= p;     an information framework to represent computer a= nd
network
           &nbs= p;     security incidents; IODEF is defined in RFC 5070= and
           &nbs= p;     has been extended by RFC 5091 to support phishin= g
       reports; RFC
           &nbs= p;     6484 provides a template for defining extensions= to
IODEF.
           &nbs= p;     Real-time Inter-network Defense (RID) defines a<= /div>
       protocol to
           &nbs= p;     facilitate sharing computer and network security=
       incidents;
           &nbs= p;     RID is defined in RFC 6545, and RID over HTTPS i= s
       defined in RFC
           &nbs= p;     6546.

           &nbs= p;     </intro>

           &nbs= p;     The MILE WG is focused on two areas, IODEF the d= ata
       format and
           &nbs= p;     extensions to represent incident and indicator d= ata
       and RID,
           &nbs= p;     the policy and transport for structured data.&nb= sp; With
       respect to
           &nbs= p;     IODEF, the working group will:

           &nbs= p;     - Revise the IODEF document to incorporate
       enhancements and
           &nbs= p;     extensions based on operational experience; use = by
       Computer
           &nbs= p;     Security Incident Response Teams (CSIRTs) and ot= hers
has
           &nbs= p;     exposed the need to extend IODEF to support indu= stry
       specific
           &nbs= p;     extensions, use case specific content, and
       representations to
           &nbs= p;     associate information related to represented thr= eats
       (system,
           &nbs= p;     threat actors, campaigns, etc.).  The = value of
information
           &nbs= p;     sharing has been demonstrated and highlighted at= an
       increasing
           &nbs= p;     rate through the success of the Information Shar= ing and
           &nbs= p;     Analysis Centers (ISACs) and the recent cyber se= curity
       Executive
           &nbs= p;     Order in the US.  International groups= , such as the
       Multinational
           &nbs= p;     Association for Collaborative Cyber Situational<= /div>
       Awareness (CCSA)
           &nbs= p;     have been running experiments to determine what = data
       is useful to
           &nbs= p;     exchange between industries and nations to effec= tively
       mitigate
           &nbs= p;     threats.  The work of these and other = groups have
       identified or
           &nbs= p;     are working to develop data representations rele= vant
       to their use
           &nbs= p;     cases that may compliment/extend IODEF or be use= ful to
       exchange
           &nbs= p;     using RID and related transport protocols.

           &nbs= p;     - Provide guidance on the implementation and use= of
       IODEF to aid
           &nbs= p;     implementers in developing interoperable
specifications.

           &nbs= p;     With respect to RID, the working group will:

           &nbs= p;     - Define a resource-oriented approach to cyber s= ecurity
           &nbs= p;     information sharing that follows the REST
       architectural style.
           &nbs= p;     This mechanism will allow CSIRTS to be more dyna= mic
       and agile in
           &nbs= p;     collaborating with a broader, and varying consti= tuency.

           &nbs= p;     - Provide guidance on the implementation and use= of
       RID transports
           &nbs= p;     based on use cases.  The guidance docu= ment will show
the
           &nbs= p;     relationship
           &nbs= p;     between transport options (RID + RID transpo= rt and
       IODEF/RID +
           &nbs= p;     ROLIE)
           &nbs= p;     and may identify the need for additional transpo= rt
       bindings.

           &nbs= p;     - RID may require modifications to address data<= /div>
       provenance,
           &nbs= p;     additional
           &nbs= p;     policy options, or other changes now that there = are
       multiple
           &nbs= p;     interoperable implementations of RFC6545 and
       RFC6546.  With the
           &nbs= p;     RID implementations in the open source community= ,
       increased use and
           &nbs= p;     experimentation may demonstrate the need for a
revision.

           &nbs= p;     <milestones>

           &nbs= p;     </milestones>


           &nbs= p;     Thank you!
           &nbs= p;     Kathleen

           &nbs= p;     ________________________________________
           &nbs= p;     From: m= ile-bounces@ietf.org
           &nbs= p;     [mile-b= ounces@ietf.org <mailto:mil= e-bounces@ietf.org>
       <mailto:mile-bounces@ietf.org>] On Behalf
           &nbs= p;     Of Sean Turner [turners@ieca.com
           &nbs= p;     Sent: Wednesday, May 01, 2013 9:04 PM
           &nbs= p;     To: mile@ietf.o= rg <mailto:mile@ietf.org>
       <mailto:mile@ietf.org>
           &nbs= p;     Subject: [mile] re-charter re-boot

           &nbs= p;     Hi,

           &nbs= p;     I'd like to propose a significant re-write of th= e
proposed
           &nbs= p;     charter.  I
           &nbs= p;     think there's too much history that's not really=
       needed any more and
           &nbs= p;     there's some repetition that's unneeded. &n= bsp;I also think
       it's a little
           &nbs= p;     open ended wrt what's actually going to get done= .
       Based on recent
           &nbs= p;     experience, I have a strong feeling that the cur= rent
       charter
           &nbs= p;     wouldn't
           &nbs= p;     get through the process.

           &nbs= p;     I'm proposing four sections: intro, iodef-relate= d
       work, rid-related
           &nbs= p;     work, milestones.

           &nbs= p;     The intro should:

           &nbs= p;     - explain what the WG does: develop standards to= do
foo.
           &nbs= p;     - summarize what foo is.
           &nbs= p;     - highlight existing RFCs that are part of the s= pace:
           &nbs= p;           IODEF: 5070/= 5091/6848 & RID: 6545/6546.

           &nbs= p;     Then we talk about what drafts the WG will produ= ce for
       the two
           &nbs= p;     topic areas.

           &nbs= p;     How about this (or something like this):

           &nbs= p;     <intro>

           &nbs= p;     The Managed Incident Lightweight Exchange (MILE)=
       working group
           &nbs= p;     develops standards to support computer and netwo= rk
       security
           &nbs= p;     incident management; an incident is an unplanned= event
       that
           &nbs= p;     occurs in an information technology (IT)
       infrastructure. An
           &nbs= p;     incident could be a benign configuration issue, = IT
       incident, an
           &nbs= p;     infraction to a service level agreement (SLA), a= system
           &nbs= p;     compromise, socially engineered phishing attack,= or a
           &nbs= p;     denial-of-service (DoS) attack, etc.  = When an
incident is
           &nbs= p;     detected, or suspected, there may be a need for<= /div>
       organizations to
           &nbs= p;     collaborate. This collaboration effort may take<= /div>
       several forms
           &nbs= p;     including joint analysis, information disseminat= ion,
       and/or a
           &nbs= p;     coordinated operational response.  Exa= mples of the
       response may
           &nbs= p;     include filing a report, notifying the source of= the
       incident,
           &nbs= p;     requesting that a third party resolve/mitigate t= he
       incident,
           &nbs= p;     sharing indicators of compromise, or requesting = that
       the source
           &nbs= p;     be located. The Incident Object Description Exch= ange
       Format
           &nbs= p;     (IODEF) defines an information framework to repr= esent
       computer
           &nbs= p;     and network security incidents; IODEF is defined= in
       RFC 5070 and
           &nbs= p;     has been extended by RFC 5091 to support phishin= g
       reports; RFC
           &nbs= p;     6484 provides a template for defining extensions= to
IODEF.
           &nbs= p;     Real-time Inter-network Defense (RID) defines a<= /div>
       protocol to
           &nbs= p;     facilitate sharing computer and network security=
       incidents;
           &nbs= p;     RID is defined in RFC 6545, and RID over HTTPS i= s
       defined in RFC
           &nbs= p;     6546.

           &nbs= p;     </into>

           &nbs= p;     This working group does two things IODEF and RID= ; we
       should be clear
           &nbs= p;     about that and then list the actual documents we= 're
       going to produce
           &nbs= p;     that relate to each one.  For the list= of deliverables
       it looks like
           &nbs= p;     there's three 5070bis, a reference/guidance draf= t,
and a
           &nbs= p;     resource-oriented indicator exchange?

           &nbs= p;     Questions:

           &nbs= p;     Are the GRC and Forensic drafts dead-dead? =  I assume
       they'd not be
           &nbs= p;     included in the milestone list.

           &nbs= p;     Is there going to only be one 5070bis draft or w= ill
       there be a
           &nbs= p;     5070bis +
           &nbs= p;     other optional extension drafts?  I as= sume it's just a
       5070bis
           &nbs= p;     based on
           &nbs= p;     the milestones but thought I'd ask.

           &nbs= p;     Are we only extending IODEF based on use or is t= here
       something
           &nbs= p;     else we
           &nbs= p;     need to consider?

           &nbs= p;     How about something along the lines of (need som= e help
       filling
           &nbs= p;     in the
           &nbs= p;     blanks):

           &nbs= p;     <iodef>

           &nbs= p;     With respect to IODEF, the working group will:

           &nbs= p;     - Revise the IODEF document to incorporate
       enhancements and
           &nbs= p;     extensions based on operational experience; use = by
       Computer
           &nbs= p;     Security Incident Response Teams (CSIRTs) and ot= hers
has
           &nbs= p;     exposed the need to extend IODEF to support x, y= , z
       (need to have
           &nbs= p;     some idea what's missing) base on a, b, c (need = to
       know a bit
           &nbs= p;     more about why stuff is missing did something ne= w pop
       up?).

           &nbs= p;     - Provide guidance on the implementation and use= of
       IODEF to aid
           &nbs= p;     implementers in developing interoperable
specifications.

           &nbs= p;     </iodef>

           &nbs= p;     For RID:

           &nbs= p;     Are we also doing defining guidance for RID as w= ell or
       is that
           &nbs= p;     incorporated in the IODEF guidance?

           &nbs= p;     Is RID itself going to be untouched and we're ju= st
       producing a new
           &nbs= p;     "transport"?

           &nbs= p;     Is it just for indicators or is it for the whole=
       incident?  Or has
           &nbs= p;     "indicators" over taken "incident= "?

           &nbs= p;     <rid>

           &nbs= p;     With respect to RID, the working group will:

           &nbs= p;     - Define a resource-oriented approach to cyber s= ecurity
           &nbs= p;     information sharing that follows the REST
       architectural style.
           &nbs= p;     This mechanism will allow CSIRTS to be more dyna= mic
       and agile in
           &nbs= p;     collaborating with a broader, and varying consti= tuency.

           &nbs= p;     </rid>

           &nbs= p;     <milestones>

           &nbs= p;     These looked fine, but I'd like some actual date= s for
       the TBDs ;)

           &nbs= p;     </milestones>

           &nbs= p;     spt
           &nbs= p;     _______________________________________________<= /div>
           &nbs= p;     mile mailing list
       = mile@ietf.org <mailto:mile@ietf.org= > <mailto:mile@ietf.org><= /div>

           &nbs= p; _______________________________________________
           &nbs= p; mile mailing list
_______________________________________________
mile mailing list
_______________________________________________
mile mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF28A3A3MIVEXAMER1N1corpn_-- From jfield@gopivotal.com Fri Jun 7 11:54:30 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9B21F96EB for ; Fri, 7 Jun 2013 11:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 868KhN6w-fsa for ; Fri, 7 Jun 2013 11:54:28 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4921F861F for ; Fri, 7 Jun 2013 11:54:27 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id g12so3691200oah.12 for ; Fri, 07 Jun 2013 11:54:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=UW+LODC79R0RtMNsOLlhdsqkJWhhsfxiURaN3f/mkfw=; b=SWWpozN7rkL+uVUWL3LlhA0A62n6ckLQFQoXggAuGcUyUihIi6RWrmhkNrGrm348Jm mc7Q9sDVuHREJMNF/iksQ9OT13DU9CuKf451HwNkrLB7+ezasWTiM7cTEUdKm1wePH0w c0RvwP9VWMDrbmVfNIgby/zq4knwTA3x71QyBqnWscbyqeN4Fnve+oPCxjEUS9Tih9RG pbCqyQKVa3TX7gqu3PeWWeWJcs1alqqSGVIxbPtNvHDNpfxARbo4+ELAXIb+GwF0rmwA VUcKmQoYoGqZ0v8USQXBXaVmjT2B/wS2OznLF0SKtXM/eh/NLyoz2F9aSvkRqGYn1c5z rH8g== MIME-Version: 1.0 X-Received: by 10.182.233.227 with SMTP id tz3mr52509obc.23.1370631267217; Fri, 07 Jun 2013 11:54:27 -0700 (PDT) Received: by 10.76.152.195 with HTTP; Fri, 7 Jun 2013 11:54:26 -0700 (PDT) In-Reply-To: <8BD71AD4-9545-4EE1-8015-79A6957DB5E6@emc.com> References: <3CBA099FBA0AB843895D72474092B8CF278501@MIVEXAMER1N1.corp.nai.org> <51AE50D9.1090408@ieca.com> <51B0C782.40202@ieca.com> <342874C7-5E2D-4645-BB12-FC1A20F4C0D8@McAfee.com> <8BD71AD4-9545-4EE1-8015-79A6957DB5E6@emc.com> Date: Fri, 7 Jun 2013 14:54:26 -0400 Message-ID: From: John Field To: "Moriarty, Kathleen" Content-Type: multipart/related; boundary=001a11c2029acda86004de94f55e X-Gm-Message-State: ALoCoQnEn4BZHSM/qU64JnzY0TKneRSgonPcdOUzpYx4DIUxlxpGr+kk9+oivck36SW0ttEORDHR Cc: "mile@ietf.org" Subject: Re: [mile] re-charter re-boot X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:54:30 -0000 --001a11c2029acda86004de94f55e Content-Type: multipart/alternative; boundary=001a11c2029acda85e04de94f55d --001a11c2029acda85e04de94f55d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Panos that the text we have in the draft charter provides the right initial context, but Kent and David have a point, and there is never any harm in getting even more specific. Referring back to the current draft charter text, we've recently added the following sentences into the intro section.... "When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response". I think this does identify the core use cases, and could serve as the basis of elaborating more detailed requirements. When I first started thinking about the ROLIE draft, I was motivated by the differences I saw in the requirements for these three aspects, or use cases: - cross-organization cyber information sharing - cross-organization joint analysis - cross-organization joint operational response Here is a really quick "swag" at how these might differ in requirements: - cross-organization information sharing (i.e. essentially a write-only operation) -- requirements: -- minimize resource consumption on provider side, to encourage broad support/participation. -- enable easy support for opt-in eventing, and historical inquiry -- allow support for multiple schemas, multiple representations, e.g. for format, or redaction.... -- support individual user-based AAA, avoiding inter-org trust management.... - cross-organization collaboration for purposes of performing joint analysis (i.e. essentially asynchronous read-write) -- requirements: -- minimize latency -- enable support for continued use of existing analyst tools/workbenches -- leverage existing org-to-org trust relationships, if present -- support for communities of interest / distribution groups - cross-organization collaboration for purposes of conducting a joint operational response. (i.e. essentially synchronous read-write) --requirements -- integrity and confidentiality assurance essential -- full support for org-to-org trust management. -- support positive/negative acknowledgement -- support explicit prioritization Of course, this is just "shooting from the hip". But, if we look at the use case problem in this way, that may help us to scope things appropriately, and enumerate specific requirements for each use case, or provide guidance on what combinations of message formats and protocols are optimal for each situation. This would not be appropriate for the charter, but could be covered in a separate document, as alluded to by Kent, and (IIRC) Eric. HTH. Regards, John On Fri, Jun 7, 2013 at 10:44 AM, Moriarty, Kathleen < kathleen.moriarty@emc.com> wrote: > Hi, > > The intent of the text that Panos pointed out was the same as what Kent > described. Does the text need to be adjusted? Any suggestions? > > FYI- I am off this week and may not respond until Monday. > > Thanks, > Kathleen > > Sent from my iPhone > > On Jun 6, 2013, at 1:40 PM, "Kent_Landfield@McAfee.com" > wrote: > > > Understand. Sounds good to me. > > > > Kent Landfield > > McAfee Labs > > Kent_Landfield@McAfee.com > > +1.817.637.8026 > > > > On Jun 6, 2013, at 12:31 PM, "Sean Turner" wrote: > > > >> Kent and this dawned on me too last night ... don't let it being a WG > item stop you or anybody really from writing an individual draft that cou= ld > be considered for wg acceptance. > >> > >> My plan is to circle the wagons on Monday with the chairs with the use > case draft as an item and start the re-chartering process. > >> > >> spt > >> > >> On 6/4/13 4:40 PM, Sean Turner wrote: > >>> Well unless I'm hearing any violent objections I think adding it woul= d > >>> make sense actually. It's also an easy for somebody who is using thi= s > >>> technology to get their feet wet in the WG. > >>> > >>> spt > >>> > >>> On 6/4/13 10:59 AM, Kent_Landfield@McAfee.com wrote: > >>>> :-) Something told me you would ask that=85. ;-) > >>>> > >>>> Let me see if I can find someone to help with it. Volunteers? I cou= ld > >>>> use some help I am sure. > >>>> > >>>> *Kent Landfield* > >>>> > >>>> *McAfee | An Intel Company* > >>>> Direct: +1.972.963.7096 > >>>> Mobile: +1.817.637.8026 > >>>> *Web: *www.mcafee.com > >>>> > >>>> From: Sean Turner > > >>>> Date: Tuesday, June 4, 2013 7:29 AM > >>>> To: Kent Landfield >>>> > > >>>> Cc: "mile@ietf.org " >>>> > > >>>> Subject: Re: [mile] re-charter re-boot > >>>> > >>>> Is that you volunteering to write such a draft ;) > >>>> > >>>> spt > >>>> > >>>> On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com > >>>> wrote: > >>>> > >>>> I have no problem with the revised charter as is but I think > >>>> there is > >>>> something missing. It would be good to have as a milestone a > >>>> document > >>>> that described use cases for these protocols. I rather see th= is > >>>> separated out since we are in a situation now of addressing th= e > >>>> transport (RID) , the data model for exchange (IODEF) and > >>>> query/reporting capabilities (ROLIE). We need to tie the thre= e > >>>> together > >>>> and a document such as this would help lay a foundation for > >>>> usage in > >>>> multiple areas. > >>>> > >>>> FWIW=85 > >>>> > >>>> *Kent Landfield* > >>>> > >>>> *McAfee | An Intel Company* > >>>> Direct: +1.972.963.7096 > >>>> Mobile: +1.817.637.8026 > >>>> *Web: *www.mcafee.com > >>>> > >>>> From: Sean Turner > >>>> > > >>>> Date: Monday, June 3, 2013 12:30 PM > >>>> To: "mile@ietf.org > >>>> " > >>>> > > >>>> Subject: Re: [mile] re-charter re-boot > >>>> > >>>> Comments from anybody else? > >>>> > >>>> spt > >>>> > >>>> On 5/25/13 9:11 AM, Moriarty, Kathleen wrote: > >>>> > >>>> Hi, > >>>> > >>>> Sorry for the delay in updating the charter. There = is > >>>> a lot of > >>>> activity in this space right now as you all know. I > >>>> took Sean's > >>>> suggested content and updated it to reflect some of > >>>> the activity > >>>> and drivers for additional work in MILE. Several > >>>> people have > >>>> mentioned an interest in submitting extensions based > >>>> on their > >>>> current work, some in virtualized environments, some > >>>> for > >>>> indicator specific formats, some industry specific > >>>> extensions, > >>>> etc. There is also work developing by other groups > >>>> who have > >>>> mentioned that they will transition their work to an > >>>> international standards body once it is mature, so > >>>> room has been > >>>> left in the charter to accommodate that work. The > >>>> need for > >>>> guidance on the transport options has surfaced so th= at > >>>> implementers understand when they may choose a > specific > >>>> transport option to enable interoperable interfaces > >>>> between > >>>> products. The guidance may be use case specific whe= re > >>>> tighter > >>>> security is needed (RID +HTTP/TLS with the object > >>>> level security > >>>> options enab > >>>> > >>>> led) or w > >>>> here ease of access is the driver (ROLIE) with no client > >>>> requirements necessary (can use a browser). > >>>> > >>>> > >>>> We will follow up with the mile stones, here the the > >>>> re-write: > >>>> > >>>> > >>>> > >>>> The Managed Incident Lightweight Exchange (MILE) > >>>> working group > >>>> develops standards to support computer and network > >>>> security > >>>> incident management; an incident is an unplanned eve= nt > >>>> that > >>>> occurs in an information technology (IT) > >>>> infrastructure. An > >>>> incident could be a benign configuration issue, IT > >>>> incident, an > >>>> infraction to a service level agreement (SLA), a > system > >>>> compromise, socially engineered phishing attack, or = a > >>>> denial-of-service (DoS) attack, etc. When an > >>>> incident is > >>>> detected, or suspected, there may be a need for > >>>> organizations to > >>>> collaborate. This collaboration effort may take > >>>> several forms > >>>> including joint analysis, information dissemination, > >>>> and/or a > >>>> coordinated operational response. Examples of the > >>>> response may > >>>> include filing a report, notifying the source of the > >>>> incident, > >>>> requesting that a third party resolve/mitigate the > >>>> incident, > >>>> sharing select indicators of compromise, or requesti= ng > >>>> that the > >>>> source be located. By sharing indicators of compromi= se > >>>> associated > >>>> with an incident or possible threat, the information > >>>> becomes a > >>>> proactive defense for others that may include > >>>> mitigation options. > >>>> The Incident Object Description Exchange Format > >>>> (IODEF) defines > >>>> an information framework to represent computer and > >>>> network > >>>> security incidents; IODEF is defined in RFC 5070 and > >>>> has been extended by RFC 5091 to support phishing > >>>> reports; RFC > >>>> 6484 provides a template for defining extensions to > >>>> IODEF. > >>>> Real-time Inter-network Defense (RID) defines a > >>>> protocol to > >>>> facilitate sharing computer and network security > >>>> incidents; > >>>> RID is defined in RFC 6545, and RID over HTTPS is > >>>> defined in RFC > >>>> 6546. > >>>> > >>>> > >>>> > >>>> The MILE WG is focused on two areas, IODEF the data > >>>> format and > >>>> extensions to represent incident and indicator data > >>>> and RID, > >>>> the policy and transport for structured data. With > >>>> respect to > >>>> IODEF, the working group will: > >>>> > >>>> - Revise the IODEF document to incorporate > >>>> enhancements and > >>>> extensions based on operational experience; use by > >>>> Computer > >>>> Security Incident Response Teams (CSIRTs) and others > >>>> has > >>>> exposed the need to extend IODEF to support industry > >>>> specific > >>>> extensions, use case specific content, and > >>>> representations to > >>>> associate information related to represented threats > >>>> (system, > >>>> threat actors, campaigns, etc.). The value of > >>>> information > >>>> sharing has been demonstrated and highlighted at an > >>>> increasing > >>>> rate through the success of the Information Sharing > and > >>>> Analysis Centers (ISACs) and the recent cyber securi= ty > >>>> Executive > >>>> Order in the US. International groups, such as the > >>>> Multinational > >>>> Association for Collaborative Cyber Situational > >>>> Awareness (CCSA) > >>>> have been running experiments to determine what data > >>>> is useful to > >>>> exchange between industries and nations to effective= ly > >>>> mitigate > >>>> threats. The work of these and other groups have > >>>> identified or > >>>> are working to develop data representations relevant > >>>> to their use > >>>> cases that may compliment/extend IODEF or be useful = to > >>>> exchange > >>>> using RID and related transport protocols. > >>>> > >>>> - Provide guidance on the implementation and use of > >>>> IODEF to aid > >>>> implementers in developing interoperable > >>>> specifications. > >>>> > >>>> With respect to RID, the working group will: > >>>> > >>>> - Define a resource-oriented approach to cyber > security > >>>> information sharing that follows the REST > >>>> architectural style. > >>>> This mechanism will allow CSIRTS to be more dynamic > >>>> and agile in > >>>> collaborating with a broader, and varying > constituency. > >>>> > >>>> - Provide guidance on the implementation and use of > >>>> RID transports > >>>> based on use cases. The guidance document will show > >>>> the > >>>> relationship > >>>> between transport options (RID + RID transport and > >>>> IODEF/RID + > >>>> ROLIE) > >>>> and may identify the need for additional transport > >>>> bindings. > >>>> > >>>> - RID may require modifications to address data > >>>> provenance, > >>>> additional > >>>> policy options, or other changes now that there are > >>>> multiple > >>>> interoperable implementations of RFC6545 and > >>>> RFC6546. With the > >>>> RID implementations in the open source community, > >>>> increased use and > >>>> experimentation may demonstrate the need for a > >>>> revision. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thank you! > >>>> Kathleen > >>>> > >>>> ________________________________________ > >>>> From: mile-bounces@ietf.org > >>>> > >>>> [mile-bounces@ietf.org > >>>> ] On Behalf > >>>> Of Sean Turner [turners@ieca.com > >>>> ] > >>>> Sent: Wednesday, May 01, 2013 9:04 PM > >>>> To: mile@ietf.org > >>>> > >>>> Subject: [mile] re-charter re-boot > >>>> > >>>> Hi, > >>>> > >>>> I'd like to propose a significant re-write of the > >>>> proposed > >>>> charter. I > >>>> think there's too much history that's not really > >>>> needed any more and > >>>> there's some repetition that's unneeded. I also thi= nk > >>>> it's a little > >>>> open ended wrt what's actually going to get done. > >>>> Based on recent > >>>> experience, I have a strong feeling that the current > >>>> charter > >>>> wouldn't > >>>> get through the process. > >>>> > >>>> I'm proposing four sections: intro, iodef-related > >>>> work, rid-related > >>>> work, milestones. > >>>> > >>>> The intro should: > >>>> > >>>> - explain what the WG does: develop standards to do > >>>> foo. > >>>> - summarize what foo is. > >>>> - highlight existing RFCs that are part of the space= : > >>>> IODEF: 5070/5091/6848 & RID: 6545/6546. > >>>> > >>>> Then we talk about what drafts the WG will produce f= or > >>>> the two > >>>> topic areas. > >>>> > >>>> How about this (or something like this): > >>>> > >>>> > >>>> > >>>> The Managed Incident Lightweight Exchange (MILE) > >>>> working group > >>>> develops standards to support computer and network > >>>> security > >>>> incident management; an incident is an unplanned eve= nt > >>>> that > >>>> occurs in an information technology (IT) > >>>> infrastructure. An > >>>> incident could be a benign configuration issue, IT > >>>> incident, an > >>>> infraction to a service level agreement (SLA), a > system > >>>> compromise, socially engineered phishing attack, or = a > >>>> denial-of-service (DoS) attack, etc. When an > >>>> incident is > >>>> detected, or suspected, there may be a need for > >>>> organizations to > >>>> collaborate. This collaboration effort may take > >>>> several forms > >>>> including joint analysis, information dissemination, > >>>> and/or a > >>>> coordinated operational response. Examples of the > >>>> response may > >>>> include filing a report, notifying the source of the > >>>> incident, > >>>> requesting that a third party resolve/mitigate the > >>>> incident, > >>>> sharing indicators of compromise, or requesting that > >>>> the source > >>>> be located. The Incident Object Description Exchange > >>>> Format > >>>> (IODEF) defines an information framework to represen= t > >>>> computer > >>>> and network security incidents; IODEF is defined in > >>>> RFC 5070 and > >>>> has been extended by RFC 5091 to support phishing > >>>> reports; RFC > >>>> 6484 provides a template for defining extensions to > >>>> IODEF. > >>>> Real-time Inter-network Defense (RID) defines a > >>>> protocol to > >>>> facilitate sharing computer and network security > >>>> incidents; > >>>> RID is defined in RFC 6545, and RID over HTTPS is > >>>> defined in RFC > >>>> 6546. > >>>> > >>>> > >>>> > >>>> This working group does two things IODEF and RID; we > >>>> should be clear > >>>> about that and then list the actual documents we're > >>>> going to produce > >>>> that relate to each one. For the list of deliverabl= es > >>>> it looks like > >>>> there's three 5070bis, a reference/guidance draft, > >>>> and a > >>>> resource-oriented indicator exchange? > >>>> > >>>> Questions: > >>>> > >>>> Are the GRC and Forensic drafts dead-dead? I assume > >>>> they'd not be > >>>> included in the milestone list. > >>>> > >>>> Is there going to only be one 5070bis draft or will > >>>> there be a > >>>> 5070bis + > >>>> other optional extension drafts? I assume it's just= a > >>>> 5070bis > >>>> based on > >>>> the milestones but thought I'd ask. > >>>> > >>>> Are we only extending IODEF based on use or is there > >>>> something > >>>> else we > >>>> need to consider? > >>>> > >>>> How about something along the lines of (need some he= lp > >>>> filling > >>>> in the > >>>> blanks): > >>>> > >>>> > >>>> > >>>> With respect to IODEF, the working group will: > >>>> > >>>> - Revise the IODEF document to incorporate > >>>> enhancements and > >>>> extensions based on operational experience; use by > >>>> Computer > >>>> Security Incident Response Teams (CSIRTs) and others > >>>> has > >>>> exposed the need to extend IODEF to support x, y, z > >>>> (need to have > >>>> some idea what's missing) base on a, b, c (need to > >>>> know a bit > >>>> more about why stuff is missing did something new po= p > >>>> up?). > >>>> > >>>> - Provide guidance on the implementation and use of > >>>> IODEF to aid > >>>> implementers in developing interoperable > >>>> specifications. > >>>> > >>>> > >>>> > >>>> For RID: > >>>> > >>>> Are we also doing defining guidance for RID as well = or > >>>> is that > >>>> incorporated in the IODEF guidance? > >>>> > >>>> Is RID itself going to be untouched and we're just > >>>> producing a new > >>>> "transport"? > >>>> > >>>> Is it just for indicators or is it for the whole > >>>> incident? Or has > >>>> "indicators" over taken "incident"? > >>>> > >>>> > >>>> > >>>> With respect to RID, the working group will: > >>>> > >>>> - Define a resource-oriented approach to cyber > security > >>>> information sharing that follows the REST > >>>> architectural style. > >>>> This mechanism will allow CSIRTS to be more dynamic > >>>> and agile in > >>>> collaborating with a broader, and varying > constituency. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> These looked fine, but I'd like some actual dates fo= r > >>>> the TBDs ;) > >>>> > >>>> > >>>> > >>>> spt > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > --=20 John P. Field | Security Architect | Pivotal Direct: (908) 962-3394 | jfield@gopivotal.com *[image: cid:332B1A9B-BFB1-42CC-8C13-5949BB4B8266]* *goPivotal.com * --001a11c2029acda85e04de94f55d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I agree with Panos that the text we have in the draft char= ter provides the right initial context, but Kent and David have a point, an= d there is never any harm in getting even more specific. =A0=A0Referring ba= ck to the current draft charter text, we've recently added the followin= g sentences into the intro section....

"When an incident is=A0detected, or= suspected, there may be a need for organizations to
collaborate. This collaboration effort may take several forms=A0= including joint analysis,=A0
information dissemination, and/or a=A0coordinated opera= tional response".

I think this does identify the core us= e cases, and could serve as the basis of elaborating more detailed requirem= ents. =A0 When I first started thinking about the ROLIE draft, I was motiva= ted by the differences I saw in the requirements for these three aspects, o= r use cases:

- cross-organization cyber information sharing
- cross-organization joint analysis
- cro= ss-organization joint operational response


Here is a really quick "swag" at how these m= ight differ in requirements:


- cross-organization information sharing (i.e. essentia= lly a write-only operation)
=A0 =A0-- requirements: =A0
=A0 =A0 =A0 =A0 =A0-- minimize resource consumption on provider side, to e= ncourage broad support/participation.=A0
=A0 =A0 =A0 =A0 =A0-- enable easy support for opt-in eventing, and his= torical inquiry
=A0 =A0 =A0 =A0 =A0-- allow support for multiple = schemas, multiple representations, e.g. for format, or redaction....
<= div>=A0 =A0 =A0 =A0 =A0-- support individual user-based AAA, avoiding inter= -org trust management....

- cross-organization collaboration for purposes of perf= orming joint analysis (i.e. essentially asynchronous read-write)
= =A0 =A0-- requirements:
=A0 =A0 =A0 =A0-- minimize latency
=A0 =A0 =A0 =A0-- enable support for continued use of existing analyst= tools/workbenches
=A0 =A0 =A0 =A0-- leverage existing org-to-org= trust relationships, if present
=A0 =A0 =A0 =A0-- support f= or communities of interest / distribution groups
=A0
- cross-organization collaboration for purposes of= conducting a joint operational response. =A0(i.e. essentially synchronous = read-write)
=A0 =A0 --requirements
=A0 =A0 =A0 =A0 -- integrity and conf= identiality assurance essential
=A0 =A0 =A0 =A0 -- full support f= or org-to-org trust management.
=A0 =A0 =A0 =A0 -- support po= sitive/negative acknowledgement=A0
=A0 =A0 =A0 =A0 -- support explicit prioritization
=A0 =A0 =A0 =A0=A0
Of course, this is just "shooting fr= om the hip". =A0But, if we look at the use case problem in this way, t= hat may help us to scope things appropriately, and enumerate specific requi= rements for each use case, or provide guidance on what combinations of mess= age formats and protocols are optimal for each situation. =A0This would not= be appropriate for the charter, but could be covered in a separate documen= t, as alluded to by Kent, and (IIRC) Eric.

HTH.

Regards= ,
John
=A0

=


On Fri, Jun 7= , 2013 at 10:44 AM, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> wrote:
Hi,

The intent of the text that Panos pointed out was the same as what Kent des= cribed. =A0Does the text need to be adjusted? =A0Any suggestions?

FYI- I am off this week and may not respond until Monday.

Thanks,
Kathleen

Sent from my iPhone

On Jun 6, 2013, at 1:40 PM, "Kent_Landfield@McAfee.com" <Kent_= Landfield@McAfee.com> wrote:

> Understand. Sounds good to me.
>
> Kent Landfield
> McAfee Labs
> Kent_Landfield@McAfee.com
> +1.817.637.80= 26
>
> On Jun 6, 2013, at 12:31 PM, "Sean Turner" <turners@ieca.com> wrote:
>
>> Kent and this dawned on me too last night ... don't let it bei= ng a WG item stop you or anybody really from writing an individual draft th= at could be considered for wg acceptance.
>>
>> My plan is to circle the wagons on Monday with the chairs with the= use case draft as an item and start the re-chartering process.
>>
>> spt
>>
>> On 6/4/13 4:40 PM, Sean Turner wrote:
>>> Well unless I'm hearing any violent objections I think add= ing it would
>>> make sense actually. =A0It's also an easy for somebody who= is using this
>>> technology to get their feet wet in the WG.
>>>
>>> spt
>>>
>>> On 6/4/13 10:59 AM, Kent_Landfield@McAfee.com wrote:
>>>> :-) Something told me you would ask that=85. =A0;-)
>>>>
>>>> Let me see if I can find someone to help with it. Voluntee= rs? =A0I could
>>>> use some help I am sure.
>>>>
>>>> *Kent Landfield*
>>>>
>>>> *McAfee | An Intel Company*
>>>> Direct: +1.972.963.7096
>>>> Mobile: +1.817.637.8026
>>>> *Web: *www.mcafee.com <http://www.mcafee.com/>
>>>>
>>>> From: Sean Turner <= turners@ieca.com <mailto:turners= @ieca.com>>
>>>> Date: Tuesday, June 4, 2013 7:29 AM
>>>> To: Kent Landfield <Kent_Landfield@McAfee.com
>>>> <mailto:Ke= nt_Landfield@McAfee.com>>
>>>> Cc: "mile@ietf.org <mailto:mile@ietf.org>" = <mile@ietf.org
>>>> <mailto:mile@ietf.org<= /a>>>
>>>> Subject: Re: [mile] re-charter re-boot
>>>>
>>>> =A0 Is that you volunteering to write such a draft ;)
>>>>
>>>> =A0 spt
>>>>
>>>> =A0 On 6/3/13 2:10 PM, Kent_Landfield@McAfee.com
>>>> =A0 <mailto:Kent_Landfield@McAfee.com> wrote:
>>>>
>>>> =A0 =A0 =A0 I have no problem with the revised charter as = is but I think
>>>> =A0 =A0 =A0 there is
>>>> =A0 =A0 =A0 something missing. =A0It would be good to have= as a milestone a
>>>> =A0 =A0 =A0 document
>>>> =A0 =A0 =A0 that described use cases for these protocols. = =A0I rather see this
>>>> =A0 =A0 =A0 separated out since we are in a situation now = of addressing the
>>>> =A0 =A0 =A0 transport (RID) , the data model for exchange = (IODEF) and
>>>> =A0 =A0 =A0 query/reporting capabilities (ROLIE). =A0We ne= ed to tie the three
>>>> =A0 =A0 =A0 together
>>>> =A0 =A0 =A0 and a document such as this would help lay a f= oundation for
>>>> usage in
>>>> =A0 =A0 =A0 multiple areas.
>>>>
>>>> =A0 =A0 =A0 FWIW=85
>>>>
>>>> =A0 =A0 =A0 *Kent Landfield*
>>>>
>>>> =A0 =A0 =A0 *McAfee | An Intel Company*
>>>> =A0 =A0 =A0 Direct: +1.972.963.7096
>>>> =A0 =A0 =A0 Mobile: +1.817.637.8026
>>>> =A0 =A0 =A0 *Web: *www.mcafee.com <http://www.mcafee.com/>
>>>>
>>>> =A0 =A0 =A0 From: Sean Turner <turners@ieca.com <mailto:turners@ieca.com>
>>>> =A0 =A0 =A0 <mailto:turners@ieca.com>>
>>>> =A0 =A0 =A0 Date: Monday, June 3, 2013 12:30 PM
>>>> =A0 =A0 =A0 To: "mil= e@ietf.org <mailto:mile@ietf.org>
>>>> =A0 =A0 =A0 <mailto:mi= le@ietf.org>" <mile@ietf.or= g <mailto:mile@ietf.org>
>>>> =A0 =A0 =A0 <mailto:mi= le@ietf.org>>
>>>> =A0 =A0 =A0 Subject: Re: [mile] re-charter re-boot
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Comments from anybody else?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 spt
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 On 5/25/13 9:11 AM, Moriarty, Kath= leen wrote:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sorry for the delay in upd= ating the charter. =A0There is
>>>> =A0 =A0 =A0 a lot of
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 activity in this space rig= ht now as you all know. =A0I
>>>> =A0 =A0 =A0 took Sean's
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 suggested content and upda= ted it to reflect some of
>>>> =A0 =A0 =A0 the activity
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and drivers for additional= work in MILE. =A0Several
>>>> =A0 =A0 =A0 people have
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mentioned an interest in s= ubmitting extensions based
>>>> =A0 =A0 =A0 on their
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 current work, some in virt= ualized environments, some
>>>> for
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicator specific formats= , some industry specific
>>>> =A0 =A0 =A0 extensions,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 etc. =A0There is also work= developing by other groups
>>>> =A0 =A0 =A0 who have
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mentioned that they will t= ransition their work to an
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 international standards bo= dy once it is mature, so
>>>> =A0 =A0 =A0 room has been
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 left in the charter to acc= ommodate that work. =A0The
>>>> =A0 =A0 =A0 need for
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 guidance on the transport = options has surfaced so that
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 implementers understand wh= en they may choose a specific
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 transport option to enable= interoperable interfaces
>>>> =A0 =A0 =A0 between
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 products. =A0The guidance = may be use case specific where
>>>> =A0 =A0 =A0 tighter
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 security is needed (RID +H= TTP/TLS with the object
>>>> =A0 =A0 =A0 level security
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 options enab
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 led) or w
>>>> =A0 =A0 =A0 =A0 =A0 =A0 here ease of access is the driver = (ROLIE) with no client
>>>> =A0 =A0 =A0 =A0 =A0 =A0 requirements necessary (can use a = browser).
>>>>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We will follow up with the= mile stones, here the the
>>>> =A0 =A0 =A0 re-write:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <intro>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Managed Incident Light= weight Exchange (MILE)
>>>> =A0 =A0 =A0 working group
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 develops standards to supp= ort computer and network
>>>> =A0 =A0 =A0 security
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 incident management; an in= cident is an unplanned event
>>>> =A0 =A0 =A0 that
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 occurs in an information t= echnology (IT)
>>>> =A0 =A0 =A0 infrastructure. An
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 incident could be a benign= configuration issue, IT
>>>> =A0 =A0 =A0 incident, an
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 infraction to a service le= vel agreement (SLA), a system
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compromise, socially engin= eered phishing attack, or a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 denial-of-service (DoS) at= tack, etc. =A0When an
>>>> incident is
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 detected, or suspected, th= ere may be a need for
>>>> =A0 =A0 =A0 organizations to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 collaborate. This collabor= ation effort may take
>>>> =A0 =A0 =A0 several forms
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 including joint analysis, = information dissemination,
>>>> =A0 =A0 =A0 and/or a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 coordinated operational re= sponse. =A0Examples of the
>>>> =A0 =A0 =A0 response may
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 include filing a report, n= otifying the source of the
>>>> =A0 =A0 =A0 incident,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 requesting that a third pa= rty resolve/mitigate the
>>>> =A0 =A0 =A0 incident,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sharing select indicators = of compromise, or requesting
>>>> =A0 =A0 =A0 that the
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source be located. By shar= ing indicators of compromise
>>>> =A0 =A0 =A0 associated
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with an incident or possib= le threat, the information
>>>> =A0 =A0 =A0 becomes a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 proactive defense for othe= rs that may include
>>>> =A0 =A0 =A0 mitigation options.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Incident Object Descri= ption Exchange Format
>>>> =A0 =A0 =A0 (IODEF) defines
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 an information framework t= o represent computer and
>>>> network
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 security incidents; IODEF = is defined in RFC 5070 and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 has been extended by RFC 5= 091 to support phishing
>>>> =A0 =A0 =A0 reports; RFC
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6484 provides a template f= or defining extensions to
>>>> IODEF.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Real-time Inter-network De= fense (RID) defines a
>>>> =A0 =A0 =A0 protocol to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 facilitate sharing compute= r and network security
>>>> =A0 =A0 =A0 incidents;
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RID is defined in RFC 6545= , and RID over HTTPS is
>>>> =A0 =A0 =A0 defined in RFC
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6546.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </intro>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The MILE WG is focused on = two areas, IODEF the data
>>>> =A0 =A0 =A0 format and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions to represent in= cident and indicator data
>>>> =A0 =A0 =A0 and RID,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the policy and transport f= or structured data. =A0With
>>>> =A0 =A0 =A0 respect to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IODEF, the working group w= ill:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Revise the IODEF documen= t to incorporate
>>>> =A0 =A0 =A0 enhancements and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions based on operat= ional experience; use by
>>>> =A0 =A0 =A0 Computer
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Security Incident Response= Teams (CSIRTs) and others
>>>> has
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exposed the need to extend= IODEF to support industry
>>>> =A0 =A0 =A0 specific
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions, use case speci= fic content, and
>>>> =A0 =A0 =A0 representations to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 associate information rela= ted to represented threats
>>>> =A0 =A0 =A0 (system,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 threat actors, campaigns, = etc.). =A0The value of
>>>> information
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sharing has been demonstra= ted and highlighted at an
>>>> =A0 =A0 =A0 increasing
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate through the success o= f the Information Sharing and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Analysis Centers (ISACs) a= nd the recent cyber security
>>>> =A0 =A0 =A0 Executive
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Order in the US. =A0Intern= ational groups, such as the
>>>> =A0 =A0 =A0 Multinational
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Association for Collaborat= ive Cyber Situational
>>>> =A0 =A0 =A0 Awareness (CCSA)
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 have been running experime= nts to determine what data
>>>> =A0 =A0 =A0 is useful to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exchange between industrie= s and nations to effectively
>>>> =A0 =A0 =A0 mitigate
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 threats. =A0The work of th= ese and other groups have
>>>> =A0 =A0 =A0 identified or
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 are working to develop dat= a representations relevant
>>>> =A0 =A0 =A0 to their use
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cases that may compliment/= extend IODEF or be useful to
>>>> =A0 =A0 =A0 exchange
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 using RID and related tran= sport protocols.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Provide guidance on the = implementation and use of
>>>> =A0 =A0 =A0 IODEF to aid
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 implementers in developing= interoperable
>>>> specifications.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 With respect to RID, the w= orking group will:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Define a resource-orient= ed approach to cyber security
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information sharing that f= ollows the REST
>>>> =A0 =A0 =A0 architectural style.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This mechanism will allow = CSIRTS to be more dynamic
>>>> =A0 =A0 =A0 and agile in
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 collaborating with a broad= er, and varying constituency.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Provide guidance on the = implementation and use of
>>>> =A0 =A0 =A0 RID transports
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 based on use cases. =A0The= guidance document will show
>>>> the
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relationship
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 between transport options = (RID + RID transport and
>>>> =A0 =A0 =A0 IODEF/RID +
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ROLIE)
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and may identify the need = for additional transport
>>>> =A0 =A0 =A0 bindings.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - RID may require modifica= tions to address data
>>>> =A0 =A0 =A0 provenance,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 additional
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 policy options, or other c= hanges now that there are
>>>> =A0 =A0 =A0 multiple
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interoperable implementati= ons of RFC6545 and
>>>> =A0 =A0 =A0 RFC6546. =A0With the
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RID implementations in the= open source community,
>>>> =A0 =A0 =A0 increased use and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 experimentation may demons= trate the need for a
>>>> revision.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <milestones>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </milestones>
>>>>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thank you!
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kathleen
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __________________________= ______________
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: mile-bounces@ietf.org
>>>> =A0 =A0 =A0 <mailto:mile-bounces@ietf.org> <mailto:mile-bounces@ietf.org>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [mile-bounces@ietf.org <mailto:mile-bounces@ietf.org>
>>>> =A0 =A0 =A0 <mailto:mile-bounces@ietf.org>] On Behalf
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Of Sean Turner [turners@ieca.com
>>>> =A0 =A0 =A0 <mailto:turners@ieca.com> <mailto:tu= rners@ieca.com>]
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Wednesday, May 01, 2= 013 9:04 PM
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: mile@ietf.org <mailto:mi= le@ietf.org>
>>>> =A0 =A0 =A0 <mailto:mi= le@ietf.org>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: [mile] re-charter= re-boot
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I'd like to propose a = significant re-write of the
>>>> proposed
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 charter. =A0I
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 think there's too much= history that's not really
>>>> =A0 =A0 =A0 needed any more and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 there's some repetitio= n that's unneeded. =A0I also think
>>>> =A0 =A0 =A0 it's a little
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 open ended wrt what's = actually going to get done.
>>>> =A0 =A0 =A0 Based on recent
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 experience, I have a stron= g feeling that the current
>>>> =A0 =A0 =A0 charter
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wouldn't
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 get through the process. >>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I'm proposing four sec= tions: intro, iodef-related
>>>> =A0 =A0 =A0 work, rid-related
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 work, milestones.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The intro should:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - explain what the WG does= : develop standards to do
>>>> foo.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - summarize what foo is. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - highlight existing RFCs = that are part of the space:
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IODEF: 5070/50= 91/6848 & RID: 6545/6546.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Then we talk about what dr= afts the WG will produce for
>>>> =A0 =A0 =A0 the two
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 topic areas.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 How about this (or somethi= ng like this):
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <intro>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Managed Incident Light= weight Exchange (MILE)
>>>> =A0 =A0 =A0 working group
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 develops standards to supp= ort computer and network
>>>> =A0 =A0 =A0 security
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 incident management; an in= cident is an unplanned event
>>>> =A0 =A0 =A0 that
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 occurs in an information t= echnology (IT)
>>>> =A0 =A0 =A0 infrastructure. An
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 incident could be a benign= configuration issue, IT
>>>> =A0 =A0 =A0 incident, an
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 infraction to a service le= vel agreement (SLA), a system
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compromise, socially engin= eered phishing attack, or a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 denial-of-service (DoS) at= tack, etc. =A0When an
>>>> incident is
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 detected, or suspected, th= ere may be a need for
>>>> =A0 =A0 =A0 organizations to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 collaborate. This collabor= ation effort may take
>>>> =A0 =A0 =A0 several forms
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 including joint analysis, = information dissemination,
>>>> =A0 =A0 =A0 and/or a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 coordinated operational re= sponse. =A0Examples of the
>>>> =A0 =A0 =A0 response may
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 include filing a report, n= otifying the source of the
>>>> =A0 =A0 =A0 incident,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 requesting that a third pa= rty resolve/mitigate the
>>>> =A0 =A0 =A0 incident,
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sharing indicators of comp= romise, or requesting that
>>>> =A0 =A0 =A0 the source
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be located. The Incident O= bject Description Exchange
>>>> =A0 =A0 =A0 Format
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (IODEF) defines an informa= tion framework to represent
>>>> =A0 =A0 =A0 computer
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and network security incid= ents; IODEF is defined in
>>>> =A0 =A0 =A0 RFC 5070 and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 has been extended by RFC 5= 091 to support phishing
>>>> =A0 =A0 =A0 reports; RFC
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6484 provides a template f= or defining extensions to
>>>> IODEF.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Real-time Inter-network De= fense (RID) defines a
>>>> =A0 =A0 =A0 protocol to
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 facilitate sharing compute= r and network security
>>>> =A0 =A0 =A0 incidents;
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RID is defined in RFC 6545= , and RID over HTTPS is
>>>> =A0 =A0 =A0 defined in RFC
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6546.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </into>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This working group does tw= o things IODEF and RID; we
>>>> =A0 =A0 =A0 should be clear
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 about that and then list t= he actual documents we're
>>>> =A0 =A0 =A0 going to produce
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that relate to each one. = =A0For the list of deliverables
>>>> =A0 =A0 =A0 it looks like
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 there's three 5070bis,= a reference/guidance draft,
>>>> and a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 resource-oriented indicato= r exchange?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Questions:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are the GRC and Forensic d= rafts dead-dead? =A0I assume
>>>> =A0 =A0 =A0 they'd not be
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 included in the milestone = list.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is there going to only be = one 5070bis draft or will
>>>> =A0 =A0 =A0 there be a
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5070bis +
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 other optional extension d= rafts? =A0I assume it's just a
>>>> =A0 =A0 =A0 5070bis
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 based on
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the milestones but thought= I'd ask.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are we only extending IODE= F based on use or is there
>>>> =A0 =A0 =A0 something
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else we
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 need to consider?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 How about something along = the lines of (need some help
>>>> =A0 =A0 =A0 filling
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in the
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 blanks):
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <iodef>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 With respect to IODEF, the= working group will:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Revise the IODEF documen= t to incorporate
>>>> =A0 =A0 =A0 enhancements and
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions based on operat= ional experience; use by
>>>> =A0 =A0 =A0 Computer
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Security Incident Response= Teams (CSIRTs) and others
>>>> has
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exposed the need to extend= IODEF to support x, y, z
>>>> =A0 =A0 =A0 (need to have
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 some idea what's missi= ng) base on a, b, c (need to
>>>> =A0 =A0 =A0 know a bit
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 more about why stuff is mi= ssing did something new pop
>>>> =A0 =A0 =A0 up?).
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Provide guidance on the = implementation and use of
>>>> =A0 =A0 =A0 IODEF to aid
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 implementers in developing= interoperable
>>>> specifications.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </iodef>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For RID:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are we also doing defining= guidance for RID as well or
>>>> =A0 =A0 =A0 is that
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 incorporated in the IODEF = guidance?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is RID itself going to be = untouched and we're just
>>>> =A0 =A0 =A0 producing a new
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "transport"?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is it just for indicators = or is it for the whole
>>>> =A0 =A0 =A0 incident? =A0Or has
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "indicators" ove= r taken "incident"?
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <rid>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 With respect to RID, the w= orking group will:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Define a resource-orient= ed approach to cyber security
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information sharing that f= ollows the REST
>>>> =A0 =A0 =A0 architectural style.
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This mechanism will allow = CSIRTS to be more dynamic
>>>> =A0 =A0 =A0 and agile in
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 collaborating with a broad= er, and varying constituency.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </rid>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <milestones>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 These looked fine, but I&#= 39;d like some actual dates for
>>>> =A0 =A0 =A0 the TBDs ;)
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 </milestones>
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spt
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __________________________= _____________________
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mile mailing list
>>>> =A0 =A0 =A0 mile@ietf.org= <mailto:mile@ietf.org> <= mailto:mile@ietf.org>
>>>> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mile >>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 __________________________________= _____________
>>>> =A0 =A0 =A0 =A0 =A0 =A0 mile mailing list
>>>> =A0 =A0 =A0 mile@ietf.org= <mailto:mile@ietf.org> <= mailto:mile@ietf.org>
>>>> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________
>>> mile mailing list
>>> mile@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile



--
=

John P. Field |=A0Security Architect |=A0Pivotal

Direct: (908) 962-3394 | jfield@gopivotal.com=A0 <= /span>

3D"cid=

goPivotal.com
--001a11c2029acda85e04de94f55d-- --001a11c2029acda86004de94f55e Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 5b082271dab5eed9_0.1 iVBORw0KGgoAAAANSUhEUgAAAFIAAAAaCAYAAAAkJwuaAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAABs9JREFUaAXtWX1oFEcUf2/3voQW24ggBAQhIAj5SylY hELEIggVQa4QPcFWkygUi1CwtFSEglIptFSaxI8SEiNNEKTSP6SCIA0UpKIQGioECoIghF4UCt4l t/v6m5n9vL29XBobi83A7cy8ee/NzG/nfcweiwitlKUjkFEq+FCpg9hdnVBn8ZwMXp5M0CMEPlRs I85u0CRrfkYGxx9Ghl/KJh/et1lvjMmR86P3VVsDiedXxPauRrvmIweIRJ5ibIjmqV8ujTyI8dm5 nWRZo4Zm9aM+Ght/GTsZ+1e9LYPLa6pttbRP5tXEfIxy/DuAPd2SzAtk4t7ieu7r3sp9+zct1zLM iYzOJnIJxn5Hk9hdS8Lr0d9FTO0e2wnuOzAtA8PgQ7FkGif2vG6LTOj6BT74SOlbsgpH9BJcUdYx tRzLaQTkLRkcuRKdnIvFHLUVhgHmu5rOcgK1BlL6RxXoBvio0P+snQSyAQAyPj7H7xU/oFx+L0zc xgntUOajAosOVBnu0mJSm5LBKxN8sLiO8oV3AlUO3ZQLw38E/boGHz6wgWzaocmOc1cujN6tYyGt s5BdTw7N+Q6+nifRt3gbrMeJ0WuVq3JxvBylYS9wXZlNCBmdOCwbSMis1a09ILc2Wc8flfXbLQGp mOW78RksSgWdNi1sZdehfki2vAFwBzWNbRVsJiiXQRZAhqYGMnQGz49Vs2HJUA/o6pSj2NtNjddV LNr0ev44WfwRFQprzTDoKgCS3CJXPlwgq+jGOrp9fUY+9wvqAEju3Q+ewjfgM/tSTKw5sRTAgx/2 /Yik8mazjKS1YKN0K/MmCVOkGs5GWhH+C0N34TvnNItIw4wgFJe9XnuGnlZuq7Y+gW35ewDxC3QN iB6TqWAFzPe4r3Q8Rl5Ex/hTZBwBiPIM4rAGiWcmOj7kwr03mKPlE0lrCurNwqxRFEDW/LRuN3h4 prcFJ0elRXjj3KkiqAxcTjh+nIhOpE8dRo1chRsxL6hQ+B60Tk/9bZjYpzRbu0+v5tspI3ug8xR+ eLn0JcCckoGRGx5vWCHYwN8rK0kUuJMuyrAJSiqNYTko/ZevRRlxEn8GyNuitLR2UyC173CzHdho FxKlz4IzzzwmA+PKzJsXR8bIZmNaQspnJoCE3ogvdcaUQgCzAyC9pZULXEW5sj0AmEidljPcU5rC a/1B8zB/jjoJpB5MedgCED0bFgA+EAcxRSqVnGra2MyPSCOekEo+tXnxK1qLyCT9WTmaqjE68KR6 00vmsWarsXkLm0yA6DE9qU144jsDNQ6djIAYkOX8yHV0/KC0WbuCYLSFBrM5aUKP4GdjWUoL0gmW VCATnCTwe9JP1erb2JjygQsW8D3DyVIbRpGtiPwxX6ciP8aN+boRsyZC7uoVp5J+RRU3HMtk/TzX l0ytdRAjUsESL7jOH6ZKNR9IN22GqYiahJECyGNyqxOtpAGJ6VyYt8UlAGZTFukTUcRn5f3TCLIx a09+VaAnSyZgBYRIg/lZ0LMklAmIKY3XyViXGhYKdaSwt0JOBVL6R861omBBntnqDSTzZR0ZmZR5 h0AyG/8oSKNmayotWZ4yC/DWBFOpgLXksgjT/mdzGf8mJhoydcGs9MkxPk22Gq1yLeYHmcNAZkVO T2IJ+AbgF5Ny+b2mNeaaC313xI00lWo++K8D6U0/ZmpeRW05E3RyeZXCeOmUczW2TKEwtXKyXbEx r2P8HC4Dqog4xPOpNydPpL7yrrW8kXu7W0px6hVE+8sDZLl6C5PO6InZ2mNqL+2BWatrZXRRNC9X NDiKaNmn64OU5m3LfQL/3eHJXcetw5xioTAQMqX7TZEhT1bNcVFfdQPC4hupPnLxqtIllNniFoFT hwQYtxzu2Vci2zJ5Ikn8NEKN+uaJ9GsIzffhW9txb/+Ne0tn0b5PrrsOsrjzW17+iduIyMlwdgRH vzCdgp6NflfXNTorF0emaXZuDJeMHtCwDt5IWbmHNd5B8FFfs84tcPWMqVSd5TmRaiYsDj+YIPya bQ9j8avQh6+qfq2GE6VcPYpx/YUJY2t1Lsv8kyfrByncgWl3bNPlCtwIPu3pgtyXuSf2sx2d9mif 7FZ2g9dLz1SerK+dAFd9Olxc8U+kmtgkt8zlRakw/EbWlYdpsup6iJN4ELckfCDQQQKmrq5wjf+a 0AGB6BD81xC+3p+A3k2Qw5cZgM88SS7Ss9nKGfCFpgwm1Ud+uoU4dwyAtIPX/C3gLywSlDx3sFv7 SLbhbwVffyzktY4X7HT6Z9yDE0m1QqyCuXnlzy8f4aXVy2faS1vnf156Bcjn9IpWgFwB8jkh8JzU /A3WyVI+PC3NMwAAAABJRU5ErkJggg== --001a11c2029acda86004de94f55e-- From turners@ieca.com Thu Jun 13 08:43:03 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1512F21F9980 for ; Thu, 13 Jun 2013 08:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFiI4bzSxzIL for ; Thu, 13 Jun 2013 08:42:58 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.16.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1045421F996A for ; Thu, 13 Jun 2013 08:42:58 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 58F2C79318590; Thu, 13 Jun 2013 10:42:46 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 4078F79318531 for ; Thu, 13 Jun 2013 10:42:46 -0500 (CDT) Received: from [173.73.135.101] (port=58961 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Un9ft-0000nC-Dc for mile@ietf.org; Thu, 13 Jun 2013 10:42:57 -0500 Message-ID: <51B9E880.5060402@ieca.com> Date: Thu, 13 Jun 2013 11:42:56 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mile@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:58961 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [mile] mile charter status X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:43:03 -0000 The updated charter is currently under IESG review. That takes a week but because of when I started the review it doesn't come up for discussion until the IESG 6/27 telechat. After that I'm going to ask that it go for external review, which is where the charter is sent out to a number of SDOs. It'll then re-appear on the next IESG formal telechat which is on the 7/11 telechat. You can follow along using the following links: https://datatracker.ietf.org/doc/charter-ietf-mile/ spt From daniel.piggott@switch2it.co.uk Fri Jun 14 05:35:27 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67921F98AD for ; Fri, 14 Jun 2013 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.839 X-Spam-Level: ** X-Spam-Status: No, score=2.839 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwHzL6LdGtvQ for ; Fri, 14 Jun 2013 05:35:21 -0700 (PDT) Received: from mail50.extendcp.co.uk (mail50.extendcp.co.uk [79.170.44.50]) by ietfa.amsl.com (Postfix) with ESMTP id 961A621F9298 for ; Fri, 14 Jun 2013 05:35:20 -0700 (PDT) Received: from switchtx.gotadsl.co.uk ([62.3.238.89] helo=88181134W) by mail50.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) id 1UnTDp-00035o-VJ; Fri, 14 Jun 2013 13:35:18 +0100 From: "Daniel Piggott" To: "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , , References: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> Date: Fri, 14 Jun 2013 13:30:37 +0100 Organization: Switch2IT Ltd Message-ID: <027901ce68fa$f9eb4060$edc1c120$@piggott@switch2it.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027A_01CE6903.5BAFA860" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-gb Thread-Index: Ac5i40Efq7jEmbbOQliqLxTXBAUoFgAGxBJw X-Antivirus: avast! (VPS 130613-1, 13/06/2013), Outbound message X-Antivirus-Status: Clean X-Authenticated-As: daniel.piggott@switch2it.co.uk X-Mailman-Approved-At: Fri, 14 Jun 2013 08:07:03 -0700 Subject: Re: [mile] Request for draft reviews - review of FC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: daniel.piggott@switch2it.co.uk List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 12:35:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_027A_01CE6903.5BAFA860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, is there any update to my response to the document reviewed below? Sent 6th June 22:57? Kathleen informed me it only made part of the distribution list. Thks Daniel Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Having looked through this draft and the example 11. Appendix III: An XML Example Would these be worth considering in the IODEF incident schema? An incident classification level or assurance level for each incident? Mac address of reporting device? A field for whether any device is virtual or physical? A hash of each incident raw data? Memory address space field (as you have PID)? NTP Time source of the incident device? In the example above in Appendix III below should the service IP protocol be 4? System category="target">
192.0.2.16/28
 80 And one last question, if the receiving node getting the alerts via IODEF goes offline From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: 06 June 2013 19:26 To: Moriarty, Kathleen; mile@ietf.org; 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com) Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hi Paul, Good starting point. Some comments and nits below from my first pass. There should be more when I review again. I remember sometime in the past there was a discussion about what is an incidents if that should be updated in the 5070. I see that in your draft an incident is used as it was in 5070. I was just wondering if we had reached a consensus on it. I also didn't see "uid" and "set id" definitions in the draft. I don't see the EMailDetails class described in the document. Nits: - Should "This document contains changes with respect to its predecessor RFC5070:" be bulleted? - The list in "This class will contain indicators from the list below " is not exactly below. The same for "the following included indicators are ones commonly used ". And the same for me occurrences of "following" in this section - I am not sure if we want to keep the "

Hello, is = there any update to my response to the document reviewed below? Sent = 6th June 22:57? Kathleen informed me it only made part of the = distribution list.

Thks

Daniel=

 =

Structured = Cybersecurity Information draft (close to = final):

http://data= tracker.ietf.org/doc/draft-ietf-mile-sci/

 = 

Having looked through this =
draft and the example  11.  Appendix III: An XML =
Example

 =

Would = these be worth considering in the IODEF incident schema?

 

An incident classification level or assurance level for each = incident?

Mac address of reporting device?

A field for whether any device is virtual or = physical?

A hash of each incident raw data?

Memory address space field (as you have PID)?

NTP Time source of the incident device?

 

In the example above in Appendix III below should the service IP = protocol be 4?

 

System = category=3D"target">

          = <Node>

            = <Address = category=3D"ipv4-net">192.0.2.16/28</Address>

          = </Node>

          <Service = ip_protocol=3D"6">

            = <Port>80</Port>

          = </Service>

 

And one last question, if the receiving node getting the alerts via = IODEF goes offline

 

From:= Panos = Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: 06 = June 2013 19:26
To: Moriarty, Kathleen; mile@ietf.org; = 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com)
Subject: Re: = [mile] Request for draft reviews - review of = FC5070-bis

 

 

Hi Paul,

 

Good starting point. Some comments and nits below from my first = pass.

There should be more when I review again.

 

I remember sometime in the past there was a discussion  about = what is an incidents if that should be updated in the 5070. I see that = in your draft an incident is used as it was in 5070. I was just = wondering if we had reached a consensus on it.

 

I also didn’t see “uid” and “set id” definitions in the draft.

 

I don’t see the EMailDetails class described in the document.

 

Nits:

- Should “This =
document contains changes with respect to its =
predecessor

      RFC5070:” be bulleted?

- The list in “This class will contain indicators =
from
      the list below =
” is not exactly below. The same for “the
      =
following included indicators are ones commonly used ”. And the same for me occurrences of “following” =
in this section
- I am not sure if we want to keep the “<!-- CHANGE:” comments in the draft
- there are some XML complexType like “SoftwareType” that are described as classes in the comments IODEF schema, =
but these are not classes.
 
I aqlso see that you will have usecases-examples in this doc, so =
mayne I will remove mine from the guidance =
document.
 

Rgs,

Panos

 

 

 

From:= mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] = On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, = 2013 2:13 PM
To: mile@ietf.org
Subject: = [mile] Request for draft reviews

 

Greetings!<= o:p>

 =

We have = had a number of documents updated since the last meeting.  Thank = you to all of the editors for making the requested changes!  The = current list of drafts up for review (including those that will be a = part of the WG after the charter update) = include:

 =

RFC5070-bis= (IODEF Revision):

 =

Draft on = IODEF Guidance:

(input = from experience, real use cases, and draft review will be = helpful)

 =

Structured = Cybersecurity Information draft (close to = final):

=

 =

IODEF = Enumeration Reference Format:

 =

Resource-Or= iented Lightweight Indicator Exchange (ROLIE): =

 =

Please = take some time to review the drafts and provide feedback to the = list.  It would be helpful if we can iterate on most of them prior = to the next meeting.  A couple of the drafts are very close to = being done.  The list of current drafts and published RFCs can be = found at the following link:

 =

We will = follow up soon on the charter update as = well.

 =

Thank you = all in advance!
Kathleen

 =

 =

------=_NextPart_000_027A_01CE6903.5BAFA860-- From rdd@cert.org Fri Jun 14 11:19:40 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47D021F8EEA for ; Fri, 14 Jun 2013 11:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BGEip7OzZLg for ; Fri, 14 Jun 2013 11:19:37 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id C672D21F85B8 for ; Fri, 14 Jun 2013 11:19:36 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r5EIJZVp027306 for ; Fri, 14 Jun 2013 14:19:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1371233975; bh=YrSIJp76jD+rfZ4HBTGQPV706RaLV4JWaNG+5xMte9Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=XKSiPHLIBM4IdI6zuC9MDGiPIopQUqA/EQ3e401E99oaMJjqlhmATIIw5L1q6/aPz YVUzTKb+T+5uDOvKr05iOByuq03uRZX7zuG6z7SAaJwgz+CqbLs6nFzd/2dkBbfnFO yCLhd9ZRjgf23y8KWqVW73s0bmanIqh/tzfq/obw= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r5EIJfrY001345 for ; Fri, 14 Jun 2013 14:19:41 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 14:19:35 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Outstanding tasks for 5070-bis listed in trac Thread-Index: Ac5pKeZl6KEZqqs9Qjq1dSpDD7wmPQ== Date: Fri, 14 Jun 2013 18:19:34 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C2BC10@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Outstanding tasks for 5070-bis listed in trac X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:19:41 -0000 In the interest of organizing the discussion around the 5070-bis draft, out= standing items that require further discussion or action have been added to= MILE's trac instance -- http://trac.tools.ietf.org/wg/mile/trac/report/1. Currently, in the queue are the following actions: #1 Fix internationaliztion=20 #2 Add better reference (citation) to RecordPattern@type=3Dregex #8 Review completeness of HistoryItem@action=20 #9 Review completeness of @restriction=20 #10 Review completeness of Impact@type=20 #4 Add support for domain name meta data=20 #11 Add geolocation representation to Node/System #13 Review completeness of recent additions in 5070-bis=20 #3 Review implementation of extending enumerated values=20 #5 Review all requirements key words (RFC 2119) #6 Harmonize the specification for Reference with other WG activity=20 #7 Review completeness of NodeRole@category=20 #12 Define clear scope for the core data model relative to other WG docume= nts and future extensions=20 Most if not all need to be brought to the mailing list for discussion. If = using trac turns out to be useful to the group, we'll also have to figure o= ut some conventions for the associated work-flow. If you think there is a = missing non-editorial issue that requires consideration, by all means let i= t be known. Roman From kathleen.moriarty@emc.com Sun Jun 16 21:43:13 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212C621F9951 for ; Sun, 16 Jun 2013 21:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ0IeWrebRhc for ; Sun, 16 Jun 2013 21:43:05 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E279721F995E for ; Sun, 16 Jun 2013 21:42:56 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5H4grvF011486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jun 2013 00:42:53 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Mon, 17 Jun 2013 00:42:44 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5H4ghAN011608 for ; Mon, 17 Jun 2013 00:42:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Mon, 17 Jun 2013 00:42:43 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Mon, 17 Jun 2013 00:42:37 -0400 Thread-Topic: Workshop on Security Incident Information Sharing Thread-Index: Ac5rFRrqKKE4XjpfT1GQNrZBq6Wrvw== Message-ID: <66B937CC-F190-405B-BCB4-160A8EC13DA6@emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66B937CCF190405BBCB4160A8EC13DA6emccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Workshop on Security Incident Information Sharing X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 04:43:15 -0000 --_000_66B937CCF190405BBCB4160A8EC13DA6emccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCldlIHdvdWxkIGxpa2UgdG8gaW52aXRlIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0 aGUgdXBjb21pbmcgd29ya3Nob3Agb24gU2VjdXJpdHkgSW5jaWRlbnQgSW5mb3JtYXRpb24gU2hh cmluZyAoU0lJUykuICBJdCBpcyBzY2hlZHVsZWQgb24gSnVseSAyNiwgMjAxMyBpbiBCZXJsaW4s IEdlcm1hbnksIHRoZSBGcmlkYXkgYmVmb3JlIHRoZSBuZXh0IElFVEYgbWVldGluZy4NCg0KRGV0 YWlscyBhbmQgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBvbiB0aGUgZm9s bG93aW5nIHdlYiBzaXRlOg0KDQpodHRwOi8vc2lpcy5yZWFsbXY2Lm9yZy8NCg0KV2UgaG9wZSB0 byBzZWUgeW91IHRoZXJlIGZvciBhIHByb2R1Y3RpdmUgd29ya3Nob3AuDQoNCkJlc3QgcmVnYXJk cywNCkthdGhsZWVuICYgQnJpYW4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0K --_000_66B937CCF190405BBCB4160A8EC13DA6emccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgc3R5bGU9 Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgIj5IZWxsbyw8L2Rpdj48ZGl2IHN0eWxl PSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9 Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgIj5XZSB3b3VsZCBsaWtlIHRvIGludml0 ZSB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIHVwY29taW5nIHdvcmtzaG9wIG9uIFNlY3VyaXR5 IEluY2lkZW50IEluZm9ybWF0aW9uIFNoYXJpbmcgKFNJSVMpLiAmbmJzcDtJdCBpcyBzY2hlZHVs ZWQgb24gSnVseSAyNiwgMjAxMyBpbiBCZXJsaW4sIEdlcm1hbnksIHRoZSBGcmlkYXkgYmVmb3Jl IHRoZSBuZXh0IElFVEYgbWVldGluZy48YnI+PGJyPkRldGFpbHMgYW5kIHJlZ2lzdHJhdGlvbiBp bmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgb24gdGhlIGZvbGxvd2luZyB3ZWIgc2l0ZTo8L2Rpdj48 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87ICI+PGJyPjwvZGl2Pjxk aXY+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7ICI+PGEgaHJl Zj0iaHR0cDovL3NpaXMucmVhbG12Ni5vcmcvIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVl IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3Rv cnMtcmVzdWx0PSIwIiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+aHR0cDovL3NpaXMucmVhbG12 Ni5vcmcvPC9hPjwvZm9udD48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldlIGhvcGUgdG8gc2Vl IHlvdSB0aGVyZSBmb3IgYSBwcm9kdWN0aXZlIHdvcmtzaG9wLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+S2F0aGxlZW4gJmFtcDsgQnJpYW48L2Rpdj48 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87ICI+PGJyPlNlbnQgZnJv bSBteSBpUGhvbmU8L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_66B937CCF190405BBCB4160A8EC13DA6emccom_-- From takeshi_takahashi@nict.go.jp Mon Jun 17 23:13:59 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6996621F9A23 for ; Mon, 17 Jun 2013 23:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zbp3X4ohuxz for ; Mon, 17 Jun 2013 23:13:54 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id B307721F9A44 for ; Mon, 17 Jun 2013 23:13:46 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r5I6DbRo017417; Tue, 18 Jun 2013 15:13:37 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r5I6Db87011710; Tue, 18 Jun 2013 15:13:37 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r5I6DboF011707; Tue, 18 Jun 2013 15:13:37 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 31FD02C2DE; Tue, 18 Jun 2013 15:13:37 +0900 (JST) Received: from VAIO (unknown [133.243.119.109]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 28E0316B52; Tue, 18 Jun 2013 15:13:37 +0900 (JST) From: "Takeshi Takahashi" To: , "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , , References: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> <027901ce68fa$f9eb4060$edc1c120$@piggott@switch2it.co.uk> In-Reply-To: <027901ce68fa$f9eb4060$edc1c120$@piggott@switch2it.co.uk> Date: Tue, 18 Jun 2013 15:13:37 +0900 Message-ID: <001101ce6bea$f89a8ac0$e9cfa040$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGrfDo3oosvrhqkCdnIlKmQHVtubgJFBsa4mW6okEA= Content-Language: ja Subject: Re: [mile] Request for draft reviews - review of FC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:13:59 -0000 Hi Daniel and all, Though the discussion is on IODEF-bis rather than IODEF-SCI, I hope you = do not mind sharing my opinion here :) > Would these be worth considering in the IODEF incident schema? I agree. > An incident classification level or assurance level for each incident? I feel that the assurance or trustworthiness of the information is = something we could consider outside IODEF document. The sender can describe "Confidence" instead of the trustworthiness. (E.g., I cannot say that I myself is very trustworthy sender of the information, but I can say that I am confident on the information. = Receiver can judge whether he/she trust me or not.) > Mac address of reporting device? I think it is good idea. The "person" who reports IODEF document could be a machine, such as IDS. For instance, we could reconsider the structure of "Contact" class. > A field for whether any device is virtual or physical? I agree. > A hash of each incident raw data? > Memory address space field (as you have PID)? I agree on the usefulness of these information. Instead of extending IODEF itself, we could consider using external = schema for that purpose. These could be then embedded into IODEF document through the use of IODEF-SCI. > NTP Time source of the incident device? I agree. > In the example above in Appendix III below should the service IP = protocol be 4? I've used the example described in the RFC5070, and I didn't realize = this point. Thank you for pointing it out. Kind wishes, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Daniel Piggott Sent: Friday, June 14, 2013 9:31 PM To: 'Panos Kampanakis (pkampana)'; 'Moriarty, Kathleen'; mile@ietf.org; Paul.Stoecker@rsa.com Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hello, is there any update to my response to the document reviewed = below? Sent 6th June 22:57? Kathleen informed me it only made part of the distribution list. Thks Daniel Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Having looked through this draft and the example=A0 11.=A0 Appendix III: = An XML Example Would these be worth considering in the IODEF incident schema? An incident classification level or assurance level for each incident? Mac address of reporting device? A field for whether any device is virtual or physical? A hash of each incident raw data? Memory address space field (as you have PID)? NTP Time source of the incident device? In the example above in Appendix III below should the service IP = protocol be 4? System category=3D"target"> =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
192.0.2.16/28
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 80 =A0=A0=A0=A0=A0=A0=A0=A0=A0 And one last question, if the receiving node getting the alerts via = IODEF goes offline From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 Sent: 06 June 2013 19:26 To: Moriarty, Kathleen; mile@ietf.org; 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com) Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hi Paul, Good starting point. Some comments and nits below from my first pass. There should be more when I review again. I remember sometime in the past there was a discussion=A0 about what is = an incidents if that should be updated in the 5070. I see that in your = draft an incident is used as it was in 5070. I was just wondering if we had = reached a consensus on it. I also didn=92t see =93uid=94 and =93set id=94 definitions in the draft. I don=92t see the EMailDetails class described in the document. Nits: - Should =93This document contains changes with respect to its = predecessor =A0=A0=A0=A0=A0 RFC5070:=94 be bulleted? - The list in =93This class will contain indicators from =A0=A0=A0=A0=A0 the list below =94 is not exactly below. The same for = =93the =A0=A0=A0=A0=A0 following included indicators are ones commonly used = =94. And the same for me occurrences of =93following=94 in this section - I am not sure if we want to keep the =93

Hi Adam,<= /span>

 

The= -02 version of this draft was definitely useful, and it’s expired, s= o

a new version would be a good idea = ;-).  This message is a bit long and

detailed, but IANA considerations are full of details ...

 

= >= Also, are there good IANA-related RFCs I can look at to tighten this<= /o:p>

> draft up a bit? What I was inten= ding for the IANA section is to convey

 

That intent is fine, as good IANA considerations text for regis= try creation

does exactly that. = At the risk of blowing my own horn, here’s a recent RFC

that is entirely IANA Considerations:<= /span>

 

&nb= sp;     http://www.rfc-editor.org/rfc/rfc6580.txt

<= p class=3DMsoNormal> 

The IANA consi= derations text in Take’s SCI draft is another reasonable

example to work from.  Also, RFC 2434 has be= en replaced by RFC 5226.

 <= /o:p>

 

Here are a few specific suggestions on the IANA considerations text:

 

[1] Change this introductory sentence:

OLD

    =   Registration request for the IODEF Enumeration Reference Format:

NEW

END

 

That s= hould resolve the confusion that Panos noted.

 

[2] This sentence see= ms out of place:

 

      The registry is int= ended to enable enumeration value additions to

      attributes of a given reference cl= ass of an IETF standard, for

 &n= bsp;    example, the Reference class of the IODEF schema.

 

I think it would be better placed in Section 2.3, which already co= vers

this, so just deleting that sent= ence may suffice.

 

[3] This text seems vague:

<= p class=3DMsoNormal> 

      Note th= at

      certain name re= quests should not be permitted as either Full Name

    &nb= sp; example, the following list should not be permitted: foo, bar,

      example.com.  It is a= nticipated that the Expert Review process

 &= nbsp;    will flag any additional undesired Full Name or Abb= reviation

      issues.<= o:p>

 

There should be some additional explanation of what should not be = permitted

and why, but that approach = seems problematic - it could easily get long and

will inevitably miss some things that we’d like to exclud= e.  Moreover, I’m

not even= sure about the excluded examples - what if someone (cleverly) comes

up with a widely used Fraud Observable Obje= cts format, would we really

want to d= isallow FOO :-) ?

 

It may be better to leave this to the<= /span>

judgment of the Designated Expert, so I’d = suggest turning this approach around

= - remove the above text and instead write some additional guidance to the

designated expert on what the abbrevia= tion should represent.

 

 

On the proposed new formats:

&n= bsp;

     =     Abbreviation: The abbreviation of the enumeration as a s= tring

from= the ASCII character set.  An abbreviation may be an initialism

or acronym, is f= ree-form, but is limited to between two and five

upper-case characters meeting the re= gular expression: ^[A-Z]{2,5}$

&= nbsp;

      =    Version: The version of the enumeration as a string using majo= r

and mino= r dotted notation meeting the regular expression as follows:

=

^[1-9]+\.[0-9]+$

 

I̵= 7;d suggest using ABNF rather than regular expressions - see RFC 5234<= /o:p>

(http://www.rfc-editor.org/rfc/rfc5234.txt) including the c= ore rules in

Appendix B.1 (e.g., DIGI= T).  OTOH, the regexp formats are more compact -

=

if they are retained, a reference needs to be cited that d= efines the

regexp notation used.=

 

Several questions:

 

- Is the limitation to ASCII ok?  It= 217;s certainly the most straightforward

approach, as use of 7-bit ASCII avoids a pil= e of Unicode issues,

but are there any important existing or likely specs whose<= /o:p>

acronyms can= 217;t be expressed in ASCII?

 

[Take - do = you know of any spec that is likely to need non-ASCII characters=

in an IODEF reference?]

- Will 5 charac= ters always be enough?  All the current examples fit, but

      what about clever = future acronyms that use more?

&= nbsp;

- Is the restriction to upper case o= k?  Same concern about current examples

      vs. future, but like the ASCII limi= tation, always upper case eliminates

=       case conversion concerns (Warning: Unicode c= ase conversion is a

complex area that should be avoided if possible).

 

- Is th= e limitation of version to major.minor (x.y) is overly restrictive?

Sooner or later= there will be 3 or 4 element version

      numbers when someone needs to make a really= small tweak/fix.  Also,

 &= nbsp;    what happens when someone decides to number somethi= ng as 4.3A

    &n= bsp; instead of adding another dotted element?

 

Overall, I’d s= uggest as little as we can get away with for version format

restrictions, as the spec authors who choose version= s probably won’t have

IODEF in = mind when they do so.

 

I also wonder how Version is going to be used= - would it be:

 

- For display only?=

- For exact ma= tch against the version that the IODEF

recipient is using?

- For more detailed comparison (e.g= ., “this or later”,

“same major version”)?

 

The first two use cases suggest no formatting restrictions, but th= e third use

case requires that versio= n be parseable - is that necessary?

<= o:p> 

As a strawman for Abbreviation,= I’d suggest:

 

Stay with upper ca= se ASCII (avoids Unicode, avoids string miscompares

courtesy of case-sensitive compa= rison instead of case-insensitive).

Allow longer strings, e.g., up to 20 characters.<= o:p>

Add guidan= ce to designated expert to favor short strings (i.e., acronyms).=

 

I&= #8217;d add a sentence to Section 2 to say that the avoidance of string mis= compares

caused by case-sensitive com= parison is the reason for upper case ASCII.

 

Thanks,
= --David

 

From: mile-bounces@ie= tf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis = (pkampana)
Sent: Thursday, June 06, 2013 3:42 PM
To: Ad= am Montville; mile@ietf.org; Adam Montville
Subject: Re: [mile] R= equest for draft reviews - review of IODEF Enumeration Reference=

 

You probably have seen this http://www.ietf.org/rfc/rfc2434.txt but I am point= ing it out anyway

&nb= sp;

 

From: Adam Montville [mailto:Adam.Montvil= le@cisecurity.org]
Sent: Thursday, June 06, 2013 1:39 PM
T= o: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org; Adam= Montville
Subject: RE: [mile] Request for draft reviews - review= of IODEF Enumeration Reference

 

Thank you!&nb= sp; I’ll make the changes you recommend.

 

Also, are there good IANA-related RFCs I can look at to tighten this draf= t up a bit?  What I was intending for the IANA section is to convey bo= th what the registry contains and the format of each element therein.<= /o:p>

 

If there’s a better way to do this, let̵= 7;s do it.

 

Adam

 

 

Hi Adam,

=  

I think this= is close to being done. I had reviewed in the past and the registry format= is as we had all agreed.

= I did a fresh review and had some minor nits and suggestions, and some conf= usion for the IANA considerations section.

 

- maybe rephrase &=
#8220;but one that seems the most approp=
riate at this point is to...” to “but the most appropriate at this point is to...”<=
o:p>
 
- “especially enumerations such =
as
   CEE=
, CVE, CCE” maybe put informative references for CEE, C=
VE and CCE?
 
- “Where id_type is =
an IANA-registered type having the form...” I am propos=
ing to rephrase the paragraph a little to avoid the “And where…=
”
“The format of the ReferenceName MUST follow the form of
    &nbs=
p; id_type:version:id
   where id_type is an IANA-registered type having the form
   &nb=
sp;  <Abbreviation>
   The version is an IANA-registered type having the =
form
  &n=
bsp;   <Version>
   The id is the actual enumeration identifier stri=
ng.”
 
- In section =
“4  IANA Considerations”, it is not very clear to me what each paragraph is trying t=
o convey. It this section trying to describe the IANA registry or the forma=
t of a registry update request? To me it seems it is mostly the former with=
 some info on the latter.  
Should =
the “Name of the Registry: "E=
numeration Reference Type Identifiers"” be in the =
“Fields to record in the registry:=
 ”? 
Does the paragr=
aph “The registry is intended to e=
nable enumeration value additions...” describe what the=
 IANA registry represents or should it be in the registry request for a new=
 value?
 
Rgs,
Panos
 
 
 
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of <=
/b>Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To=
: mile@ietf.org
Subject:=
 [mile] Request for draft reviews
 
Greetings!<=
/span>
 
<=
p class=3DMsoNormal>We have had a number of documents updated since the last meeti=
ng.  Thank you to all of the editors for making the requested changes!=
  The current list of drafts up for review (including those that will =
be a part of the WG after the charter update) include:
 
RFC5070-bis (IODEF Revision):
 
=

Draft on IODEF Guidance:
(input from experience, real use cases, and draft review wil=
l be helpful)

 

Structured Cybersecurity Information draft (close to final):<= /span>

 

IODEF Enumeration Reference Format:

 

Resource-Oriented Lightweight Indicator Exchange (ROLIE): =

 

Please take some time to review the d= rafts and provide feedback to the list.  It would be helpful if we can= iterate on most of them prior to the next meeting.  A couple of the d= rafts are very close to being done.  The list of current drafts and pu= blished RFCs can be found at the following link:

 

We will follow u= p soon on the charter update as well.

 

Thank you all= in advance!
Kathleen

&nbs= p;

 


...

This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete th= e message and any attachments.

= --_000_8D3D17ACE214DC429325B2B98F3AE712982651F2MX15Acorpemccom_-- From Adam.Montville@cisecurity.org Mon Jun 24 08:55:39 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3121E811E for ; Mon, 24 Jun 2013 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtYLs0XGGU0A for ; Mon, 24 Jun 2013 08:55:32 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) by ietfa.amsl.com (Postfix) with ESMTP id 847EE21E80E9 for ; Mon, 24 Jun 2013 08:55:32 -0700 (PDT) Received: from [216.82.250.179:49283] by server-12.bemta-12.messagelabs.com id D5/84-24760-3FB68C15; Mon, 24 Jun 2013 15:55:31 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-13.tower-210.messagelabs.com!1372089325!8019819!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 22950 invoked from network); 24 Jun 2013 15:55:26 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-13.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2013 15:55:26 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 11:55:15 -0400 From: Adam Montville To: "Black, David" , "mile@ietf.org" Thread-Topic: [mile] Request for draft reviews - review of IODEF Enumeration Reference Thread-Index: Ac5iywbBL2OPl7oFTvaNQKS+LaneQQAET99QAAROS4ACTLzOYAE0tT1Q Date: Mon, 24 Jun 2013 15:55:14 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6700607@CISEXCHANGE1.msisac.org.local> References: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> <05BCCEB107AF88469B9F99783D47C1D66F2D3B@CISEXCHANGE1.msisac.org.local> <1C9F17D1873AFA47A969C4DD98F98A753C8B6E@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712982651F2@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712982651F2@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6700607CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:55:39 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D6700607CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, before I forget, thanks for the assistance here... I haven't had a= n opportunity to read through this in detail, and might not be able to thi= s week due to impending deadlines. I will certainly get to it next week, = however. Adam From: Black, David [mailto:david.black@emc.com] Sent: Tuesday, June 18, 2013 6:48 AM To: Adam Montville; mile@ietf.org Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeratio= n Reference Hi Adam, The -02 version of this draft was definitely useful, and it's expired, so a new version would be a good idea ;-). This message is a bit long and detailed, but IANA considerations are full of details ... > Also, are there good IANA-related RFCs I can look at to tighten this > draft up a bit? What I was intending for the IANA section is to convey > both what the registry contains and the format of each element therein. That intent is fine, as good IANA considerations text for registry creatio= n does exactly that. At the risk of blowing my own horn, here's a recent RF= C that is entirely IANA Considerations: http://www.rfc-editor.org/rfc/rfc6580.txt The IANA considerations text in Take's SCI draft is another reasonable example to work from. Also, RFC 2434 has been replaced by RFC 5226. Here are a few specific suggestions on the IANA considerations text: [1] Change this introductory sentence: OLD Registration request for the IODEF Enumeration Reference Format: NEW This memo creates the following registry for IANA to manage: END That should resolve the confusion that Panos noted. [2] This sentence seems out of place: The registry is intended to enable enumeration value additions to attributes of a given reference class of an IETF standard, for example, the Reference class of the IODEF schema. I think it would be better placed in Section 2.3, which already covers this, so just deleting that sentence may suffice. [3] This text seems vague: Note that certain name requests should not be permitted as either Full Name or Abbreviation entries for the requested IANA table. For example, the following list should not be permitted: foo, bar, example.com. It is anticipated that the Expert Review process will flag any additional undesired Full Name or Abbreviation issues. There should be some additional explanation of what should not be permitte= d and why, but that approach seems problematic - it could easily get long an= d will inevitably miss some things that we'd like to exclude. Moreover, I'm= not even sure about the excluded examples - what if someone (cleverly) com= es up with a widely used Fraud Observable Objects format, would we really want to disallow FOO :-) ? It may be better to leave this to the judgment of the Designated Expert, so I'd suggest turning this approach ar= ound - remove the above text and instead write some additional guidance to the designated expert on what the abbreviation should represent. On the proposed new formats: Abbreviation: The abbreviation of the enumeration as a string from the ASCII character set. An abbreviation may be an initialism or acronym, is free-form, but is limited to between two and five upper-case characters meeting the regular expression: ^[A-Z]{2,5}$ Version: The version of the enumeration as a string using major and minor dotted notation meeting the regular expression as follows: ^[1-9]+\.[0-9]+$ I'd suggest using ABNF rather than regular expressions - see RFC 5234 (http://www.rfc-editor.org/rfc/rfc5234.txt) including the core rules in Appendix B.1 (e.g., DIGIT). OTOH, the regexp formats are more compact - if they are retained, a reference needs to be cited that defines the regexp notation used. Several questions: - Is the limitation to ASCII ok? It's certainly the most straightforward approach, as use of 7-bit ASCII avoids a pile of Unicode issues, but are there any important existing or likely specs whose acronyms can't be expressed in ASCII? [Take - do you know of any spec that is likely to need non-ASCII character= s in an IODEF reference?] - Will 5 characters always be enough? All the current examples fit, but what about clever future acronyms that use more? - Is the restriction to upper case ok? Same concern about current example= s vs. future, but like the ASCII limitation, always upper case elimina= tes case conversion concerns (Warning: Unicode case conversion is a complex area that should be avoided if possible). - Is the limitation of version to major.minor (x.y) is overly restrictive?= Sooner or later there will be 3 or 4 element version numbers when someone needs to make a really small tweak/fix. Also, what happens when someone decides to number something as 4.3A instead of adding another dotted element? Overall, I'd suggest as little as we can get away with for version format restrictions, as the spec authors who choose versions probably won't have IODEF in mind when they do so. I also wonder how Version is going to be used - would it be: - For display only? - For exact match against the version that the IODEF recipient is using? - For more detailed comparison (e.g., "this or later", "same major version")? The first two use cases suggest no formatting restrictions, but the third = use case requires that version be parseable - is that necessary? As a strawman for Abbreviation, I'd suggest: Stay with upper case ASCII (avoids Unicode, avoids string miscompares courtesy of case-sensitive comparison instead of case-insensitive). Allow longer strings, e.g., up to 20 characters. Add guidance to designated expert to favor short strings (i.e., acronyms).= I'd add a sentence to Section 2 to say that the avoidance of string miscom= pares caused by case-sensitive comparison is the reason for upper case ASCII. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pa= nos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 3:42 PM To: Adam Montville; mile@ietf.org; Adam Montville Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeratio= n Reference You probably have seen this http://www.ietf.org/rfc/rfc2434.txt but I am p= ointing it out anyway From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Thursday, June 06, 2013 1:39 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org; Adam M= ontville Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeratio= n Reference Thank you! I'll make the changes you recommend. Also, are there good IANA-related RFCs I can look at to tighten this draft= up a bit? What I was intending for the IANA section is to convey both wh= at the registry contains and the format of each element therein. If there's a better way to do this, let's do it. Adam From: mile-bounces@ietf.org [mailto:mile-bou= nces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 8:33 AM To: Moriarty, Kathleen; mile@ietf.org; Adam Montvill= e (amontville@tripwire.com) Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeratio= n Reference Hi Adam, I think this is close to being done. I had reviewed in the past and the re= gistry format is as we had all agreed. I did a fresh review and had some minor nits and suggestions, and some con= fusion for the IANA considerations section. - maybe rephrase "but one that seems the most appropriate at this point is= to..." to "but the most appropriate at this point is to..." - "especially enumerations such as CEE, CVE, CCE" maybe put informative references for CEE, CVE and CCE? - "Where id_type is an IANA-registered type having the form..." I am propo= sing to rephrase the paragraph a little to avoid the "And where..." "The format of the ReferenceName MUST follow the form of id_type:version:id where id_type is an IANA-registered type having the form The version is an IANA-registered type having the form The id is the actual enumeration identifier string." - In section "4 IANA Considerations", it is not very clear to me what eac= h paragraph is trying to convey. It this section trying to describe the IA= NA registry or the format of a registry update request? To me it seems it = is mostly the former with some info on the latter. Should the "Name of the Registry: "Enumeration Reference Type Identifiers"= " be in the "Fields to record in the registry: "? Does the paragraph "The registry is intended to enable enumeration value a= dditions..." describe what the IANA registry represents or should it be in= the registry request for a new value? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bou= nces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank y= ou to all of the editors for making the requested changes! The current li= st of drafts up for review (including=20those that will be a part of the W= G after the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format= / Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the lis= t. It would be helpful if we can iterate on most of them prior to the nex= t meeting. A couple of the drafts are very close to being done. The list= of current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up=20soon on the charter update as well. Thank you all in advance! Kathleen ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissem= ination, distribution or copying of this message and attachments is strict= ly prohibited. Please notify the sender immediately and permanently delete= the message and any attachments. ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. --_000_05BCCEB107AF88469B9F99783D47C1D6700607CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David, before I forget,= thanks for the assistance here…  I haven’t had an opport= unity to read through this in detail, and might not be able to this week d= ue to impending deadlines.  I will certainly get to it next week, howev= er.

 

Adam<= /p>

 

From: Black= , David [mailto:david.black@emc.com]
Sent: Tuesday, June 18, 2013 6:48 AM
To: Adam Montville; mile@ietf.org
Subject: RE: [mile] Request for draft reviews - review of IODEF Enu= meration Reference

 

Hi Adam,

 

The -02 version of this draft was definitely= useful, and it’s expired, so

a new version would be a good idea ;-). = ; This message is a bit long and

detailed, but IANA considerations are full o= f details ...

 

> Also, are there good IANA-related RFCs = I can look at to tighten this

> draft up a bit? What I was intendi= ng for the IANA section is to convey

> both what the registry contains and the= format of each element therein.

 

That intent is fine, as good IANA considerat= ions text for registry creation

does exactly that.  At the risk of blow= ing my own horn, here’s a recent RFC

that is entirely IANA Considerations:

 

      http://www.rfc-edito= r.org/rfc/rfc6580.txt

 

The IANA considerations text in Take’s= SCI draft is another reasonable

example to work from.  Also, RFC 2434 h= as been replaced by RFC 5226.

 

 

Here are a few specific suggestions on the I= ANA considerations text:

 

[1] Change this introductory sentence:<= /o:p>

OLD

      Registration = request for the IODEF Enumeration Reference Format:

NEW

      This memo cre= ates the following registry for IANA to manage:

END

 

That should resolve the confusion that Panos= noted.

 

[2] This sentence seems out of place:

 

      The registry = is intended to enable enumeration value additions to

=

      attributes of= a given reference class of an IETF standard, for

      example, the = Reference class of the IODEF schema.

 

I think it would be better placed in Section= 2.3, which already covers

this, so just deleting that sentence may suf= fice.

 

[3] This text seems vague:=

 

      Note that

      certain name requests sho= uld not be permitted as either Full Name

      or Abbreviation entries f= or the requested IANA table.  For

      example, the following li= st should not be permitted: foo, bar,

      example.com.  It is = anticipated that the Expert Review process

      will flag any additional = undesired Full Name or Abbreviation

      issues.=

 

There should be some additional explanation = of what should not be permitted

and why, but that approach seems problematic= - it could easily get long and

will inevitably miss some things that weR= 17;d like to exclude.  Moreover, I’m

not even sure about the excluded examples - = what if someone (cleverly) comes

up with a widely used Fraud Observable Objec= ts format, would we really

want to disallow FOO :-) ?=

 

It may be better to leave this to the

judgment of the Designated Expert, so I̵= 7;d suggest turning this approach around

- remove the above text and instead write so= me additional guidance to the

designated expert on what the abbreviation s= hould represent.

 

 

On the proposed new formats:

 

        = Abbreviation: The abbreviation of the enumeration as a string<= /p>

from the ASCII charac= ter set.  An abbreviation may be an initialism

or acronym, is free-f= orm, but is limited to between two and five

upper-case characters= meeting the regular expression: ^[A-Z]{2,5}$

 

        = Version: The version of the enumeration as a string using major

and minor dotted nota= tion meeting the regular expression as follows:

^[1-9]+\.[0-9]= 3;$

 

I’d suggest using ABNF rather than reg= ular expressions - see RFC 5234

(http://www.rfc-editor.org/rfc/rfc5234.txt) including the co= re rules in

Appendix B.1 (e.g., DIGIT). =20OTOH, th= e regexp formats are more compact -

if they are retained, a reference needs to b= e cited that defines the

regexp notation used.

 

Several questions:

 

- Is the limitation to ASCII ok?  It= 217;s certainly the most straightforward

approach, as use = of 7-bit ASCII avoids a pile of Unicode issues,

but are there any= important existing or likely specs whose

acronyms can̵= 7;t be expressed in ASCII?

 =

[Take - do you know of any spec that is like= ly to need non-ASCII characters

in an IODEF reference?]

 

- Will 5 characters always be enough?  = All the current examples fit, but

      what about cl= ever future acronyms that use more?

 

- Is the restriction to upper case ok? = Same concern about current examples

      vs. future, b= ut like the ASCII limitation, always upper case eliminates

      case conversi= on concerns (Warning: Unicode case conversion is a

complex area that= should be avoided if possible).

 

- Is the limitation of version to major.mino= r (x.y) is overly restrictive?

Sooner or later t= here will be 3 or 4 element version

      numbers when = someone needs to make a really small tweak/fix.  Also,

      what happens = when someone decides to number something as 4.3A

      instead of ad= ding another dotted element?

 

Overall, I’d suggest as little as we c= an get away with for version format

restrictions, as the spec authors who choose= versions probably won’t have

IODEF in mind when they do so.

 

I also wonder how Version is going to be use= d - would it be:

 

- For display onl= y?

- For exact match= against the version that the IODEF

recipient is usi= ng?

- For more detail= ed comparison (e.g., “this or later”,

= “same major version”)?

 

The first two use cases suggest no formattin= g restrictions, but the third use

case requires that version be parseable - is= that necessary?

 

As a strawman for Abbreviation, I’d su= ggest:

 

Stay with upper c= ase ASCII (avoids Unicode, avoids string miscompares

=

courtesy of case= -sensitive comparison instead of case-insensitive).

Allow longer stri= ngs, e.g., up to 20 characters.

Add guidance to d= esignated expert to favor short strings (i.e., acronyms).

 

I’d add a sentence to Section 2 to say= that the avoidance of string miscompares

caused by case-sensitive comparison is the r= eason for upper case ASCII.

 

Thanks,
--David

 

From: mile-= bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 06, 2013 3:42 PM
To: Adam Montville; mile@ietf.org; Adam Montville
Subject: Re: [mile] Request for draft reviews - review of IODEF Enu= meration Reference

 

You probably have seen = this http://www.ietf.org/rfc/rf= c2434.txt but I am pointing it out anyway

 

 

From: Adam = Montville [mailto:Adam.Montville@cisecurity.org]
Sent: Thursday, June 06, 2013 1:39 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org;= Adam Montville
Subject: RE: [mile] Request for draft reviews - review of IODEF Enu= meration Reference

 

Thank you!  I̵= 7;ll make the changes you recommend.

 

Also, are there good IA= NA-related RFCs I can look at to tighten this draft up a bit?  What I= was intending for the IANA section is to convey both what the registry contains and the format of each element therein.

 

If there’s a bett= er way to do this, let’s do it.

 

Adam<= /p>

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 06, 2013 8:33 AM
To: Moriarty, Kathleen; mile@ietf.= org; Adam Montville (amontv= ille@tripwire.com)
Subject: Re: [mile] Request for draft reviews - review of IODEF Enu= meration Reference

 

Hi Adam,

 

I think this is close t= o being done. I had reviewed in the past and the registry format is as we = had all agreed.

I did a fresh review an= d had some minor nits and suggestions, and some confusion for the IANA con= siderations section.

 

- maybe rephrase “but one that seems the most appropriate at this point is=
 to...” to “but the most appropriate at this point is to...”=

 
- “especially enumerations such as
   CEE, CVE, CCE” maybe put informative references for CEE, CVE =
and CCE?
 
- “Where id_type is an IANA-registered type having the form...” I am proposing to rephrase the paragraph a =
little to avoid the “And where…”
= 
“The format of the ReferenceName MUST follow the form of=

      id_type:ve=
rsion:id
   where id_type is an IANA-reg=
istered type having the form
      <Abbrev=
iation>
   The version is an IANA-regis=
tered type having the form
      <Versio=
n>
   The id is the actual enumera=
tion identifier string.”
 
- In section “4  IANA ConsiderationsShould the “Name of the Registry: "Enumeration Reference Type Identif=
iers"” be in the “Fields to record in the registry: ”? 
Does the paragraph “The registry is intended to enable enumeration value a=
dditions...” describe what the IA=
NA registry represents or should=20it be in the registry request for a new=
 value?

 

Rgs,<= /p>

Panos=

 

 

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To: mile@ietf.org
Subject: [mile] Request for draft reviews

 

Greetings!

 

We have had a number of documents upd= ated since the last meeting.  Thank you to all of the editors for mak= ing the requested changes!  The current list of drafts up for review (including those that will be a part of the WG after the charter update) = include:

 

RFC5070-bis (IODEF Revision):

 

Draft on IODEF Guidance:

(input from experience, real use case= s, and draft review will be helpful)

 

Structured Cybersecurity Information = draft (close to final):

 

IODEF Enumeration Reference Format:

 

Resource-Oriented Lightweight Indicat= or Exchange (ROLIE):

 

Please take some time to review the d= rafts and provide feedback to the list.  It would be helpful if we ca= n iterate on most of them prior to the next meeting.  A couple of the drafts are very close to being done.  The list of current drafts= and published RFCs can be found at the following link:<= /p>

 

We will follow up soon on the charter= update as well.

 

Thank=20you all in advance!
Kathleen

 

 


...


This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissem= ination, distribution or copying of this message and attachments is strict= ly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.<= /o:p>


...


This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments.
--_000_05BCCEB107AF88469B9F99783D47C1D6700607CISEXCHANGE1msisa_-- From trammell@tik.ee.ethz.ch Fri Jun 28 01:09:41 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DA21F84A8 for ; Fri, 28 Jun 2013 01:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIkMaEw7Zjtp for ; Fri, 28 Jun 2013 01:09:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C1FE721F8475 for ; Fri, 28 Jun 2013 01:07:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C588BD9309 for ; Fri, 28 Jun 2013 10:07:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id T4oBnA+n0Moe for ; Fri, 28 Jun 2013 10:07:45 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9950FD9304 for ; Fri, 28 Jun 2013 10:07:45 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jun 2013 10:07:44 +0200 Message-Id: To: MILE IETF Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [mile] MILE Agenda in Berlin X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "mile-chairs@tools.ietf.org" List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:09:41 -0000 Greetings, all, If you'd like a slot to talk at the MILE WG meeting in Berlin, please = let us know at mile-chairs@tools.ietf.org by Friday, July 12. Topics for = discussion include any document or topic covered by the in-progress = recharter (http://datatracker.ietf.org/wg/mile/charter/). Priority will = be given to working-group drafts and discussion of significant progress = on previously presented documents. The meeting will tentatively take place in Potsdam 2 on Tuesday, July = 30, 17:00-18:30 CEST; this is subject to change. Best regards, Brian= From kathleen.moriarty@emc.com Fri Jun 28 07:08:20 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095ED21F855F for ; Fri, 28 Jun 2013 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnWiQBizuMYG for ; Fri, 28 Jun 2013 07:08:15 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6021F8517 for ; Fri, 28 Jun 2013 07:08:14 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5SE82Dg026178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 10:08:04 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 28 Jun 2013 10:07:45 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5SE7i6j009737; Fri, 28 Jun 2013 10:07:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Fri, 28 Jun 2013 10:07:44 -0400 From: "Moriarty, Kathleen" To: Takeshi Takahashi , "daniel.piggott@switch2it.co.uk" , "'Panos Kampanakis (pkampana)'" , "mile@ietf.org" , "Stoecker, Paul" , Roman Danyliw Date: Fri, 28 Jun 2013 10:07:43 -0400 Thread-Topic: [mile] Request for draft reviews - review of FC5070-bis Thread-Index: AQGrfDo3oosvrhqkCdnIlKmQHVtubgJFBsa4mW6okECAEEfc4A== Message-ID: References: <1C9F17D1873AFA47A969C4DD98F98A753C8AC8@xmb-rcd-x10.cisco.com> <027901ce68fa$f9eb4060$edc1c120$@piggott@switch2it.co.uk> <001101ce6bea$f89a8ac0$e9cfa040$@nict.go.jp> In-Reply-To: <001101ce6bea$f89a8ac0$e9cfa040$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Request for draft reviews - review of FC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 14:08:20 -0000 Roman & Paul, Can you help on Daniel's questions below? If possible, can we iterate on t= he draft before the next meeting as well to address some of the questions r= aised at the last IETF meeting? I believe we have some other outstanding questions on this draft, I will re= -forward them if I can find them. Thank you! Kathleen -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Tuesday, June 18, 2013 2:14 AM To: daniel.piggott@switch2it.co.uk; 'Panos Kampanakis (pkampana)'; Moriarty= , Kathleen; mile@ietf.org; Stoecker, Paul Subject: RE: [mile] Request for draft reviews - review of FC5070-bis Hi Daniel and all, Though the discussion is on IODEF-bis rather than IODEF-SCI, I hope you do not mind sharing my opinion here :) > Would these be worth considering in the IODEF incident schema? I agree. > An incident classification level or assurance level for each incident? I feel that the assurance or trustworthiness of the information is somethin= g we could consider outside IODEF document. The sender can describe "Confidence" instead of the trustworthiness. (E.g., I cannot say that I myself is very trustworthy sender of the information, but I can say that I am confident on the information. Receiver can judge whether he/she trust me or not.) > Mac address of reporting device? I think it is good idea. The "person" who reports IODEF document could be a machine, such as IDS. For instance, we could reconsider the structure of "Contact" class. > A field for whether any device is virtual or physical? I agree. > A hash of each incident raw data? > Memory address space field (as you have PID)? I agree on the usefulness of these information. Instead of extending IODEF itself, we could consider using external schema for that purpose. These could be then embedded into IODEF document through the use of IODEF-SCI. > NTP Time source of the incident device? I agree. > In the example above in Appendix III below should the service IP protocol be 4? I've used the example described in the RFC5070, and I didn't realize this point. Thank you for pointing it out. Kind wishes, Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Daniel Piggott Sent: Friday, June 14, 2013 9:31 PM To: 'Panos Kampanakis (pkampana)'; 'Moriarty, Kathleen'; mile@ietf.org; Paul.Stoecker@rsa.com Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hello, is there any update to my response to the document reviewed below? Sent 6th June 22:57? Kathleen informed me it only made part of the distribution list. Thks Daniel Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Having looked through this draft and the example=A0 11.=A0 Appendix III: An= XML Example Would these be worth considering in the IODEF incident schema? An incident classification level or assurance level for each incident? Mac address of reporting device? A field for whether any device is virtual or physical? A hash of each incident raw data? Memory address space field (as you have PID)? NTP Time source of the incident device? In the example above in Appendix III below should the service IP protocol b= e 4? System category=3D"target"> =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
192.0.2.16= /28
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 80 =A0=A0=A0=A0=A0=A0=A0=A0=A0 And one last question, if the receiving node getting the alerts via IODEF goes offline From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 Sent: 06 June 2013 19:26 To: Moriarty, Kathleen; mile@ietf.org; 'Paul.Stoecker@rsa.com' (Paul.Stoecker@rsa.com) Subject: Re: [mile] Request for draft reviews - review of FC5070-bis Hi Paul, Good starting point. Some comments and nits below from my first pass. There should be more when I review again. I remember sometime in the past there was a discussion=A0 about what is an incidents if that should be updated in the 5070. I see that in your draft a= n incident is used as it was in 5070. I was just wondering if we had reached = a consensus on it. I also didn't see "uid" and "set id" definitions in the draft. I don't see the EMailDetails class described in the document. Nits: - Should "This document contains changes with respect to its predecessor =A0=A0=A0=A0=A0 RFC5070:" be bulleted? - The list in "This class will contain indicators from =A0=A0=A0=A0=A0 the list below " is not exactly below. The same for "the =A0=A0=A0=A0=A0 following included indicators are ones commonly used ". And= the same for me occurrences of "following" in this section - I am not sure if we want to keep the "

Roman &am= p; Paul,

 =

Can you help with these questions/co= mments as well?

 = ;

Thank you,<= /p>

Kathleen

 

Fro= m: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent:<= /b> Thursday, June 06, 2013 2:26 PM
To: Moriarty, Kathleen; mile@= ietf.org; Stoecker, Paul
Subject: RE: Request for draft reviews -= review of FC5070-bis

 

 =

Hi Paul,

 

Good= starting point. Some comments and nits below from my first pass.

There should be more when I review = again.

 

I remember sometime in the past there = was a discussion  about what is an incidents if that should be updated= in the 5070. I see that in your draft an incident is used as it was in 507= 0. I was just wondering if we had reached a consensus on it.

 

=
I also didn’t see “uid”=
; and “set id” definitions in the draft.

 

I don’t see the EMailDetails class described in the =
document.

 

Nits:

- Should “This document contains changes with respect to its predece=
ssor

     = RFC5070:” be bulleted?

- The list in “This class will c=
ontain indicators from
      the list below ” is =
not exactly below. The same for “t=
he
  &nbs=
p;   following included indicators are ones commonly used =
”. And the same for me occurrences of “following” =
in this section
- I am not sure if we wa=
nt to keep the “<!-- CHANGE:” comments in the draft=

- there are some XML complexType like “SoftwareType” that are described as cl=
asses in the comments IODEF schema, but these are not classes.
 
I aqlso se=
e that you will have usecases-examples in this doc, so mayne I will remove =
mine from the guidance document.
&n=
bsp;

Rgs,

Panos

 

&nbs= p;

 

=

From: mile-bounces@ietf.org [ma= ilto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
<= b>Sent: Friday, May 17, 2013 2:13 PM
To: mile@ietf.org
Subject: [mile] Request for draft = reviews

 

Greetings!

 

We have had a= number of documents updated since the last meeting.  Thank you to all= of the editors for making the requested changes!  The current list of= drafts up for review (including those that will be a part of the WG after = the charter update) include:

=  

RFC5070-bis (IODEF Rev= ision):

<= p class=3DMsoNormal> 

Draft on = IODEF Guidance:

(input from e= xperience, real use cases, and draft review will be helpful)

&nb= sp;

Structured Cybersecurity = Information draft (close to final):

 

IODEF Enumeration Reference Format:

&= nbsp;

Resource-Oriented Light= weight Indicator Exchange (ROLIE):

 

Please take some time to review the drafts and provide feedback to= the list.  It would be helpful if we can iterate on most of them prio= r to the next meeting.  A couple of the drafts are very close to being= done.  The list of current drafts and published RFCs can be found at = the following link:

 

We will follow up soon on the charter updat= e as well.

 <= /span>

Thank you all in advance!
Kathleen

 

 

= --_000_F5063677821E3B4F81ACFB7905573F24DF1B833DMX15Acorpemccom_-- From kathleen.moriarty@emc.com Fri Jun 28 08:32:08 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C721F9C21 for ; Fri, 28 Jun 2013 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afgOTc8hpn0S for ; Fri, 28 Jun 2013 08:32:04 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E581F21F9C20 for ; Fri, 28 Jun 2013 08:32:01 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5SFVxZQ015074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Jun 2013 11:32:00 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 28 Jun 2013 11:31:52 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5SFVq9G019345 for ; Fri, 28 Jun 2013 11:31:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Fri, 28 Jun 2013 11:31:51 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Fri, 28 Jun 2013 11:31:50 -0400 Thread-Topic: IODEF Guidance and existing implementations Thread-Index: Ac50FJvqDXIScHyVQ5KFPwaEQfxE6g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24DF1B8373MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] IODEF Guidance and existing implementations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:32:08 -0000 --_000_F5063677821E3B4F81ACFB7905573F24DF1B8373MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos & Others, Panos had asked about moving the examples from the IODEF Guidance to RFC507= 0-bis, was that the right thing to do? I would like to see us use the IODEF guidance document to work through use = cases and document what gets shared with whom for various use cases, then d= emonstrated using RFC5070-bis. Implementations are increasing and I think = this would be really helpful so that those implementations have guidance to= implement the use cases relevant to their users. We could start with documentation on some of the existing use cases that ha= ve been implemented, some in development, and then look to see how we can s= hare effectively with new use cases. The existing and active implementations I am aware of include: o APWG Anti-phishing - using IODEF o APWG eCrime - using IODEF o XMPP Operators using IODEF over XMPP for active exchanges o Blackthorn - Using IODEF + extensions for communications between severa= l nations, with IODEF accessed on mobile platforms Names may not be ready to be public: o energy sector organization using IODEF over XMPP o reports sent via IODEF for consumption from a sharing group PoCs: o Multiple PoCs in play using IODEF + RID between several vendors in suppo= rt of the MACCSA framework Implementations: * DFLabs - has the Digital Investigation Manager product using IODEF = since at least 2007 * Arcsite supports imports of RFC5070 formatted IODEF reports, there = may be other vendors? * Blackthorn - product using IODEF + private extensions for active sh= aring * Open Source RID Agent with RFC5070-bis support in java from EMC/RSA= - on GitHub: https://github.com/RSAIntelShare/RID-Server * Open source RID Agent implementation in Python from MITRE - I don't= have the link, but it is compatible with the EMC/RSA one * CSI Extension support for IODEF on Github from NICT in Java: https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools * eCRISP-X: Suports eCrime use cases using IODEF RFC5070, from Pat C= ain: http://sourceforge.net/projects/ecrisp-x * eCRISP-X: Phisihing report support - can't find the link, but know = it exists for the APWG use case * iodeflib: a python library to create, parse & edit IODEF: http://www.decalage.info/python/iodeflib * IODEF/RID - older versions (RFC6045, RFC6046 and RFC5070) in open s= ource from Japan: http://www.ipa.go.jp/security/fy16/development/IODEF/api/= index.html * IODEF & RID implementation in Japanese from the Information technol= ogy Protection Agency (IPA): http://www.cysols.com/research/iodef/IODEFApp.html * CPAN IODEF perl module to create & parse IODEF: http://search.cpan.org/~johng/XML-IODEF-0.06/ * Collective Intelligence Framework (CIF) from Ren-ISAC uses a modifi= ed version of IODEF for their active sharing platform The CERT.org site that tracked this in the past has a few others listed and= also says the following organizations have active projects using IODEF on = their page http://www.cert.org/ietf/inch/inch.html : CERT/CC: AirCERT, JPC= ERT/CC: Internet Scan Data Acquisition Systems (ISDAS), and eCSIRT.net: The= European CSIRT Network If I missed any, please add to the list. It would be good to get these on = a web page or wiki as a running list that can be amended as there is a lot = of development/PoC activity right now. For the IODEF Guidance, we can look at the use cases, determine what is suc= cessful and get the use cases documented. Thank you, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24DF1B8373MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Panos & Others,
 
Panos had asked about moving the examples from the IODEF Guidance to R= FC5070-bis, was that the right thing to do?
 
I would like to see us use the IODEF guidance document to work through= use cases and document what gets shared with whom for various use cases, t= hen demonstrated using RFC5070-bis.  Implementations are increasing an= d I think this would be really helpful so that those implementations have guidance to implement the use cases rele= vant to their users.
 
We could start with documentation on some of the existing use cases th= at have been implemented, some in development, and then look to see how we = can share effectively with new use cases.
 
The existing and active implementations I am aware of include:
o   APWG Anti-phishing – using IODEF
o   APWG eCrime – using IODEF
o   XMPP Operators using IODEF over XMPP for active exchange= s
o   Blackthorn – Using IODEF + extensions for comm= unications between several nations, with IODEF accessed on mobile platforms=
 
Names may not be ready to be public:
o   energy sector organization using IODEF over XMPP
o   reports sent via IODEF for consumption from a sharing gr= oup
 
PoCs:
o  Multiple PoCs in play using IODEF + RID between several ve= ndors in support of the MACCSA framework
 
Implementations:
  • DFLabs – has the Digital Investigation Manager product using IODE= F since at least 2007
  • Arcsite supports imports of RFC5070 formatted= IODEF reports, there may be other vendors?
  • Blackthorn – prod= uct using IODEF + private extensions for active sharing
  • Open So= urce RID Agent with RFC5070-bis support in java from EMC/RSA – on Git= Hub: https://github.com/RSAIntelShare/RID-Server
  • Open source RID Agent implementation in Python from MITRE – I do= n’t have the link, but it is compatible with the EMC/RSA one
  • = CSI Extension support for IODEF on Github from NICT in Java:
https://= github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools
  • eCRISP-X:  Suports eCrime use cases using IODEF RFC5070, from Pat = Cain:
  • eCRISP-X: Phisihing report support – can’t find the link, b= ut know it exists for the APWG use case
  • iodeflib: a python library = to create, parse & edit IODEF:
  • CPAN IODEF perl module to create & parse IODEF:
  • Collective Intelligence Framework (CIF) from Ren-ISAC uses a modified v= ersion of IODEF for their active sharing platform
The CERT.org site that tracked this in the past has a few others liste= d and also says the following organizations have active projects using IODE= F on their page http://www.cert.org/ietf/inch/inch.html :  CERT/CC: AirCERT, JPCERT/CC: Internet Scan Data Acquisition Systems= (ISDAS), and eCSIRT.net: The European CSIRT Network
 
If I missed any, please add to the list.  It would be good to get= these on a web page or wiki as a running list that can be amended as there= is a lot of development/PoC activity right now.
 
For the IODEF Guidance, we can look at the use cases, determine what i= s successful and get the use cases documented.
 
Thank you,
Kathleen
 
--_000_F5063677821E3B4F81ACFB7905573F24DF1B8373MX15Acorpemccom_-- From iesg-secretary@ietf.org Fri Jun 28 09:40:17 2013 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E627B21F9B22; Fri, 28 Jun 2013 09:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.86 X-Spam-Level: X-Spam-Status: No, score=-101.86 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNRJwYL3ziXY; Fri, 28 Jun 2013 09:40:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4645B21F9B10; Fri, 28 Jun 2013 09:40:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628164017.27055.32231.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:40:17 -0700 Cc: mile WG Subject: [mile] WG Review: Managed Incident Lightweight Exchange (mile) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:40:18 -0000 The Managed Incident Lightweight Exchange (mile) working group in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Managed Incident Lightweight Exchange (mile) ------------------------------------------------ Current Status: Active WG Chairs: Kathleen Moriarty Brian Trammell Assigned Area Director: Sean Turner Mailing list Address: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Charter: The Managed Incident Lightweight Exchange (MILE) working group develops standards to support computer and network security incident management; an incident is an unplanned event that occurs in an information technology (IT) infrastructure. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, or suspected, there may be a need for organizations to collaborate. This collaboration effort may take several forms including joint analysis, information dissemination, and/or a coordinated operational response. Examples of the response may include filing a report, notifying the source of the incident, requesting that a third party resolve/mitigate the incident, sharing select indicators of compromise, or requesting that the source be located. By sharing indicators of compromise associated with an incident or possible threat, the information becomes a proactive defense for others that may include mitigation options. The Incident Object Description Exchange Format (IODEF) defines an information framework to represent computer and network security incidents; IODEF is defined in RFC 5070 and has been extended by RFC 5091 to support phishing reports; RFC 6484 provides a template for defining extensions to IODEF. Real-time Inter-network Defense (RID) defines a protocol to facilitate sharing computer and network security incidents; RID is defined in RFC 6545, and RID over HTTPS is defined in RFC 6546. The MILE WG is focused on two areas, IODEF, the data format and extensions to represent incident and indicator data, and RID, the policy and transport for structured data. With respect to IODEF, the working group will: - Revise the IODEF document to incorporate enhancements and extensions based on operational experience. Use by Computer Security Incident Response Teams (CSIRTs) and others has exposed the need to extend IODEF to support industry specific extensions, use case specific content, and representations to associate information related to represented threats (system, threat actors, campaigns, etc.). The value of information sharing has been demonstrated and highlighted at an increasing rate through the success of the Information Sharing and Analysis Centers (ISACs) and the recent cyber security Executive Order in the US. International groups, such as the Multinational Alliance for Collaborative Cyber Situational Awareness (CCSA) have been running experiments to determine what data is useful to exchange between industries and nations to effectively mitigate threats. The work of these and other groups have identified or are working to develop data representations relevant to their use cases that may compliment/extend IODEF or be useful to exchange using RID and related transport protocols. - Provide guidance on the implementation and use of IODEF to aid implementers in developing interoperable specifications. With respect to RID, the working group will: - Define a resource-oriented approach to cyber security information sharing that follows the REST architectural style. This mechanism will allow CSIRTS to be more dynamic and agile in collaborating with a broader, and varying constituency. - Provide guidance on the implementation and use of RID transports based on use cases. The guidance document will show the relationship between transport options (RID + RID transport and IODEF/RID + ROLIE) and may identify the need for additional transport bindings. - RID may require modifications to address data provenance, additional policy options, or other changes now that there are multiple interoperable implementations of RFC6545 and RFC6546. With the RID implementations in the open source community, increased use and experimentation may demonstrate the need for a revision. Milestones: Aug 2013 - Submit a draft on the representation of Structured Cybersecurity Information in IODEF to the IESG for publication as a Standards Track RFC Aug 2013 - Submit a draft on enumeration reference formats for IODEF to the IESG for publication as a Standards Track RFC Dec 2013 - Submit a draft on RESTful indicator exchange using IODEF/RID to the IESG for publication as an Informational RFC Jan 2014 - Submit an update of RFC5070 to the IESG for publication as a Standards Track RFC Apr 2014 - Submit a draft on guidance for IODEF applications to the IESG for publication as an Informational RFC