All domains have value and might be interesting to discuss in a
primer, but I believe that we should highlight the cloud profile and pursue
more deeply, rather than “bury” it with the other domains that might appear in
the primer. This is the profile that should be a centerpiece to our efforts, as
the knowledge is more resident within the group, IMHO. The procedure to add
this profile to our charter is well-understood and not too hard. I can
elaborate in, say…2 minutes! :-)
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
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: Thursday, October 29, 2009 9:01 AM
To: saf@lists.oasis-open.org
Subject: [saf] Possible TC Actions to Consider
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:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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> |
<image005.png> |
|
<image004.png> |
<image005.png> |
|
<image004.png> |
<image005.png> |
|
<image004.png> |
<image005.png> |
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)
|
______________________________________________________________________ |