[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Submission of <draft-ietf-ops-mib-review-guidelines-00.txt>
Colleagues,
As noted in a previous message, the Guidelines for MIB Authors and
Reviewers have (finally) submitted to the I-D repository under the
name <draft-ietf-ops-mib-review-guidelines-00.txt>. I want to thank
all of you who commented on the previous version and on the
fragments posted to this list; most of those comments (as well as
some that I picked up from other places) have been incorporated into
this draft. You'll find most of the changes documented in the
responses to those comments that I've attached below my signature
(that's why this message is so long). I've managed to keep most of
the section numbers from changing; the exceptions are the section
covering the IpAddress data type, which has been renumbered from
4.6.1.4 to 4.6.1.7, and the section covering "other" data types,
which has renumbered from 4.6.1.5 to 4.6.1.10. This was done to
make room for sections on all the primitive data types (except
Opaque) and some very basic TCs. Hopefully I did a better
pre-submission proofreading job this time and there will be fewer
typos and grammatical errors for you to catch.
The next steps that I'd like suggest -- subject to Bert's
approval -- are as follows:
1.) Since this guide is supposed to document what we look for in MIB
reviews, we should continue continue discussion on this list and
updating the draft until we get a document that accurately reflects
how we think MIB reviews should be done.
2.) Once milestone #1 is achieved, I think it would be appropriate
to have an open discussion and pseudo-WG last call on the
mibs@ops.ietf.org list, with document respins as needed.
3.) Once milestone #3 is achieved, submit the results to the IESG
for consideration as a BCP.
Bert, what do you think of this roadmap?
//cmh
--responses to comments follow--
On Fri, 6 Sep 2002 "Harrington, David" wrote:
> As SNMP is being more widely accepted, other standards bodies are
> creating their own mibs, and are not always following all the crappy
> little rules we define. I have recently run into mibs from other
> organizations with 0 sub-ids, so we need to be careful about relying
> on good OID-assignment behavior, and make sure the rationale behind
> any crappy little rules that would affect this are clearly and
> prominently documented.
Section 4.6.4 re-iterates the restrictions in RFC 2578 Section
7.10 as MUSTS (no final sub-OID of zero, no objects subordinate
to other objects except in tables).
On Fri, 8 Nov 2002 Dave Thaler wrote:
> Another point I make to the authors when reviewing their MIB
> if they have any objects with MAX-ACCESS of read-write or
> read-create... I make sure they understand that unless they
> use MIN-ACCESS in the conformance section, that implementations
> must support write access to be conformant. Often this is
> the right thing, but many authors/WGs are unaware of this.
> So I usually point it out so they can confirm this is what
> is intended, as many times it is not.
Agreed. The relevant text is in Section 4.8.
On Fri, 08 Nov 2002 Andy Bierman wrote:
> I read through the draft and it looks very good.
> There are probably some more style-guide type details to include.
> Here are a few I can think of now:
>
> DESCRIPTION clause for fooEntry:
> - should mention how the table is populated
> - if read-create, then do mgmt apps and agent both create rows?
> - if SPARSE-AUGMENTS, what is the sparse condition?
> - any external objects in the INDEX clause should be explained,
> wrt/ to any relationship to objects in this table
Agreed. The relevant text is in Section 4.6.3.
> DESCRIPTION clause for fooRowStatus
> - mention which objects (if any) have to be set to valid values
> before the row can be activated
> - mention if any cascading tables have to be populated with
> related entries before this entry is activated
Agreed. The relevant text is in Section 4.6.3.
> DESCRIPTION clause for StorageType objects
> - (from 2579) Every usage of this textual convention is required to
> specify the columnar objects which a permanent(4) row must
> at a minimum allow to be writable.
Agreed. The relevant text is in Section 4.6.3.
> Nits to check for:
> - Use of TimeTicks when TimeStamp is actually appropriate
> - Use of Counter32 when semantics not rigidly followed;
> should be Gauge32 or Unsigned32 instead
These considerations are covered in Sections 4.6.1.8 and 4.6.1.2.
On Sun, 10 Nov 2002, Dan Romascanu wrote:
> A couple of suggestions:
>
> 1. about the use of DESCRIPTION clauses - I encountered [too] many
> cases when the DESCRIPTION clause of stdMIBPoofpoofCounter is just
> 'Number of poofpoofs'. I think that a minimal explanation, or use of
> the optional REFERENCE clause to the definition of 'poofpoofs' should
> be RECOMMENDED.
Agreed. The newly-added Section 4.6.2, "DESCRIPTION and REFERENCE
clauses", contains text adapted from this comment.
> 2. RECOMMEND use of TruthValue, whenever it applies (could be an
> 'Other Types' item at 4.6.1.5)
Agreed. The relevant text is in the newly-added Section 4.6.1.9.
On Mon, 11 Nov 2002, Juergen Schoenwaelder wrote:
> Thanks for picking up this work. I believe such a document is highly
> useful. Below are some nits, comments and suggestions.
>
> 1. In the Introduction:
>
> "meet or exceed certain generally accepted standards of"
>
> I suggest to remove "or exceed" since it is hard to measure
> something that goes beyond what is generally accepted...
Done.
> 2. The RFC editor will love it if you cite standard numbers. So
> instead of writing
>
> "requirements of SMIv2 [RFC2578] ..."
>
> you may want to write
>
> "requirements of SMIv2, STD 58, [RFC2578] ..."
Done (but written as "requirements of SMIv2 (STD 58) [RFC2578] ...")
> 3. In section 3, you wrote that the narrative part MAY include a
> section that briefly describes the structure of the MIB module. I
> believe that this section SHOULD contain a description of the
> structure of the MIB module in terms of the conceptual structure.
> (as opposed to e.g. the OID tree which is rather unimportant for
> the first time reader and tools can easily generate them.) In
> fact, a good MIB should have an informal (information) model, see
> also draft-irtf-nmrg-im-dm-02.txt. I have run several times into
> documents with hundreds of pages of SMIv2 definition and basically
> no high-level description upfront, which is I think unacceptable.
Done: MAY was changed to SHOULD and grammatical errors were corrected.
> 4. Should we not simply include the boilerplate texts in this
> document? They do not change frequently and if they do, we have a
> good reason to revise and extend this document. ;-)
I don't agree. There should be one and only one authoritative source,
and this document should point to it. (Bert asks the same question
below and I give him the same answer. :)
> 5. Regarding copyright notices: It should be spelled out that the
> DESCRIPTION clause of the MODULE-IDENTITY clause should refer to
> the copyright statement in the RFC. Here is a template:
>
> Copyright (C) The Internet Society (2002). This version of
> this MIB module is part of RFC XXXX, see the RFC itself for
> full legal notices."
Done.
> 7. Should we have more guidelines on how to choose a good module
> name?
I've added text strongly recommending that module names be mnemonic
(there does not seem to be much else to say).
> 8. In section 4.5:
>
> Thus, a draft version of a MIB module MUST contain just one
> REVISION clause that covers all changes since the last published
> version (if any).
>
> While the text is OK, I think it could be made clearer by
> inserting "new" just before REVISION.
Done.
> 9. Using Gauge in an INDEX clause seems strange to me.
Following the lengthy discussion on the list, the text of Section
4.6.1.1 now recommends Unsigned32 in the general case, but says
that Gauge32 is appropriate when an index has gauge semantics.
There is more discussion on this below.
> 10. Do we want to say something about *Index TCs? I mean something
> like: If you have an Index which is likely to be used to refer to
> a table, please consider to introduce a *Index TC and another
> *IndexOrZero TC with the ranges ...
Text along these lines has been added to Section 4.6.1.1.
> 11. Similar to my comment 9, in section 4.6.1.3, I think that Gauge
> is not a generally aquivalent to an Unsigned. The second
> paragraph in this section is confusing for me.
The text in Section 4.6.1.3 has been changed to say that this TC should
be used when a 64-bit unsigned data type with gauge semantics is needed
and that a different TC based on Counter64 MUST be used if different
semantics are required.
> 12. Should we add guidelines for checking MIB module revisions? In
> particular, I request people who break SMIv2 rules (which
> sometimes makes sense after a cost/benefit analysis) that such
> things are well documented and explained in an SMIv2 comment.
These points are addressed in Section 4.9, "Revisions to MIB Modules".
The semantic change made to ifIndex in the transition from MIB-II to
the IF-MIB is cited as an example of a case where breaking the rules
was justified, and the explanation given in RFC 2863 is cited as an
example of how to document such a change (this is much better than an
ASN.1 comment, which is probably not sufficient in many cases).
The RFC1595 -> RFC2558 REVISION clause of the SONET-MIB documenting
raising MAX-ACCESS while adding MIN-ACCESS is cited as another example.
> Perhaps it would also be good to point people explicitely to tools
> such smidiff which can produce lists to check differences quickly.
smidiff is mentioned in Section 4.9 and also in Appendix B.
> 13. Appendix A:
>
> "review the actual technical for compliance"
>
> should be
>
> "review the actual technical content for compliance"
Fixed.
> 14. Appendix B:
>
> You can simplify your smilint examples to the following:
>
> smilint -l 6 -i namelen-32 <module>
The recommended command line has been changed to
smilint -m -s -l 9 -s -i namelength-32 <module>
Note the "-l 9" and not "-l 6" ... except for the 32-character
name stuff all warnings should be examined. In most cases any
warnings that appear SHOULD be fixed, although there are
legitimate exceptions in certain cases. I think Bert, at least,
agrees with this: in the recent discussion on the instructions
in http://www.ietf.org/ID-nits.html he stated:
"In fact I like it if people use -l 9 to check their MIB
Modules. They should look at the warnings and evaluate if
they are serious or not. Sometimes they are not serious and
easily fixable too ... so it would not hurt to just fix it."
This command line is the default for the smilint e-mail service
(which the appendix also mentions) so I guess that Frank agrees
with this too.
It is worth pointing out that smidiff does not at present honor
the switch "-i namelength-32" so I have mentioned that equivalent
results can be obtained by piping the merged stdout/stderr through
the command "grep -v 'name .* longer than 32 characters$'".
> 15. Acknowledgements:
>
> Instead of "XML guide" just write "guide" (I do not think that
> is relevant how we formatted this unpublished guide).
Done (and while I was at it, the many valuable comments received
from people on this mailing list have also been acknowledged).
On Tue, 12 Nov 2002 Andy Bierman wrote:
> I have some concerns about the smilint requirements.
> BTW, I use this tool all the time, and rely on it for Cisco
> MIB reviews. There are some warning messages that I don't
> usually fix, and some that I think smilint doesn't catch
> (but SMICng does catch).
That's been my experience too, and that's why checklist
item #9 (formerly #6) suggests using both compilers.
> I think we MUST fix errors ( < severity 5 ) and SHOULD
> fix warnings ( >= severity 5 ).
I have reworked the text of checklist item #9 (formerly #6)
to say that this is generally appropriate. I stopped short
of saying MUST because there are some level 4 messages that
are not really errors (the warning for 32-character names
that we routinely suppress is one of those).
On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote:
> - Say something about discontinuity timers
Section 4.6.1.2 already says "if it is possible for such
resets to occur, then a discontinuity indicator object
SHOULD be provided to indicate when the last such reset
occurred." Is more required? I didn't think so because
there is already a discussion of this in RFC 2578. So,
the resolution here was "no change".
> - Discuss if enumerations should start with zero
In accordance with the lengthy discussions on the list, text
covering this point has been added to Section 4.6.1.1 (just
after the integer-valued enumerations bullet list).
> - Same for BITS
Text to the effect that BITS enumerations MUST start at zero
and MUST be contiguous is present in the newly-added Section
4.6.1.6. This is a MUST because the SMI is very clear and
allows no leeway on this point (RFC 2578 Section 7.1.4).
> - say something about StorageType and the rule that one
> needs to specify which objects need write access for
> permanent rows
Section 4.6.3 now contains text stating that tables admitting
dynamic row creation by management apps must either specify
in the row object DESCRIPTION clause what happens to dynamically
created rows in case of an agent restart, or else must have a
StorageType column, and in the latter case there is text
re-iterating the RFC 2579 rule on permanent(4) rows.
> - say something about rowstatus and that it must explain [which]
> objects must be properly set before activation, and
> if objects can be changed if active
Agreed. The relevant text is in Section 4.6.3.
> - Might say something about not needing to support createAndWait?
I did not provide any discussion, but there is a syntax refinement
example in Section 4.8 (stolen from RFC 3289) that shows how to
write an OBJECT clause excusing an implementation from having
to support createAndWait but requiring it to support createAndGo.
> - Do we want to say something about a xxxReadOnlyCompliance vs
> or in addition to a xxxFullCompliance (see RFC3289 as example)
Agreed. The relevant text is in Section 4.8, and RFC 3289 is
cited as an example.
> - Do we want to say something about >128 subids. I think yes
Agreed. The relevant text is in Section 4.6.4, "OID Length
Limitations and Table Indexing".
> - Say something about NOT using IMPLIED ?
I don't remember why this was considered evil, and
I know that some people don't agree that it us.
Can someone refresh my memory? [OPEN]
> - You may want to check MIB related stuff on
> http://www.ietf.org/ID-nits.html
> In fact a ptr to that web page is generally useful
A pointer to http://www.ietf.org/ID-nits.html has been
added to Section 3. In a separate e-mail thread I have
already asked for correction of some of the MIB-related
stuff in http://www.ietf.org/ID-nits.html
> Now comments on the I-D
>
> - seems that sect 3.1 can probably reproduce the MIB boilerplate
> (once we agree) since it will be pretty short.
I disagree. There should be ONE authoritative source for the
boilerplate. This document, not being authoritative for the
boilerplate, should refer readers to the authoritative source.
> - sect 3.4
> Sometime bullet (C) must be produced.
I think that you mean bullet (D) [of RFC 2026 Section 10.4].
It deals with encumbered technology and contains a notice
that has to be included in the Intellectual Property Section if
proprietary rights are claimed with respect to the technology
described in the document. Text to that effect has been added.
> - sect 3.6
> The sensitivity of each (group of) object(s) needs to be
> explained and text needs to be there on how to address any
> security risks/concerns
I made a stab at rewording this section. If it is still
unsatisfactory please suggest suitable replacement text.
> - sect 3.8
> May want to add the recommended text from:
> http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt
Done (see response to Juergen's comment above).
> - sect 4.6.1.1
>
> Not sure that this is correct:
> - For integer-valued objects that are to be used as an index column:
>
> - Use of Unsigned32 or Gauge32 with a range that excludes 0 is
> RECOMMENDED. If 0 is included in the range, then a good reason
> MUST be specified.
>
> Do we allow Gauge32 (or does it make sense) as an index?
> Was that part of the input I provided?
The input that you provided did not actually say anything
about Gauge32. The text of Section 4.6.1.1 now recommends
Unsigned32 in the general case, but says that Gauge32 is
appropriate when an index has gauge semantics. There is
more discussion on this below.
> - Appendix B
> Frank/Juergen, any comments?
See responses to Frank (below) and Juergen (above).
> - appendix C
> - We have now RFC2578/9/80 instead of 1902/3/4
> So better use an example that has those.
> - I would like Dave Perkins to speak up (get involved) on what the
> best flags are [for] SMICng
The reason why rfc1902.inc, rfc1903.inc, and rfc1904.inc appear
in the include file is that the example was designed to work with
SMICng 2.2.07 (book version), and those files are what you get with
that version. The appendix notes that the sample include file was
prepared for SMICng 2.2.07 and may have to be changed somewhat to
work with later versions. If I receive more up-to-date information
from Dave Perkins I'll be happy to incorporate it.
On 6 Dec 2002, Frank Strauss wrote:
> Bert> - Appendix B
> Bert> Frank/Juergen, any comments?
>
> Just a small comment on the smilint usage: There is an option "-i" to
> make smilint ignore messages (see "smilint -e" for a list of messages)
> that contain a given substring, so the currently suggested pipe could
> be replaced by the following shorter command line:
>
> smilint -l 9 -s -i namelength-32 <module>
The recommended command line has been changed to
smilint -m -s -l 9 -s -i namelength-32 <module>
which is the default for the smilint email service (which the appendix
now describes).
On Fri, 6 Dec 2002 C. M. Heard wrote:
> [ ... ] there is one comment that I received from Dave Perkins
> that I'd like to get other opinions on:
>
> On Mon, 18 Nov 2002, David T. Perkins wrote:
> > [ ... ] there is that little item about importing
> > items used in MODULE-COMPLIANCE and AGENT-CAPABILITIES
> > that I very much disagree with.
>
> The item in question is this:
>
> Although exemptions to this general requirement are granted by RFC
> 2580 Sections 5.4.3 and 6.5.2 for names of objects appearing in the
> OBJECT clause of a MODULE-COMPLIANCE macro invocation or in the
> VARIATION clause of an AGENT-CAPABILITIES macro invocation, it is
> nonetheless RECOMMENDED by these guidelines that such symbols be
> included in the module's IMPORTS statement. There are two reasons
> for this. One is that these special rules are somewhat obscure and
> may not be implemented by all MIB compilers, especially since RFC
> 2580 has no analogous rules for names of notifications referenced
> by a VARIATION clause nor for names of object groups or notification
> groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or a
> SUPPORTS clause. The other reason is that including these items
> helps to make dependencies on other modules obvious from looking at
> the IMPORTS statement.
>
> The "general requirement" in questions is that if an external symbol
> other than a predefined ASN.1 type or the BITS construct is used,
> then it MUST be mentioned in the module's IMPORTS statement.
On Fri, 6 Dec 2002 Randy Presuhn replied:
> I think the RECOMMENDation is the right thing to do.
[ ... ]
> [ However, ] I believe the value in the RECOMMENDation is for
> humans, not compilers, despite the stated rationale, which
> I've already characterized as a red herring. Just try explaining
> to a human why no IMPORT is needed for items in a MODULE-COMPLIANCE
> or AGENT-CAPABILITIES construct, but is needed in the case of
> things like "modulename.typereference" Taking our quirky
> notation as a given, the least we can do is help people write
> more-or-less human-readable specifications using it.
On Fri, 6 Dec 2002 Juergen Schoenwaelder wrote:
> I agree with this statement. I believe that two simple rules should
> be followed:
>
> (a) All items that must be imported from other MIB modules should be
> imported in an IMPORTS clause.
>
> (b) If there is a name clash within a MIB module, the ambiguity is
> resolved by using the <Module>.<descriptor> notation instead of
> the <descriptor> notation.
The text of Section 4.4 was changed to state that although descriptors
of external objects, groups, and notifications referenced by compliance
and capabilities statements are granted exemptions (either de jure by
RFC 2580 or de facto by MIB compilers) from being listed in the IMPORTS
statement, these exemptions are sometimes seen as unhelpful, and so the
symbols in question MAY be included in the IMPORTS statement. This is
a compromise: it is intended to express the opinion of majority of us
who spoke up and think that the best course of action is to include
these symbols in the IMPORTS statement to make life easier for humans,
but the use of the neutral MAY (instead of SHOULD or RECOMMENDED) is
intended reflect the fact that we do not have a consensus on this point.
On Thu, 12 Dec 2002, Juergen Schoenwaelder wrote:
> >>>>> C M Heard writes:
>
> Mike> It would be better if we could get the mailer service to at
> Mike> least omit the namelength-32 warnings, which IMHO are just
> Mike> annoying noise. Thus, it would be nice if the default assumed
> Mike> by the mailer service could be "smilint -l 9 -s -i
> Mike> namelength-32".
>
> If there would be a document which says that the underlying SMIv2 rule
> is considered to be not important anymore, then I am happy to just
> remove this warning from smilint. (I am myself annoyed by it so I
> usually turn it off anyway. In fact, the -i option was added some time
> ago specifically to handle this case...)
>
> In other words, rather than spending time to write down how to tweak
> specific tools to not carefully check what is written down in the
> SMIv2 specs, I would prefer a sentence which says that there is
> consensus that this rule serves no purpose and then tools will just
> get changed.
The text in Section 4.2 has been changed to convey this message.
On Fri, 20 Dec 2002 "Wijnen, Bert (Bert)" wrote:
> For RFC2493bis I would also like
>
> - change year format for revision date
> that is change
> REVISION "9811071100Z"
> into
> REVISION "199811071100Z"
> - I would rather see WG mailing list info than charter page info
> WG charter page may go away when WG shuts down, mailing list
> often stays around much longer
>
> For RFC2558bis I would also like
>
> - Update MIB boiler-plate to latest version, now that new SNMPv3 RFCs
> have been published. New revision of boilerplate (much shorter by
> the way) is at: http://www.ops.ietf.org/mib-boilerplate.html
> - make (old) REVISION dates to use 4-digit year notation (as also
> stated above for rfc2493bis)
> - It would be good to add WG charter mailing list info
A paragraph has been added to Section 4.5 stating that four-digit
years SHOULD be used in the Extended UTCTime dates in the LAST-UPDATED
and REVISION clauses of a MODULE-IDENTITY invocation.
On Sat, 28 Dec 2002 Bert Wijnen wrote:
> > 2) DoS attacks (as described in some of the ADSL MIBs'
> > security considerations sections) based on the
> > conditions under which notifications are generated.
> >
> Mmm... I wonder... in the end it depends on
> - having proper access control to those objects that control/limit
> the sending of notifications (for example access to the tables in
> RFC3413).
> - ensuring that no notification flooding will take place.
> That I guess depends on proper mib design and the MIB doctors should
> be looking for such issues. I don't think it is OK to just say that
> DoS attacks are possible. Better to build in controls to prevent it.
There is now text in 4.7 to the effect that notifications which can
be generated by rapidly changing external conditions SHOULD have a
rate-limiting mechanism in order to avoid overwhelming the network
with floods of notifications. RFC 2108/RFC 2737 are cited as examples.
On Sat, 4 Jan 2003 Bert Wijnen wrote:
> [C. M. Heard wrote:]
> > [Randy Presuhn wrote:]
> > > [C. M. Heard wrote:]
> > > > [Randy Presuhn wrote:]
> > > > [C. M. Heard wrote:]
> > > > > ...
> > > > > > The above is a direct translation of the INDEX rules in RFC
> > > > > > 2578 Section 7.7 up to and including bullet (1). Although
> > > > > > not forbidden by RFC 2578, using objects of type Gauge32 in
> > > > > > an INDEX clause is NOT RECOMMENDED under these guidelines.
> > > > > ...
> > > > >
> > > > > What is so dangerous about the use of Gauge32 as an
> > > > > index that it should warrant a "NOT RECOMMENDED"?
> > > >
> > > > The original text treated Gauge32 and Unsigned32 as synonymous,
> > > > and both Juergen and Bert voiced objections on the grounds
> > > > that the special semantics attached to Gauge32 make it an
> > > > inappropriate SYNTAX for a variable that appears in an INDEX
> > > > clause. That is, it was perceived as something that you SHOULD
> > > > NOT do. I had to agree with that, because I can't think of a
> > > > situation where I would want to use Gauge32 in an INDEX clause
> > > > other than in a MIB module that was translated from SMIv1.
> > >
> > > Reasoning like this led to the unfortunate situation
> > > with 64-bit integers. We shouldn't use our lack of
> > > imagination as the reason for a prohibition. When
> > > someone *does* come up with a reason to want to do it,
> > > we'll be guilty of yet another CLR.
> >
> [ ... ]
> >
> > I'm convinced. I've rewritten the text in question as follows:
> >
> > - For integer-valued objects that appear in an INDEX clause or for
> > integer-valued TCs that are to be used in an index column:
> >
> > - Use of Unsigned32 with a range that excludes 0 is RECOMMENDED,
> > provided that the object in question does not have gauge
> > semantics. If 0 is included in the range, then a good reason
> > MUST be specified.
> >
> > - Integer32 or INTEGER with a non-negative range is acceptable.
> > Again, if 0 is included in the range, then a good reason MUST
> > be specified.
> >
> > - Use of Gauge32 is appropriate for index objects that have gauge
> > semantics.
> >
> > The above is a direct translation of the INDEX rules in RFC 2578
> > Section 7.7 up to and including bullet (1) plus the penultimate
> > paragraph on page 28.
>
> I asked Keith what he thinks about this (Keith was one of the
> 3 STD58 editors) that I checked with when I came up with
> my guidelines that Mike used as a basis for the initial
> draft. Here is his response.
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: vrijdag 3 januari 2003 16:56
> To: bwijnen@lucent.com
> Cc: kzm@cisco.com
> Subject: Re: FW: Gauge32 as an INDEX (was: Index values of zero)
>
>
> > Any opinion?
>
> On Gauge32, I agree with Randy. Using a Gauge32 as an auxiliary
> object is a matter of MIB design; it may be bad in some/most cases,
> but that doesn't necessarily mean it's always bad.
>
> As for 0, I think "a good reason MUST be specified" is bogus; where
> must it be specified ? and who decides whether it's good or not ??
> If someone does use 0, they presumably have a reason which they think
> is a good reason, and if they specify it in private, then they have
> complied with this rule. Thus, all the rule really means is that the
> index value of 0 shouldn't be used arbitrarily, which I think is
> already better expressed in the SMI as:
> ... The use of zero as
> a value for an integer-valued index object should be avoided, except
> in special cases.
>
> If there's anything lacking in that sentence from the SMI, it's that
> there are two types of special cases:
>
> 1. when 0 is semantically meaningful (e.g., a temperature of 0, or
> an IP-address of 0.0.0.0)
> 2. when 0 has a special meaning (e.g., InterfaceIndexOrZero).
Keith's elaboration is now included in the part of Section 4.6.1.1
dealing with the selection of data types for index objects, in
accordance with discussions on the mailing list.
On Fri, 17 Jan 2003, C. M. Heard wrote:
> The SMIv2 documents explicitly permit the labels assigned to
> enumerations in INTEGER or BITS types to be changed when a
> MIB module is revised:
[ ... ]
> Unfortunately, such revisions have the potential to cause backward
> compatibility problems. Consider the following:
>
[ snip example showing module that imports a TC based on enumerated ]
[ INTEGER to define an object with a DEFVAL clause, which becomes ]
[ invalid when the label is changed in the module that defines the TC ]
>
> ./ELEVATOR-MANAGEMENT:20: [2] {defval-syntax} default value syntax
> does not match object syntax
> ./ELEVATOR-MANAGEMENT:20: [2] {defval-enum} default value does not
> match underlying enumeration type
>
> The same type of problem can result from modifying labels in
> OBJECT-TYPES, because a VARIATION clause in an AGENT-CAPABILITIES
> statement can specify a DEFVAL for an object with enumerated INTEGER
> SYNTAX and be undermined in precisely the same way. And since the
> labels are in DEFVALs for objects with BITS SYNTAX, the same problem
> can arise from modifying labels associated with bit positions, too.
>
> I think it was a mistake for the SMIv2 documents to allow labels
> associated with existing enumerations and bit positions to be
> changed when a MIB module is revised. Indeed, I would go so far as
> to call this a bug in the SMIv2 documents, because they go out of
> their way to ban similar changes that break backward compatibility --
> in particular, changes to descriptors of objects and notifications
> are classified as semantic change and is not allowed because those
> descriptors can be used in an IMPORTS statement in another module.
Section 4.9, "Revisions to MIB Modules", states that enumerated
INTEGER and BITS labels MUST NOT be changed in IETF MIB modules
and SHOULD NOT be changed in enterprise MIB modules.
On Mon, 20 Jan 2003 David Harrington wrote:
> section 4.3 talks about "standard" objects being under
> { iso 3 6 1 2 }. I will point out that that subtree is for IETF
> standard objects. Other organizations, such as IEEE also produce
> standards, and they can assign them under their own "standard"
> branches that apparently are not under IANA control.
The paragraph in question now makes it explicit that the
{ iso 3 6 1 2 } branch is for IETF "standard" objects.
> Paragraph two of that section says "Experience has shown that is
> impractical objects from one subtree to another once those objects
> have seen ..." - dat ain't good English.
Fixed.
> section 4.5 mentions transmission, but doesn't provide the OID for
> transmission of from which mib it should be imported.
Added reference to [RFC2578] for both mib-2 and transmission.
> section 4.5 "under under"
Fixed.
> 4.6.1.1 "is a direct translation the definitions" is missing an "of"
This is now moot -- the "direct translation" language is no longer
present following the reworking of this section to include Keith
McCloghrie' elaboration (see above).
> 4.6.1.2 "there is a requirement MUST reset" needs extra words.
Fixed.
> 4.6.1.3 "that that objects"
Fixed.
> Appendix A: "maintanance" s/b maintenance
Fixed.
> "review the actual technical for" is missing "content"
Fixed.
> Informative References: need to be updated to the RFC341x documents.
Fixed.
> Informative References: the formatting of [RFC2863] needs to be fixed.
Fixed, and moved to Normative References.
On Tue, 28 Jan 2003, Wijnen, Bert (Bert) wrote:
> I have (this was a while ago) checked with the 3 editors
> of SMIv2 (STD 58) documents and back then they basically
> had rough consensus that this was allowed. I must admit that
> Dave Perkins had some objections... and his SMICng still
> complains about it. For all I remember he promised me to
> fix it, or at least make it controllable with a switch.
> smilint accepts it as far as I know.
>
> In any event, this is what I have been telling MIB authors
> for some 2 years now I think.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: C. M. Heard [mailto:heard@pobox.com]
> > Sent: dinsdag 28 januari 2003 22:21
> > To: Mreview (E-mail)
> > Subject: Re: Anyone wants to do a double check on an IPCDN mib?
> >
[ ... ]
> >
> > I'm not going to do a complete review, however, I do have
> > one question: have we settled whether this is going to
> > be considered legal syntax
> >
> > OBJECT docsSubMgtCpeIpAddressType
> > SYNTAX InetAddressType { ipv4(1) }
> > DESCRIPTION
> > "An implementation is only required to support IPv4
> > addresses."
> >
> > even though RFC 2578/2579/2580 (through provisions incorporated
> > from ISO 8824) apparently DO NOT allow it?
> >
> > I need an answer, and a justification for the answer, to
> > incorporate in the MIB reviewer's guide. As I said the
> > last time I asked this question, a pointer to a definitive
> > public discussion of the issue is OK; I looked but did not
> > find one.
> >
> > Thanks,
> >
> > //cmh
Since it seems that the consensus of the MIB doctors is that the
guidelines should say that this usage is OK, there is a note at the
end of Section 4.8 with text to this effect, but it warns that some
MIB compilers do not accept that usage and says that using the
base type in a refinement, as is done in the IF-MIB, is acceptable.
On Fri, 31 Jan 2003 Bert Wijnen wrote:
> W.r.t.
> > 11.) I notice that ranges have been added to ipForwardPolicy and
> > ipCidrRouteTos index variables to ensure that they are non-negative.
> > That's not actually required by the SMI, and, strictly speaking,
> > it is not a legal revision. It is probably acceptable since it
> > cannot possibly change anything on the wire, but another solution
> > would be to leave these as-is and turn off the the strict checking
> > in your SMICng include file (#removeOpt "B").
> >
> I have been encouraging people to add ranges to index objects when/if
> they make sense. And I think in this case they do make sense.
> As you say, strictly once cannot make such a change.
> But also, strictly, a negative index is not allowed.
There is a "clarification" in Section 4.9 that this should be
treated by reviewers as an editorial change, since it can't affect
backward compatibility (either over the wire or with MIB modules
that import the object). One can argue, I think, that this is in
line with both the intent and the wording of the last paragraph in
RFC 2578 Section 10.2:
Otherwise, if the semantics of any previously defined object are
changed (i.e., if a non-editorial change is made to any clause other
than those specifically allowed above), then the OBJECT IDENTIFIER
value associated with that object must also be changed.
On Fri, 31 Jan 2003 Mike Heard wrote:
> The checklist is incomplete -- many of the "mechanical" steps in a
> review are not spelled out.
The checklist in Appendix C has been expanded to make explicit all of
the more-or-less "mechanical" steps in a MIB review.