[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf RE: script extensibility I-D

Forwarding non-subscriber submission ...

------- Forwarded Message

From: "Wallis, David" <David_Wallis@bmc.com>
To: Randy Presuhn <rpresuhn@dorothy.bmc.com>, snmpconf@snmp.com
Subject: RE: script extensibility I-D
Date: Tue, 26 Jun 2001 02:30:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;

Dear Randy,

Thanks for setting me straight on standards track vs. experimental.

As to your question regarding draft-ietf-snmpconf-pm-06.txt, a quick perusal
of the document prompts me to ask the following questions:

1) What is the justification for creating a new PolicyScript language rather
than using an existing language? The PolicyScript language is extremely
similar to Java and its variants and the three differences noted in the
"Quickstart for JavaScript/ECMAScript/JScript Programmers" are not what I
would consider to be critical to expressing policy, nor are they language
improvements. So why not define an API or PDU instead of a language?

2) Assuming a new language is needed, why not base it on MIB syntax? It is
already necessary to know the MIB language in order to describe the data
that the policies will be based upon. If a single compiler could be used for
both code and data, it would simplify implementations as well. A common
representation will allow a single scanner/parser and a single storage
mechanism. (Note that Lisp derives a great deal of its power from its
ability to express code and data using identical syntax.) Since the code
must be pushed to heterogenous managed nodes, some compatible data format
must be chosen for transmission. Why not choose a data format compatible
with other SNMP data (i.e. a MIB)?

3) Why are function definitions and enums not supported? Policy needs to be
expressed as coherently as possible. Functions and enums are both highly
effective abstraction mechanisms, and I would not want to have to define a
large body of policy code without them (or their moral equivalents). To add
insult to injury, the pre-processor is also excluded.

4) Why is there only one scope for variables, with loosely-typed data, and
yet variable declarations are required? A variable declaration carries no
information content if it does not specify scope and type information. A
statement with no information content is, by definition, noise. Noise should
not be permitted in a language concerned with the clear, concise expression
of policy.

5) Won't the use of the term "role" to mean any "characteristic of a managed
element" be confusing? We already have the established definition of role to
mean "the profile of security enablements necessary to accomplish a
particular job function by a user." I particularly object to a simple
boolean like "paid" to be given the exalted term of "role". This is not a
role, it is merely an attribute or property or characteristic or element
parameter, so why not use one of these terms?

6) The integer type is defined to range over -2^63 to 2^64-1. Surely it
would be an extremely rare policy that would require such extremes of
integers for its expression, and yet pervasive policy enforcement will
require for some time to come that such expressions be interpreted on a lot
of equipment with less than 64-bit word lengths. Why are 64-bit integers

7) The integer type is defined to require inconsistent treatment of negative
and positive overflow. Positive overflow is to be ignored, a dangerous
proposition in policy enforcement. Negative overflow, surprisingly, does not
necessarily result in an RTE, instead the result is undefined. Why?

8) It is unclear how expressions in the language are to be typed if "var"
variables can be either strings or integers, and string operators also have
integer interpretations. How do I know "+" means concatenation and not
addition in a given expression such as a + b? Having worked with JavaScript,
I can testify that it is important to make string and integer operations
syntactically distinct, especially if variables are loosely typed. (If a
simple language is desired, integers are unnecessary and should be
eliminated in favor of automatic and transparent conversions, as is done in
many other interpreted languages.)

9) Making a distinction between character constants (e.g. 'c') and strings
(e.g. "character string") is not useful. Why this carryover from C/C++?
Allowing a string of any length to be delimited by either single or double
quotes *is* useful as it permits unescaped single or double quotes in the
other type of string.

10) Perl programmers will be unpleasantly surprised to learn that the die()
function does not have the arguments they expect. Both defer() and die() are
noisy; and the entire defer feature is of dubious necessity, and predictably
error-prone to implement. It should be eliminated in the interest of clear
policy expression. As a policy writer, the last thing I want to happen when
a policy encounters an RTE due to less than well-defined conditions is to
have another similar policy substituted that is equally likely to fail as
well. Why not use Python's try statement or Perl's eval {} construct for
error handling? That way the interpreter doesn't have to abandon the entire
policy if one expression fails, and code can take different actions if
different expressions fail, or if different errors are detected in one

11) To avoid the problem of a security policy not being available when
needed after redefinition of roles or capabilities, policies should be
tagged with a "preload" attribute when they are security related or
otherwise would cause problems if they are not immediately available when

12) Why is the policy execution security model not well-defined? One might
hope for something along the same lines as RFC 2575 (view-based access
control) and RFC 2574 (user-based security model). This draft does
"recommend" use of those models, but doesn't go into any detail on how they
are expected to be used. There is no detail on what safeguards are to be
placed on the pushing of policy code from the management station to the
managed nodes. I would want to know when the view-based access controls
should be applied, and when the user-base security model should be applied,
and the details of how to extend those models to cover execution access in
addition to read/write access, and how to identify the responsible user at
each point. There are many possible answers, so why leave us guessing? 

13) Why is it required that policy code execute locally with the credentials
of the person who last updated it? (And if this is a good idea, why not make
it the default for remote execution as well?) Why not use the credentials of
the person who installed the management station software, or the person that
installed SNMP on the managed node, or a person defined to own all global
policies? There is no thought given to the possible need to revoke a
credential, or replace it with that of another principal if someone leaves
the enterprise. 

14) If a credential is not valid for execution on a given managed node, what
is to be done? Is the global policy to be ignored? How does a managed node
define who may or may not issue global policies that apply to that node? Are
we to assume that the credential is the same as a logon credential for the
operating system of the managed node?

David Wallis

------- End of Forwarded Message