Policy Based Management MIB
RFC 4011

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' **)
No email
send info
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' **)
No email
send info
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' **)
No email
send info
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.

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection