Subject: Re: Closing Script MIB issues

From: Alan Luchuk <[email-masked]>
Date: Wed, 5 Apr 2000 12:33:53 -0400 (EDT)

Hello all,

>>>>>> Randy Presuhn writes:
>
>Randy> We need to get closure on the Script MIB issues so we can do a
>Randy> WG last call before requesting advancement to Draft Standard.
>Randy> Issues from the i-d:
>
>Randy>    02: Restartable scripts
>
>I think the strawman here was to have an smLaunchFlags objects of type
>BITS which indicates whether a script is being restarted on
>reinitialization.

I support the proposal to add the smLaunchFlags objects of type
BITS which indicates whether a script is being restarted on
reinitialization.

>Randy>    03: Error message during script retrieval or compilation (
>Randy> smScriptError)
>
>I think the strawman here was to add an smScriptError object which
>contains the last error message generated.

I support the proposal to add an smScriptError object which
contains the last error message generated.

>Randy>    04: Scripts that can run forever without having to reset
>Randy> smRunLifeTime
>
>I think the strawman here was to give the max. smRunLifeTime value a
>special meaning (which stops the timer from decrementing).

I support the proposal to to give the maximum smRunLifeTime value a
special meaning that stops the timer from decrementing.

>Randy>    05: Index smLangTable and smExtsnTable by name rather than
>Randy> Integer32

I can align with this proposal.

>Randy>    06: Dependencies between scripts and script versioning
>Randy> (Eamonn)
>
>Randy>    07: Storage type of script code versus storage type of
>Randy> script meta information

If possible, could someone (privately) refresh my memory about
the meaning of these two terse descriptions or point me to a
better description.

>Randy> All issues on which there are no contributions within the next
>Randy> two weeks will be closed with a status of "no action".
>
>I have a few more issues in my list:
>
>   08: Final polling missing in procedures 7.6 and 7.7 (Frank)
>
>I think a suitable clarification should be added to these sections.
>
>   09: Add procedures for suspend/resume/purge to section 7 (Frank)
>
>I think it is helpful to define these procedures.
>
>   10: Any changes needed for editing in the SNMP code table? (Juergen)
>
>There have been a few comments on the smCodeTable and its flexibility
>regarding the numbering scheme and so on. Do we want to keep it the
>way it is defined? Many implementations so far do not support it and
>we may get problems with it anyway once we want to advance to Draft
>standard.

I support keeping the smCodeTable. 

Justification:

1.  Keeping the smCodeTable in the MIB does not mandate its implementation.

2.  Keeping the smCodeTable allows an all-SNMP solution for populating 
    scripts in the script MIB.  Omitting the smCodeTable would require 
    the script MIB agent support TCP/HTTP and/or other protocols necess-
    ary only for pulling scripts into the script MIB.  Eliminating other
    protocols (and their software code size) may be an issue in some
    embedded environments.

3.  The implementation complexity of supporting "pushing" scripts into
    the smCodeTable is less than, or certainly no greater than, the
    implementation complexity of supporting "pulling" scripts into the
    agent.  I argue that the complexity of supporting the smCodeTable
    and reading scripts from the smCodeTable is less than the complexity 
    of parsing URLs, "pulling" scripts using FTP/HTTP, and handling
    possible download error conditions.

4.  Although SNMP is inefficent as a bulk data transfer mechanism, SNMP's
    bulk data transfer efficiency is really a non-issue here because:

    a.  scripts will tend to be loaded relatively infrequently; and 
    b.  scripts will be relatively small, not like booting a whole
        workstation over the net.

5.  To be politically correct:  celebrate diversity.

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Note:  Our area code changed to 865 from 423 in November.  If you have
   trouble reaching us via area code 865, please try the old area code (423) 
   and let us know.  Both area codes should work until April.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Apr 2000 12:03:44 +0200

>>>>> Alan Luchuk writes:

[...]

Alan> I can align with this proposal.

I actually did not but a strawman here because I am not sure what the
strawman position is.

Are you saying that obsoleting smLangTable, smExtsnTable and
smLangLanguage and replacing them with new tables indexed by name
rather than Integer32 (1..2147483647) and a new column in the
smScriptTable is a good idea? Or are you just saying that you won't
object if it happens?

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