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