From owner-snmpconf@seymour39.snmp.com Tue Jul 1 10:27:57 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02500 for ; Tue, 1 Jul 2003 10:27:57 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id KAA29836 for snmpconf-outgoing; Tue, 1 Jul 2003 10:23:19 -0400 (EDT) Message-Id: <200307011423.KAA29830@seymour39.snmp.com> To: snmpconf@snmp.com Subject: snmpconf quarterly list instructions mailing Date: Tue, 01 Jul 2003 10:23:16 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The snmpconf list is for discussing the business of the Configuration Management using SNMP (snmpconf) working group of the IETF. This working group is an open forum for raising and discussing issues related to network device configuration management and SNMP. To remove yourself from the snmpconf discussion list, send a message to snmpconf-request@majordomo.snmp.com containing just the word unsubscribe in the message body (not in the subject). If you have subscribed at an address other than your email from address, send the message unsubscribe address-to-unsubscribe. A http archive is available at http://www.snmp.com/snmpconf/mailing-list/index.html Please send any questions or comments about the management of this list to owner-snmpconf@majordomo.snmp.com. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** From owner-snmpconf@seymour39.snmp.com Tue Jul 29 09:09:14 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21855 for ; Tue, 29 Jul 2003 09:09:13 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id JAA17910 for snmpconf-outgoing; Tue, 29 Jul 2003 09:00:32 -0400 (EDT) Message-Id: <200307291300.JAA17903@seymour39.snmp.com> Content-Type: text/plain; charset="iso-8859-15" From: Jon Saperia To: snmpconf@snmp.com, "Wijnen, Bert (Bert)" , "'Randy Bush'" Subject: Request to Publish: draft-ietf-snmpconf-diffpolicy-06.txt Date: Tue, 29 Jul 2003 09:02:39 -0500 X-Mailer: KMail [version 1.3.2] Organization: Ohia Networks, Inc. Cc: iesg-secretary@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Folks, the last call on draft-ietf-snmpconf-diffpolicy-06.txt has expired and there have not been any comments. This note serves as our request to the ADs that the document be evaluated for proposed standard status. Thanks /jon -- Jon Saperia saperia@ohianets.com Phone: 978-461-0249 Fax: 617-249-0874 http://www.ohianets.com/ From owner-snmpconf@seymour39.snmp.com Tue Jul 29 10:56:27 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25464 for ; Tue, 29 Jul 2003 10:56:26 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id KAA22442 for snmpconf-outgoing; Tue, 29 Jul 2003 10:50:16 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213BD7C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: AD review of: draft-ietf-snmpconf-diffpolicy-06.txt Date: Tue, 29 Jul 2003 16:49:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Here is my AD review: 1. First, a SMICng compiler (With strict checking) reveals: W: f(diffpol.mi2), (20,4) MODULE-IDENTITY diffServConfigMib should have at least one REVISION clause 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 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 2. I am also missing the Copyright statement in the DESCRIPTION clause of the MODULE-IDENTITY. 3. I am also not sure we need to repeat the whole compliance statements from the DIFFSERV MIB. It seems to me it is an exact copy of the diffServMIBFullCompliance, and if indeed so, then I think it is sufficient to state (within the DESCRIPTION clause of diffServConfigMIBFullCompliance, that the diffServMIBFullCompliance must also be met. See 2nd para page 25 of draft-ietf-ops-mib-review-guidelines-01.txt 4. When one reads the doc, one would get the impression that one MUST undestand the PM-MIB in order to understand this one. Not only because of the normative ref, but also reading the text one gets that impression. Harrie and Jon had mentioned that this document would not need a normative reference to the PM-MIB, but from the text it seems to me that it indeed DOES need to, and if not, then it does not make clear how this MIB could/should be used without the PM-MIB. 5. I also suspect that the security-considerations section needs to list which tables and objects are security sensitive and why. 6. I also miss the IPR section. 7. There may be other issues that one might find if one does a carefull check against: draft-ietf-ops-mib-review-guidelines-01.txt 8. Page 14, Is it really: if return roleMatch("Administrator") Or is it suppused to be: if (roleMatch("Administrator") But even with that, I do not think the context is readily understandable is it? I think you want to show (possibly with some more complete PM-MIB code fragment) how this works and how th various entries get created. And/Or, show how it can be done without the use of PM-MIB 9. objectdiffServConfigID DESCRIPTION "A unique id for the per-hop-behavior policy. The range of up to 116 characters is chosen to stay within the SMI limit of 128 subidentifiers in an index." s/character/octets/ It is important to distinguis, UTF-8 characters may occupy more than one octet per character. 10. StorageType Might want to add a DEFVAL ?? But in any event, you need to say something about write access for permanent entries. See the StorageTypeTC in RFC2579 11. RowStatus Need to say which (if any) objects can be changed while a row is active. See RowStatus TC in RFC2579 12. Pls remove the IMPORT for InetAddressType, InetAddress, they are not used 13. RFC3411 needs to be normatively referenced, you are IMPORTing SnmpAdminString from it. REAL NITS - page 8, last line of first para ".. via a so called the element." ??? - page 11 2nd para "... treatment of 1) is also in the tables." Does "1)" refer to section 6.2.1 ?? If so, better make that explicit - Page 13 I wonder if "DSCP(EF)" is a clear indication of the fact that this is entry diffServDscpMarkActDscp. and same for DSCP(AF). - Pages 12, 13 and 16 I understand that the values (content) of things like diffServClfrStorage and diffServCountActOctets (etc) are irrelevant. But you may want to say something about that. - I'd change ::= { mib-2 xxx } -- Needs to be assigned by before publishing into: ::= { mib-2 xxx } -- to be assigned by IANA Thanks, Bert From owner-snmpconf@seymour39.snmp.com Tue Jul 29 14:24:11 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03717 for ; Tue, 29 Jul 2003 14:24:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id OAA02181 for snmpconf-outgoing; Tue, 29 Jul 2003 14:17:45 -0400 (EDT) Date: Tue, 29 Jul 2003 20:22:57 +0200 Subject: Item 1) Re: AD review of: draft-ietf-snmpconf-diffpolicy-06.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel To: snmpconf@snmp.com From: Harrie Hazewinkel In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550213BD7C@nl0006exch001u.nl.lucent.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit 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 From owner-snmpconf@seymour39.snmp.com Tue Jul 29 15:12:08 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05600 for ; Tue, 29 Jul 2003 15:12:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id PAA04541 for snmpconf-outgoing; Tue, 29 Jul 2003 15:08:04 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213BDD3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Cc: Harrie Hazewinkel Subject: RE: Item 1) Re: AD review of: draft-ietf-snmpconf-diffpolicy-06.t xt Date: Tue, 29 Jul 2003 21:07:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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 > From owner-snmpconf@seymour39.snmp.com Wed Jul 30 02:55:03 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21666 for ; Wed, 30 Jul 2003 02:55:03 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id CAA11225 for snmpconf-outgoing; Wed, 30 Jul 2003 02:50:24 -0400 (EDT) Date: Wed, 30 Jul 2003 08:55:40 +0200 Subject: Re: Item 1) Re: AD review of: draft-ietf-snmpconf-diffpolicy-06.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel , snmpconf@snmp.com To: "Wijnen, Bert (Bert)" From: Harrie Hazewinkel In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550213BDD3@nl0006exch001u.nl.lucent.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit On Tuesday, July 29, 2003, at 09:07 PM, Wijnen, Bert (Bert) wrote: > 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. I agree fully on adding the compliance statement, but I merely wanted to point out the errors that SMICng gave. The errors did not seem errors to me and neither did libsmi seen them as such. While looking at it, do we not need to add this in the guidelines?? I mean, whether the import of an object, group is needed in the compliance statement. But that is not a discussion for SNMPCONF, IMHO. > 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 Yes, that is what I understood and have done. Sorry, I believe I was not clear the first time. regards, Harrie