Re: Generic Textual Conventions

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Tue, Apr 06, 2004 at 03:20:15PM +0200, Wijnen, Bert (Bert) wrote:

[...]

> If we were to do a generic TC MIB document that gets updated all the time,
> then it will stay at PS and so docs who import have a tough time to advance.

This seems to point to the core of the problem.
 
> So I thought... let us make then IANA-GENERIC-TC-MIB  items, which is
> (maybe a bit sneaky) bypass when it comes to normative references for
> DS and STD docs.

This proposal essentially boils down to moving the most generic and thus
most important definitions out of the standards process control mechanism.
Here are some other thoughts on the subject, trying to stay within the
standards process:

What might work is a two-phase approach where new TCs are introduced
as the need arises in technology specific modules. If it turns out that
some TCs are actually reused by other MIB modules (note that I mean
actual reuse, not intended reuse), then the TC is copied over to a
generic module (actually a series put on the standards track say every
two years) and we allow documents to change to use the generic TCs 
when they are updated/revised (which is stretching the SMI rules a
bit, but perhaps for a good purpose).

The benefit would be that (a) we only worry about TCs that are actually
reused and (b) that once the TCs are in a generic TC module, they can 
just proceed along the standards track. The downside is that managing 
the updates in various places and ensuring that things semantically
do not change when they are copied will be extra work and it might
be not unlikely that people will just not like to go through the 
pain^Hprocess, especially since the majority of MIB modules hardly 
ever go to Draft or even Standard.

The other more simpler approach might be to have a working document
for generic new TCs that is edited by someone who is willing to act as
a contact person for generic TCs. Periodically, this working document 
is published on the standards track and a new working document is
started. This is basically the model that we currently use for the
INET-ADDRESS-MIB (except that so far we had no problem to just cycle
this document at Proposed and we did not have to create a supplement).

Perhaps a more feasible solution is a combined approach where there 
is always a working document for (a) generic new TCs (where we know 
with high confidence that the TC is generic) and for (b) TCs which 
have turned out to be of generic nature which we pick up from other 
modules to avoid strange dependency relationships.

The other alternative is to encourage people to create many very small
TC modules, like DIFFSERV-DSCP-TC or the IPV6-FLOW-LABEL-MIB or the 
VLAN ID module under discussion in the bridge MIB WG. A good indexing
scheme is important in this case to locate the generic definitions,
but we already have this in place (we just need someone to keep the
list updated): http://www.ops.ietf.org/mib-common-tcs.html

I find it hard to decide between these approaches.

Perhaps we should really go to NEWTRK and ask seriously for the "good 
enough" status for MIB modules (which I think Mike O'Dell introduced 
many years ago). Such a status would indeed save us quite some time.
Since the SMI update rules disallow arbitrary incompatible changes,
having all MIB modules in the good enough state might not be as bad 
as it sounds at first glance...
 
/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany