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

["David B Harrington" <dbharrington@comcast.net>]

Hi,

I'm not suggesting creating such a WG. 

I'm saying publish it as a BCP, and apply the guidelines when doing
MIB Doctor reviews. As you say, the reality is that these guidelines
will improve MIB development, whether it officially "Updates"
RFC2578-80 or not. I don't see the need to have it officially Update
RFCs 2578-80.

If we do have it officially update RFCs2578-80, do we need to update
the MIB boilerplate to reflect this? Do all MIB modules currently
under development for IETF standards-track need to update their
boilerplates to match, etc.?

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Randy Presuhn
> Sent: Monday, October 24, 2005 3:30 PM
> To: 'Mreview (E-mail)'
> Subject: Re: RFC 4181 indeed updates RFC 2578..2580 (fwd)
> 
> 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
> >
> >
> >
> 
> 
> 
> 
> 
>