[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Time to Revise the TC list



Inline

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1@hardakers.net]
> Sent: Thursday, May 04, 2006 18:15
> To: Wijnen, Bert (Bert)
> Cc: Romascanu, Dan (Dan); Mreview (E-mail); ietfmibs@ops.ietf.org
> Subject: Re: Time to Revise the TC list
> 
> 
> >>>>> On Thu, 4 May 2006 17:29:19 +0200 , "Wijnen, Bert 
> (Bert)" <bwijnen@lucent.com> said:
> 
> Bert> Not having heard much more on the below emails, I have now
> Bert> updated http://www.ops.ietf.org/mib-common-tcs.html
> Bert> with the following additional TCs.:
> 
> I think it's important to put a piece of text in the page that
> discusses what happens when a RFC with a MIB in it references another
> RFC's MIB.  Specifically, that when an RFC is ready to advance and
> it's waiting on TCs found in another MIB.
> 

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.

> 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).
- 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.

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

Bert