OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Groups - PbD-SE Version 1.0 Revision 4 - R3 uploaded

Submitter's message
Compilation of TC edits in one document across all sections but Section 2.

SECTION 1 Notes: Incorporated the great majority of edits from John, Stuart, Jonathan, Sander, Colin, Gail, and Fred.
Further requests for clarification and comments to address TC?s edits and comments
@Stuart: Page 5, please can you further explain why we may need to clarify ? beyond user/data subject preferences? in the spec?

@Jonathan: I intend to add text and an edited diagram to illustrate how the Privacy by Design Use Case Template can be adapted for agile methodology and user stories. So the ?however? is not needed. I have suggested to John that we can rename it to the Privacy Use Template so that agile methodologists do not incorrectly surmise that the PbD-SE spec is not applicable to them.

@John: We may leave a few further details about the PMRM to Section 5 without loss to the PbD-SE introduction. I left in the PMRM reference as normative as you correctly stated that the PbD-SE WD asserts that Privacy Use Template is RECOMMENDED for embedding privacy requirements in a Privacy Use Case or User Story, then the Normative designation for PMRM is appropriate as the accessible Privacy Use Template is based on the PMRM.

@Fred: I added goals in section 1 but also left in requirements as software engineers interests in this document are for privacy requirements and the documentation required by PbD.

@Sander and Colin: There are normative references to section 5 in Table 4.1. e.g. SHALL use the Privacy Use Template or EQUIVALENT that also results in further documentation. There will be more explicit linking of software engineering documentation, as the spec asks for specific or ?equivalent? documentation across Sections 3, 4, and 5.


SECTION 3: No edits from John, Sander, Fred, Colin, and Gail.
Incorporated Stuart?s and Sander?s edits.
No questions for Section 3 edits

SECTION 4: No edits from Jonathan, Colin, Gail. Accepted edits from John, Stuart, and Fred.

Response to Sander?s edits for discussion: As individual software engineers will have varying preferences for conformance documentation in Table 4.1, to maintain flexibility to the software engineers while facilitating standardization for auditing and better privacy management, I suggest we can create definitions of LEVELS of PbD-SE conformance for the second CSD version. The goal of providing levels of conformance is to allow organizations to seek and demonstrate compliance to their growing selection of subset of the PbD sub-principles.

Could we start off with a default set of SHALLs in a first CSD with the knowledge that we will work on defining and refining PbD conformance levels by early Fall? This first CSD is to aggregate the substantial work that the TC has done to date, and knowing that many members will break for summer.

SECTION 5. Incorporated updates from TC members.

This section has not been moved to the Appendix pending further discussion. The Privacy Use Template, and flexible choice or combination of Spreadsheet modeling, UML, or other modeling language are directly linked to normative clauses in Table 4.1 (column 3: Documentation). Flexibility is given in allowing for EQUIVALENCE. The specification needs to stipulate EQUIVALENT to WHAT.

@Fred: Not all contributions in Section 5 are ?tools?. Some are examples of software engineering UML documentation. Thus I did not accept the title change for section 5.

@Stuart: a User Story has a special definition in software engineering. There is no Data Subject Story construct in SE terminology (as yet, but it is an idea :).

Dawn?s additional minor edits: Replaced ?Privacy Use Case Template? with ?Privacy Use Template? wherever it made sense so as not to exclude agile practitioners and minor edits for readability. Updated Figure 5.0 to show the iteration of slices that aligns to core tenets in agile methodology. Updated the title of Section 5.2. Added ?document? and ?documentation? explicitly throughout. Also removed RECOMMENDED regarding the PMRM Privacy Use Template/PMRM methodology to SHALL and allowed for EQUIVALENT method.

Inserted Fred?s SECTION 6. Added comment that ?In a next version (in Fall perhaps as people break for summer), I am suggesting that the TC does work to provide levels of conformance so that software organizations can select what subset of PbD principles it reasonably seeks to demonstrate compliance to. We may place language in this section to signal such intent.?

Updated the Revision History table.

Note that text formatting edits are to be re-applied to the full document. Should any of the edits have fallen by the wayside, blame it on my being up in the wee hours of the morning flicking among many documents/communications. We will get them all in soon. That?s the great thing about believing in OASIS processes where there is always another chance to address errors and omissions.

The IPC will add in section 2 and upload it.

In my opinion, the TC feedback has been very valuable. Looking forward to your further input and a fruitful discussion tomorrow.

Thanks all. Dawn.

-- Dr. Dawn Jutla
Document Name: PbD-SE Version 1.0 Revision 4 - R3

Raw compilation of the 7 sets of edits across all sections (except Section
2) with comments in submitter's notes
Download Latest Revision
Public Download Link

Submitter: Dr. Dawn Jutla
Group: OASIS Privacy by Design Documentation for Software Engineers (PbD-SE) TC
Folder: Documents
Date submitted: 2014-06-17 08:20:01

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]