Subject: [mile] Call for WG Reviews of RFC5070-bis

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 13 Dec 2013 09:23:46 -0500

Hello,

RFC5070-bis will move to working group last call as scheduled in January.  Reviews prior to last call are extremely important to ensure the WG has addressed any major concerns in the draft.  Please take the time to review the draft that will result in an IODEF v2.0.  Reviews and discussion of reviews should all be posted to [email-masked].  If something is more sensitive, please send it to the editors and copy Brian and myself so that we see the activity and interest.

This will be the easiest time to get your requested changes in as we can allow for detailed discussions that may be necessary.  Reviews will be encouraged during last call as well within a 2 week period in January.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis 

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Saturday, October 19, 2013 9:11 PM
To: [email-masked]
Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt

Hello!

A new version of 5070bis has been published as -02.  The following is a list of the changes:

** (schema) Added Contact/ContactTitle to describe the title of the contact (Issue #35)
** (schema) Added System/AssetId to represent an opaque asset identifier (Issue #33)
** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, Description, AdditionalData} (Issue #31 and partial #22)
** (schema) Changed cardinality of Incident/RelatedActivity to be 0..many in Incident (needed for Issue #31)
** (schema) Added System@virtual to convey whether a device is physical or virtual (Issue #16)
** (schema) Added Incident@purpose={watch} (Issue #17)
** (schema) Added System@ownership to describe asset ownership (Issue #34)
** (schema) Various fixes to schema to make it valid 
** (editorial) Minor spelling fixes

Roman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, October 19, 2013 9:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF.

	Title           : The Incident Object Description Exchange Format v2
	Author(s)       : Roman Danyliw
                          Paul Stoecker
	Filename        : draft-ietf-mile-rfc5070-bis-02.txt
	Pages           : 112
	Date            : 2013-10-19

Abstract:
   The Incident Object Description Exchange Format (IODEF) defines a
   data representation that provides a framework for sharing information
   commonly exchanged by Computer Security Incident Response Teams
   (CSIRTs) about computer security incidents.  This document describes
   the information model for the IODEF and provides an associated data
   model specified with XML Schema.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rfc5070-bis-02

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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: Jerome Athias <[email-masked]>
Date: Mon, 16 Dec 2013 19:13:08 +0300

Hi,

after a quick review, here are some notes:

Nice work!

The attributes are sometimes missing into the figures.
Examples:
3.11.1.
and in many cases the (new) indicator-uid and indicator-set-id (3.12.,
3.15., 3.18.2., 3.19., 3.21.1., ...)

Sometimes the sentence "The X class has no attributes." is missing, i.e.: 3.18.

In 3.4, should
"activity described the IODEF document"
be
"activity described in the IODEF document"
?

In 3.9.1 should
"A means by which"
be
"A mean by which" (or meaning)
?

Is the word "STRING" missing in 3.22.1. for KeyName and Value?
Is Value a full path? (if so, maybe it should be clarified)
(I will review later the registry action default enumeration)

I would review the relationships between FileName and FileSize in
3.23. HashInformation Class

(I would prefer to have ProtoCode and ProtoType to be ProtocolCode and
ProtocolType)

Maybe the virtual enumeration (3.17. System Class) could have also "unknown"

I would double-check the description of duration in 3.18.1.

Could we discuss the possibility to extend the Application (and so
OperatingSystem) Class?, with:
name
lang
or/and an extension mechanism

Contact Class
It should be difficult to use a RACI matrix (if needed) with the
actual roles enumeration

Cardinality of 0..1 between Incident and AlternativeID (I would have
to investigate further, but it could lead to some issues while
consolidating information for the same incident described by 2+
parties)

I like to use a ConfidenceReason when describing/exchanging a Confidence
NB: It also helps for making automated choices at a parser level
And also for automation, "asset" or "system" could be useful in the
type enumeration of 3.9. Contact class

I will try to review the XML part (is everything documented?
EMailDetails (should maybe be EmailDetails), DomainData,
HashSigDetails...)
I will think about the user-agent
(and maybe come with some thoughts about predictability next year)

My 2c for now

Best regards
/JA

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 19 Dec 2013 21:54:23 +0000

Hi Jerome,

Thanks for the thorough review!  Comments inline ...

> From: mile [mailto:[email-masked]] On Behalf Of Jerome Athias
> Sent: Monday, December 16, 2013 11:13 AM
> To: Moriarty, Kathleen
> Cc: [email-masked]
> Subject: Re: [mile] Call for WG Reviews of RFC5070-bis
> 
> Hi,
> 
> and in many cases the (new) indicator-uid and indicator-set-id (3.12., 3.15.,
> 3.18.2., 3.19., 3.21.1., ...)

Concur.  Good catch.  This will be fixed.

> Sometimes the sentence "The X class has no attributes." is missing, i.e.: 3.18.

Concur.  This will be fixed.

> "activity described in the IODEF document"

Concur.  Your text "activity described in the IODEF document" is the better language to use

> "A mean by which" (or meaning)

Disagree.  The "A means by which" is the standard language used by all of the ext-* attribute write-ups.
 
> Is the word "STRING" missing in 3.22.1. for KeyName and Value?

Concur.  STRING is missing.

> Is Value a full path? (if so, maybe it should be clarified) (I will review later the
> registry action default enumeration)

Did you mean is KeyName a full path?  I'm not sure what a full path is for a registry value (i.e., the Value class).

> I would review the relationships between FileName and FileSize in 3.23.
> HashInformation Class

Concur.  This came up as an issue and is tracked in Ticket #20 (http://trac.tools.ietf.org/wg/mile/trac/ticket/20).  While identified, it is not yet resolved.
 
> (I would prefer to have ProtoCode and ProtoType to be ProtocolCode and

I see how this change would be cleaner.  Balanced against the backward compatibility of IODEF-v1, do you think it's worth the change?

> Maybe the virtual enumeration (3.17. System Class) could have also

Concur.  "unknown" will be added.

> I would double-check the description of duration in 3.18.1.

Could you please be a little more specific? Is the text clumsy, not clear in some way, or both?

> or/and an extension mechanism

Do you have a specific proposal in mind, or is the list above data you'd like to see represented?

How does this list match against the Platform class in draft-ietf-mile-sci-12?

> Contact Class
> It should be difficult to use a RACI matrix (if needed) with the actual roles
> enumeration

Could you provide an example of where the current approach would break?

> Cardinality of 0..1 between Incident and AlternativeID (I would have to
> investigate further, but it could lead to some issues while consolidating
> information for the same incident described by 2+
> parties)

Could you provide an example of where the current cardinality wouldn't be adequate?  While an Incident can only have 0..1 AlternativeIDs, an AlternativeID has many IncidentIDs potentially from many organizations.

> NB: It also helps for making automated choices at a parser level And also for
> automation, 

Can you clarify (or provide an example of) of your thinking about "ConfidenceReason"?  Is there a need to document why a particular confidence value was chosen?

> "asset" or "system" could be useful in the type enumeration of
> 3.9. Contact class

Can you clarify (or provide an example of) what it would mean to have a Contact@type="system"?  Is it to convey contact information at the asset level?  If so, a System and Contact class can already be represented grouped together with an EventData class.

> (and maybe come with some thoughts about predictability next year)

We're very appreciative for this feedback Jerome!

Roman

> > RFC5070-bis will move to working group last call as scheduled in January.
> Reviews prior to last call are extremely important to ensure the WG has
> addressed any major concerns in the draft.  Please take the time to review
> the draft that will result in an IODEF v2.0.  Reviews and discussion of reviews
> should all be posted to [email-masked].  If something is more sensitive, please
> send it to the editors and copy Brian and myself so that we see the activity
> and interest.
> >
> > This will be the easiest time to get your requested changes in as we can
> allow for detailed discussions that may be necessary.  Reviews will be
> encouraged during last call as well within a 2 week period in January.
> >
> > ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence,
> > Description, AdditionalData} (Issue #31 and partial #22)
> > ** (schema) Changed cardinality of Incident/RelatedActivity to be
> > 0..many in Incident (needed for Issue #31)
> > ** (schema) Added System@ownership to describe asset ownership
> (Issue
> > #34)
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >