Fast Track Review
Common Data Security Architecture (CDSA)
This section contains the following information for eligible voting reviewers of The Open Group CDSA Fast Track specifications:
email archives
|
Fast Track ReviewCommon Data Security Architecture (CDSA)This section contains the following information for eligible voting reviewers of The Open Group CDSA Fast Track specifications: |
| PKI
Task Group email archives |
Dear CDSA Reviewer,
The Common Data Security Architecture (CDSA) defines a
horizontal, multi-layer architecture. The layering distinguishes
application developers from security service providers, from
infrastructure providers. The CDSA specification is partitioned
among thirteen documents in order to address the needs of these
three distinct audiences. Most of the documents are normative,
(they define programming interfaces) and a small number are
descriptive and/or informative.
While it is essential to review all of the documents in the CDSA specification, it is exceptional that an individual reviewer can review the complete set of specifications without undue burden. It is likely that each reviewing organization will partition and distribute the review process among a set of reviewers. The CDSA specification documents are partitioned to address the needs and perspectives of the three audiences listed above. This parititioning should simplify an organization's efforts to distribute the review process.
To further assist you in this effort, Intel, as the sponsor of the CDSA proposal, has provided the following categorization of CDSA specification documents.
CDSA defines a horizontal, four-layer architecture:
Three categories of developers are represented:
All Developers (CDSA layers 1 through 4):
Application Developers (CDSA layers 1 and 2):
Normative specification documents:
Descriptive/Informational specification documents:
CSSM Infrastructure Providers (CDSA layer 3):
Normative specification documents:
Descriptive/Informational specification documents:
Security Service Module Developers:
Normative specification documents:
Descriptive/Informational specification documents:
The fast-track review of the Common Data
Security Architecture set of specifications submitted to The Open
Group by Intel Corporation
will start on August 8 and finish on September 30.
The review will be carried out via the existing open e-mail alias
which includes interested parties from both inside and outside of The Open Group membership. Experts from companies who are not members of The Open Group have the right to comment on the specifications and submit change requests but not to vote. The voting entitlement belongs to those who have committed resource to the process through membership of The Open Group, i.e. sponsors, technical buy-out members, specification members, and duly elected representatives of The Open Group Customer and Software Councils.
The vote will be carried out via the e-mail alias
which is a subset of pki-tg consisting of representatives coming from TOG member companies entitled to vote, plus the nominated Council representatives. The companies entitled to vote are hereby asked to make sure that their input to this review is coordinated and that they have nominated a single representative coordinating their input and entitled to cast the vote on behalf of the company. The Technical Managers who currently do not have a representative on the pki-tg alias but wish to add one should send that person's name, phone number and e-mail address to
Piers McMahon p.mcmahon@opengroup.org .
If you nominate several representatives for the review, please indicate which one will have the right to vote on behalf of your organization. All those nominated to the pki-wg alias will also automatically be added to the pki-tg list.
The documents under review will be by the start date made available to the review group via The Open Group's Web site; appropriate notification will be sent out. Guidance will be provided by Intel on how to best review the specification set, taking into account the differing interests of the various categories of reviewers.
The review will be conducted in accordance with the appended procedure. A consolidated list of references to all Change Requests received during the review period will be circulated to the group and Intel on October 1st. This is to check that all submitted Change Requests have been received and registered. Intel's proposal for disposition of each one of the submitted Change Requests will be circulated to the pki-tg alias at latest by October 21st. On the first working day after the response has been received, the ballot table for these proposals will be sent out and the balloting members of pki-wg will be asked to cast their vote within one week. The ballot results will be communicated to Intel on the next working day after the end of the ballot period. Intel will announce their response to the outcome of the vote within one week after that.
PROCEDURE
1. All requests for modifications must be the subject of formal change requests. They should be submitted via electronic mail sent to the review group address.
2. Immediately after been received from the submitter, the proposals recommending how each submitted change request be responded to shall be circulated to the review group, together with a ballot form.
3. ALL members entitled to vote shall vote by electronic mail via the ballot group alias on EVERY submitted proposal within the agreed period. The votes will be counted and the results circulated immediately after the end of the ballot period.
4. A `clear majority' is declared on each proposal if and only if at least 75% of votes cast (excluding abstentions) are in the same direction; i.e. a proposal can be `clearly accepted' or `clearly rejected' or `unresolved'. [Further discussion of the unresolved change requests during an agreed period might be needed. Eventually, only those that reach 75% approval will be accepted.]
5. The outcome of the vote will immediately be communicated to the submitter.
6. After agreed period, the submitter will announce their response to the outcome of the vote.
FORMAT OF CHANGE REQUESTS
All change requests must follow the same format, which has a number of
headings as described below. Please submit changes in `straight-ASCII',
not troff-source or other strange formats. Limit line lengths to 80
characters, page heights to 60 lines. Break pages with form-feeds
between change requests, or failing that don't break pages at all.
DON'T PAD PAGES WITH BLANK LINES: not everybody uses the same size
paper as you!
Start your submission e-mail with the following two entries which
then do not have to be repeated for each Change Request.
Document: Which document the Change Request refers to.
Source: name of the company submitting the request
Then enter each change request in the following format. The "@"
character must be in the first character position on the line:
@ Page <pageno> Line <lineno> Change Number <aaa-nnn>
Change number: with sequence numbers of form <aaa-nnn>
where <aaa> are company initials and
<nnn> is change request number of the form
[digit][digit][digit]
Allocate numbers sequentially within your company.
Title: one-liner describing the request
Qualifier: nature and severity of the change requested.
Possible values are:
- Severity: Minor, Major, Critical
- Nature: Editorial, Technical
Rationale: reason that change is needed, reason that suggested
change is preferred over other possibilities, etc.
This is your chance to persuade other companies to
support the change request.
Change: Please include page numbers AND line numbers AND section
numbers to identify the location affected and to assist in
collation. Then specify detailed edits which must be made
to the text.
The format of the first line should be as follows:
page <number|range> line <number|range> section <number|range>
NOTE that page and line numbers or ranges must not include
spaces: 1-2,3,5-6 is valid, but 1-2 3 5-6 is interpreted as
1-2. (see example below for correct usage)
There may be cases where the originator feels unable to
provide text, for example where a clarification is
requested. In such cases there are two possibilities:
- write down one of the possible alternatives. This at
least serves to illustrate your concern.
- contact someone else, in advance, who may be able to
suggest some wording.
To emphasize:
CHANGE REQUESTS WITHOUT EXPLICIT EDITING INSTRUCTIONS
WILL BE REJECTED.
------------------------------------------------------------------------
EXAMPLE CHANGE REQUEST
----------------------
Document : X/Open ACSE/Presentation (XAP) Specification
Source : ABC Co Ltd
@ Page 36 Line 1000-1020 Change Number ABC-017
Change number: ABC-017
Title : Accessibility of AP_PCDL environment attribute.
Qualifier : Minor Technical
Rationale : The presentation context definition list serves only to
inform the called application and presentation provider
of the presentation contexts that were proposed by the
calling application. Its modification by the calling
application following an A_ASSOCIATE_ind has no
Significance.
To prevent possible incorrect usage of the XAP API, it
should therefore be writable only in the AP_UNBOUND and
AP_IDLE states by the calling application.
Change : page 36 line 1000-1020 section 5.7
In the table under AP_ENV(), describing the environment
attributes and their read/write accessibility, delete the
state AP_WASSOCrsp_ASSOCind in the "AP_PCDL" row and
"Writable" column.
Wherever possible we have identified contact points for further information. If you can't find the information you need, please contact The Open Group at any of of the following locations:
