RE: thoughts on documentation reuse.

["Ayers, Mike" <Mike_Ayers@bmc.com>]

> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] 
> Sent: Tuesday, March 26, 2002 05:27 AM

> >>>>> Wijnen, Bert (Bert) writes:
> 
> Bert> Let us stick to TCs, the other stuff may involve much more.

	Err... I'll accept your suggestion to drop discussion of encryption
algorithms (it was just a nudge anyway :-).  However, I do not think we
should consider this issue as occuring in a vaccuum.  There are other things
(Juergen's mention of MIBs without headers in them is a good example) which
can benefit from a faster development time.

<SNIP/>

> I think we should investigate whether we can make the standard process
> work faster for these things before we go to IANA. Some things we can
> do:
> 
> (a) Use individual submissions to avoid charter discussions and
>     working group activation.

	I don't like this.  The first thing that comes to mind: how do we
maintain the document after the train hits you?

> (b) Work hard with the ADs to figure out how we can update MIB
>     documents without destabilizing them on the standards
>     track. Putting additions into separate modules just for this
>     reason is IMHO broken since it forces MIB readers to deal with all
>     the fragemented MIB pieces. (The inverted stack table of the
>     IF-MIB is a good example for this.) I would like to have a process
>     where I can publish a MIB fragment (more or less a patch) that
>     goes into an existing MIB module.

	I feel your distaste for the practices that have sprung up to deal
with the current situation, but I think that rapid updates of RFC MIBs will
not solve the problem - I suspect it will create worse problems than those
it is intended to solve.

> (c) Work with IANA to setup a repository where all the MIBs in their
>     latest form are available for download. We maintain such a set for
>     our libsmi distribution and it is not too much work. However, the
>     question comes up whether the IANA version contains fixes or not
>     (some older MIBs have some serious errors.) But perhaps this can
>     be handeled once we know the answer to (b).

	This should be done in any case.  The current practice of requiring
users to download the entire RFC and strip out page headers and fotters is,
IMHO, cruel and unusual punishment, and prone to causing errors.  Again,
however, I do not see IANA as the solution.  The RFC Editor already may
maintain multiple documents for an RFC (text, XML, PostScript) - maintaining
a MIB file as well should cause no undue burden.  It could be mandated that
all new RFC submissions which contain MIBs also submit the MIBs as separate,
compilable files (while still keeping the copy in the document) with a name
of the form <module name>.mib (for i-ds, the name would be <i-d-name>.mib,
so that it would appear next to its i-d in the i-d repository).  When an RFC
is updated, the new file would replace the old one, so that only the current
MIBs appear in the distribution.  The current MIBs could be distributed as a
.tar.gz file. (Separate files could be maintained for historic and
experimental RFCs, but at least the experimental shouldn't be encouraged
this way...?)  Volunteers could be recruited to extract existing MIBs to get
things started (and yes, I would volunteer).

	However, I don't think that this addresses the TC problem (but let's
still do it!).

> If we can define a process like this, I would prefer to stay with the
> standards track rather than giving change control to IANA and perhaps
> loosing the capability to reconstruct the MIB modules from RFCs that
> were present at a certain moment in time.
> 
> Also note that such a process would work not only for TCs.

	How about:

	A new class of documents, Support Documents, is created.  The
contents of these documents are strictly limited so that can only contain
information such as TC definitions, which is intended to support development
of RFCs proper.  These documents must be generated by a WG, and may only be
updated by that WG (unless that WG has disbanded, in which case any WG can
update).  No charter modification would be required to generate them, and
they need only an initial discussion period of two weeks and a Last Call,
with WG consensus required to pass each phase.  These documents would have a
standards track just like RFCs.

	I think that this would solve the problem that we're having.

	Boy, I'm just full of ideas today - maybe  I should do some work!


/|/|ike