RFC 2593

Script MIB Extensibility Protocol Version 1.0

📅 published May 1999, from ietf

Script MIB Extensibility Protocol Version 1.0 🎀

okay bestie, this is RFC 2593 and it's giving Experimental 🧪✨. It's from the Network Working Group and was written by J. Schoenwaelder (TU Braunschweig) and J. Quittek (NEC Europe Ltd.) in May 1999. It's labelled Category: Experimental, and the header doesn't list anything it obsoletes or updates 💅.

Status of This Memo 📋

okay so this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind. The authors are literally asking for discussion and suggestions for improvement 🫶, and distribution of this memo is unlimited 🌈.

Copyright Notice ©️

Abstract ✨

so the IETF Script MIB gives you an interface for delegating management functions, based on the Internet management framework 🧚. A management script is a set of instructions that gets run by a language specific runtime system 🔥. The Script MIB extensibility protocol (SMX) in this memo is the thing that separates those language specific runtime systems from the language independent Script MIB implementations. It's giving clean separation 👑.

Table of Contents 🍓

1. Introduction ................................................    2
2. Process Model and Communication Model .......................    3
3. Security Profiles ...........................................    3
4. Start of Runtime Systems and Connection Establishment .......    4
5. SMX Messages ................................................    5
5.1 Common Definitions .........................................    5
5.2 Commands ...................................................    7
5.3 Replies ....................................................    8
6. Elements of Procedure .......................................    9
6.1 SMX Message Processing on the Runtime Systems ..............    9
6.1.1 Processing the `hello' Command ...........................   10
6.1.2 Processing the `start' Command ...........................   10
6.1.3 Processing the `suspend' Command .........................   11
6.1.4 Processing the `resume' Command ..........................   12
6.1.5 Processing the `abort' Command ...........................   12
6.1.6 Processing the `status' Command ..........................   12
6.1.7 Generation of Asynchronous Notifications .................   13
6.2 SMX Message Processing on the SNMP Agent ...................   13
6.2.1 Creating a Runtime System ................................   13
6.2.2 Generating the `hello' Command ...........................   13
6.2.3 Generating the `start' Command ...........................   14
6.2.4 Generating the `suspend' Command .........................   15
6.2.5 Generating the `resume' Command ..........................   16
6.2.6 Generating the `abort' Command ...........................   16
6.2.7 Generating the `status' Command ..........................   17
6.2.8 Processing Asynchronous Notifications ....................   18
7. An Example SMX Message Flow .................................   19
8. Security Considerations .....................................   19
9. Acknowledgments .............................................   20
10. References .................................................   20
11. Authors' Addresses .........................................   21
12. Full Copyright Statement ...................................   22

1. Introduction 🌸

okay so the Script MIB 🎀 [1] gives you a standard interface for delegating management functions, based on the Internet management framework. It's lowkey a lot, but the highlights are:

Transferring management scripts to a distributed manager 📦.
Starting, suspending, resuming and terminating management scripts 🔄.
Transferring arguments for management scripts 🎁.
Monitoring and controlling running management scripts 👀.
Transferring results produced by management scripts 🏆.

A management script is a set of instructions run by a language specific runtime system 🔥. The Script MIB doesn't pick a specific language. Instead it lets you control scripts written in different languages that are running at the same time, which is so iconic 💅.

The Script MIB Extensibility protocol (SMX) in this memo can be used to separate language specific runtime systems from the runtime system independent Script MIB implementations 🦋. SMX is lightweight, and it lets you support different runtime systems without changing the language neutral part of a Script MIB implementation. no cap, that's the whole glow-up ✨.

Some examples considered while designing SMX are the Java virtual machine [2] and the Tool Command Language (Tcl) [3]. Other languages with comparable features should be easy to integrate as well 🧚.

2. Process Model and Communication Model 🦋

Figure 1 shows the process and communication model that SMX sits on 💖. The language and runtime system independent SNMP agent, which implements the Script MIB, talks to one or more runtime systems over the SMX protocol. A runtime system may be able to run one or multiple scripts at once (multi-threading) 🧵. SMX supports multi-threading, but it doesn't require multi-threaded runtime systems, so no pressure 🫶.

SMX uses a local storage device (usually built on top of the local file system) to move scripts from the SNMP agent over to the runtime systems 📂. The SNMP agent has read and write access to the script storage device, while the runtime systems only need read access 👑. SMX passes the location of a script in the local storage device to the runtime engines, and then it's the runtime engines' job to load the script from that location 💅.

                                                    runtime 1
                   +--------------+       SMX      +---------+
                   |              |<-------------->| O  O  O |<-+
           SNMP    |  Script MIB  |                +---------+  |
       <---------->|              |                             |
                   |  SNMP Agent  |                 runtime 2   |
                   |              |       SMX      +---------+  |
                   |              |<-------------->| O       |  |
                   +--------------+                +---------+  |
                           ^                            ^       |
                           |       +---------+          |       |
                           |       | script  |----------+       |
                           +------>| storage |------------------+
                                   +---------+

           Figure 1: SMX process and communication model

3. Security Profiles 🔐

okay the security profiles are what control what a running script is allowed to do 🛡️. It's useful to split them into two classes:

The operating system security profile says which operating system services the OS level process running a script is allowed to use 💻. Under UNIX, this maps to the effective user and group identity for the running process. Lots of UNIX versions also let you set other resource limits, like the number of open files or the maximum stack sizes 📏. Another UNIX mechanism is the chroot() system call, which changes the file system root for a process 🌳. chroot() can be used to stop runtime systems from accessing any system files. It's suggested to use every applicable operating system security mechanism to protect the OS from malicious scripts or runtime systems 🚨.
Secure runtime systems give you fine grained control over which services a running script can use at a particular point during script execution 🎯. A runtime security profile that does fine grained access control depends on the runtime system. For a Java virtual machine, the runtime security profile is interpreted by the SecurityManager and ClassLoader classes[4]. For Tcl, the runtime security profile maps to the interpreter's security profile [5] 🧠.

SMX lets you run scripts under different operating system profiles and runtime system profiles 🌈. Multiple operating system security profiles are realised by using multiple runtime systems, each running in an operating system process with its own security profile. Multiple runtime security profiles are supported by passing a security profile name to a runtime system when a script is invoked 🎀.

The Script MIB doesn't define how operating system or runtime system security profiles get identified. This memo suggests that the smLaunchOwner gets mapped to an operating system security profile and a runtime system security profile when a script is started 💜.

4. Start of Runtime Systems and Connection Establishment 🚀

The SNMP agent starts runtime systems based on the static properties of the runtime system (multi-threaded or single-threaded) and the operating system security profiles 🧚. Starting a new runtime system means creating a process environment that matches the operating system security profile 🛠️.

The SNMP agent first passes information to the runtime system through environment variables 🌷. That information is needed to set up a trusted communication channel between the SNMP agent and a runtime system 🤝.

The SNMP agent first creates a listening TCP socket that accepts connections from runtime systems 🔌. It's the runtime system's responsibility to connect to this TCP socket once it's been started. The port number of the listening TCP socket is passed from the SNMP agent to the runtime system in the environment variable SMX_PORT 🎟️.

the SNMP agent must make sure that only authorized runtime systems connect to the listening TCP socket 🚫. These are the rules it uses:

The TCP connection must come from the local host 🏠.
The SNMP agent asks the runtime system for a security cookie, and it closes the TCP connection if no valid response shows up within a given time interval ⏰. The security cookie is a random number that the SNMP agent generates and passes to the runtime system as part of its environment. It's found in the environment variable SMX_COOKIE 🍪.

The security assumption here is that access to the process environment is protected by the operating system 🔒.

Alternate transports (e.g. UNIX domain sockets) are possible but aren't defined yet 🤷‍♀️. TCP was picked as the transport for SMX because it's supported by all the potential runtime systems, while other transports aren't universally available 💖.

5. SMX Messages 💌

The message formats below are defined using the Augmented BNF (ABNF) from RFC 2234 [6] 📝. The definitions for ALPHA, DIGIT, HEXDIG, WSP, CRLF, CR, LF, HTAB, VCHAR and DQUOTE are imported from appendix A of RFC 2234 and aren't repeated here 🫶.

that's the first part of the glow-up, bestie 🌈✨

5.1. Common Definitions ✨

okay bestie, so before we get into the actual SMX messages, we need to agree on the building blocks 🧱💅 these ABNF definitions are what every later section leans on, so let's go through them 🎀

Zero          = %x30          ; the ASCII character '0'

AlNum         = DIGIT / ALPHA / %x2D-2F
                              ; digits, alphas plus '-', '.', '/'

QuotedString  = DQUOTE *(VCHAR / WSP) DQUOTE

HexString     = 1*(HEXDIG HEXDIG)
Id            = 1*DIGIT       ; identifier for an SMX transaction

Script        = QuotedString  ; script file name

RunId         = 1*DIGIT       ; globally unique identifier for a
                              ; running script (note, smRunIndex
                              ; is only unique for a smLaunchOwner,
                              ; smLaunchName pair)

Profile       = 1*AlNum       ; security profile name

RunState      =  "1"          ; smRunState `initializing'
RunState      =/ "2"          ; smRunState `executing'
RunState      =/ "3"          ; smRunState `suspending'
RunState      =/ "4"          ; smRunState `suspended'
RunState      =/ "5"          ; smRunState `resuming'
RunState      =/ "6"          ; smRunState `aborting'
RunState      =/ "7"          ; smRunState `terminated'

ExitCode      =  "1"          ; smRunExitCode `noError'
ExitCode      =/ "2"          ; smRunExitCode `halted'
ExitCode      =/ "3"          ; smRunExitCode `lifeTimeExceeded'
ExitCode      =/ "4"          ; smRunExitCode `noResourcesLeft'
ExitCode      =/ "5"          ; smRunExitCode `languageError'
ExitCode      =/ "6"          ; smRunExitCode `runtimeError'
ExitCode      =/ "7"          ; smRunExitCode `invalidArgument'
ExitCode      =/ "8"          ; smRunExitCode `securityViolation'
ExitCode      =/ "9"          ; smRunExitCode `genericError'

Cookie        = HexString     ; authentication cookie

Version       = "SMX/1.0"     ; current version of the SMX protocol

Argument      = HexString / QuotedString      ; see smRunArgument

Result        = HexString / QuotedString      ; see smRunResult

ErrorMsg      = HexString / QuotedString      ; see smRunError

so the QuotedString one needs a little extra explaining 🫶 inside a quoted string you can have special sequences, and they all start with a backslash (%x5C) 🌸 here's what they mean:

`\\'   backslash character       (`%x5C')
`\t'   tab character             (`HTAB')
`\n'   newline character         (`LF')
`\r'   carriage-return character (`CR')
`\"'   quote character           (`DQUOTE')

and for any other case that isn't listed, the backslash just gets dropped and the character after it is treated as a normal character 🦋 Argument and Result are each either a QuotedString or a HexString 💖 the Script MIB says script arguments and results are arbitrary octet strings, and SMX supports both a binary form and a human readable one, because printable strings are probably going to be used a lot ✨ but an implementation MUST be able to handle both formats to be compliant with the Script MIB 👑

the Cookie is a HexString with no meaning beyond being a random sequence of bytes, so it doesn't need a human readable form 🙈 it's giving pure mystery 🔥

5.2. Commands 🎀

this section is the list of SMX commands the SNMP agent can send to a runtime system 💅

Command =  "hello"   WSP Id CRLF

Command =/ "start"   WSP Id WSP RunId WSP Script WSP Profile
                     WSP Argument CRLF

Command =/ "suspend" WSP Id WSP RunId CRLF

Command =/ "resume"  WSP Id WSP RunId CRLF

Command =/ "abort"   WSP Id WSP RunId CRLF

Command =/ "status"  WSP Id WSP RunId CRLF

hello is always the first command sent over an SMX connection 👑 it's how the runtime system gets identified and authenticated 🫶 start kicks off a script's execution 🚀 suspend, resume and abort can change the status of a running script ✨ and status is for pulling status info on a running script 💀

there's no compile command, so the SNMP agent has to do any compilation it needs before using start 🧚 there's also no SMX command to shut down a runtime system 😭 instead, closing the connection has to be read as a request to terminate every running script in that runtime system AND shut the runtime system down 💜

5.3. Replies 🌈

every reply message starts with a three digit reply code and ends with CRLF 🍓 the three digits have special meaning: the first one tells you the class of the reply 🦋

1yz   transient positive response
2yz   permanent positive response
3yz   transient negative response
4yz   permanent negative response
5yz   asynchronous notification

the 1yz and 3yz classes aren't used by SMX version 1.0 yet 🙈 they're only defined for future SMX extensions 🔮

the second digit is the specific category 🎀

x0z   syntax errors that don't fit any other category
x1z   replies for commands targeted at the whole runtime system
x2z   replies for commands targeted at scripts
x3z   replies for commands targeted at running instances of scripts

and the third digit gives a finer grade of meaning inside each category 💅 here's the ABNF for every reply and code:

Reply =  "211" WSP Id WSP Version WSP Cookie CRLF
                              ; identification of the
                              ; runtime system

Reply =/ "231" WSP Id WSP RunState CRLF
                              ; status of a running script

Reply =/ "232" WSP Id CRLF    ; abort of a running script

Reply =/ "401" WSP Id CRLF    ; syntax error in command

Reply =/ "402" WSP Id CRLF    ; unknown command

Reply =/ "421" WSP Id CRLF    ; unknown or illegal Script

Reply =/ "431" WSP Id CRLF    ; unknown or illegal RunId
Reply =/ "432" WSP Id CRLF    ; unknown or illegal Profile

Reply =/ "433" WSP Id CRLF    ; illegal Argument

Reply =/ "434" WSP Id CRLF    ; unable to change the status of
                              ; a running script

Reply =/ "511" WSP Zero WSP QuotedString CRLF
                              ; an arbitrary message send from
                              ; the runtime system

Reply =/ "531" WSP Zero WSP RunId WSP RunState CRLF
                              ; asynchronous running script
                              ; status change

Reply =/ "532" WSP Zero WSP RunId WSP RunState WSP Result CRLF
                              ; intermediate script result

Reply =/ "533" WSP Zero WSP RunId WSP RunState WSP Result CRLF
                              ; intermediate script result that
                              ; trigger an event report

Reply =/ "534" WSP Zero WSP RunId WSP Result CRLF
                              ; normal script termination

Reply =/ "535" WSP Zero WSP RunId WSP ExitCode WSP ErrorMsg CRLF
                              ; abnormal script termination.

6. Elements of Procedure 🧠

this section goes through, step by step, what the SNMP agent and the runtime system each do with the SMX protocol 🫶

6.1. SMX Message Processing on the Runtime Systems 💜

this part covers how a runtime engine handles SMX command messages, and the conditions under which it generates asynchronous notifications 🔥

when the runtime system gets a message, it first tries to recognize a command made of the command string and the transaction identifier 🎀 if it can't pull out BOTH of those, the message gets discarded 💀 an asynchronous 511 reply MAY be generated in that case 🌸 otherwise, the command string gets checked to be valid, meaning it has to be one of hello, start, suspend, resume, abort, or status ✨ if it's invalid, a 402 reply is sent and processing of the message stops 🙅 if the command IS valid, the rest of the processing depends on that command, as described below 💅

the command-specific processing describes several possible syntax errors that get their own reply messages 🦋 if the runtime engine finds a syntax error that isn't explicitly mentioned, or one that can't be identified uniquely, a generic 401 reply gets sent to say the command can't be executed 😭

6.1.1. Processing the `hello` Command 🧚

when the runtime system receives a hello command, here's what it does 🌈

the runtime system grabs the security cookie from its process environment 🔐
the runtime system sends a 211 reply containing the security cookie 💖

6.1.2. Processing the `start` Command 🚀

when the runtime system receives a start command, here's the play-by-play 🎬

the syntax of the start command's arguments gets checked, and the following four checks MUST be made:
- (a) the syntax of the RunId parameter is checked, and a 431 reply is sent if any syntax error shows up 🙈
- (b) the syntax of the Script parameter is checked, and a 421 reply is sent if any syntax error shows up 🙈
- (c) the syntax of the Profile parameter is checked, and a 432 reply is sent if any syntax error shows up 🙈
- (d) if the syntax of the Argument parameter is checked and a 433 reply is sent if any syntax error shows up 🙈
the runtime system checks whether the new RunId is already in use 🔍 if yes, a 431 reply is sent and processing stops 🛑
the runtime system checks whether the Script parameter is the name of a file on the local storage device that can be read 📂 a 421 reply is sent and processing stops if the file doesn't exist or isn't readable 🚫
the runtime system checks whether the security profile is known, and sends a 432 reply and stops processing if it isn't 🔐
the runtime engine starts the script named by the script name ✨ once the script has started, a 231 reply is sent with the current run state 🦋

processing of the start command stops when the script reaches the state running 🏁 for every asynchronous state change of the running script, a 531 reply is sent 🔔 processing of the start command also stops if an error happens before the state running is reached 😭 in that case the run is aborted and a 535 reply is generated 💀

if an abort command or a suspend command for the running script is received before processing of the start command is complete, processing of the start command MAY be stopped before the state running is reached 🌸 in that case, the resulting status of the running script is given by the respective reply to the abort or suspend command, and NO reply with the transaction identifier of the start command gets generated 🫶

6.1.3. Processing the `suspend' Command

okay so when the runtime system gets a `suspend' command, here's the exact order it goes through 💅✨

if there's a syntax error in the running script identifier, or there's no running script matching the identifier, send a 431 reply and stop processing the command 🙅‍♀️
if the running script is already in the state suspended, send a 231 reply and stop processing the command 🌸
if the running script is in the state running, suspend it and send a 231 reply after suspending. if suspending fails, send a 434 reply and stop processing the command 🦋
if the running script hasn't reached the state running yet (the start' command is still being processed), it may reach the state suspendedwithout ever having been in the staterunning. after it reaches suspended, send a 231` reply 🧚
if the running script is in any other state, send a 434 reply 💀

6.1.4. Processing the `resume' Command

bestie, the resume' command is basically the mirror image of suspend' 🪞💖 here's the flow:

if there's a syntax error in the running script identifier, or there's no running script matching the identifier, send a 431 reply and stop processing the command 🙈
if the running script is already in the state running, send a 231 reply and stop processing the command ✨
if the running script is in the state suspended, resume it and send a 231 reply after resuming. if resuming fails, send a 434 reply and stop processing the command 🔥
if the start' command is still being processed for the script, send a 231reply once the staterunning` has been reached 👑
if the running script is in any other state, send a 434 reply 😭

6.1.5. Processing the `abort' Command

when the runtime system receives an `abort' command, it's giving "shut it down" energy 🛑💅

if there's a syntax error in the running script identifier, or there's no running script matching the identifier, send a 431 reply and stop processing the command 🙅‍♀️
if the running script is already aborted, send a 232 reply and stop processing the command 🌷
the running script is aborted, and a 232 reply is sent after aborting. if aborting fails, send a 434 reply and stop processing 💔

6.1.6. Processing the `status' Command

the `status' command is the chill one 🧋 when it shows up:

if there's a syntax error in the running script identifier, or there's no running script matching the identifier, send a 431 reply and stop processing the command 🫠
the status of the script is obtained, and a 231 reply is sent 📋✨

6.1.7. Generation of Asynchronous Notifications

okay this part is where the runtime system gets to be chatty 📣🌈 without being asked, it generates (or may generate) these notifications:

if the runtime system notices a change in the status of a running script, a 531 reply is sent 👀
a 534 reply is sent if a running script terminates normally 🎉
a 535 reply is sent if a running script terminates abnormally 💔
if a script produces an intermediate result, a 532 reply is sent 🍓
if a script asks for a smScriptResult' notification to be generated, a 533` reply is sent 🎀
besides the notifications above, the runtime system may generate arbitrary 511 replies, which are logged or displayed by the SNMP agent 🦋🫶

6.2. SMX Message Processing on the SNMP Agent

this section is the SNMP agent's side of the story 🧚💜 it covers when an SNMP agent that implements the Script MIB generates SMX commands, and how it handles the replies that come back.

6.2.1. Creating a Runtime System

new runtime systems get started by the SNMP agent while it's processing set requests for a smLaunchStart' variable 🚀 first, it searches for an already running runtime systems which matches the security profiles associated with the smLaunchStart' variable. if there's no suitable runtime system available, a new one is started. that means preparing the environment, then starting the executable in a new process that conforms to the operating system security profile 🔐 after that, the SNMP agent gets ready to accept a connection from the new runtime system. and the smRunState' of every script that should run in this new runtime system gets set to initializing' 🌸

6.2.2. Generating the `hello' Command

the hello' command is generated once a connection request from a runtime system has been accepted 🤝 the SNMP agent sends the hello' command, as defined in section 5.2, and then waits for a reply from the runtime system within a reasonable timeout interval ⏳

if the timeout expires before the SNMP agent receives a reply, the connection is closed and all data associated with it is deleted. any scripts that should be running in this runtime system are aborted, the smRunExitCode' is set to genericError', and `smRunError' is modified to describe the error situation 😱
if the received message can not be analyzed because it does not have the required format, the connection is closed and all data associated with it is deleted. any scripts that should be running in this runtime system are aborted, the smRunExitCode' is set to genericError', and `smRunError' is modified to describe the error situation 🙅‍♀️
if the received message is a 211 reply, the Id' is checked to see whether it matches the Id' used in the hello' command. if the Id' matches, the Version' is checked. if the Version' matches a supported SMX protocol version, the Cookie' is checked to see whether it matches the cookie passed to the runtime system. if any of these tests fails, the connection is closed and all data associated with this runtime system is deleted. any scripts that should be running in this runtime system are aborted, the smRunExitCode' is set to genericError', and smRunError' is modified to describe the error situation 🚨
received messages are discarded if none of the previous rules applies 🗑️

6.2.3. Generating the `start' Command

the start' command is generated while the SNMP agent processes set-requests for a smLaunchStart' variable ✨ it assumes the SNMP agent has already figured out which runtime system is suitable for running the script associated with that variable. the SNMP agent sends the `start' command, as defined in section 5.2, to the selected runtime system and then waits for a reply within a reasonable timeout interval 🦋

if the timeout expires before the SNMP agent receives a reply, the SNMP agent sends an abort' command to abort the running script, sets the smRunState' of the running script to terminated', sets the smRunExitCode' to genericError', and smRunError' is modified to describe the timeout situation ⏰
if the received message can not be analyzed because it does not have the required format, the message is ignored. the SNMP agent keeps waiting for a valid reply message until the timeout expires 👂
if the received message is a 4yz' reply and the Id' matches the Id' of the start' command, the SNMP agent assumes that the script can not be started. the smRunState' of the running script is set to terminated', the smRunExitCode' is set to genericError', and the `smRunError' is modified to contain a message describing the error situation 💀
if the received message is a 231' reply and the Id' matches the Id' of the start' command, the `smRunState' variable of the running script is updated 🌈
received messages are discarded if none of the previous rules applies 🗑️

6.2.4. Generating the `suspend' Command

the suspend' command is generated while the SNMP agent processes set-requests for the smLaunchControl' and smRunControl' variables that change the value to suspend' 🛑 the SNMP agent sets the smRunState' variable to suspending', sends the `suspend' command as defined in section 5.2, and then waits for a reply from the runtime system within a reasonable timeout interval 🕰️

if the timeout expires before the SNMP agent receives a reply, the SNMP agent sends an abort' command to abort the running script, sets the smRunState' of the running script to terminated', sets the smRunExitCode' to genericError', and smRunError' is modified to describe the timeout situation 😵
if the received message can not be analyzed because it does not have the required format, the message is ignored. the SNMP agent keeps waiting for a valid reply message until the timeout expires 🙉
if the received message is a 401', 402' or a 431' reply and the Id' matches the Id' of the suspend' command, the runtime systems is assumed to not provide the suspend/resume capability, and processing of the `suspend' command stops 🙅‍♀️
if the received message is a 231' reply and the Id' matches the Id' of the suspend' command, the `smRunState' variable of the running script is updated 🌸
received messages are discarded if none of the previous rules applies 🗑️

6.2.5. Generating the `resume' Command

the resume' command is generated while the SNMP agent processes set-requests for the smLaunchControl' and smRunControl' variables that change the value to resume' 🔁 the SNMP agent sets the smRunState' variable to resuming', sends the `resume' command as defined in section 5.2, and then waits for a reply from the runtime system within a reasonable timeout interval 💜

if the timeout expires before the SNMP agent receives a reply, the SNMP agent sends an abort' command to abort the running script, sets the smRunState' of the running script to terminated', sets the smRunExitCode' to genericError', and smRunError' is modified to describe the timeout situation 😭
if the received message can not be analyzed because it does not have the required format, the message is ignored. the SNMP agent keeps waiting for a valid reply message until the timeout expires 🫶
if the received message is a 401', 402' or a 431' reply and the Id' matches the Id' of the resume' command, the runtime systems is assumed to not provide the suspend/resume capability, and processing of the `resume' command stops 🙈
if the received message is a 231' reply and the Id' matches the Id' of the resume' command, the `smRunState' variable of the running script is updated 👑
received messages are discarded if none of the previous rules applies 🗑️

6.2.6. Generating the `abort' Command 🛑

okay so the abort' command gets generated when you're processing set-requests for smLaunchControl' and smRunControl' that change the value to abort'. 🙅‍♀️ It also pops up if smRunLifeTime' hits 0, which is basically the script running out of time ⏰. The SNMP agent sends the abort' command as defined in section 5.2, and then it waits for a reply from the runtime system within a reasonable timeout interval. 🫶

ok so if the timeout expires before the SNMP agent gets a reply, the agent sets the smRunState' of the running script to terminated', sets smRunExitCode' to genericError', and modifies `smRunError' to describe the timeout situation 💀.
if the received message can't be analyzed because it doesn't have the required format, the message gets ignored 🙈. The SNMP agent keeps waiting for a valid reply until the timeout expires.
if the received message is a 4yz' reply and the Id' matches the Id' of the abort' command, the SNMP agent assumes the script can not be aborted 😩. The smRunState' of the running script is set to terminated', the smRunExitCode' is set to genericError', and `smRunResult' gets modified to describe the error situation.
if the received message is a 232' reply and the Id' matches the Id' of the abort' command, the smRunExitCode' of the terminated script changes to either halted' (when processing a set-request for the smLaunchControl' and smRunControl' variables) or lifeTimeExceeded' (if the abort' command was generated because smRunLifeTime' reached the value 0) ✨. The smRunState' variable is changed to `terminated'. ya win 🏆
received messages are discarded if none of the previous rules applies 🗑️.

6.2.7. Generating the `status' Command 👀

the status' command is generated either periodically or on demand by the SNMP agent, and its whole job is to pull status info from running scripts 🧐. The SNMP agent sends the status' command as defined in 5.2 and then waits for a reply from the runtime system within a reasonable timeout interval.

if the timeout expires before the SNMP agent gets a reply, the agent sends an abort' command to abort the running script 🛑. It also sets the smRunState' of the running script to terminated', the smRunExitCode' to genericError', and modifies smRunError' to describe the timeout situation.
if the received message can't be analyzed because it doesn't have the required format, the message gets ignored 🙈. The SNMP agent keeps waiting for a valid reply until the timeout expires.
if the received message is a 4yz' reply and the Id' matches the Id' of the status' command, the SNMP agent assumes the script status can not be read 😱. That's a fatal error condition, so the agent sends an abort' command to abort the running script. The smRunState' of the running script is set to terminated', the smRunExitCode' is set to genericError', and smRunError' is modified to describe the error situation.
if the received message is a 231' reply and the Id' matches the Id' of the status' command, then the `smRunState' variable of the running script gets updated 🔄.
received messages are discarded if none of the previous rules applies 🗑️.

6.2.8. Processing Asynchronous Notifications 🔔

the runtime system can send asynchronous status change notifications, which are the `5yz' replies, and these get processed like this 💅:

if the received message is a `511' reply, the message is displayed or logged appropriately and processing stops 📝.
if the received message is a 531' reply, the SNMP agent checks whether a running script with the given RunId' exists in the runtime system. If there's no running script with that RunId', processing of the notification stops. Otherwise, the smRunState' gets updated.
if the received message is a 532' reply, the SNMP agent checks whether a running script with the given RunId' exists in the runtime system. No script with that RunId' means processing of the notification stops. Otherwise, smRunState' and `smRunResult' get updated.
if the received message is a 533' reply, the SNMP agent checks whether a running script with the given RunId' exists in the runtime system. If not, processing of the notification stops 🛑. Otherwise, smRunState' and smRunResult' get updated and the `smScriptResult' notification is generated 🎉.
if the received message is a 534' reply, the SNMP agent checks whether a running script with the given RunId' exists in the runtime system. If there isn't one, processing stops. Otherwise, smExitCode' is set to noError', smRunState' is set to terminated', and `smRunResult' gets updated 🥳.
if the received message is a 535' reply, the SNMP agent checks whether a running script with the given RunId' exists in the runtime system. No match means processing stops. Otherwise, smRunState' is set to terminated' and smExitCode' and smRunError' get updated 💔.

7. An Example SMX Message Flow 🎬

okay this is the part where we watch the whole thing happen 🍿. The messages sent from the SNMP agent are marked with >', and the replies from the runtime system are marked with <'. The line terminators (`CRLF') are not shown so the example is easier to read 🫶.

  > hello 1
  < 211 1 SMX/1.0 0AF0BAED6F877FBC
  > start 2 42 "/var/snmp/scripts/foo.jar" untrusted ""
  > start 5 44 "/var/snmp/scripts/bar.jar" trusted "www.ietf.org"
  < 231 2 2
  > start 12 48 "/var/snmp/scripts/foo.jar" funny ""
  < 231 5 2
  < 532 0 44 2 "waiting for response"
  > status 18 42
  > status 19 44
  < 432 12
  < 231 19 2
  < 231 18 2
  > hello 578
  < 211 578 SMX/1.0 0AF0BAED6F877FBC
  > suspend 581 42
  < 231 581 4
  < 534 0 44 "test completed"
  > abort 611 42
  < 232 611

8. Security Considerations 🔐

this part is serious, bestie, so pay attention 🧐. The SMX protocol runs on top of a local TCP connection, and protocol messages never leave the local system. So it's not possible to attack the message exchanges, as long as the underlying operating system protects local TCP connections from other users on the same machine 🛡️.

The only critical situation is the connection establishment phase 😬. The rules defined in section 4 make sure that only local connections are accepted, and that a runtime system has to identify itself with a security cookie. That cookie is generated by the SNMP agent and passed to the runtime system process as part of its environment. This rule makes sure scripts only run on authorized runtime systems ✅. The scheme relies on the operating system protecting process environments, and well maintained UNIX operating systems have this property 🐧.

The SMX protocol lets you execute scripts under different operating system and runtime system security profiles 🎭. The memo suggests mapping the smLaunchOwner value to an operating system and a runtime system security profile. The operating system security profile is enforced by the operating system, which sets up a proper process environment. The runtime security profile is enforced by a secure runtime system, like the Java virtual machine or a safe Tcl interpreter [7] 💜.

9. Acknowledgments 🫶

the protocol in this memo is the result of a joint project between the Technical University of Braunschweig and C&C Research Laboratories of NEC Europe Ltd. in Berlin 🌈. These project members get a big thank you for their contributions to the initial design and implementation:

          M. Bolz         (TU Braunschweig)
          C. Kappler      (NEC Europe Ltd.)
          A. Kind         (NEC Europe Ltd.)
          S. Mertens      (TU Braunschweig)
          J. Nicklisch    (NEC Europe Ltd.)

10. References 📚

[1] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 2592, May 1999.
[2] Lindholm, T., and F. Yellin, "The Java Virtual Machine Specification", Addison Wesley, 1997.
[3] J.K. Ousterhout, "Tcl and the Tk Toolkit", Addison Wesley, 1994.
[4] Fritzinger, J.S., and M. Mueller, "Java Security", White Paper, Sun Microsystems, Inc., 1996.
[5] Levy, J.Y., Demailly, L., Ousterhout, J.K., and B. Welch, "The Safe-Tcl Security Model", Proc. USENIX Annual Technical Conference, June 1998.
[6] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997.
[7] Schoenwaelder, J., and J. Quittek, "Secure Management by Delegation within the Internet Management", Proc. IFIP/IEEE International Symposium on Integrated Network Management '99, May 1999.

11. Authors' Addresses 📮

Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany

Phone: +49 531 391-3283
EMail: schoenw@ibr.cs.tu-bs.de


Juergen Quittek
NEC Europe Ltd.
C&C Research Laboratories
Hardenbergplatz 2
10623 Berlin
Germany

Phone: +49 30 254230-19
EMail: quittek@ccrle.nec.de

12. Full Copyright Statement ⚖️

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 💖.

📦 where this page comes from

ietf: rfc2593 1999-05
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms