RE: RFC 4181 indeed updates RFC 2578..2580 (fwd)

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

On Sat, 22 Oct 2005, Wijnen, Bert (Bert) wrote:
> If we want to do anything we should create the exact and complete list
> of what we are altering. Note that if something that is OK in STD58 
> and is still OK/ACCEPTABLE (although maybe not recommended or prefered
> by RFC4181), then we (MIB doctors) can strongly advise a WG to follow
> the recommendations of 4181, but I doubt we can block a document for
> that. So I am somewhat hesitant to tag 4181 with a "Updates STD58"
> because it makes the "guidelines" a "hard rules" as opposed to 
> guidelines. I think we intended the last (namely guidelines). I do
> see that at a few places we may be saying that we are in fact 
> changing a rule.

Obviously, the "General Documentation Guidelines" in Section 3 don't
have anything to do with RFCs 2578/2579/2580 so we can focus attention
on Section 4, which says:

   The guidelines in this section are intended to supplement the SMIv2
   documents in the following ways:

    o to document the current generally accepted interpretation when
      those documents contain ambiguities or contradictions;

    o to update recommendations in those documents that have been shown
      by practical experience to be out-of-date or otherwise suboptimal;

    o to provide guidance in selection of SMIv2 options in cases where
      there is a consensus on a preferred approach.

The first two bullets are clearly things that could be considered as
updating the SMIv2 RFCs, although there is precedent for not
considering ambiguity resolution as a specification update (for
instance RFC 1122 is not listed as updating RFCs 791 and 792, even
though it has text to clear up many ambiguities in those
specifications).  The last bullet covers usage guidelines, and I
tend to agree with Bert that since those are guidelines and not
hard-and-fast requirements they need not be considered updating to
the SMIv2 RFCs.

Here is a list of things I've found in RFC 4181 that either update a
recommendation or document and resolve a contradiction in the SMIv2
RFCs.  The list seems pretty short;  it is possible that I've
overlooked something.

- Section 4.2 abolishes the recommendation in RFCs 2579 and 2579
that names be limited to 32 characters.  It does not alter the
requirement that names be limited to 64 characters, so the critera
for syntactic validity remain unchanged.

- Section 4.6.1.2 abolishes the requirement that RFC 2578 imposes on
"standard" MIB modules that the Counter64 type may be used only if
the information being modelled would wrap in less than one hour if
the Counter32 type was used instead.

- Section 4.9 resolves contradictions between the general rule that
MIB moudule revisions shall not make semantic changes to existing
definitions and the specific lists of changes that RFC 2580 allows
to be made to compliance statements and capabilities statements.

HOWEVER, this is not the whole story.

After re-reading the document it becomes clear that RFC 4181 Section
4 supplements the SMIv2 documents in at least one other way that
those stated:  in some cases content requirements are imposed on
IETF MIB modules that go beyond the minimal requirements of correct
syntax specified in the STD 58 documents.  One example is Section
4.5 on the usage of the MODULE-IDENTITY macro.  It says:

   RFC 2578 Section 5 describes how the various clauses are used.  The
   following additional guidelines apply to all MIB modules over which
   the IETF has change control:

Another example is the following from Section 4.6.4:

   - If dynamic row creation and/or deletion by management applications
     is supported, then:
   [ ... ]
     - There either MUST be one columnar object with a SYNTAX value of
       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
       else the row object (table entry) DESCRIPTION clause MUST specify
       what happens to dynamically-created rows after an agent restart.

     - If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause.

Should these things be considered as updating the STD 58 RFCs?  Or is
the situation something like the Host Requirements documents (RFCs
1122/1123, STD 3), which specify requirements for hosts that are in
addition to the basic requirements of the underlying protocols?

Mike