[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: time to say "good enough"?
wfm. i.e. ship a rev 01.
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 17 februari 2003 23:34
> To: Mreview (E-mail)
> Subject: 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.
>
>