RE: Generic TC Module

["C. M. Heard" <heard@pobox.com>]

On Thu, 1 Sep 2005, Wijnen, Bert (Bert) wrote:
> I would think that if we declare that the TC first needs to be 
> documented (not in a MIB module, but just as a simple TC) and
> that we need IETF consensus on it, then we can do it. It would
> be OK (as far as I am concerned) to just have such a document
> as Informational. The IESG does a 2 week Last Call on them,
> and only after approval will IANA add the TC.
> 
> For many simple TCs (like the Unsigned16TC and Unsigned8TC) I
> would think that this can be done fairly easy and quickly.
> For more complicated TCs I see problems. But if they are 
> complicated, then I doubt they are always genereic. In such
> cases we can require them to just be done in some other
> document first.
> 
> And I think we can defend the idea that the IANA maintained
> TCs are good enough for documents at PS, DS and STD level.
> We can write that up in our initial document where we 
> set the rules for additions and an initial set of TCs.
> Maybe that initial doc should be BCP and it is OK to
> have a ref to a BCP from a DS or STD doc. And we can
> make it explicit that IETF has consensus and IESG approves
> that such an IANA MIB module can be referenced from PS,
> DS, STD.
> 
> See... I'd like to be practical and just DO it.
> 
> But if two of our core MIB doctors (Mike and Juergen)
> already have an issue with it... then we won't get far.

If there is consensus to proceed with this idea I certainly
won't stand in the way.  I don't object to having a "living list"
of useful TCs, or even (in principle) to doing all of our
standards in this way.  I just questioned whether _having the
IANA_ maintain these things is appropriate.  It somehow does
not seem like maintenance of registries of assigned names and
numbers, which is the IANA mission.

However, given the lack of action in newtrk in the last couple
of years, I can see the motivation for using a mechanism that
we have in place instead of waiting for years for something
to come out of newtrk, with the significant risk of coming up
empty-handed.

//cmh