Subject: PWG> HR MIB Dependency Issues

From: Randy Turner <[email-masked]>
Date: Tue, 17 Dec 1996 09:35:34 -0800

During the Network Management Open Area Meeting at the IETF
 in San Jose, Lloyd, Chris Wellens, and I discussed our options
 for advancing the status of the Printer MIB with reliance on
 the HR Mib. Included in this discussion were Scott Bradner, the
 Area Director for Operational Requirements within the IETF, Steve
 Waldbusser, and Jeff Case. Scott Bradner wrote the document that
 describes document advancement within the IETF, and we came up
 with three possible options that we can take with advancing the
 status of the Printer MIB:
 
 (For those of you that were at the discussion, I have taken
 editorial liberty with the ordering of the options, but the
 meanings are still the same)
 
 Option 1:
 
 Once the draft is in final form for RFC publishing, submit it to
 the RFC editor, with a request through Dierdre to the IESG for
 advancement to "Draft Status". We do NOT include any information
 or conformance information that explicitly states a reliance on
 the Host Resources MIB for implementations that wish to be
 compliant with the Printer MIB. While not exactly the case (since
 every table we have in the MIB is indexed by HrDeviceIndex), we
 can attempt to make a case for not requiring the HrDeviceIndex
 for implementations, and instead state that this index is always
 "1" or some other plausible argument.
 
 Option 2:
 
 Petition the IESG to move HR MIB to Draft, showing the PWG's
 implementation experience with the HR MIB. Scott Bradner stated
 that the HR MIB working group does not have to re-chartered or
 restarted to take the HR MIB from "proposed" to "draft". Some
 other working group or group of individuals can petition the
 IESG to advance the status of the HR MIB. Which of course was
 news to me.
 
 Basically, if PWG members have implemented RFC 1759, then they
 probably implemented some, if not all, of the HR MIB. If the
 implementations by PWG members do encompass all of the required
 groups within the HR MIB, then this may not be the way to go.
 
 But, if we have at least two implementations that have implemented
 all of the mandatory HR MIB groups, then we have ammunition to
 ask the IESG to advance it, based on our experience.
 
 One other way would be to ask Steve Waldbusser to poll the
 members of the working group to send their respective
 implementation experience so that Steve can pass this along to
 the IESG with a recommendation to advance to "draft" status.
 
 Option 3:
 
 Do nothing and leave the printer MIB (not RFC 1759, but the
 new RFC when we publish it) at "proposed" state. Both Steve
 Waldbusser and Jeff Case pointed out that it is not entirely
 necessary for a specification to advance all the way through
 the standards track to achieve market success. The primary
 example they pointed out was the RMON MIB, which has been a
 smashing market success. This document only recently became
 draft, but during its market buildup and implementation, it
 remained at "proposed" status for 4 years.
 
 Even though 4 years exceeds the two year lifetime for RFCs
 at the "proposed" level, both Scott Bradner and Steve echoed
 the IETF sentiment that these lifetimes are not strictly
 enforced, especially in light of a market-driven acceptance
 and success of a particular WG's effort.
 
 --

 There are probably many permutations of these combinations that
 could be formed but I think these options should be taken as
 they are since I feel comfortable with the esteemed review of
 our colleagues within the IETF community. Subsequently, I would
 like to hear the WG's comments with regards to these options,
 hopefully we can make a decision on the direction we would like
 to take by the January meeting, since work on
 at least one of these options should start immediately.
 (Option 2, with help from Steve W.)

Randy

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]