Subject: [lmap] Recommendation for Path Forward

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 8 Nov 2012 18:39:08 +0000

I agree with Phil's sentiments, and here are my thoughts on the topic of path forward.

After sleeping on last night's discussion, I recommend the following path forward:

1. Scope the problem space.
2. Identify use cases of interest. Use cases need to clearly identify the primary "user" of the use case.
3. Determine which use cases we "must" solve vs. "may/should" solve.
4. Determine "Business Requirements" for the use cases. [It's ok to accept input of biz requirements for all use cases, so long as we keep in mind that the primary focus is to meet the needs of mandatory use cases.]
5. Business Requirements drive high level functional requirements and criteria for assessing various possible architectural solutions.
6. Allow for proposals to be submitted for functional architectures that would meet the needs of the Business Requirements. Compare the proposed functional architectures as to their ability to satisfy the functional requirements and other assessment criteria.
7. Select a functional architecture.
8. Determine gaps in the architecture (functional requirements for which solutions are not obvious or do not exist) that require additional effort, and determine which of these the IETF wants to tackle and is well-suited to tackle. Other SDOs can make similar assessments.
9. Create the needed gap-filling solutions.

In my experience (as a primary use case "user" who has needed solutions created in the past), it is in this "primary user's" best interest to consider themselves to be the owner of the process as a whole. It may be possible to hand off ownership to a SIG (Special Interest Group), if there is a SIG whose interests are primarily to meet the needs of a group of such users. IETF is not a SIG, and I do not recommend trying to hand off ownership of the holistic solution to the IETF. An example of a SIG as an owner, consider the way the US and Canadian governments use NENA to create architectures for emergency services, and use IETF to create protocols where there are gaps.

I think we should be able to get items 1 through 3 done really quickly, and then proceed directly to 4.
I think the current draft is assuming an architecture (step 7), and trying to back into 5, without first having tackled 1-4. As such, I'm not willing to provide comments on the current draft. I think it's the wrong architecture. 

I think that it may be possible to do steps 1-8 within the context of lmap+IETF, if others are willing. I think 1-4 could be done using this email reflector. Once we do 1-4, I think we will have what we need to proceed with establishing a more formal environment in which to work 5-7.

My next email will propose what I think are answers for items 1-3.
Barbara