Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 1 Apr 2013 17:53:21 +0900

Hello all,

Thank you for your kind support to the draft.

Before the draft goes to the WGLC, we are currently reviewing the content of
the draft once again.
Let me update the draft and come back to the mailing list with revised
version in a couple of weeks.

Thank you.
Take

> -----Original Message-----
> From: Moriarty, Kathleen [mailto:[email-masked]]
> Sent: Thursday, March 28, 2013 9:59 AM
> To: Takeshi Takahashi; [email-masked]
> Subject: RE: [mile] Consensus Call - SCI draft MMDEF as MTI
> 
> Hello,
> 
> Thank you for voicing your opinions at the MILE meeting, the two week
period
> is up and we have full agreement.  We will move forward with MMDEF as the
> MTI for the SCI draft.
> 
> Take - Thank you for updating the draft to include MMDEF as the MTI as
well
> as the update below.  Could you expand the acronym for MTI in the draft
> and update the version to the latest?
> 
> Bets regards,
> Kathleen
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Takeshi Takahashi
> Sent: Saturday, March 23, 2013 4:17 AM
> To: [email-masked]
> Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI
> 
> Hi all,
> 
> I remember the discussion on the EICAR and agree upon David's kind
> suggestion.
> The attached is the revised SCI draft, whose section 10 talks about the
> EICAR (with an example XML).
> 
> Kind regards,
> Take
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Black, David
> > Sent: Thursday, March 14, 2013 11:54 PM
> > To: Moriarty, Kathleen; [email-masked]
> > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI
> >
> > I support MMDEF as the MTI, and since MMDEF is a malware spec, I'd
> > like to resurrect a previously-discussed suggestion that the SCI draft
> > include discussion of the "EICAR Standard Anti-Virus Test File" as a
> > specific
> example
> > that SHOULD (or MUST?) be supported for black-box testing purposes.
> >
> > See: http://www.eicar.org/86-0-Intended-use.html
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Moriarty, Kathleen
> > > Sent: Thursday, March 14, 2013 10:38 AM
> > > To: Panos Kampanakis (pkampana); [email-masked]
> > > Subject: Re: [mile] Consensus Call - SCI draft MMDEF as MTI
> > >
> > > Hello Panos,
> > >
> > > Thank you for joining us remotely!  The recording is available for
> > > those who were not able to attend during the session.
> > >
> > > We need to choose one included schema as MTI for 'black box' testing
> > > of the method described.  Essentially, if you can exchange using the
> > > MTI spec, then any other specs supported should theoretically work
> > > as the pattern has been established.
> > >
> > > MMDEF was recommended as it is in use by the eCrime WG as an
> > extension
> > > to IODEF/RFC5901.  It replaced the method to include malware in
> > > exchanges and seemed to make sense to adopt more broadly as it is
> > > maintained by a group in IEEE focused on that particular problem.
> > >
> > > BTW, I meant to say the last call will end in two weeks from
> > > yesterday, Wednesday March 27th.
> > >
> > > Thank you!
> > > Kathleen
> > > ________________________________________
> > > From: Panos Kampanakis (pkampana) [[email-masked]]
> > > Sent: Thursday, March 14, 2013 9:59 AM
> > > To: Moriarty, Kathleen; [email-masked]
> > > Subject: RE: Consensus Call - SCI draft MMDEF as MTI
> > >
> > > I agree with MMDEF included in SCI.
> > > I am not sure why it must be MTI. Due to some audio problems I
> > > missed part of the call yesterday. Can you briefly summarize why we
> > > want it
> MTI?
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Moriarty, Kathleen
> > > Sent: Wednesday, March 13, 2013 3:04 PM
> > > To: [email-masked]
> > > Subject: [mile] Consensus Call - SCI draft MMDEF as MTI
> > >
> > > Hello,
> > >
> > > In today's MILE session, a call for consensus began to include MMDEF
> > > in the SCI draft as the mandatory-to-implement (MTI) specification.
> > > The call for consensus will last for 2 weeks and we ask that you
> contribute
> > your opinion.
> > > The vote in the room was unanimous and we want to make sure we hear
> > > from participants not in attendance.
> > >
> > > Poll will end on Wednesday next week.
> > >
> > > Thank you!
> > > Kathleen
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> > > _______________________________________________
> > > mile mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mile
> >
> > _______________________________________________
> > mile mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mile

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Apr 2013 08:36:06 -0400

Next week that URI can change. It is not an IEEE standard, so there is no P number. Since it is not an IEEE standard, you cannot buy or reference the spec from IEEE.

Is there someone involved with the MMDEF work who can find out about a stable reference? We don't need an RFC, but we do need something that is likely to be there next month. An individual informational RFC would work, too.

Another alternative is to do a wink and a nudge and have IODEF say there are things out there for malware identification. One could use something *like* MMDEF which you *might* be able to find at the IEEE-SA industry site. It would be an informative reference, so there would be no violation of IETF rules.  That approach will not promise long-term interoperability, but it is better than nothing.

On Mar 28, 2013, at 8:35 AM, "Martin, Robert A." <[email-masked]> wrote:

> This page would seem to provide that.
> 
> <http://standards.ieee.org/develop/indconn/icsg/mmdef.html>
> 
> On 3/27/13 10:25 PM, Eric Burger wrote:
>> Did we ever find a stable reference for MMDEF?
>> 
>> On Mar 27, 2013, at 8:59 PM, "Moriarty, Kathleen" <[email-masked]> wrote:
>> 
>>> Hello,
>>> 
>>> Thank you for voicing your opinions at the MILE meeting, the two week period is up and we have full agreement.  We will move forward with MMDEF as the MTI for the SCI draft.
>>> 
>>> Take - Thank you for updating the draft to include MMDEF as the MTI as well as the update below.  Could you expand the acronym for MTI in the draft and update the version to the latest?
>>> 
>>> Bets regards,
>>> Kathleen
>>> 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
>>>> Black, David
>>>> I support MMDEF as the MTI, and since MMDEF is a malware spec, I'd like to
>>>> resurrect a previously-discussed suggestion that the SCI draft include
>>>> discussion of the "EICAR Standard Anti-Virus Test File" as a specific
>>> example
>>>>> MTI spec, then any other specs supported should theoretically work as
>>>>> the pattern has been established.
>>>>> 
>>>>> I am not sure why it must be MTI. Due to some audio problems I missed
>>>>> part of the call yesterday. Can you briefly summarize why we want it
>>> MTI?
>>>>> 
>> .

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 3 Apr 2013 20:08:09 +0900

Hi Eric,

Thank you for your kind email.
Yes, this is an issue that had been bothered us.
I appreciate your kind consideration.

I understood that we have somehow agreed to use MMDEF as an MTI, though it
is not an official IEEE standard, because the link seems to be stable (with
version control).
Do I need to change the above understanding?
Hopefully not, but if necessary, we need to do that.

If so, I am not sure what would be a feasible approach for that.
One approach is, as you have suggested, to use MMDEF as an MTI and reference
it as an informative reference.

Alternatively, could we include the schema of the MMDEF so that the draft
itself can become a stable reference?
(of course, we need to ask permission to the MMDEF community.)
The name space could be changed to http://www.ietf.org/draft-IODEF-SCI-mti,
for instance.

The purpose of having MTI is to check interoperability, thus the above
approach could be ok, I guess.

I would appreciate any assistance or guidance.

Thank you.
Take

> Eric Burger
> Sent: Monday, April 1, 2013 9:36 PM
> To: Martin, Robert A.
> Cc: [email-masked]
> Next week that URI can change. It is not an IEEE standard, so there is no
> P number. Since it is not an IEEE standard, you cannot buy or reference
> the spec from IEEE.
> 
> Is there someone involved with the MMDEF work who can find out about a
stable
> reference? We don't need an RFC, but we do need something that is likely
> to be there next month. An individual informational RFC would work, too.
> 
> Another alternative is to do a wink and a nudge and have IODEF say there
> are things out there for malware identification. One could use something
> *like* MMDEF which you *might* be able to find at the IEEE-SA industry
site.
> It would be an informative reference, so there would be no violation of
> IETF rules.  That approach will not promise long-term interoperability,
> but it is better than nothing.
> 
> period is up and we have full agreement.  We will move forward with MMDEF
> as the MTI for the SCI draft.
> >>>
> >>> Take - Thank you for updating the draft to include MMDEF as the MTI
> as well as the update below.  Could you expand the acronym for MTI in the
> draft and update the version to the latest?
> >>>
> >>> Bets regards,
> >>> Kathleen
> >>>
> >>> Of Takeshi Takahashi
> >>> The attached is the revised SCI draft, whose section 10 talks about
> >>> the EICAR (with an example XML).
> >>>
> >>> Kind regards,
> >>> Take
> >>>
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Black, David
> >>>> like to resurrect a previously-discussed suggestion that the SCI
> >>>> draft include discussion of the "EICAR Standard Anti-Virus Test
> >>>> File" as a specific
> >>> example
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>> Behalf Of Moriarty, Kathleen
> >>>>> We need to choose one included schema as MTI for 'black box'
> >>>>> testing of the method described.  Essentially, if you can exchange
> >>>>> using the MTI spec, then any other specs supported should
> >>>>> theoretically work as the pattern has been established.
> >>>>>
> >>>>> missed part of the call yesterday. Can you briefly summarize why
> >>>>> we want it
> >>> MTI?
> >>>>>
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>> Behalf Of Moriarty, Kathleen
> >>>>> In today's MILE session, a call for consensus began to include
> >>>>> MMDEF in the SCI draft as the mandatory-to-implement (MTI)
> specification.
> >>>>> The vote in the room was unanimous and we want to make sure we
> >>>>> hear from participants not in attendance.
> >>>>>

---

From: Eric Burger <[email-masked]>
Date: Wed, 3 Apr 2013 19:00:21 -0400

The approach you mention, importing the markup, with permission, into an appendix, is precisely what we did for RFC 6787. We imported the NLSML markup once we found out that (1) no one planned to use EMMA and (2) the W3C did not plan on publishing NLSML.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 4 Apr 2013 09:54:59 +0900

Ok, then let me try to contact them.
I will post some messages to MMDEF's mailing list.
Hopefully they could give us a good answer.

Let me come back to here later.

Take

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, April 4, 2013 8:00 AM
> To: Takeshi Takahashi
> Cc: [email-masked]
> The approach you mention, importing the markup, with permission, into an
> appendix, is precisely what we did for RFC 6787. We imported the NLSML
markup
> once we found out that (1) no one planned to use EMMA and (2) the W3C did
> not plan on publishing NLSML.
> 
> > I understood that we have somehow agreed to use MMDEF as an MTI,
> > though it is not an official IEEE standard, because the link seems to
> > be stable (with version control).
> > One approach is, as you have suggested, to use MMDEF as an MTI and
> > reference it as an informative reference.
> >
> > Alternatively, could we include the schema of the MMDEF so that the
> > draft itself can become a stable reference?
> > (of course, we need to ask permission to the MMDEF community.) The
> > name space could be changed to
> > http://www.ietf.org/draft-IODEF-SCI-mti,
> > for instance.
> >
> >> Of Eric Burger
> >> Next week that URI can change. It is not an IEEE standard, so there
> >> is no P number. Since it is not an IEEE standard, you cannot buy or
> >> reference the spec from IEEE.
> >>
> >> reference? We don't need an RFC, but we do need something that is
> >> likely to be there next month. An individual informational RFC would
> work, too.
> >>
> >> Another alternative is to do a wink and a nudge and have IODEF say
> >> there are things out there for malware identification. One could use
> >> something
> >> It would be an informative reference, so there would be no violation
> >> of IETF rules.  That approach will not promise long-term
> >> interoperability, but it is better than nothing.
> >>
> >> period is up and we have full agreement.  We will move forward with
> >> MMDEF as the MTI for the SCI draft.
> >>>>>
> >> as well as the update below.  Could you expand the acronym for MTI in
> >> the draft and update the version to the latest?
> >>>>>
> >>>>> Bets regards,
> >>>>> Kathleen
> >>>>>
> >>>>> Behalf Of Takeshi Takahashi
> >>>>> The attached is the revised SCI draft, whose section 10 talks
> >>>>> about the EICAR (with an example XML).
> >>>>>
> >>>>> Kind regards,
> >>>>> Take
> >>>>>
> >>>>>
> >>>>>> I support MMDEF as the MTI, and since MMDEF is a malware spec,
> >>>>>> I'd like to resurrect a previously-discussed suggestion that the
> >>>>>> SCI draft include discussion of the "EICAR Standard Anti-Virus
> >>>>>> Test File" as a specific
> >>>>> example
> >>>>>>> Thank you for joining us remotely!  The recording is available
> >>>>>>> for those who were not able to attend during the session.
> >>>>>>>
> >>>>>>> testing of the method described.  Essentially, if you can
> >>>>>>> exchange using the MTI spec, then any other specs supported
> >>>>>>> should theoretically work as the pattern has been established.
> >>>>>>>
> >>>>>>> exchanges and seemed to make sense to adopt more broadly as it
> >>>>>>> is maintained by a group in IEEE focused on that particular
problem.