[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Re: [EXT] Re: [cti] Working Call Recap
Arenât bundles designed to be thrown away? So if the information is only kept at the bundle level for how the identifier is generated, you would lose that information as soon as the bundle drops on the floor. You could never retransmit
with that information (in the use case that you were passing along data you didnât create), and the consumer wouldnât be able to go back and reference it in the future.
Am I missing something? Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
On Behalf Of Sean Barnum I see two options.
Sean Barnum Principal Architect FireEye M: 703.473.8262 From: <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org> How do we handle bundles that contain SCOs with different methods of creating the UUID? For instance - Iâm just passing on various SCOs I received from different producers, who used different methodsâ From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> After talking with Sean on the phone about this, even though this is very late in the game, I think this really makes a lot of sense. I think if we would have thought about this during the Mini-Group we probably would have done this from
the get go. Basically, to be really clear, what he is proposing is that we move the id_method and id_method_details from individual SCOs to the Bundle. The pros I see are: 1) less bloat on the wire 2) simplify some of the indicator text We can talk about this in next weekâs working call. Bret Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]