Subject: Re: [Fwd: I-D ACTION:draft-bierman-disman-see-00.txt]

From: Marcus Brunner <[email-masked]>
Date: Tue, 13 Mar 2001 11:55:16 +0100

--On Tuesday, February 20, 2001 8:49 AM -0800 Andy Bierman 
<[email-masked]> wrote:

> Marcus Brunner wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Andy,
>>
>> You did a great job defining an scripting environment. I have a few
>> comments:
>> - - why have you dismissed the lunch and run table of the Script MIB and
>> introduced your own constructs? However, I have to admit that it makes it
>> easier, but is it worth dismissing the Script MIB constructs?
>
> The smLaunchTable is designed for manual (i.e. NMS) script invocation
> and the smRunTable is designed to record the result of each manual
> invocation. The seeTaskControlTable and seeLogTable replace these tables
> in order to support the new script invocation modes and provide more
> debugging control.
>

Would it be possible to get the same functionality for your various script 
invocation methods with an extension of the smLaunchTable and smRunTable?

>>
>> - - I fully agree on the need for script statistics -> this could have
>> been added to the Script MIB as well.
>>
>> - - Why have you invented a new language? I would expect, that you are
>> able to achieve the same result, by defining some requierments to
>> existing languages and run-time environments of the language.
>
> This is the #1 open issue and the rathole with the strongest gravity.
>
> At first I didn't include the language, then I made it an appendix,
> and then finally moved it to the definitions section.
> It is included as a starting point -- an attempt to specify
> the minimum set of constructs needed to support a workable
> programming environment.  (The only feature not part of the ANSI C
> grammar  is the <OID-expression> construct.)
>
> I might support tossing the language and specifying java extensions
> instead. Computing resources are very expensive on embedded devices, so
> it's extremely unlikely that anything like a java VM would be deployed on
> them.                  Choosing java would probably limit deployment to
> mid-level managers only, which may not be a bad thing.
>

I agree with you for very small embedded devices. But people already 
control their coffee machine runing http server of it.

Would you download the ANSI C like source code? In this case you need to 
run a compiler on the device, which is also not a very cheap task.

Marcus

>>
>> Marcus
>
> Andy
>
>>
>> - --On Friday, February 16, 2001 10:06 PM -0800 Andy Bierman
>> <[email-masked]> wrote:
>>
>> > Hi,
>> >
>> > I think there is a need for a set of standardized execution environment
>> > features, including a programming grammar, for use with the Script MIB
>> > and Scheduling MIB. This draft is a proposal to the DISMAN WG as a
>> > starting point for this work.
>> >
>> > thanks,
>> > Andy
>>
>> - --------------------------------------
>> Dr. Marcus Brunner
>> C&C Research Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: [email-masked]
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.tik.ee.ethz.ch/~brunner
>>
>> Adenauerplatz 6
>> D-69115 Heidelberg
>> Germany
>>
>> Phone: +49 (0)6221/ 9051129
>> Fax:   +49 (0)6221/ 9051155
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: Mulberry PGP Plugin v2.0
>> Comment: processed by Mulberry PGP Plugin
>>
>> iQA/AwUBOpElSFhvF0PcuRgqEQI1wwCfX22Y7jJLw5ZKwZ6H4XhvC4B8e4MAnjNz
>> a4iTavyRT7FvlYbX4AnU5FeM
>> =X0Zp
>> -----END PGP SIGNATURE-----
>

--------------------------------------
Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Mar 2001 10:32:11 -0800

> invocation methods with an extension of the smLaunchTable and smRunTable?

I tried that, but there is much more to a programmatic execution environment
than script invocation, and the existing tables don't support much more than that.
Most of the definitions in the SEE I-D are outside the SEE-MIB module, because most
of the problem with the Script MIB (lack of a language or any runtime features)
cannot be addressed with more MIB objects. 

> control their coffee machine runing http server of it.

I still use a 'standalone' coffee maker with no plans to upgrade ;-)

The choice of programming language is often coupled to the choice
of execution environment. There is a big difference (in cost and complexity)
between a java virtual machine and a lightweight shell, especially
on routers and switches.  I do not accept the premise that "even coffee
machines have WEB servers, so a router should be able to provide a java VM
for net-mgmt". The trade-offs between light-weight and heavy-weight 
solutions are very real, and need to be considered carefully by the WG.

> run a compiler on the device, which is also not a very cheap task.

First of all, I put the language definition in the I-D as a starting point
for discussion.  I would actually prefer the IETF to adopt, rather than create,
a standard programming language, but not if we have to argue over
which language to use for longer than it takes to write one from scratch.

I think an interpreted mode (like csh) should be mandatory, and pre-compiled
binaries should be optional. It would be difficult to provide the same 
debugging capabilities for binaries as for interpreted source code.
(I would probably choose slow robust code over fast buggy code every time :-)

Andy