-----Original Message-----
From: owner-mreview at ops.ietf.org
[mailto:owner-mreview at ops.ietf.org] On Behalf Of C. M. Heard
Sent: Monday, October 24, 2005 11:04 AM
To: Mreview (E-mail)
Cc: Alfred HÎnes
Subject: RE: RFC 4181 indeed updates RFC 2578..2580 (fwd)
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