Hello PbD-Seers.
I am sorry that will my work load I have not had adequate bandwidth to give the WD4 an adequate editorial review. However, I did want to make known, for
the record, my concern about moving this document to Committee Specification Draft.
My apologies for missing the call today. Hopefully, my colleague, Frederick Hirsch can join, but I am busy still at work, here in Finland.
Agenda item #4 for today’s call asks for group to approve the WD4 to be approved as a Committee Specification Draft.
I am concerned that the WD4 is still at a working draft product quality. As a Committee Specification Draft, I expect that the following editorial errors
would not have been found
1)
A Committee Specification Draft document needs to meet product quality levels that this Working Document does reflect. The document text has
not been edited for consistent language use, as it shows multiple-editor’s style of writing and needs to be put into one OASIS specification style of writing. The document has numerous vernacular usage of English (e.g., use of “app” instead of “application”)
that needs editing out of the document.
2)
While the document has improved as a Working Draft it still contains significant mistakes (e.g., §2.1.2.2 is titled, “Limiting Collection,
Use, and Retention” and the following sub-section 2.1.2.3 is titled “Limiting Collection” and §2.1.2.2 the last bullet states “• in compliance with applicable laws and regulations.”, which is not related to the titled section).
3)
This document is a Standards Track document and needs to have a completely specified Conformance Clause (see OASIS Policies-Guidelines §2.18
Work Product Quality, (8a)). Clause 5.9 is not structured in accordance. While the proposal is to move this to Committee SpecificIt only lists Table 4.1 in another clause as the conformance elements.
4)
The use of “conformance” in this version of the document is inconsistent. Some places it refers to what the software engineering processes
must follow to be conformance to the specification. In other places it refers to, inappropriately to privacy regulation compliance, but states “privacy conformance”. This puts into serious question the readiness as a Committee Specification Draft.
5)
The use of conformance terminology such as “SHALL” in “Table 4.1. Mapping of Privacy-by-Design Principles to Software Engineering Referenced
and Generated Documentation” is overtly prescriptive. However, the Introduction clearly states, in part, “The PbD-SE specification does not represent a prescriptive set of rules”. The document needs more editing to narrow the use of conformance terms to scope
intended by an OASIS standards track document. Additionally, a mix of “must” and “shall” is found within the document.
6)
In addition, Table 4.1 confuses requirements for organizational privacy governance with business process requirements. These two need to be
undone. This specification is about specification of requirements for software engineering processes to be conformant to best practices for privacy engineering. Organizational privacy governance is not within the scope for this specification.
We should take this document through another round of review and update.
Frank/
From: pbd-se@lists.oasis-open.org [mailto:pbd-se@lists.oasis-open.org]
On Behalf Of ext Gershon Janssen
Sent: Tuesday, June 10, 2014 19:17
To: pbd-se@lists.oasis-open.org
Subject: [pbd-se] PROPOSED AGENDA - PbD-SE TC - 11 June 2014
Privacy by Design Documentation for Software Engineers (PbD-SE) TC
11 June 2014, 1:30-2:15 PM EDT / 19.30-20.15 CET (45 minutes)
Please find attached and below the draft agenda for the OASIS PBD-SE TC meeting.
See separate email with call-in information.
1. New Business / Approval of Agenda
2. Approval of Previous Meeting Minutes
3. Feedback for Working Draft 1.0 Revision 4 by TC members
4. Consideration of the following motion [with TC members amendments]:
Draft motion: "Move that the TC approve "Privacy by Design Documentation for Software Engineers Version 1.0" Working Draft 4 contained in