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

["Michael Willett" <mwillett@nc.rr.com>]

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