Title: Message
Hi all,
regarding the naming issue, despite some objections to the
"symptoms" name, I think it kind-of stands out and there is a good chance it
will attract attention. I also think I like
the term framework because, well, that's what it is -I know some will complain about this though.
That said, I am in favor of keeping "Symptoms" or a derivative in the title, but
I will not fight too much for the "framework" term :-)
A few more things
on naming: in line with what Marcelo
recommends, I also would not like to unnecessarily constrain the domain
applicability of symptoms.
On the
admin side, renaming should be relatively straightforward once we reach
consensus on the name (brief discussion on next call and vote on the one after).
However, expanding the scope to include profiles requires re-chartering, and as
we learned on the first meeting, this is something to be avoided at all costs
-especially this early in the process. There might be a way though to add a
cloud profile deliverable in the list but we need to discuss what such an action
would entail.
Cheers,
Stavros
-----Original Message-----
From: Marcelo Perazolo
[mailto:]
Sent: 26 October 2009
19:01
To:
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:
"Lipton, Paul C" ---10/26/2009 02:01:52 PM---Hi
all,
From:
"Lipton, Paul C"
<>
To:
<>
Date:
10/26/2009 02:01 PM
Subject:
[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:
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.
______________________________________________________________________
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.
