RE: Time to Revise the TC list

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

On Fri, 5 May 2006, Wijnen, Bert (Bert) wrote:
> I am not sure it is good to include IETF process-related text on the
> page that points out the Common/Generic TCs. 
> What may make sense is to include the status of each document, so I
> could do:
>    The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411, STD]:
> and
>    The following TCs are defined in HCNUM-TC [RFC2856, PS]:
> 
> and so on. Let me know if people thinks that such would be helpful.

That's probably a good idea.

> [Wes Hardaker wrote:]
> > I believe the current accepted solution is that the RFC won't be able
> > to advance without splitting out the TCs into a separate document and
> > advancing that as well.  What I don't remember is if the new split-out
> > MIB needs to go to proposed first or whether it could skip to draft.
> 
> Here are my thoughts:
> - many MIB documents have no plan to ever advance further than PS.
>   so for those (the most of our MIB documents) it is moot
> - my personal take is that if TCs get taken out (unchanged) to a 
>   separate document, that it would be acceptable to advance that to
>   the next level on standards track (assuming the TCs meet the
>   requirments for advancement).

If the TCs live by themselves in a separate MIB module -- which is
often, but not always the case -- then I agree with this.  However,
TCs that reside in a MIB module with other definitions cannot be
moved into another MIB module, since that would break MIB modules
that import those TCs.  So it's not possible to split such TCs out
into a separate document.

> - It is (in my view) ALLWAYS possible to take a copy (renamed) of any
>   TC and include it in a document that wants to advance and then
>   use the renamed TC. It means no semantic change of any object and
>   it means no change on the wire.

Technically true, but historically we've discouraged people from doing
this, because we don't like people reinventing the wheel.  I think that's
the right policy, but it does point out one way that the standards track
is broken.  (The newtrk WG is chartered to fix such problems, but has
not made much progress.)

> But again, I don't think this type of text should be put on that 
> web pages of Common/Generic TCs.

Agreed.

//cmh