I did a cursory review of the Coman drafts. These consolidate a rather useful body of knowledge, even if it is still in flux in many areas. It may be more important to get them published in some state, with an explicit qualification of being somewhat work in progress, than trying to further polish them until nothing of substance is left. My strong recommendation here would be: if in doubt, publish.
The most important aspect that probably needs to be expanded is the security considerations, with a view to resiliency. Not having a management interface is a security liability. Adding one is an even greater security liability. Instead of trying to say what is needed here in my imperfect words, I’d like to refer to the discussion under number (5) in http://geer.tinho.net/geer.blackhat.6viii14.txt In a related vein, many of the coman-specific management issues stem from the peculiar lifecycles the devices go through. draft-garcia-core-security is the best document we have about this aspect, and the two coman documents probably should be developed in unison with this one. It is not always easy to separate “constrained network” considerations from “constrained node network” considerations, and probstate might benefit from one more editing round to get the right focus in the right places. (Adding another unfocused term, LLN, and alternating back and forth, does not help.) A related editorial problem is the usage “non-constrained” (which of course is physically impossible) — in RFC 7228 we missed coming up with good terminology for what we mean by less-constrained or affluent systems. But these are more general editorial problems, and it is maybe too much to expect them being solved here. I support Thomas’ comment on the use of the term “requirement”. The definition of “Priority” in Section 3 of probstate, where a requirement suddenly becomes less important just because it happens to be impossible to fulfill, is a symptom of this. Editorially, the requirements list would become less tedious if Requirement Type, Device Type, and Priority could be put into tabular form, maybe together with Req-ID. 2.002 does not mention the cost of copying and maybe should. 2.003 may be a bit optimistic about “compression” (as opposed to concise representation in the first place), but then this term isn’t really defined anyway. A major problem with using classical network management thinking for constrained devices is that, for these, there may be little difference between network and application configuration, including firmware updating. There are some actual “requirements” (6.*, 9.001 — which is “medium” priority???); it may be worth calling them out. I don’t understand 10.004 vs. 6.* — while secure message transport is a good choice in many cases, it is ultimately there to support security objectives. A great aspect of the use-case document is that it calls out the management responsibility for some of the use cases; this should always be done. It would be good to know in which cases that responsibility is clearly separable from the application responsibilities (in the way network management has been traditionally). “Medical Applications” is not a use case, it is a whole universe of use cases, and one or two should be included as their own use cases (e.g., separating a BYOD/personal interest case from a professional/healthcare use case). I’m sorry for throwing out all these observations in front of the authors; again, if in doubt: publish, but maybe expand on some of these observations in a “future work” section. Grüße, Carsten _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
