MUWS Document Comments

["Andrea Westerinen" <andreaw@cisco.com>]

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