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

["C. M. Heard" <heard@pobox.com>]

>>>>> On Mon, 24 Oct 2005, C. M. Heard wrote:
cmh> On Mon, 24 Oct 2005, David B Harrington wrote:
cmh> > As I contributed to the development of the mib guidelines, I
cmh> > thought we were producing guidelines to help people, not new
cmh> > rules to hit them over the head with.
cmh> 
cmh> Just out of curiousity, do you consider things like this:
cmh> 
cmh> |   - If dynamic row creation and/or deletion by management applications
cmh> |     is supported, then:
cmh> |   [ ... ]
cmh> |     - There either MUST be one columnar object with a SYNTAX value of
cmh> |       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
cmh> |       else the row object (table entry) DESCRIPTION clause MUST specify
cmh> |       what happens to dynamically-created rows after an agent restart.
cmh> |
cmh> |     - If the agent itself may also create and/or delete rows, then the
cmh> |       conditions under which this can occur MUST be clearly documented
cmh> |       in the row object DESCRIPTION clause.
cmh> 
cmh> to be "new  rules to hit them over the head with" or something than helps
cmh> people?  The rules cited above are (a) above and beyond the requirements
cmh> of RFCs 2678/2579/2580, (b) sometimes painful for writers of MIB modules
cmh> (and possibly for agent implementors as well), but (c) it should make life
cmh> a whole lot easier for the writers of management applications.

>>>>> On Mon, 24 Oct 2005, David B Harrington wrote:
dbh> I view this as a CLR.
dbh> 
dbh> I can accept this CLR as a BCP guideline that SHOULD be followed to
dbh> help improve interoperability between agent implementations and
dbh> management applications. If we make this an Update to a STD, and
dbh> enforce it as if it were a STD, then it is something to hit people
dbh> over the head with. We already have enough CLR-hammers; we don't need
dbh> more.
dbh> 
dbh> Here's a question for you - how will making this an official update
dbh> improve my ability to manage a network, as compared to this being just
dbh> BCP guidelines applied during MIB Doctor reviews? 
dbh> 
dbh> I suspect the answer is "It would give us a bigger hammer." If these
dbh> are just guidelines, then WGs and WG chairs can argue with the MIB
dbh> Doctors that it doesn't apply in certain circumstances; if we Update
dbh> the STD, WGs and WG chairs are denied that privilege. The IETF has not
dbh> given us the right to make that change in process.

<sidebar>
I wish that people would not use the term CLR (which means "crappy little
rule") for something that they apparently think is actually  useful, as
you seem to in this case ... it would not be acceptable as a SHOULD, if
it were not useful, would it?  And if it's useful, why call it crappy?
</sidebar>

Oh well, getting to the substance of your objection, your position seems
to be that nothing in the "SMIv2 usage guidelines" part of the MIB review
guidelines document should be a MUST unless it's actually required by
STD 58.  The example above certainly violates that condition.  And the
present reality is that it is effectively a blocking issue ... if a MIB
module comes from an IETF WG without specifying whether dynamically
created objects survive a reboot, than either the MIB Doctor will ask
for that to be fixed, or the AD will.

It's too bad that this didn't come out when the document was last-called.

>>>>>> In a subsequent message, David B Harrington wrote:
dbh> I'm saying publish it as a BCP, and apply the guidelines when doing
dbh> MIB Doctor reviews. As you say, the reality is that these guidelines
dbh> will improve MIB development, whether it officially "Updates"
dbh> RFC2578-80 or not.

I thought we already did that.

dbh> I don't see the need to have it officially Update
dbh> RFCs 2578-80.

Fine with me.

//cmh