Re: [mile] Working Group Last Call for draft-ietf-mile-sci

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Mon, 22 July 2013 12:30 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
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 7A13821F9D92 for <mile@ietfa.amsl.com>; Mon, 22 Jul 2013 05:30:46 -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=[AWL=-0.000, 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 7jJGTkuu26F1 for <mile@ietfa.amsl.com>; Mon, 22 Jul 2013 05:30:41 -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 302E621F9D87 for <mile@ietf.org>; Mon, 22 Jul 2013 05:30:41 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r6MCUWlE018730; Mon, 22 Jul 2013 21:30:32 +0900 (JST)
Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r6MCUWpR023391; Mon, 22 Jul 2013 21:30:32 +0900 (JST)
Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r6MCUWP1023388; Mon, 22 Jul 2013 21:30:32 +0900 (JST)
Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id EA8882C9A5; Mon, 22 Jul 2013 21:30:31 +0900 (JST)
Received: from VAIO (unknown [133.243.119.109]) by mail1.nict.go.jp (NICT Mail) with ESMTP id E16B22C9A3; Mon, 22 Jul 2013 21:30:31 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'Ian Hardman' <Ian.Hardman@blackthorn.com>, mile@ietf.org
References: <5E860DD6-0BCD-4B02-94F8-9C5F03CEAFDA@tik.ee.ethz.ch> <43E1A65ED32E444C9DBE53F853C1E47893C8FE566E@qccsrv13.qcc.local> <43E1A65ED32E444C9DBE53F853C1E47893C8FE5C50@qccsrv13.qcc.local> <F5063677821E3B4F81ACFB7905573F24DF2F83DA@MX15A.corp.emc.com> <43E1A65ED32E444C9DBE53F853C1E47893C8FE5D50@qccsrv13.qcc.local>
In-Reply-To: <43E1A65ED32E444C9DBE53F853C1E47893C8FE5D50@qccsrv13.qcc.local>
Date: Mon, 22 Jul 2013 21:30:33 +0900
Message-ID: <001201ce86d7$42925520$c7b6ff60$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJRo70fbhfuidd71zYXUkmGBKULhgGpx4vRAU1ONTICwzG1pwJmklPomClaFlA=
Content-Language: ja
Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-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" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 12:30:46 -0000

Hi Ian,

Thank you for sharing the slides/articles, which were really interesting.
I am looking forward to the workshop in this week.

These insight should be reflected directly to the IODEF(bis) or SCI.
If it is going to be applied to the SCI draft, I do not see any problem and
it should be able to cope with the SCI classes nicely.
We simply need to register new schema (for the new Alert, for instance) to
the IANA table.

> We believe all the XML Elements need some method of referring to the
> objects/elements without having to supply the whole object again.  For
> example:

Regarding the above comments, I agree.
The SCI classes can embed the XML itself. Nevertheless, it can also put
links or identifiers instead of the XML object.
In this way, we do not have to resend the whole object again.
(we could simply assign identifier for a certain namespace for the report,
for instance. The SCI class supports namespaces that are not listed to the
IANA by using the ext-SpecID attribute and the attribute could be used for
this usage. Or we could simply use web links to identify the report, for
instance.)

In addition to that, it would be interesting if we could discuss how to
reflect these issues you kindly presented in the slides/article to the
IODEF-bis as well.

Thank you.
Take



> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Ian Hardman
> Sent: Tuesday, July 16, 2013 1:19 AM
> To: mile@ietf.org
> Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-sci
> 
> Kathleen has ask me to forward these documents to you.
> 
> These documents contain a summary based on alert handling, but there are
> a number of other areas we would like see implemented.
> 
> The main issue we have when synchronising incidents, when particular
> objects/XML elements are either:
>         repeated through the XML exchange (typically with people) or
>         there has been no change since it was last sent
> 
> We believe all the XML Elements need some method of referring to the
> objects/elements without having to supply the whole object again.  For
> example:
> 
> o)  party A sent information regarding an incident to party B.
> o) it was later found out a known threat source was influencing a threat
> agent
> o) information need to be resent with just the packet stating that that
> known threat source was now influencing the threat agent.
> 
> Then viz
> o) it was later found out a known threat source was no longer influencing
> that threat agent
> o) information need to be resent with just the packet stating that that
> known threat source was no longer influencing the threat agent.
> 
> There may be something in the specification we have not picked up on but
> we add attributes to say where we are just referencing object and the
> process.
> 
> Anyway see what you think and any help in standardising data interchange
> will be much appreciated.
> 
> 
> Thanks,
> 
> Ian
> 
> -----Original Message-----
> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
> Sent: 15 July 2013 13:28
> To: Ian Hardman
> Cc: Neil Hare-Brown; mile-chairs@tools.ietf.org
> Subject: RE: [mile] Working Group Last Call for draft-ietf-mile-sci
> 
> Hi Ian,
> 
> I should have gone through all of the materials before sending my first
> email.  The presentation looks great for the workshop on the 26th and will
> be really helpful for people to understand what has been done for your use
> case.
> 
> For a draft, any extensions you have created that you think could be of
> broader use, like the alerting would be good to submit as a draft to MILE
> creating an extension.  The extension could be off the SCI draft or direct
> to IODEF.  For altering, if you want that off the SCI draft, you may need
> to ask Take to create a branch where that is appropriate, or use the
> EventReport with a special tag or something?  I would ask that you provide
> this feedback as soon as possible on list since the draft is in last call
> for about another week.  If you do want to get in a draft and present it
> at the MILE meeting (get a slot on the MILE agenda too).
> 
> Your document also includes some recommended changes to IODEF.  Could you
> post those to the list and also to the tool Roman started using to track
> IODEF issues?  We can get the working group to weigh in on them and should
> be able to fix it in RFC5070-bis.
> 
> 
> 
> Please let us know if you have any questions.
> 
> Thank you!
> Kathleen
> 
> -----Original Message-----
> From: Ian Hardman [mailto:Ian.Hardman@blackthorn.com]
> Sent: Monday, July 15, 2013 4:26 AM
> To: Moriarty, Kathleen
> Cc: Neil Hare-Brown
> Subject: RE: [mile] Working Group Last Call for draft-ietf-mile-sci
> 
> Kathleen,
> 
> There are a number of points that we would like see implemented to aid
data
> transfer between hosts.
> 
> I have attached a document which contains a summary based on alert
handling,
> but there are a number of other areas we would like see implemented.
> 
> The main issue we have when synchronising incidents, when particular
> objects/XML elements are either
>         repeated through the XML exchange (typically with people) or
>         there has been no change since it was last sent
> 
> As you can tell this can lead to large XML file, particular when you are
> looking at files (RecordData).  This was also brought up in the BCS
meeting.
> How we implemented it,  is to pass the unique id of the element and/or the
> unique external reference of the element and passing an attribute to say
> "no change".  Maybe it is already included and we haven't seen it.  Either
> way it would be good to get a standard on this.
> 
> I am not too sure how we should be submitting these ideas, or should we
> just discuss it in Berlin?
> 
> Many thanks.
> 
> Ian
> 
> 
> 
> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Brian Trammell
> Sent: 09 July 2013 07:02
> To: MILE IETF
> Subject: [mile] Working Group Last Call for draft-ietf-mile-sci
> 
> Greetings, all,
> 
> This is the Working Group Last Call for draft-ietf-mile-sci,
> IODEF-extension for structured cybersecurity information.
> 
> The last call starts now, and ends Saturday 27 July, just before the IETF
> 87 meeting in Berlin.
> 
> Please read the latest revision of the draft,
> http://tools.ietf.org/html/draft-ietf-mile-sci-08, and send your
> comments to the mailing list; we'd also appreciate a comment if you're
fine
> with the draft as is.
> 
> Many thanks, and best regards,
> 
> Brian
> 
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
> 
> This email and any attachments are confidential and may also be
privileged.
> If you are not the named recipient, please notify the sender immediately,
> and do not disclose the contents to another person, use it for any
purpose,
> or store, or copy the information in any medium. Please also destroy and
> delete the message from your computer.
> 
> This email and any attachments are confidential and may also be
privileged.
> If you are not the named recipient, please notify the sender immediately,
> and do not disclose the contents to another person, use it for any
purpose,
> or store, or copy the information in any medium. Please also destroy and
> delete the message from your computer.