Subject: IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000

From: Dale Francisco <[email-masked]>
Date: Tue, 29 Aug 2000 15:44:31 -0700 (PDT)

IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000

Reported by Dale Francisco ([email-masked])
and Steve Moulton ([email-masked]).

Summary
=======
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
Related Questions".

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
below).

We decided that the next interim meeting would be
in Knoxville, TN, hosted by SNMP Research.

Attributions
============
    Andy == Andy Bierman            [email-masked]
    Bert == Bert Wijnen             [email-masked]
    Case == Jeff Case               [email-masked]
    Harrington == Dave Harrington   [email-masked]
    Joel == Joel Halpern            [email-masked]
    Jon == Jon Saperia              [email-masked]
    Partain == Dave Partain         [email-masked]
    Randy == Randy Presuhn          [email-masked]
    Steve == Steve Waldbusser       [email-masked]

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
true/false?

    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
    applies to.

    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
wildcarding?

    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
tables?

    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
    doing.

    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
    further.

    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
goals?

    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
    is assured.

    Harrington: Just for sanity's sake, should we add
    language saying that agent is ultimate arbiter of
    timing?

    Randy: Language that can be stolen from
    Expression MIB.

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
    should provide.

    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
    is.

    Jon: I think we'd had discussions where it was
    the method that was used to select from all
    possible objects...

    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
    instances.

    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
    self-describing.

    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
    table?

    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?

[No comments.]

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
    constraint.

3) Would like a clearer definition of what "this element" is.

    [No comments.]

4) What's the scheduling environment?

    [No comments.]

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
    down rationale.

    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
    mention it.

2) Temp variables? Garbage collection?

    [No comments]

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
    variable names.

    Randy: there are languages that allow UTF8
    variable names, and in some dev environments
    that's useful.

    Steve: Randy and I already have action item to
    fix this.

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
    functions).

    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
    "no extensibility".

    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
    based way.

    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
    registry.

    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
    manage.

    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
    over time.

    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]