[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000
IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000
Reported by Dale Francisco (firstname.lastname@example.org)
and Steve Moulton (email@example.com).
Continued with Steve Waldbusser's presentation,
in the section "Policy Processing Questions". We
resumed discussion at question (9). After
completing this section, we moved on to
"Execution Environment Questions", then "Language
The questions that generated the most discussion
were on how to select instances in filters
(Policy Processing questions 21-23 below), and
whether the language and the accessor functions
should be extensible (Language Related question 4
We decided that the next interim meeting would be
in Knoxville, TN, hosted by SNMP Research.
Andy == Andy Bierman firstname.lastname@example.org
Bert == Bert Wijnen email@example.com
Case == Jeff Case firstname.lastname@example.org
Harrington == Dave Harrington email@example.com
Joel == Joel Halpern firstname.lastname@example.org
Jon == Jon Saperia email@example.com
Partain == Dave Partain David.Partain@ericsson.com
Randy == Randy Presuhn Randy_Presuhn@bmc.com
Steve == Steve Waldbusser firstname.lastname@example.org
Policy Processing Questions
9) Is it a requirement that we support UTF8 in
our accessor functions?
Randy Presuhn will work with Steve on this.
10) Do we want to feed values from filters into
policy action? E.g., suppose there's filtering
on interfaces, and say I/Fs 1, 2, fail, but I/F 3
succeeds...should there be any state variables
that linger from the earlier, failed processing?
And after we get a return value do we want to
fire an action, and if so with a param other than
Andy: Suppose I go through RMON control table
where ifIndex is a columnar value, not an
index...how would I pass this into an action?
Steve: The same way the filter got it.
11) Is the constraint of left and right useful (cleavage into
two scripts, filter and action)?
Jon: One of the compelling reasons for keeping them
separate is it may be handy to do the eval on
left side at a different time than eval on right
side, especially if one or the other is
computationally complex. Left decides what policy
Steve: Another advantage is code reuse. E.g.,
imagine an icon for "select all enet I/Fs", drag
to left, "turn off all I/Fs", drag to right.
Also, Policy group supports this split.
12) Do we need both action and filter or would
one do? What are the interactions allowed?
This just restates questions 10 and 11. There was
no further discussion on this.
13) Need to address the question of the syntax of
an identifier, what is the proper syntax of
ifType.$1--what is the structure including
Steve: Does anyone want a different syntax? I'd
like to prove what we're doing is inefficient
before changing it.
Joel: How do we handle wildcarding on multiple
indices? Will they each get a wildcard?
Steve: They should, the design isn't finished yet.
14) What are implications of wildcarding and
implications in both directions in the role
Steve: I can't remember what this one meant.
Joel: Larger issue: We're trying to build a
solution, but what if there are base attributes
that are used by both alternatives [snmpconf and
rap]. "Role" is particularly problematic. I would
like to have one table where roles are dealt
with, i.e., not different than what rap group is
Steve: In a offline activity, we're working with
rap to either resolve the identity or come up
with different names.
Joel: It'd be nice if were easy to factor out the
simple cases of role use.
Steve: What we called assertions...as we go
through usage examples, we may find it'll be
difficult for a manager to look at a filter and
know whether it should be downloaded to a
system...but you do know what roles and
capabilities are on a system. "Assertion" is a
term for pulling some terms of a filter out that
would allow a mgmt station to know it didn't need
to download a particular policy.
Case: Wildcarding has been used in two places.
One associated with roles, one with identifiers.
Item #14 really isn't about roles, it's about
identifiers. With roles: How do you do roles and
role combinations? #14 is suppose you had a
table that's not the ifTable that has two
indexes, and you want to wildcard over one and
hold the other constant. Another person asked
what is the balance between complexity and
functionality (is wildcarding too expensive?).
Jon: I'm keeping a list of side topics such as
assertions and roles for Saturday afternoon.
15) How big should an expression be allowed to be?
Steve: No larger than necessary [laughter]. Most
filters will be 1 or 2 or 3 lines, so I picked
something very high (65k).
Jon: I think that's fine for now. We can express
local limitations using the CAPS file if
desired. So different vendors with different
memory constraints can restrict as necessary.
16) Not possible to download all policies
everywhere. Must subset what to send, so must
handle two errors: download superfluous policy,
fail to download needed policy.
Steve: Two cases: (1) False positive (superfluous
download)...filter never executes on that
system. False negative would have operational
impact (didn't download something that was
needed...if it had been, it would have
executed). Assertions will make it easier to
decide what to download, but haven't heard an
idea of how to prevent false negatives.
Case: This is more something that should be
observed than something we need to worry about.
Just need to alert the readers. This really
isn't an open issue.
Randy: I agree with what Jeff just said, also
feel that we need to be careful about saying
whether or not it's a problem. If we try to
determine whether a filter could ever be true, it
gets messy, possibly even not computable with a
sufficiently powerful filter language.
17) How do we detect and how to standardize error handling?
Steve: No text yet on notifications of errors
(not necessarily SNMP notifications, but even
just error counting variables)...will investigate
Randy: Should look at history of script and
expression MIBs...this is a deceptively devilish
problem. This has some things in common with
both of them.
18) Estimate the # of policies we need to handle. We need the
architecture to scale up and down--what attribs needed to meet the
Jon: Start collecting usage scenarios, need a
base level understanding of how many expressions
are out there, how large they'd be, accessor
functions. Anyone who has experience in this
area please get in touch with Steve...any
volunteers? [No response.]
19) Where to start the policy evaluation?
Steve: That is, is the role the first thing to
evaluate in order to reduce computation? (Move
role comparison to front of filter to
short-circuit evaluation). Should this be in the
form of a recommendation? Role table and element
table help bound the problem.
Jon: Even as we get more examples, we may want
to modify Rules for Filter writers. What is the
general sequence of events that a policy mgr
takes to get a policy properly executing..."This
is how the system works start to finish."
Case: All of these questions are subitems of
"What does the execution environment look
like?". 19-24 are all related.
20) How often to eval filter and when?
Steve: Don't want to leave this completely up to
agent. Need to specify on a policy-by-policy
basis. Straw proposal: 2 new objects,
filterMaxLatency, actionMaxLatency. Not the time
between when a policy executes on I/F 7 and I/F
8, but on the same I/F. Agent is free to execute
filters and actions in any order.
Harrington: On ordering, if I write an action
that has Sets, is that not guaranteed order?
Steve: No, within an action, order of execution
Harrington: Just for sanity's sake, should we add
language saying that agent is ultimate arbiter of
Randy: Language that can be stolen from
21) Is the iterator inside or outside the filter statement?
Steve: E.g., should the expression have a for-loop
that would iterate through interfaces? I think
it's a bad idea. How to find instances quickly
is something that the execution environment
Harrington: I think it may be clearer for people
to be allowed to write iterators.
Steve: It may take some mindset change to think
in terms of policy rather than iterators.
22) Is one iterator sufficient or do we need nested iterators?
[same as 21].
23) How do we select instances?
Steve: Execution environment hands elements to
filter. That's how we know what "this" element
Jon: I think we'd had discussions where it was
the method that was used to select from all
Steve: Right, this was the element type
registration table. A way for mgmt station to
download to agent what elements it wants under
policy control. Agent doesn't know (out of the
box) whether policies are executed on I/Fs,
circuits, whatevers. This table provides the OID
of say, right up to ifIndex. The agent
conceptually does a walk of that OID, comes up
with a hit for every I/F instance.
Jon: One thing that isn't covered is shortlived
Steve: This table is just a way to describe to
the system things it doesn't understand. It
would be difficult to create a standard set of
element types. Shouldn't confuse conceptual
algorithm with how agent implements it. Text
allows for builtin element types, so e.g. for
ifIndex, it already knows how to handle objects
in this table. I.e., not a polling arch.
Randy: Just know the base OID doesn't give you
the info to get to indices..they're not
Steve: This system treats the OIDs opaquely.
Treats suffixes opaquely as well, whether one
subid or many. Suppose FR circuit table, 1.111,
1.112, 5.317 (ifIndex, DLCI). $1==1, $2==111.
Randy: Isn't it then possible to derive from the
filter expression itself the contents of this
Steve: Yes, sigh. It's not artificial
intelligence, but it's close.
Randy: At expression download time, you look for
the OIDs that this filter expression cares about,
that gives you the element types that the table
needs. If the filter expression needs to know
how the indexes are composed, then the filter is
required to know what the element name is. If
ifOperStatus is in the filter exp, then you know
ifTable is an element type.
Steve: Doesn't that make your brain hurt? We
haven't discussed expressions that effect things
that contain things that they work on (e.g.,
touching the parent ifIndex of an FR circuit).
Randy: Is the type table necessary to evaluate
the filter expressions? If there's sufficient
info in the filter itself, than the type table is
superfluous. You need a way of specifying the
iteration context per filter--if you have that,
the table is superfluous. If there's always a
(type==something), the table is superfluous.
Steve: I'll take an action item to see if I can
get comfortable with it.
Randy: I think that since all your expressions
have a "type==something", that says something
about the structure of the filters.
Steve: Autoregistering element types by
inspection of policy filters (especially if
there's a mandatory "type==something").
24) What do we want for role--iterators...how many, where?
Execution Environment Questions
1) What are the implementation target environment
requirements for the work?
Steve: E.g., what's the size of 'int'? Don't
want people to have to check ints with sizeof()
every time they use them. Still not entirely
defined...please send notes to mailing list when
you find things like this.
2) What are minimal requirements for systems that participate
in policy configuration?
Steve: E.g., date and time?
Jon: I wanted to ask...I think we want elements
to execute on internal schedules, but do we want
to allow a model of operation where the managed
device says "I don't have date and time, so you
have to do it for me"?
Randy: I think it's a deployment decision on
whether time is local or distributed.
Jon: Architecturally we shouldn't add a
3) Would like a clearer definition of what "this element" is.
4) What's the scheduling environment?
Language Related Questions
1) Language for expressions: Do we want to use an existing one?
Do we want to create a new one?
Steve: We've been given a directive that we're
not allowed to define a new language. The IESG
will look askance if we do so. So instead, let's
subset an existing language. There's a BNF in
the doc that shows a subset of ANSI C. The BNF
doesn't fully describe the syntax. Normative
reference to ANSI C. Would subset of C or subset
of PERL be better? What we have is such a
restricted subset of C that I think it's also
PERL [laughter]. There is no normative ref for
PERL, and the PERL5 to PERL6 is a huge
non-backward-compatible change, so I think C
really is the right choice.
Case: Primary difference between having two
identical grammars (subset of C / subset of PERL)
is marketing. You're concerned that it's true,
and we're talking about marketing.
Joel: I think we need this level of complexity,
but I think we need to spell out exactly why we
need this level of richness.
Steve: I agree. We'll come up with a list of
examples, learn and realize what's only
achievable through this langauage, then write
Randy: There's a rather PERL-like script language
that BMC has used for years that has a normative
ref in an ISO standard. SMSL is the name...one
of the language for ISO command sequencer stuff.
May or may not be useful, but thought I should
2) Temp variables? Garbage collection?
3) Is UTF8 required?
Randy: Anything outside the 7-bit range gets
entered as multiple "\" escaped sequences if
we're using subset of C.
Case: We have to be sensitive to
internationalization issues, it has to be UTF8,
other schemes wouldn't be good. If we decided to
support C except for UTF8, I don't think the IESG
would shoot us down. So let's just do good
engineering and it'll work out.
Joel: IESG mandate is that we shall
internationalize. We need to know how to put
UTF8 strings in expressions, but _not_ in
Randy: there are languages that allow UTF8
variable names, and in some dev environments
Steve: Randy and I already have action item to
4) Extensibility of language and accessor
functions without revisiting the standard?
Current doc says no subsetting, no extensions.
Randy: I agree with that for the language. In
the library it gets trickier. We dealt with that
in the Script MIB (extending accessor
Steve: Regardless of what we say, vendors will
extend accessor functions.
Case: You want consistency across the system. But
there are two issues here: product
differentiation, and spec evolution. We should
be cautious in terms of blocking spec evolution.
One way to allow evolution is a standardized
system for extension. So as we find useful
improvements, we can upgrade easily. I think
it's also true that vendors will make
non-standard extensions, but I think we can
contain the damage by specifying how such
extensions are made. It might be as simple as
having an app level err code that is returned to
indicate you didn't have a particular accessor
function available. I don't think we should say
Randy: You want to be able to interrogate a
system to discover the language level supported
and accessor functions supported, so you don't
have to wait for a runtime error to find out that
a policy wasn't the right version for a device.
Steve: Do we need to do anything explicitly?
Partain: There are going to be extensions. We
should make it possible to do in a standards
Andy: I think the draft currently says only the
specified accessor functions are allowed...that's
a mistake...I think there needs to be an accessor
Steve: The high level goal is to manage a network
as a whole, not a device. The network will
include devices from many vendors. If we have
subsetting and extensibility, it gets hard to
Andy: Capabilities grow over time, and we can't
ignore it. If I'm managing a class of devices
and I know it has the extension, then I want to
use it. A CAPS table, read-only.
Steve: I don't want to allow subsetting of this
very minimal set of accessors.
Case: Unlikely we'll resolve this today. Two
separate issues: Language extensibility, accessor
extensibility (Andy was just referring to
accessor extensibility). I'm uncomfortable with
waiting until the first extension comes along to
figure out how to allow for extensibility. Andy
is correct that the difference between extensions
and subsets...they're really the same problem
from an interoperability point of view. We need
to design something that will evolve gracefully
Bert: Are we struggling over whether we need the
absolutely minimal set of accessors? I think we
need a minimal subset of accessors available, even
if there's a registry.
[end of discussion]