Re: [cti] Working Call Recap and action items

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I still think versioning of SCOs is not
being fully thought through. RE the breaking changes on the meaning of
"created"
and "modified" on several SCOs and how to deal with this. I don't
see a clear solution proposed.

Another aspect I don't see fully thought-through
here is that SCOs do not exist in isolation, they still "live"
inside one or more observed-data SDOs. Those SDOs *themselves* have full
versioning capabilities.

 If we are going to allow versioning
of SCOs, then someone needs to come up with a clear explanation of the
workflows expected:

* When would someone version the SCO
vs the SDO? Why can I not do "the email use case" by versioning
the observed-data SDO? This makes a lot more sense to me because what I
am doing is re-reporting the observation with more information, I am not
changing the email itself.

* What happens when an SCO is versioned
but the SDO is not, or vice-versa, creating a conflict? Does that make
any sense? What happens when the version dates become mis-aligned?


-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple,
really. Double your rate of failure."

- Thomas J. Watson



From:      
 Bret Jordan <Bret_Jordan@symantec.com>
To:      
 "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:      
 04/23/2019 06:23 PM
Subject:    
   [cti] Working
Call Recap and action items
Sent by:    
   <cti@lists.oasis-open.org>

---

All,

We had a good working call today, thanks
to everyone for joining the discussion.  The things we talked about
were (sorry this is a bit long):

1) Release Train.  The consensus
on the call was to wait on releasing working draft 04 until the TC has
had a chance to review the mini-group proposals for Infrastructure and
COA. These will be scheduled for an upcoming working call.  Just so
everyone understands, this will push the completion of Milestone 2 out
to mid or late May at the earliest.  If you disagree with this, please
speak up on the list. The alternate proposal is to release Working Draft
04 now, and when we do Working Draft 05 include Infrastructure and COA
at that point, since it may take several weeks or a month to get that done.
 This way the broader TC can start reviewing Working Draft 04 now.

2) JSON and I-JSON references. We
talked through this and seemed to have solid consensus if not unanimity
on making these changes. The editors will get this implemented in the documents.
If you have questions or issues with this, please speak up.

3) We had a good but short discussion
on the SCO relationships and which are being deprecated and being moved
to external relationships. Just so everyone fully understands, here are
the relationships that are being deprecated and moved to external:

a) Domain Name Object: resolves_to_refs
b) IPv4 Address Object: resolves_to_refs,
belongs_to_refs
c) IPv6 Address Object: resolves_to_refs,
belongs_to_refs
d) Network Traffic Object: encapsulates_refs,
encapsulated_by_refs

For a, b, and c the rational is that an
external relationship will allow you to time box the resolution so you
can say that it resolved to foo.com from 2015 to 2016 and bar.com from
2017 to 2018. Embedded relationships do not allow this.

I am not sure how to explain d though.
 Maybe someone can speak up and explain why that one is being deprecated
and what the use case is.    If not, then maybe that one should
be left as embedded. 

Action Item: Jason and John-Mark
are going to work on some text that describes what it means to be "deprecated"


4) We started the long discussion
on what it means for a SCO to be versioned.  While we did not get
consensus on the call, we semi-mostly stayed civil in our discussion.  We
will need to pick this up again next week to try and resolve this with
the broader TC. We also need to remember that a proposal from a Mini-Group
is not TC Consensus.  It may have achieved consensus in the Mini-Group,
but we need the whole TC to agree, regardless of the amount of time and
effort that went in to the Mini-Group.  Some times mini-groups produce
proposals that sail right through, sometimes the TC as a whole wants more
input, and that is okay. 

The major points on this topic today were:

a) Often when we talk about these use cases,
we respond with the "IP Address is a fact" use case.  However,
we need to be thinking about this from the Email Message or File / Artifact
use case. 

b) Having the ability to do data markings
on a SCO seems like a super critical use-case that people need and want.
 But by doing this, this kind-of forces having some of the other properties.

c) Some people want the ability to have
a revoked property on SCOs, some think revoking is not really going to
work so why have it.

b) Can you version an object if you do
not have a created_by_ref.  Some think you can and think that it will
enable you to know who versioned it, others think this is a bad idea as
it will prevent re-use.  If the created_by_ref is found and the object
ID is deterministic, you should be able to de-dup and aggregate the data.
 

e) Can SCOs have translations?  Should
you be able to say that an email was written in language FOO or language
BAR or that a translation to JP is being provided?

f) There is a difference between calling
something out in the spec as "optional" and allowing it via "custom
properties".  We have been down this road many many times in
the past.  They are not the same thing. 

I personally believe that everyone agrees
that SCOs, at this time (2.1-2.x), are NOT going to be the same thing as
SDOs and SROs.  However, there seems to be some requests for a bit
more than what came out of the mini-group and last F2F. 

The mini-group work did not have any of
the common properties other than "type" and "id".  However,
at the last F2F, there was a push to add data markings and "created"
and "modified". What was agree is they would be "optional"
and not "required".  Later in the F2F there was also a desire
to add "spec_version", but we could not get agreement on it being
required and thus it went in as "optional" (even though that
might be weird from an interoperability standpoint).  

Now it seems like the last hurtle that
people are looking to address is to possibly add a few more of the common
properties as optional.  This could be as simple as just saying we
will add:
a) "revoked" and "lang"
b) "created_by_ref", "revoked",
and "lang"
c) Just add all of them but as optional
to make things easier 


The fundamental options I see are:
I) Do nothing more than what we have right
now
II) Add a few more properties (TBD which)
III) Add the rest of the properties
IV) Remove all versioning from SCOs (not
that I agree with this, but adding it for completeness) 


If you read this far, thank you.  We
will pick this critical topic up again next week.

Bret