[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
From: Chet Ensign <chet.ensign@oasis-open.org>
Sent: Tuesday, January 22, 2019 8:49:39 AM
To: Bret Jordan; cti-comment@lists.oasis-open.org
Cc: OASIS TAB; Jacques Durand
Subject: [EXT] Fwd: FW: Comments for PR of TAXII 2.1Â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Â
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]