[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MUWS Document Comments
Since I have obviously been bad and not attended enough meetings, so I can't vote on the MUWS document. However, I have a couple serious issues and concerns with MUWS (#1-14), a couple items that need clarification (#17), and some nits to note (#15 and 16). Here is my feedback: 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. 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. 3. Page 15, SEC.004 - what is a "standalone security model"? This is not clear. 4. Page 15, MDL-EXP.001.2 - .5 - "relevant" is a very imprecise term. It should be removed. 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? 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? 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. 8. Page 17, MNGBL-RES.002 - "... Support some management capabilities" means nothing. This needs to be reworded and clarified. 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. 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. 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. 12. Page 19, DISC.002 - I am not sure what the requirement means. Could this be reworded? 13. Page 19, DISC.003 - Appears to be a duplicate of MDL-EXP.001.7.5, but the latter is a SHOULD. 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." 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 ... - 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. - 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" - Page 18, MAN-MGMT.001 - Is a duplicate of 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"? - Page 19, DISC.001 - Is a duplicate of WS-BASE.001.3. - Page 20, EXTN.001 - Clarify that this requirement enables extension and MDL-EXP.002 indicates that changes MUST be exposed. Andrea
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]