Subject: [mile] how to register new specifications in the future

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 11 Nov 2011 09:40:51 +0900

Let me change the title of the email since I am not talking about CybOX...
I would appreciate any other views.

Thank you.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Takahashi
Sent: Friday, November 11, 2011 9:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] CybOX and IODEF

Hi Kent,

Thank you for the useful discussion.
I appreciate it very much.
This is an issue we need to think to maintain future extensibility of the
draft, I think.

I said "I do not have any objection", to mean that "I agree on the
usefulness of preparing a mechanism to check the quality (or matureness or
popularity or usefulness. Since I cannot find the right word for this at
this moment, let me keep using this word "quality" for a while.) of new
specification before registering it to the IANA table."
I guess my lack of expression caused some confusion, sorry.

On the other hand, the issue I wanted to raise in the previous email was,
how can we do that?
At this moment, I still cannot figure out how we can guarantee such a system
that reviews qualities of all the future specification, even after reading
your email.
We cannot "mandate" MILE working group to exist for the purpose of reviewing
new specifications. (or can we?) The same applies to the other organizations
or voluntary groups.

So, only the feasible way to maintain the future extensibility of the draft
was, "when a specification is emerged and authorized by certain organization
with proper namespace, it could be registered to the IANA table", I thought.
For the moment (from the viewpoint of the draft), I cannot figure out any
better design of registering new drafts, as you also mentioned in the
previous email.
I think it is good idea to seek for such a mechanism to review new
specifications, but I think all we can expect is voluntary actions outside
this draft, and I am hesitant to describe these voluntary actions in the
draft since they might be seen as mandated actions.

Anyway, I am happy to develop the draft further if we could come up with
better solution for this.
So, I would appreciate any suggestions.

Thank you.
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 11, 2011 1:55 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] CybOX and IODEF

Take,

I am a bit confused here.  Please bear with me.

You stated:
         I basically do not have any objection to the comments you raised in
the list, but the question is, do we want to review all the future
specifications?

KL : In what context are you asking this question?  If we are looking to
include any specification, we should make sure that it is appropriate and
viable to some extent.

I do not think IANA wants to review the quality of future specifications.

KL: Quality is not the issue here.  The fact is all the other areas have
either active implementations or a very active working group that includes
many vendors.  As stated here and in the presentations that was given at
ITSAC, this is a VERY new effort with little to no active vendor
involvement.  I am not saying that is going to be the case in the future but
that is the state now.

And I do not think MILE working group exists forever.

KL: I don't think this is relevant. IETF groups can be rechartered and as in
the case of this working group,  restarted.  That should not be a
consideration here.

So, when a specification is emerged and authorized by certain organization
with proper namespace, it could be registerd to the IANA table.
(Correct me if my understanding of IANA function is wrong.)

Or, do we have any good way to review the quality of specification before
registering that to the IANA table (list of supported specifications)?

KL: I think we need to have a higher bar than just some organization
published something.  There needs to be some vetting that it will be truly
valuable to the community we are trying to serve. Again, I do not think we
should put it in * at this time *.  I do think that it may mature into
something very useful.  But we need to get it to a point that all understand
it, there are multiple organizations working on it and there is a shared
understanding it will be viable moving forward.  All the others that are
documented in the draft meet that low bar.  This has not yet gotten there.

Kent

Kent Landfield
Director Content Strategy, Architecture and Standards

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

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

From: Takeshi Takahashi
<[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Nov 2011 09:46:13 -0600
To: Kent Landfield
<[email-masked]<mailto:[email-masked]>>, Luis Nunez
<[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
Subject: RE: [mile] CybOX and IODEF

Hi Panos, Luis, and Kent,

I think I might be discussing a slightly different issue here, but let me
talk about how I see the extension.
I want to see the extension as a container to convey structured
cybersecurity information.
So, if new specification is emerged, it should be registered to the IANA
table (that lists the IDs for specifications). Then the data formatted by
the specification schema can be embedded in the IODEF document.
If new version of specification is provided, it should be again registered
to the table. Both old and new versions of the specification are supported
by the extension.

I basically do not have any objection to the comments you raised in the
list, but the question is, do we want to review all the future
specifications?
I do not think IANA wants to review the quality of future specifications.
And I do not think MILE working group exists forever.
So, when a specification is emerged and authorized by certain organization
with proper namespace, it could be registerd to the IANA table.
(Correct me if my understanding of IANA function is wrong.)

Or, do we have any good way to review the quality of specification before
registering that to the IANA table (list of supported specifications)?

Take

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of
[email-masked]<mailto:[email-masked]>
Sent: Friday, November 11, 2011 12:14 AM
To: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: Re: [mile] CybOX and IODEF

One of the major concerns that I have is that we are just now learning about
CybOX. I first learned about it at the EMAP working group meeting in August.
I am not the only one that just started to see what this is about.  It
really began in May of this year.

While this may be a good idea, I am not sure we want to rush it until the
community has an understanding as to how to apply it.  The key here is that
vendors and those who are going to be asked to support it via
implementations need to assure it is solid and in a condition to implement
it.  The schema is at Version 0.6.  I do believe this should be included as
work and evaluation in the MILE working group but I think we need to take it
slow as to incorporating it into drafts until the effort is a bit more
mature.

Kent Landfield
Director Content Strategy, Architecture and Standards

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

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

From: Luis Nunez
<[email-masked]<mailto:[email-masked]><mailto:lnunez@c3isecu
rity.com>>
Date: Thu, 10 Nov 2011 07:54:14 -0600
To: Panos Kampanakis
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]><mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [mile] CybOX and IODEF

Good observation,  If CAPEC and MAEC are included as an extension, do we
need Cybox?   I think Cybox may add additional context and relationships to
other emerging standards if I am interpreting it correctly (artifact
collection and integration with CEE, EMAP).  I am just not as familiar with
Cybox to provide details.  Maybe someone can explain how Cybox could further
complement MILE?

-ln

On Nov 8, 2011, at 6:34 PM, Panos Kampanakis wrote:

Take,
Cybox's observables seem to have been included in the latest CAPEC and will
also be integrated in MAEC.
Since the IODEF extension draft will include the these schemata, would
integration with Cybox be necessary?
Rgs,
Panos
-----Original Message-----
From:
[email-masked]<mailto:[email-masked]><mailto:mile-bounces@ietf
.org>
[mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Thursday, November 03, 2011 4:20 AM
To:
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [mile] CybOX and IODEF
Hi Tony,
Thank you for the information.
I like the CybOX work, and also think this should be supported by IODEF as
well.
Let me change our IODEF extension draft to support CybOX.
Thank you.
Take
-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]]
Sent: Wednesday, November 02, 2011 11:45 PM
To: Takeshi Takahashi;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: CybOX and IODEF
Hi Take,
I was wondering what is the reaction of you and other MILErs to the
introduction of the CybOX language this week at the SCAP Developer's
conference.  There are specific references to its serving as an underlying
means of integration with the incident exchange community.  See
http://scap.nist.gov/events/2011/itsac/presentations/day1/Struse,%20Barnum%2
0-%20Cyber%20Observables%20eXpression%20(CybOX)%20-%20Use%20Cases.pdf
especially slide 26.
It would seem appropriate for MILE to serve as a home for integration of
IODEF and CybOX.
best,
tony
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile