Subject: Re: RFC 2592 revision implementation experience

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Apr 2001 14:45:14 -0700 (PDT)

Hi -

A couple of technical comments...

> Date: Thu, 5 Apr 2001 16:12:25 +0200
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: disman <[email-masked]>
> Subject: RFC 2592 revision implementation experience
...
> (a) The description of smLaunchLastChange says:
...
>     Note that smLaunchRowExpireTime changes every centi-seconds and it
>     is more or less obvious that this should not influence the
>     smLaunchLastChange value. We also believe that any changes to the
>     smLaunchStart and smLaunchControl objects should not affect the
>     smLaunchLastChange object since these changes do not change the
>     template used to launch scripts.

Agreed.

> (b) The description of smLaunchRowExpireTime does not say what happens
>     if someone tries to modify this object while the associated
>     smLaunchOperStatus is already `expired'. We decided that attempts
>     to change smLaunchRowExpireTime while the smLaunchOperStatus is
>     expired should lead to an inconsistentValue error.

Seems ok.  However, the context for the word "respectively"
provides no clue as to what the circustances under which the
two alternatives are chosen.  It looks like the rest of what
"respectively" refers to is two paragraphs prior, and not
the "increase or reduce" that a strict reading of the text
would imply.

|           The value of this object may be set in order to increase
|           or reduce the remaining time that the launch table entry
|           may be used. Setting the value to 0 will cause an immediate
|           row deletion or transition into the `expired' operational
|           state, respectively.

> (c) The description of smLaunchRowExpireTime is ambiguous. The first
>     sentence says:
> 
>          The value of this object specifies how long this row remains
>          in the `enabled' operational state.    
> 
>     The last sentence says:
> 
>          Note that the timer ticks backwards independent of the
>          operational state of the launch table entry.
> 
>     The underlying question here is whether the timer continues to
>     tick backward, independ of whether the operational state is
>     `enabled' or `disabled'. We believe that this is the desired
>     behaviour.

Agreed.  Perhaps "available for use" might be a replacement for
"in the `enabled' operational state."

> Taking (a), (b) and (c) together, we get the following diff relative
> to <draft-ietf-disman-script-mib-v2-02.txt>:
...
> -	 that a change of smLaunchRunIndexNext is not considered
> -	 a change of this launch table entry."
> +	 that a change of smLaunchStart, smLaunchControl, 
> +	 smLaunchRunIndexNext, and smLaunchRowExpireTime, is not
> +	 considered a change of this launch table entry."

ok

...
> -         in the `enabled' operational state. The value reported by
> -         this object ticks backwards. When the value reaches 0 it
> -         stops ticking backward, and the row gets deleted if there are
> -         no smRunTable entries associated with this smLaunchTable
> -         entry. Otherwise, the smLaunchOperStatus changes to `expired'
> -         and the row deletion is delayed.
> +         in the `enabled' or `disabled' operational state. The value
> +	 reported by this object ticks backwards. When the value 
> +	 reaches 0, it stops ticking backward and the row is
> +	 deleted if there are no smRunTable entries associated with
> +	 this smLaunchTable entry. Otherwise, the smLaunchOperStatus
> +	 changes to `expired' and the row deletion is delayed.

It looks like some "TAB" characters might have crept in.
Otherwise, I'd suggest replacing "delayed" with "deferred
until there are no smRunTable entries associated with this
smLaunchTable entry."

...
> +	 It is not possible to set this object while the operational
> +	 status is `expired'. Attempts to modify this object while 
> +	 the operational status is `expired' leads to an 
> +	 inconsistentValue error.

ok.

...
> Comments? Is there someone uncomfortable with these changes?
...

I'm not really convinced that it is logically necessary for
expired smLaunchEntries to linger until all corresponding
smRunEntries have gone away, as the i-d currently requires.

Consider the case where a script is launched, and, before
completion, a manager would like to set smLaunchRowStatus to
"delete".  This can't succeed until smLaunchOperStatus is set
to "disabled" or "expired", but smLaunchOperStatus is stuck at
"enabled" until those pesky smRunEntries have gone away.

Sooo, the manager that REALLY wants to get rid of one of these
things will just set smLaunchRowExpireTime to zero, and then
set smRunControl to "abort" for the associated rmSunEntries.

This seems just a bit baroque, though perhaps not rococo.
However, I don't feel strongly enough about this to call
for a change if the various implementations out there
have not found this to be a problem.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Frank Strauss <[email-masked]>
Date: 06 Apr 2001 14:28:07 +0200

Hi!

Randy> I'm not really convinced that it is logically necessary for
Randy> expired smLaunchEntries to linger until all corresponding
Randy> smRunEntries have gone away, as the i-d currently requires.

Randy> Consider the case where a script is launched, and, before
Randy> completion, a manager would like to set smLaunchRowStatus to
Randy> "delete".  This can't succeed until smLaunchOperStatus is set
Randy> to "disabled" or "expired", but smLaunchOperStatus is stuck at
Randy> "enabled" until those pesky smRunEntries have gone away.

Deleting an smLaunchEntry while there are associated smRunEntries is
not possible. However, the smLaunchOperStatus *can* go to expired by
setting smLaunchRowExpireTime to zero. Then, subsequent attempts to
set smLaunchAdminStatus to other values than disabled or
smLaunchRowExpireTime to other values than zero would cause an
inconsistentValue error.

Randy> Sooo, the manager that REALLY wants to get rid of one of these
Randy> things will just set smLaunchRowExpireTime to zero, and then
Randy> set smRunControl to "abort" for the associated rmSunEntries.

Randy> This seems just a bit baroque, though perhaps not rococo.
Randy> However, I don't feel strongly enough about this to call
Randy> for a change if the various implementations out there
Randy> have not found this to be a problem.

If the manager wants to remove unconditionally a smLaunchEntry and
all associated smRunEntries - running or not - it can simply
set smLaunchRowExpireTime to zero and *smLaunchControl* to abort, even
in a single Set request.

 -frank

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2001 18:02:39 +0200

>>>>> Randy Presuhn writes:

There are at least two reasons why we require that the launch entries
stay around as long as there is a run entry started from this launch
entry:

(1) The launch entry is the only way to lookup which script a run
    entry is actually executing.

(2) If the launch entry were allowed to go away, then it would be
    possible to replace it with a new launch entry with the same
    owner and name. This would really obscure what is actually
    being executed.

Hey, its SNMP. :-)

/js