Subject: Re: agenda for disman working group in Oslo

From: Wes Hardaker <[email-masked]>
Date: 02 Jul 1999 08:47:45 -0700

>>>>> On Mon, 28 Jun 1999 22:16:20 -0700 (PDT), Randy Presuhn <[email-masked]> said:

Randy> 4.2 RFC 2592 (script MIB):
Randy> Index smLangTable by name rather than Integer32
Randy> Index smScriptTable by name rather than Integer32

Unfortunately, I was the last one to bring this subject up but I won't 
be there...  (Unless by chance it'll be broadcast over multicast).
(or an extra $1500 shows up in my bank account that I forgot about).

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Jul 1999 16:29:16 +0200

>>>>> Wes Hardaker writes:

>>>>> On Mon, 28 Jun 1999 22:16:20 -0700 (PDT), Randy Presuhn <[email-masked]> said:

Randy> 4.2 RFC 2592 (script MIB): Index smLangTable by name rather
Randy> than Integer32 Index smScriptTable by name rather than
Randy> Integer32

Wes> Unfortunately, I was the last one to bring this subject up but I
Wes> won't be there...  (Unless by chance it'll be broadcast over
Wes> multicast).  (or an extra $1500 shows up in my bank account that
Wes> I forgot about).

Since I cannot increase your bank account, I will simply use email to
express my view on this. ;-)

I agree that using names for the smLangTable and smExtsnTable would
have been more intuitive and it would actually better fit the way we
store a scriptMIB agent configuration in our implementation.

However, changing the indexing structure requires to deprecate the
smLangTable, the smCodeTable and the smScriptLanguage object in the
smScriptTable and we need to define new tables that use a name as an
index and we have to add a new object to the smScriptTable which
points back to the language. The question is whether this non-trivial
change to the MIB and the price we pay for it is well justified.

A less drastic option would be to keep the tables as they are and to
add two new columns smLangAlias and smExtsnAlias to smLangTable and
smExtsnTable which are used to hold a unique name for a language or
extension. This would make the label we use in our configuration file
accessible in the MIB. Furthermore, these new objects may help if
future tables have to refer to the smLangTable or the smCodeTable.
From the functional point of view, this does not add anything new to
the MIB nor does it fix a serious problem. So still the question
remains whether this change is well justified.

I currently see three options:

(1) keep things as they are

(2) add another name column to the smLangTable and the smCodeTable

(3) redo the smLangTable and the smCodeTable to use names as indexes

I prefer option (1), I can live with option (2) and I dislike option
(3). Comments? What do others think about this issue?

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 1999 11:30:04 +0200

>>>>> Randy Presuhn writes:

Randy> Here's the current agenda for the disman working group meeting
Randy> in Oslo.

Here is another issue we should try to solve in Oslo. The IANA
maintained MIB module IANA-LANGUAGE-MIB got removed from RFC 2592
prior to publication (which is fine). The MIB module never showed up
on ftp.iana.org or on any other side I am aware of. I know that the
future of IANA itself is unclear at the moment but I think we cannot
tolerate that IANA maintained MIB modules silently disappear.

							Juergen

---

From: Wes Hardaker <[email-masked]>
Date: 08 Jul 1999 21:32:17 -0700

>>>>> On Mon, 5 Jul 1999 16:29:16 +0200, Juergen Schoenwaelder <[email-masked]> said:

Wes> won't be there...

Juergen> I agree that using names for the smLangTable and smExtsnTable
Juergen> would have been more intuitive and it would actually better
Juergen> fit the way we store a scriptMIB agent configuration in our
Juergen> implementation.

More importantly, in my mind, it makes it much easier for a manager to
find the script implementation its looking for.  Currently, to find if
a remote agent supports "java", it would have to walk a column of the
table to search for that name which it could only search by OID
currently.  Having the string "java" in the table would definitely
help, as you suggested.  However, even with this addition, a manager
must still walk the entire column of the table to figure out it in a
given language is supported. Fortunately, this table will most likely
be small.  The other option, since currently no column exists which is
sufficient, would be to index the table with a the smLangLanguage
column. This would be just as acceptable in my eyes.

Juergen> However, changing the indexing structure requires to
Juergen> deprecate the smLangTable, the smCodeTable and the
Juergen> smScriptLanguage object in the smScriptTable and we need to
Juergen> define new tables that use a name as an index and we have to
Juergen> add a new object to the smScriptTable which points back to
Juergen> the language. The question is whether this non-trivial change
Juergen> to the MIB and the price we pay for it is well justified.

I brought up this very point when I first mentioned this
suggestion. At that time, I stated that even though this change would
be nice, in probably many people's eyes, I was betting that this
working group would not be willing to implement this change this late in
the standards process. I need to get started in getting more involved
at an earlier point in a working group's progress, as this keeps
happening to me repeatedly.

This change its worth it in my eyes, but I'm probably biased. I have
yet to deploy an agent with this script mib implemented, so I have no
clients that are making use of an older table.

Juergen> A less drastic option would be to keep the tables as they are and to
Juergen> add two new columns smLangAlias and smExtsnAlias to smLangTable and
Juergen> smExtsnTable which are used to hold a unique name for a language or
Juergen> extension.

This would definitely be an improvement, but does not solve the the
worst of the problems. Consider an agent who get upgraded in a new
script implementation is installed. In the current table, if the first 
row (indexed by the numeral one) was replaced by a different script
language with the same index, in the manager using the aged didn't
notice that the agent had changed, it might attempt to use the
smScriptLanguage node of the smScriptTable table incorrectly. This, in 
my opinion, is the worst of the problems. A smart vendor will always 
use a different numerical index for any built-in and scripts that
it didn't support. However, for user configurable systems (like the one 
I am implementing) it is possible that the user will not foresee this 
complex problem and will replace a script language with another
without changing the index.   One possible solution to this problem,
is to replace the definition of the smScriptLanguage node with a
similar node whose datatype is an object identifier, found above.

Juergen> I currently see three options:

Juergen> (1) keep things as they are

Juergen> (2) add another name column to the smLangTable and the smCodeTable

Juergen> (3) redo the smLangTable and the smCodeTable to use names as indexes

Juergen> I prefer option (1), I can live with option (2) and I dislike option
Juergen> (3). Comments? What do others think about this issue?

I would prefer option 3, then 2, then 1, as I've indicated.   However,
I would not be surprised if this working group is unwilling to head
this direction.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jul 1999 11:23:53 +0200

>>>>> Wes Hardaker writes:

Wes> More importantly, in my mind, it makes it much easier for a
Wes> manager to find the script implementation its looking for.
Wes> Currently, to find if a remote agent supports "java", it would
Wes> have to walk a column of the table to search for that name which
Wes> it could only search by OID currently.  Having the string "java"
Wes> in the table would definitely help, as you suggested.  However,
Wes> even with this addition, a manager must still walk the entire
Wes> column of the table to figure out it in a given language is
Wes> supported. Fortunately, this table will most likely be small.

You can't bet on the name since there is nobody who is going to
"standardize" names. And its very well possible to have multiple
versions of a language. So looking for "java" does not help at all.
You either end up encoding all the information into the name
"java-1.2-sun" or you once again need to scan the whole table
(since there might be "java", "Java", "JAVA" and so on).

Wes> The other option, since currently no column exists which is
Wes> sufficient, would be to index the table with a the smLangLanguage
Wes> column. This would be just as acceptable in my eyes.

The smLangLanguage column is what uniquely identifies a particular
language. But it does not identify a particular version or revision of
a language. 

I think you there are three problems you want to have solved:

1) You do not want to read the whole smLangTable in order to find the
   right index value. Instead, you like to lookup the language
   directly.

   I think this is hard to achieve. Sure, its possible to have a
   cross-reference table which maps language names to index values.
   But it does IMHO not really solve the problem since you still have
   to know the right name in order to find things.

2) You are arguing that the references via smScriptLanguage can be
   problematic if users configure new languages and screw up the
   indexing structure.

   This problem can be solved by proper design of the configuration
   file. This is basically the reason why we use name tags in the
   configuration file for these references. So the indexing is
   actually generated by the agent when it loads the configuration
   file and is therefore always consistent within the agent.

3) The re-initialization of the agent might change the indexing
   structure in the smLangTable/smExtsnTable and hence any cached
   index values in a manager may be wrong.

   This is true. Thats why the procedures suggested in RFC 2592 (7.2
   and 7.3) says that the manager has to obtain the right language
   index from the smLanguageTable first. (Oops, this should actually
   be smLangTable - we found the first bug in the RFC). This means
   that the problem can only happen in the time window where you
   install the script. (I guess you can even work around this by
   clever usage of snmpSetSerialNo.)

This probably sounds like I am arguing against any changes. This is
not necessarily true. All I want right now is to figure out what
exactly the problem is we are trying to solve.

I am not convinced yet that a different indexing structure makes it
much easier for the manager to search for the right language. A name
is just a name and you still have to look into the smLangTable (and
most likely also into the smExtsnTable) to select the right name you
want to use (unless you encode all information into the name).

For me, the only problematic thing is the reference from the
smScriptTable to the smLangTable by number rather than name. This
causes problems that probably would have been less likely if we were
using names instead. (Note that names do not make it go away - just
less likely. If I change the names for languages, I still have the
same problem to solve.) I think that its possible to take care of this
problem by proper implementation design on the manager and the agent
(as outlines above).
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Wes Hardaker <[email-masked]>
Date: 13 Jul 1999 21:57:47 -0700

>>>>> On Fri, 9 Jul 1999 11:23:53 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> You can't bet on the name since there is nobody who is going
Juergen> to "standardize" names. And its very well possible to have
Juergen> multiple versions of a language. So looking for "java" does
Juergen> not help at all.  You either end up encoding all the
Juergen> information into the name "java-1.2-sun" or you once again
Juergen> need to scan the whole table (since there might be "java",
Juergen> "Java", "JAVA" and so on).

Well, I must agree that since the names aren't standardized (just
common), then in that case I'd prefer to index by the OID which will
be standardized.  I don't see the version numbering as being so much
of a problem.  Yes, you need to know what version the scripting
language is, but unless there are major incompatibilities (like
between most of the java language versions) then you may have to index
by a different defined OID.  For more stable languages (C, C++, Perl,
etc) then that probably won't be as necessary.  At least you'd have a
starting place to look for data without having to traverse an entire
mib column.  Again, if something changes out from underneath it
numerically, as can happen in the current integer indexed scheme, bad
things may happen.  And determining how often a manager should check to
see if something has changed can be problematic.  If an OID is used,
the language may disappear but then you'll get a definitive error back
from the operations instead of data that is incorrect...

Juergen> I think you there are three problems you want to have solved:

Juergen> 1) You do not want to read the whole smLangTable in order to
Juergen> find the right index value. Instead, you like to lookup the
Juergen> language directly.

Correct.

Juergen> I think this is hard to achieve. Sure, its possible to have a
Juergen> cross-reference table which maps language names to index values.
Juergen> But it does IMHO not really solve the problem since you still have
Juergen> to know the right name in order to find things.

Or OID.  Whichever.  I agree that an OID is probably a better choice.

Juergen> 2) You are arguing that the references via smScriptLanguage
Juergen> can be problematic if users configure new languages and screw
Juergen> up the indexing structure.

Juergen> This problem can be solved by proper design of the
Juergen> configuration file. This is basically the reason why we use
Juergen> name tags in the configuration file for these references. So
Juergen> the indexing is actually generated by the agent when it loads
Juergen> the configuration file and is therefore always consistent
Juergen> within the agent.

And when your agent generates the indexes that have changed from the
previous reboot of 5 minutes ago and the manager hasn't checked for
that change?  If you have 3 scripts in your configuration file, and
you auto-generate the numbers then you modify the mib to remove one
and add another that the sequence and numbers won't be messed up?  I
suppose you could hash the token name into a integer, which would
would but would be an annoying oid to use...

Juergen> 3) The re-initialization of the agent might change the indexing
Juergen> structure in the smLangTable/smExtsnTable and hence any cached
Juergen> index values in a manager may be wrong.

Juergen> This is true. Thats why the procedures suggested in RFC 2592 (7.2
Juergen> and 7.3) says that the manager has to obtain the right language
Juergen> index from the smLanguageTable first. (Oops, this should actually
Juergen> be smLangTable - we found the first bug in the RFC). This means
Juergen> that the problem can only happen in the time window where you
Juergen> install the script. (I guess you can even work around this by
Juergen> clever usage of snmpSetSerialNo.)

Well, you're right here.  I guess the only time that the problem
should be checked against is when you actually do a create operation.
After that, you should probably be ok...

Juergen> I am not convinced yet that a different indexing structure
Juergen> makes it much easier for the manager to search for the right
Juergen> language. A name is just a name and you still have to look
Juergen> into the smLangTable (and most likely also into the
Juergen> smExtsnTable) to select the right name you want to use
Juergen> (unless you encode all information into the name).

As indicated above, because names aren't standardized, I agree...  An
OID would be better (smLangLanguage specifically)...

Juergen> For me, the only problematic thing is the reference from the
Juergen> smScriptTable to the smLangTable by number rather than
Juergen> name. This causes problems that probably would have been less
Juergen> likely if we were using names instead. (Note that names do
Juergen> not make it go away - just less likely. If I change the names
Juergen> for languages, I still have the same problem to solve.) I
Juergen> think that its possible to take care of this problem by
Juergen> proper implementation design on the manager and the agent (as
Juergen> outlines above).

Anything is possible with enough convoluted design.  We're (well, I
haven't been of any help, so its really "you're") designing a mib and
all I'm saying is you have the chance now to make it as convenient as
possible for the agent and management implementer and the end user.
The time to make it right is now, so that people don't *have* to make
it work and worry about these problems, because they won't be there.

Again, I'll repeat my comment in all my other messages that the
problem is a small and atheistic only.  "It would be nice, but its not
required".

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jul 1999 10:59:21 +0200

>>>>> Wes Hardaker writes:

Wes> Well, I must agree that since the names aren't standardized (just
Wes> common), then in that case I'd prefer to index by the OID which
Wes> will be standardized.  I don't see the version numbering as being
Wes> so much of a problem.

It was part of the DISMAN charter that whatever we invent should not
create new management problems. And this is why we spend quite some
time to work out the attributes that are now in the smLangTable and
the smExtsnTable. The whole purpose of these tables is actually to be
prepared to deal with versioning issues that will show up once this
gets deployed in the real world.

And OID simply does not cut it (even if you define lots of OIDs, it
will be very hard to write management applications to do reasonable
things with them (such as selecting the version of a language which is
closest to what I would prefer to have)). You should be able to find
the discussion why OIDs alone are problematic somewhere in the WG
mailing list archive.

Wes> Yes, you need to know what version the scripting language is, but
Wes> unless there are major incompatibilities (like between most of
Wes> the java language versions) then you may have to index by a
Wes> different defined OID.  For more stable languages (C, C++, Perl,
Wes> etc) then that probably won't be as necessary.  At least you'd
Wes> have a starting place to look for data without having to traverse
Wes> an entire mib column.

You can't reason about OID values. But you want to reason about
version numbers.

Wes> I guess the only time that the problem should be checked against
Wes> is when you actually do a create operation.  After that, you
Wes> should probably be ok...

Right. BTW, there is another way to make the script creation operation
safe: You simply create the entry and before enabling the script, you
check whether the language is correct. You do not even need the
snmpSetSerialNo object to do this.

Wes> Anything is possible with enough convoluted design.  We're (well,
Wes> I haven't been of any help, so its really "you're") designing a
Wes> mib and all I'm saying is you have the chance now to make it as
Wes> convenient as possible for the agent and management implementer
Wes> and the end user.  The time to make it right is now, so that
Wes> people don't *have* to make it work and worry about these
Wes> problems, because they won't be there.

As I said, it is a trade-off decision. The price for using names is to
deprecate two tables and to deprecate at least the object which points
to these tables. The question is whether this price is justified for
what we get for it. The indexes we have now definitely work. The only
advantage of names over numbers is that they are move convenient for
users that manually configure these tables. But you still can get
corrupted indexes if the manager is not careful when installing new
scripts.

[BTW, the result of the discussion today was that we do not yet have
 agreement on this issue. And we don't have to decide now since we
 will not open up the documents before autumn this year. This also
 means we can get more experience from early deployments and/or
 alternate implementations.]
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)