[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Rserpool] WG Last Call on the Rserpool MIB draft

Dirk:

Let me add my two cents to this discussion as well..

The company I work for will soon be using Rserpool for its
fault tolerant deployments. We will be highly dependent on having
a mib since all of our monitoring is via SMNP... so it would be
really useful to have it as a "standard" mib.. we can use it
without this.. but then we will have to keep the document alive
somehow for a long time... not a good situation IMO..

R
On Oct 30, 2008, at 11:47 AM, Dirk Hoffstadt wrote:


Dear Magnus,
in our company DH Datentechnik, we actively deploy RSerPool for workload 
distribution in a SimProcTC-based simulation pool. For our
administration, we strongly rely on SNMP-based tools. Having the
possibility to also administer different RSerPool systems would be a
great benefit for reducing our non-SNMP administration overhead.

I have reviewed the draft document draft-ietf-rserpool-mib-07.txt and
found - except for the missing opaque transport parameter mentioned by
Michael Tüxen - no problems. Since the core RSerPool documents are RFCs 
now, I think it is quite useful to also bring the MIB document to RFC
soon. Otherwise, I see the problem that different RSerPool-based systems 
use incompatible MIBs - which should be avoided.


--

Regards,

Dirk Hoffstadt

------------------------------------------------------------------
M.Sc. Dirk Hoffstadt
DH Datentechnik
45219 Essen
Germany
E-Mail: hoffstadt at dhdt.de
Internet:  http://www.dhdt.de
PGP-PublicKey: https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
------------------------------------------------------------------

_______________________________________________
rserpool mailing list
rserpool at ietf.org
https://www.ietf.org/mailman/listinfo/rserpool



-----
Randall Stewart
randall at lakerest.net




_______________________________________________
rserpool mailing list
rserpool at ietf.org
https://www.ietf.org/mailman/listinfo/rserpool