Mark,
On the conformance clause issue, just so we have a common starting
point, the TC Process requires:
*****
A specification that is approved by the TC at the Committee
Specification Public Review Draft, Committee Specification or OASIS
Standard level must include a separate section, listing a set of
numbered conformance clauses, to which any implementation of the
specification must adhere in order to claim conformance to the
specification (or any optional portion thereof).
*****
The conformance clauses as proposed don't meet the requirement of
being numbered nor do they state any basis for conformance to those
clauses. See elsewhere isn't a conformance clause.
I wasn't a party to drafting that requirement but I suspect there
were two main reasons for that language:
1) To provide the best chance that implementers will read the same
requirements for conformance to all or part of a specification. To
say:
*****
Conformant implementations must conform to all Normative Statements
that apply to the portions of TAXII they implement
*****
leaves implementers at the mercy of hoping that all other
implementers read the portions of TAXII the same way.
Contrast that with sets of conformance clauses that enumerate the
portions of TAXII (I assume that means conformance targets) and
under each target lists numbered clauses that state the conformance
requirements.
Each set of conformance clauses would identify some portion, such
as Discovery Service and so I could be assured that anyone saying
they conform to Discovery Service, do in fact conform to the
enumerated clauses.
2) For procurement purposes, of governments or enterprises, both of
who are very interested in security products, the enumerated and
numbered conformance clauses provide the means to specify the
capabilities or characteristics that are desired for a particular
project.
It would look odd in a RFP to say: applications that conform to all
the normative statements for Discovery Service in TAXII.
Yes?
3) Ease of reference can be increased by well written, numbered
conformance clauses. For example, you can page after page of prose
when all you really wanted to check was: MUST conform to Extensible
Markup Language (XML) 1.0 (Fifth Edition).
4) My personal hobby horse is that well written conformance clauses
reduce the need for oddly worded prose and replace it with
statements of fact. The datatype of attribute X is (insert
content). You can say The datatype of attribute X MUST be (insert
content). but that reads oddly.
The bulk of the standard becomes a series of factual declarations
and you can move all the RFC terms into the conformance clauses.
Which gives you a much smaller surface to check for proper usage of
RFC terms.
Those are some of the general issues with the conformance clauses
that obtain without looking at the specific standard content in
question.
Oh, one closing example, an implementer can't discover from the
proposed conformance clauses, what other portions of TAXII exist,
much less what their conformance requirements might be.
True, they can labor through the document to discover them, maybe,
but the question there is do you want to encourage implementation
of TAXII or do you want to make it onerous?
Hope you are having a great day!
Patrick
On 07/14/2015 08:51 AM, Davidson II,
Mark S wrote:
The
Conformance section was written with that guidance in mind.
In fact, the Conformance Guidelines were extremely helpful
(I have no prior experience writing OASIS Conformance
Clauses).
Based
on what I know (and please recognize that I’m new at this) I
think the conformance clause, as written, functions
as intended. I’m not sure whether to take the list’s silence
as acceptance or not, but if there are no comments the
conformance clause will likely go in pretty close to as-is.
If
there are specific comments that those more experienced can
offer, I’m more than happy to hear them. I recognize part of
making those comments requires understanding TAXII, and I
can help with that.
Thank
you.
-Mark
From:
[ mailto: ]
On Behalf Of Chet Ensign
Sent: Monday, July 13, 2015 1:47 PM
To: Jordan, Bret
Cc: Davidson II, Mark S;
; OASIS TAB
Subject: Re: [cti-taxii] TAXII Conformance - proposed
language
Hi Bret -
Sure. I'm not
suggesting any substantive change to the specification at
all. Just suggesting that the conformance clause language
be thought through from the perspective that I described.
A conformance clause section is a requirement so I'm just
suggesting making sure it does what it is intended to do.
/chet
On Mon, Jul
13, 2015 at 1:38 PM, Jordan, Bret <
>
wrote:
Chet,
IMO,
that would represent something we would do in TAXII
2.0 as we lock down the protocol to more of single
implementation. This initial version, from the
statement of the CTI Charter is to be just an OASIS
version of the MITRE specification that is already
in wide use today. If we make substantive changes,
it will be in violation of the charter. And most of
the TAXII specification is optional today. For
example there is no hard and fast rule that requires
you to use HTTP or XML. Intact, we have several
groups using JSON based TAXII today.
Thanks,
Bret
Bret
Jordan CISSP
Director
of Security Architecture and
Standards
Office of the CTO
Blue
Coat Systems
PGP
Fingerprint: 63B4 FC53 680A
6B7D 1447 F2C0 74F8 ACAE
7415 0050
Without
cryptography vihv vivc ce
xhrnrw, however, the only
thing that can not be
unscrambled is an egg.
On Jul 13,
2015, at 08:55, Chet Ensign <
>
wrote:
Hi Mark
& all -
I have
copied the OASIS TAB (Technical
Advisory Board) on my reply as the
group has done a lot of work (and
continues to do a lot of work) on
helping TCs craft conformance
clauses. The TAB maintains a
document with guidelines on how to
draft conformance clauses that may
be useful here: http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html
You might
want to talk with them a bit and
consider spelling out conformance
clauses in a bit more detail.
Here's why: the conformance
clauses are intended to act as a
litmus test - a set of yes/no
questions if you will - that an
implementer can check off in order
to know whether or not they can
claim conformance to the Committee
Specification / OASIS Standard.
That is important because the
OASIS patent protections
specifically apply to conforming
implementations.
As you
say, the clauses do not change in
any way the requirements in the
specification. They simply act as
the checklist for conforming
implementations. So that is the
way I would think about them.
Best,
/chet
On Mon,
Jul 13, 2015 at 8:23 AM, Davidson
II, Mark S <
>
wrote:
All,
As
Bret and I work toward
converting TAXII into a set
of OASIS documents, we came
across the OASIS requirement
for a conformance section,
which TAXII 1.1 does not
have. One example of an
OASIS conformance section is
the Universal Business
Language (UBL) specification
[1].
TAXII
1.1 does not have a
conformance section, and
instead relies on RFC 2119
normative statements (e.g.,
statements containing
MUST/SHOULD/MAY) throughout
the document. The OASIS
conformance section seems to
be a mechanism for wrapping
the many Normative
Statements in a
specification into a
condensed set of higher
level
statements/requirements.
Bret
and I have drafted a
proposal for the conformance
section of the TAXII
Services Specification. The
goal of the proposed text is
to meet the OASIS
requirement for a
conformance section without
altering the requirements
for TAXII. This text is not
intended to add, modify, or
remove any requirements from
TAXII 1.1. If you feel this
text might not meet that
criteria, please speak up.
Without
further preamble, here is
the proposed text. Your
feedback is welcome.
Conformance
Implementations
have discretion over which
parts of TAXII they
implement (e.g., Discovery
Service).
Conformant
implementations must conform
to all Normative Statements
that apply to the portions
of TAXII they implement
(e.g., Implementers of the
Discovery Service must
conform to all Normative
Statements regarding the
Discovery Service).
Conformant
implementations are free to
ignore Normative Statements
that do not apply to the
portions of TAXII they
implement (e.g.,
Non-implementers of the
Discovery Service are free
to ignore all Normative
Statements regarding the
Discovery Service).
The
conformance section of this
document is intentionally
broad and attempts to
reiterate what already
exists in this document. The
TAXII 1.1 Specifications,
which this specification is
based on, did not have a
conformance section.
Instead, the TAXII 1.1
Specifications relied on
normative statements. TAXII
1.1.1 represents a minimal
change from TAXII 1.1, and
in that spirit no
requirements have been
added, modified, or removed
by this section.
Thank
you.
Mark
and Bret
[1]
http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-CONFORMANCE
--
/chet
----------------
Chet Ensign
Director of Standards
Development and TC
Administration
OASIS: Advancing open
standards for the
information society
http://www.oasis-open.org
Primary: +1
973-996-2298
Mobile: +1
201-341-1393
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC
Administration
OASIS: Advancing open standards for the information
society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
--
Patrick Durusau
Technical Advisory Board, OASIS (TAB)
OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau
