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
rturner at sharplabs.com