Policy Based Management MIB
Note: This ballot was opened for revision 15 and is now closed.
(Bert Wijnen) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) (was Discuss) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
Comment (2004-01-08 for -** No value found for 'p.get_dochistory.rev' **)
I'm a no-obj on this one, but I have to say that this sort of full language specification makes me a bit nervous. I hope we really have the necessary langauge design expertise for this sort of thing.
(Ted Hardie) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2003-12-31 for -** No value found for 'p.get_dochistory.rev' **)
There are some line wrap problems in the Security Considerations section that ought to be fixed.
(Allison Mankin) No Objection
Comment (2004-01-13 for -** No value found for 'p.get_dochistory.rev' **)
Bert wrote: W.r.t. security issues. I think it would help a lot if we add a description how this could be used in the most simple way and then be reasonable secure. Like a small set (one or two) principals (that is the term we use in SNMP Arch, but maybe users is a better term) who can create and modify the scripts and then also schedule them. So that is a vey controlled environment. We should then also add a serious warning that the system allows for a lot more flexible ways, but that such makes it much more complex to keep things properly configured. It brings a lot of risk for error and thus security holes because of misconfiguration. It would be a great idea to add the text you describe. I can see it appearing in the most detail in the Security Considerations, but I'd also recommend a flavor of it in Section 3, after the discussion of enabling the management of hundreds of thousands of variables, according to policies that include geographic, price-sensitive ones, etc. Then there are three subsections: Roles, Capabilities, and Time. After those (end of page 7) would be a good place to put a Caution section.