Subject: [mile] CybOX and IODEF

From: Tony Rutkowski <[email-masked]>
Date: Wed, 02 Nov 2011 10:44:33 -0400

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%20-%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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 3 Nov 2011 17:19:58 +0900

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]
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

---

From: "Panos Kampanakis" <[email-masked]>
Date: Tue, 8 Nov 2011 18:34:25 -0500

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]] On Behalf Of
Takeshi Takahashi
Sent: Thursday, November 03, 2011 4:20 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] CybOX and IODEF

Hi Tony,

Thank you.
Take

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2011 11:45 PM
To: Takeshi Takahashi; [email-masked]
Subject: CybOX and IODEF

Hi Take,

especially slide 26.

best,
tony

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

---

From: Luis Nunez <[email-masked]>
Date: Thu, 10 Nov 2011 08:54:14 -0500

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

---

From: <[email-masked]>
Date: Thu, 10 Nov 2011 09:14:17 -0600

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]>>
Date: Thu, 10 Nov 2011 07:54:14 -0600
To: Panos Kampanakis <[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

-ln

Take,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Takeshi Takahashi
Sent: Thursday, November 03, 2011 4:20 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [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]>
Subject: CybOX and IODEF
Hi Take,
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 11 Nov 2011 00:46:13 +0900

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]] On Behalf Of
[email-masked]
Sent: Friday, November 11, 2011 12:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [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

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Nov 2011 07:54:14 -0600
To: Panos Kampanakis <[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

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

Take,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Thursday, November 03, 2011 4:20 AM
To: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
[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]>
Subject: CybOX and IODEF
Hi Take,

---

From: "Barnum, Sean D." <[email-masked]>
Date: Thu, 10 Nov 2011 16:30:49 +0000

Yes, I do believe that CybOX needs to be its own context. CAPEC and MAEC
leverage CybOX but for specific use case contexts. There are other contexts
where CybOX will be leveraged under the covers (e.g. CEE, EMAP , etc.) and I
can certainly envision where it could be leveraged directly as well.
Assuming that it is adequately covered because CAPEC & MAEC are included
would be a mistake, I believe.

Sean

-----Original Message-----
From: Luis Nunez [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 8:54 AM
To: Panos Kampanakis
Cc: 'Takeshi Takahashi'; [email-masked]; Barnum, Sean D.; [email-masked]
Subject: Re: [mile] CybOX and IODEF

-ln

---

From: "Barnum, Sean D." <[email-masked]>
Date: Thu, 10 Nov 2011 16:32:03 +0000

I think this approach makes sense.

Thank you Takeshi.

sean

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 10:46 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Barnum, Sean D.
Subject: RE: [mile] CybOX and IODEF

 

Take

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

Kent Landfield

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

-ln

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]>
Subject: CybOX and IODEF
Hi Take,

---

From: <[email-masked]>
Date: Thu, 10 Nov 2011 10:54:42 -0600

Take,

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

You stated:

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.

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.

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.

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

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Takeshi Takahashi <[email-masked]<mailto:[email-masked]>>
Date: Thu, 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

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

Kent Landfield

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Luis Nunez <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
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

-ln

Take,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
[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,
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>

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

---

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

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,

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.

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.

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.

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

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Takeshi Takahashi
<[email-masked]<mailto:[email-masked]>>
Date: Thu, 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

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

Kent Landfield

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

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

-ln

Take,
-----Original Message-----
From:
[email-masked]<mailto:[email-masked]><mailto:mile-bounces@ietf
.org>
To:
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>;

---

From: Youki Kadobayashi <[email-masked]>
Date: Fri, 11 Nov 2011 12:15:36 +0900

Hi Kent and others,

I think three independent and interoperable implementations are
good enough to say the specification is reasonably well written and
community supports it.

For whatever XML-schema that IETF RFC points to, the same guiding
principle (as well as "rough consensus and running code") can be
applied.  Based on implementation experience (or at least spec
review by implementers) we can say something about quality of the
spec.

--
	Youki Kadobayashi
	WIDE Project / Nara Institute of Science and Technology

---

From: Luis Nunez <[email-masked]>
Date: Fri, 11 Nov 2011 10:53:29 -0500

I like the idea of "running code".  At minimum maybe a rough prototype IODEF document with all the relevant standards (expand on the IODEF-ext-sci example).  This may spark some simple tools to consume and generate incident communications.   

-ln

---

From: <[email-masked]>
Date: Fri, 11 Nov 2011 10:25:20 -0600

I totally agree with Youki. We need to follow the guidelines the  IETF has followed successfully for years.  This should properly address your quality concerns Take.

Kent Landfield

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Youki Kadobayashi <[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Nov 2011 21:15:36 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Luis Nunez <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] CybOX and IODEF

Hi Kent and others,

(11/11/11 1:54), [email-masked]<mailto:[email-masked]> wrote:
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.

---

From: <[email-masked]>
Date: Fri, 11 Nov 2011 11:55:11 -0500

Hi Kent,

The general IETF starting point to address this concern:

> 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.

is the IANA "Expert Review" process for managing new registrations.  See RFC 5226 for the definition of Expert Review and the discussion of the role of the designated expert.  One of the chairs of the mile WG would be a fine initial designated expert, and that role would outlive the mile WG's completion of work.  I'm probably an example, as WGs that I have chaired (and are now concluded) have created a number of registries, and I believe that I'm still the designated expert for some of them (I'm not 100% sure, as I don't recall seeing a registration request from IANA for quite a while now, but the registries are stable).

> good enough to say the specification is reasonably well written and

IETF is very flexible about what the designated expert has to review for, which could include evidence of multiple interoperable implementations, but that's not strictly required (the mile WG can decide what is appropriate).  One of the roles of the RFC that creates the registry is to lay out guidelines that the expert reviewer is expected to use in reviewing registration requests, and that RFC can also lay out other requirements for the expert, e.g., maintain a relationship w/some other standards body that's relevant (that's common in the storage space where I spend most of my time, as some crucial related standards like SCSI [no 'i'] are developed and published outside the IETF).

In addition, I'd encourage everyone to think about whether the requirements for registering a new specification should be different from registering a version update to an existing specification.  It's definitely possible to specify different levels of review for those two cases.

Finally, I would strongly suggest that "Specification Required" be added to "Expert Review" as a registration requirement so that any registration is accompanied by a public specification for the standard that has been registered.

As one can probably infer from this message, I've done a fair amount of IANA-related work, and I've already volunteered to Take in private that I will help write the IANA Considerations text that documents what the mile WG decides is appropriate.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, November 11, 2011 11:25 AM
> To: [email-masked]
> Cc: [email-masked]
> I totally agree with Youki. We need to follow the guidelines the  IETF has followed successfully for
> years.  This should properly address your quality concerns Take.
> 
> Kent Landfield
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Luis Nunez
> <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> 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.
> 
> --
> Youki Kadobayashi

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sat, 12 Nov 2011 11:00:54 +0900

Yes indeed :)
I also agree with you.

Thank you very much for the discussion.

Take

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

I totally agree with Youki. We need to follow the guidelines the  IETF has
followed successfully for years.  This should properly address your quality
concerns Take.

Kent Landfield

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Youki Kadobayashi
<[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Nov 2011 21:15:36 -0600
To: Kent Landfield
<[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>, Luis
Nunez <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] CybOX and IODEF

Hi Kent and others,

I think three independent and interoperable implementations are good enough
to say the specification is reasonably well written and community supports
it.

For whatever XML-schema that IETF RFC points to, the same guiding principle
(as well as "rough consensus and running code") can be applied.  Based on
implementation experience (or at least spec review by implementers) we can
say something about quality of the spec.

(11/11/11 1:54), [email-masked]<mailto:[email-masked]>
wrote:

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 15 Nov 2011 09:46:28 +0900

Hi David,

Thank you very much for your kind assistances online and offline.
Let me raise this review criteria issue at the session.

Best Regards,
Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, November 12, 2011 1:55 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mile] Registering new specification

Hi Kent,

> published something.  There needs to be some vetting that it will be truly
valuable to the community we are trying to serve.

is the IANA "Expert Review" process for managing new registrations.  See RFC
5226 for the definition of Expert Review and the discussion of the role of
the designated expert.  One of the chairs of the mile WG would be a fine
initial designated expert, and that role would outlive the mile WG's
completion of work.  I'm probably an example, as WGs that I have chaired
(and are now concluded) have created a number of registries, and I believe
that I'm still the designated expert for some of them (I'm not 100% sure, as
I don't recall seeing a registration request from IANA for quite a while
now, but the registries are stable).

> I think three independent and interoperable implementations are good 
> enough to say the specification is reasonably well written and 
> community supports it.

IETF is very flexible about what the designated expert has to review for,
which could include evidence of multiple interoperable implementations, but
that's not strictly required (the mile WG can decide what is appropriate).
One of the roles of the RFC that creates the registry is to lay out
guidelines that the expert reviewer is expected to use in reviewing
registration requests, and that RFC can also lay out other requirements for
the expert, e.g., maintain a relationship w/some other standards body that's
relevant (that's common in the storage space where I spend most of my time,
as some crucial related standards like SCSI [no 'i'] are developed and
published outside the IETF).

In addition, I'd encourage everyone to think about whether the requirements
for registering a new specification should be different from registering a
version update to an existing specification.  It's definitely possible to
specify different levels of review for those two cases.

Finally, I would strongly suggest that "Specification Required" be added to
"Expert Review" as a registration requirement so that any registration is
accompanied by a public specification for the standard that has been
registered.

As one can probably infer from this message, I've done a fair amount of
IANA-related work, and I've already volunteered to Take in private that I
will help write the IANA Considerations text that documents what the mile WG
decides is appropriate.

Thanks,
--David

> I totally agree with Youki. We need to follow the guidelines the  IETF 
> has followed successfully for years.  This should properly address your
quality concerns Take.
> <[email-masked]<mailto:[email-masked]>>, 
> Luis Nunez <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>"
> I think three independent and interoperable implementations are good 
> enough to say the specification is reasonably well written and 
> community supports it.
> 
> applied.  Based on implementation experience (or at least spec review 
> by implementers) we can say something about quality of the spec.
> 
> (11/11/11 1:54),
[email-masked]<mailto:[email-masked]> wrote:
> 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.