[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Submission of <draft-ietf-ops-mib-review-guidelines-00.txt>
Now on to the comments on how you handled discussions
Only those where I have still concerns...
> On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote:
> > - Say something about discontinuity timers
> Section 184.108.40.206 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".
The current text seems to focus on the RESET (to zero?)...
In general, one of the most encountered problems with counters
is that it is not clear which discontinuity timer is used.
By default that then means sysUpTime, and if the system were
to indeed reset sysUpTime for some random counter discontinuity,
then a lot of counters are to be considered to have experienced
a discontinuity (since tso many default to sysUpTime).
So I feel that a bit more of a warning/focus/ and a
check-by-mib-doctors is justified
> > - 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]
4.1.36 Deprecate Use of IMPLIED Keyword
Description: The SMIng SNMP mapping must deprecate the use of the
IMPLIED indexing schema.
Motivation: IMPLIED is confusing and most people don't understand it.
The solution (IMPLIED) is worse than the problem it is trying to
solve and therefore for the sake of simplicity, the use of IMPLIED
should be deprecated.
> > - 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
It is much better already. How about adding:
If there are no risks/vulnerabilities at all in a specific
category, then please do state that. Then at least we can
see that you did think about it and that you claim that there
are no risks/vulnerabilities. Just copying the text is not good.
You should think and evaluate the risks/vulnerabilies and then
state/document the result of your evaluation.
I have seen too many people who just copied the guideline text
without even thinking about it.
> > - 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.
Mmmm.. so I now understand why you did it. The risk we run is that
people will potentially copy this... I'd rather see us do an up to
date include file... so that if people copy.. it is OK.
People who do IETF MIB work can always ask me (or Perkins I guess)
to do a SMIC compile for them.
> 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.
I kind of feel the MAY is too weak. I'd rather see people do a
consistent IMPORTS.... I will do a spearate email to see if I can read
a rough consensus on mreview. If we do have one, then we may change
it and then we can see if IETF Last Call changes it.
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:email@example.com]
> > Sent: vrijdag 3 januari 2003 16:56
> > To: firstname.lastname@example.org
> > Cc: email@example.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 220.127.116.11
> dealing with the selection of data types for index objects, in
> accordance with discussions on the mailing list.
One worry I now have is this: would any people be encouraged to start
use Gauge32 as an INDEX ???