Subject: Re: closing Script MIB issues

From: Randy Presuhn <[email-masked]>
Date: Tue, 4 Apr 2000 13:54:28 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 04 Apr 2000 11:57:58 +0200
> From: Eamonn McManus <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> CC: [email-masked]
> Subject: Re: closing Script MIB issues
> References: <[email-masked]>
> List-Id: IETF disman Working Group mailing list <[email-masked]>
> 
> 
> Randy Presuhn wrote:
> > > From: Eamonn McManus <[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.
> 
> 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'."

It's bad enough to make one table dependent on a value in another (the
current situation).  It's worse to make a table dependent on an object
in another having not had some particular value at some time in the past
(the proposal).  It wouldn't bother me as much if the proposal read
"when the corresponding smScriptAdminStatus is not 'enabled' rather
than "before the corresponding smScriptAdminStatus is 'enabled'".

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

This is asking for trouble with typical "conformance" test tools
that check mib implementations by checking that what comes back
in response to a get request is the same as what was written by
the most recent set request for that object.

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

A line image that is not "active".  At least some level of
quarantine is necessary to implement RowStatus correctly so
that partially-created things (createAndWait) can be cleaned
up.

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

If we find that there are not at least two implementations of
this capability, and we decide that the document is otherwise
ready to advance, then our only sensible option is to deprecate
the table.

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

If there is no editing facility, why bother reading it back
at all?  If the requirement is to verify that the right script
has been downloaded, there are much cheaper ways, like a
message digest.

> > > * 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.
> 
> I'm not sure what this comment means.
> 
> > > * 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.
> 
> 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.
> 
> > 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.
> 
> 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.

Perhaps because you deleted the following text from my message:

| 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.
> 
> 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.
> 
> > From an SNMP-download feature perspective, we have:
> > 
> >     current: download, readback, edit/patch
> >     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.

Making readback optional would be a big mistake, in my opinion.
It needs to be either a mandatory capability or not supported
at all.  The decision should depend on an understanding of the
requirements.  Possibilities might be:
    1) verification that the script is intact 
       - does not require readback per se, a message digest would suffice
    2) support for editing / patching / incremental update
       - does not require readback per se, but does require that indexes
         and offsets into the script content remain stable

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

RFC 2592's use of URLs doesn't limit implementations to FTP and HTTP.
Those are just given as examples.

The smCodeTable is a consequence of this requirement from section 4:

|  o    The Script MIB must provide SNMP interfaces to all functions
|       required to delegate management scripts. However, other
|       protocols might be used in addition if they provide a
|       significant improvement in terms of convenience for
|       implementation or performance.

In getting rid of smCodeTable (if no one supports it) and
possibly replacing it with something else, we need to consider:

    - whether we need to support SNMP-based download, or are
      willing to depend on other protocols for that function
    - whether incremental updates / patches are something we
      need to support, especially in bandwidth-limited environments.
    - whether script readback is needed
    - whether other script integrity checks (e.g. MD5 or SHA) 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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Apr 2000 10:20:37 +0200

[The comments below are slightly off topic but I had to jump in here.]

>>>>> Randy Presuhn writes:

Randy> It's bad enough to make one table dependent on a value in
Randy> another (the current situation).

There are IMHO cases where you need to have table interdependencies.
Just saying it is bad makes me feel a bit uncomfortable since it
ignores reality. (I would be interested to see how you can define
the Script MIB functionality without any table interdependencies.)

Randy> This is asking for trouble with typical "conformance" test
Randy> tools that check mib implementations by checking that what
Randy> comes back in response to a get request is the same as what was
Randy> written by the most recent set request for that object.

It is not our job to define MIBs so that typical "conformance" test
tools make the right assumptions. Every object which triggers an
underlying state machinery has the property that subsequent gets may
return different values. We have several of these objects in various
MIBs. I think an argument that this should be avoided since it breaks
typical "conformance" test tools is not valid.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>