Hi,
As a programmer, I am accustomed to using header files, includes, and other modular pieces referenced by my code. I prefer that to having data cut and pasted all over the place. It also allows for reusable documentation, which increases the likelihood of it being stable. Cut and paste leads many to make minor modifications, especially to enterprise mibs, leading to bugs and inconsistencies in implementation.
As pointed out, there are tools such as debuggers available that make working through all the references easier. With browser-based tools and web servers, the consistency of user interface of these tools and hypertext makes it quite easy for users to use.
I think the problem is much more an issue of not having a standard set of reusable libraries available that writers and readers can learn. If we can make it easier to reuse the existing set of T-Cs by making them accessible from a central location, and we can discourage mib writers from reinventing wheels, a standard set could be developed. When every WG feels they need to define their own named version of a UTF-8 DisplayString rather than relying on T-Cs developed in other WGs, a standard set of T-Cs cannot be learned easily by writer or reader. When a T-C is defined and made readily available for reuse, people will learn the T-C and will reuse it; RowStatus falls into that category.
One thing that I think discourages the reuse of T-Cs is the inability to specialize an existing T-C. To develop an SnmpAdminString with a limited set of characters or other specialization, the writer must cut and paste the original definition into the new SnmpAdminString description, add a paragraph for specialization, and rename it. This makes developing a standard set of T-Cs that can be learned pretty impossible.
An inheritance mechanism would lead to many T-Cs referencing many of the same base T-Cs, would encourage people to learn the commonly referenced T-Cs, just as programmers learn the C library or Java library routines.
The other serious disincentive to reuse is a standards process that allows a normative reference to totally stall any dependent effort from forward progress. Nobody wants to stall their WG's progress by reusing something that hasn't advanced yet. The development of a header file document, such as INET-ADDRESS-MIB, that can be moved toward standard separately from and faster than the full-blown mib would help alleviate that disincentive, as would versioning.
dbh
> -----Original Message-----
> From: Durham, David [mailto:david.durham@intel.com]
> Sent: Friday, March 29, 2002 4:12 PM
> To: 'Juergen Schoenwaelder'; wes@hardakers.net
> Cc: sming@ops.ietf.org
> Subject: RE: thoughts on documentation reuse.
>
>
> I would liken this to reading a book and having a glossary
> for acronyms.
> After I read it once, I really don't want to know what IETF
> expands out to
> be each and every time I use the acronym.
>
> So even from a documentation standpoint, I could see the need for a
> "glossary" of reused data in an appendix somewhere, but I
> wouldn't want to
> see that extra text repeated over and over again everywhere in my
> document... I don't view that as being particularly readable
> for anyone.
>
> -Dave
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> > Sent: Friday, March 29, 2002 12:42 PM
> > To: wes@hardakers.net
> > Cc: sming@ops.ietf.org
> > Subject: Re: thoughts on documentation reuse.
> >
> >
> >
> > >>>>> Wes Hardaker writes:
> >
> > Juergen> If I see a data type in a program and I need to know more
> > Juergen> about it, I have to go to the place where it is defined to
> > Juergen> see the details. This is really not that hard to do.
> >
> > Wes> The discussion in question centers around a notion that people
> > Wes> aren't doing that.
> >
> > I agree that modular systems require people to do more lookups. How
> > people do these lookups is IMHO something outside the scope of a
> > language definition. If you prefer to print MIBs with all IMPORTS
> > resolved into one big set of definitions - no problem. It would be
> > relatively easy to hack smidump so that it produces output which
> > incorporates all imported definitions and thus works more
> or less like
> > a C preprocessor (although I do not know how to deal with
> things like
> > ifIndex - incorporate the whole ifTable??).
> >
> > I personally doubt this is extremely useful (as much as I usually
> > dislike reading C preprocessor output). But that is probably more
> > personal taste and working style. I also doubt that it will work to
> > provide little summaries that are automatically merged without
> > generating some confusing output in same cases, especially if MIB
> > authors tend to not read the expanded version of their documents.
> >
> > I am not sure how big this problem really is and whether it really
> > requires a solution in the language specification. I have
> heard people
> > complaint that it is hard to obtain complete MIB
> definitions from some
> > vendors and nasty to extract MIBs from RFCs. I never heard someone
> > complain that looking up and imported definition was too
> complex once
> > the MIB module was available.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder
> <http://www.informatik.uni-osnabrueck.de/schoenw/>
>
>
>