Hi,
As I contributed to the development of the mib guidelines, I thought
we were producing guidelines to help people, not new rules to hit them
over the head with.
RFCs 2578-2580 were developed by a working group, following
appropriate IETF procedures for developing new standards-track RFCs,
notably those procedures documented in RFC2026, section 6.2.
The mib guidelines were developed by the MIB Doctors, a closed group,
following a process that was consistent with BCP procedures, but not
consistent with IETF procedures for developing new standards-track
RFCs.
Therefore, I object to the mib guidelines, a BCP document, being
considered an official update to the SMIv2 STD rules, and I object to
enforcement of the new MUST requirements in the mib guidelines, since
those requirements can have a serious impact on implementers, who have
not had the opportunity to debate the proposals in an open working
group, and test the proposed and draft standards, as afforded by the
three-phase standards-development process.
Is that a solid-enough opinion on the topic?
-----Original Message-----
From: owner-mreview@ops.ietf.org
[mailto:owner-mreview@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