OASIS Open Mailing List Archives  ·  All Lists  ·  pmrm  ·  2011-07

pmrm — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

REMINDER: OASIS PMRM TC Formal telecon - Thursday, 14 July, 11 AM Eastern


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:[email protected]] Sent: Tuesday, June 28, 2011 12:44 PM To: '[email protected]' 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

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]