[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: MUWS Document Update - Comments from Andreas with feedback fromJohn
Andrea, Andrea Westerinen wrote: > John, My comments follow yours, preceeded by <arw>. I got up to #16, > and want to get something to you, for your review. I will send the > remainder right after I get some lunch :-). > > Andrea > > > 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. > <arw> I would remove it as it is a technology from webMethods and HP, > and not a standard. <jd> I'll leave it in for now, but feel free to take it out. I don't see how it really hurts anyone, and there was a bit of previous discussion of this 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. > <arw> Addressed by my work with Shel. The bullet item should definitely > be removed from "out of scope". <jd> agreed. and done. > > > 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. > > <arw> I agree with both of you - it is important, but is part of the > spec and work, not the requirements. <jd> So I won't touch anything here. Trying to identify and remove any part of any requirement that impacts the information model is wasted time at this point. > > >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. > <arw> Could we modify the requirement as follows: > "The Manageability Interface MUST enable interoperability between > vendors (for example, > WS-I basic profile conformance). Note that interoperability MAY require > agreement on > aspects of the management information model." <jd> Done. > >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 > > later.) > > 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 > kind.) > > Glossary. Also, there may not be consensus on these words. > > <arw> I would suggest a slight rewording (for clarity) as follows: > A) MUST support synchronous delivery of messages (requests, > notifications, etc.) > A.1) MUST support synchronous request/response (ie, the sender is > connected, "waiting" until a response is received) > A.2) MUST support synchronous, delayed response (ie, the sender gets > an > immediate response acknowledging the message, but waits on the > receipt > of the final response) > B) SHOULD support asynchronous delivery of messages (requests, > notifications, etc.) > B.1) SHOULD support asynchronous request/response (ie, a response is > expected, but the sender is not "waiting") > C) SHOULD support one-way communications of requests, notifications, > etc. (ie, > the sender gets no response of any kind) <jd> See what you think of what I ended up doing. > >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. > <arw> I would leave as-is. <jd> 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. > > <arw> Recommend adding a sub-requirement: > [STD-CON.003.1] The Manageability Interface MUST NOT inhibit the > simultaneous usage of > existing standard management environments and protocols (at a minimum, > WBEM/CIM and SNMP). <jd> Done. > > >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. > <arw> Works for me. <jd> OK. > >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:" > <arw> Works for me. <jd> Done. > >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? > > <arw> Perhaps the following words in SEC.001 will help: > "The Manageability Interface MUST enable secure management, as dictated > by > the threats of the environment. This includes (but is not limited to) > support for > the functionality described in the sub-requirements, SEC.001.1-6." <jd> Done. > >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. > > <arw> Both Andreas and your points are good. Suggest: > "The Manageability Interface MUST be NAT and firewall "friendly", > meaning that > the interface MUST NOT require additional support in NAT and firewall > products, > and that sufficient information MUST be provided for a firewall proxy to > inspect > the management messages." <jd> Done. > >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. > <arw> Done. <jd> Agree. > >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. > > <arw> Suggest removing the new requirement. The section talks about > model neutrality, > but this new requirement talks about switching existing models to use a > MUWS one. That is not > possible unless WSDM defines a model (which right now, is not true). > However, could we > reword the existing requirement as follows: > "The Manageability Interface MUST be model neutral and be able to work > with multiple > existing, domain specific models (at a minimum, the information exposed > by CIM and > by the standard MIBs of the IETF)." <jd> Done. > > >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. > <arw> Suggest that we leave as-is. <jd> Done. > >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. > <arw> Suggest wording the item as: > "Events MUST be specified according to a standard XML management event > Format." <jd> Done. I added "or extensions to such." > >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. > <arw> I think that our changes to MDL-ESP.001.7 help to address this. I > wouldn't remove > these requirements. <jd> Done. > > 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. > <arw> I would add this requirement. <jd> Done. > >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. > <arw> As in #12, I would add the following words to the end of the > sentence, > "... (at a minimum, the information exposed by CIM and by the standard > MIBs of the IETF)." <jd> Done. -- John DeCarlo, The MITRE Corporation, My Views Are My Own email: jdecarlo@mitre.org voice: 703-883-7116 fax: 703-883-3383 DISA cube: 703-882-0593
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]