Closed johnwunder closed 6 years ago
if someone intended to publish a new marking definition for an object from TLP Green to TLP Amber then they would also republish the objects because the objects themselves presumably have changed somehow to warrant going back from more open disclosure to more closed disclosure. this use case is covered by modification rules on the obejcts themselves and the relationships to marking objects. however, i’m suggesting a different use case which is where an existing marking definition was published with a mistake or needs a tweak to remain correctly defined. its a more common use case and likely to happen. right now we would force people to have to create a new marking definition and literally have to update all objects from the previous marking definition to the new one. thats a substantially more negative impact
in either case (whether you allow only create or modification) the recipient still has detect the change and then do something about it. with allowing modification on marking objects then there will be a lot less new STIX objects created vs if you create to create a new marking object you need to go and modify all the obejcts that used the prior marking definition too. The recipient would have process either case the same anyway and all we are doing is forcing a lot more noise over the wire to communicate something that can be communicated by a modification to the marking object, the recipient detects that change and then looks up in their view what has to be redone themselves (or not). There is no enforcement to begin with anyway. So we are making a decision at a system level that has a big impact on the system when products can take care of the issue in either scenario
I can see an argument to support allowing markings to be revoked, but am against allowing them to otherwise be modified. Though I suppose "revoking" would require a new version anyway. So I guess I'm opposed to allowing revoking, too.
I am against allowing it to be versions as well. I worry about the legal aspects of that.
Bret
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Jul 14, 2017, at 10:22 AM, Greg Back notifications@github.com wrote:
I can see an argument to support allowing markings to be revoked, but am against allowing them to otherwise be modified. Though I suppose "revoking" would require a new version anyway. So I guess I'm opposed to allowing revoking, too.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Maybe you can introduce a multi-member voting requirement before revoke's are granted.
This was discussed at the working call on 2/13/18. The consensus on the call was to NOT make this change. The poll was: For the change: 0 Against the change: 9 (Sarah Kelley, Chris Ricard, Mark Davidson, Richard Struse, Nicholas Hayden, Paul Patrick, Bret Jordan, Sean Barnum, Philip Royer) Abstain: 1
The call for objections ended COB 02 March with no objections received to the TC mailing list. QED, we are closing this issue.
In STIX 2.0, marking definitions cannot be versioned.
Allan Thomson has suggested allowing versioning of them. The idea is that it would reduce network traffic and that the end result is the same.