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: [cti] Normative Statements

I would argue that if a normative statement can not be tested then it is not actually normative and is just a guideline.

It should be noted that we aren't even talking about "automated testing" - the proposed normative statement is not even testable in the mind of a human reading the document, because they have no idea if the things in the bundle were intended by the producer to be related or not.

As such, I agree with Alan that such statements serve little purpose in a spec and belong more in a set of implementor guidelines.

Sent from my mobile device, please excuse any typos.

Eric Burger --- [cti] Normative Statements ---

From:"Eric Burger" <Eric.Burger@georgetown.edu>
Date:Tue, Nov 15, 2016 7:28 PM
Subject:[cti] Normative Statements

MUST all normative statements be testable?

I suppose it depends on what we mean by testable. A few have said that not everything that we have as normative statements are not, in fact, testable. I would offer that is a proof point of something that cannot be normative.

Let us take an example:
Implementations of TAXII servers that offer TLP MUST NOT forward STIX documents marked TLP Red to non-trusted destinations.

This sounds like a fantastic requirement. However, this is what that requirement translates to when we write code:
Implementations of TAXII servers that offer TLP MUST NOT forward STIX documents marked TLP Red to non-trusted destinations, unless they feel like it because it is impossible for the sender to know what the recipient does once they receive and decode the document.

Now we can have such statements in requirements documents or system conformance documents. However, they are meaningless in protocol or document definition documents. In fact, I would offer they are dangerous. Let us consider this example. I am a consumer of CTI technology. I read the specs, and a TAXII server MUST NOT forward a STIX document marked TLP Red to non-trusted destinations. I am looking at a vendor, and their product “is fully compliant with the TAXII specification.” Too bad for me there is no way to hold them to the fire if they do improper forwarding. It’s way too late to call the Protocol Police.

While I am on my soapbox, since I just saw a dialog here along the lines of “Bundles SHOULD not have related objects in them,” I would like to reiterate the best practice for MUST/SHOULD/MAY. 

Note that given the formulation of SHOULD, specifically that the conditions under which the implementation does not do the SHOULD, leads us to a clearer formulation of SHOULD, namely the conditional MUST. Using the above example, instead of:
The implementation SHOULD implement X, unless Y or Z are present.
It is clearer to say:
If Y and Z are not present, the implementation MUST do X.

Beating the dead horse: every SHOULD and MAY in the specification non-linearly increases the likelihood of implementation errors and interoperability failures. The spec is already extremely hard to implement - JSON does not eliminate cyclomatic complexity! There is no reason to hand our adversaries which is supposed to make or more resilient to attack an infrastructure begging for attack.

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