OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: MUWS Document Update


Attached is a new Word version of the MUWS document.  I will be 
uploading the PDF version to the web site.

What follows here are my responses to Andrea's comments first, then 

I know it is very long.  My apologies in advance.


Andrea Westerinen wrote:

> 1. I am very concerned that transactions are not included in MUWS as
> noted in Section 1.3.  There is (somewhat) overlapping work in IETF on a
> new protocol called NetConf.  This protocol puts strong emphasis on
> transactions and locking.  I believe that locking is part of the
> information model (what you can lock and how) and out-of-scope for MUWS,
> but transactions are something that the infrastructure must understand.
> I believe that we should reconsider this, so that MUWS is a proper
> superset of NetConf and does not leave out a requirement that (at least)
> part of the industry considers important.

Good point to discuss.

> 2. Page 15, SEC.005.1 indicates that we MUST allow security features to
> be enabled/disabled - but SEC.001.6 says that we SHOULD support access
> control.  This is very dangerous as an attacker can disable security.  I
> think that security features are indeed SHOULD, but that if they exist
> and therefore SEC.005.1 MUST be implemented, then SEC.001.6 MUST be
> done.  

We can either add clarifying statements, or change SEC.005.1 to just say 
configurable and take out "enable/disable".  Either way, a note should 
be added to SEC.005.1 to say that any "security configuration should 
only be allowed via the manageability interface if appropriate access 
controls are in place."

> 3. Page 15, SEC.004 - what is a "standalone security model"?  This is
> not clear.

I am not sure how to reword this.  I believe the intent was to support 
use of an external security mechanism that is independent of WSDM and 
already existing in the environment.

> 4. Page 15, MDL-EXP.001.2 - .5 - "relevant" is a very imprecise term.
> It should be removed.

I went ahead and removed it.

> 5. Page 16, MDL-EXP.001.7 + .001.7.x subrequirements - The text
> indicates that the interface MUST expose relations, but all the
> subrequirements are SHOULD.  This struck me as very odd - what MUST I
> do?

I personally don't see an issue here, but it is worth discussing.  The 
issue was that some manageable resources may have only one of the types 
of relationships, so there is no required type.

> 6. Page 16, MDL-EXP.001.8 - Should the wording of "enable exposure of
> other associated descriptions including work flows and policies" be
> "enable exposure of other associated manageability interfaces including
> work flows and policies"?  Aren't these also manageable resources with
> interfaces, as we define them on page 6?  

Not sure I understand work flows and policies enough to answer this, so 
we should discuss it.

> 7. Page 17, MDL-EXP.002 - Does this requirement apply to the model and
> the instantiation of the model (its data)?  I believe so, but this is
> unspecified.

I don't think so.  It was intended for changes in what management 
capabilities are available via the manageability interface.  Not for 
changes in any of the underlying data, such as counters.

> 8. Page 17, MNGBL-RES.002 - "... Support some management capabilities"
> means nothing.  This needs to be reworded and clarified.

I went ahead and tried to reword it.  Still should be discussed.

> 9. Page 17, MNGBL-RES.002.1 to .002.3 - We must be specific what
> Monitoring, Configure and Control management capabilities are.
> Otherwise, the requirements are imprecise and subject to interpretation.
> Also, we should be consistent in using "ing" endings or not, on the
> words.

I fixed the "ing" problem.  I am not entirely sure we can fully define 
"Monitor", "Configure", "Control".  Also, I believe WSMF and maybe 
WS-Manageability (I haven't read it yet) may have their own categories. 
  Maybe this is a job for WS-SOS or Glossary work.

> 10. Page 18, MNGBL-RES.006 - You use terms, "minimally Identifiable to
> Monitorable to Controllable to Fully Manageable" that are imprecise and
> subject to interpretation.  This must be clarified.

This is similar to comment 9.  I tried to partially address this with 
some extra words.  But again, maybe WS-SOS or Glossary needs precise 

> 11. Page 18, Section 2.1.9 - I am very concerned that lifecycle depends
> in part on the data model. Yes, you have basic start/stop, but this may
> not apply to all elements - ie, the thing is always running.  However,
> there are other states such as quiesced, in test, completed, ... That
> are dependent on the element and its data model.

Since this section didn't require any particular data elements, I am not 
sure what the concern is.  Maybe that there won't be any way to build 
this into the UML?

> 12. Page 19, DISC.002 - I am not sure what the requirement means.  Could
> this be reworded?

I tried to reword it, but didn't like anything, so left it alone.  Let's 
discuss it.  It could mean that it MUST enable the discovery of 
manageable resources.  It could be that we don't even really need this 

> 13. Page 19, DISC.003 - Appears to be a duplicate of MDL-EXP.001.7.5,
> but the latter is a SHOULD.

I suggest we delete MDL-EXP.001.7.5.

> 14. Page 20, INTEROP.002 - Disagree that we "SHOULD define the set of
> compliance requirements" and say that we "MUST define the set of minimal
> compliance requirements and SHOULD define additional, recommended
> compliance requirements."

I went and added this in, but not sure if there is consensus on this or not.

> 15. There are many cases where the words "managed resource" should be
> changed to "manageable resource":
> - Page 7, second bullet from bottom
> - Page 11, MEP.004.7
> - Page 12, DIST-M.001.5
> - Page 14, SEC.001.1 and SEC.001.2
> - Page 18, all requirements in Section 2.1.9


> 16. There are some grammar issues:
> - Page 11, MEP.004.1, period should follow the closing parenthesis
> - Page 13, DIST-M.001.7 - Not "MUST be enable", but "MUST enable"
> - Page 15, SEC.004 and SEC.005 needs "#" in front of the numeric
> reference in {},
> 	for consistency
> - Page 17, MNGBL-RES.003 - Sentence is missing some words, "...
> Identification
> 	of the manageable resource where the and be uniquely
> identifiable"


> 17. Clarification is needed:
> - Page 11, MEP.004.3 - SENDER SHOULD ...
> - Page 11, MEP.004.4 - BOTH SENDER and RECEIVER MUST ...
> - Page 11, MEP.004.5 - SENDER MUST ... (especially needed since there is
> 	an unresolved reference to "it")
> - Page 11, MEP.004.6 - SENDER MUST ...

When there is no subject in this section, substitute "The Manageability 

> - Page 14, SEC.001.6 - "should be controllable by role" should
> capitalize SHOULD
> 	and it may be valuable to further indicate that we are
> discussing RBAC here.
> 	RBAC is a known term.

There was some skittishness about requiring Role Based Access Control. 
That should be left to the security mechanism.

> - Page 17, MDL-EXP.001.10.2 - reword "MUST be able to associate read/and
> write 
> 	ability of attributes" to "MUST be able to define the read/write
> characteristics
> 	of attributes"

Slightly different rewording.  Discuss.

> - Page 18, MAN-MGMT.001 - Is a duplicate of DIST-M.001.13.1.

Suggest we delete DIST-M.001.13.1.

> - Page 19, CO-EXIST.003 - The sentence has a double negative ("MUST not
> preclude 
> 	having implementations co-exist WITHOUT interfering"). Can we
> reword this to
> 	"MUST allow implementations to co-exist without interfering"?

The feeling in the group was that "allow" was too strong, so we 
substituted "not preclude".  It may be awkward, but it isn't a double 

> - Page 19, DISC.001 - Is a duplicate of WS-BASE.001.3.

Agreed.  Which to delete?

> - Page 20, EXTN.001 - Clarify that this requirement enables extension
> and 
> 	MDL-EXP.002 indicates that changes MUST be exposed.

Actually I disagree.  MDL-EXP.002 basically says that a manageable 
resource has an initial set of management capabilities that are exposed 
and discoverable.  Over time, that set may change, requiring the ability 
to communicate that change.

EXTN.001 says there need to be a mechanism to extend the management 
capabilities, but this would normally be done beforehand, not in the 
middle of the life cycle.

So I think these don't really have any relationship and don't need to be 
clarified any more.

Andreas Maier wrote:

 >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 ?

Discussion point.

 >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.

Discussion point.

 > 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.

First, while the Requirements document may not be clear on this, Heather 
has mentioned several times that there will probably need to be some 
sort of generic information model for "manageable resources" in MUWS. 
Of course there will be a lot more in the information model developed 
for MOWS.

This is important.  So is a set of reference implementations.  But the 
approach the TC has taken is to get the requirements done first, then 
start the specification.  Without at least a draft specification, it 
doesn't seem possible to try any mappings or any implementations.

 >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.

Discussion point.

 >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.

This could probably be clarified.  I think the set of types of 
interactions is:

A) MUST support synchronous delivery of messages (requests, 
notifications, etc.)
A.1) MUST support request/response style. (Synchronous request/response 
means that the sender "stays on the line" until the response comes back.)
A.2) MUST support delayed response style.  (Sender gets an immediate 
response acknowledging the message, but the official response comes back 

B) SHOULD support asynchronous delivery of messages (requests, 
notifications, etc.)
B.1) SHOULD support request/response style. (This means that there is a 
logical response coming, but the sender isn't waiting for any response.)
B.2) SHOULD support one-way style. (The sender gets no response of any 

Glossary.  Also, there may not be consensus on these words.

 >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].

Discussion point.  But what is wrong with saying it can be used/applied? 
  Yes, it isn't perfectly clear, but it seems to me too early in the 
process to know exactly what can be done.

 >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.

Agree.  Discussion point.  Past discussions have been that there may be 
some environments that are not widely used that may cause problems.

 >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.

Tried to address this in document.

 >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".

Agree that 15.1 is more information for 15.  What if 15 ended with 
"managers, including but not limited to:"

 >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.

Discussion point.  This just addresses how much flexibility is needed. 
Doesn't it imply that a MUST at a higher level requires at least one of 
the SHOULDs at the lower level, or must this be explicit?

 >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).

This is a very good point.  I like it.  Though there is a point to be 
made that this is more of a property of the binding mechanism used. 
Unless you want to provide sufficient information for a firewall proxy 
to inspect the management messages.

 >11. [SEC.004]
 > It reads: "The Manageability Interface MUST allow a standalone
 > security model"
 > We should define what we mean with "standalone security model".

Agreed.  Andrea had the same comment.

 >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".

Added to the document for discussion.

 >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).

I disagree that requirements on the management information model should 
be removed.  They are very important to MUWS, as it has been addressed 
so far.  And there may be a need for a generic management information 
model in the MUWS specification.

 >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.

Good point.

 >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.

Interesting point.

 > 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.

Good discussion point.

 >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.

Good discussion point.

 >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 ?

This was to highlight that current management models have a concept of a 
"service" that needs to be addressed when doing 1.9.

 >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" ?

This has not been fully defined yet.  WSMF has "types", others have 
other ways of categorizing management capabilities.  It also doesn't say 
whether WSDM will specify the categories or let them be open.

 >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.

How about "elements of the Web Services Architecture"?

 >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
 > requirements are in fact requirements on an underlying information
 > model.

Well, they are requirements on the Manageability Interface and the 
underlying information model.  If you can't perform these functions via 
the Manageability Interface, though, it doesn't matter whether anything 
in the underlying information model supports it.

 > 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

See what the reworded section says and whether it addresses your concerns.

The hard part about having a separate section is that so many of the 
requirements impact both the interface and the model.

 >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.

They are clearly related.  Discussion point.

 >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 gist 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.

I changed it to "invocable reference to the Manageability Interface)". 
But that leads me to think that perhaps the subject of the requirement 
is wrong.

 >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 aggregates and groupings, we
 > should define what the difference is. Otherwise, we can remove one of
 > them.

Hmmmm.  If we combine them, need some rewording, as they are saying 
slightly different things.  Agree there is a lot of overlap.

 >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.

Others felt it was one of the most important, because otherwise the 
barrier to entry will be too high.  Need to have a set of increments or 
modules to implement, some of which are easy.

I did try to make it clearer in the document.

 >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.

Relates to the issue of requirements on the information model.

 >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].

Yes.  Some of that is addressed, some not.

 >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] ?

Glossary work.

 >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.

Good discussion point.

 >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 ?

Yes.  Although it could also be interpreted as discovering the 
management capabilities of the resource.

 >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 ?

Yes.  Good discussion point.

 >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)."



John DeCarlo, The MITRE Corporation, My Views Are My Own


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]