OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [Non-DoD Source] Re: [cti] Incident Extension Draft


Understood, weâll keep it focused as a property extension, but any community feedback is welcome as our goal for this extension is to attempt to capture the majority use case not just DC3âs to avoid having producers and consumers need to handle a large number of potential extensions. Doubly so when submitting data to USG sources or getting data from them.

 

//SIGNED//

 

Jeffrey Mates, Civ DC3/TSD

Computer Scientist

Technical Solutions Development

jeffrey.mates@dc3.mil

410-694-4335

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of aa tt
Sent: Monday, August 2, 2021 9:25 PM
To: JG @ OASIS <jg@ctin.us>
Cc: cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] Incident Extension Draft

 

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.


 

First of, Jeff - thanks to you and the team that presumably worked to put together this extension proposal. Much appreciated to all of you.

 

Regarding top-level vs property-extension question that you raised and Jane replied to.

 

I would strongly suggest sticking with the your current proposal as a property-extension and not making it a top-level extension.

 

The primary reason that incident has remained a contentious issue in the TC is that there are multiple definitions of incident and its unlikely to achieve consensus due to the multiple use cases that can have incident as a core part of their data model. As we know there are multiple examples of incident workflows throughout the industry and we need to approach this particular data model challenge with modularity in mind. Not assuming one teamâs view is the only view.

 

I suggest we stay with your proposed property-extension to avoid all the problems that a top-level extension brings. It also means that if people find a core part of your incident important and want to use it with their additional aspects of incident then they can do that more easily even if there are naming conflicts in properties.

 

This is why we preferred and suggested using property-extension as the primary mechanism to extend STIX and *NOT* using top-level extension. 

 

Allan



On Aug 2, 2021, at 2:41 PM, JG @ OASIS <jg@ctin.us < Caution-mailto:jg@ctin.us > > wrote:

 

Jeffery:

This is great.  We really need this.  I agree with your roadmap of moving this to a top-level extension for a future draft.

Jane


On 8/2/2021 11:30 AM, Mates, Jeffrey CIV DC3/TSD wrote:

Based on a number of internal discussions I wanted to provide a draft for a
proposed Incident property extension for general community consideration.
I've attached the raw JSON Schema of the current draft (still not on GitHub)
as well as three examples using it.  Since currently the Incident object
exists as a stub I am hoping that with some community feedback this could be
shared and provide a more general way to share this information.

While it is currently drafted as a property extension, if there is general
agreement that whatever we arrive at is solid I could change this to a
top-level extension before sharing to prepare it to eventually be moved into
the spec as part of a future version of STIX.

//SIGNED//

Jeffrey Mates, Civ DC3/TSD
Computer Scientist
Technical Solutions Development
jeffrey.mates@dc3.mil < Caution-mailto:jeffrey.mates@dc3.mil > 
410-694-4335

--
**********************************
R. Jane Ginn, MSIA, MRP
OASIS, CTI TC Secretary
OASIS, TAC TC Secretary
jg@ctin.us < Caution-mailto:jg@ctin.us > 
**********************************


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
Caution-https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]