Greetings, It's not clear from what you write below whether or not you have considered and rejected the idea of creating a proprietary supplemental MIB module to augment the IETF Host-Resources-MIB. Basically, this is suggestion (B) in Randy Presuhn's message
http://www.ietf.org/mail-archive/web/opsawg/current/msg02368.html but with the supplemental object(s) registered under an enterprise OID subtree (available from IANA for the asking) instead of an IETF OID subtree. This approach would not require any standardization effort at all, just the effort to write the supplemental MIB module and to implement the object(s) in it. If the IETF community has low interest in standardizing the extension you are asking for, then this is probably the right way to go. On the other hand, if your extension is seen as broadly useful, updating the Host-Resources-MIB itself is probably the right way to go. It's true that once an object is defined and registered under a given OID the object's semantics are not allowed to change (except in some very limited ways spelled out in RFC 2580) and that OID under which it is registered cannot be reused for something else. But I don't follow why you are worried that if you create an augmenting table for your proposed extension that you would be left high and dry by a subsequent update of the Host-Resources-MIB. Such updates (if they occur) are supposed to be backward-compatible. Mike Heard On Thu, 13 Sep 2012, Sheppy Reno wrote: > I'm in the position of having to go through IETF because none of the work > arounds that I proposed were acceptable for various reasons (a large part > of it boils down to manpower considerations). It seems that from > everything I've read, that updating the Host-Resources-MIB RCF itself is > the proper way to implement this -- manpower considerations aside. I > believe that this is the right way to go and another RFC said something to > the effect that once an OID is placed somewhere it can't be moved. I'd > rather not go through the process of getting it added as an augment only to > find out that RFC2790 was superseded in the next year or two and I'm unable > to get this added correctly. > > Sorry if I seem a bit dense, but RFCs relating to the ins and outs of RFC > documentation is very difficult to navigate for the uninitiated. > > As far as manpower is concerned, assuming I want to proceed with getting > RFC2790 itself updated are there steps that I can take to reduce the > overhead of others as much as possible? > > Thanks again, > Sheppy > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
