Re: Alternative procedure for updating MIB modules

[Andy Bierman <abierman@cisco.com>]

At 07:16 AM 5/17/2004, Wijnen, Bert (Bert) wrote:
>MIB doctors. We have done this in the past with the two 
>rmon MIB modules. Currently the ADSLMIB is following the 
>same procedure. 
>
>I am trying to writeup the procedure (for the IESG secretariat)
>for this alternative procedure. I will discuss it in IESG also
>to get IESG consensus on this procedure.
>
>Pls check my wording below and let me know if you agree or if
>you have any concerns or possibly better wording.

I don't think we know how to define metrics to measure
the "confusion factor" caused by this procedure.  The
RMON-2 enums are the only case I know about.  Here's the current
situation:

  - HC-RMON (RFC 3273, sec. 3) includes enum updates to RMON (STD 59)
    and RMON2 (RFC 2021).  
    Pros:
       - It is clear to the HC-RMON developer what needs to be done
         to add HC TopN report capability to RMON and RMON2.
       - HC stuff is related only to HC-RMON document and does not
         impact conformance or semantics of existing RMON and RMON2
         whatsoever (IMO, prerequisite for this delta approach)
       - STD 59 did not have to be republished to add the HC-related
         enums
       - The updated modules are available (FTP) so authors do not
         have to patch these MIB modules themselves
    Cons:
       - RFC 3273 doesn't have the normative version of these 
         *TopNControlRateBase objects.  Neither does the FTP version.
         (Yet, section 3 of RFC 3273 is normative -- oops.)
         It just so happens that RMON2 is about to be republished.
         The update <draft-ietf-rmonmib-rmon2-v2-01.txt> contains all 
         the HC enums.  Soon all the 'RMON2' related text in RFC 3273 
         (and the FTP version rmon2.mib) will be obsolete.  IMO, this
         will cause some confusion.
       - This approach doesn't scale at all.  I don't even think N=2
         is manageable.

IMO, the ability to add enumerations over time to an object or TC is
mandatory to support an evolving MIB base.  We need to adjust
the SMI, or the CLRs, or whatever, so the standards process
doesn't get in the way of this requirement.
        

>Thanks,
>Bert 

Andy


>----------------
>
>Alternative procedure 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. 
>
>So, as an altenative procedure, 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.
>
>An example of a RFC that has followed this method is RFC 3273, page 6.
>
>This procedure can also be followed if some 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 might be better to
>include the full MIB module again. However, the above procedure also
>works and is acceptable.