RE: Alternative Procedure for updating MIB Modules

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Sorry to have to come back to this. But this has been lingering
and I would prefer to finish/close this one.

I have included some changes based on the discussion we have had.

I also want to get IESG to approve this as a new
"procedure being tested" as opposed to fully approved procedure.
This to allow us to first get some experience before we make it final
(if ever). To that effect I have added text that I want MIB doctor review
before we accept that a document uses the alternative procedure.

Hope this is acceptable as such a "procedure being tested"

By the way, I see that the ADSLMIB WG has not followed through using this
alternative procedure. So this is currently not "urgenT", yet I'd rather
have the procedure in place if it comes up again.

Thanks, Bert


---------------

Alternative procedure being tested for updating MIB modules 

The normal process for updating a MIB module is to create an
internet draft that contains the new/updated MIB module.
Such an internet draft, when published as RFC, will then 
obsolete an earlier RFC. For example, RFC 2863 (IF-MIB module)
obsoletes RFC 2233.

But in some cases, there are just very small changes or additions
to a specific MIB module. It would waste a lot of pages of RFC text
if one needs to repeat the whole MIB module in order to just make
a few small changes. 

There are also cases where a MIB module may already be at Draft 
Standard (DS) or at Internet Standard (STD) when new additions
to the MIB module will cause a restart at Proposed Standard. 
In such cases it would be good to keep the DS or STD level MIB
document untouched and do a new document with just updates and
starting that at Proposed Standard (PS).

So, as an altenative procedure, we are tesing a procedure by which
one can create a short internet draft that describes the few 
updates/additions to the MIB Module. The changes to the MIB module 
itself can then be provided in a separate MIB module. The way to 
do so is to have a ptr in the internet draft in the form of (if 
your I-D is named draft-ietf-wgname-somename-nn.txt):

  For convenience, an updated MIB module containing these (changed/new) 
  objects may be found at:
  http://www.ietf.org/internet-drafts/draft-ietf-wgname-somename-nn-modulename.mib

  Note to RFC-Editor:
       above MIB mdoule to be moved and link in this document to be
       updated to RFC-Editor location
              ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/ 
       when RFC-is published.

When you submit the internet-draft, you must at the same time submit the
MIB module and explicitly request internte-drafts@ietf.org to post
the MIB module in the I-D repository as well. Pls refer to this
procedure.

An example of a RFC that has followed this method is RFC 3273, page 6.

When this procedure is followed for a MIB module (as published in
an RFC) has already advanced to DS or STD, the new RFC will have to
start at PS of course. By the time the new RFC comes to the same level
of standardization (certainly at STD level) it MUST be merged into
the full MIB module again and should then obsolete bot the orginal
MIB document (RFC at DS or STD) plus the new RFC that came up to the
same standards level.

Since this procedure is under test, a MIB Doctors review needs to give
its OK to follow this alternative procedure first.