Subject: snmpconf #4: Code reuse

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 11:28:23 -0700

Options as I see it (I'm not going to describe how each one "could" be
done, as this message would get far too long.  If feedback (consensus)
is given that one should be explored more, I'd be happy to elaborate
on an item at that time):

1) Leave things as they are without changing the document.  This is
   probably the easiest option.  I suspect, however, that as we get
   into the point of interoperability and even more likely deployment
   and usage tests this will come back to bite us.  I doubt it'll be a
   huge problem until then.

2) Implement function definitions in the base language.

   Problems: This was previously decided not to be done.

3) Implement functions as a new capability, registering the "function"
   capability in the capabilities table.

   Problems: It's beyond a basic capability.  How to deal with
     some machines that don't have functions and others do?  To a
     large extent, if you had any that didn't you'd write your code
     ignoring (and suffering from) the reuse problem.

The following suggestions all have one problem:
  - the first index to the code table is explicitly managed by the
    Filter/Action tables and creation of new entries is currently
    prohibited by the description clause of pmPolicyCodeProgramIndex.
    This would have to be dealt with in order to implement any of the
    below.

4) Implement a "gosub(codenum)" style function that calls the
   functionality of another code block.

   Problems:
     Values would have to be passed via something like the scratchpad,
     for instance.

5) Implement a "link to" set of columns in the pmPolicyCodeTable.  The
   definition for a given segment isn't stored here, but rather in a
   different code/segment base.  Two new columns would be needed,
   something like otherCodeIndex, otherCodeSegment.  When the policy
   engine hit this row it would check to see that the code definition
   was "", and refer to these numbers to find the real location of the
   code (or else run-time-error).

   Problems:
     Kind of hacky feeling.

6) Implement a "copy from" column in the pmPolicyCodeTable.  It would
   copy code from a different code  so that 

   Problems:
     Copies from an entire code entry, or just a segment.  If from an
     entire entry the value should be the int pointing to that
     segment.  If a segment, however, two values are needed which
     would require two additional columns and a "doit" button or
     something.

     Tracking: if code is copied, it is not updated later and all
     entries must be updated by the manager.

My personal opinions:

  1)   this will bite us later if don't fix it now.
  2)   this is the way to go, IMHO, but I won't attempt to argue this point.
  3)   This is probably the next best thing to do.
  4-6) ugly, but "could work".  I'd prefer 4 and probably think 5 and
         6 aren't worth the trouble.
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 Apr 2001 15:20:04 -0400

My own inclination is either (1) [Don't do functions] or (2) [Do 
functions].  The various "sort of" solutions that Wes described (including 
making it a capability) all seem like bad compromises.
Yours,
Joel M. Halpern

PS:  I am slightly inclined to leave them out.

---

From: Pablo Halpern <[email-masked]>
Date: Mon, 02 Apr 2001 15:51:46 -0400

Just my 2 cents:

I agree with Wes that we need a decent mechanism for code reuse in the 
policy language. I've been part of debates as to which accessor functions 
should or should not be put into the language. We tried strike a balance 
between completeness and minimalism. That balance will be wrong for some 
people. A function-call mechanism gives the user a way to make up for the 
general functions we left out as well as to write functions that are 
specific to his/her needs.

I agree completely with the ranking Wes gave to the options he described 
Specifically:

I  prefer #2 (implement functions in the policy language) although there 
would need to be a method of registering functions (not hard).

Of the other options, #3 (add functions as an optional capability) is the 
cleanest but, for the reasons mentioned, would probably discourage portable 
code.  Works well for device-specific policies.

I think #4 (a gosub(function-number) call) could be extended to take a 
single additional argument, which would be retrieved by the called function 
the same way policy arguments are retrieved. I don't see any advantage to 
this over #1 except to be able to say that we stuck to the initial decision 
not to have true functions. (A foolish consistency ...)

>          6 aren't worth the trouble.

- Pablo
----------------------------------------------------------------------
Pablo Halpern                      http://www.halpernwightsoftware.com
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 16:19:49 -0700

>>>>> On 02 Apr 2001 11:28:23 -0700, Wes Hardaker <[email-masked]> said:

Wes> Options as I see it (I'm not going to describe how each one
Wes> "could" be done, as this message would get far too long.  If
Wes> feedback (consensus) is given that one should be explored more,
Wes> I'd be happy to elaborate on an item at that time):

I should have mentioned in my previous post that I've also not liked
the way that the pmPolicyFilter and pmPolicyAction numbers are not
writable and are assigned for you.  This would be one method of
promoting reuse: if actions and filters could be reused it would make
things easier to maintain.  As is, the filter has to account for every
possible test it might want to do.  It'd be easier to have multiple
"compartmentalized" filters that may all point to the same action
giving you OR type semantics within the policy Table itself and allows
you to more easily determine where errors are (separate error
counters per row).

Currently my filters/actions would be something like this:

  if (serivce is GOLD
      OR interface is local office subnet
      OR interface is 100Mb)
     set special QoS

Writing it like: 

  if (serivce is GOLD)
     set special QoS
  if (interface is local office subnet)
     set special QoS
  if (interface is 100Mb)
     set special QoS

Provides *some* reuse, realizing of course that the "set special QoS"
action may be called more than once.  It does, however, provide me to
apply the second filter during a scheduled time or temporarily
(rowstatus = volatile) but the others are more permanent.

Yet more thoughts,
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 16:25:42 -0700

>>>>> On Mon, 02 Apr 2001 15:20:04 -0400, "Joel M. Halpern" <[email-masked]> said:

Joel> My own inclination is either (1) [Don't do functions] or (2) [Do
Joel> functions].  The various "sort of" solutions that Wes described
Joel> (including making it a capability) all seem like bad
Joel> compromises.

I agree completely in general.  We should simply do them ;-)

Joel> PS:  I am slightly inclined to leave them out.

I'd love to hear reasons behind your thoughts other than "slightly
inclined".  IE, why not?

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 16:24:16 -0700

>>>>> On Mon, 02 Apr 2001 15:51:46 -0400, Pablo Halpern <[email-masked]> said:

Pablo> I think #4 (a gosub(function-number) call) could be extended to
Pablo> take a single additional argument, which would be retrieved by
Pablo> the called function the same way policy arguments are
Pablo> retrieved.

I thought about that.  That truly becomes "function like" except the
naming convention for the function is by the code reference number
rather than a name.

Anyway, as long as we're talking about it, I'd rather shoot for the
moon and say a variable number of arguments could be added (we already
have sprintf taking a variable number of arguments so the capability
to deal with it is already present in some fashion).

But then, I'd rather define a real function and reference it by name.

I *suppose* that a decent script compiler could let you define a
function and then convert it into gosub()s or changing all the text to
inline (required by the mib now), but then its non-standardized and
the code isn't portable from manager to manager.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 03 Apr 2001 17:19:18 -0400

My reason for leaning towards leaving them out is that while functions 
(code reuse) are nice to have, they are not strictly necessary.  And this 
proposal is already sufficiently large and complicated that the magnitude 
may deter people from adoption.  I believe that most (maybe even all) the 
current features are there for good reasons.  But that does not mean we 
should not be very cautious about adding more.

Yours,
Joel

---

From: Wes Hardaker <[email-masked]>
Date: 03 Apr 2001 17:25:38 -0700

>>>>> On Tue, 03 Apr 2001 17:19:18 -0400, "Joel M. Halpern" <[email-masked]> said:

Joel> My reason for leaning towards leaving them out is that while
Joel> functions (code reuse) are nice to have, they are not strictly
Joel> necessary.  And this proposal is already sufficiently large and
Joel> complicated that the magnitude may deter people from adoption.
Joel> I believe that most (maybe even all) the current features are
Joel> there for good reasons.  But that does not mean we should not be
Joel> very cautious about adding more.

Thanks for spelling that out for me.

Now, if only we could reach a consenus...  Current count is 2-1 in
favor of adding something to support reuse.  That's not very
many opinions.

-- 
Wes Hardaker
NAI Labs
Network Associates