PMRM TC Members:
I was assigned several comments/recommendations that were proposed as part of our external review. For discussion at our September 20 TC meeting, the issues I looked at and my proposed disposition for each
are noted below. Where changes are proposed, they are contained in the attached Word documents, referenced below. Changes to Figure 2 in the spec are shown in the “Figure 2 Content Draft 082212.docx” document since I couldn’t change the graphic
in the PMRM draft spec.
Sorry this appears a bit disorganized, but hopefully it will fall into place at tomorrow’s meeting. Hopefully I got the references to the various attachment right – if not, my apologies –it all starts running
together after a while.
John
Issue 1: “Clarify definitions and use of terms "policies" and "principles"
Proposed Response:
An updated definition of “policy” which is comprehensive, and including that in the glossary.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Issue 2: “It would be helpful if the sections headings in Section 2 identically matched the activities and tasks in Figure 2 (including the numbering). This would ease navigation. It took me a while
to convince myself that they were the same because the wording is different.”
Proposed Response:
Major edits to the section numbers and header descriptions so they would be more logically organized (e.g. maintaining distinction between tasks and
headers for clusters of tasks) and also proposed wording changes in the headers.
See PMRM-v1 0-wd04 SABO DRAFT EDITS-v082812.docx
Mapping the content of the boxes in Figure 2 to the correct headings – I propose consolidating in one box all the steps in the Detailed Use Case
Analysis, but these can be separated if one box is too large when inserted into the graphic.
Also on Figure 2, distinguish between the content that is normative from the content which is out of scope (e.g. Develop Privacy Architecture and Implementation).
See Word document Figure 2 Content Draft 082212.docx
Issue 5: “Tasks 9-14 should probably result in a table listing (i) a process step in which data is exchanged - Task 9, (ii) the party from whom
the data are extracted/sent - Task 9, (iii) the party to whom the data is sent/collected - Task 9, (iv) the party initiating the transaction - Task 9, (v) the data elements identified in Section 3.2 - Task 11, (vi) the mode of communication - Task 10, and
(vii) a brief description of how the transaction takes place - Task 10, (vii) privacy protections employed - Tasks 12-14. The use of the table forces the user to account for all of the process steps and all of the data flows; it forces alignment of the privacy
risks and protections for each that mere textual descriptions fail to compel. “
Proposed Response:
Illustrate tasks 9-14 in tabular form. Since I re-numbered the PMRM Draft tasks for Issue 2, my proposed edits track to tasks 5-16 rather than 9-14.
Note: Doing this exercise illustrated to me the rigor needed to use the PMRM and the importance of maintaining internally consistent logic with respect to the tasks
themselves and the various components. For example, actors have multiple roles (customer system sends PI and customer system receives PI – this lends itself more to modeling than a chart). Likewise, data flows are hard to display in chart form without getting
into lots of nested charts etc.
The other thing I see is that our
use case needs some attention – maybe a detailed use case is in the appendix, and we accept more abstract references prefaced by “for example” in the running use case in the body. I believe we need to discuss the chart and some of its implications at
a TC meeting.
Also, because of time constraints, I didn’t complete the last three tasks (inherited, internal and exported privacy controls) since I felt the chart already raises some questions.
I also modified the language from the use case descriptions to fit the logic of the chart (from my perspective) better.
See Word document PMRM Table-Tasks 5 to 16.docx
Issue 6:.” It would be good if the examples were more exhaustive (as if they were real). This would give a better sense of the comprehensiveness anticipated for
the model. Listing several (if not all) of the communications for the EV charging example in the table [proposed in Issue #5] would give users a better sense of how to use the model.”
Proposed response:
No Modification at this time. We tried to keep the flowing sample use case as high level as possible as an aid to understanding the specification. Developing a more comprehensive use case can be very valuable, but that would
be best done separately from the specification itself. – see draft Word document PMRM Issues 6-9-10-Sabo.docx
Issue 9: “The example should demonstrate one-to-many relationships between the services and the activities to prevent users of the model from presuming that filling
in one answer covers the waterfront. In the example given for "Log EV location" under Enforcement, it would be useful to show two responses explaining why some circumstances would prompt contacting the user and others would prompt contacting the utility.”
Proposed response:
Minor modification to the Enforcement example –
see draft Word document PMRM Issues 6-9-10-Sabo.docx
Issue 10: “Tasks 15-17 might best be combined into a table to ensure alignment of interactions, functions, and risks.”
Proposed Response: Change the Example box to tabular format – see
Word document PMRM Issues 6-9-10-Sabo.docx
John Sabo
CA Technologies
Senior Director, Global Government Relations
Tel: +1 202-513-6304
Mobile: +1 443-629-6198
john.t.sabo@ca.com
