[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Item 1) Re: AD review of: draft-ietf-snmpconf-diffpolicy-06.txt
Harry, you were involved (as one of the MIB doctors) when we
crteated the mib-guidelines. The below are all as a result of
what we as collective set of MIB doctors thought to be good.
One of my reasons to get the mib-guidelines was so that it
can be used by MIB doctors during their review, and so that
we get a CONSISTENT (or as consistent as possible) review
for all MIB documents, and not a review that is heavily biased
based on which MIB Doctor does the actual review.
W.r.t. the IMPORT thing.... it is a MAY, but most MIB docotrs
prefer the explicit IMPORT. It makes it clearer for everyone.
Now..... as I indicated, it seems that you do not need to
IMPORT any of those things for the MODULE-COMPLIACE. You can
just mention (in the DESCRIPTION clause) that one needs to
implement DIFFSERV-MIB according to diffServMIBFullCompliance.
Hope this explains
Thanks,
Bert
> -----Original Message-----
> From: Harrie Hazewinkel [mailto:harrie@jumpy.it]
> Sent: dinsdag 29 juli 2003 20:23
> To: snmpconf@snmp.com
> Cc: Harrie Hazewinkel
> Subject: Item 1) Re: AD review of:
> draft-ietf-snmpconf-diffpolicy-06.txt
>
>
> HI all,
>
> I am working on the AD review comments. In the meantime
> I would like feedback on the following, item 1.
>
> On Tuesday, July 29, 2003, at 04:49 PM, Wijnen, Bert (Bert) wrote:
>
> > Here is my AD review:
> >
> > 1. First, a SMICng compiler (With strict checking) reveals:
>
> ONly I do not have a version of SMICng to compile it, but libsmi
> is not mentioning problems with the arguments suggested in
> draft-ietf-ops-mib-review-guidelines-01.txt.
>
> >
> > W: f(diffpol.mi2), (20,4) MODULE-IDENTITY diffServConfigMib should
> > have at least one REVISION clause
>
> With respect to the REVISION clause, RFC 25780 says:
> RevisionPart ::=
> Revisions
> | empty
> Revisions ::=
> Revision
> | Revisions Revision
> Revision ::=
> "REVISION" value(Update ExtUTCTime)
> "DESCRIPTION" Text
>
> Am I correct if I interpret this as a REVISION-clause is NOT
> required??
> This is in contradiction with
> draft-ietf-ops-mib-review-guidelines-01.txt.
>
> But I will just add:
> REVISION "20030730000Z" -- 30 July 2003
> DESCRIPTION
> "Initial version publicsh as RFC XXX" -- to be
> assigned by the
> RFC editor
>
> > W: f(diffpol.mi2), (68,4) Row "diffServConfigEntry" has indexing
> > that may create variables with more than 128 sub-ids
> > - bw: I think this is a bug in SMICng, cause your limit of 116
> > seems to
> > be limiting it to exact 128 sub-ids
>
> I agree.
>
> > E: f(diffpol.mi2), (204,12) Item
> "ifCounterDiscontinuityGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (207,15) module "DIFFSERV-MIB" may be specified
> > only once
> > E: f(diffpol.mi2), (209,12) Item "diffServMIBDataPathGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (209,38) Item "diffServMIBClfrGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (210,12) Item
> "diffServMIBClfrElementGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (210,41) Item "diffServMIBMultiFieldClfrGroup"
> > should be IMPORTed
> > E: f(diffpol.mi2), (211,12) Item "diffServMIBActionGroup"
> should be
> > IMPORTed
> > E: f(diffpol.mi2), (211,36) Item
> "diffServMIBAlgDropGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (212,12) Item "diffServMIBQGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (212,31) Item
> "diffServMIBSchedulerGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (213,12) Item
> "diffServMIBMaxRateGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (213,37) Item
> "diffServMIBMinRateGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (214,12) Item
> "diffServMIBCounterGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (217,14) Item "diffServMIBMeterGroup"
> should be
> > IMPORTed
> > E: f(diffpol.mi2), (222,14) Item
> "diffServMIBTBParamGroup" should be
> > IMPORTed
> > E: f(diffpol.mi2), (227,14) Item "diffServMIBDscpMarkActGroup"
> > should be IMPORTed
> > E: f(diffpol.mi2), (232,14) Item
> "diffServMIBRandomDropGroup" should
> > be IMPORTed
> > E: f(diffpol.mi2), (237,15) Item "diffServDataPathStatus"
> should be
> > IMPORTed
> > E: f(diffpol.mi2), (243,15) Item "diffServClfrStatus" should be
> > IMPORTed
> > E: f(diffpol.mi2), (249,15) Item
> "diffServClfrElementStatus" should
> > be IMPORTed
> > E: f(diffpol.mi2), (255,15) Item "diffServMultiFieldClfrAddrType"
> > should be
> > IMPORTed
> > E: f(diffpol.mi2), (261,15) Item "diffServMultiFieldClfrDstAddr"
> > should be
> > IMPORTed
> > E: f(diffpol.mi2), (267,15) Item "diffServAlgDropStatus"
> should be
> > IMPORTed
> > E: f(diffpol.mi2), (273,15) Item
> "diffServRandomDropStatus" should
> > be IMPORTed
> > E: f(diffpol.mi2), (279,15) Item "diffServQStatus" should
> be IMPORTed
> > E: f(diffpol.mi2), (285,15) Item
> "diffServSchedulerStatus" should be
> > IMPORTed
> > E: f(diffpol.mi2), (291,15) Item "diffServMinRateStatus"
> should be
> > IMPORTed
> > E: f(diffpol.mi2), (297,15) Item "diffServMaxRateStatus"
> should be
> > IMPORTed
>
> I am not sure about this, but are those IMPORTs not done
> 'implicit' by the MODULE clause of the compliance??
>
> At least for the defined objects RFC 2580 says in section 5.4.3
> By definition, each object specified in an OBJECT clause follows a
> MODULE clause which names the information module in which
> that object
> is defined. Therefore, the use of an IMPORTS statement,
> to specify
> from where such objects are imported, is redundant and is not
> required in an information module.
>
> OK, it does not specify this for the MANDATROY-GROUPS or GROUP clause,
> but I assumed the same as in the OBJECT clause. In that case
> I believe
> this
> is a bug in the SMICng compiler.
>
> Am I correct with this assumption??
>
>
> regards,
>
> Harrie
>