RE: Time to Revise the TC list

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

NOTE: I believe the current process of not allowing TCs to
be moved (or other definitions to be moved) is really broken.

I put in some support in SMICng to deal with this. I believe
that other MIB parsers should be also able to support movement.
This should be supported by the addition of MIB parser directives
to the MIB module language. 

Regards,
/david t. perkins

On Fri, 5 May 2006, C. M. Heard wrote:
> 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
> 
>