Subject: RE: Report on Script MIB action item

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 23 Mar 2001 04:06:29 +0100

So... is this an indication that maybe we need some
clarifying text in the Script MIB?

Bert

> ----------
> From: 	Andy Bierman[SMTP:[email-masked]]
> Sent: 	Thursday, March 22, 2001 3:43 PM
> To: 	[email-masked]
> Subject: 	Report on Script MIB action item
> 
> 
> Hi,
> 
> I was asked at the last session to re-examine the Script MIB
> and determine if the enhancements I proposed in the SEE I-D
> could be added to the smLaunchTable and smRunTable, rather
> than replacing these tables with the seeTaskControlTable.
> 
> After much enlightenment from the Script MIB authors, 
> I think the existing tables can be used, without
> deprecating any Script MIB objects. I had misunderstood
> the complete semantics of the smLaunchStart and smLaunchControl
> objects. There are no restrictions directly related to
> manual script invocation.  There are some technical
> issues to solve in order to utilize the smRunIndex
> as a task ID instead of the seeTaskControlIndex,
> but nothing major.  In addition, the notifications
> in the Script MIB can be used directly, so the SEE
> notifications can be removed.  
> 
> Andy
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Mar 2001 04:38:49 +0100

>>>>> Wijnen, Bert (Bert) writes:

Bert> So... is this an indication that maybe we need some clarifying
Bert> text in the Script MIB?

We did not identify any specific things that were confusing as far as
I remember our hallway discussion. Andy, is that a fair statement?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Mar 2001 08:05:48 -0800

> I remember our hallway discussion. Andy, is that a fair statement?

The recycling of smRunIndex values as generated by
the associated smLauchStart object is not described
in one place, but the 'total' text is not ambigious.

It is desirable to support unique integer task IDs across 
the agent. Yet smRunIndex is only unique within the scope of
a particular smLaunchOwner, smLaunchName pair,  which 
means the task ID is rather bulky (2 strings and an integer).
Some of the SEE tables need this global task ID, and their
INDEX clauses will be rather large and complicated.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Mar 2001 17:31:58 +0100

>>>>> Andy Bierman writes:

Andy> The recycling of smRunIndex values as generated by the
Andy> associated smLauchStart object is not described in one place,
Andy> but the 'total' text is not ambigious.

Can you be more precise what is missing where? Any concrete wording
proposals?

Andy> It is desirable to support unique integer task IDs across the
Andy> agent. Yet smRunIndex is only unique within the scope of a
Andy> particular smLaunchOwner, smLaunchName pair, which means the
Andy> task ID is rather bulky (2 strings and an integer).  Some of the
Andy> SEE tables need this global task ID, and their INDEX clauses
Andy> will be rather large and complicated.

I agree that it would be nice to require that run index values are
unique across all running scripts. I came across this myself when I
was writing a management application.

I will put text in the MIB which says that smRunIndex values must be
globally unique and spin another ID. If someone has an issue with
making smRunIndex unique, please speak up now.

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 24 Mar 2001 08:02:03 -0800

> Can you be more precise what is missing where? Any concrete wording

The most likely failure case between a correctly implemented and
configured schedEntry and smLaunchEntry (with a non-zero smLaunchStart 
value), is because the script is already running.

The text for smLaunchStart that describes this failure case is 
the first sentence of step 5, in the test procedure for
inconsistentValue.
It's kind of buried in the middle of a really long DESCRIPTION clause,
but the text is very precise, and I can't really think of something to
add
right now.

> making smRunIndex unique, please speak up now.

I think this would be great, but it is definitely a change that will
cause existing conforming implementations to be deemed broken.

What if you add a TruthValue r/o scalar that indicates whether
the agent enforces uniqueness of the smRunIndex object (for running
tasks)
for the entire agent or for a particular smLaunchOwner, smLaunchName
pair.
A conforming implementation can return false, which means the
application cannot have global integer task IDs. Implementations
for the SEE extensions will need to return true.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Mar 2001 11:33:53 +0200

>> I will put text in the MIB which says that smRunIndex values must
>> be globally unique and spin another ID. If someone has an issue
>> with making smRunIndex unique, please speak up now.

Andy> I think this would be great, but it is definitely a change that
Andy> will cause existing conforming implementations to be deemed
Andy> broken.

Andy> What if you add a TruthValue r/o scalar that indicates whether
Andy> the agent enforces uniqueness of the smRunIndex object (for
Andy> running tasks) for the entire agent or for a particular
Andy> smLaunchOwner, smLaunchName pair.  A conforming implementation
Andy> can return false, which means the application cannot have global
Andy> integer task IDs. Implementations for the SEE extensions will
Andy> need to return true.

Well, the only case where problems might show up is this. A future
script mib management applications relies on smRunIndex to be unique
and it hits an RFC 2592 agent where it is not necessarily unique
(although some implementations may already implement it as being
unique). And this is really only significant when loadings/displaying
the smRunTable - there does not seem to be a problem with actually
launching scripts or something like that. And given the fact that the
MIB has seem relatively limited installations in actual devices where
it is hard to update the code, I would expect that doing the change
now is not a big deal. I am sure that most of the people who
downloaded our code will upgrade anyway once we support the revised
version of the MIB in order to be able to use the new and worthwhile
feature.

Are there any implementors on this list who think that requiring
smRunIndex to be unique in the RFC 2592 update will cause any serious
interoperability problems? If yes, please make your point now.

/js

---

From: Eamonn McManus <[email-masked]>
Date: Thu, 29 Mar 2001 16:45:22 +0200

> Andy> will cause existing conforming implementations to be deemed
[...]
> launching scripts or something like that.

That is not clear to me.  There could be a compatibility problem in the
other direction (old manager, new agent).  Today, if a manager knows
that it is the only manager of a given agent, it can legitimately
determine a value for smLaunchStart by knowing what values it used in
the past, or by reading through the smRunTable entries for a given
smLaunchTable entry and finding a value not used there.  It might do
this if it attaches some additional significance to smRunIndex values
(e.g., encoding information in bits therein) which means that it can't
use the standard smLaunchRunIndexNext value.

This is pure hypothesis -- I am not aware of a system that does this.

> And given the fact that the
> it is hard to update the code

...as far as you know...

> I would expect that doing the change

I think it rather defeats the purpose of a standard if people using it
are obliged to follow high-traffic mailing lists where it is discussed
in order to make sure that no changes are made that break their
implementations.  If there is no answer to your question, you cannot
then assume that nobody will be affected by this change.

Éamonn

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Mar 2001 09:52:54 -0800

Juergen Schoenwaelder wrote:
> 
> >>>>> Eamonn McManus writes:
> 
> Eamonn> I think it rather defeats the purpose of a standard if people
> Eamonn> using it are obliged to follow high-traffic mailing lists
> Eamonn> where it is discussed in order to make sure that no changes
> Eamonn> are made that break their implementations.  If there is no
> Eamonn> answer to your question, you cannot then assume that nobody
> Eamonn> will be affected by this change.
> 

My proposed TruthValue object was based on theory as well.
I don't know of any actual implementations that would benefit
from such a MIB object. I was just thinking that (theoretical)
existing implementations could simply return a hard-wired FALSE value,
if their implementation could not easily support global task IDs,
and still conform to the new RFC.

Now I like your suggestion better because it's simpler. Interested
parties will have WG Last Call and IESG Last Call to object, but I doubt
that will happen.

Andy

> Eamonn, we are cycling at _Proposed_. We already made changes such as
> giving the max. value of smRunLifeTime some special meaning. There
> were other clarifications where people could just interpret the text
> in RFC 2592 in different ways. I believe it is OK to make these
> changes (which do not seem to impact seriously any implementations
> this WG is aware of) at this point in time while cycling at _Proposed_
> level. Note that all the changes/clarifications are clearly documented
> in the spec so that early implementors can easily see what has
> changed.
> 
> Once we go to Draft standard or even to Full standard, one would be
> really careful with touching things. See RFC 2026 section 4.1.1 2nd
> paragraph and section 4.1.2 4-5th paragraph for the differences
> between Proposed and Draft maturity levels.
> 
> Anyway, it is helpful input that you are also not aware of any system
> that will be affected by making smRunIndex globally unique. (Did I
> understand that right or is this my wishful thinking? ;-)
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Mar 2001 17:10:45 +0200

/js

---

From: Eamonn McManus <[email-masked]>
Date: Fri, 30 Mar 2001 16:58:35 +0200

[Reminder of context: it is proposed to make the smRunIndex element in
the Script MIB's smRunTable globally unique, rather than unique per
generating smLaunchEntry as at present.]

> in the spec so that early implementors can easily see what has

OK, my mistake.  I still feel that this change is more violent than the
other ones you mention, though, for the following reasons:

* It is hard for a manager to know whether an agent implements it or
not.  It's easy to see if an agent has a new object introduced since
RFC2592.  It's relatively easy to see if an agent supports max
smRunLifeTime meaning no expiry, and in any case even if it doesn't it's
likely that the very long expiry time will be sufficient.  But if you
need global uniqueness among smRunIndex values, how can you tell whether
you'll have it?  Possible, but tricky.

* Design problem 1: Why is smLaunchRunIndexNext in the smLaunchTable? 
Now that smRunIndex values must be unique, this variable is global and
should not be duplicated in each smLaunchEntry.

* Design problem 2: Why is smRunTable indexed by smLaunchOwner and
smLaunchName as well as smRunIndex, when smRunIndex alone would be
sufficient?  Why aren't smLaunchOwner and smLaunchName just plain
columns in the smRunEntry?  Is the ability to walk through the running
scripts for a given smLaunchEntry with getNext sufficient
justification?  After all, there's no equivalent for a given
smScriptEntry, which seems to me to be at least as interesting.

These problems can be fixed, but it seems to me that the right fix is
more complicated than just tweaking the wording about the uniqueness of
smRunIndex.

> understand that right or is this my wishful thinking? ;-)

That is correct.  My implementation only guaranteed uniqueness within a
given smRunTable but would not have been used in the sorts of contexts
where the difference between this local uniqueness and global uniqueness
would matter.

Éamonn