[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: time to say "good enough"?
On Mon, 17 Feb 2003, David Harrington:
> Could we submit this for "good-enough" status?
>
> Could we redirect our scarce resources to something useful to operators?
I assume that this comment is directed at all of the ongoing MIB
review guidelines doc discussion, and not just the recent chatter on
the "Extensible TCs" thread. And I've gathered from the generally
low level of participation in the discussion that most of the folks
here feel pretty much the same way.
If that is indeed the case, then I would be happy to wrap up this
phase of the work and submit an -01 draft. If I were to do that,
the table below shows how I would deal with current open issues.
As far as I'm concerned the only really pressing issue is the 2nd
one on the list ("Disposition of IANA-maintained MIB modules"), but
I don't think we can actually settle that one here. With that one
exception, I think the document could be used "as is" (even with a
few open issues) to get our "running code" experience.
Regards,
Mike
Issue Section Status Disposition
Importing items used in 4.4 Change from MAY to RECOMMENDED Leave the
compliance statements & proposed; call for consensus current
capabilities statements issued; no feedback received. text as is.
Disposition of 4.5 Current text states that List as an
IANA-maintained IANA-maintained MIB modules open issue
MIB modules are to be removed prior to in the -01
publication. Some folks draft.
advocate publishing the
initial version (cf. RFC 1573)
to provide a record; others
argue that the IANA version is
normative and that IETF specs
should not have non-normative
text that duplicates something
in a referenced spec. This
issue is still under discussion.
It will also be necessary to add
instructions for including an
IESG-mandated copyright notice
once the IESG has decided what
form that notice should take.
Should the guidelines 4.6.1.10 Change proposal for 4.8 posted Accept the
RECOMMEND that compliance to list; A. Bierman objected on latest text
statements include OBJECT the grounds that it makes the proposed by
clauses with SYNTAX that compliance statements too long, the editor.
includes all named and suggested that such OBJECT
numbers or named bits clauses be added only after a
for enumerated INTEGER revision makes them necessary
or BITS objects with (note that Section 4.9 already
extensible enumerations? recommends doing that when
it is needed). B. Wijnen
suggested that the reco could
apply just to definitions that
use imported TCs. Text was
proposed for Section 4.6.1.10
recommending specification of
supported values in such cases;
it is under discussion.
Should DESCRIPTION 4.6.2 Text has been proposed; Accept the
clause of read-write "wfm" from B. Wijnen; proposed
objects specify more feedback awaited. text.
persistence of
values across reboot?
Should guidelines say 4.6.3 Text has been proposed; Accept the
something about not a comment from R. Presuhn text with
using IMPLIED? has been incorporated; Randy's
additional feedback awaited. changes.
Should it be explicitly 4.6.4 Text has been proposed; Accept the
stated that objects lukewarm OK from B. Wijnen; editor's
SHOULD NOT be registered more feedback awaited. proposed
beneath groups, MCs, ACs? text.
Should it be mandated 4.6.5 Editor has proposed modified Accept the
that overall index size text that is though to editor's
limit be spelled out in better represent the rough proposed
tables where SIZE clauses consensus from the APM-MIB text.
do not enforce the 128 discussion; feedback has
sub-identifier limit? been requested.
Should a section be 4.6.6 B. Wijnen & M. Heard supported List as an
added to cover the idea; other opinions have open issue
recommended naming been requested, but none have in the -01
conventions? been publically expressed. draft.
Does SMICng include Appendix C The include file in Appendix C List as an
file need to be updated was built for book version open issue
2.2.07 in the -01
draft.