Our next formal meeting should be on your calendars, with the call-in information. As to the Agenda: We are working on two major items: - Refine the Methodology (+ embedding the original PMRM): see attached e-mail sent earlier - Completing the Emergency Responder Use Case: o analyze the remaining Touch Points and Input/Output flows: volunteers?? John S and I had a side-band conversation: - The initial work on the Use Case has already helped us refine the details of the Methodology steps; let’s document those details. - Under each Service, the Functions are broken into 7 categories: 1. DEFINE [SVC] operational requirements 2. SELECT [SVC] (input, process, and output) information and parameters 3. INPUT [SVC] information and parameter values in accordance with Select 4. PROCESS [SVC] information and parameter values within Functions 5. OUTPUT [SVC] information, parameter values, and actions 6. LINK [SVC] to other (named) Services 7. SECURE [SVC] with the appropriate security functions For a given Service, these Function categories are customized to the particular instance (actor, input/output, requirements). The “guts” of the Service operation is contained in the Process steps. Also note that Define is the step when all “operational requirements” are gathered, including jurisdictional policies and a prior or ‘static’ agreements. The remaining 6 steps are more explicitly “operational”, so we can think of each Service invocation as having those two phases: define + operations. In our Use Case analysis (so far), we have identified the Services to be invoked (based on the high-level Service definitions), but have not fully identified the “define and operations” breakdown for that instance. Agenda (net): Come prepared to discuss: - refinement of the merged Methodology (pre-call comments welcome!) - completion of the Emergency Responder Use Case (volunteers are most revered!) Michael From: Michael Willett [mailto:
mwillett@nc.rr.com] Sent: Tuesday, June 28, 2011 12:44 PM To: '
pmrm@lists.oasis-open.org' Subject: PMRM TC: merger of the Methodology and PMRM/ISTPA I just uploaded to the PMRM TC site a first draft of the OUTLINE of a merger of the Methodology and PMRM/ISTPA. The basic ideas are: - merge the two into one deliverable to be published - still call the merged doc the PMRM – emphasis on Reference Model - move the 7 Function categories from the PMRM/ISTPA to the Functions (and Mechanisms?) sections of the Methodology Clarification added: The Service Functions should not be confused with the Mechanisms needed to actually implement a Service/Function. Mechanisms include cryptography, challenge/response authentication, etc. - dramatically edit the merged docs for continuity Next steps: - argue/revise/agree to the merger - (one option) – assign individuals to each section to draft the words - all the while, completing the Emergency Responder and Smart Grid use cases - reflect “lessons learned” back into the merger Opinions? Michael