Re: thoughts on documentation reuse.

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Wijnen, Bert (Bert) writes:

Bert> Let us stick to TCs, the other stuff may involve much more.

Bert> Making an IANA considerations for registering new common/generic
Bert> TCs seems something we can do.  The problem is that we have MIBs
Bert> that gos PS, DS, STD.  So what we need to be able to defend is
Bert> that a set of such TCs at IANA may be referenced (imported) in a
Bert> normative way and yet such docs may advance on the stds track.

Bert> Does anybody see an objection to that?  Or do many people
Bert> support this?

As you said, standards track documents will end up being dependent on
the TCs. Thus, we need a process in place to update the IANA TCs which
requires open review, last calls and so on. So how can we be sure the
end result is much faster than e.g. a non working group standards
track submission? We have done the INET-ADDRESS-MIB and we are now
doing the TRANSPORT-ADDRESS-MIB without a WG and it basically works.

The slowest part in this process was the turnaround time of the IDs
and the RFC publication delay. The first one does not matter whether
the final result is a standards track RFC or something IANA
maintained. The publication delay is probably smaller with IANA. On
the other hand, the first drafts of the *-ADDRESS-MIBs were much
different from what we have today - so some discussion and time in the
process is probably a good thing for TCs that are not trivial.

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.

(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.

(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).

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.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>