Re: Generic TC Module

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

On Wed, Aug 31, 2005 at 11:07:33PM -0700, C. M. Heard wrote:
> [Discussion of MIB Doctor-like issues diverted to mreview list]
> 
> On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote:
> > Now w.r.t. the TC names [indraft-ietf-isis-wg-mib-22.txt]:
> > - AdminState, can in my view best be named IsisAdminState
> > 
> > But I am not sure about the other 2 [Unsigned16TC and
> > Unsigned8TC]. Renaming them to be Isis-prefixed would be OK.
> > They are somewhat generic though, and we have allowed such
> > generic names in some other MIB modules. But this is a real
> > strange MIB module to have such generic TCs. If they do name
> > them IsisXxxx, then of course if we ever do such TCs in a more
> > generic place, then they can easily replace theirs in a later
> > revision and import from our generic MIB module.
> > 
> > Again it seems time that we start a IANA Maintained
> > GENERIC-TC-MIB module or some such, which extends RFC2579. Maybe
> > we should just do a document that picks up RFC2579 MIB and then
> > add a set of TCs we allready agree on, and then at the same time
> > hand it over to [IANA] for further maintenenace.?
> 
> While I can see the value in a "living document" of generic TCs,
> I am not sure that we would want to hand such a thing over to the
> IANA, nor am I sure that they would want to take on the job.  It
> seems to me that this would be a technical document rather than a
> registry, and they are not really equipped to handle the
> maintenance of technical documents.
> 
> The problem, of course, is that the IETF doesn't really have a
> any process for publishing and maintaining living technical
> documents.  Maybe this is an issue we need to raise over in newtrk.

We have this topic on the table every say two years. While I favoured
the IANA solution some time ago, I am not really sure this is a
solution. In fact, generic TCs need wide review and thus they should
go the normal path. The only thing that is really special here is that
TC collections are just TC _collections_ and the standard status
really is a property of individual TC definitions and not the whole
collection. Since we can only progress documents and we only have
normative references to documents, collections really do not work
well. In fact, the STATUS clause can also be seen as some way to work
around this, leading to things like Standard obsolete definitions.  So
to fix this, one would either have extremely narrow and focussed
collections that have a reasonable change to be complete at some point
in time so that they can progress or one would need documents where
different parts have different standards status. The later one would a
rather significant chance from existing practice and thus imply a
change of many mindsets, something less likely to be successful. So
from that perspective, I believe the only option is to start very
narrow TC collections. To some extend, this is what the
INET-ADDRESS-MIB did.

Now, getting back to things like Unsigned8TC, I am not even convinced
there is much value in having a standardized definition for these
things since it is a) trivial to create them if you need them and b)
there is not much implementations can take advange of by having a
general TC definition since these TCs do not seem to have a special
semantics which code generators can not already explore today.

/js

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