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

From: Dirk Hoffstadt <[email-masked]>
Date: Thu, 30 Oct 2008 16:47:04 +0100

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: [email-masked]
Internet:  http://www.dhdt.de
PGP-PublicKey: https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
------------------------------------------------------------------

_______________________________________________
rserpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rserpool

---

From: "Michael Kohnen" <[email-masked]>
Date: Fri, 31 Oct 2008 10:15:25 +0100

Dear all,

as part of my work on distributed systems, I actively deploy RSerPool
systems to manage highly-available compute services using the Open Source
rsplib and FH Muenster implementations. Using SNMP to manage such setups is
highly useful, since the number of components may get very large (my pools
contain about 40 systems, which is still small). I definitively see the need
for a common MIB, since otherwise the RSerPool components managed by
different implementations will define and use their own MIBs. This causes
unnecessary incompatibilities. Therefore, and since the core RSerPool
documents are already published as RFCs, I suggest to get the MIB draft
forwarded to RFC status. I have reviewed the MIB; after adding the opaque
transport parameter, the document is in my opinion okay.

Regards

Michael Kohnen
-- 
Dipl.-Wirt.-Inf. Michael Kohnen
 
Lehrstuhl für Technik der Rechnernetze
Institut für Experimentelle Mathematik und Institut für Informatik und
Wirtschaftsinformatik
Universität Duisburg-Essen, Campus Essen
Ellernstr. 29
45326 Essen
 
Telefon: +49 (201) 183-7636
Fax: +49 (201) 183-7673
E-Mail: [email-masked]
Homepage: http://www.uni-due.de/tdr/

---

From: Randy Stewart <[email-masked]>
Date: Fri, 31 Oct 2008 07:49:58 -0400

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

> use incompatible MIBs - which should be avoided.

-----
Randall Stewart
[email-masked]