Subject: [mile] ppt slides for the discussion

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 30 Jul 2012 08:08:43 +0900

Hello all,

The attached is the slides I would like to use at the MILE session on
Tuesday.
If I am missing some points, please kindly let me know.
I would appreciate your kind assistance.

Thank you.
Take

> -----Original Message-----
> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Sunday, July 22, 2012 11:14 PM
> To: 'Panos Kampanakis (pkampana)'; 'Waltermire, David A.';
> [email-masked]'; [email-masked]'
> Subject: RE: [mile] Nits on SCI draft and point for discussion
> 
> Thank you for your kind clarification.
> I agree on that as well.
> 
> Sincerely,
> Take
> 
> 
> > -----Original Message-----
> > From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
> > Sent: Sunday, July 22, 2012 10:58 PM
> > To: Takeshi Takahashi; 'Waltermire, David A.';
> > [email-masked]; [email-masked]
> > Subject: RE: [mile] Nits on SCI draft and point for discussion
> >
> > I think, as Dave also suggested, that doc A doesn't need to be based
> > on IODEF Ref Class or SCI. It will just define the identifier format
> > and namespace. Then that can be used in IODEF's Ref Class, SCI's
> > References or other places.
> >
> > Panos
> >
> >
> >
> >
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:[email-masked]]
> > Sent: Friday, July 20, 2012 8:58 PM
> > To: Panos Kampanakis (pkampana); 'Waltermire, David A.';
> > [email-masked]; [email-masked]
> > Subject: RE: [mile] Nits on SCI draft and point for discussion
> >
> > Hi all,
> >
> > I agree with both of you on that we intend to define proper method to
> > embed identifier and namespace.
> > I was thinking that the SCI draft could use the draft doc A for
> > describing SCI classes.
> > I think that was what we have discussed in Paris.
> >
> > On the other hand, I think we need to discuss whether we design doc
> A
> > based on the Reference class or not.
> > Allow me the repetition I've mentioned in the mailing list before:
> >
> > If we define draft doc A based on IODEF reference class, the structure
> > cannot be used within the SCI draft as it is.
> > (pros and cons are described in former emails.) But if the community
> > thinks that is better idea than other options, that is fine.
> > In that case, I would suggest to define all of the SCI classes by
> > extending the newly defined Reference class, instead of allowing doc
> A
> > and SCI draft to have different ways of embedding the identifiers.
> >
> > The direction of how to define the draft doc A is the bottleneck of
> > SCI draft work, and I hope we could agree upon clear direction on this
> > by the end of the Vancouver meeting.
> >
> > Thank you.
> > Take
> >
> >
> >
> > From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
> > Sent: Saturday, July 21, 2012 3:44 AM
> > To: Waltermire, David A.; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [mile] Nits on SCI draft and point for discussion
> >
> > Makes sense.
> > Panos
> >
> >
> > From: Waltermire, David A. [mailto:[email-masked]]
> > Sent: Friday, July 20, 2012 2:08 PM
> > To: Panos Kampanakis (pkampana); [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [mile] Nits on SCI draft and point for discussion
> >
> > I agree, but I think we should go further than what you are
> > suggesting.  We should identify, in a separate document (doc A), a
> > method to identify an identifier format and namespace using an IANA
> > registry.  We should then in SCI and/or IODEF define how the namespace
> > and ids are used relative to the registry defined in doc A.  Think of
> > this as an encoding of the information that doc A specifies.  This
> > would provide a foundation for other efforts to define how to use
> > identifier formats described by doc A.  This will be of great use to
> future SACM efforts at minimum.
> >
> > Sincerely,
> > Dave
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Panos Kampanakis
> > Sent: Wednesday, July 11, 2012 11:14 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [mile] Nits on SCI draft and point for discussion
> >
> > Now I understand, and remember the discussion.
> >
> > My personal opinion is that the way of represented the enumerated
> > values should be a separate document. SCI defines the extensions, but
> > the enumerated value representations could better be served separately
> > and used in other models too. Also, I think these changes should not
> > apply to IODEF Reference classes, but to the SCI Reference classes.
> > This falls within this draft's scope (extensions for structure cyber
> security).
> > Doing it in IODEF I think may fall out of scope for this work.
> >
> > Thank you,
> > Panos
> >
> >
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, July 11, 2012 8:43 AM
> > To: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: Nits on SCI draft and point for discussion
> >
> > Hi Panos,
> >
> > Thanks for weighing in!  I am not quite clear on your response, so let
> > me try again to see if I can better explain the questions I was hoping
> > to get consensus on from the WG.  If you and others could clarify your
> > preferences in approach for these options, it would be very helpful.
> > My questions are based on the current proposal in the SCI draft and
> to
> > figure out if that is right or if we want to do this another way.
> >
> > We will need guidance to be written somewhere to establish a
> > consistent way to represent enumerated values.  We can either do this
> > in the SCI draft in a new section or in a separate draft as Adam
> > Montville proposed a while back. Getting working group consensus on
> > how we want to represent these values and if we should do this in the
> > SCI draft or another draft would be good in addition to consensus on
> > where we think the values should be placed (in the IODEF Reference
> > class or in the Reference classes embedded in the extensions of the
> > SCI draft as is currently proposed in the draft).  The update to IODEF
> > would handle any changes to the Reference class as you clearly stated.
> >
> > I think there are a few other points we will need to make sure we have
> > consensus on from the SCI draft to help wrap it up, but let's see if
> > we can tackle these first.
> >
> > Thank you!
> > Kathleen
> >
> >
> >
> > From: Panos Kampanakis [mailto:[email-masked]]
> > Sent: Tuesday, July 10, 2012 2:36 PM
> > To: Moriarty, Kathleen; [email-masked]; [email-masked]
> > Subject: RE: Nits on SCI draft and point for discussion
> >
> > Hi Kathleen,
> >
> > Maybe I didn't completely get the suggestion, but why would creating
> a
> > new IODEF Reference Class with a predefined IANA table table fall
> > within SCI's scope? Is it only in order to pre-define CVE, CEE etc to
> > be included in the references in SCI? I think that makes sense.
> > But I believe that., as Take suggested, if the Reference Class is
> > updated in IODEF then the new Reference Class can be used in SCI,
> > after the "allowed reference item" new IANA table is defined.
> >
> > Rgs,
> > Panos
> >
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of [email-masked]
> > Sent: Friday, July 06, 2012 12:53 PM
> > To: [email-masked]; [email-masked]
> > Subject: [mile] Nits on SCI draft and point for discussion
> >
> > Hi Take,
> >
> > I am reading through the SCI draft again and noticed a few nits:
> >
> > In the paragraph right before the start of section 4, there is a typo
> > in the first word, it should say "Another".
> >
> > In figure 1, there are two bars for each of the included classes under
> > EventData, is that correct?
> >
> > Section 4.3.1:  Says the following:
> > "It is recommended that Method class SHOULD contain one or more of the
> >    extension elements whenever available."
> >
> > Can you explain the reasoning?  It does only say should, so it is
> > optional, but I would like to understand the reason for the statement.
> >
> > Discussion Point:
> >
> > In IODEF, the Method Class includes a Reference Class.  I know that
> > you can include just a CVE number using the SCI draft, but it requires
> > the use of the new Vulnerability Class (or other extended class with
> > the embedded Reference class from IODEF).  I think it would be cleaner
> > to use the Reference class in IODEF when the purpose is just to
> > include a CVE number and URL or other enumerated values directly into
> > the Reference class.  The part missing from the IODEF draft is a an
> > exact specification on how to include the enumerations in a standard
> > way.  The discussion by Adam and Dave provided an option everyone
> > seemed to agree upon, the preferred option required a change to IODEF,
> > which will be possible soon (there were options do not require that
> modification).
> >
> > If people agree, can we update your draft to include that method and
> > make a clear distinction from when you include a full XML document and
> > when you just include an enumerated value, like for CVE using the
> > IODEF method class and a format specified in the SCI draft for that?
> > This would also require a second IANA table as it would not require
> > the use of an SCI extension and would specify the format to represent
> > the enumerated value and included URL.
> >
> > I would like to hear opinions on the SCI method versus creating a
> > second table that allows the use of the IODEF Reference class directly
> > (no extension required).  The table would explicitly state how to
> > format the reference to the enumerated values and would allow any
> > enumerated value (of a registered format) to be included directly in
> the reference class.
> >
> > Thank you!
> > Kathleen
> >
> > Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO |
> > 617-851-5807 | [email-masked]  | EMC Corporation
> >
> >
> >

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 30 Jul 2012 08:35:01 +0900

Let me change the slides a bit, and use the attached instead, sorry.

Thank you.
Take

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Takeshi Takahashi
> Sent: Monday, July 30, 2012 8:09 AM
> To: [email-masked]
> Subject: [mile] ppt slides for the discussion
> 
> Hello all,
> 
> > > I agree with both of you on that we intend to define proper method
> > > to embed identifier and namespace.
> > > If we define draft doc A based on IODEF reference class, the
> > > structure cannot be used within the SCI draft as it is.
> > > SCI draft work, and I hope we could agree upon clear direction on
> > > this by the end of the Vancouver meeting.
> > >
> > > Thank you.
> > > Take
> > >
> > >
> > >
> > > registry.  We should then in SCI and/or IODEF define how the
> > > namespace and ids are used relative to the registry defined in doc
> > > A.  Think of this as an encoding of the information that doc A
> > > specifies.  This would provide a foundation for other efforts to
> > > define how to use identifier formats described by doc A.  This will
> > > be of great use to
> > > values should be a separate document. SCI defines the extensions,
> > > but the enumerated value representations could better be served
> > > separately and used in other models too. Also, I think these changes
> > > should not apply to IODEF Reference classes, but to the SCI Reference
> classes.
> > > Thanks for weighing in!  I am not quite clear on your response, so
> > > let me try again to see if I can better explain the questions I was
> > > hoping to get consensus on from the WG.  If you and others could
> > > clarify your preferences in approach for these options, it would be
> very helpful.
> > > consistent way to represent enumerated values.  We can either do
> > > this in the SCI draft in a new section or in a separate draft as
> > > Adam Montville proposed a while back. Getting working group
> > > consensus on how we want to represent these values and if we should
> > > do this in the SCI draft or another draft would be good in addition
> > > to consensus on where we think the values should be placed (in the
> > > IODEF Reference class or in the Reference classes embedded in the
> > > extensions of the SCI draft as is currently proposed in the draft).
> > > The update to IODEF would handle any changes to the Reference class
> as you clearly stated.
> > >
> > > I think there are a few other points we will need to make sure we
> > > have consensus on from the SCI draft to help wrap it up, but let's
> > > see if we can tackle these first.
> > >
> > > Thank you!
> > > Kathleen
> > >
> > >
> > >
> > > within SCI's scope? Is it only in order to pre-define CVE, CEE etc
> > > to be included in the references in SCI? I think that makes sense.
> > > In the paragraph right before the start of section 4, there is a
> > > typo in the first word, it should say "Another".
> > >
> > > In figure 1, there are two bars for each of the included classes
> > > under EventData, is that correct?
> > >
> > > you can include just a CVE number using the SCI draft, but it
> > > requires the use of the new Vulnerability Class (or other extended
> > > class with the embedded Reference class from IODEF).  I think it
> > > would be cleaner to use the Reference class in IODEF when the
> > > purpose is just to include a CVE number and URL or other enumerated
> > > values directly into the Reference class.  The part missing from the
> > > IODEF draft is a an exact specification on how to include the
> > > enumerations in a standard way.  The discussion by Adam and Dave
> > > provided an option everyone seemed to agree upon, the preferred
> > > option required a change to IODEF, which will be possible soon
> > > (there were options do not require that
> > modification).
> > >
> > > make a clear distinction from when you include a full XML document
> > > and when you just include an enumerated value, like for CVE using
> > > the IODEF method class and a format specified in the SCI draft for
> that?
> > > the use of an SCI extension and would specify the format to
> > > represent the enumerated value and included URL.
> > >
> > > second table that allows the use of the IODEF Reference class
> > > directly (no extension required).  The table would explicitly state
> > > how to format the reference to the enumerated values and would allow
> > > any enumerated value (of a registered format) to be included
> > > directly in
> > the reference class.
> > >
> > > Thank you!
> > > Kathleen
> > >

---

From: Brian Trammell <[email-masked]>
Date: Mon, 30 Jul 2012 06:45:11 -0700

Hi, Take, all,

Thanks! The slides are now available on the Meeting Materials page.

Best regards,

Brian

On Jul 29, 2012, at 4:35 PM, Takeshi Takahashi wrote:

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