Re: Apendices B and C (Was: RE: comments on mib review guidelines01)

["C. M. Heard" <heard@pobox.com>]

On Sun, 6 Jul 2003, Romascanu, Dan (Dan) wrote:
> > JS> k) Appendix B says that smidiff does not honor the -i 
> > JS>    namelength-32 switch which was indeed correct. I have 
> > JS>    fixed this bug and the next release will just do the
> > JS>    right thing so I suggest to remove the relevant text.
> > 
> > BW> I thought we were going to remove the listing of specific 
> > BW> tools (cause it might look as promoting things or omiting 
> > BW> others).
> > 
> > I have to say (reluctantly) that the comments we got some months
> > ago on the mibs@ops.ietf.org list lead me to agree with Bert on
> > this.  Personally, I think that the appendices are quite useful,
> > but I don't want to get in the middle of a cat fight about this.
> 
> I also find the information in appendices B and C very useful. I
> understand the argument that we want to avoid looking like
> promoting some tools, and omitting others. On the other hand we
> want MIB authors to be aware about what we consider to be the
> appropriate tools for them to use, in order to do the right
> thing from the start. Would keeping and maintaining this
> information on a Web page accessible from
> http://www.ops.ietf.org/, be a better solution? We could draft a
> neutral text to recommend the usage without promoting them, and
> in the future we could do easily updates like the ones suggested
> by Juergen for smidiff.

I think that the approach suggested by Dan is probably the right way
to go.  Such an approach would make it possible to add information
for MIB compilers from other vendors if warranted.

Assuming that we get consensus on this approach, what I'd like to do
in the published document is (a) remove appendices B & C and (b) to
revise the places in the text that refer to those appendices to
refer instead to the URL of the proposed web page.  One problem with
this plan is that we would need to at least have a stable URL and
preferably a working web page before publication of the guidelines
document as an RFC.  In fact, since we have lots of folks using the
I-D, I'd rather not make any changes in this area the next I-D spin
until we've made a decision and gotten a web page up, if that's what
we decide to do.

Let's hear some other opinions, please.

Mike