Fwd: FW: Comments for PR of TAXII 2.1

[Chet Ensign <chet.ensign@oasis-open.org>]

Bret, and members of the CTI TC, please accept our apologies for missing the deadline. As you can see below, Jacques realized this arrives late but wants to share the feedback all the same.Â

As these comments are arriving after the close of the public review period and after your announcement Bret that no comments were received, accepting and addressing them is yourÂcall. If you find them helpful, by all means, follow up.Â

Again, apologies for the late arrival and regardless, congratulations on advancing TAXIIÂv2.1 so expeditiously.Â

Best,Â

/chet

---------- Forwarded message ---------
From: jdurand@fujitsu.com <jdurand@fujitsu.com>
Date: Mon, Jan 21, 2019 at 10:53 PM
Subject: FW: Comments for PR of TAXII 2.1
To: Chet Ensign <chet.ensign@oasis-open.org>
Cc: Patrick Durusau <patrick@durusau.net>

Chet:

Â

Forwarding this to you, so you can transmitâ

It seems that the deadline is already passed a few hours (midnight UTC) but I still like for the TC to get this comment.

For some reason, it did not go through the cti-comment list.

Usually Patrick and I start by logging the comments on JIRA but it seems that TAXII 2.1 is not recorded on the Versions attribute (?) although older TAXII 2.0 is.

Â

Thanks,

-ÂÂÂÂÂÂÂ Jacques

Â

From: Durand, Jacques
Sent: Monday, January 21, 2019 7:48 PM
To: 'cti-comment@lists.oasis-open.org' <cti-comment@lists.oasis-open.org>
Subject: Comments for PR of TAXII 2.1

Â

Overall I find the specification well-written but I am focusing here on a weak point of many specifications:

The ÂConformance clause. Although there is clearly some good work into it, Âthis conformance clause is still confusing:

1.ÂÂÂ Looking at 8.1.1 and 8.1.2: it seems there is nothing that distinguishes TAXII server from TAXII collection serverâ the former IS the same as the latter based on 8.1.1 ?

2. Normally, a conf clause should not have normative keywords MUST SHOULD MAY â these belong to the normative body of the spec. In particular, no SHOULD and MAY. Please look at conformance guideline on public TAB site: http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html

3.ÂÂÂ 8.1.3 Channels Server: what is RESERVED?

4. Ââmandatory server featuresâ 8.2. These should be referred to explicitly from 8.1.1 and 8.1.2. More generally Section 8 should be structured as a set of Clauses (see again TAB guideline above) where each clause is clearly identified, and being the single entry point to all that is necessary to conform with.

5.ÂÂÂ Section 8.2.2: are these conformance requirements for Servers as defined above? If yes the conf clauses of server(s) should explicitly refer to that section as including its requirements.

6.ÂÂÂ Section 8.3: Conformance clause should not need to state anything optional: either an implementation satisfies it or not. All optionalities and recommendations belong to the normative body of spec. The conf clauses only need to refer to these.

7.ÂÂÂ Section 8.5.2 reads too much like a part of the spec itself. Why isnât it inside the specification body as normative content? Then the conf clause can refer to it. As a general rule, anything that can be moved up in the spec body, should. The conf clause then is overseeing the normative content in spec body, referring as needed to subsets of it, upgrading a âshouldâ as a âmustâ occasionally for its conformance level.

8.ÂÂÂ The âconformance targetsâ (what kinds of implementations can claim conformance) should be clearly identified from the start and Âideally I the spec body, before the conformance section. See again conformance guideline on public TAB site: http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html .

9.ÂÂÂ Same comments for Clients.

10.It would be good to identify the types of implementations that will be of interest (i.e. become conformance targets, in the conf clause) early on in the specification, so that many normative requirements unambiguously . For example in 3.1: ââThe endpoint path in a requests to a TAXII server MUST end in a trailing slash "/"ââ What kind of implementation is supposed to satisfy this requirement in order to conform? Seems like a Client. But in the conf clause, we see nothing referring to 3.1. All normative content in the spec Âshould be referred one way or the other by some conf clause! And that referencing chain should be clear.

Â

Other than that, one can recognize the work and details that went into defining conformance. The content is there in general, but rather confusing. Just needs be more structured, some of it really belongs to spec body (as normative content), more explicit references to some normative content, and optionality removed in conformance section â or only very exceptionally there.

Â

Best,

Jacques Durand.

TAB member

Â

Â

--

/chetÂ
----------------

Chet Ensign

Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â