Good morning Frank and TC members:
I would like to bring up a few more aspects to our present discussion.
I asked OASIS administration to take a look at our draft several
weeks ago to which it positively responded. The Introduction as laid out is not in violation of any of OASIS
rules, or its spec template. Our future standard addresses privacy governance and closes a
well-known communication gap between policy makers, business, and
technologists, whereas the large majority of OASIS existing standards are purely technical. Therefore
our goals (and that of OASIS TCs dealing with Transformational Government for example) may introduce new ways of looking at things. I don't have to say that your Chairs are not from
the usual milieu of OASIS TC chairs. Diversity is not a bad thing.
This TC is proposing to change the way software engineers work.
Traditionally, change has been more difficult for those in management than the
software engineers themselves. The SE field demands continual change so software
engineers are used to change. All software engineers I know are bright and enjoy learning. As
we further develop our work in coming months, I hope that we will provide a
pedagogical resource (Annex) and a specification that positively propels the
profession towards embracing privacy and security in the mainstream.
This TC’s work adds one more tool for people in the present and
future software engineering workforce to support privacy preservation of online
societies, and to affect the future of the next generation of citizens in positive
ways. It may be naïve to think that this goal may be larger than companies’
profit margins, but being labeled wonderfully naïve in
order to affect positive change may not be that off-putting to this TC's members. Service is not a bad thing.
The field of privacy is immature. Privacy engineering practice
is immature. The goals of this TC’s work are not to reify current privacy
engineering practice. The work we have
done to date as a TC provides a substantial glimpse of big picture for Privacy
by Design and software engineering that has never been provided before. That is valuable service in itself to the mainstream software industry. The TC's widely signalled intent to release its first CSD to meet its first milestone is why we have been meeting weekly for the last 3 weeks.
I back my co-Chair Commissioner Cavoukian's proposal that we consider the Revision 6 draft we have submitted as a first CSD tomorrow. Afterwards, I propose that we proceed to have further substantial discussions as a TC,
including levels of PbD-SE conformance and RFC 2119 keywords usage, and address Frank’s preference for wording etc. for the second CSD update.
With thanks for your kindest consideration.
Dawn.
P.S. Frank, the definition of a software organization, in the spec's Terminology section, is not as restrictive as interpreted. The definition includes units within all organizations that directly or indirectly engineer software. We can put more wording for busy readers in future. Anyway, let's move such disposition to a second CSD version. With much appreciation for your valuable contributions, D.
On Mon, Jun 23, 2014 at 8:24 PM, <> wrote:
Chairs and TC members.
Please find my review comments on the WD6 of the PbD-SE working draft.
These are substantial comments that need adequate discussion. That would require others in the TC to also have time to review these comments.
I have not had time to review the Annex document. Unfortunately, most of this week, I am involved in privacy policy work and unable to dedicate much time
to review the Annex.
Frank/
