Subject: Re: closing Script MIB issues

From: Randy Presuhn <[email-masked]>
Date: Mon, 3 Apr 2000 23:44:31 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Mon, 03 Apr 2000 16:17:51 +0200
> From: Eamonn McManus <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>
> CC: [email-masked], [email-masked]
> Subject: Re: closing Script MIB issues
> References: <[email-masked]> <[email-masked]>
...
> I would like to re-suggest the scheme I described in my Simple Times article,
>   http://www.simple-times.org/pub/simple-times/issues/7-2.html#tools
> 
> 
> * Entries can only be added to the smCodeTable before the corresponding
> smScriptAdminStatus is ``enabled.'' 

I'd really rather avoid introducing inter-table dependencies like this.
They add significantly to implementation and test complexity.

> * The first entry to be added to the smCodeTable must have smCodeIndex 1, and
> every subsequent entry must have smCodeIndex one more than the current largest
> value. Each entry must have its smCodeRowStatus set to ``active'' before any
> subsequent entry can be added.  Entries once added to the smCodeTable cannot be
> deleted. 

This is a fair amount of added implementation complexity.  What's the
benefit?  It looks like it would save about four bytes per "line" of
pushed scripts after the download, and perhaps a bit more during
download to manage "quarantined" lines.

> These constraints mean that during download the agent does not have to store
> smCodeRowStatus or smCodeIndex values anywhere. It does have to remember where
> each smCodeText object is within the script, but only while the script is being
> pushed. 

If "read-back" of scripts is permitted, the byte-offset to index
mapping within a script has to be remembered by an implementation
anyway, along with the length of the "line" and so on, so that
those "lines" can be reconstructed for retrieval by a manager.

> * Once the script has been pushed, the manager sets the smScriptAdminStatus to
> ``enabled.'' As at present, the fact that the code comes from the smCodeTable is
> indicated by an empty smScriptSource and an smScriptStorageType that is
> ``volatile.'' 

I think that the implementation needs to consider all three in order to
come to the right conclusion.

> * When the smScriptRowStatus is set to ``active,'' an agent may choose to delete
> the smCodeTable, or it may reorganize it so that the same code is presented
> using a different division into smCodeText objects. In particular it may decide
> to chop up the presented text into fixed-length smCodeText objects so that it
> does not have to remember the offsets corresponding to smCodeIndex values. This
> means that the smCodeTable takes up no storage: the agent can construct replies
> to SNMP get requests on the fly. 

Hmm.  This means that the number of "line images" read back
could be larger or smaller than the number sent.  Scary.

This sounds like it would be a pain to test for
interoperability.  I think we could agree that there isn't
much point to providing a read-back facility without also
providing an edit capability.

> If the smScriptStorageType is then made non-volatile, the script text will be
> written to non-volatile storage. 
> 
> * The only way to modify the text of a script after it has been downloaded is to
> delete the smScriptEntry and create a new one. 
> 
> Éamonn (speaking in a personal capacity)

As much as I dislike patches, I've been around long enough
to know that there are times when there's no other choice.
The argument based on script size cuts both ways; on bandwidth-
limited links it's a good motivation for providing incremental
update facilities, which ARE still used in machine-to-machine
communications today.

Based on your article and this thread, I think we have several
alternatives:

    1) leave smCodeTable as it as

    2) deprecate smCodeTable 

    3) create a smSimpleCodeTable with semantics like those
       you describe and deprecate smCodeTable

    4) add smSImpleCodeTable while retaining smCodeTable,
       letting implementators choose and putting some yet-
       to-be-defined weasel words in smScriptTable to explain
       which gets used when.

    5) something else...

>From an SNMP-download feature perspective, we have:

    current: download, readback, edit/patch
    proposed: download, readback (questionable)

Does SNMP-download without readback and edit/patch make sense?

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Eamonn McManus <[email-masked]>
Date: Tue, 04 Apr 2000 11:57:58 +0200

> They add significantly to implementation and test complexity.

I don't understand this objection.  There are already several such dependencies,
notably in the existing smCodeTable: "Modifications of the smCodeTable are only
possible if the associated smScriptOperStatus object has the value `editing'."

> download to manage "quarantined" lines.

On the contrary, my intent was for there to be *less* implementation complexity
as well as less memory overhead.  You don't need to have a table mapping line
numbers to script offsets at all.  You just need the offsets themselves during
download, and not even that once the download is completed.  I'm trying to
imagine the simplest possible model for pushing scripts: you accumulate
successive blocks of "text" until you have the complete script.

I don't know what you mean by "quarantined" lines.

I believe that if nobody has implemented script pushing it is because the
current definition is too costly both in terms of implementation complexity and
in terms of memory needs.  Those are certainly the reasons I didn't implement
it.

> those "lines" can be reconstructed for retrieval by a manager.

No.  I explicitly said that once the script has been downloaded the agent may
redivide it into "lines" as it pleases.  Therefore it can arbitrarily decide
that each line is 64 bytes, say, and convert line numbers into offsets by
subtracting one and multiplying by 64.  This is because I don't see the utility
of reading parts but not the whole of the script.

> come to the right conclusion.

I'm not sure what this comment means.

> could be larger or smaller than the number sent.  Scary.

I suppose I'm either brave or foolhardy, but this doesn't scare me.  I don't
care about the lines; I just want to see the whole script.  How it gets broken
down into blocks during transmission is of no interest.

Possibly there is a difference in perspective due to the fact that the "scripts"
I was dealing with in my implementation were binary files (Java JAR files).  So
the division into "lines" really was (or would have been) completely arbitrary.

> providing an edit capability.

No, I don't agree with that, for the reasons I stated in my article.  I don't
understand under what circumstances you would want to edit a script without
either reading it back into the machine doing the editing or already having a
copy on that machine.  I really don't believe in hand-applied "patches" in this
sort of environment.  Do you imagine there being an editor with a GUI that talks
SNMP to the agent in order to read a screenful of script text and propagate
changes back to the agent?  If not, how would you see patches being prepared and
applied?  It may be that I am blinkered by thinking about my implementation, but
I just don't understand the sort of environment where the current smCodeTable
would be useful.

>        to-be-defined weasel words in smScriptTable to explain

As you might guess, I'd favour (3).  (4) might be an interesting experiment to
see whether anybody in the world chooses to implement the feature-laden
smCodeTable.  But standards are not really the place for experiments.

>     proposed: download, readback (questionable)

To clarify, readback is not "questionable" but "optional".  A management system
dealing with an agent that doesn't support it must support another approach,
such as remembering or refetching the script text.  One reason not to support
readback might be that the agent transforms the script into an internal form and
would have no other reason to retain the original form than to send it back to
the manager.  But I wouldn't be unhappy with a decision that readback is
mandatory.

> Does SNMP-download without readback and edit/patch make sense?

Yes.  In the system I was working with, we wanted to be able to send scripts
from a local repository to a remotely-managed system.  We weren't interested in
reading the scripts back, because the name of the script was enough to find its
text in the local repository.  But the Script MIB as it stands required us
either to have a private HTTP or FTP server as part of the management system, or
to support the smCodeTable.  Both solutions seemed very ugly to me, but the
former was less ugly than the latter, and shouldn't have been.

Éamonn (writing in a personal capacity)