Subject: Re: agenda for disman working group in Oslo

From: Randy Presuhn <[email-masked]>
Date: Fri, 2 Jul 1999 11:15:01 -0700 (PDT)

Hi -

> To: Randy Presuhn <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: agenda for disman working group in Oslo
> References: <[email-masked]>
> 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).
...

Then let's take extra pains to discuss this (and any of the other issues!)
on the mailing list!  The fact that something appears on the agenda for a
meeting should not be interpreted as any kind of obstacle to discussion
of that issue on the disman mailing list.  If we can resolve any of
these issues on the mailing list, so much the better!

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 15 Jul 1999 04:35:20 -0700 (PDT)

Hi -

> Date: Wed, 14 Jul 1999 10:59:21 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
...
> [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.]
...

Yes, but please continue the discussion.  As I said at the meeting,
arguments based SOLELY on progression won't get very far with this working
group chair.  If we happen to come to the conlusion that a change really
is needed here, it's better that we reach any such conclusion before
the various implementors' installed bases become too large.

---

From: [email-masked]
Date: Wed, 28 Jul 1999 11:55:30 -0400 (EDT)

Sorry for my untimely response;  please disregard this E-mail if
this issue has been settled.

>>>>>> Wes Hardaker writes:
>Randy> 4.2 RFC 2592 (script MIB): Index smLangTable by name rather
>Randy> than Integer32 Index smScriptTable by name rather than
>Randy> Integer32
>
>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

My preference is option (1), only because I've got an agent already
implemented this way.  Aside from that, I have no preference, and
will implement whatever the working group decides is optimal.

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------