Re: 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=FCxen - 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 protected]
> Internet:  http://www.dhdt.de
> PGP-PublicKey: https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
> ------------------------------------------------------------------
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rserpool
>

-----
Randall Stewart
[email protected]