Re: [EXT] Fwd: FW: Comments for PR of TAXII 2.1

Chet / Jacques,

Thanks for the comments and suggestions. Since these came outside the public 30-day window, I would prefer to not formally accept and track them. However, I will try and address some of them in the next working draft and subsequent public review. Then if they are not addressed to your satisfaction, you can resubmit during the 2nd public review period. Would this be deemed an acceptable compromise? Also, please note that the conformance section has not changed at all since TAXII 2.0 CS 01 and the public review of TAXII 2.0.

If I may, I would like to generally address some of the comments. I think there is a balance between readability and organization of a specification standard. I agree with some of the guidelines that were called out, but I also think some flexibility needs to exist on a case by case basis. For example, yes, there is part of the conformance that reads more like prose text given the normative statements. We had tried unsuccessfully in the past (early TAXII 2.0 timeframe) to include them in the main parts of the document. But to make them clear, it proved to be overly complicated and required a lot more prose text. Therefore we purposefully moved them to the conformance section and it greatly simplified things and thus IMO made things more clear.

Part of the confusion also stems from the fact that we identified conformance levels that will enable future conformance levels without a complete restructuring of the conformance section. Meaning, we know where this specification is going to be 2-5 versions from now, and we wanted to start calling out elements specifically as they exist today. So you have the idea of a TAXII Collections server as an option, which is a specific version of a TAXII Server. In the future there will be other TAXII Server Types that will flesh out this conformance section and cause divergent elements to exist. By calling things what they are now, it prevents changes to terminology later on, which I am trying to avoid as that just confuses the market.

So what I am trying to say is, most all of the decision about the conformance section and the language in it, was done purposefully and specifically to address certain problems or issues.

Bret

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

cti-comment message