Re: [MIB-DOCTORS] [OPS-AREA] FW: IESG Statement on Copyright

["C. M. Heard" <[e-mail]>]

+1 also (though I really don't have a stake in the outcome).

One of the things that should probably be discussed is whether the 
issues brought up in the attached e-mail (downgrading some of the 
MUSTSs to SHOULDs) should be addressed under the head of bug fixes.

//cmh

On Wed, 23 Sep 2009, David B Harrington wrote:
> +1 
> dbh 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Juergen 
> > Schoenwaelder
> > Sent: Wednesday, September 23, 2009 5:22 AM
> > To: Romascanu, Dan (Dan)
> > Cc: C. M. Heard; MIB Doctors (E-mail); OPS Area (E-mail)
> > Subject: Re: [MIB-DOCTORS] [OPS-AREA] FW: IESG Statement on Copyright
> > 
> > On Wed, Sep 23, 2009 at 10:14:46AM +0200, Romascanu, Dan (Dan) wrote:
> > > I have some good news to share. Randy Presuhn stepped ahead and accepted
> > > to be the editor of 4181bis. Thanks, Randy!
> > > 
> > > I have two questions: 
> > > 
> > > 1. OPSAWG (which did not exist by the time 4181 was edited and
> > > published) seems to me to be the natural home for 4181bis.  Does anybody
> > > see any problem with this? If all agree we shall move discussions to
> > > [e-mail]
> > > 
> > > 2.  What should be the scope of 4181bis? 
> > 
> > Bug fixes and alignment to current IETF procedures and rules (although
> > the last thing might be an endless undertaking ;-). As little rewrite
> > as possible if you ask me.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> > 
> 

--- Begin Message ---

David B Harrington wrote:

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

I agree with you.  I don't care as much about SNMP as I used to,
but from a process POV, it is better to make these guidelines SHOULD
instead of MUST, especially en masse.  IMO, MUST should be reserved
for when it would cause "obvious harm to interoperability" to do otherwise.
MIB style guidelines have a minimal impact (at best) on interoperability.
(Perhaps SHOULD is even too strong for some guidelines, but MAY is
too weak. Oh well.)

>David Harrington
>[e-mail]
>

Andy

>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] 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
>>
>

--- End Message ---