[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MUWS Document Comments (2)
I have some comments on the MUWS document (draft 5, 8/13):
1. "1.2 Existing Management Frameworks"
The introduction paragraph lists "A number of standard management
frameworks are currently in wide use". SNMP and CIM do and certainly
should show up in such a list, but I'm not sure as to whether OMI should
be listed there. Is OMI a standard ? How widely used is it in the
industry ?
2. "1.3 Scope"
a) I'd like to second Andrea's comment about support for transactions. I
believe it is important to have it at some point, whatever the exact
flavour is going to be (at least consistency needs to be covered IMHO).
The only way to get it is to have it in scope of the MUWS document. If
we feel that we cannot tackle it in the first release, let's open a
section on future work, but let's not exclude it unconditionally.
b) Since we assume the existence of a management information model
(which we do not want to develop in MUWS), a very important reality
check for MUWS is whether existing information models can be mapped
easily into the Web Services defined by MUWS. It seems we are developing
MUWS without doing such a reality check and I'm highly concerned about
that. I propose that we use a few classes from CIM to do the reality
check. In the end, someone needs to come up with a guide on how to map
existing management information models to MUWS. Ideally, this is a
straight forward algorithm. The more complicated the algorithm is, the
smaller the chances that existing models can be used under MUWS, and the
higher the chances that MUWS in fact does define its own new management
information model, with all the burden that comes with that.
3. [WS-BASE.001.5]
It reads: "The Manageability Interface MUST enable interoperability
between vendors. Goal: WS-I basic profile conformance."
What is our notion of interoperability ? True interoperability requires
agreement on the management information model. Since the definition of
the information model is out of scope for MUWS, it is even more
important to add this as a dependency or assumption in the text of this
requirement.
4. "2.1.2 Message Exchange Patterns"
The requirements:
- [MEP.002] SHOULD support asynchronous interactions.
- [MEP.003] SHOULD support one-way style interaction
(asynchronously).
are not clear to me given that we also have:
- [MEP.001.2] SHOULD support asynchronous delivery of messages and
request/response styles.
- [MEP.004.3] SHOULD support asynchronous delivery of notifications
If [MEP.002] and [MEP.003] are meant to denote something else than
[MEP.001.2] and [MEP.004.3], they should be refined to say what that is.
Otherwise, remove them.
5. [STD-CON.001]
It reads: "The Manageability Interface SHOULD be consistent with
existing management specifications such that it can be used/applied in
those communities. Including, but not limited to: GGF, DMTF.".
It is not clear to me what we mean with "consistent". Let's use DMTF and
CIM as an example: Does it mean that MUWS is supposed to be able to map
down to the CIM information model ? Does it mean that MUWS is supposed
to reach down to infrastructures supporting WBEM Operations ? I'd like
to see more clarity here. Similar comment applies to [STD-CON.002].
6. [STD-CON.003]
It reads: "The Manageability Interface SHOULD not inhibit the
simultaneous usage with existing management environments and protocols
in a common environment."
I'd like this to be a MUST because it is important for real life
deployment of MUWS.
7. [DIST-M.001.13]
It reads: "The Manageability Interface MUST support role collapsing."
One only understands what is meant by "role collapsing" after reading
the following two sub-requirements. I suggest to briefly define what we
mean with "role collapsing" in order to make [DIST-M.001.13] stand on
its own feet.
8. [DIST-M.001.15*]
They read:
[DIST-M.001.15] The Manageability Interface MUST not preclude
Collaboration/Federation among managers.
[DIST-M.001.15.1] Cooperative, peer to peer, managers.
I have the impression that 001.15.1 is not really a separate
(sub-)requirement, but rather additional information for 001.15. If it
was meant to be a separate thing then I guess it deserves some more
explanation regarding the difference between "Collaboration/Federation
among managers" and "Cooperative, peer to peer, managers".
9. [SEC.001]
It uses MUST for the general requirement, but all the sub-requirements
are SHOULD. Since the sub-requirement cover everything I read into the
general requirement, this feels like an inconsistency. Specifically, I
propose to change 001.2, 3, 4, 5 to be a MUST.
10. [SEC.002]
It reads: "The Manageability Interface MUST be firewall friendly, i.e.
work across enterprises."
The notion of "firewall friendly" strikes me somewhat. I'm completely
aware that this is a very common notion, not just in this document. I
have to say though that it is not the purpose of a firewall to offer the
big HTTP hole through which all "firewall friendly" protocols can tunnel
without being bothered by the stupid security administrators. So what do
we mean when we say "firewall friendly" ?
A much more useful requirement BTW would be to be NAT friendly (meaning
to work across today's NAT routers without requiring additional support
in them just for our protocol).
11. [SEC.004]
It reads: "The Manageability Interface MUST allow a standalone security
model"
We should define what we mean with "standalone security model".
12. [MDL-NEUT.001]
It reads: "The Manageability Interface MUST be model neutral and be able
to work with multiple existing, domain specific models."
This is rather vague. First of all, if this is important enough to be a
MUST, then we should be specific as to which existing models we mean.
I'd like to see CIM and SNMP there as a MUST, maybe as sub-requirements.
Secondly, if we take the functionality (both information model wise and
operations wise) of such existing models as given, do we intend to make
it possible for consumers of the existing interface to switch to the
MUWS interface ? Only if we intend to do that, does the whole MUWS
effort make sense, IMHO. But if we intend to do that, we need much more
care for the specific existing models as we choose to exhibit today.
Let's be serious about what we do here.
I suggest to add a new requirement to express this seriousness
explicitly:
[MDL-NEUT.00new] "The Manageability Interface MUST support enough
functionality to allow consumers of multiple existing models to
switch over to it".
13. [MDL-EXP.001.*]
The following requirements:
[MDL-EXP.001.2] The Manageability Interface MUST expose relevant
management lifecycle state of the manageable resource.
[MDL-EXP.001.3] The Manageability Interface MUST expose relevant
management performance metrics of the manageable resource.
[MDL-EXP.001.4] The Manageability Interface MUST expose relevant
management configuration of the manageable resource.
specify requirements on the management information model, and therefore
should be removed.
Not all manageable resources will have lifecycle state, performance
metrics or configuration data, I guess that is why "relevant" is part of
the text, but what is the point of stating that if e.g. lifecycle is
relevant to a resource it must expose it ? That is really a requirement
against the model.
In all existing models I know of, there are some standard behaviours
defined that are not considered part of the information model, e.g. the
WBEM Operations, or SNMP get/set. I strongly believe it is a wise
decision to keep that set of standard behaviours very small and
specifically not to clutter it with things that not every element is
going to have (like the above three).
14. [MDL-EXP.001.6.1]
It reads: "Events MUST be extensions of a standard XML management event
format"
I'd like us to name the set of candidates for this, if only by example,
so we can judge what the implications of such a MUST might be.
15. [MDL-EXP.001.7.*]
The following reqs:
[MDL-EXP.001.7.2] The Manageability Interface SHOULD expose
relationships between portTypes
[MDL-EXP.001.7.3] The Manageability Interface SHOULD expose
relationships between service instances
make assumptions about how real life resources are going to be mapped to
Web Services elements such as port types or service instances. I
consider this premature, given that we talk about requirements at this
point, and not about a particular solution. At the requirements stage,
we need to talk about relations between the real life resources instead.
Therefore I suggest to remove these two requirements.
In order to demonstrate our desire to be able to expose existing models
sufficiently well, I suggest to add a new requirement instead:
[MDL-EXP.001.7.new] The Manageability Interface MUST be able to
expose the relationship concepts of multiple existing models.
16. [MDL-EXP.001.9]
It reads: "The Manageability Interface SHOULD enable exposure of
existing standard management models and runtimes"
A weak statement like this may be ok as long as we leave it open which
models we mean. I strongly believe however that we need to name the
models, and so I suggest this to be extended to specify for which
existing models we consider this a MUST. The ones that come to my mind
are CIM and SNMP.
17. [MDL-EXP.001.9.1]
It reads: "The Manageability Interface SHOULD consider and leverage
current models of service"
What do we mean with "models of service" ? applying fixes ?
18. [MDL-EXP.001.10.1]
It reads: "The Manageability Interface MUST be able to associate
categories with information, operations, notifications, and relations"
What do we mean with "categories" ?
19. [MNGBL-RES.001.*]
They read:
[MNGBL-RES.001] The Manageability Interface MUST support management
of varieties of resources:
[MNGBL-RES.001.4] Web services and Web services architecture
Don't think the "Web services architecture" itself is a resource. If we
mean the runtime environment, let's change the wording.
20. [MNGBL-RES.002.*]
They read:
[MNGBL-RES.002] The Manageability Interface MUST support some
management capabilities.
[MNGBL-RES.002.1] The Manageability Interface SHOULD support
Monitoring management capabilities
[MNGBL-RES.002.2] The Manageability Interface SHOULD support
Configure management capabilities
[MNGBL-RES.002.3] The Manageability Interface SHOULD support
Control management capabilities
In many existing models, these capabilities are part of the management
information model, and not part of the manageability interface. These
requirement are in fact requirements on an underlying information model.
Secondly, given that the sub-requirements are SHOULD, and given that the
main requirement refers quite vaguely to "some management capabilities",
I think the main requirement does not deserve MUST.
I suggest to remove these four requirements since they are out of scope.
Since that seems to have happened not just at this occasion, it may make
sense to open a new section of requirements on an underlying information
model, and to move them there. instead of removing them
21. [MNGBL-RES.003]
It reads: "The Manageability Interface MUST support identification of
the manageable resource where the and be uniquely identifiable (where
identifiers can be recreatable)"
I don't think I completely understand what is intends to say, but I have
the string feeling it says the same as:
[MDL-EXP.001.1] The Manageability Interface MUST expose the Identity
of the manageable resource.
If we agree, let;s remove one of them.
22. [MNGBL-RES.004]
It reads: "The Manageability Interface MUST support finding a
description ( and therefore an invocable reference to the management
endpoint) for an identity"
Not sure I get the jist of that one. Why does finding a "description"
for an identity allow to refer to the management end point ? What is a
management end point anyway ? It is not among the terms defined in the
beginning.
23. [MNGBL-RES.005]
It reads: "The Manageability Interface MUST support expressing groupings
of resources"
To me, this says the same as:
[DIST-M.001.7] The Manageability Interface MUST be enable access to
aggregates of manageable resources. Allowing: ...
If we think there is a difference between aggegates and groupings, we
should define what the difference is. Otherwise, we can remove one of
them.
24. [MNGBL-RES.006]
It reads: "The Manageability Interface MUST be able to support
manageability incrementally. (Ranges from minimally Identifiable to
Monitorable to Controllable to Fully Manageable)"
While this is valuable, I don't think it deserves a MUST. There are more
important things we classified SHOULD. Also, it has a very strong
relationship with the information model which is the main contributor to
what the supported range is. So I think we should more clearly isolate
the part of the requirement that does not come from the information
model. In fact, i have the feeling that there is nothing in here that
does not come from the information model.
25. [LC-MGMT.*]
They read:
[LC-MGMT.001] The Manageability Interface MUST allow monitoring of
life-cycle states of managed resources.
[LC-MGMT.002] The Manageability Interface MUST allow control of
life-cycle states of managed resources.
Both of these requirements are requirements on the underlying
information model and therefore are out of scope. We may move them to
the model requirements section mentioned above.
26. "2.1.10 Management Manageability (S) [MAN-MGMT]"
There is some overlap between this section and [DIST-M.001.13], and also
to some extent with [DIST-M.001.14, 15].
27. [FED.001]
It reads: "The Manageability Interface MUST not preclude the development
of federated managers."
How do we define federated managers ?
What is the difference to [DIST-M.001.15] ?
28. [DISC.001]
It reads: "The manageability interface MUST be described in WSDL
documents and XML Schema so that it can be discoverable (like any other
Web service)."
While I support the first part of the sentence, I'm not sure I can
follow the conclusion "so that it can be discoverable". WSDL description
alone does not do that, one needs some kind of registry (e.g. UDDI) in
addition. WSDL description also is not a prereq for discovery, either. I
suggest to clearly separate the basic requirements and not to bundle
them.
29. [DISC.002]
It reads: "The Manageability Interface MUST not require a manager to
have all resources explicitly defined to it."
Not sure I understand it. Is it about dynamically discovering the
resources by a manager without having prior knowledge about them ?
30. [DISC.003]
It reads: "The Manageability Interface and Description MUST enable the
discovery of appropriate relationships between manageable resources via
Web services discovery mechanisms."
Given that we have:
[MDL-EXP.001.7] The Manageability Interface MUST expose the relations
of the manageable resource with other manageable resources.
I'd like to understand whether we think there is a "discovery" of
relationships on top of "exposure" of relationships. Is there a
difference between exposure by providing an enumeration capability, and
discovery ?
31. [MISC.001]
It reads: "The Manageability Interface MUST use XML schema types
available for Time and Date when representing a time."
Why just date and time ?
Thinking about the XML schema types, I'd like to raise a new requirement
that is motivated by the fact that SOAP as a binding shines through on
array types, currently. This is in fact a requirement on another
standard, but as stated somewhere in the introduction of the MUWS
document, we should spell out such requirements too:
[MISC.new] "Advance the definition of XML array types so that they
become independent of the web services binding (currently, SOAP shines
through)."
Andy
Andreas Maier
IBM Senior Technical Staff Member, eServer Software Architecture and Design
IBM Lab Boeblingen, maiera@de.ibm.com, +49-7031-16-3654
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]