I'm ok with Hiro's suggestion - I'm
not sure a draft can be available for the F2F.
And, I think there is another piece
of work that was proposed at the last F2F - and was to provide a short
non-technical document describing the role of the RM design team/DMTF and
relationship to other GGF workgroups for information/data models, where
to start in information models (e.g. CIM) , how to extend existing model
(e.g. CIM), etc. I know everyone likes to dive into the technical
work, but writing down the rules of engagement here is very important given
the distributed nature of this work - this would be a good piece of work
to have for the F2F. And this will also provide guidance to the development
of the profile(s) Hiro / Fred suggested.
Thoughts?
Ellen
Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> Sent by: owner-ogsa-wg@ggf.org
09/26/2005 03:24 AM
To
ogsa-wg@ggf.org
cc
Subject
Re: [ogsa-wg] Information
model profile doc for OGSA -- initial thoughts
Hi Fred,
My comments in line <HK>.
----
Hiro Kishimoto
Fred Maciel wrote:
> Hi all,
>
> I've been thinking of our guidance document on CIM profiles and how
to
> represent them on the OGSA spec. I don't have any answers, but at
least
> I got to the point where I have a lot of questions... :-) I'm hoping
to
> have your opinion on them in Monday's teleconference. So, let's start.
>
> First of all, DMTF's document on how to write a profile has started
a
> one-month review inside the DMTF, so all DMTF members should have
access
> to it. The document is right on the top of the document review page:
> http://www.dmtf.org/members/review/ . It's still DMTF confidential
so I
> can't post it here (sorry), but I'm taking into consideration since
it
> should be publicly available in a month as a preliminary document.
> Meanwhile, the first slides of Andrea's presentation in the last
> face-to-face (see
> http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/08/msg00075.html
> ) are a good summary of the sections and contents in such a profile.
>
> The DMTF document gives all the details on how to specify a profile,
> includes a lot of experience (which allows us to avoid some pitfalls)
> and saves us a lot of time. However, I think that it's an overkill
for
> individual OGSA specs (*), especially the ones that cover only one
or
> two classes.
>
> So what I'm thinking for now is two levels:
> (1) We create an information model profile per OGSA area (Execution
> Management, Data, etc.), or, a profile for OGSA with sub-profiles
for
> each area. These can be part of an OGSA profile (i.e., some of the
OGSA
> profiles will include the corresponding information model profile).
> These profiles act as integration points between the pieces of the
> information models that each individual OGSA spec uses. The definition
> of these information model profiles follows the guidelines of the
DMTF
> profile spec.
<HK>
As I mentioned at the Aug. F2F, I would like to have simple management
profile document on BES container as an example within OGSA-WG.
Given Fred, Andrea, and Ellen has done CIM/JSDL/GLUE comparison already.
Is it possible to have very early profile draft at F2F meeting?
Since DMTF's usage guide is not publically available, small sub team,
who can access this document, draw up profile draft and full OGSA-WG
reviews this draft.
Based on the synopsis definition on Andrea's slides, this profile is
something like;
> (2) Individual specs show the information models they use in a
> lightweight way. The OGSA document on how to write an information
model
> profile (we need a title and a nickname for it. Suggestions?) is a
> guideline on how to specify the information model on these specs.
>
> Notice that Cisco's modeling tool (about to become open-source) will
be
> useful for both (1) and (2) above. It can even change the balance
of
> things above in subtle ways depending on how (and how much) it makes
the
> creation of a profile easier.
>
> That's all for now. Opinions please.
>
> Regards,
>
> Fred Maciel
> Hitachi America R&D
>
> (*) By "individual OGSA specs" I mean specs like ByteIO,
OGSA-BES, etc.,
> not the roadmap, profile definition, guideline specs, the OGSA spec
> itself, etc.
>
>
>