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

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

This touches a nerve for me...

<rant>
This is essentially the same argument that derailed the IETF last call
of the language tag registry update last year.  The result was the formation
of a working group to painfully re-hash the discussion, and eventually produce
essentially the same document, though with a host of minor tweaks.  This is a
process, complete with threats of appeal, I would not wish on anyone.
Do we *really* want to duplicate it here?

Whether one puts an official "Updates" on it or not, the reality is that
RFC 4181 does indeed affect how MIBs get done, and marks a significant
advance over the way things were prior to its development.  I'd hate to
see all the work that went into it wasted while a WG goes through a make-
work project it re-writing it.
</rant>

Randy

----- Original Message ----- 
From: "David B Harrington" <dbharrington@comcast.net>
To: "'C. M. Heard'" <heard@pobox.com>; "'Mreview (E-mail)'" <mreview@ops.ietf.org>
Cc: "'Alfred HÎnes'" <ah@tr-sys.de>
Sent: Monday, October 24, 2005 11:43 AM
Subject: RE: RFC 4181 indeed updates RFC 2578..2580 (fwd)


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?

David Harrington
dbharrington@comcast.net

> -----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
>
>
>