Possible TC Actions to Consider

[Marcelo Perazolo <mperazol@us.ibm.com>]

I agree with Dave - a Cloud profile helps us have an interesting scenario and to also piggyback in the Cloud "buzz", which could help disseminate our group. For this reason I would assign it a high priority in our list.

On the same train of thought we could think of a number of other interesting applications, such as Social Networking / Knowledge Management, SOA, Virtualization / Appliances, Grid, Green Computing, etc.

Other than that I think we should also pay attention soon to Systems Management despite being "bread and butter" - and at the same time address the differences between us and the CDM work from DMTF... which is a question that has already been brought up by others commenting on symptoms...

And there are many other interesting scenarios too which we have discussed in the past in our pre-standard meetings, and Industry-related scenarios would be good to have in our repertoire as well. We wouldn't be able to address all these with depth but the idea of having mini-scenarios for understanding and dissemination (and to maybe "seed" other sub-initiatives) is probably a good thing.

In connection with this expanded scenario list we should also discuss strategies for marketing and expansion to promote growth in our group. Our first mission I believe should be to make people notice this initiative and get them interested on possible applications and start forming a larger community. This agrees well with the concept of being a "broad" and generic specification.

Marcelo Perazolo
IBM Systems Director
IBM Corporation
phone: +1-919-5438491
email: mperazol@us.ibm.com


David Snelling ---10/29/2009 05:41:16 AM---Folks, I have commented of the naming issue, but not the Cloud Profile:

From:	David Snelling <David.Snelling@UK.Fujitsu.com>
To:	"Lipton, Paul C" <Paul.Lipton@ca.com>
Cc:	<saf@lists.oasis-open.org>
Date:	10/29/2009 05:41 AM
Subject:	Re: [saf] Possible TC Actions to Consider

---

Folks,

I have commented of the naming issue, but not the Cloud Profile:

I am strongly in favor of doing a Cloud Profile of Symptoms, probably at the IaaS level. Within the DMTF and OGF there are activities that provide us with domain specific schema, etc. I suggest we consider, as Pual suggests, a "test" of the system. This would not need to be a normative deliverable of the TC, but possibly part of a primer or suchlike. This should not then interfere with our charter, but give us something cloud-like to socialize the spec with. The next question, should you all like this idea, is what scenario should we look at describing in Symptoms terminology?

Talk to you tonight.

On 28 Oct 2009, at 21:27, Lipton, Paul C wrote:

This is exactly the kind of explicit examination of pros/cons that I believe we needed. Ultimately, based on the perspectives I’ve heard shared, I think we have largely (but not entirely) paid the education/confusion price. We are now left with an interesting and uniquely named TC, which is good. Thus, I am leaning towards either keeping the current name or going the complete abstraction route, as in “RAF - Reasoning & Automation Framework.”

I think the more interesting discussion, and really not so fully addressed in this email thread, is the issue of adding a Cloud Profile to the deliverables. On one hand, we gain specific relevance to a hot area, get to “test” the abstraction of SAF against a specific domain that the current participants are already involved in, and possibly get more synergies with other groups. On the negative side, it adds to the work to be done starting perhaps with carefully scoping the profile domain (do we do IaaS and/or PaaS, for example).

I assume that these will be put on the agenda either this week or next week.

Regards,
Paul

Paul Lipton
VP, Industry Standards and Open Source
Member, CA Council for Technical Excellence
Phone (preferred number!): +1 215 539-2731
Mobile: +1 267 987-6887
Email: paul.lipton@ca.com
<image001.gif>
THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE), YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.


From: Marcelo Perazolo [mailto:mperazol@us.ibm.com]
Sent: Monday, October 26, 2009 3:01 PM
To: saf@lists.oasis-open.org
Subject: Re: [saf] Possible TC Actions to Consider


I see the dilemma in either keeping the medical analogy or going full-IT or something else... the name of the specification is tied to this decision.

It depends a lot on what we want to be the focus. I believe we would want a very broad core specification and then do a deep-dive in each domain applications of the core spec, possibly in sub-groups under our TC or even totally different specifications spawned in OASIS after the core spec is ready. The IT Management space would be one, the Cloud space another, then others like Process Management, specific industries like Energy, Healthcare, etc. All these domains would have the option to extend the core spec to their own needs and to define authoritative classifications types for symptoms/syndromes/prescriptions/etc. (for better exchange of knowledge among intra-domain implementations).

A good non-biased replacement for "autonomic" has always been "self-management" but then again "management" has a bit more of an IT-specific connotation...

If we go with the IT-biased terminology my suggestion is this:
SMF - Self-Management Framework
AMF - Automated Management Framework

If we stick with Medical terminology:
SDF - Self-Diagnostic Framework
SDTF - Self-Diagnostic & Treatment Framework

If we abstract from everything and try to have a very broad terminology that can be applied to any multiple domains:
SRF - Self-Reasoning Framework
RAF - Reasoning & Automation Framework
SRKF - Self-Reasoning & Knowledge Framework

In my particular opinion I think we should eliminate the IT-biased option. I believe a medical analogy is something that everybody understands and despite what blog comments elsewhere may say it's something that differentiates this effort and gives it an interesting appeal... In a close second I also favor a broader generic terminology with the words "Reasoning", "Knowledge" and "Automation"... these are terms that - in my opinion - fit well in several different application domains - but are not as appealing I think.

I also disagree with having terms like Optimization and Remediation in the name associated to the core spec because I believe the uses will be broader than that - including prediction/avoidance and full root-cause resolution of problems (not only remediation), security issues identification and prevention, configuration and deployment issues, etc. In autonomic computing terminology we used to classify "Self-Management" in four different quadrants: Self-Healing, Self-Configuring, Self-Optimizing and Self-Protecting - symptoms were supposed to help in all quadrants, not being specific to one or two of them...

I'm also not too keen with "Framework" - I wish I had a better suggestion for that, but at the moment I haven't...

Marcelo Perazolo
IBM Systems Director
IBM Corporation
phone: +1-919-5438491
email: mperazol@us.ibm.com


<image002.gif>"Lipton, Paul C" ---10/26/2009 02:01:52 PM---Hi all,

<image004.png> From:	<image005.png> "Lipton, Paul C" <Paul.Lipton@ca.com>
<image004.png> To:	<image005.png> <saf@lists.oasis-open.org>
<image004.png> Date:	<image005.png> 10/26/2009 02:01 PM
<image004.png> Subject:	<image005.png> [saf] Possible TC Actions to Consider

---





Hi all,

I took an action item to detail three possible actions that should be explicitly considered, IMHO, rather than deciding “by default.” If there is interest, perhaps this should be discussed at the next meeting, make the decisions we need to, and then move on to the real work, as they say.

Change the name of the base spec: Is the time for this past? I don’t know. On one hand, both “Symptom” and “Autonomic” have caused (and are still causing) tremendous confusion. If it is not clear why, I can elaborate, but I hope the reasons are clear to us all. Heck, Symptom is not even necessarily the most important entity in our information model! On the other hand, OASIS has promoted SAF a bit and there has been some small notice of it amongst some respected people in the standards community. It may be that we have already paid the confusion price up front and now we can benefit from a fairly unique name. Symptoms Autonomic Framework (SAF) is that, I grant. Either way, this TC should decide if it wants to change the name. If so, sooner is better than later. A subtext of this discussion is the commitment to a medical analogy, perhaps. Some possible alternative names (better ones no doubt exist and should be volunteered please):
· FOR: “Framework for Optimization and Remediation” (simple and sweet or too simple?)
· FORAD: Framework for Optimization and Remediation Across Domains (in the Urban Dictionary it also is a composite of “For Real” and “Radical”)
· FDT: “Framework for Diagnosis and Treatment” (possibly too medical again)

The TC procedure, I believe, would be for us to agree to all charter changes. Then we would have to make a motion for the TC Admin to make a Charter Clarification Ballot. There is a 7-day ballot that 2/3’s of the TC must approve. Given the current size of the TC, this should not be hard if we agree we need to do it. Once approved, OASIS updates the website. We should add to the FAQ, IMHO, that the name change was for clarity.

Other possible changes:
· Remove medical analogy and just go straight IT? Is this really necessary or helpful? Not worth it if we don’t change the name of the TC.
· Add a Cloud Profile? I admit that my initial thoughts are this is a good idea. Cloud is hot and SAF could be uniquely useful to the cloud in complicated, cross-domain applications, I think. It would broaden the scope of interest and at the same time most of the folks involved are also interested in Cloud.

Of course, your mileage and perspective might vary considerably.

Regards,
Paul

Paul Lipton
VP, Industry Standards and Open Source
Member, CA Council for Technical Excellence
Phone (preferred number!): +1 215 539-2731
Mobile: +1 267 987-6887
Email: paul.lipton@ca.com
<image001.gif>
THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE), YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.

Take care:

    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe Limited
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE
    Reg. No. 4153469

    +44-7590-293439 (Mobile)

______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.