From dromasca@avaya.com Mon Oct 1 02:06:10 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1AC21F8545 for ; Mon, 1 Oct 2012 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.297 X-Spam-Level: X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLaE2hGIfiSk for ; Mon, 1 Oct 2012 02:06:09 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D37FE21F8513 for ; Mon, 1 Oct 2012 02:06:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8VANBbaVDGmAcF/2dsb2JhbABFtneGMwSBDIEIgiABAQEBAwEBAQ8eCjQEBwwEAgEVAQMEAQEBCgYMCwEGASYfCQgBAQQBEggah2MLnS+cSwSLHxUihTRgA5ttiieCaYFZ X-IronPort-AV: E=Sophos;i="4.80,515,1344225600"; d="scan'208";a="326795306" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Oct 2012 05:00:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2012 04:58:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 11:06:01 +0200 Message-ID: In-Reply-To: <004a01cd1748$b03f1220$6701a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with conformance statements) Thread-Index: Ac0XSLeJRjBdjh4+RyOqG/c6MNY1xCIauACQ References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net> <004a01cd1748$b03f1220$6701a8c0@JoanPC> From: "Romascanu, Dan (Dan)" To: "Joan Cucchiara" , "Bert Wijnen (IETF)" , Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org, Ralph Droms Subject: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 (was: RE: Help with conformance statements) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:06:10 -0000 Hi Joan, Version draft-ietf-trill-rbridge-mib-08 of this document was submitted and Benoit needs conformation that all critical issues were resolved before he approves the document. Did you have the time to check 08 and can you confirm this? Other MIB doctors advice is of course welcome. Thanks and Regards, Dab > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] > On Behalf Of Joan Cucchiara > Sent: Tuesday, April 10, 2012 9:35 PM > To: Bert Wijnen (IETF); adrian@olddog.co.uk > Cc: mib-doctors@ietf.org; draft-ietf-trill-rbridge-mib@tools.ietf.org; > ops-ads@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Help with conformance statements >=20 > Adrian and Bert, >=20 > I think it would be very helpful if the authors could specify ISIS > objects in a MODULE_COMPLIANCE as Bert suggests. >=20 > When I reviewed version 6 of the MIB, I asked if the authors could > ensure that WG was aware there is no read-only > compliance and this point was not addressed in version 7 either. Not > a > MUST, but certainly want to make sure > that the WG is aware they need to support read-create and read-write via > SNMP. >=20 > Additionally, there are some warnings from the MIB compilers that were > also there in version 6 and I'd like to see those addressed in the > document (either discussed or fixed). My comments below were emailed to > the authors. >=20 > fyi, > -Joan >=20 >=20 >=20 > * LAST-UPDATED and REVISION clauses have the same date as Version 6 >=20 >=20 > OUTPUT from SMICNGPRO > ----------------------- >=20 > W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have > SIZE specified > W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has > indexing that may create variables with more than 128 sub-ids > W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should > have SIZE specified > W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does not have > a consistent indexing scheme - cannot specify an index item from > additional "base row" rbridgeBasePortEntry, since can have only one > "base row" which is rbridgeVlanEntry >=20 >=20 > SMILINT > ----------- >=20 > mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index > of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 > subidentifier(s) >=20 > Additional descriptions of some error/warning messages: >=20 > Error: index-element-no-size (level 3) > Message: index element `%s' of row `%s' must have a size restriction > Description: Object identifiers are restricted in size to have at most > 128 > sub-identifiers. This implies that index elements used to > form > instance identifiers must have a size contraint which > ensures > that the 128 sub-identifier constraint is kept intact for > any > possible combination of the index elements' values (RFC > 2578, > Section 3.5). >=20 >=20 > * Looking at the objects with TC of PortList (rbridgeMultiFibPorts, > rbridgeSnoopingAddrPorts) >=20 > W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have > SIZE specified >=20 >=20 > rbridgeMultiFibPorts OBJECT-TYPE > SYNTAX PortList > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The list of ports to which a frame destined to this > multicast distribution tree is flooded. This may be pruned > further based on other forwarding information." > ::=3D { rbridgeMultiFibEntry 2 } >=20 > Q-BRIDGE-MIB defines: > PortList ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Each octet within this value specifies a set of eight > ports, with the first octet specifying ports 1 through > 8, the second octet specifying ports 9 through 16, etc. > Within each octet, the most significant bit represents > the lowest numbered port, and the least significant bit > represents the highest numbered port. Thus, each port > of the bridge is represented by a single bit within the > value of this object. If that bit has a value of '1' > then that port is included in the set of ports; the port > is not included if its bit has a value of '0'." > SYNTAX OCTET STRING >=20 > OCTET STRING is 0..65535 characters. >=20 > Consider that a range of 0..255 would give 8*256 =3D=3D 2048 Ports > Are more ports needed? >=20 >=20 >=20 > * Both compilers warn about rbridgeSnoopingEntry >=20 > The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes, so > why > is this > not indicated? (An example is below.) >=20 > rbridgeSnoopingAddrType OBJECT-TYPE > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2)} > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The IP multicast address type for which a listener has been > detected by this RBridge. This MIB requires support for only > IPv4 and IPv6 address types." > REFERENCE > "RFC 6325 section 4.7" > ::=3D { rbridgeSnoopingAddrEntry 1 } >=20 > rbridgeSnoopingAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(0|4|16)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The IP multicast address for which a listener has been > detected by this RBridge. The address type of this object > is specified in rbridgeSnoopingAddrType. This MIB requires > support for only global IPv4 and IPv6 addresses, so the > length of the object can be either 4 or 16 bytes." > REFERENCE > "RFC 6325 section 4.7" > ::=3D { rbridgeSnoopingAddrEntry 2 } >=20 >=20 >=20 > * Suggested OID layout is not as Specified in the MIB Guidelines > document: >=20 > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) >=20 >=20 > Compliances and Groups are reversed in the MIB draft. >=20 >=20 > INDEXING > =3D=3D=3D=3D=3D=3D=3D=3D > I am a little concerned about the Indexing in this MIB, only because it > looks like several table > should really have an AUGMENTS relationship. >=20 > INDEX { rbridgeBaseNicknameName } > INDEX { rbridgeBasePort } > INDEX { rbridgeFdbId, rbridgeUniFdbAddr } > INDEX { rbridgeUniFibNickname, rbridgeUniFibPort, > INDEX { rbridgeMultiFibNickname } > INDEX { rbridgeVlanIndex } > INDEX { rbridgeBasePort, rbridgeVlanIndex } > INDEX { rbridgeBasePort } > INDEX { rbridgeVlanIndex } > INDEX { rbridgeBasePort } > INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType, > INDEX { rbridgeDtreeNumber } > INDEX { rbridgeTrillNbrMacAddr } >=20 >=20 >=20 > * Conformance Statement. > Same comment as on the prior draft. Still no read-only and full > conformance. > This is okay, but want to make sure that working group is "okay" with > having > to do a full conformance (i.e. support read-write and read-create via > SNMP)? >=20 >=20 > ----- Original Message ----- > From: "Bert Wijnen (IETF)" > To: > Cc: ; mib@tools.ietf.org>; > > Sent: Tuesday, April 10, 2012 4:53 AM > Subject: Re: [MIB-DOCTORS] Help with conformance statements >=20 >=20 > > From a quick read that I did (section 6.7), then it > > indeed seems to specify a set of requirements (even in > > MUST) language for the ISIS-MIB module. So here (in > > sect 6.7) they are described in English. > > > > It would indeed be useful to have that documented > > in machine readable format, i.e. in (or as part of) > > a MODULE-COMPLIANCE statement. > > > > Is it a reason to hold up the document? > > Not sure about that. At the time when I was AD, I > > tried to strongly encourage people to express such > > requirements in the form of MODULE_COMPLIANCE > > statements. But that was/is my view. > > > > Maybe other MIB doctors do have an opinion on that. > > > > Bert > > > > On 4/8/12 10:34 PM, Adrian Farrel wrote: > >> Hi, > >> > >> Is there a MIB Doctor that can help us? > >> > >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt > >> > >> It reads... > >> > >>> I would like help from the OPS ADs (and MIB Doctors) on this point: > >>> > >>> It seems to me that section 6.7 needs a new conformance statement to > >>> be applied to ISIS-MIB. The text in the section appears to be in two > >>> parts: > >>> > >>> - Implementation guidance (what value to return on a GET from a > Trill > >>> implementation) > >>> > >>> - Implementation requirements (which tables/objects to implement or > >>> not (conformance statement). > >> > >> Can anyone tell me if I am right or wrong. > >> > >> Thanks, > >> Adrian > >> > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > >> > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From jcucchiara@mindspring.com Tue Oct 2 05:47:08 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE121F87D3 for ; Tue, 2 Oct 2012 05:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNZfRKH1rr5C for ; Tue, 2 Oct 2012 05:47:07 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35521F87C9 for ; Tue, 2 Oct 2012 05:47:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LC13YMDlnP5hAum4UltOw5SSuGZ6vW1zdhUlzevUy2kDyfUJFoIKmJrE/2lWmK9e; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TJ1rw-0006fI-Mv; Tue, 02 Oct 2012 08:46:36 -0400 Message-ID: <5aa901cda09b$f53e7aa0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Romascanu, Dan \(Dan\)" , "Bert Wijnen \(IETF\)" , References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net> <004a01cd1748$b03f1220$6701a8c0@JoanPC> Date: Tue, 2 Oct 2012 08:46:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654f3eeb95dc15ad377d1593e4419059189f0dc0b2615eb44cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org, Ralph Droms Subject: Re: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 (was: RE: Help with conformance statements) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:47:08 -0000 Dan, I have not reviewed this draft, however a quick scan reveals that 3 comments made during MIB Dr. review have not been addressed: 1) The Indexing. INDEX { rbridgeBasePort } is used as an index in several tables and the relationship should really be an AUGMENTS. Not sure why this was not done. 2) > * Suggested OID layout is not as Specified in the MIB Guidelines > document: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > > Compliances and Groups are reversed in the MIB draft. > 3) the Conformance is a full conformance which contains read-create and read-write objects. I raised this as a concern as part of the MIB Dr rview and asked that the WG be informed that in order to be compliant with the MIB, they will need to support SNMP sets. While not technically wrong, my experience is having both a read-only and full conformance in a MIB which contains sets, allows more flexibility for those that do not configure their products using SNMP. This allows them to be compliant with the RFC, and I believe that the WG needs to be made aware of this, since most MIBs from the IETF in recent history have a read-only conformance. I asked the authors to confirm with the WG that this is what the WG wants, but did not see any emails to the WG on the list. I may have missed the email, or they may have confirmed this in some other way, but I am not aware. Will do a more thorough check on other MIB Dr. review comments later, but think these 3 are critical and should be discussed/followed-up. Thanks, -Joan ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Joan Cucchiara" ; "Bert Wijnen (IETF)" ; Cc: ; ; ; "Ralph Droms" Sent: Monday, October 01, 2012 5:06 AM Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with conformance statements) Hi Joan, Version draft-ietf-trill-rbridge-mib-08 of this document was submitted and Benoit needs conformation that all critical issues were resolved before he approves the document. Did you have the time to check 08 and can you confirm this? Other MIB doctors advice is of course welcome. Thanks and Regards, Dab > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] > On Behalf Of Joan Cucchiara > Sent: Tuesday, April 10, 2012 9:35 PM > To: Bert Wijnen (IETF); adrian@olddog.co.uk > Cc: mib-doctors@ietf.org; draft-ietf-trill-rbridge-mib@tools.ietf.org; > ops-ads@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Help with conformance statements > > Adrian and Bert, > > I think it would be very helpful if the authors could specify ISIS > objects in a MODULE_COMPLIANCE as Bert suggests. > > When I reviewed version 6 of the MIB, I asked if the authors could > ensure that WG was aware there is no read-only > compliance and this point was not addressed in version 7 either. Not > a > MUST, but certainly want to make sure > that the WG is aware they need to support read-create and read-write via > SNMP. > > Additionally, there are some warnings from the MIB compilers that were > also there in version 6 and I'd like to see those addressed in the > document (either discussed or fixed). My comments below were emailed to > the authors. > > fyi, > -Joan > > > > * LAST-UPDATED and REVISION clauses have the same date as Version 6 > > > OUTPUT from SMICNGPRO > ----------------------- > > W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have > SIZE specified > W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has > indexing that may create variables with more than 128 sub-ids > W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should > have SIZE specified > W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does not have > a consistent indexing scheme - cannot specify an index item from > additional "base row" rbridgeBasePortEntry, since can have only one > "base row" which is rbridgeVlanEntry > > > SMILINT > ----------- > > mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index > of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 > subidentifier(s) > > Additional descriptions of some error/warning messages: > > Error: index-element-no-size (level 3) > Message: index element `%s' of row `%s' must have a size restriction > Description: Object identifiers are restricted in size to have at most > 128 > sub-identifiers. This implies that index elements used to > form > instance identifiers must have a size contraint which > ensures > that the 128 sub-identifier constraint is kept intact for > any > possible combination of the index elements' values (RFC > 2578, > Section 3.5). > > > * Looking at the objects with TC of PortList (rbridgeMultiFibPorts, > rbridgeSnoopingAddrPorts) > > W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have > SIZE specified > > > rbridgeMultiFibPorts OBJECT-TYPE > SYNTAX PortList > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The list of ports to which a frame destined to this > multicast distribution tree is flooded. This may be pruned > further based on other forwarding information." > ::= { rbridgeMultiFibEntry 2 } > > Q-BRIDGE-MIB defines: > PortList ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Each octet within this value specifies a set of eight > ports, with the first octet specifying ports 1 through > 8, the second octet specifying ports 9 through 16, etc. > Within each octet, the most significant bit represents > the lowest numbered port, and the least significant bit > represents the highest numbered port. Thus, each port > of the bridge is represented by a single bit within the > value of this object. If that bit has a value of '1' > then that port is included in the set of ports; the port > is not included if its bit has a value of '0'." > SYNTAX OCTET STRING > > OCTET STRING is 0..65535 characters. > > Consider that a range of 0..255 would give 8*256 == 2048 Ports > Are more ports needed? > > > > * Both compilers warn about rbridgeSnoopingEntry > > The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes, so > why > is this > not indicated? (An example is below.) > > rbridgeSnoopingAddrType OBJECT-TYPE > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2)} > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The IP multicast address type for which a listener has been > detected by this RBridge. This MIB requires support for only > IPv4 and IPv6 address types." > REFERENCE > "RFC 6325 section 4.7" > ::= { rbridgeSnoopingAddrEntry 1 } > > rbridgeSnoopingAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(0|4|16)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The IP multicast address for which a listener has been > detected by this RBridge. The address type of this object > is specified in rbridgeSnoopingAddrType. This MIB requires > support for only global IPv4 and IPv6 addresses, so the > length of the object can be either 4 or 16 bytes." > REFERENCE > "RFC 6325 section 4.7" > ::= { rbridgeSnoopingAddrEntry 2 } > > > > * Suggested OID layout is not as Specified in the MIB Guidelines > document: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > > Compliances and Groups are reversed in the MIB draft. > > > INDEXING > ======== > I am a little concerned about the Indexing in this MIB, only because it > looks like several table > should really have an AUGMENTS relationship. > > INDEX { rbridgeBaseNicknameName } > INDEX { rbridgeBasePort } > INDEX { rbridgeFdbId, rbridgeUniFdbAddr } > INDEX { rbridgeUniFibNickname, rbridgeUniFibPort, > INDEX { rbridgeMultiFibNickname } > INDEX { rbridgeVlanIndex } > INDEX { rbridgeBasePort, rbridgeVlanIndex } > INDEX { rbridgeBasePort } > INDEX { rbridgeVlanIndex } > INDEX { rbridgeBasePort } > INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType, > INDEX { rbridgeDtreeNumber } > INDEX { rbridgeTrillNbrMacAddr } > > > > * Conformance Statement. > Same comment as on the prior draft. Still no read-only and full > conformance. > This is okay, but want to make sure that working group is "okay" with > having > to do a full conformance (i.e. support read-write and read-create via > SNMP)? > > > ----- Original Message ----- > From: "Bert Wijnen (IETF)" > To: > Cc: ; mib@tools.ietf.org>; > > Sent: Tuesday, April 10, 2012 4:53 AM > Subject: Re: [MIB-DOCTORS] Help with conformance statements > > > > From a quick read that I did (section 6.7), then it > > indeed seems to specify a set of requirements (even in > > MUST) language for the ISIS-MIB module. So here (in > > sect 6.7) they are described in English. > > > > It would indeed be useful to have that documented > > in machine readable format, i.e. in (or as part of) > > a MODULE-COMPLIANCE statement. > > > > Is it a reason to hold up the document? > > Not sure about that. At the time when I was AD, I > > tried to strongly encourage people to express such > > requirements in the form of MODULE_COMPLIANCE > > statements. But that was/is my view. > > > > Maybe other MIB doctors do have an opinion on that. > > > > Bert > > > > On 4/8/12 10:34 PM, Adrian Farrel wrote: > >> Hi, > >> > >> Is there a MIB Doctor that can help us? > >> > >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt > >> > >> It reads... > >> > >>> I would like help from the OPS ADs (and MIB Doctors) on this point: > >>> > >>> It seems to me that section 6.7 needs a new conformance statement to > >>> be applied to ISIS-MIB. The text in the section appears to be in two > >>> parts: > >>> > >>> - Implementation guidance (what value to return on a GET from a > Trill > >>> implementation) > >>> > >>> - Implementation requirements (which tables/objects to implement or > >>> not (conformance statement). > >> > >> Can anyone tell me if I am right or wrong. > >> > >> Thanks, > >> Adrian > >> > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > >> > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Wed Oct 3 02:22:03 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7367C21F86B6 for ; Wed, 3 Oct 2012 02:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=-2.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqLp3oKd0PGC for ; Wed, 3 Oct 2012 02:22:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 198D121F86B7 for ; Wed, 3 Oct 2012 02:22:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q939Lt9Y016288; Wed, 3 Oct 2012 11:21:55 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q939Lsbs006565; Wed, 3 Oct 2012 11:21:54 +0200 (CEST) Message-ID: <506C03B2.9060902@cisco.com> Date: Wed, 03 Oct 2012 11:21:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Joan Cucchiara References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net> <004a01cd1748$b03f1220$6701a8c0@JoanPC> <5aa901cda09b$f53e7aa0$6801a8c0@JoanPC> In-Reply-To: <5aa901cda09b$f53e7aa0$6801a8c0@JoanPC> Content-Type: multipart/alternative; boundary="------------090706070203040203040306" Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org, mib-doctors@ietf.org, ops-ads@tools.ietf.org, Ralph Droms , adrian@olddog.co.uk Subject: Re: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 09:22:03 -0000 This is a multi-part message in MIME format. --------------090706070203040203040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Joan, Thanks for your review. Let me update the DISCUSS/COMMENT with your feedback below. Do you know when you will have the time to review the MIB module? Note that the authors posted a new version of the MIB module, addressing one DISCUSS point: The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rbridge-mib-09 Regards, Benoit. > Dan, > > I have not reviewed this draft, however a quick scan reveals that 3 > comments made during > MIB Dr. review have not been addressed: > > 1) The Indexing. > > INDEX { rbridgeBasePort } is used as an index in several tables and > the relationship > should really be an AUGMENTS. Not sure why this was not done. > > 2) >> * Suggested OID layout is not as Specified in the MIB Guidelines >> document: >> >> xxxMIB >> | >> +-- xxxNotifications(0) >> +-- xxxObjects(1) >> +-- xxxConformance(2) >> | >> +-- xxxCompliances(1) >> +-- xxxGroups(2) >> >> >> Compliances and Groups are reversed in the MIB draft. >> > > > 3) the Conformance is a full conformance which contains read-create and > read-write objects. I raised this as a concern as part of the MIB Dr > rview > and asked that the WG be informed that in order to be compliant with > the MIB, > they will need to support SNMP sets. > > While not technically wrong, my experience is having both a read-only > and full conformance in a MIB > which contains sets, allows more flexibility for those that do not > configure their products using > SNMP. This allows them to be compliant with the RFC, and I believe > that the WG needs to > be made aware of this, since most MIBs from the IETF in recent history > have a read-only conformance. > I asked the authors to confirm with the WG that this is what the WG > wants, but did not see any emails to the WG on the list. > I may have missed the email, or they may have confirmed this in some > other way, but I am not aware. > > > Will do a more thorough check on other MIB Dr. review comments later, > but think these 3 are critical and should be > discussed/followed-up. > > Thanks, > -Joan > > > ----- Original Message ----- From: "Romascanu, Dan (Dan)" > > To: "Joan Cucchiara" ; "Bert Wijnen (IETF)" > ; > Cc: ; > ; > ; "Ralph Droms" > Sent: Monday, October 01, 2012 5:06 AM > Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help > with conformance statements) > > > Hi Joan, > > Version draft-ietf-trill-rbridge-mib-08 of this document was submitted > and Benoit needs conformation that all critical issues were resolved > before he approves the document. Did you have the time to check 08 and > can you confirm this? > > Other MIB doctors advice is of course welcome. > > Thanks and Regards, > > Dab > > > > >> -----Original Message----- >> From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] >> On Behalf Of Joan Cucchiara >> Sent: Tuesday, April 10, 2012 9:35 PM >> To: Bert Wijnen (IETF); adrian@olddog.co.uk >> Cc: mib-doctors@ietf.org; draft-ietf-trill-rbridge-mib@tools.ietf.org; >> ops-ads@tools.ietf.org >> Subject: Re: [MIB-DOCTORS] Help with conformance statements >> >> Adrian and Bert, >> >> I think it would be very helpful if the authors could specify ISIS >> objects in a MODULE_COMPLIANCE as Bert suggests. >> >> When I reviewed version 6 of the MIB, I asked if the authors could >> ensure that WG was aware there is no read-only >> compliance and this point was not addressed in version 7 either. > Not >> a >> MUST, but certainly want to make sure >> that the WG is aware they need to support read-create and read-write > via >> SNMP. >> >> Additionally, there are some warnings from the MIB compilers that were >> also there in version 6 and I'd like to see those addressed in the >> document (either discussed or fixed). My comments below were emailed > to >> the authors. >> >> fyi, >> -Joan >> >> >> >> * LAST-UPDATED and REVISION clauses have the same date as Version 6 >> >> >> OUTPUT from SMICNGPRO >> ----------------------- >> >> W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have >> SIZE specified >> W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has >> indexing that may create variables with more than 128 sub-ids >> W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should >> have SIZE specified >> W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does not > have >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" rbridgeBasePortEntry, since can have only one >> "base row" which is rbridgeVlanEntry >> >> >> SMILINT >> ----------- >> >> mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index >> of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 >> subidentifier(s) >> >> Additional descriptions of some error/warning messages: >> >> Error: index-element-no-size (level 3) >> Message: index element `%s' of row `%s' must have a size > restriction >> Description: Object identifiers are restricted in size to have at most >> 128 >> sub-identifiers. This implies that index elements used to >> form >> instance identifiers must have a size contraint which >> ensures >> that the 128 sub-identifier constraint is kept intact for >> any >> possible combination of the index elements' values (RFC >> 2578, >> Section 3.5). >> >> >> * Looking at the objects with TC of PortList (rbridgeMultiFibPorts, >> rbridgeSnoopingAddrPorts) >> >> W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have >> SIZE specified >> >> >> rbridgeMultiFibPorts OBJECT-TYPE >> SYNTAX PortList >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The list of ports to which a frame destined to this >> multicast distribution tree is flooded. This may be pruned >> further based on other forwarding information." >> ::= { rbridgeMultiFibEntry 2 } >> >> Q-BRIDGE-MIB defines: >> PortList ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "Each octet within this value specifies a set of eight >> ports, with the first octet specifying ports 1 through >> 8, the second octet specifying ports 9 through 16, etc. >> Within each octet, the most significant bit represents >> the lowest numbered port, and the least significant bit >> represents the highest numbered port. Thus, each port >> of the bridge is represented by a single bit within the >> value of this object. If that bit has a value of '1' >> then that port is included in the set of ports; the port >> is not included if its bit has a value of '0'." >> SYNTAX OCTET STRING >> >> OCTET STRING is 0..65535 characters. >> >> Consider that a range of 0..255 would give 8*256 == 2048 Ports >> Are more ports needed? >> >> >> >> * Both compilers warn about rbridgeSnoopingEntry >> >> The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes, > so >> why >> is this >> not indicated? (An example is below.) >> >> rbridgeSnoopingAddrType OBJECT-TYPE >> SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2)} >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The IP multicast address type for which a listener has > been >> detected by this RBridge. This MIB requires support for > only >> IPv4 and IPv6 address types." >> REFERENCE >> "RFC 6325 section 4.7" >> ::= { rbridgeSnoopingAddrEntry 1 } >> >> rbridgeSnoopingAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The IP multicast address for which a listener has been >> detected by this RBridge. The address type of this object >> is specified in rbridgeSnoopingAddrType. This MIB requires >> support for only global IPv4 and IPv6 addresses, so the >> length of the object can be either 4 or 16 bytes." >> REFERENCE >> "RFC 6325 section 4.7" >> ::= { rbridgeSnoopingAddrEntry 2 } >> >> >> >> * Suggested OID layout is not as Specified in the MIB Guidelines >> document: >> >> xxxMIB >> | >> +-- xxxNotifications(0) >> +-- xxxObjects(1) >> +-- xxxConformance(2) >> | >> +-- xxxCompliances(1) >> +-- xxxGroups(2) >> >> >> Compliances and Groups are reversed in the MIB draft. >> >> >> INDEXING >> ======== >> I am a little concerned about the Indexing in this MIB, only because > it >> looks like several table >> should really have an AUGMENTS relationship. >> >> INDEX { rbridgeBaseNicknameName } >> INDEX { rbridgeBasePort } >> INDEX { rbridgeFdbId, rbridgeUniFdbAddr } >> INDEX { rbridgeUniFibNickname, rbridgeUniFibPort, >> INDEX { rbridgeMultiFibNickname } >> INDEX { rbridgeVlanIndex } >> INDEX { rbridgeBasePort, rbridgeVlanIndex } >> INDEX { rbridgeBasePort } >> INDEX { rbridgeVlanIndex } >> INDEX { rbridgeBasePort } >> INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType, >> INDEX { rbridgeDtreeNumber } >> INDEX { rbridgeTrillNbrMacAddr } >> >> >> >> * Conformance Statement. >> Same comment as on the prior draft. Still no read-only and full >> conformance. >> This is okay, but want to make sure that working group is "okay" with >> having >> to do a full conformance (i.e. support read-write and read-create via >> SNMP)? >> >> >> ----- Original Message ----- >> From: "Bert Wijnen (IETF)" >> To: >> Cc: ; > mib@tools.ietf.org>; >> >> Sent: Tuesday, April 10, 2012 4:53 AM >> Subject: Re: [MIB-DOCTORS] Help with conformance statements >> >> >> > From a quick read that I did (section 6.7), then it >> > indeed seems to specify a set of requirements (even in >> > MUST) language for the ISIS-MIB module. So here (in >> > sect 6.7) they are described in English. >> > >> > It would indeed be useful to have that documented >> > in machine readable format, i.e. in (or as part of) >> > a MODULE-COMPLIANCE statement. >> > >> > Is it a reason to hold up the document? >> > Not sure about that. At the time when I was AD, I >> > tried to strongly encourage people to express such >> > requirements in the form of MODULE_COMPLIANCE >> > statements. But that was/is my view. >> > >> > Maybe other MIB doctors do have an opinion on that. >> > >> > Bert >> > >> > On 4/8/12 10:34 PM, Adrian Farrel wrote: >> >> Hi, >> >> >> >> Is there a MIB Doctor that can help us? >> >> >> >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt >> >> >> >> It reads... >> >> >> >>> I would like help from the OPS ADs (and MIB Doctors) on this > point: >> >>> >> >>> It seems to me that section 6.7 needs a new conformance statement > to >> >>> be applied to ISIS-MIB. The text in the section appears to be in > two >> >>> parts: >> >>> >> >>> - Implementation guidance (what value to return on a GET from a >> Trill >> >>> implementation) >> >>> >> >>> - Implementation requirements (which tables/objects to implement > or >> >>> not (conformance statement). >> >> >> >> Can anyone tell me if I am right or wrong. >> >> >> >> Thanks, >> >> Adrian >> >> >> >> >> >> _______________________________________________ >> >> MIB-DOCTORS mailing list >> >> MIB-DOCTORS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> >> > _______________________________________________ >> > MIB-DOCTORS mailing list >> > MIB-DOCTORS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mib-doctors >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > --------------090706070203040203040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Joan,

Thanks for your review.
Let me update the DISCUSS/COMMENT with your feedback below.
Do you know when you will have the time to review the MIB module?
Note that the authors posted a new version of the MIB module, addressing one DISCUSS point:
The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rbridge-mib-09


Regards, Benoit.
Dan,

I have not reviewed this draft, however a quick scan reveals that 3 comments made during
MIB Dr. review have not been addressed:

1) The Indexing.

INDEX  { rbridgeBasePort } is used as an index in several tables and the relationship
should really be an AUGMENTS.    Not sure why this was not done.

2)
* Suggested OID layout is not as Specified in the MIB Guidelines
document:

  xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)


Compliances and Groups are reversed in the MIB draft.



3)  the Conformance is a full conformance which contains read-create and
read-write objects.   I raised this as a concern as part of the MIB Dr rview
and asked that the WG be informed that in order to be compliant with the MIB,
they will need to support SNMP sets.

While not technically wrong, my experience is having both a read-only and full conformance in a MIB
which contains sets, allows more flexibility for those that do not configure their products using
SNMP.   This allows them to be compliant with the RFC, and I believe that the WG needs to
be made aware of this, since most MIBs from the IETF in recent history have a read-only conformance.
I asked the authors to confirm with the WG that this is what the WG wants, but did not see any emails to the WG on the list.
I may have missed the email, or they may have confirmed this in some other way, but I am not aware.


Will do a more thorough check on other MIB Dr. review comments later, but think these 3 are critical and should be
discussed/followed-up.

Thanks,
 -Joan


----- Original Message ----- From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Joan Cucchiara" <jcucchiara@mindspring.com>; "Bert Wijnen (IETF)" <bertietf@bwijnen.net>; <adrian@olddog.co.uk>
Cc: <mib-doctors@ietf.org>; <draft-ietf-trill-rbridge-mib@tools.ietf.org>; <ops-ads@tools.ietf.org>; "Ralph Droms" <rdroms.ietf@gmail.com>
Sent: Monday, October 01, 2012 5:06 AM
Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with conformance statements)


Hi Joan,

Version draft-ietf-trill-rbridge-mib-08 of this document was submitted
and Benoit needs conformation that all critical issues were resolved
before he approves the document. Did you have the time to check 08 and
can you confirm this?

Other MIB doctors advice is of course welcome.

Thanks and Regards,

Dab




-----Original Message-----
From: mib-doctors-bounces@ietf.org
[mailto:mib-doctors-bounces@ietf.org]
On Behalf Of Joan Cucchiara
Sent: Tuesday, April 10, 2012 9:35 PM
To: Bert Wijnen (IETF); adrian@olddog.co.uk
Cc: mib-doctors@ietf.org; draft-ietf-trill-rbridge-mib@tools.ietf.org;
ops-ads@tools.ietf.org
Subject: Re: [MIB-DOCTORS] Help with conformance statements

Adrian and Bert,

I think it would be very helpful if the authors could specify ISIS
objects in a MODULE_COMPLIANCE as Bert suggests.

When I reviewed version 6 of the MIB, I asked if the authors could
ensure that WG was aware there is no read-only
compliance and this point was not addressed in version 7 either.
Not
a
MUST, but certainly want to make sure
that the WG is aware they need to support read-create and read-write
via
SNMP.

Additionally, there are some warnings from the MIB compilers that were
also there in version 6 and I'd like to see those addressed in the
document (either discussed or fixed).  My comments below were emailed
to
the authors.

fyi,
  -Joan



* LAST-UPDATED and REVISION clauses  have the same date as Version 6


OUTPUT from SMICNGPRO
-----------------------

W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have
SIZE specified
W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has
indexing that may create variables with more than 128 sub-ids
W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should
have SIZE specified
W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does not
have
a consistent indexing scheme - cannot specify an index item from
additional "base row" rbridgeBasePortEntry, since can have only one
"base row" which is rbridgeVlanEntry


SMILINT
-----------

mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index
of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142
subidentifier(s)

Additional descriptions of some error/warning messages:

Error:       index-element-no-size (level 3)
Message:     index element `%s' of row `%s' must have a size
restriction
Description: Object identifiers are restricted in size to have at most
128
             sub-identifiers. This implies that index elements used to
form
             instance identifiers must have a size contraint which
ensures
             that the 128 sub-identifier constraint is kept intact for
any
             possible combination of the index elements' values (RFC
2578,
             Section 3.5).


*  Looking at the objects with TC of PortList (rbridgeMultiFibPorts,
rbridgeSnoopingAddrPorts)

W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have
SIZE specified


   rbridgeMultiFibPorts OBJECT-TYPE
       SYNTAX      PortList
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The list of ports to which a frame destined to this
           multicast distribution tree is flooded. This may be pruned
           further based on other forwarding information."
       ::= { rbridgeMultiFibEntry 2 }

Q-BRIDGE-MIB defines:
PortList ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Each octet within this value specifies a set of eight
        ports, with the first octet specifying ports 1 through
        8, the second octet specifying ports 9 through 16, etc.
        Within each octet, the most significant bit represents
        the lowest numbered port, and the least significant bit
        represents the highest numbered port.  Thus, each port
        of the bridge is represented by a single bit within the
        value of this object.  If that bit has a value of '1'
        then that port is included in the set of ports; the port
        is not included if its bit has a value of '0'."
    SYNTAX      OCTET STRING

OCTET STRING is 0..65535 characters.

Consider that a range of 0..255 would give 8*256 == 2048 Ports
Are more ports needed?



* Both compilers warn about rbridgeSnoopingEntry

The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes,
so
why
is this
not indicated?  (An example is below.)

   rbridgeSnoopingAddrType OBJECT-TYPE
       SYNTAX      InetAddressType { unknown(0), ipv4(1), ipv6(2)}
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The IP multicast address type for which a listener has
been
           detected by this RBridge. This MIB requires support for
only
           IPv4 and IPv6 address types."
       REFERENCE
           "RFC 6325 section 4.7"
       ::= { rbridgeSnoopingAddrEntry 1 }

   rbridgeSnoopingAddr OBJECT-TYPE
       SYNTAX      InetAddress (SIZE(0|4|16))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The IP multicast address for which a listener has been
           detected by this RBridge. The address type of this object
           is specified in rbridgeSnoopingAddrType. This MIB requires
           support for only global IPv4 and IPv6 addresses, so the
           length of the object can be either 4 or 16 bytes."
       REFERENCE
           "RFC 6325 section 4.7"
       ::= { rbridgeSnoopingAddrEntry 2 }



* Suggested OID layout is not as Specified in the MIB Guidelines
document:

  xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)


Compliances and Groups are reversed in the MIB draft.


INDEXING
========
I am a little concerned about the Indexing in this MIB, only because
it
looks like several table
should really have an AUGMENTS relationship.

       INDEX  { rbridgeBaseNicknameName }
       INDEX  { rbridgeBasePort }
       INDEX   { rbridgeFdbId, rbridgeUniFdbAddr }
       INDEX   { rbridgeUniFibNickname, rbridgeUniFibPort,
       INDEX   { rbridgeMultiFibNickname }
       INDEX   { rbridgeVlanIndex }
       INDEX   { rbridgeBasePort, rbridgeVlanIndex }
       INDEX   { rbridgeBasePort }
       INDEX   { rbridgeVlanIndex }
       INDEX   { rbridgeBasePort }
       INDEX  { rbridgeVlanIndex, rbridgeSnoopingAddrType,
       INDEX  { rbridgeDtreeNumber }
       INDEX  { rbridgeTrillNbrMacAddr }



* Conformance Statement.
Same comment as on the prior draft.  Still no read-only and full
conformance.
This is okay, but want to make sure that working group is "okay" with
having
to do a full conformance (i.e. support read-write and read-create via
SNMP)?


----- Original Message -----
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: <adrian@olddog.co.uk>
Cc: <mib-doctors@ietf.org>; <draft-ietf-trill-rbridge-
mib@tools.ietf.org>;
<ops-ads@tools.ietf.org>
Sent: Tuesday, April 10, 2012 4:53 AM
Subject: Re: [MIB-DOCTORS] Help with conformance statements


> From a quick read that I did (section 6.7), then it
> indeed seems to specify a set of requirements (even in
> MUST) language for the ISIS-MIB module. So here (in
> sect 6.7) they are described in English.
>
> It would indeed be useful to have that documented
> in machine readable format, i.e. in (or as part of)
> a MODULE-COMPLIANCE statement.
>
> Is it a reason to hold up the document?
> Not sure about that. At the time when I was AD, I
> tried to strongly encourage people to express such
> requirements in the form of MODULE_COMPLIANCE
> statements. But that was/is my view.
>
> Maybe other MIB doctors do have an opinion on that.
>
> Bert
>
> On 4/8/12 10:34 PM, Adrian Farrel wrote:
>> Hi,
>>
>> Is there a MIB Doctor that can help us?
>>
>> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt
>>
>> It reads...
>>
>>> I would like help from the OPS ADs (and MIB Doctors) on this
point:
>>>
>>> It seems to me that section 6.7 needs a new conformance statement
to
>>> be applied to ISIS-MIB. The text in the section appears to be in
two
>>> parts:
>>>
>>> - Implementation guidance (what value to return on a GET from a
Trill
>>>   implementation)
>>>
>>> - Implementation requirements (which tables/objects to implement
or
>>> not  (conformance statement).
>>
>> Can anyone tell me if I am right or wrong.
>>
>> Thanks,
>> Adrian
>>
>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> MIB-DOCTORS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



--------------090706070203040203040306-- From jcucchiara@mindspring.com Thu Oct 4 06:06:04 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6F21F86A4 for ; Thu, 4 Oct 2012 06:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkUq8V3QoUYD for ; Thu, 4 Oct 2012 06:06:02 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC021F86AD for ; Thu, 4 Oct 2012 06:06:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iJR1EIL1+eAvFB33BWjGnC4r21J3eI+3yvibxElLNESz2JZKrkZaAiPUZB2XvZOM; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TJl7R-0008IY-3m; Thu, 04 Oct 2012 09:05:37 -0400 Message-ID: <5c2401cda230$f1ce2000$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Benoit Claise" References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net> <004a01cd1748$b03f1220$6701a8c0@JoanPC> <5aa901cda09b$f53e7aa0$6801a8c0@JoanPC> <506C03B2.9060902@cisco.com> Date: Thu, 4 Oct 2012 09:05:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5C21_01CDA20F.6A1A4C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654d7d3940cf26c8e23b77c0e79c110442f8858d97c050d2b86350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org, mib-doctors@ietf.org, ops-ads@tools.ietf.org, Ralph Droms , adrian@olddog.co.uk Subject: Re: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:06:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_5C21_01CDA20F.6A1A4C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benoit, Thanks for the info about version 9. I'll try to have a more thorough = review done by Tues. Thanks, -Joan ----- Original Message -----=20 From: Benoit Claise=20 To: Joan Cucchiara=20 Cc: Romascanu, Dan (Dan) ; Bert Wijnen (IETF) ; adrian@olddog.co.uk ; = mib-doctors@ietf.org ; draft-ietf-trill-rbridge-mib@tools.ietf.org ; = ops-ads@tools.ietf.org ; Ralph Droms=20 Sent: Wednesday, October 03, 2012 5:21 AM Subject: Re: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 Hi Joan, Thanks for your review. Let me update the DISCUSS/COMMENT with your feedback below. Do you know when you will have the time to review the MIB module? Note that the authors posted a new version of the MIB module, = addressing one DISCUSS point: The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-rbridge-mib-09 Regards, Benoit. Dan,=20 I have not reviewed this draft, however a quick scan reveals that 3 = comments made during=20 MIB Dr. review have not been addressed:=20 1) The Indexing.=20 INDEX { rbridgeBasePort } is used as an index in several tables and = the relationship=20 should really be an AUGMENTS. Not sure why this was not done.=20 2)=20 * Suggested OID layout is not as Specified in the MIB Guidelines=20 document:=20 xxxMIB=20 |=20 +-- xxxNotifications(0)=20 +-- xxxObjects(1)=20 +-- xxxConformance(2)=20 |=20 +-- xxxCompliances(1)=20 +-- xxxGroups(2)=20 Compliances and Groups are reversed in the MIB draft.=20 3) the Conformance is a full conformance which contains read-create = and=20 read-write objects. I raised this as a concern as part of the MIB = Dr rview=20 and asked that the WG be informed that in order to be compliant with = the MIB,=20 they will need to support SNMP sets.=20 While not technically wrong, my experience is having both a = read-only and full conformance in a MIB=20 which contains sets, allows more flexibility for those that do not = configure their products using=20 SNMP. This allows them to be compliant with the RFC, and I believe = that the WG needs to=20 be made aware of this, since most MIBs from the IETF in recent = history have a read-only conformance.=20 I asked the authors to confirm with the WG that this is what the WG = wants, but did not see any emails to the WG on the list.=20 I may have missed the email, or they may have confirmed this in some = other way, but I am not aware.=20 Will do a more thorough check on other MIB Dr. review comments = later, but think these 3 are critical and should be=20 discussed/followed-up.=20 Thanks,=20 -Joan=20 ----- Original Message ----- From: "Romascanu, Dan (Dan)" = =20 To: "Joan Cucchiara" ; "Bert Wijnen = (IETF)" ; =20 Cc: ; = ; ; = "Ralph Droms" =20 Sent: Monday, October 01, 2012 5:06 AM=20 Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] = Help with conformance statements)=20 Hi Joan,=20 Version draft-ietf-trill-rbridge-mib-08 of this document was = submitted=20 and Benoit needs conformation that all critical issues were resolved = before he approves the document. Did you have the time to check 08 = and=20 can you confirm this?=20 Other MIB doctors advice is of course welcome.=20 Thanks and Regards,=20 Dab=20 -----Original Message-----=20 From: mib-doctors-bounces@ietf.org=20 [mailto:mib-doctors-bounces@ietf.org]=20 On Behalf Of Joan Cucchiara=20 Sent: Tuesday, April 10, 2012 9:35 PM=20 To: Bert Wijnen (IETF); adrian@olddog.co.uk=20 Cc: mib-doctors@ietf.org; = draft-ietf-trill-rbridge-mib@tools.ietf.org;=20 ops-ads@tools.ietf.org=20 Subject: Re: [MIB-DOCTORS] Help with conformance statements=20 Adrian and Bert,=20 I think it would be very helpful if the authors could specify ISIS = objects in a MODULE_COMPLIANCE as Bert suggests.=20 When I reviewed version 6 of the MIB, I asked if the authors could = ensure that WG was aware there is no read-only=20 compliance and this point was not addressed in version 7 either.=20 Not=20 a=20 MUST, but certainly want to make sure=20 that the WG is aware they need to support read-create and = read-write=20 via=20 SNMP.=20 Additionally, there are some warnings from the MIB compilers that = were=20 also there in version 6 and I'd like to see those addressed in the = document (either discussed or fixed). My comments below were = emailed=20 to=20 the authors.=20 fyi,=20 -Joan=20 * LAST-UPDATED and REVISION clauses have the same date as Version = 6=20 OUTPUT from SMICNGPRO=20 -----------------------=20 W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should = have=20 SIZE specified=20 W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has=20 indexing that may create variables with more than 128 sub-ids=20 W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" = should=20 have SIZE specified=20 W: f(RBRIDGE-MIB.my), (1044,18) Row "rbridgeVlanPortEntry" does = not=20 have=20 a consistent indexing scheme - cannot specify an index item from=20 additional "base row" rbridgeBasePortEntry, since can have only = one=20 "base row" which is rbridgeVlanEntry=20 SMILINT=20 -----------=20 mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: = index=20 of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 = subidentifier(s)=20 Additional descriptions of some error/warning messages:=20 Error: index-element-no-size (level 3)=20 Message: index element `%s' of row `%s' must have a size=20 restriction=20 Description: Object identifiers are restricted in size to have at = most=20 128=20 sub-identifiers. This implies that index elements = used to=20 form=20 instance identifiers must have a size contraint which = ensures=20 that the 128 sub-identifier constraint is kept intact = for=20 any=20 possible combination of the index elements' values = (RFC=20 2578,=20 Section 3.5).=20 * Looking at the objects with TC of PortList = (rbridgeMultiFibPorts,=20 rbridgeSnoopingAddrPorts)=20 W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should = have=20 SIZE specified=20 rbridgeMultiFibPorts OBJECT-TYPE=20 SYNTAX PortList=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The list of ports to which a frame destined to this=20 multicast distribution tree is flooded. This may be = pruned=20 further based on other forwarding information."=20 ::=3D { rbridgeMultiFibEntry 2 }=20 Q-BRIDGE-MIB defines:=20 PortList ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "Each octet within this value specifies a set of eight=20 ports, with the first octet specifying ports 1 through=20 8, the second octet specifying ports 9 through 16, etc.=20 Within each octet, the most significant bit represents=20 the lowest numbered port, and the least significant bit=20 represents the highest numbered port. Thus, each port=20 of the bridge is represented by a single bit within the=20 value of this object. If that bit has a value of '1'=20 then that port is included in the set of ports; the port=20 is not included if its bit has a value of '0'."=20 SYNTAX OCTET STRING=20 OCTET STRING is 0..65535 characters.=20 Consider that a range of 0..255 would give 8*256 =3D=3D 2048 Ports = Are more ports needed?=20 * Both compilers warn about rbridgeSnoopingEntry=20 The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 = byes,=20 so=20 why=20 is this=20 not indicated? (An example is below.)=20 rbridgeSnoopingAddrType OBJECT-TYPE=20 SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2)} = MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The IP multicast address type for which a listener has = been=20 detected by this RBridge. This MIB requires support for = only=20 IPv4 and IPv6 address types."=20 REFERENCE=20 "RFC 6325 section 4.7"=20 ::=3D { rbridgeSnoopingAddrEntry 1 }=20 rbridgeSnoopingAddr OBJECT-TYPE=20 SYNTAX InetAddress (SIZE(0|4|16))=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The IP multicast address for which a listener has been = detected by this RBridge. The address type of this = object=20 is specified in rbridgeSnoopingAddrType. This MIB = requires=20 support for only global IPv4 and IPv6 addresses, so the = length of the object can be either 4 or 16 bytes."=20 REFERENCE=20 "RFC 6325 section 4.7"=20 ::=3D { rbridgeSnoopingAddrEntry 2 }=20 * Suggested OID layout is not as Specified in the MIB Guidelines=20 document:=20 xxxMIB=20 |=20 +-- xxxNotifications(0)=20 +-- xxxObjects(1)=20 +-- xxxConformance(2)=20 |=20 +-- xxxCompliances(1)=20 +-- xxxGroups(2)=20 Compliances and Groups are reversed in the MIB draft.=20 INDEXING=20 =3D=3D=3D=3D=3D=3D=3D=3D=20 I am a little concerned about the Indexing in this MIB, only = because=20 it=20 looks like several table=20 should really have an AUGMENTS relationship.=20 INDEX { rbridgeBaseNicknameName }=20 INDEX { rbridgeBasePort }=20 INDEX { rbridgeFdbId, rbridgeUniFdbAddr }=20 INDEX { rbridgeUniFibNickname, rbridgeUniFibPort,=20 INDEX { rbridgeMultiFibNickname }=20 INDEX { rbridgeVlanIndex }=20 INDEX { rbridgeBasePort, rbridgeVlanIndex }=20 INDEX { rbridgeBasePort }=20 INDEX { rbridgeVlanIndex }=20 INDEX { rbridgeBasePort }=20 INDEX { rbridgeVlanIndex, rbridgeSnoopingAddrType,=20 INDEX { rbridgeDtreeNumber }=20 INDEX { rbridgeTrillNbrMacAddr }=20 * Conformance Statement.=20 Same comment as on the prior draft. Still no read-only and full=20 conformance.=20 This is okay, but want to make sure that working group is "okay" = with=20 having=20 to do a full conformance (i.e. support read-write and read-create = via=20 SNMP)?=20 ----- Original Message -----=20 From: "Bert Wijnen (IETF)" =20 To: =20 Cc: ; ;=20 =20 Sent: Tuesday, April 10, 2012 4:53 AM=20 Subject: Re: [MIB-DOCTORS] Help with conformance statements=20 > From a quick read that I did (section 6.7), then it=20 > indeed seems to specify a set of requirements (even in=20 > MUST) language for the ISIS-MIB module. So here (in=20 > sect 6.7) they are described in English.=20 >=20 > It would indeed be useful to have that documented=20 > in machine readable format, i.e. in (or as part of)=20 > a MODULE-COMPLIANCE statement.=20 >=20 > Is it a reason to hold up the document?=20 > Not sure about that. At the time when I was AD, I=20 > tried to strongly encourage people to express such=20 > requirements in the form of MODULE_COMPLIANCE=20 > statements. But that was/is my view.=20 >=20 > Maybe other MIB doctors do have an opinion on that.=20 >=20 > Bert=20 >=20 > On 4/8/12 10:34 PM, Adrian Farrel wrote:=20 >> Hi,=20 >>=20 >> Is there a MIB Doctor that can help us?=20 >>=20 >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt=20 >>=20 >> It reads...=20 >>=20 >>> I would like help from the OPS ADs (and MIB Doctors) on this=20 point:=20 >>>=20 >>> It seems to me that section 6.7 needs a new conformance = statement=20 to=20 >>> be applied to ISIS-MIB. The text in the section appears to be = in=20 two=20 >>> parts:=20 >>>=20 >>> - Implementation guidance (what value to return on a GET from = a=20 Trill=20 >>> implementation)=20 >>>=20 >>> - Implementation requirements (which tables/objects to = implement=20 or=20 >>> not (conformance statement).=20 >>=20 >> Can anyone tell me if I am right or wrong.=20 >>=20 >> Thanks,=20 >> Adrian=20 >>=20 >>=20 >> _______________________________________________=20 >> MIB-DOCTORS mailing list=20 >> MIB-DOCTORS@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/mib-doctors=20 >>=20 > _______________________________________________=20 > MIB-DOCTORS mailing list=20 > MIB-DOCTORS@ietf.org=20 > https://www.ietf.org/mailman/listinfo/mib-doctors=20 _______________________________________________=20 MIB-DOCTORS mailing list=20 MIB-DOCTORS@ietf.org=20 https://www.ietf.org/mailman/listinfo/mib-doctors=20 _______________________________________________=20 MIB-DOCTORS mailing list=20 MIB-DOCTORS@ietf.org=20 https://www.ietf.org/mailman/listinfo/mib-doctors=20 ------=_NextPart_000_5C21_01CDA20F.6A1A4C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Benoit,
 
Thanks for the info about version = 9.  =20 I'll try to have a more thorough review done by Tues.
 
Thanks,
  -Joan
 
----- Original Message -----
From:=20 Benoit = Claise=20
Cc: Romascanu, Dan (Dan) ; Bert = Wijnen=20 (IETF) ; adrian@olddog.co.uk ; mib-doctors@ietf.org ; draft-ietf-tr= ill-rbridge-mib@tools.ietf.org=20 ; ops-ads@tools.ietf.org ; Ralph=20 Droms
Sent: Wednesday, October 03, = 2012 5:21=20 AM
Subject: Re: [MIB-DOCTORS]=20 draft-ietf-trill-rbridge-mib-08

Hi Joan,

Thanks for your = review.
Let me=20 update the DISCUSS/COMMENT with your feedback below.
Do you know = when you=20 will have the time to review the MIB module?
Note that the authors = posted a=20 new version of the MIB module, addressing one DISCUSS point:
The IETF datatracker page for this =
Internet-Draft is:
h=
ttps://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-rbridge-mib-09=


Regards,=20 Benoit.
Dan,=20

I have not reviewed this draft, however a quick scan reveals = that 3=20 comments made during
MIB Dr. review have not been addressed: =

1)=20 The Indexing.

INDEX  { rbridgeBasePort } is used as an = index in=20 several tables and the relationship
should really be an=20 AUGMENTS.    Not sure why this was not done. =

2)
* Suggested OID layout is not as Specified = in the=20 MIB Guidelines
document:

  xxxMIB=20
         |=20
         +--=20 xxxNotifications(0) =
        =20 +-- xxxObjects(1) =
         +--=20 xxxConformance(2)=20 =
           &nb= sp;=20 |=20 =
           &nb= sp;=20 +-- xxxCompliances(1)=20 =
           &nb= sp;=20 +-- xxxGroups(2)


Compliances and Groups are reversed = in the=20 MIB draft.



3)  the Conformance = is a full=20 conformance which contains read-create and
read-write=20 objects.   I raised this as a concern as part of the MIB = Dr rview=20
and asked that the WG be informed that in order to be compliant = with the=20 MIB,
they will need to support SNMP sets.

While not = technically=20 wrong, my experience is having both a read-only and full conformance = in a=20 MIB
which contains sets, allows more flexibility for those that = do not=20 configure their products using
SNMP.   This allows = them to be=20 compliant with the RFC, and I believe that the WG needs to
be = made aware=20 of this, since most MIBs from the IETF in recent history have a = read-only=20 conformance.
I asked the authors to confirm with the WG that = this is=20 what the WG wants, but did not see any emails to the WG on the list. =
I=20 may have missed the email, or they may have confirmed this in some = other=20 way, but I am not aware.


Will do a more thorough check = on other=20 MIB Dr. review comments later, but think these 3 are critical and = should be=20
discussed/followed-up.

Thanks,
 -Joan =


-----=20 Original Message ----- From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> =
To:=20 "Joan Cucchiara" <jcucchiara@mindspring.com&g= t;;=20 "Bert Wijnen (IETF)" <bertietf@bwijnen.net>; = <adrian@olddog.co.uk> =
Cc: <mib-doctors@ietf.org>; = <draft-iet= f-trill-rbridge-mib@tools.ietf.org>;=20 <ops-ads@tools.ietf.org>= ;=20 "Ralph Droms" <rdroms.ietf@gmail.com>=20
Sent: Monday, October 01, 2012 5:06 AM
Subject:=20 draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with=20 conformance statements)


Hi Joan,

Version=20 draft-ietf-trill-rbridge-mib-08 of this document was submitted =
and=20 Benoit needs conformation that all critical issues were resolved =
before=20 he approves the document. Did you have the time to check 08 and =
can you=20 confirm this?

Other MIB doctors advice is of course welcome. =

Thanks and Regards,

Dab




-----Original Message-----
From: mib-doctors-bounces@ietf.org= =20
[mailto:mib-doctors-bounces@i= etf.org]=20
On Behalf Of Joan Cucchiara
Sent: = Tuesday,=20 April 10, 2012 9:35 PM
To: Bert Wijnen (IETF); adrian@olddog.co.uk =
Cc: mib-doctors@ietf.org; draft-ietf-tr= ill-rbridge-mib@tools.ietf.org;=20
ops-ads@tools.ietf.org=20
Subject: Re: [MIB-DOCTORS] Help with conformance statements=20

Adrian and Bert,

I think it would be very helpful = if the=20 authors could specify ISIS
objects in a MODULE_COMPLIANCE as = Bert=20 suggests.

When I reviewed version 6 of the MIB, I asked if = the=20 authors could
ensure that WG was aware there is no read-only=20
compliance and this point was not addressed in version 7 = either.=20
Not
a
MUST, but certainly want to make = sure=20
that the WG is aware they need to support read-create and = read-write=20
via
SNMP.

Additionally, there are some = warnings from the MIB compilers that were
also there in = version 6 and=20 I'd like to see those addressed in the
document (either = discussed or=20 fixed).  My comments below were emailed
to =
the authors.

fyi,
  -Joan =



* LAST-UPDATED and REVISION clauses  have the = same=20 date as Version 6


OUTPUT from SMICNGPRO=20
-----------------------

W: f(RBRIDGE-MIB.my), (921,20) = Item=20 "rbridgeMultiFibPorts" should have
SIZE specified
W:=20 f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has=20
indexing that may create variables with more than 128 sub-ids =
W:=20 f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" = should=20
have SIZE specified
W: f(RBRIDGE-MIB.my), (1044,18) Row=20 "rbridgeVlanPortEntry" does not
have
a consistent indexing scheme - cannot = specify an=20 index item from
additional "base row" rbridgeBasePortEntry, = since can=20 have only one
"base row" which is rbridgeVlanEntry =


SMILINT=20
-----------

mibs/RBRIDGE-MIB.my:1453: [5]=20 {index-exceeds-too-large} warning: index
of row=20 `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142=20
subidentifier(s)

Additional descriptions of some = error/warning=20 messages:

Error:      =20 index-element-no-size (level 3) =
Message:     index=20 element `%s' of row `%s' must have a size =
restriction
Description: Object identifiers are = restricted in=20 size to have at most
128=20 =
           &nb= sp;=20 sub-identifiers. This implies that index elements used to
form = =
           &nb= sp;=20 instance identifiers must have a size contraint which
ensures=20 =
           &nb= sp;=20 that the 128 sub-identifier constraint is kept intact for
any=20 =
           &nb= sp;=20 possible combination of the index elements' values (RFC
2578,=20 =
           &nb= sp;=20 Section 3.5).


*  Looking at the objects with TC = of=20 PortList (rbridgeMultiFibPorts,
rbridgeSnoopingAddrPorts) =

W:=20 f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should = have=20
SIZE specified


   rbridgeMultiFibPorts=20 OBJECT-TYPE
      =20 SYNTAX      PortList=20
       MAX-ACCESS  = read-only=20
      =20 STATUS      current=20
       DESCRIPTION=20
           = "The list=20 of ports to which a frame destined to this=20
           = multicast=20 distribution tree is flooded. This may be pruned=20
           = further=20 based on other forwarding information."=20
       ::=3D { = rbridgeMultiFibEntry 2 }=20

Q-BRIDGE-MIB defines:
PortList ::=3D = TEXTUAL-CONVENTION=20
    STATUS      = current=20
    DESCRIPTION=20
        "Each octet within = this=20 value specifies a set of eight=20
        ports, with the = first octet=20 specifying ports 1 through =
       =20 8, the second octet specifying ports 9 through 16, etc.=20
        Within each octet, = the most=20 significant bit represents =
       =20 the lowest numbered port, and the least significant bit=20
        represents the = highest=20 numbered port.  Thus, each port=20
        of the bridge is=20 represented by a single bit within the=20
        value of this = object. =20 If that bit has a value of '1'=20
        then that port is = included=20 in the set of ports; the port=20
        is not included if = its bit=20 has a value of '0'."
   =20 SYNTAX      OCTET STRING

OCTET = STRING is=20 0..65535 characters.

Consider that a range of 0..255 would = give=20 8*256 =3D=3D 2048 Ports
Are more ports needed? =



* Both=20 compilers warn about rbridgeSnoopingEntry

The DESCRIPTION = clause=20 indicates that IPv4 and IPv6 so 4 or 16 byes,
so =
why
is this
not indicated?  = (An=20 example is below.)

   rbridgeSnoopingAddrType=20 OBJECT-TYPE
      =20 SYNTAX      InetAddressType { unknown(0), = ipv4(1), ipv6(2)}
      =20 MAX-ACCESS  not-accessible =
      =20 STATUS      current=20
       DESCRIPTION=20
           = "The IP=20 multicast address type for which a listener has =
been
          = ;=20 detected by this RBridge. This MIB requires support for=20
only
          = ;=20 IPv4 and IPv6 address types." =
      =20 REFERENCE =
          =20 "RFC 6325 section 4.7"
       = ::=3D {=20 rbridgeSnoopingAddrEntry 1 }

   = rbridgeSnoopingAddr=20 OBJECT-TYPE
      =20 SYNTAX      InetAddress (SIZE(0|4|16))=20
       MAX-ACCESS  = not-accessible=20
      =20 STATUS      current=20
       DESCRIPTION=20
           = "The IP=20 multicast address for which a listener has been=20
           = detected=20 by this RBridge. The address type of this object=20
           = is=20 specified in rbridgeSnoopingAddrType. This MIB requires=20
           = support=20 for only global IPv4 and IPv6 addresses, so the=20
           = length of=20 the object can be either 4 or 16 bytes."=20
       REFERENCE=20
           = "RFC 6325=20 section 4.7"
       ::=3D {=20 rbridgeSnoopingAddrEntry 2 }



* Suggested OID = layout is not=20 as Specified in the MIB Guidelines
document:

  = xxxMIB=20
         |=20
         +--=20 xxxNotifications(0) =
        =20 +-- xxxObjects(1) =
         +--=20 xxxConformance(2)=20 =
           &nb= sp;=20 |=20 =
           &nb= sp;=20 +-- xxxCompliances(1)=20 =
           &nb= sp;=20 +-- xxxGroups(2)


Compliances and Groups are reversed = in the=20 MIB draft.


INDEXING
=3D=3D=3D=3D=3D=3D=3D=3D
I = am a little concerned=20 about the Indexing in this MIB, only because
it =
looks like several table
should really = have an=20 AUGMENTS relationship. =

      =20 INDEX  { rbridgeBaseNicknameName }=20
       INDEX  { = rbridgeBasePort }=20
       INDEX   { = rbridgeFdbId,=20 rbridgeUniFdbAddr }
      =20 INDEX   { rbridgeUniFibNickname, rbridgeUniFibPort,=20
       INDEX   {=20 rbridgeMultiFibNickname }
       = INDEX   { rbridgeVlanIndex }=20
       INDEX   {=20 rbridgeBasePort, rbridgeVlanIndex }=20
       INDEX   {=20 rbridgeBasePort }
      =20 INDEX   { rbridgeVlanIndex }=20
       INDEX   {=20 rbridgeBasePort }
       = INDEX  {=20 rbridgeVlanIndex, rbridgeSnoopingAddrType,=20
       INDEX  { = rbridgeDtreeNumber=20 }
       INDEX  {=20 rbridgeTrillNbrMacAddr }



* Conformance Statement. =
Same=20 comment as on the prior draft.  Still no read-only and full=20
conformance.
This is okay, but want to make sure that = working=20 group is "okay" with
having
to do a full conformance (i.e. = support=20 read-write and read-create via
SNMP)?


----- = Original=20 Message -----
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>=20
To: <adrian@olddog.co.uk> =
Cc:=20 <mib-doctors@ietf.org>;=20 <draft-ietf-trill-rbridge-
mib@tools.ietf.org>; =
<ops-ads@tools.ietf.org>= =20
Sent: Tuesday, April 10, 2012 4:53 AM
Subject: Re: = [MIB-DOCTORS]=20 Help with conformance statements


> From a quick = read that I=20 did (section 6.7), then it
> indeed seems to specify a set = of=20 requirements (even in
> MUST) language for the ISIS-MIB = module. So=20 here (in
> sect 6.7) they are described in English. =
>=20
> It would indeed be useful to have that documented =
> in=20 machine readable format, i.e. in (or as part of)
> a=20 MODULE-COMPLIANCE statement.
>
> Is it a reason to = hold up=20 the document?
> Not sure about that. At the time when I was = AD, I=20
> tried to strongly encourage people to express such =
>=20 requirements in the form of MODULE_COMPLIANCE
> statements. = But=20 that was/is my view.
>
> Maybe other MIB doctors do = have an=20 opinion on that.
>
> Bert
>
> On = 4/8/12 10:34=20 PM, Adrian Farrel wrote:
>> Hi,
>> =
>> Is=20 there a MIB Doctor that can help us?
>>
>> I = am=20 holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt =
>>=20
>> It reads...
>>
>>> I would = like help=20 from the OPS ADs (and MIB Doctors) on this
point: =
>>>
>>> It seems to = me that=20 section 6.7 needs a new conformance statement
to =
>>> be applied to ISIS-MIB. The = text in=20 the section appears to be in
two
>>> parts:
>>>=20
>>> - Implementation guidance (what value to return = on a GET=20 from a
Trill
>>>   implementation)=20
>>>
>>> - Implementation requirements = (which=20 tables/objects to implement
or
>>> not  (conformance = statement).=20
>>
>> Can anyone tell me if I am right or = wrong.=20
>>
>> Thanks,
>> Adrian
>> =
>>
>> = _______________________________________________=20
>> MIB-DOCTORS mailing list
>> MIB-DOCTORS@ietf.org =
>>=20 https://www.ie= tf.org/mailman/listinfo/mib-doctors=20
>>
> = _______________________________________________=20
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org =
> https://www.ie= tf.org/mailman/listinfo/mib-doctors=20

_______________________________________________ =
MIB-DOCTORS=20 mailing list
MIB-DOCTORS@ietf.org =
https://www.ie= tf.org/mailman/listinfo/mib-doctors=20

_______________________________________________=20
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ie= tf.org/mailman/listinfo/mib-doctors=20



------=_NextPart_000_5C21_01CDA20F.6A1A4C90-- From bclaise@cisco.com Fri Oct 5 00:28:28 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9321F8467; Fri, 5 Oct 2012 00:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.702 X-Spam-Level: X-Spam-Status: No, score=-8.702 tagged_above=-999 required=5 tests=[AWL=1.897, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs7hm9IIFevD; Fri, 5 Oct 2012 00:28:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD721F8437; Fri, 5 Oct 2012 00:28:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q957SKGb025985; Fri, 5 Oct 2012 09:28:21 +0200 (CEST) Received: from [10.55.81.34] (dhcp-10-55-81-34.cisco.com [10.55.81.34]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q957SJwI011192; Fri, 5 Oct 2012 09:28:20 +0200 (CEST) Message-ID: <506E8C13.40700@cisco.com> Date: Fri, 05 Oct 2012 09:28:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> In-Reply-To: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-10-11 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 07:28:28 -0000 Dear all, Please find below the agenda of the October 11th IESG telechat. Please send your questions, comments and concerns before October 11 COB. Thanks and Regards, Benoit. ============================================= INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-10-11 IESG Teleconference This agenda was generated at 2012-10-04 14:56:09 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-storm-iscsi-cons-07 iSCSI Protocol (Consolidated) (Proposed Standard) Note: David Black (david.black@emc.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-fecframe-ldpc-03 Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME (Proposed Standard) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd Token: Martin Stiemerling o draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol version 2 (Proposed Standard) Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-6man-dad-proxy-05 Duplicate Address Detection Proxy (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the Document Shepherd. Token: Brian Haberman o draft-ietf-v6ops-ivi-icmp-address-06 Stateless Source Address Mapping for ICMPv6 Packets (Best Current Practice) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-dnsext-rfc6195bis-04 Domain Name System (DNS) IANA Considerations (Best Current Practice) Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-sipcore-proxy-feature-11 Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP) (Proposed Standard) Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the Document Shepherd Token: Robert Sparks o draft-ietf-abfab-gss-eap-naming-06 Name Attributes for the GSS-API EAP mechanism (Proposed Standard) Token: Stephen Farrell o draft-ietf-6man-udpchecksums-04 UDP Checksums for Tunneled Packets (Proposed Standard) Token: Brian Haberman 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-fecframe-pseudo-cdp-04 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework (Informational) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd Token: Martin Stiemerling o draft-ietf-6man-udpzero-06 IPv6 UDP Checksum Considerations (Informational) Token: Brian Haberman 3.1.2 Returning Items o draft-ietf-avtext-splicing-for-rtp-09 Content Splicing for RTP Sessions (Informational) Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd. Token: Gonzalo Camarillo 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-mme-trill-fcoe-01 IETF conflict review for draft-mme-trill-fcoe (None) Token: Ralph Droms 3.3.2 Returning Items NONE 3.3.3 For Action o conflict-review-pornin-deterministic-dsa-00 IETF conflict review for draft-pornin-deterministic-dsa (None) Token: Sean Turner 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Bidirectional Forwarding Detection (bfd) 4.2.2 Proposed for Approval o Operations and Management Area Working Group (opsawg) From jcucchiara@mindspring.com Tue Oct 9 21:19:49 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7981311E80CC for ; Tue, 9 Oct 2012 21:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_40=-0.185, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LRtDoQji8cG for ; Tue, 9 Oct 2012 21:19:48 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 44FBF1F0429 for ; Tue, 9 Oct 2012 21:19:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MT5oc/Bpmp9P5TFF8wznMwNTMcN6TLN+ReBtB0KPR4TwrF+S3/q2WZAaKr348GVy; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TLnlk-0000lF-Q3; Wed, 10 Oct 2012 00:19:40 -0400 Message-ID: <001601cda69e$2c7e4a10$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Joan Cucchiara" , "Benoit Claise" References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net><004a01cd1748$b03f1220$6701a8c0@JoanPC><5aa901cda09b$f53e7aa0$6801a8c0@JoanPC><506C03B2.9060902@cisco.com> <5c2401cda230$f1ce2000$6801a8c0@JoanPC> Date: Wed, 10 Oct 2012 00:17:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CDA67C.A4DFFA70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654082e9220aa42b6108b6f5cab44a180faa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mib-doctors@ietf.org, draft-ietf-trill-rbridge-mib@tools.ietf.org, ops-ads@tools.ietf.org, Ralph Droms , adrian@olddog.co.uk Subject: [MIB-DOCTORS] MIB Dr review of draft-ietf-trill-rbridge-mib-09 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 04:19:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CDA67C.A4DFFA70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The following is a review of version 9. Many prior comments have been = updated and are reflected in this new draft, so Thank you for that.=20 -Joan Output from smicngPro: W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the last = update for MODULE-IDENTITY rbridgeMIB W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should have = SIZE specified W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has = indexing that may create variables with more than 128 sub-ids W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" should = have SIZE specified W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not have = a consistent indexing scheme - cannot specify an index item from = additional "base row" rbridgeBasePortEntry, since can have only one = "base row" which is rbridgeVlanEntry Output from SmiLint: mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date after = last update mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last update = is missing mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: index = of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 = subidentifier(s) Additional descriptions of some error/warning messages: Error: index-element-no-size (level 3) Message: index element `%s' of row `%s' must have a size restriction Description: Object identifiers are restricted in size to have at most = 128 sub-identifiers. This implies that index elements used to = form instance identifiers must have a size contraint which = ensures that the 128 sub-identifier constraint is kept intact for = any possible combination of the index elements' values (RFC = 2578, Section 3.5). *) rbridgeBaseTrillVersion According to RFC6325, this is a 2 bit field and you have 4 bytes. Please clarify. Unsigned32(0..3). DEFVAL(0) <-- only version supported right now. *) rbridgeBaseForwardDelay According to RFC6325, should have a DEFVAL of 15 seconds. *) rbridgeBaseAcceptEncapNonadj according to RFC6325, should have: DEFVAL(false) *) rbridgeBaseNicknameNumber Please add: "Additionally, this value represents the maximum amount of entries in the rbridgeBaseNicknameTable." Why doesn't this have a DEFVAL(1) as specified in RFC6325? Also, you should add a REFERENCE clause RFC6325, Section 5.1. *) rbridgeBaseNicknameTable Please clarify in the Table's DESCRIPTION clause that this table represents nickname information which is configured by an operator OR learned dynaically by the Rbridge. *)rbridgeBaseNicknamePriority This DESCRIPTION needs additional information. When nickname is configured, the most significant bit (0x80) MUST be set AND the bottom 7 bits have the default value of 0x40, so 0x80 + 0x40 =3D=3D 0xC0 which is 192 decimal. Additionally, the bottom 7 bits could be configured to value other than 0x40. However, if a row is created due to the nickname dynamically created, then the most significant bit (0x80) MUST NOT be set. =20 *) rbridgeBasePortTable Please check REFERENCE clauses for this table. I think you mean section 5.3 (not 5.2). *) rbridgeBasePort Where did you get the range for this Index? I think you should define a TC for this Value. This is used as an index for this table, and is used in several other tables as an index, thus a TC would be better. *)I asked this in a prior review, but could you specify the ifType associated with the ifIndex, i.e. physical layer? *)Please specify what the value is when the bit is set (i.e. true). Please check this throughout the MIB because while the DESCRIPTION clauses are more specific, there are places where the value of true/false is not specified for TruthValue *) rbridgeBasePortStpRootChanges Please remove UNITS clause. The units is a count and we know that already. Probably discontinuities can occur if this port changes status also (please see ifCounterDiscontinuityTime in RFC2863). =20 *) rbridgeConfidenceNative Need to add DEFVAL (32) *) rbridgeConfidenceDecap Need to add DEFVAL (32) *) rbridgeFdbId -- Why is this not rbridgeUniFdbId? The naming should be consistent for the objects in this table. More importantly, where does this value come from? Could you give a reference? My concern is that it may be more advantageous to index by the MAC addr directly, or ( Port, Mac) so I'm not sure where I see the advantage of=20 having an additional index which doesn't appear to be used anywhere else. Please clarify. *)rbridgeUniFdbPort DESCRIPTION clause mentions rbridgeUniFdbAddress but I think the object is rbridgeUniFdbAddr? *)rbridgeUniFdbNickname AND in other places,=20 the term "rbridgeFdbAddress" is used, but this isn't defined anywhere that I can see. I think you mean rbridgeUniFdbAddr? Also, "FdbId", I think should be rbridgeFdbId? *) rbridgeVlanIndex=20 Why was VlanIndex from Q-BRIDGE-MIB not used? *) rbridgeVlanForwarderLosts Please remove the UNITS clause. Probably discontinuities can occur if this port changes status also (please see ifCounterDiscontinuityTime in RFC2863). =20 *) rbridgePortCounterEntry Why is AUGMENTS not used here? Using AUGMENTS is actually quite meaningful here and I asked about this in a prior review. Please clarify. Additionally, the naming should be consistent with the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc. UNITS clauses for these counters can be removed. The UNIT is a count, so kind of redundant. *rbridgeVlanPortTable Please check the TruthValue objects in this table (and elsewhere)=20 to ensure that the value of true(1) and false(2) are clearly stated. *) rbridgeEsadiTable I think this table AUGMENTS or sparsely AUGMENTS the rbridgeVlanTable. Please add wording to the DESCRIPTION of the table/entry and, if = appropriate, change the INDEX to an AUGMENTS. *) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime The REFERENCE clause could be better, since I couldn't find the size of the priority anywhere in this section. *) rbridgeSnoopingPortTable This table seems to sparsely augment the rbridgeBasePortTable and the rbridgePortCounterTable. That should be discussed in the table/entry DESCRIPTION. The IPv4 and IPv6 needs to be specified in the Conformance Section. *) rbridgeDtreePriority A default value is specified in DESCRIPTION but this needs a proper DEFVAL clause. *) rbridgeDtreeActiveTrees Should this be a Gauge32? *) rbridgeTrillMinMtuDesired Should this have a DEFVAL of 1470 Octets? (just asking) *) rbridgeTrillMaxMtuProbes Why does this value need to be saved after reinitializations? *) rbridgeBaseTopologyChange Please remove the term "trap". SNMPv1 had a mechanism called trap, but these are Notifications. what is meant by "if a newDrb trap is sent for the same transition". Do you mean the "rbridgeBaseNewDrb" notification? Conformance and Group --------------------- *) As mentioned prior, the Compliances and Groups are reversed order. *) Also, as mentioned prior, this conformance does not have a read-only version. While not technically incorrect, most recent MIBs support a Full Conformance and a Read-only Conformance. =20 Have you confirmed with the WG that this is what they want and if they will implement this MIB as written? --- end of review ------ ------=_NextPart_000_0013_01CDA67C.A4DFFA70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
The following is a review of version = 9.  =20 Many prior comments have been updated
and are reflected in this new draft, so = Thank you=20 for that. 
 
-Joan
 

Output from smicngPro:
W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the = last=20 update for MODULE-IDENTITY rbridgeMIB
W: f(RBRIDGE-MIB.my), (919,20) = Item=20 "rbridgeMultiFibPorts" should have SIZE specified
W: = f(RBRIDGE-MIB.my),=20 (1452,4) Row "rbridgeSnoopingAddrEntry" has indexing that may create = variables=20 with more than 128 sub-ids
W: f(RBRIDGE-MIB.my), (1502,20) Item=20 "rbridgeSnoopingAddrPorts" should have SIZE specified
W: = f(RBRIDGE-MIB.my),=20 (1043,18) Row "rbridgeVlanPortEntry" does not have a consistent indexing = scheme=20 - cannot specify an index item from additional "base row" = rbridgeBasePortEntry,=20 since can have only one "base row" which is rbridgeVlanEntry
 

Output from SmiLint:
mibs/RBRIDGE-MIB.my:47: [3]=20 {revision-after-update} revision date after last=20 update
mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for = last=20 update is missing
mibs/RBRIDGE-MIB.my:1452: [5] = {index-exceeds-too-large}=20 warning: index of row `rbridgeSnoopingAddrEntry' can exceed OID size = limit by=20 142 subidentifier(s)
 
Additional descriptions of some error/warning messages:
 
Error:       index-element-no-size = (level=20 3)
Message:     index element `%s' of row `%s' = must have=20 a size restriction
Description: Object identifiers are restricted in = size to=20 have at most=20 128
           =  =20 sub-identifiers. This implies that index elements used to=20 form
           = ; =20 instance identifiers must have a size contraint which=20 ensures
          &n= bsp; =20 that the 128 sub-identifier constraint is kept intact for=20 any
           =  =20 possible combination of the index elements' values (RFC=20 2578,
          &nbs= p; =20 Section 3.5).
 
 
 

*) rbridgeBaseTrillVersion
According to RFC6325, this is a 2 = bit=20 field and you
have 4 bytes.  Please clarify.
 
Unsigned32(0..3).
 
DEFVAL(0) <-- only version supported right now.
 

*) rbridgeBaseForwardDelay
According to RFC6325, should have = a=20 DEFVAL of 15 seconds.
 
*) rbridgeBaseAcceptEncapNonadj
according to RFC6325, should=20 have:
DEFVAL(false)
 
*) rbridgeBaseNicknameNumber
Please add:
"Additionally, this = value=20 represents the maximum amount
of entries in the=20 rbridgeBaseNicknameTable."
 
Why doesn't this have a DEFVAL(1) as specified = in
RFC6325?  =20 Also, you should add a REFERENCE clause
RFC6325, Section 5.1.
 
*) rbridgeBaseNicknameTable
Please clarify in the Table's = DESCRIPTION=20 clause that
this table represents nickname information which is=20 configured
by an operator OR learned dynaically by the Rbridge.
 

*)rbridgeBaseNicknamePriority
This DESCRIPTION needs = additional=20 information.
When nickname is configured, the most significant
bit = (0x80)=20 MUST be set AND the bottom 7 bits
have the default value of 0x40, so = 0x80 +=20 0x40 =3D=3D 0xC0
which is 192 decimal.   Additionally, the = bottom 7=20 bits
could be configured to value other than 0x40.
 
However, if a row is created due to the nickname
dynamically = created,=20 then the most significant bit (0x80) MUST NOT
be set.   =
 
*) rbridgeBasePortTable
Please check REFERENCE clauses for this=20 table.
I think you mean section 5.3 (not 5.2).
 

*) rbridgeBasePort
Where did you get the range for this = Index?
I=20 think you should define a TC for this Value.
This is used as an index = for=20 this table, and is used
in several other tables as an index, thus a = TC=20 would
be better.
 

*)I asked this in a prior review, but could you specify
the = ifType=20 associated with the ifIndex, i.e. physical
layer?
 

*)Please specify what the value is when the bit is set (i.e.=20 true).
Please check this throughout the MIB because while the=20 DESCRIPTION
clauses are more specific, there are places where the = value
of=20 true/false is not specified for TruthValue
 

*) rbridgeBasePortStpRootChanges
Please remove UNITS = clause. =20 The units is a count and
we know that already.
 
Probably discontinuities can occur if this port changes
status = also=20 (please see ifCounterDiscontinuityTime
in RFC2863). 
 

*) rbridgeConfidenceNative
Need to add DEFVAL (32)
 
*) rbridgeConfidenceDecap
Need to add DEFVAL (32)
 
*) rbridgeFdbId -- Why is this not rbridgeUniFdbId?
The naming = should be=20 consistent for the objects in this
table.
 
More importantly, where does this value come from?
Could you = give a=20 reference?
My concern is that it may be more advantageous to
index = by the=20 MAC addr directly, or ( Port, Mac)
so I'm not sure where I see the = advantage=20 of
having an additional index which doesn't appear
to be used = anywhere=20 else.
Please clarify.
 
*)rbridgeUniFdbPort DESCRIPTION clause
mentions = rbridgeUniFdbAddress but=20 I think the object is
rbridgeUniFdbAddr?
 
*)rbridgeUniFdbNickname AND in other places,
the term=20 "rbridgeFdbAddress" is used, but this isn't defined
anywhere that I = can=20 see.  I think you mean rbridgeUniFdbAddr?
 
Also, "FdbId", I think should be rbridgeFdbId?
 

*) rbridgeVlanIndex
Why was VlanIndex from Q-BRIDGE-MIB not = used?
 
*) rbridgeVlanForwarderLosts
Please remove the UNITS = clause.
 
Probably discontinuities can occur if this port changes
status = also=20 (please see ifCounterDiscontinuityTime
in RFC2863). 
 

*) rbridgePortCounterEntry
Why is AUGMENTS not used = here?
Using=20 AUGMENTS is actually quite meaningful here and
I asked about this in = a prior=20 review.  Please clarify.
Additionally, the naming should be = consistent=20 with
the rbridgeBasePortTable (so rbridgeBasePortCounterTable) = etc.
 

UNITS clauses for these counters can be removed.
The UNIT is = a=20 count, so kind of redundant.
 

*rbridgeVlanPortTable
 
Please check the TruthValue objects in this table (and elsewhere) =
to=20 ensure that the value of true(1) and false(2) are clearly stated.
 
*) rbridgeEsadiTable
I think this table AUGMENTS or sparsely = AUGMENTS=20 the rbridgeVlanTable.
Please add wording to the DESCRIPTION of the=20 table/entry and, if appropriate,
change the INDEX to an = AUGMENTS.
 
*) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime
The = REFERENCE=20 clause could be better, since I couldn't
find the size of the = priority=20 anywhere in this section.
 

*) rbridgeSnoopingPortTable
This table seems to sparsely = augment the=20 rbridgeBasePortTable
and the rbridgePortCounterTable.   = That should=20 be
discussed in the table/entry DESCRIPTION.
 
The IPv4 and IPv6 needs to be specified in the=20 Conformance
Section.
 

*) rbridgeDtreePriority
A default value is specified in = DESCRIPTION=20 but this
needs a proper DEFVAL clause.
 
*) rbridgeDtreeActiveTrees
Should this be a Gauge32?
 
*) rbridgeTrillMinMtuDesired
Should this have a DEFVAL of 1470 = Octets?=20 (just asking)
 
*) rbridgeTrillMaxMtuProbes
Why does this value need to be saved = after=20 reinitializations?
 
*) rbridgeBaseTopologyChange
Please remove the term = "trap".  SNMPv1=20 had a mechanism called
trap, but these are Notifications.
 
what is meant by "if a newDrb trap is sent for the same = transition".
Do=20 you mean the "rbridgeBaseNewDrb" notification?
 
Conformance and Group
---------------------
 
*) As mentioned prior, the Compliances and Groups are reversed = order.
 
*) Also, as mentioned prior, this conformance does not have a=20 read-only
version.  While not technically incorrect, most recent = MIBs=20 support
a Full Conformance and a Read-only Conformance.  =
Have you=20 confirmed with the WG that this is what they want and
if they will = implement=20 this MIB as written?
 
--- end of review ------
 
 
------=_NextPart_000_0013_01CDA67C.A4DFFA70-- From anil@charter.net Wed Oct 10 05:19:02 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BD21F86C8 for ; Wed, 10 Oct 2012 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZa7Zf463qMW for ; Wed, 10 Oct 2012 05:19:00 -0700 (PDT) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87C21F86C5 for ; Wed, 10 Oct 2012 05:18:59 -0700 (PDT) Received: from imp11 ([10.20.200.11]) by mta11.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20121010121858.QEEG10966.mta11.charter.net@imp11>; Wed, 10 Oct 2012 08:18:58 -0400 Received: from [192.168.1.107] ([66.189.33.199]) by imp11 with smtp.charter.net id 9QJy1k00L4Hn1RN05QJynU; Wed, 10 Oct 2012 08:18:58 -0400 X-Authority-Analysis: v=1.1 cv=Mv9Cy8NsQItTEAHnXr6fCNbI23lcrkmyMeqLv9HU3yU= c=1 sm=1 a=PXre7kIjtaAA:10 a=yUnIBFQkZM0A:10 a=EiiBzwjGkpP7seHRDOKx7g==:17 a=7CtPjRLeD8W-1_j-olgA:9 a=wPNLvfGTeEIA:10 a=2YDyF5VxgLqpWCfa:21 a=fDjrNJZIUNR3s4jF:21 a=7r6WZvrtGTUyUduK3pkA:9 a=_W_S_7VecoQA:10 a=xuBKsIFefO9_Y5_1:21 a=EiiBzwjGkpP7seHRDOKx7g==:117 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D41B0F1-8C10-4B8B-8745-BCD428B01B9B" From: Anil R X-Priority: 3 In-Reply-To: <001601cda69e$2c7e4a10$6801a8c0@JoanPC> Date: Wed, 10 Oct 2012 08:18:59 -0400 Message-Id: <43E282B1-9797-4687-8070-FC2462B68E29@charter.net> References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net><004a01cd1748$b03f1220$6701a8c0@JoanPC><5aa901cda09b$f53e7aa0$6801a8c0@JoanPC><506C03B2.9060902@cisco.com> <5c2401cda230$f1ce2000$6801a8c0@JoanPC> <001601cda69e$2c7e4a10$6801a8c0@JoanPC> To: "Joan Cucchiara" X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 10 Oct 2012 06:28:05 -0700 Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org, mib-doctors@ietf.org, ops-ads@tools.ietf.org, Ralph Droms , adrian@olddog.co.uk Subject: Re: [MIB-DOCTORS] MIB Dr review of draft-ietf-trill-rbridge-mib-09 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:19:02 -0000 --Apple-Mail=_7D41B0F1-8C10-4B8B-8745-BCD428B01B9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Joan, Sorry, you don't get multiple cracks at making yet another round of = comments on the same document. As you have noted below, most of your = prior comments have been addressed. We have to draw a line somewhere. This MIB has been held up for a year in IESG review! This has been = primarily due to your multiple rounds of "exhaustive reviews", most of = which have been nits or subjective opinions. Every time a new draft has = been published to address the previous round of comments, you have come = right back with a new round of comments. This is unprecedented in my = long experience of writing IETF MIBs. Versions -04 to -09 have been written to address IESG (mostly your) = comments. That is fully 60% of the drafts written. If you have so many comments, you should have been done so as part of = the TRILL working group. This is an IETF working group, and most of the = work is done in the IETF - not in the IESG. Please don't try to = influence or delay work from outside of a working group. I have contacted both the Internet AD and Operations AD. This non-stop = barrage of mib-doctor nits, apparently to prevent a document from moving = forward, is unacceptable to me and the working group, and should be = unacceptable to the IESG. We need to get this document published now. Thanks, Anil On Oct 10, 2012, at 12:17 AM, Joan Cucchiara wrote: > Hello, > =20 > The following is a review of version 9. Many prior comments have = been updated > and are reflected in this new draft, so Thank you for that.=20 > =20 > -Joan > =20 >=20 > Output from smicngPro: > W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the last = update for MODULE-IDENTITY rbridgeMIB > W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should have = SIZE specified > W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has = indexing that may create variables with more than 128 sub-ids > W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" should = have SIZE specified > W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not = have a consistent indexing scheme - cannot specify an index item from = additional "base row" rbridgeBasePortEntry, since can have only one = "base row" which is rbridgeVlanEntry > =20 >=20 > Output from SmiLint: > mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date = after last update > mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last = update is missing > mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: index = of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 = subidentifier(s) > =20 > Additional descriptions of some error/warning messages: > =20 > Error: index-element-no-size (level 3) > Message: index element `%s' of row `%s' must have a size = restriction > Description: Object identifiers are restricted in size to have at most = 128 > sub-identifiers. This implies that index elements used to = form > instance identifiers must have a size contraint which = ensures > that the 128 sub-identifier constraint is kept intact for = any > possible combination of the index elements' values (RFC = 2578, > Section 3.5). > =20 > =20 > =20 >=20 > *) rbridgeBaseTrillVersion > According to RFC6325, this is a 2 bit field and you > have 4 bytes. Please clarify. > =20 > Unsigned32(0..3). > =20 > DEFVAL(0) <-- only version supported right now. > =20 >=20 > *) rbridgeBaseForwardDelay > According to RFC6325, should have a DEFVAL of 15 seconds. > =20 > *) rbridgeBaseAcceptEncapNonadj > according to RFC6325, should have: > DEFVAL(false) > =20 > *) rbridgeBaseNicknameNumber > Please add: > "Additionally, this value represents the maximum amount > of entries in the rbridgeBaseNicknameTable." > =20 > Why doesn't this have a DEFVAL(1) as specified in > RFC6325? Also, you should add a REFERENCE clause > RFC6325, Section 5.1. > =20 > *) rbridgeBaseNicknameTable > Please clarify in the Table's DESCRIPTION clause that > this table represents nickname information which is configured > by an operator OR learned dynaically by the Rbridge. > =20 >=20 > *)rbridgeBaseNicknamePriority > This DESCRIPTION needs additional information. > When nickname is configured, the most significant > bit (0x80) MUST be set AND the bottom 7 bits > have the default value of 0x40, so 0x80 + 0x40 =3D=3D 0xC0 > which is 192 decimal. Additionally, the bottom 7 bits > could be configured to value other than 0x40. > =20 > However, if a row is created due to the nickname > dynamically created, then the most significant bit (0x80) MUST NOT > be set. =20 > =20 > *) rbridgeBasePortTable > Please check REFERENCE clauses for this table. > I think you mean section 5.3 (not 5.2). > =20 >=20 > *) rbridgeBasePort > Where did you get the range for this Index? > I think you should define a TC for this Value. > This is used as an index for this table, and is used > in several other tables as an index, thus a TC would > be better. > =20 >=20 > *)I asked this in a prior review, but could you specify > the ifType associated with the ifIndex, i.e. physical > layer? > =20 >=20 > *)Please specify what the value is when the bit is set (i.e. true). > Please check this throughout the MIB because while the DESCRIPTION > clauses are more specific, there are places where the value > of true/false is not specified for TruthValue > =20 >=20 > *) rbridgeBasePortStpRootChanges > Please remove UNITS clause. The units is a count and > we know that already. > =20 > Probably discontinuities can occur if this port changes > status also (please see ifCounterDiscontinuityTime > in RFC2863).=20 > =20 >=20 > *) rbridgeConfidenceNative > Need to add DEFVAL (32) > =20 > *) rbridgeConfidenceDecap > Need to add DEFVAL (32) > =20 > *) rbridgeFdbId -- Why is this not rbridgeUniFdbId? > The naming should be consistent for the objects in this > table. > =20 > More importantly, where does this value come from? > Could you give a reference? > My concern is that it may be more advantageous to > index by the MAC addr directly, or ( Port, Mac) > so I'm not sure where I see the advantage of=20 > having an additional index which doesn't appear > to be used anywhere else. > Please clarify. > =20 > *)rbridgeUniFdbPort DESCRIPTION clause > mentions rbridgeUniFdbAddress but I think the object is > rbridgeUniFdbAddr? > =20 > *)rbridgeUniFdbNickname AND in other places,=20 > the term "rbridgeFdbAddress" is used, but this isn't defined > anywhere that I can see. I think you mean rbridgeUniFdbAddr? > =20 > Also, "FdbId", I think should be rbridgeFdbId? > =20 >=20 > *) rbridgeVlanIndex=20 > Why was VlanIndex from Q-BRIDGE-MIB not used? > =20 > *) rbridgeVlanForwarderLosts > Please remove the UNITS clause. > =20 > Probably discontinuities can occur if this port changes > status also (please see ifCounterDiscontinuityTime > in RFC2863).=20 > =20 >=20 > *) rbridgePortCounterEntry > Why is AUGMENTS not used here? > Using AUGMENTS is actually quite meaningful here and > I asked about this in a prior review. Please clarify. > Additionally, the naming should be consistent with > the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc. > =20 >=20 > UNITS clauses for these counters can be removed. > The UNIT is a count, so kind of redundant. > =20 >=20 > *rbridgeVlanPortTable > =20 > Please check the TruthValue objects in this table (and elsewhere)=20 > to ensure that the value of true(1) and false(2) are clearly stated. > =20 > *) rbridgeEsadiTable > I think this table AUGMENTS or sparsely AUGMENTS the rbridgeVlanTable. > Please add wording to the DESCRIPTION of the table/entry and, if = appropriate, > change the INDEX to an AUGMENTS. > =20 > *) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime > The REFERENCE clause could be better, since I couldn't > find the size of the priority anywhere in this section. > =20 >=20 > *) rbridgeSnoopingPortTable > This table seems to sparsely augment the rbridgeBasePortTable > and the rbridgePortCounterTable. That should be > discussed in the table/entry DESCRIPTION. > =20 > The IPv4 and IPv6 needs to be specified in the Conformance > Section. > =20 >=20 > *) rbridgeDtreePriority > A default value is specified in DESCRIPTION but this > needs a proper DEFVAL clause. > =20 > *) rbridgeDtreeActiveTrees > Should this be a Gauge32? > =20 > *) rbridgeTrillMinMtuDesired > Should this have a DEFVAL of 1470 Octets? (just asking) > =20 > *) rbridgeTrillMaxMtuProbes > Why does this value need to be saved after reinitializations? > =20 > *) rbridgeBaseTopologyChange > Please remove the term "trap". SNMPv1 had a mechanism called > trap, but these are Notifications. > =20 > what is meant by "if a newDrb trap is sent for the same transition". > Do you mean the "rbridgeBaseNewDrb" notification? > =20 > Conformance and Group > --------------------- > =20 > *) As mentioned prior, the Compliances and Groups are reversed order. > =20 > *) Also, as mentioned prior, this conformance does not have a = read-only > version. While not technically incorrect, most recent MIBs support > a Full Conformance and a Read-only Conformance. =20 > Have you confirmed with the WG that this is what they want and > if they will implement this MIB as written? > =20 > --- end of review ------ > =20 > =20 --Apple-Mail=_7D41B0F1-8C10-4B8B-8745-BCD428B01B9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Joan,

Sorry, you don't get = multiple cracks at making yet another round of comments on the same = document. As you have noted below, most of your prior comments have been = addressed. We have to draw a line = somewhere.

This MIB has been held up for a year = in IESG review! This has been primarily due to your multiple rounds of = "exhaustive reviews", most of which have been nits or subjective = opinions. Every time a new draft has been published to address the = previous round of comments, you have come right back with a new round of = comments. This is unprecedented in my long experience of writing IETF = MIBs.

Versions -04 to -09 have been written to = address IESG (mostly your) comments. That is fully 60% of the drafts = written.

If you have so many comments, you = should have been done so as part of the TRILL working group. This is an = IETF working group, and most of the work is done in the IETF - not in = the IESG. Please don't try to influence or delay work from outside of a = working group.

I have contacted both the = Internet AD and Operations AD. This non-stop barrage of mib-doctor nits, = apparently to prevent a document from moving forward, is unacceptable to = me and the working group, and should be unacceptable to the IESG. We = need to get this document published = now.

Thanks,
Anil

<= div>
On Oct 10, 2012, at 12:17 AM, Joan Cucchiara = wrote:

Hello,
 
The= following is a review of version 9.   Many prior comments = have been updated
and = are reflected in this new draft, so Thank you for = that. 
 
-Joan
 

Output from smicngPro:
W: = f(RBRIDGE-MIB.my), (47,17) The first revision should match the last = update for MODULE-IDENTITY rbridgeMIB
W: f(RBRIDGE-MIB.my), (919,20) = Item "rbridgeMultiFibPorts" should have SIZE specified
W: = f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has indexing = that may create variables with more than 128 sub-ids
W: = f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" should have = SIZE specified
W: f(RBRIDGE-MIB.my), (1043,18) Row = "rbridgeVlanPortEntry" does not have a consistent indexing scheme - = cannot specify an index item from additional "base row" = rbridgeBasePortEntry, since can have only one "base row" which is = rbridgeVlanEntry
 

Output from = SmiLint:
mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision = date after last update
mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} = revision for last update is missing
mibs/RBRIDGE-MIB.my:1452: [5] = {index-exceeds-too-large} warning: index of row = `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 = subidentifier(s)
 
Additional descriptions of = some error/warning = messages:
 
Error:     &= nbsp; index-element-no-size (level = 3)
Message:     index element `%s' of row `%s' = must have a size restriction
Description: Object identifiers are = restricted in size to have at most = 128
           &= nbsp; sub-identifiers. This implies that index elements used to = form
           =   instance identifiers must have a size contraint which = ensures
          &nb= sp;  that the 128 sub-identifier constraint is kept intact for = any
           &= nbsp; possible combination of the index elements' values (RFC = 2578,
           = ;  Section = 3.5).
 
 
 

*) = rbridgeBaseTrillVersion
According to RFC6325, this is a 2 bit field = and you
have 4 bytes.  Please = clarify.
 
Unsigned32(0..3).
 
DEFVAL(0) <-- only version supported right = now.
 

*) = rbridgeBaseForwardDelay
According to RFC6325, should have a DEFVAL of = 15 seconds.
 
*) = rbridgeBaseAcceptEncapNonadj
according to RFC6325, should = have:
DEFVAL(false)
 
*) = rbridgeBaseNicknameNumber
Please add:
"Additionally, this value = represents the maximum amount
of entries in the = rbridgeBaseNicknameTable."
 
Why doesn't this = have a DEFVAL(1) as specified in
RFC6325?   Also, you = should add a REFERENCE clause
RFC6325, Section = 5.1.
 
*) rbridgeBaseNicknameTable
Please = clarify in the Table's DESCRIPTION clause that
this table represents = nickname information which is configured
by an operator OR learned = dynaically by the = Rbridge.
 

*)rbridgeBaseNicknamePriority
T= his DESCRIPTION needs additional information.
When nickname is = configured, the most significant
bit (0x80) MUST be set AND the = bottom 7 bits
have the default value of 0x40, so 0x80 + 0x40 =3D=3D = 0xC0
which is 192 decimal.   Additionally, the bottom 7 = bits
could be configured to value other than = 0x40.
 
However, if a row is created due to the = nickname
dynamically created, then the most significant bit (0x80) = MUST NOT
be set.  
 
*) = rbridgeBasePortTable
Please check REFERENCE clauses for this = table.
I think you mean section 5.3 (not = 5.2).
 

*) rbridgeBasePort
Where did you = get the range for this Index?
I think you should define a TC for this = Value.
This is used as an index for this table, and is used
in = several other tables as an index, thus a TC would
be = better.
 

*)I asked this in a prior review, = but could you specify
the ifType associated with the ifIndex, i.e. = physical
layer?
 

*)Please specify what = the value is when the bit is set (i.e. true).
Please check this = throughout the MIB because while the DESCRIPTION
clauses are more = specific, there are places where the value
of true/false is not = specified for TruthValue
 

*) = rbridgeBasePortStpRootChanges
Please remove UNITS clause.  The = units is a count and
we know that = already.
 
Probably discontinuities can occur = if this port changes
status also (please see = ifCounterDiscontinuityTime
in = RFC2863). 
 

*) = rbridgeConfidenceNative
Need to add DEFVAL = (32)
 
*) rbridgeConfidenceDecap
Need to add = DEFVAL (32)
 
*) rbridgeFdbId -- Why is this = not rbridgeUniFdbId?
The naming should be consistent for the objects = in this
table.
 
More importantly, where = does this value come from?
Could you give a reference?
My concern = is that it may be more advantageous to
index by the MAC addr = directly, or ( Port, Mac)
so I'm not sure where I see the advantage = of 
having an = additional index which doesn't appear
to be used anywhere = else.
Please clarify.
 
*)rbridgeUniFdbPort = DESCRIPTION clause
mentions rbridgeUniFdbAddress but I think the = object = is
rbridgeUniFdbAddr?
 
*)rbridgeUniFdbNicknam= e AND in other places, 
the term = "rbridgeFdbAddress" is used, but this isn't defined
anywhere that I = can see.  I think you mean = rbridgeUniFdbAddr?
 
Also, "FdbId", I think = should be rbridgeFdbId?
 

*) = rbridgeVlanIndex 
Why= was VlanIndex from Q-BRIDGE-MIB not used?
 
*) = rbridgeVlanForwarderLosts
Please remove the UNITS = clause.
 
Probably discontinuities can occur if = this port changes
status also (please see = ifCounterDiscontinuityTime
in = RFC2863). 
 

*) = rbridgePortCounterEntry
Why is AUGMENTS not used here?
Using = AUGMENTS is actually quite meaningful here and
I asked about this in = a prior review.  Please clarify.
Additionally, the naming should = be consistent with
the rbridgeBasePortTable (so = rbridgeBasePortCounterTable) etc.
 

UNITS = clauses for these counters can be removed.
The UNIT is a count, so = kind of = redundant.
 

*rbridgeVlanPortTable
=  
Please check the TruthValue objects in this table (and = elsewhere) 
to = ensure that the value of true(1) and false(2) are clearly = stated.
 
*) rbridgeEsadiTable
I think this = table AUGMENTS or sparsely AUGMENTS the rbridgeVlanTable.
Please add = wording to the DESCRIPTION of the table/entry and, if = appropriate,
change the INDEX to an = AUGMENTS.
 
*) rbridgeEsadiDrbPriority, = rbridgeEsadiDrbHoldingTime
The REFERENCE clause could be better, = since I couldn't
find the size of the priority anywhere in this = section.
 

*) = rbridgeSnoopingPortTable
This table seems to sparsely augment the = rbridgeBasePortTable
and the rbridgePortCounterTable.   = That should be
discussed in the table/entry = DESCRIPTION.
 
The IPv4 and IPv6 needs to be = specified in the = Conformance
Section.
 

*) = rbridgeDtreePriority
A default value is specified in DESCRIPTION but = this
needs a proper DEFVAL clause.
 
*) = rbridgeDtreeActiveTrees
Should this be a = Gauge32?
 
*) = rbridgeTrillMinMtuDesired
Should this have a DEFVAL of 1470 Octets? = (just asking)
 
*) = rbridgeTrillMaxMtuProbes
Why does this value need to be saved after = reinitializations?
 
*) = rbridgeBaseTopologyChange
Please remove the term "trap".  SNMPv1 = had a mechanism called
trap, but these are = Notifications.
 
what is meant by "if a newDrb = trap is sent for the same transition".
Do you mean the = "rbridgeBaseNewDrb" notification?
 
Conformance = and Group
---------------------
 
*) As = mentioned prior, the Compliances and Groups are reversed = order.
 
*) Also, as mentioned prior, this = conformance does not have a read-only
version.  While not = technically incorrect, most recent MIBs support
a Full Conformance = and a Read-only Conformance.  
Have you confirmed with = the WG that this is what they want and
if they will implement this = MIB as written?
 
--- end of review = ------
 
 

= --Apple-Mail=_7D41B0F1-8C10-4B8B-8745-BCD428B01B9B-- From bclaise@cisco.com Wed Oct 10 06:35:24 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC721F8720 for ; Wed, 10 Oct 2012 06:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.805 X-Spam-Level: X-Spam-Status: No, score=-8.805 tagged_above=-999 required=5 tests=[AWL=1.792, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w32qD3Mll+W for ; Wed, 10 Oct 2012 06:35:22 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA0A21F8686 for ; Wed, 10 Oct 2012 06:35:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9ADZIlx007954; Wed, 10 Oct 2012 15:35:18 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9ADZHgB007430; Wed, 10 Oct 2012 15:35:17 +0200 (CEST) Message-ID: <50757995.2040807@cisco.com> Date: Wed, 10 Oct 2012 15:35:17 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anil R References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net><004a01cd1748$b03f1220$6701a8c0@JoanPC><5aa901cda09b$f53e7aa0$6801a8c0@JoanPC><506C03B2.9060902@cisco.com> <5c2401cda230$f1ce2000$6801a8c0@JoanPC> <001601cda69e$2c7e4a10$6801a8c0@JoanPC> <43E282B1-9797-4687-8070-FC2462B68E29@charter.net> In-Reply-To: <43E282B1-9797-4687-8070-FC2462B68E29@charter.net> Content-Type: multipart/alternative; boundary="------------040005030709080401010806" Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org, mib-doctors@ietf.org, ops-ads@tools.ietf.org, Ralph Droms , adrian@olddog.co.uk Subject: Re: [MIB-DOCTORS] MIB Dr review of draft-ietf-trill-rbridge-mib-09 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:35:24 -0000 This is a multi-part message in MIME format. --------------040005030709080401010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anil, Please direct your message to me, as I'm the one owning the COMMENT. However, it's a good practice to copy mib-doctors. Also please use the list from my COMMENT, as there are a couple that I didn't insist on (like the UNITS clause for example), and because I regrouped them. Reminder: the MIB doctor is not part of the IESG, but provide feedback to the IESG. " We need to get this document published now". Agreed, but not at all costs. Can we please go back in the mood of progressing the draft! Regards, Benoit. > Joan, > > Sorry, you don't get multiple cracks at making yet another round of > comments on the same document. As you have noted below, most of your > prior comments have been addressed. We have to draw a line somewhere. > > This MIB has been held up for a year in IESG review! This has been > primarily due to your multiple rounds of "exhaustive reviews", most of > which have been nits or subjective opinions. Every time a new draft > has been published to address the previous round of comments, you have > come right back with a new round of comments. This is unprecedented in > my long experience of writing IETF MIBs. > > Versions -04 to -09 have been written to address IESG (mostly your) > comments. That is fully 60% of the drafts written. > > If you have so many comments, you should have been done so as part of > the TRILL working group. This is an IETF working group, and most of > the work is done in the IETF - not in the IESG. Please don't try to > influence or delay work from outside of a working group. > > I have contacted both the Internet AD and Operations AD. This non-stop > barrage of mib-doctor nits, apparently to prevent a document from > moving forward, is unacceptable to me and the working group, and > should be unacceptable to the IESG. We need to get this document > published now. > > Thanks, > Anil > > > On Oct 10, 2012, at 12:17 AM, Joan Cucchiara wrote: > >> Hello, >> The following is a review of version 9. Many prior comments have >> been updated >> and are reflected in this new draft, so Thank you for that. >> -Joan >> >> Output from smicngPro: >> W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the >> last update for MODULE-IDENTITY rbridgeMIB >> W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should >> have SIZE specified >> W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has >> indexing that may create variables with more than 128 sub-ids >> W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" >> should have SIZE specified >> W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not >> have a consistent indexing scheme - cannot specify an index item from >> additional "base row" rbridgeBasePortEntry, since can have only one >> "base row" which is rbridgeVlanEntry >> >> Output from SmiLint: >> mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date >> after last update >> mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last >> update is missing >> mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: >> index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by >> 142 subidentifier(s) >> Additional descriptions of some error/warning messages: >> Error: index-element-no-size (level 3) >> Message: index element `%s' of row `%s' must have a size restriction >> Description: Object identifiers are restricted in size to have at >> most 128 >> sub-identifiers. This implies that index elements used >> to form >> instance identifiers must have a size contraint which >> ensures >> that the 128 sub-identifier constraint is kept intact >> for any >> possible combination of the index elements' values (RFC >> 2578, >> Section 3.5). >> >> *) rbridgeBaseTrillVersion >> According to RFC6325, this is a 2 bit field and you >> have 4 bytes. Please clarify. >> Unsigned32(0..3). >> DEFVAL(0) <-- only version supported right now. >> >> *) rbridgeBaseForwardDelay >> According to RFC6325, should have a DEFVAL of 15 seconds. >> *) rbridgeBaseAcceptEncapNonadj >> according to RFC6325, should have: >> DEFVAL(false) >> *) rbridgeBaseNicknameNumber >> Please add: >> "Additionally, this value represents the maximum amount >> of entries in the rbridgeBaseNicknameTable." >> Why doesn't this have a DEFVAL(1) as specified in >> RFC6325? Also, you should add a REFERENCE clause >> RFC6325, Section 5.1. >> *) rbridgeBaseNicknameTable >> Please clarify in the Table's DESCRIPTION clause that >> this table represents nickname information which is configured >> by an operator OR learned dynaically by the Rbridge. >> >> *)rbridgeBaseNicknamePriority >> This DESCRIPTION needs additional information. >> When nickname is configured, the most significant >> bit (0x80) MUST be set AND the bottom 7 bits >> have the default value of 0x40, so 0x80 + 0x40 == 0xC0 >> which is 192 decimal. Additionally, the bottom 7 bits >> could be configured to value other than 0x40. >> However, if a row is created due to the nickname >> dynamically created, then the most significant bit (0x80) MUST NOT >> be set. >> *) rbridgeBasePortTable >> Please check REFERENCE clauses for this table. >> I think you mean section 5.3 (not 5.2). >> >> *) rbridgeBasePort >> Where did you get the range for this Index? >> I think you should define a TC for this Value. >> This is used as an index for this table, and is used >> in several other tables as an index, thus a TC would >> be better. >> >> *)I asked this in a prior review, but could you specify >> the ifType associated with the ifIndex, i.e. physical >> layer? >> >> *)Please specify what the value is when the bit is set (i.e. true). >> Please check this throughout the MIB because while the DESCRIPTION >> clauses are more specific, there are places where the value >> of true/false is not specified for TruthValue >> >> *) rbridgeBasePortStpRootChanges >> Please remove UNITS clause. The units is a count and >> we know that already. >> Probably discontinuities can occur if this port changes >> status also (please see ifCounterDiscontinuityTime >> in RFC2863). >> >> *) rbridgeConfidenceNative >> Need to add DEFVAL (32) >> *) rbridgeConfidenceDecap >> Need to add DEFVAL (32) >> *) rbridgeFdbId -- Why is this not rbridgeUniFdbId? >> The naming should be consistent for the objects in this >> table. >> More importantly, where does this value come from? >> Could you give a reference? >> My concern is that it may be more advantageous to >> index by the MAC addr directly, or ( Port, Mac) >> so I'm not sure where I see the advantage of >> having an additional index which doesn't appear >> to be used anywhere else. >> Please clarify. >> *)rbridgeUniFdbPort DESCRIPTION clause >> mentions rbridgeUniFdbAddress but I think the object is >> rbridgeUniFdbAddr? >> *)rbridgeUniFdbNickname AND in other places, >> the term "rbridgeFdbAddress" is used, but this isn't defined >> anywhere that I can see. I think you mean rbridgeUniFdbAddr? >> Also, "FdbId", I think should be rbridgeFdbId? >> >> *) rbridgeVlanIndex >> Why was VlanIndex from Q-BRIDGE-MIB not used? >> *) rbridgeVlanForwarderLosts >> Please remove the UNITS clause. >> Probably discontinuities can occur if this port changes >> status also (please see ifCounterDiscontinuityTime >> in RFC2863). >> >> *) rbridgePortCounterEntry >> Why is AUGMENTS not used here? >> Using AUGMENTS is actually quite meaningful here and >> I asked about this in a prior review. Please clarify. >> Additionally, the naming should be consistent with >> the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc. >> >> UNITS clauses for these counters can be removed. >> The UNIT is a count, so kind of redundant. >> >> *rbridgeVlanPortTable >> Please check the TruthValue objects in this table (and elsewhere) >> to ensure that the value of true(1) and false(2) are clearly stated. >> *) rbridgeEsadiTable >> I think this table AUGMENTS or sparsely AUGMENTS the rbridgeVlanTable. >> Please add wording to the DESCRIPTION of the table/entry and, if >> appropriate, >> change the INDEX to an AUGMENTS. >> *) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime >> The REFERENCE clause could be better, since I couldn't >> find the size of the priority anywhere in this section. >> >> *) rbridgeSnoopingPortTable >> This table seems to sparsely augment the rbridgeBasePortTable >> and the rbridgePortCounterTable. That should be >> discussed in the table/entry DESCRIPTION. >> The IPv4 and IPv6 needs to be specified in the Conformance >> Section. >> >> *) rbridgeDtreePriority >> A default value is specified in DESCRIPTION but this >> needs a proper DEFVAL clause. >> *) rbridgeDtreeActiveTrees >> Should this be a Gauge32? >> *) rbridgeTrillMinMtuDesired >> Should this have a DEFVAL of 1470 Octets? (just asking) >> *) rbridgeTrillMaxMtuProbes >> Why does this value need to be saved after reinitializations? >> *) rbridgeBaseTopologyChange >> Please remove the term "trap". SNMPv1 had a mechanism called >> trap, but these are Notifications. >> what is meant by "if a newDrb trap is sent for the same transition". >> Do you mean the "rbridgeBaseNewDrb" notification? >> Conformance and Group >> --------------------- >> *) As mentioned prior, the Compliances and Groups are reversed order. >> *) Also, as mentioned prior, this conformance does not have a read-only >> version. While not technically incorrect, most recent MIBs support >> a Full Conformance and a Read-only Conformance. >> Have you confirmed with the WG that this is what they want and >> if they will implement this MIB as written? >> --- end of review ------ > --------------040005030709080401010806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Anil,

Please direct your message to me, as I'm the one owning the COMMENT.  However, it's a good practice to copy mib-doctors.
Also please use the list from my COMMENT, as there are a couple that I didn't insist on (like the UNITS clause for example), and because I regrouped them.
Reminder: the MIB doctor is not part of the IESG, but provide feedback to the IESG.
" We need to get this document published now". Agreed, but not at all costs.

Can we please go back in the mood of progressing the draft!

Regards, Benoit.
Joan,

Sorry, you don't get multiple cracks at making yet another round of comments on the same document. As you have noted below, most of your prior comments have been addressed. We have to draw a line somewhere.

This MIB has been held up for a year in IESG review! This has been primarily due to your multiple rounds of "exhaustive reviews", most of which have been nits or subjective opinions. Every time a new draft has been published to address the previous round of comments, you have come right back with a new round of comments. This is unprecedented in my long experience of writing IETF MIBs.

Versions -04 to -09 have been written to address IESG (mostly your) comments. That is fully 60% of the drafts written.

If you have so many comments, you should have been done so as part of the TRILL working group. This is an IETF working group, and most of the work is done in the IETF - not in the IESG. Please don't try to influence or delay work from outside of a working group.

I have contacted both the Internet AD and Operations AD. This non-stop barrage of mib-doctor nits, apparently to prevent a document from moving forward, is unacceptable to me and the working group, and should be unacceptable to the IESG. We need to get this document published now.

Thanks,
Anil


On Oct 10, 2012, at 12:17 AM, Joan Cucchiara wrote:

Hello,
 
The following is a review of version 9.   Many prior comments have been updated
and are reflected in this new draft, so Thank you for that. 
 
-Joan
 

Output from smicngPro:
W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the last update for MODULE-IDENTITY rbridgeMIB
W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should have SIZE specified
W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has indexing that may create variables with more than 128 sub-ids
W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" should have SIZE specified
W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" rbridgeBasePortEntry, since can have only one "base row" which is rbridgeVlanEntry
 

Output from SmiLint:
mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date after last update
mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last update is missing
mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 subidentifier(s)
 
Additional descriptions of some error/warning messages:
 
Error:       index-element-no-size (level 3)
Message:     index element `%s' of row `%s' must have a size restriction
Description: Object identifiers are restricted in size to have at most 128
             sub-identifiers. This implies that index elements used to form
             instance identifiers must have a size contraint which ensures
             that the 128 sub-identifier constraint is kept intact for any
             possible combination of the index elements' values (RFC 2578,
             Section 3.5).
 
 
 

*) rbridgeBaseTrillVersion
According to RFC6325, this is a 2 bit field and you
have 4 bytes.  Please clarify.
 
Unsigned32(0..3).
 
DEFVAL(0) <-- only version supported right now.
 

*) rbridgeBaseForwardDelay
According to RFC6325, should have a DEFVAL of 15 seconds.
 
*) rbridgeBaseAcceptEncapNonadj
according to RFC6325, should have:
DEFVAL(false)
 
*) rbridgeBaseNicknameNumber
Please add:
"Additionally, this value represents the maximum amount
of entries in the rbridgeBaseNicknameTable."
 
Why doesn't this have a DEFVAL(1) as specified in
RFC6325?   Also, you should add a REFERENCE clause
RFC6325, Section 5.1.
 
*) rbridgeBaseNicknameTable
Please clarify in the Table's DESCRIPTION clause that
this table represents nickname information which is configured
by an operator OR learned dynaically by the Rbridge.
 

*)rbridgeBaseNicknamePriority
This DESCRIPTION needs additional information.
When nickname is configured, the most significant
bit (0x80) MUST be set AND the bottom 7 bits
have the default value of 0x40, so 0x80 + 0x40 == 0xC0
which is 192 decimal.   Additionally, the bottom 7 bits
could be configured to value other than 0x40.
 
However, if a row is created due to the nickname
dynamically created, then the most significant bit (0x80) MUST NOT
be set.  
 
*) rbridgeBasePortTable
Please check REFERENCE clauses for this table.
I think you mean section 5.3 (not 5.2).
 

*) rbridgeBasePort
Where did you get the range for this Index?
I think you should define a TC for this Value.
This is used as an index for this table, and is used
in several other tables as an index, thus a TC would
be better.
 

*)I asked this in a prior review, but could you specify
the ifType associated with the ifIndex, i.e. physical
layer?
 

*)Please specify what the value is when the bit is set (i.e. true).
Please check this throughout the MIB because while the DESCRIPTION
clauses are more specific, there are places where the value
of true/false is not specified for TruthValue
 

*) rbridgeBasePortStpRootChanges
Please remove UNITS clause.  The units is a count and
we know that already.
 
Probably discontinuities can occur if this port changes
status also (please see ifCounterDiscontinuityTime
in RFC2863). 
 

*) rbridgeConfidenceNative
Need to add DEFVAL (32)
 
*) rbridgeConfidenceDecap
Need to add DEFVAL (32)
 
*) rbridgeFdbId -- Why is this not rbridgeUniFdbId?
The naming should be consistent for the objects in this
table.
 
More importantly, where does this value come from?
Could you give a reference?
My concern is that it may be more advantageous to
index by the MAC addr directly, or ( Port, Mac)
so I'm not sure where I see the advantage of 
having an additional index which doesn't appear
to be used anywhere else.
Please clarify.
 
*)rbridgeUniFdbPort DESCRIPTION clause
mentions rbridgeUniFdbAddress but I think the object is
rbridgeUniFdbAddr?
 
*)rbridgeUniFdbNickname AND in other places, 
the term "rbridgeFdbAddress" is used, but this isn't defined
anywhere that I can see.  I think you mean rbridgeUniFdbAddr?
 
Also, "FdbId", I think should be rbridgeFdbId?
 

*) rbridgeVlanIndex 
Why was VlanIndex from Q-BRIDGE-MIB not used?
 
*) rbridgeVlanForwarderLosts
Please remove the UNITS clause.
 
Probably discontinuities can occur if this port changes
status also (please see ifCounterDiscontinuityTime
in RFC2863). 
 

*) rbridgePortCounterEntry
Why is AUGMENTS not used here?
Using AUGMENTS is actually quite meaningful here and
I asked about this in a prior review.  Please clarify.
Additionally, the naming should be consistent with
the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc.
 

UNITS clauses for these counters can be removed.
The UNIT is a count, so kind of redundant.
 

*rbridgeVlanPortTable
 
Please check the TruthValue objects in this table (and elsewhere) 
to ensure that the value of true(1) and false(2) are clearly stated.
 
*) rbridgeEsadiTable
I think this table AUGMENTS or sparsely AUGMENTS the rbridgeVlanTable.
Please add wording to the DESCRIPTION of the table/entry and, if appropriate,
change the INDEX to an AUGMENTS.
 
*) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime
The REFERENCE clause could be better, since I couldn't
find the size of the priority anywhere in this section.
 

*) rbridgeSnoopingPortTable
This table seems to sparsely augment the rbridgeBasePortTable
and the rbridgePortCounterTable.   That should be
discussed in the table/entry DESCRIPTION.
 
The IPv4 and IPv6 needs to be specified in the Conformance
Section.
 

*) rbridgeDtreePriority
A default value is specified in DESCRIPTION but this
needs a proper DEFVAL clause.
 
*) rbridgeDtreeActiveTrees
Should this be a Gauge32?
 
*) rbridgeTrillMinMtuDesired
Should this have a DEFVAL of 1470 Octets? (just asking)
 
*) rbridgeTrillMaxMtuProbes
Why does this value need to be saved after reinitializations?
 
*) rbridgeBaseTopologyChange
Please remove the term "trap".  SNMPv1 had a mechanism called
trap, but these are Notifications.
 
what is meant by "if a newDrb trap is sent for the same transition".
Do you mean the "rbridgeBaseNewDrb" notification?
 
Conformance and Group
---------------------
 
*) As mentioned prior, the Compliances and Groups are reversed order.
 
*) Also, as mentioned prior, this conformance does not have a read-only
version.  While not technically incorrect, most recent MIBs support
a Full Conformance and a Read-only Conformance.  
Have you confirmed with the WG that this is what they want and
if they will implement this MIB as written?
 
--- end of review ------
 
 


--------------040005030709080401010806-- From rdroms.ietf@gmail.com Wed Oct 10 07:37:10 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC0921F87B2 for ; Wed, 10 Oct 2012 07:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSpBhZ3tl7TV for ; Wed, 10 Oct 2012 07:37:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F198621F87BF for ; Wed, 10 Oct 2012 07:37:08 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so530449qcg.31 for ; Wed, 10 Oct 2012 07:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=mgr6czPJ/MHtz7lbhsVkqv3HKT9nE/Gh8PZdnuV4JlQ=; b=mWC0MKs+3F6QxGTAL7yQ9mNPVLgDlFkv8HmL88F2MhafqY1tHSGR/gtWujErEFXwRg F8vV4P8PP3cNheywjPUWO3Plo6AR3zr7y93H2mcscTLUteJz+EzDtH4DfxIYpmNlPa14 Qv1NlzRsD4Q4FG9BM96vOkmJHv8+0J4KgSUOuemCGx+ap+wIR7QIHBdBABHzFHjOvCpa R8ZlEiwJRsquN9u0CL7eCzjhQiGHwzerbDtFyYEc0uG7RmA8MTCrKxa7cX58CVotua0T Ev6fO4mtEgDbrSbnihPTyfwn8QDTvx5q5t1AvmpRwJOPQKF6dnv25qxq2twzT1wbkC+T 1Olg== Received: by 10.49.104.65 with SMTP id gc1mr2353736qeb.22.1349879828381; Wed, 10 Oct 2012 07:37:08 -0700 (PDT) Received: from rtp-rdroms-8912.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id em3sm1789901qab.5.2012.10.10.07.36.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 07:36:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms X-Priority: 3 In-Reply-To: <43E282B1-9797-4687-8070-FC2462B68E29@charter.net> Date: Wed, 10 Oct 2012 10:36:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDAB6D1-5C86-4820-8DCC-375CE35AF5FA@gmail.com> References: <09a201cd15c7$0dc175b0$29446110$@olddog.co.uk><4F83F4FB.3010005@bwijnen.net><004a01cd1748$b03f1220$6701a8c0@JoanPC><5aa901cda09b$f53e7aa0$6801a8c0@JoanPC><506C03B2.9060902@cisco.com> <5c2401cda230$f1ce2000$6801a8c0@JoanPC> <001601cda69e$2c7e4a10$6801a8c0@JoanPC> <43E282B1-9797-4687-8070-FC2462B68E29@charter.net> To: Anil R X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org, mib-doctors@ietf.org, ops-ads@tools.ietf.org, Farrel Adrian Subject: Re: [MIB-DOCTORS] MIB Dr review of draft-ietf-trill-rbridge-mib-09 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:37:10 -0000 Anil - as Benoit wrote, please refer to the list of Comments in the IESG = Evaluation Record, which Benoit extracted from Joan's careful and = helpful review. I see two issues: the length of time that the review has taken, and the = importance and validity of the comments on the document. The review has = taken a long time for a variety of reasons and it's inappropriate to = assign blame to any individual. It is especially inappropriate to = assign a motivation to what you perceive as an unnecessarily long review = process. We have a list of comments from Benoit in his AD review. Let's work to = resolve those comments so the document can be published. - Ralph On Oct 10, 2012, at 8:18 AM 10/10/12, Anil R wrote: > Joan, >=20 > Sorry, you don't get multiple cracks at making yet another round of = comments on the same document. As you have noted below, most of your = prior comments have been addressed. We have to draw a line somewhere. >=20 > This MIB has been held up for a year in IESG review! This has been = primarily due to your multiple rounds of "exhaustive reviews", most of = which have been nits or subjective opinions. Every time a new draft has = been published to address the previous round of comments, you have come = right back with a new round of comments. This is unprecedented in my = long experience of writing IETF MIBs. >=20 > Versions -04 to -09 have been written to address IESG (mostly your) = comments. That is fully 60% of the drafts written. >=20 > If you have so many comments, you should have been done so as part of = the TRILL working group. This is an IETF working group, and most of the = work is done in the IETF - not in the IESG. Please don't try to = influence or delay work from outside of a working group. >=20 > I have contacted both the Internet AD and Operations AD. This non-stop = barrage of mib-doctor nits, apparently to prevent a document from moving = forward, is unacceptable to me and the working group, and should be = unacceptable to the IESG. We need to get this document published now. >=20 > Thanks, > Anil >=20 >=20 > On Oct 10, 2012, at 12:17 AM, Joan Cucchiara wrote: >=20 >> Hello, >> =20 >> The following is a review of version 9. Many prior comments have = been updated >> and are reflected in this new draft, so Thank you for that.=20 >> =20 >> -Joan >> =20 >>=20 >> Output from smicngPro: >> W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the = last update for MODULE-IDENTITY rbridgeMIB >> W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should = have SIZE specified >> W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has = indexing that may create variables with more than 128 sub-ids >> W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" = should have SIZE specified >> W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not = have a consistent indexing scheme - cannot specify an index item from = additional "base row" rbridgeBasePortEntry, since can have only one = "base row" which is rbridgeVlanEntry >> =20 >>=20 >> Output from SmiLint: >> mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date = after last update >> mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last = update is missing >> mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: = index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 = subidentifier(s) >> =20 >> Additional descriptions of some error/warning messages: >> =20 >> Error: index-element-no-size (level 3) >> Message: index element `%s' of row `%s' must have a size = restriction >> Description: Object identifiers are restricted in size to have at = most 128 >> sub-identifiers. This implies that index elements used = to form >> instance identifiers must have a size contraint which = ensures >> that the 128 sub-identifier constraint is kept intact = for any >> possible combination of the index elements' values (RFC = 2578, >> Section 3.5). >> =20 >> =20 >> =20 >>=20 >> *) rbridgeBaseTrillVersion >> According to RFC6325, this is a 2 bit field and you >> have 4 bytes. Please clarify. >> =20 >> Unsigned32(0..3). >> =20 >> DEFVAL(0) <-- only version supported right now. >> =20 >>=20 >> *) rbridgeBaseForwardDelay >> According to RFC6325, should have a DEFVAL of 15 seconds. >> =20 >> *) rbridgeBaseAcceptEncapNonadj >> according to RFC6325, should have: >> DEFVAL(false) >> =20 >> *) rbridgeBaseNicknameNumber >> Please add: >> "Additionally, this value represents the maximum amount >> of entries in the rbridgeBaseNicknameTable." >> =20 >> Why doesn't this have a DEFVAL(1) as specified in >> RFC6325? Also, you should add a REFERENCE clause >> RFC6325, Section 5.1. >> =20 >> *) rbridgeBaseNicknameTable >> Please clarify in the Table's DESCRIPTION clause that >> this table represents nickname information which is configured >> by an operator OR learned dynaically by the Rbridge. >> =20 >>=20 >> *)rbridgeBaseNicknamePriority >> This DESCRIPTION needs additional information. >> When nickname is configured, the most significant >> bit (0x80) MUST be set AND the bottom 7 bits >> have the default value of 0x40, so 0x80 + 0x40 =3D=3D 0xC0 >> which is 192 decimal. Additionally, the bottom 7 bits >> could be configured to value other than 0x40. >> =20 >> However, if a row is created due to the nickname >> dynamically created, then the most significant bit (0x80) MUST NOT >> be set. =20 >> =20 >> *) rbridgeBasePortTable >> Please check REFERENCE clauses for this table. >> I think you mean section 5.3 (not 5.2). >> =20 >>=20 >> *) rbridgeBasePort >> Where did you get the range for this Index? >> I think you should define a TC for this Value. >> This is used as an index for this table, and is used >> in several other tables as an index, thus a TC would >> be better. >> =20 >>=20 >> *)I asked this in a prior review, but could you specify >> the ifType associated with the ifIndex, i.e. physical >> layer? >> =20 >>=20 >> *)Please specify what the value is when the bit is set (i.e. true). >> Please check this throughout the MIB because while the DESCRIPTION >> clauses are more specific, there are places where the value >> of true/false is not specified for TruthValue >> =20 >>=20 >> *) rbridgeBasePortStpRootChanges >> Please remove UNITS clause. The units is a count and >> we know that already. >> =20 >> Probably discontinuities can occur if this port changes >> status also (please see ifCounterDiscontinuityTime >> in RFC2863).=20 >> =20 >>=20 >> *) rbridgeConfidenceNative >> Need to add DEFVAL (32) >> =20 >> *) rbridgeConfidenceDecap >> Need to add DEFVAL (32) >> =20 >> *) rbridgeFdbId -- Why is this not rbridgeUniFdbId? >> The naming should be consistent for the objects in this >> table. >> =20 >> More importantly, where does this value come from? >> Could you give a reference? >> My concern is that it may be more advantageous to >> index by the MAC addr directly, or ( Port, Mac) >> so I'm not sure where I see the advantage of=20 >> having an additional index which doesn't appear >> to be used anywhere else. >> Please clarify. >> =20 >> *)rbridgeUniFdbPort DESCRIPTION clause >> mentions rbridgeUniFdbAddress but I think the object is >> rbridgeUniFdbAddr? >> =20 >> *)rbridgeUniFdbNickname AND in other places,=20 >> the term "rbridgeFdbAddress" is used, but this isn't defined >> anywhere that I can see. I think you mean rbridgeUniFdbAddr? >> =20 >> Also, "FdbId", I think should be rbridgeFdbId? >> =20 >>=20 >> *) rbridgeVlanIndex=20 >> Why was VlanIndex from Q-BRIDGE-MIB not used? >> =20 >> *) rbridgeVlanForwarderLosts >> Please remove the UNITS clause. >> =20 >> Probably discontinuities can occur if this port changes >> status also (please see ifCounterDiscontinuityTime >> in RFC2863).=20 >> =20 >>=20 >> *) rbridgePortCounterEntry >> Why is AUGMENTS not used here? >> Using AUGMENTS is actually quite meaningful here and >> I asked about this in a prior review. Please clarify. >> Additionally, the naming should be consistent with >> the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc. >> =20 >>=20 >> UNITS clauses for these counters can be removed. >> The UNIT is a count, so kind of redundant. >> =20 >>=20 >> *rbridgeVlanPortTable >> =20 >> Please check the TruthValue objects in this table (and elsewhere)=20 >> to ensure that the value of true(1) and false(2) are clearly stated. >> =20 >> *) rbridgeEsadiTable >> I think this table AUGMENTS or sparsely AUGMENTS the = rbridgeVlanTable. >> Please add wording to the DESCRIPTION of the table/entry and, if = appropriate, >> change the INDEX to an AUGMENTS. >> =20 >> *) rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime >> The REFERENCE clause could be better, since I couldn't >> find the size of the priority anywhere in this section. >> =20 >>=20 >> *) rbridgeSnoopingPortTable >> This table seems to sparsely augment the rbridgeBasePortTable >> and the rbridgePortCounterTable. That should be >> discussed in the table/entry DESCRIPTION. >> =20 >> The IPv4 and IPv6 needs to be specified in the Conformance >> Section. >> =20 >>=20 >> *) rbridgeDtreePriority >> A default value is specified in DESCRIPTION but this >> needs a proper DEFVAL clause. >> =20 >> *) rbridgeDtreeActiveTrees >> Should this be a Gauge32? >> =20 >> *) rbridgeTrillMinMtuDesired >> Should this have a DEFVAL of 1470 Octets? (just asking) >> =20 >> *) rbridgeTrillMaxMtuProbes >> Why does this value need to be saved after reinitializations? >> =20 >> *) rbridgeBaseTopologyChange >> Please remove the term "trap". SNMPv1 had a mechanism called >> trap, but these are Notifications. >> =20 >> what is meant by "if a newDrb trap is sent for the same transition". >> Do you mean the "rbridgeBaseNewDrb" notification? >> =20 >> Conformance and Group >> --------------------- >> =20 >> *) As mentioned prior, the Compliances and Groups are reversed order. >> =20 >> *) Also, as mentioned prior, this conformance does not have a = read-only >> version. While not technically incorrect, most recent MIBs support >> a Full Conformance and a Read-only Conformance. =20 >> Have you confirmed with the WG that this is what they want and >> if they will implement this MIB as written? >> =20 >> --- end of review ------ >> =20 >> =20 >=20 From bclaise@cisco.com Wed Oct 10 09:09:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0694021F8658 for ; Wed, 10 Oct 2012 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.833 X-Spam-Level: X-Spam-Status: No, score=-8.833 tagged_above=-999 required=5 tests=[AWL=1.766, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKr2W82Nc9IQ for ; Wed, 10 Oct 2012 09:09:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E410A21F8647 for ; Wed, 10 Oct 2012 09:09:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9AG9CZa024595; Wed, 10 Oct 2012 18:09:12 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9AG9Af2007710; Wed, 10 Oct 2012 18:09:11 +0200 (CEST) Message-ID: <50759DA6.9020900@cisco.com> Date: Wed, 10 Oct 2012 18:09:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Martin Stiemerling , "MIB Doctors (E-mail)" , Michael MacFaden References: <50758E1C.6070706@neclab.eu> In-Reply-To: <50758E1C.6070706@neclab.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ronald Bonica , "storm-chairs@tools.ietf.org" Subject: Re: [MIB-DOCTORS] Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:09:16 -0000 Hi Mike, As far as I know, you did the review of draft-ietf-storm-iscsimib Can you please have a look to see if this latest version addresses your points at http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt Regards, Benoit > Hi Ron and Benoit, > > The MIB doctors did a review of draft-ietf-storm-iscsimib a while back > and did comment on the text, but also on the MIB module itself. > (https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib) > > The STORM working group has gone through the review and updated the > draft to address these. > > Can you please ask the MIB doctors to review the ISCSI MIB module again? > > Thanks in advance, > > Martin > From sam.aldrin@gmail.com Wed Oct 10 17:02:46 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D101F041F for ; Wed, 10 Oct 2012 17:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtLqsNb71sAX for ; Wed, 10 Oct 2012 17:02:45 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC8521F8618 for ; Wed, 10 Oct 2012 17:02:44 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1144875pad.31 for ; Wed, 10 Oct 2012 17:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=58lcP05G1bF3/UXH9z5qLgZ0xZh0YWEgOD6BIQi8A1U=; b=tv1zBt4pqpxg5G4YFOujlKPMc1rAROamjyLl4DUWBtreraNDJ+1D+6sjmrgXCjwKTy IRckXT1J5k5Lp9zKb3DaZM5iRFumg9C2/NipP/z1yAN3VETn3cJdXBqpLW6QZ07DrmUX bekyX2A7Q5c2BBGh+j/UOmlOxtydTGOv8Td78hsrpA87Pij2Kd57RWEogzYKyKCz+x5U 4TD+wOFV5nCMVvoesQFlRhceH4mojHJuZxeoovU2IkqixgHOnICxrq/jA7E5t4TXzcSD AKcz/OGDEakZbcBfd82P9zrBf8IxWcasmO+6FAQa4SeUUpB9qn3mgU1+1uSM1LHYPb6Z soVQ== Received: by 10.68.197.9 with SMTP id iq9mr16760105pbc.130.1349913764435; Wed, 10 Oct 2012 17:02:44 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id x8sm1583617paw.16.2012.10.10.17.02.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 17:02:43 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7769B03B-45B0-419D-A8BA-5F7D4E327F22" From: Sam Aldrin X-Priority: 3 In-Reply-To: <025601cd97f2$fea5c910$6801a8c0@JoanPC> Date: Wed, 10 Oct 2012 17:02:41 -0700 Message-Id: <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:02:46 -0000 --Apple-Mail=_7769B03B-45B0-419D-A8BA-5F7D4E327F22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Joan and MIB doctors, I hope you have gotten a chance to review the MIB document. Kindly let me know if you have any further comments. Will be glad to address them. thanks in advance -sam On Sep 21, 2012, at 5:16 AM, Joan Cucchiara = wrote: > Sam, > =20 > Yes please include MIB Drs on these emails (I have forwarded your = email to them). > =20 > I will take a look at the spreadsheet and MIB soon - hopefully next = week. > =20 > Thanks for being so organized! > -Joan > =20 > =20 > =20 > ----- Original Message ----- > From: Sam Aldrin > To: Joan Cucchiara > Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; = Kannan Sampath > Sent: Sunday, September 16, 2012 2:16 AM > Subject: MPLS TP TE MIB - Edited for review comments >=20 > Hi Joan, >=20 > How are you? thank you in advance for taking time to review the MIB = draft. Appreciate very much. > Please find attachments of the following > - New edited version of the draft > - Excel sheet with all the comments listed and the status and = comments for each of those > - Emails regarding TP names from AD and WG chair (sent as separate = email) > - Changes from last version. >=20 > Some more details: >=20 > We have edited the MIB draft to address the comments. Some of the = comments are not closed till we agree to resolve them with a common = solution or point. They are listed as open in the XLS sheet. Otherwise = most of the comments are addressed. Please do not take this as the = document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level. >=20 > W.r.t TP within the MIB object names, I am not sure when we agreed to = change. If we have done it, we might have misspoke. Reason why we do not = want to change is as follows. When we initially started off the MIB, it = had TP within every object name. But AD (Adrian Farell) and WG chair = (Loa) have comeback and gave review comments to remove because MPLS TP = is not another technology rather it is MPLS. And also, the objects could = be used not only for TP but for bidirectional TE etc. Please find more = details in the attached emails(actually forwarding separately) from = them. >=20 > I haven't copied the email to MIB Dr's. If you want us to, we could do = that. >=20 > Appreciate if you could review and give us your comments, within the = XLS sheet or email. Either way is fine. > Also do let us know if we have missed any comments to track. >=20 > thanks in advance > -sam >=20 > p.s. I'll be out of country for the next 8 days and email access is = sparse. --Apple-Mail=_7769B03B-45B0-419D-A8BA-5F7D4E327F22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi Joan and MIB = doctors,

I hope you have gotten a chance to review = the MIB document.
Kindly let me know if you have any further = comments.
Will be glad to address = them.

thanks in = advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan = Cucchiara <jcucchiara@mindspring.com>= ; wrote:

Sam,
 
Yes please include MIB Drs on these emails (I = have forwarded your email to them).
 
I = will take a look at the spreadsheet and MIB soon - hopefully next = week.
 
Thanks for being so organized!
  -Joan
 
 
 
----- Original Message -----
Sent: Sunday, September 16, 2012 = 2:16 AM
Subject: MPLS TP TE MIB - Edited for = review comments

Hi Joan,

How are you? = thank you in advance for taking time to review the MIB draft. Appreciate = very much.
Please find attachments of the following
  - New = edited version of the draft
  - Excel sheet with all the = comments listed and the status and comments for each of those
  = - Emails regarding TP names from AD and WG chair (sent as separate = email)
  - Changes from last version.

Some more = details:

We have edited the MIB draft to address the comments. = Some of the comments are not closed till we agree to resolve them with a = common solution or point. They are listed as open in the XLS sheet. = Otherwise most of the comments are addressed. Please do not take this as = the document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level.

W.r.t TP within the MIB = object names, I am not sure when we agreed to change. If we have done = it, we might have misspoke. Reason why we do not want to change is as = follows. When we initially started off the MIB, it had TP within every = object name. But AD (Adrian Farell) and WG chair (Loa) have comeback and = gave review comments to remove because MPLS TP is not another technology = rather it is MPLS. And also, the objects could be used not only for TP = but for bidirectional TE etc. Please find more details in the attached = emails(actually forwarding separately) from them.

I haven't = copied the email to MIB Dr's. If you want us to, we could do = that.

Appreciate if you could review and give us your comments, = within the XLS sheet or email. Either way is fine.
Also do let us = know if we have missed any comments to track.

thanks in = advance
-sam

p.s. I'll be out of country for the next 8 days = and email access is sparse. <TP-TE-MIB-Comments.= xls><draft-ietf-mpls-tp-te-mib-05.txt>&= lt;Diff  draft-ietf-mpls-tp-te-mib-04.txt - = draft-ietf-mpls-tp-te-mib-05.txt.htm>
= --Apple-Mail=_7769B03B-45B0-419D-A8BA-5F7D4E327F22-- From bclaise@cisco.com Thu Oct 11 02:26:45 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9AD21F862A for ; Thu, 11 Oct 2012 02:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.846 X-Spam-Level: X-Spam-Status: No, score=-8.846 tagged_above=-999 required=5 tests=[AWL=1.752, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiaBfTUy30gV for ; Thu, 11 Oct 2012 02:26:44 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8881E21F8550 for ; Thu, 11 Oct 2012 02:26:43 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9B9QgII007742 for ; Thu, 11 Oct 2012 11:26:42 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9B9QfJg006610 for ; Thu, 11 Oct 2012 11:26:41 +0200 (CEST) Message-ID: <507690D1.4070800@cisco.com> Date: Thu, 11 Oct 2012 11:26:41 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <50768D41.90205@cisco.com> In-Reply-To: <50768D41.90205@cisco.com> X-Forwarded-Message-Id: <50768D41.90205@cisco.com> Content-Type: multipart/alternative; boundary="------------050504060806050508020207" Subject: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:26:45 -0000 This is a multi-part message in MIME format. --------------050504060806050508020207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit MIB doctors, Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerous review of this MIB, which I fully support. Now, we received some push back from Anil, the author, on the required DEFVAL for scalar. As I wrote below, I always considered the DEFVAL for scalar to be useful information, but I understand both arguments. Read the email exchange below. Which advice do we want to give in the future on this topic? I'm in favor of telling: - DEFVAL for scalar objects are nice-to-have, and it's good practice to have them This is in line with RFC 2578, section 7.9 says: Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. - If you don't put DEFVAL for scalar objects, then insert in the description a pointer on where to find the information Regards, Benoit. -------- Original Message -------- Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) Date: Thu, 11 Oct 2012 11:11:30 +0200 From: Benoit Claise To: Anil Rijhsinghani CC: Romascanu, Dan (Dan) , Donald Eastlake , Erik Nordmark , Ralph Droms , Bert Wijnen (IETF) , zebrose@alum.mit.edu, Joan Cucchiara , me Anil, Dan, I understand both arguments for and against DEFVAL for scalar. I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. 1. If you are the implementor, you must know the spec by heart, and obviously, these scalar DEFVAL's are not useful to you. 2. If you are the SNMP agent, it's true that the SNMPset contains the value to be set, so you don't need the DEFVAL. 3. If you are the network operator using the NMS GUI , it's pretty useful information to have default values. It's pretty nice when a NMS GUI contains the DEVAL value. Sure you can tell that, by looking at the specifications, someone will be able to get this value. In practice, is it done? So if the GUI developers could directly get the information from the DEFVAL, that's a plus. I've seen to many GUIs where the first config page allows to enter almost anything. And the network operator just puts random values in there. In the world of NetFlow, inserting non-sense timeout values produced some funny results. 4. If you are none of the above... Once upon a time, I was a NMS customer support engineer, and I read many MIB modules. And the DEFVAL always helped getting the default values. If nothing else, for troubleshooting. And no, I didn't know (and didn't want to know) all the protocol specification details of the feature/protocol to be managed. You see, there are multiple actors dealing with MIB modules. How to more forward? > By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable. That's good information already, and I could leave with that. It's actually just a (*) level of indirection (*) time consuming if I take the case 4 above, i.e. my customer support engineer. I want to publicly thanks Joan for the time spent on her review. Much appreciated. Now, I would like to have some consistency from the MIB doctors in terms of guidelines on this topic. Let me discuss with them. Regards, Benoit. > Dan, > > An SNMP set operation is used to change the value of a read-write > object, or to create a new row in a table. There is a distinct > difference between the applicability of DEFVAL in these two cases, > hence the "appropriate" versus "permitted" language in the definition > of the DEFVAL clause for these two cases. > > When a set operation is performed on a scalar object, it comes with a > value to write into it. The SNMP agent need not guess what that value > might be, nor does it need to rely on the MIB to tell it what to do. > > When a set operation is performed to create a new row in a table, it > may specify the value of one or more columns in that row. If the SNMP > agent is going to create a row, and not all column objects have been > specified, it is left with a dilemma: what should it set as the values > of those column objects? This is what the DEFVAL clause allows you to > do: give the agent a default value for unspecified column objects. > Such a dilemma does not occur for setting of scalar objects. > > If what you were saying is true, then every read-write object in every > MIB would need a DEFVAL clause. Clearly that is not the case. > > By the way I have included a REFERENCE clause in most objects, guiding > an implementor to the section of the protocol RFC where he can find > more information about the object and its default, if applicable. > > If this doesn't convince you, we will have to agree to disagree on this. > > Regards, > Anil > > > On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: > > Hi Anil, > I need to disagree with you on this. The DEFVAL function is the same > for a scalar and for a columnar object – as you well put it ‘the > agent can deduce the missing value from the MIB syntax’. > I do not understand your argument that the implementor should look at > the protocol specifications to in the case of scalar objects. We are > talking about writeable objects. Whatever the agent initializes with > will be sent to the instrumentation. In the absence of a DEFVAL value > anything can be written there. The same as in the case of a columnar > object the DEFVAL will indicate the value the agent initializes with > which will be the first value to be sent to the instrumentation until > a setRequest command changes it. Why should the agent implementor need > to look in the protocol specifications and not help him defining > DEFVAL clauses? > Regards, > Dan > *From: *Anil R [mailto:anil@charter.net] > *Sent: *Wednesday, October 10, 2012 3:33 PM > *To: *Romascanu, Dan (Dan) > *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert > Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara > *Subject: *Re: Benoit Claise's Discuss on > draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) > Dan, > From the description: > - as a columnar object, it is "appropriate" to use DEFVAL > - as a scalar object, it is "permitted" to use DEFVAL. > Sure I know it is permitted for scalar objects, as that will not cause > a compile error. > For columnar objects, it is actually useful, because a manager may > create an instance without specifying a columnar object. So it is > syntactically and practically useful to do so in such cases, because > the agent can deduce the missing value from the MIB syntax. It makes > the protocol more efficient. I know this is why we added DEFVAL, based > on my interaction at the time with the original SNMP authors (Jeff > Case, et al). > My point is that not only is specifying DEFVAL for a scalar useless > from an SNMP syntactical point of view - because an agent cannot > actually use it, other than an implementor reading the RFC text - but > it is actually dangerous to do so. An implementor TRILL should be > looking to the protocol specification (RFC6325 in this case) to > determine how the protocol works and what the needed defaults are. > We don't to define defaults in two different RFCs if we can help it. > If the protocol decides to change a default, we shouldn't have to go > update the MIB. > Regards, > Anil > On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: > > > > Hi Anil, > I believe that you are wrong stating that DEFVAL clauses should not be > present in the definitions of scalar objects, or at least I could not > find such a recommendations in the RFCs that define the SMI. On the > contrary, RFC 2578, section 7.9 says: > Note that with this definition of the DEFVAL clause, it is > appropriate to use it for any columnar object of a read-create table. > It is also permitted to use it for scalar objects dynamically created > by an agent, or for columnar objects of a read-write table > dynamically created by an agent. > So when an agent is initialized it is good practice to define default > values for writeable objects (scalar or columnar) unless we do not > care what value the agent starts operating with. > Regards, > Dan > *From: * Anil R [ _mailto:anil@charter.net_ > ] > *Sent: * Wednesday, October 10, 2012 2:40 PM > *To: * Benoit Claise > *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen > (IETF); _zebrose@alum.mit.edu_ > ; > Romascanu, Dan (Dan); Joan Cucchiara > *Subject: * Re: Benoit Claise's Discuss on > draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) > Benoit, > I will make a good faith attempt at responding to these comments yet > again, although I have already responded to many of them (other than > new ones that just showed up in the latest round). > The DEFVAL comment is one which keeps coming back, disregarding my > many responses that this is not a useful construct for scalar objects > and its chief purpose is to give a default value to tables objects > missing in the creation of a table instance, as described in its > definition "The DEFVAL clause, which need not be present, defines an > acceptable default value which may be used when an object instance is > created." > DEFVAL need not be present even in table objects, but definitely > should not be present in scalar objects - but the latter is what > several of these comments are insisting upon. It is the protocol > specification that defines default values for protocol objects, not MIBs. > Regards, > Anil > --------------050504060806050508020207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be useful information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice to have them
    This is in line with
RFC 2578, section 7.9 says:
 
   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.
- If you don't put DEFVAL for scalar objects, then insert in the description a pointer on where to find the information

Regards, Benoit.

 


-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake <d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, Ralph Droms <rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <bertietf@bwijnen.net>, zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me <bclaise@cisco.com>


Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.

1. If you are the implementor, you must know the spec by heart, and obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty useful information to have default values. It's pretty nice when a NMS GUI contains the DEVAL value. Sure you can tell that, by looking at the specifications, someone will be able to get this value. In practice, is it done? So if the GUI developers could directly get the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter almost anything. And the network operator just puts random values in there. In the world of NetFlow, inserting non-sense timeout values produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.
That's good information already, and I could leave with that. It's actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer support engineer.

I want to publicly thanks Joan for the time spent on her review. Much appreciated.
Now, I would like to have some consistency from the MIB doctors in terms of guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,
An SNMP set operation is used to change the value of a read-write object, or to create a new row in a table. There is a distinct difference between the applicability of DEFVAL in these two cases, hence the "appropriate" versus "permitted" language in the definition of the DEFVAL clause for these two cases.
When a set operation is performed on a scalar object, it comes with a value to write into it. The SNMP agent need not guess what that value might be,  nor does it need to rely on the MIB to tell it what to do.
When a set operation is performed to create a new row in a table, it may specify the value of one or more columns in that row. If the SNMP agent is going to create a row, and not all column objects have been specified, it is left with a dilemma: what should it set as the values of those column objects? This is what the DEFVAL clause allows you to do: give the agent a default value for unspecified column objects. Such a dilemma does not occur for setting of scalar objects.
If what you were saying is true, then every read-write object in every MIB would need a DEFVAL clause. Clearly that is not the case.
By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.
If this doesn't convince you, we will have to agree to disagree on this.
Regards,
Anil
On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:
 Hi Anil,
 
I need to disagree with you on this. The DEFVAL function is the same for a scalar and for a columnar object – as you well put it  ‘the agent can deduce the missing value from the MIB syntax’.
 
I do not understand your argument that the implementor should look at the protocol specifications to in the case of scalar objects. We are talking about writeable objects. Whatever the agent initializes with will be sent to the instrumentation. In the absence of a DEFVAL value anything can be written there. The same as in the case of a columnar object the DEFVAL will indicate the value the agent initializes with which will be the first value to be sent to the instrumentation until a setRequest command changes it. Why should the agent implementor need to look in the protocol specifications and not help him defining DEFVAL clauses?
 
Regards,
 
Dan
 
 
 
From: Anil R [mailto:anil@charter.net]
Sent: Wednesday, October 10, 2012 3:33 PM
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara
Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
 
Dan,
 
From the description:
- as a columnar object, it is "appropriate" to use DEFVAL
- as a scalar object, it is "permitted" to use DEFVAL.
 
Sure I know it is permitted for scalar objects, as that will not cause a compile error.
 
For columnar objects, it is actually useful, because a manager may create an instance without specifying a columnar object. So it is syntactically and practically useful to do so in such cases, because the agent can deduce the missing value from the MIB syntax. It makes the protocol more efficient. I know this is why we added DEFVAL, based on my interaction at the time with the original SNMP authors (Jeff Case, et al).
 
My point is that not only is specifying DEFVAL for a scalar useless from an SNMP syntactical point of view - because an agent cannot actually use it, other than an implementor reading the RFC text - but it is actually dangerous to do so. An implementor TRILL should be looking to the protocol specification (RFC6325 in this case) to determine how the protocol works and what the needed defaults are.
 
We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to go update the MIB.
 
Regards,
Anil
 
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:



Hi Anil,
 
I believe that you are wrong stating that DEFVAL clauses should not be present in the definitions of scalar objects, or at least I could not find such a recommendations in the RFCs that define the SMI. On the contrary, RFC 2578, section 7.9 says:
 
   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.
 
So when an agent is initialized it is good practice to define default values for writeable objects (scalar or columnar) unless we do not care what value the agent starts operating with.
 
 
Regards,
 
Dan
 
 
 
 
From:   Anil R [ mailto:anil@charter.net]  
Sent:   Wednesday, October 10, 2012 2:40 PM
To:   Benoit Claise
Cc:   Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF);   zebrose@alum.mit.edu; Romascanu, Dan (Dan); Joan Cucchiara
Subject:   Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
 
Benoit,
 
I will make a good faith attempt at responding to these comments yet again, although I have already responded to many of them (other than new ones that just showed up in the latest round).
 
The DEFVAL comment is one which keeps coming back, disregarding my many responses that this is not a useful construct for scalar objects and its chief purpose is to give a default value to tables objects missing in the creation of a table instance, as described in its definition "The DEFVAL clause, which need not be present, defines an acceptable default value which may be used when an object instance is created."
 
DEFVAL need not be present even in table objects, but definitely should not be present in scalar objects - but the latter is what several of these comments are insisting upon. It is the protocol specification that defines default values for protocol objects, not MIBs.
 
Regards,
Anil
 

--------------050504060806050508020207-- From j.schoenwaelder@jacobs-university.de Thu Oct 11 04:13:58 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80F521F8589 for ; Thu, 11 Oct 2012 04:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.221 X-Spam-Level: X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mRiH3iTeHPZ for ; Thu, 11 Oct 2012 04:13:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7521F8575 for ; Thu, 11 Oct 2012 04:13:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 078B120C77; Thu, 11 Oct 2012 13:13:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4QS1cIIcRt3Z; Thu, 11 Oct 2012 13:13:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91AB120C6F; Thu, 11 Oct 2012 13:13:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E94062243419; Thu, 11 Oct 2012 13:13:52 +0200 (CEST) Date: Thu, 11 Oct 2012 13:13:52 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20121011111352.GA65010@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <507690D1.4070800@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:13:58 -0000 Hi, I think the issue boils down to the question whether the scalars are dynamically created by an agent or not. e.e., they come into existance as a side effect of setting some other object. In such situations, DEFVALs are useful to document which value a management system may expect to be held in the newly established scalar (but note also that the DEFVAL clause is not binding; the value is used "at the discretion of an agent when an object instance is created" - a conservative management application will thus check the value anyway if it is important). /js On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: > MIB doctors, > > Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your > numerous review of this MIB, which I fully support. > > Now, we received some push back from Anil, the author, on the > required DEFVAL for scalar. > As I wrote below, I always considered the DEFVAL for scalar to be > useful information, but I understand both arguments. > Read the email exchange below. > > Which advice do we want to give in the future on this topic? > > I'm in favor of telling: > - DEFVAL for scalar objects are nice-to-have, and it's good practice > to have them > This is in line with > > RFC 2578, section 7.9 says: > Note that with this definition of the DEFVAL clause, it is > appropriate to use it for any columnar object of a read-create > table. > It is also permitted to use it for scalar objects dynamically > created > by an agent, or for columnar objects of a read-write table > dynamically created by an agent. > > - If you don't put DEFVAL for scalar objects, then insert in the > description a pointer on where to find the information > > Regards, Benoit. > > > > > -------- Original Message -------- > Subject: Re: Benoit Claise's Discuss on > draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) > Date: Thu, 11 Oct 2012 11:11:30 +0200 > From: Benoit Claise > To: Anil Rijhsinghani > CC: Romascanu, Dan (Dan) , Donald Eastlake > , Erik Nordmark , Ralph Droms > , Bert Wijnen (IETF) , > zebrose@alum.mit.edu, Joan Cucchiara , me > > > > > Anil, Dan, > > I understand both arguments for and against DEFVAL for scalar. > > I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. > > 1. If you are the implementor, you must know the spec by heart, and > obviously, these scalar DEFVAL's are not useful to you. > 2. If you are the SNMP agent, it's true that the SNMPset contains > the value to be set, so you don't need the DEFVAL. > 3. If you are the network operator using the NMS GUI , it's pretty > useful information to have default values. It's pretty nice when a > NMS GUI contains the DEVAL value. Sure you can tell that, by looking > at the specifications, someone will be able to get this value. In > practice, is it done? So if the GUI developers could directly get > the information from the DEFVAL, that's a plus. > I've seen to many GUIs where the first config page allows to enter > almost anything. And the network operator just puts random values in > there. In the world of NetFlow, inserting non-sense timeout values > produced some funny results. > 4. If you are none of the above... Once upon a time, I was a NMS > customer support engineer, and I read many MIB modules. > And the DEFVAL always helped getting the default values. If nothing > else, for troubleshooting. > And no, I didn't know (and didn't want to know) all the protocol > specification details of the feature/protocol to be managed. > > You see, there are multiple actors dealing with MIB modules. > > How to more forward? > > By the way I have included a REFERENCE clause in most objects, > guiding an implementor to the section of the protocol RFC where he > can find more information about the object and its default, if > applicable. > That's good information already, and I could leave with that. It's > actually just a (*) level of indirection > > (*) time consuming if I take the case 4 above, i.e. my customer > support engineer. > > I want to publicly thanks Joan for the time spent on her review. > Much appreciated. > Now, I would like to have some consistency from the MIB doctors in > terms of guidelines on this topic. Let me discuss with them. > > > Regards, Benoit. > > >Dan, > > > >An SNMP set operation is used to change the value of a read-write > >object, or to create a new row in a table. There is a distinct > >difference between the applicability of DEFVAL in these two cases, > >hence the "appropriate" versus "permitted" language in the > >definition of the DEFVAL clause for these two cases. > > > >When a set operation is performed on a scalar object, it comes > >with a value to write into it. The SNMP agent need not guess what > >that value might be, nor does it need to rely on the MIB to tell > >it what to do. > > > >When a set operation is performed to create a new row in a table, > >it may specify the value of one or more columns in that row. If > >the SNMP agent is going to create a row, and not all column > >objects have been specified, it is left with a dilemma: what > >should it set as the values of those column objects? This is what > >the DEFVAL clause allows you to do: give the agent a default value > >for unspecified column objects. Such a dilemma does not occur for > >setting of scalar objects. > > > >If what you were saying is true, then every read-write object in > >every MIB would need a DEFVAL clause. Clearly that is not the > >case. > > > >By the way I have included a REFERENCE clause in most objects, > >guiding an implementor to the section of the protocol RFC where he > >can find more information about the object and its default, if > >applicable. > > > >If this doesn't convince you, we will have to agree to disagree on this. > > > >Regards, > >Anil > > > > > >On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: > > > >Hi Anil, > >I need to disagree with you on this. The DEFVAL function is the > >same for a scalar and for a columnar object – as you well put it > >‘the agent can deduce the missing value from the MIB syntax’. > >I do not understand your argument that the implementor should look > >at the protocol specifications to in the case of scalar objects. > >We are talking about writeable objects. Whatever the agent > >initializes with will be sent to the instrumentation. In the > >absence of a DEFVAL value anything can be written there. The same > >as in the case of a columnar object the DEFVAL will indicate the > >value the agent initializes with which will be the first value to > >be sent to the instrumentation until a setRequest command changes > >it. Why should the agent implementor need to look in the protocol > >specifications and not help him defining DEFVAL clauses? > >Regards, > >Dan > >*From: *Anil R [mailto:anil@charter.net] > >*Sent: *Wednesday, October 10, 2012 3:33 PM > >*To: *Romascanu, Dan (Dan) > >*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; > >Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara > >*Subject: *Re: Benoit Claise's Discuss on > >draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) > >Dan, > >From the description: > >- as a columnar object, it is "appropriate" to use DEFVAL > >- as a scalar object, it is "permitted" to use DEFVAL. > >Sure I know it is permitted for scalar objects, as that will not > >cause a compile error. > >For columnar objects, it is actually useful, because a manager may > >create an instance without specifying a columnar object. So it is > >syntactically and practically useful to do so in such cases, > >because the agent can deduce the missing value from the MIB > >syntax. It makes the protocol more efficient. I know this is why > >we added DEFVAL, based on my interaction at the time with the > >original SNMP authors (Jeff Case, et al). > >My point is that not only is specifying DEFVAL for a scalar > >useless from an SNMP syntactical point of view - because an agent > >cannot actually use it, other than an implementor reading the RFC > >text - but it is actually dangerous to do so. An implementor TRILL > >should be looking to the protocol specification (RFC6325 in this > >case) to determine how the protocol works and what the needed > >defaults are. > >We don't to define defaults in two different RFCs if we can help it. > >If the protocol decides to change a default, we shouldn't have to > >go update the MIB. > >Regards, > >Anil > >On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: > > > > > > > >Hi Anil, > >I believe that you are wrong stating that DEFVAL clauses should > >not be present in the definitions of scalar objects, or at least I > >could not find such a recommendations in the RFCs that define the > >SMI. On the contrary, RFC 2578, section 7.9 says: > > Note that with this definition of the DEFVAL clause, it is > > appropriate to use it for any columnar object of a read-create table. > > It is also permitted to use it for scalar objects dynamically created > > by an agent, or for columnar objects of a read-write table > > dynamically created by an agent. > >So when an agent is initialized it is good practice to define > >default values for writeable objects (scalar or columnar) unless > >we do not care what value the agent starts operating with. > >Regards, > >Dan > >*From: * Anil R [ _mailto:anil@charter.net_ > >] > >*Sent: * Wednesday, October 10, 2012 2:40 PM > >*To: * Benoit Claise > >*Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen > >(IETF); _zebrose@alum.mit.edu_ ; > >Romascanu, Dan (Dan); Joan Cucchiara > >*Subject: * Re: Benoit Claise's Discuss on > >draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) > >Benoit, > >I will make a good faith attempt at responding to these comments > >yet again, although I have already responded to many of them > >(other than new ones that just showed up in the latest round). > >The DEFVAL comment is one which keeps coming back, disregarding my > >many responses that this is not a useful construct for scalar > >objects and its chief purpose is to give a default value to tables > >objects missing in the creation of a table instance, as described > >in its definition "The DEFVAL clause, which need not be present, > >defines an acceptable default value which may be used when an > >object instance is created." > >DEFVAL need not be present even in table objects, but definitely > >should not be present in scalar objects - but the latter is what > >several of these comments are insisting upon. It is the protocol > >specification that defines default values for protocol objects, > >not MIBs. > >Regards, > >Anil > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Oct 11 04:35:48 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9824121F86DE for ; Thu, 11 Oct 2012 04:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr4u5CHACTPY for ; Thu, 11 Oct 2012 04:35:47 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 1106221F86D3 for ; Thu, 11 Oct 2012 04:35:47 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TMH3H-00078M-Iu; Thu, 11 Oct 2012 13:35:46 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TMH3H-0003ld-0U; Thu, 11 Oct 2012 13:35:43 +0200 Message-ID: <5076AF0E.1000209@bwijnen.net> Date: Thu, 11 Oct 2012 13:35:42 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Benoit Claise , "MIB Doctors (E-mail)" References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com> <20121011111352.GA65010@elstar.local> In-Reply-To: <20121011111352.GA65010@elstar.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121011 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46615229a6e905ff70c383ba6a8e5e9ff Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:35:48 -0000 Agree. I consider it a nice to have for scalars, but we have approved quite a few MIB modules that did not have it for (all) scalars. So we betterbe a bit flexible on this point. We can recommend that they do it where it makes sense. I would not hold up a MIB module for too long if they resist/reject (certainly if they have good arguments). Bert On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: > Hi, > > I think the issue boils down to the question whether the scalars are > dynamically created by an agent or not. e.e., they come into existance > as a side effect of setting some other object. In such situations, > DEFVALs are useful to document which value a management system may > expect to be held in the newly established scalar (but note also that > the DEFVAL clause is not binding; the value is used "at the discretion > of an agent when an object instance is created" - a conservative > management application will thus check the value anyway if it is > important). > > /js > > On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >> MIB doctors, >> >> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your >> numerous review of this MIB, which I fully support. >> >> Now, we received some push back from Anil, the author, on the >> required DEFVAL for scalar. >> As I wrote below, I always considered the DEFVAL for scalar to be >> useful information, but I understand both arguments. >> Read the email exchange below. >> >> Which advice do we want to give in the future on this topic? >> >> I'm in favor of telling: >> - DEFVAL for scalar objects are nice-to-have, and it's good practice >> to have them >> This is in line with >> >> RFC 2578, section 7.9 says: >> Note that with this definition of the DEFVAL clause, it is >> appropriate to use it for any columnar object of a read-create >> table. >> It is also permitted to use it for scalar objects dynamically >> created >> by an agent, or for columnar objects of a read-write table >> dynamically created by an agent. >> >> - If you don't put DEFVAL for scalar objects, then insert in the >> description a pointer on where to find the information >> >> Regards, Benoit. >> >> >> >> >> -------- Original Message -------- >> Subject: Re: Benoit Claise's Discuss on >> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >> Date: Thu, 11 Oct 2012 11:11:30 +0200 >> From: Benoit Claise >> To: Anil Rijhsinghani >> CC: Romascanu, Dan (Dan) , Donald Eastlake >> , Erik Nordmark , Ralph Droms >> , Bert Wijnen (IETF) , >> zebrose@alum.mit.edu, Joan Cucchiara , me >> >> >> >> >> Anil, Dan, >> >> I understand both arguments for and against DEFVAL for scalar. >> >> I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. >> >> 1. If you are the implementor, you must know the spec by heart, and >> obviously, these scalar DEFVAL's are not useful to you. >> 2. If you are the SNMP agent, it's true that the SNMPset contains >> the value to be set, so you don't need the DEFVAL. >> 3. If you are the network operator using the NMS GUI , it's pretty >> useful information to have default values. It's pretty nice when a >> NMS GUI contains the DEVAL value. Sure you can tell that, by looking >> at the specifications, someone will be able to get this value. In >> practice, is it done? So if the GUI developers could directly get >> the information from the DEFVAL, that's a plus. >> I've seen to many GUIs where the first config page allows to enter >> almost anything. And the network operator just puts random values in >> there. In the world of NetFlow, inserting non-sense timeout values >> produced some funny results. >> 4. If you are none of the above... Once upon a time, I was a NMS >> customer support engineer, and I read many MIB modules. >> And the DEFVAL always helped getting the default values. If nothing >> else, for troubleshooting. >> And no, I didn't know (and didn't want to know) all the protocol >> specification details of the feature/protocol to be managed. >> >> You see, there are multiple actors dealing with MIB modules. >> >> How to more forward? >>> By the way I have included a REFERENCE clause in most objects, >> guiding an implementor to the section of the protocol RFC where he >> can find more information about the object and its default, if >> applicable. >> That's good information already, and I could leave with that. It's >> actually just a (*) level of indirection >> >> (*) time consuming if I take the case 4 above, i.e. my customer >> support engineer. >> >> I want to publicly thanks Joan for the time spent on her review. >> Much appreciated. >> Now, I would like to have some consistency from the MIB doctors in >> terms of guidelines on this topic. Let me discuss with them. >> >> >> Regards, Benoit. >> >>> Dan, >>> >>> An SNMP set operation is used to change the value of a read-write >>> object, or to create a new row in a table. There is a distinct >>> difference between the applicability of DEFVAL in these two cases, >>> hence the "appropriate" versus "permitted" language in the >>> definition of the DEFVAL clause for these two cases. >>> >>> When a set operation is performed on a scalar object, it comes >>> with a value to write into it. The SNMP agent need not guess what >>> that value might be, nor does it need to rely on the MIB to tell >>> it what to do. >>> >>> When a set operation is performed to create a new row in a table, >>> it may specify the value of one or more columns in that row. If >>> the SNMP agent is going to create a row, and not all column >>> objects have been specified, it is left with a dilemma: what >>> should it set as the values of those column objects? This is what >>> the DEFVAL clause allows you to do: give the agent a default value >>> for unspecified column objects. Such a dilemma does not occur for >>> setting of scalar objects. >>> >>> If what you were saying is true, then every read-write object in >>> every MIB would need a DEFVAL clause. Clearly that is not the >>> case. >>> >>> By the way I have included a REFERENCE clause in most objects, >>> guiding an implementor to the section of the protocol RFC where he >>> can find more information about the object and its default, if >>> applicable. >>> >>> If this doesn't convince you, we will have to agree to disagree on this. >>> >>> Regards, >>> Anil >>> >>> >>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>> >>> Hi Anil, >>> I need to disagree with you on this. The DEFVAL function is the >>> same for a scalar and for a columnar object – as you well put it >>> ‘the agent can deduce the missing value from the MIB syntax’. >>> I do not understand your argument that the implementor should look >>> at the protocol specifications to in the case of scalar objects. >>> We are talking about writeable objects. Whatever the agent >>> initializes with will be sent to the instrumentation. In the >>> absence of a DEFVAL value anything can be written there. The same >>> as in the case of a columnar object the DEFVAL will indicate the >>> value the agent initializes with which will be the first value to >>> be sent to the instrumentation until a setRequest command changes >>> it. Why should the agent implementor need to look in the protocol >>> specifications and not help him defining DEFVAL clauses? >>> Regards, >>> Dan >>> *From: *Anil R [mailto:anil@charter.net] >>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>> *To: *Romascanu, Dan (Dan) >>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; >>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>> *Subject: *Re: Benoit Claise's Discuss on >>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>> Dan, >> >From the description: >>> - as a columnar object, it is "appropriate" to use DEFVAL >>> - as a scalar object, it is "permitted" to use DEFVAL. >>> Sure I know it is permitted for scalar objects, as that will not >>> cause a compile error. >>> For columnar objects, it is actually useful, because a manager may >>> create an instance without specifying a columnar object. So it is >>> syntactically and practically useful to do so in such cases, >>> because the agent can deduce the missing value from the MIB >>> syntax. It makes the protocol more efficient. I know this is why >>> we added DEFVAL, based on my interaction at the time with the >>> original SNMP authors (Jeff Case, et al). >>> My point is that not only is specifying DEFVAL for a scalar >>> useless from an SNMP syntactical point of view - because an agent >>> cannot actually use it, other than an implementor reading the RFC >>> text - but it is actually dangerous to do so. An implementor TRILL >>> should be looking to the protocol specification (RFC6325 in this >>> case) to determine how the protocol works and what the needed >>> defaults are. >>> We don't to define defaults in two different RFCs if we can help it. >>> If the protocol decides to change a default, we shouldn't have to >>> go update the MIB. >>> Regards, >>> Anil >>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>> >>> >>> >>> Hi Anil, >>> I believe that you are wrong stating that DEFVAL clauses should >>> not be present in the definitions of scalar objects, or at least I >>> could not find such a recommendations in the RFCs that define the >>> SMI. On the contrary, RFC 2578, section 7.9 says: >>> Note that with this definition of the DEFVAL clause, it is >>> appropriate to use it for any columnar object of a read-create table. >>> It is also permitted to use it for scalar objects dynamically created >>> by an agent, or for columnar objects of a read-write table >>> dynamically created by an agent. >>> So when an agent is initialized it is good practice to define >>> default values for writeable objects (scalar or columnar) unless >>> we do not care what value the agent starts operating with. >>> Regards, >>> Dan >>> *From: * Anil R [ _mailto:anil@charter.net_ >>> ] >>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>> *To: * Benoit Claise >>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen >>> (IETF); _zebrose@alum.mit.edu_ ; >>> Romascanu, Dan (Dan); Joan Cucchiara >>> *Subject: * Re: Benoit Claise's Discuss on >>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>> Benoit, >>> I will make a good faith attempt at responding to these comments >>> yet again, although I have already responded to many of them >>> (other than new ones that just showed up in the latest round). >>> The DEFVAL comment is one which keeps coming back, disregarding my >>> many responses that this is not a useful construct for scalar >>> objects and its chief purpose is to give a default value to tables >>> objects missing in the creation of a table instance, as described >>> in its definition "The DEFVAL clause, which need not be present, >>> defines an acceptable default value which may be used when an >>> object instance is created." >>> DEFVAL need not be present even in table objects, but definitely >>> should not be present in scalar objects - but the latter is what >>> several of these comments are insisting upon. It is the protocol >>> specification that defines default values for protocol objects, >>> not MIBs. >>> Regards, >>> Anil >>> >> > >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > From bertietf@bwijnen.net Thu Oct 11 04:48:58 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DDA21F862B for ; Thu, 11 Oct 2012 04:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.623 X-Spam-Level: X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppY+XDuJVKOV for ; Thu, 11 Oct 2012 04:48:57 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A78221F861D for ; Thu, 11 Oct 2012 04:48:57 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.80) (envelope-from ) id 1TMHFo-0001Cv-A8; Thu, 11 Oct 2012 13:48:40 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: , References: In-Reply-To: Date: Thu, 11 Oct 2012 13:48:34 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1068_01CDA7B7.1B4F0670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] MEF-SOAM-FM-MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:48:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1068_01CDA7B7.1B4F0670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So a few questions: - where is the MIB module located now? Since it is a MEF MIB module, it is probably somewhere on the MEF web site? I am not a regular MEF participant. - So if you can (have access rights) to upload a new version is not a question I can answer - What I DO know: there are SMI and MIB rules that need to be followed when you make changes/fixes to MIB modules. They are described in section 4.9 of RFC4181. Bert ----- Original Message -----=20 From: Patrik.Hollstrom@tieto.com=20 To: smood@omnitron-systems.com ; bertietf@bwijnen.net=20 Sent: Thursday, October 11, 2012 12:20 PM Subject: MEF-SOAM-FM-MIB Hi Steve and Bert, I found a mailing list(MIB Doctors from 2010) with your names in it = regarding the MEF-SOAM-FM-MIB. We seem to have found some possible errors/warnings, preventing = compilation of the MIB. Is there any way to update the current MIB? What is the process? One of our problems: =20 mefSoamMepStatusLastDefectSentStatus OBJECT-TYPE SYNTAX Dot1agCfmMepDefects MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the state of the = previous MEP defects, dot1agCfmMepDefects, that was sent with the = previous mefSoamMepDefect notification. It is always = some *previous* value of dot1agCfmMepDefects. Once an = mefSoamMepDefect is sent the dot1agCfmMepDefects that was sent in the = notification updates the contents of this object. If no mefSoamMepDefect notification has been = sent the value of this object is '0'. " DEFVAL { { } } ::=3D { mefSoamMepStatusEntry 5 } =20 =20 Hope you have the time to answer, =20 Best Regards Patrik ------=_NextPart_000_1068_01CDA7B7.1B4F0670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So a few questions:
 
- where is the MIB module located now?
  Since it is a MEF MIB module, it is probably = somewhere=20 on the MEF
  web site? I am not a regular MEF = participant.
- So if you can (have access rights) to upload a new = version=20 is
  not a question I can answer
- What I DO know: there are SMI and MIB rules that = need to=20 be
  followed when you make changes/fixes to MIB=20 modules.
  They are described in section 4.9 of=20 RFC4181.
 
Bert
----- Original Message -----
From:=20 Patrik.Hollstrom@tieto.com=
To: smood@omnitron-systems.com= ; bertietf@bwijnen.net
Sent: Thursday, October 11, = 2012 12:20=20 PM
Subject: MEF-SOAM-FM-MIB

Hi Steve=20 and Bert,

I found=20 a mailing list(MIB Doctors from 2010) with your names in it regarding = the=20 MEF-SOAM-FM-MIB.

We seem=20 to have found some possible errors/warnings, preventing compilation of = the=20 MIB.

Is there=20 any way to update the current MIB? What is the = process?

One of=20 our problems:

 

mefSoamMepStatusLastDefectSentStatus=20 OBJECT-TYPE

          =  =20 SYNTAX Dot1agCfmMepDefects

          =  =20 MAX-ACCESS read-only

          =  =20 STATUS current

          =  =20 DESCRIPTION

          =             &= nbsp;=20 "This attribute indicates the state of the previous MEP=20 defects,

          =             &= nbsp;=20 dot1agCfmMepDefects, that was sent with the = previous

          =             &= nbsp;=20 mefSoamMepDefect notification. It is always some *previous*=20 value

          =             &= nbsp;=20 of dot1agCfmMepDefects. Once an mefSoamMepDefect is = sent

          =             &= nbsp;=20 the dot1agCfmMepDefects that was sent in the=20 notification

          =             &= nbsp;=20 updates the contents of this object.

          =             &= nbsp;=20 If no mefSoamMepDefect notification has been sent the value=20 of

          =             &= nbsp;=20 this object is '0'.

          =             &= nbsp;=20 "

          =  =20 DEFVAL { { } = }

          =  =20 ::=3D { mefSoamMepStatusEntry 5 }

 

 

Hope you=20 have the time to answer,

 

Best=20 Regards

Patrik

------=_NextPart_000_1068_01CDA7B7.1B4F0670-- From jcucchiara@mindspring.com Thu Oct 11 08:04:41 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125EC21F86F6 for ; Thu, 11 Oct 2012 08:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg-UOYbd5zWT for ; Thu, 11 Oct 2012 08:04:39 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFDE21F86C9 for ; Thu, 11 Oct 2012 08:04:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TmAIIKum72iftwrnabomRiJgJLWW1KT5fJXaDOqlvoyLq7pqVDG1FBKcxPMkYb0U; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TMKJN-0008F1-PS; Thu, 11 Oct 2012 11:04:33 -0400 Message-ID: <007101cda7c1$6ed964c0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Bert Wijnen \(IETF\)" , "Benoit Claise" , "MIB Doctors \(E-mail\)" References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com><20121011111352.GA65010@elstar.local> <5076AF0E.1000209@bwijnen.net> Date: Thu, 11 Oct 2012 11:02:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26541bbfb1ff54e3653900ead0e9616fc3a3773bb16c9ad91485350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:04:41 -0000 For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have DEFVALs specified in the protocol (RFC6325). Not all protocol specifications do specify default values as clearly as this specification does. When default values are specified in the protocol (RFC) as is mostly the situation being discussed here with the scalars, I think DEFVALs SHOULD be put into the MIB. I would like to say MUST, but believe Bert and Juergen have pointed out that there is precedence to flexible on this. Please note, however, if these DEFVALs which have been specified by the RFC6325 were in the MIB, they could be interpreted/compiled by tools which process MIBs and this reduces error and assists in promoting interoperability. All in all, better for the MIB's deployment and better for the WG to promote the protocol. Thanks, -Joan ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Benoit Claise" ; "MIB Doctors (E-mail)" Sent: Thursday, October 11, 2012 7:35 AM Subject: Re: [MIB-DOCTORS] DEVAL for scalar object > Agree. > I consider it a nice to have for scalars, but we have > approved quite a few MIB modules that did not have it > for (all) scalars. So we betterbe a bit flexible on > this point. We can recommend that they do it where it > makes sense. I would not hold up a MIB module for too > long if they resist/reject (certainly if they have > good arguments). > > Bert > > On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >> Hi, >> >> I think the issue boils down to the question whether the scalars are >> dynamically created by an agent or not. e.e., they come into existance >> as a side effect of setting some other object. In such situations, >> DEFVALs are useful to document which value a management system may >> expect to be held in the newly established scalar (but note also that >> the DEFVAL clause is not binding; the value is used "at the discretion >> of an agent when an object instance is created" - a conservative >> management application will thus check the value anyway if it is >> important). >> >> /js >> >> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>> MIB doctors, >>> >>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your >>> numerous review of this MIB, which I fully support. >>> >>> Now, we received some push back from Anil, the author, on the >>> required DEFVAL for scalar. >>> As I wrote below, I always considered the DEFVAL for scalar to be >>> useful information, but I understand both arguments. >>> Read the email exchange below. >>> >>> Which advice do we want to give in the future on this topic? >>> >>> I'm in favor of telling: >>> - DEFVAL for scalar objects are nice-to-have, and it's good practice >>> to have them >>> This is in line with >>> >>> RFC 2578, section 7.9 says: >>> Note that with this definition of the DEFVAL clause, it is >>> appropriate to use it for any columnar object of a read-create >>> table. >>> It is also permitted to use it for scalar objects dynamically >>> created >>> by an agent, or for columnar objects of a read-write table >>> dynamically created by an agent. >>> >>> - If you don't put DEFVAL for scalar objects, then insert in the >>> description a pointer on where to find the information >>> >>> Regards, Benoit. >>> >>> >>> >>> >>> -------- Original Message -------- >>> Subject: Re: Benoit Claise's Discuss on >>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>> From: Benoit Claise >>> To: Anil Rijhsinghani >>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>> , Erik Nordmark , Ralph Droms >>> , Bert Wijnen (IETF) , >>> zebrose@alum.mit.edu, Joan Cucchiara , me >>> >>> >>> >>> >>> Anil, Dan, >>> >>> I understand both arguments for and against DEFVAL for scalar. >>> >>> I've been in favor of DEFVAL for scalar, and considered it a >>> nice-to-have. >>> >>> 1. If you are the implementor, you must know the spec by heart, and >>> obviously, these scalar DEFVAL's are not useful to you. >>> 2. If you are the SNMP agent, it's true that the SNMPset contains >>> the value to be set, so you don't need the DEFVAL. >>> 3. If you are the network operator using the NMS GUI , it's pretty >>> useful information to have default values. It's pretty nice when a >>> NMS GUI contains the DEVAL value. Sure you can tell that, by looking >>> at the specifications, someone will be able to get this value. In >>> practice, is it done? So if the GUI developers could directly get >>> the information from the DEFVAL, that's a plus. >>> I've seen to many GUIs where the first config page allows to enter >>> almost anything. And the network operator just puts random values in >>> there. In the world of NetFlow, inserting non-sense timeout values >>> produced some funny results. >>> 4. If you are none of the above... Once upon a time, I was a NMS >>> customer support engineer, and I read many MIB modules. >>> And the DEFVAL always helped getting the default values. If nothing >>> else, for troubleshooting. >>> And no, I didn't know (and didn't want to know) all the protocol >>> specification details of the feature/protocol to be managed. >>> >>> You see, there are multiple actors dealing with MIB modules. >>> >>> How to more forward? >>>> By the way I have included a REFERENCE clause in most objects, >>> guiding an implementor to the section of the protocol RFC where he >>> can find more information about the object and its default, if >>> applicable. >>> That's good information already, and I could leave with that. It's >>> actually just a (*) level of indirection >>> >>> (*) time consuming if I take the case 4 above, i.e. my customer >>> support engineer. >>> >>> I want to publicly thanks Joan for the time spent on her review. >>> Much appreciated. >>> Now, I would like to have some consistency from the MIB doctors in >>> terms of guidelines on this topic. Let me discuss with them. >>> >>> >>> Regards, Benoit. >>> >>>> Dan, >>>> >>>> An SNMP set operation is used to change the value of a read-write >>>> object, or to create a new row in a table. There is a distinct >>>> difference between the applicability of DEFVAL in these two cases, >>>> hence the "appropriate" versus "permitted" language in the >>>> definition of the DEFVAL clause for these two cases. >>>> >>>> When a set operation is performed on a scalar object, it comes >>>> with a value to write into it. The SNMP agent need not guess what >>>> that value might be, nor does it need to rely on the MIB to tell >>>> it what to do. >>>> >>>> When a set operation is performed to create a new row in a table, >>>> it may specify the value of one or more columns in that row. If >>>> the SNMP agent is going to create a row, and not all column >>>> objects have been specified, it is left with a dilemma: what >>>> should it set as the values of those column objects? This is what >>>> the DEFVAL clause allows you to do: give the agent a default value >>>> for unspecified column objects. Such a dilemma does not occur for >>>> setting of scalar objects. >>>> >>>> If what you were saying is true, then every read-write object in >>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>> case. >>>> >>>> By the way I have included a REFERENCE clause in most objects, >>>> guiding an implementor to the section of the protocol RFC where he >>>> can find more information about the object and its default, if >>>> applicable. >>>> >>>> If this doesn't convince you, we will have to agree to disagree on >>>> this. >>>> >>>> Regards, >>>> Anil >>>> >>>> >>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>> >>>> Hi Anil, >>>> I need to disagree with you on this. The DEFVAL function is the >>>> same for a scalar and for a columnar object – as you well put it >>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>> I do not understand your argument that the implementor should look >>>> at the protocol specifications to in the case of scalar objects. >>>> We are talking about writeable objects. Whatever the agent >>>> initializes with will be sent to the instrumentation. In the >>>> absence of a DEFVAL value anything can be written there. The same >>>> as in the case of a columnar object the DEFVAL will indicate the >>>> value the agent initializes with which will be the first value to >>>> be sent to the instrumentation until a setRequest command changes >>>> it. Why should the agent implementor need to look in the protocol >>>> specifications and not help him defining DEFVAL clauses? >>>> Regards, >>>> Dan >>>> *From: *Anil R [mailto:anil@charter.net] >>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>> *To: *Romascanu, Dan (Dan) >>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; >>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>> *Subject: *Re: Benoit Claise's Discuss on >>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>> Dan, >>> >From the description: >>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>> Sure I know it is permitted for scalar objects, as that will not >>>> cause a compile error. >>>> For columnar objects, it is actually useful, because a manager may >>>> create an instance without specifying a columnar object. So it is >>>> syntactically and practically useful to do so in such cases, >>>> because the agent can deduce the missing value from the MIB >>>> syntax. It makes the protocol more efficient. I know this is why >>>> we added DEFVAL, based on my interaction at the time with the >>>> original SNMP authors (Jeff Case, et al). >>>> My point is that not only is specifying DEFVAL for a scalar >>>> useless from an SNMP syntactical point of view - because an agent >>>> cannot actually use it, other than an implementor reading the RFC >>>> text - but it is actually dangerous to do so. An implementor TRILL >>>> should be looking to the protocol specification (RFC6325 in this >>>> case) to determine how the protocol works and what the needed >>>> defaults are. >>>> We don't to define defaults in two different RFCs if we can help it. >>>> If the protocol decides to change a default, we shouldn't have to >>>> go update the MIB. >>>> Regards, >>>> Anil >>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>> >>>> >>>> >>>> Hi Anil, >>>> I believe that you are wrong stating that DEFVAL clauses should >>>> not be present in the definitions of scalar objects, or at least I >>>> could not find such a recommendations in the RFCs that define the >>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>> Note that with this definition of the DEFVAL clause, it is >>>> appropriate to use it for any columnar object of a read-create >>>> table. >>>> It is also permitted to use it for scalar objects dynamically >>>> created >>>> by an agent, or for columnar objects of a read-write table >>>> dynamically created by an agent. >>>> So when an agent is initialized it is good practice to define >>>> default values for writeable objects (scalar or columnar) unless >>>> we do not care what value the agent starts operating with. >>>> Regards, >>>> Dan >>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>> ] >>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>> *To: * Benoit Claise >>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen >>>> (IETF); _zebrose@alum.mit.edu_ >>>> ; >>>> Romascanu, Dan (Dan); Joan Cucchiara >>>> *Subject: * Re: Benoit Claise's Discuss on >>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>> Benoit, >>>> I will make a good faith attempt at responding to these comments >>>> yet again, although I have already responded to many of them >>>> (other than new ones that just showed up in the latest round). >>>> The DEFVAL comment is one which keeps coming back, disregarding my >>>> many responses that this is not a useful construct for scalar >>>> objects and its chief purpose is to give a default value to tables >>>> objects missing in the creation of a table instance, as described >>>> in its definition "The DEFVAL clause, which need not be present, >>>> defines an acceptable default value which may be used when an >>>> object instance is created." >>>> DEFVAL need not be present even in table objects, but definitely >>>> should not be present in scalar objects - but the latter is what >>>> several of these comments are insisting upon. It is the protocol >>>> specification that defines default values for protocol objects, >>>> not MIBs. >>>> Regards, >>>> Anil >>>> >>> >> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From jcucchiara@mindspring.com Thu Oct 11 08:08:13 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DFF21F8714 for ; Thu, 11 Oct 2012 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztbs23euJmYB for ; Thu, 11 Oct 2012 08:08:12 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAC3D21F86D4 for ; Thu, 11 Oct 2012 08:08:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aku7rhHQ+kZ1XPkIO8c1YRn5WnSVQnhceavQPtj6Rs9qWj4M36xEW6ojdP48hxaM; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TMKMq-0001Jd-6n; Thu, 11 Oct 2012 11:08:08 -0400 Message-ID: <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Sam Aldrin" References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> Date: Thu, 11 Oct 2012 11:06:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CDA7A0.67152F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26541bbfb1ff54e365391370ac38fcfc4ccb387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:08:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0084_01CDA7A0.67152F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sam, Yes, I have been working on this MIB review and sorry for taking so = long. Getting some interrupts ;) but should be able to finish up within a = week. Thanks for your email, -Joan ----- Original Message -----=20 From: Sam Aldrin=20 To: Joan Cucchiara=20 Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; = venkatesan mahalingam ; Kannan Sampath=20 Sent: Wednesday, October 10, 2012 8:02 PM Subject: Re: MPLS TP TE MIB - Edited for review comments Hi Joan and MIB doctors, I hope you have gotten a chance to review the MIB document. Kindly let me know if you have any further comments. Will be glad to address them. thanks in advance -sam On Sep 21, 2012, at 5:16 AM, Joan Cucchiara = wrote: Sam, Yes please include MIB Drs on these emails (I have forwarded your = email to them). I will take a look at the spreadsheet and MIB soon - hopefully next = week. Thanks for being so organized! -Joan ----- Original Message ----- From: Sam Aldrin To: Joan Cucchiara Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; = Kannan Sampath Sent: Sunday, September 16, 2012 2:16 AM Subject: MPLS TP TE MIB - Edited for review comments Hi Joan, How are you? thank you in advance for taking time to review the MIB = draft. Appreciate very much. Please find attachments of the following - New edited version of the draft - Excel sheet with all the comments listed and the status and = comments for each of those - Emails regarding TP names from AD and WG chair (sent as separate = email) - Changes from last version. Some more details: We have edited the MIB draft to address the comments. Some of the = comments are not closed till we agree to resolve them with a common = solution or point. They are listed as open in the XLS sheet. Otherwise = most of the comments are addressed. Please do not take this as the = document is complete with LC comments addressed. Only after all are = addressed, we will take it to next level. W.r.t TP within the MIB object names, I am not sure when we agreed = to change. If we have done it, we might have misspoke. Reason why we do = not want to change is as follows. When we initially started off the MIB, = it had TP within every object name. But AD (Adrian Farell) and WG chair = (Loa) have comeback and gave review comments to remove because MPLS TP = is not another technology rather it is MPLS. And also, the objects could = be used not only for TP but for bidirectional TE etc. Please find more = details in the attached emails(actually forwarding separately) from = them. I haven't copied the email to MIB Dr's. If you want us to, we could = do that. Appreciate if you could review and give us your comments, within the = XLS sheet or email. Either way is fine. Also do let us know if we have missed any comments to track. thanks in advance -sam p.s. I'll be out of country for the next 8 days and email access is = sparse. ------=_NextPart_000_0084_01CDA7A0.67152F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sam,
 
Yes, I have been working on this MIB = review and=20 sorry for taking so long.
Getting some interrupts ;)   = but should=20 be able to finish up within a week.
 
Thanks for your email,
  -Joan
 
----- Original Message -----
From:=20 Sam=20 Aldrin
Cc: MIB Doctors (E-mail) ; Thomas = Nadeau=20 ; Venkatesan Mahalingam = ; venkatesan=20 mahalingam ; Kannan Sampath
Sent: Wednesday, October 10, = 2012 8:02=20 PM
Subject: Re: MPLS TP TE MIB - = Edited for=20 review comments

Hi Joan and MIB doctors,

I hope you have gotten a chance to review the MIB document.
Kindly let me know if you have any further comments.
Will be glad to address them.

thanks in advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan Cucchiara <jcucchiara@mindspring.com&g= t;=20 wrote:

Sam,
 
Yes please include MIB Drs on these = emails (I=20 have forwarded your email to them).
 
I will take a look at the = spreadsheet and MIB=20 soon - hopefully next week.
 
Thanks for being so = organized!
  -Joan
 
 
 
----- Original Message -----
From: Sam Aldrin
To: Joan=20 Cucchiara
Cc: Thomas=20 Nadeau ; Venkatesan = Mahalingam ; venkatesan mahalingam ; Kannan Sampath
Sent: Sunday,=20 September 16, 2012 2:16 AM
Subject: MPLS TP=20 TE MIB - Edited for review comments

Hi Joan,

How are you? thank you in advance for = taking=20 time to review the MIB draft. Appreciate very much.
Please find=20 attachments of the following
  - New edited version of the=20 draft
  - Excel sheet with all the comments listed and the = status=20 and comments for each of those
  - Emails regarding TP names = from AD=20 and WG chair (sent as separate email)
  - Changes from last=20 version.

Some more details:

We have edited the MIB = draft to=20 address the comments. Some of the comments are not closed till we = agree to=20 resolve them with a common solution or point. They are listed as = open in the=20 XLS sheet. Otherwise most of the comments are addressed. Please do = not take=20 this as the document is complete with LC comments addressed. Only = after all=20 are addressed, we will take it to next level.

W.r.t TP within = the MIB=20 object names, I am not sure when we agreed to change. If we have = done it, we=20 might have misspoke. Reason why we do not want to change is as = follows. When=20 we initially started off the MIB, it had TP within every object = name. But AD=20 (Adrian Farell) and WG chair (Loa) have comeback and gave review = comments to=20 remove because MPLS TP is not another technology rather it is MPLS. = And=20 also, the objects could be used not only for TP but for = bidirectional TE=20 etc. Please find more details in the attached emails(actually = forwarding=20 separately) from them.

I haven't copied the email to MIB = Dr's. If you=20 want us to, we could do that.

Appreciate if you could review = and give=20 us your comments, within the XLS sheet or email. Either way is = fine.
Also=20 do let us know if we have missed any comments to = track.

thanks in=20 advance
-sam

p.s. I'll be out of country for the next 8 = days and=20 email access is sparse. <TP-TE-MIB-Comments.x= ls><draft-ietf-mpls-tp-te-mib-05.txt>&= lt;Diff=20  draft-ietf-mpls-tp-te-mib-04.txt -=20 = draft-ietf-mpls-tp-te-mib-05.txt.htm>
<= BR> ------=_NextPart_000_0084_01CDA7A0.67152F60-- From bertietf@bwijnen.net Thu Oct 11 08:18:05 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6174921F866D for ; Thu, 11 Oct 2012 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NgeZ4EOYPl0 for ; Thu, 11 Oct 2012 08:18:04 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B394E21F8625 for ; Thu, 11 Oct 2012 08:18:03 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TMKW8-00026I-JG; Thu, 11 Oct 2012 17:18:01 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TMKW8-0003GN-AU; Thu, 11 Oct 2012 17:17:44 +0200 Message-ID: <5076E317.8070403@bwijnen.net> Date: Thu, 11 Oct 2012 17:17:43 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Joan Cucchiara References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com><20121011111352.GA65010@elstar.local> <5076AF0E.1000209@bwijnen.net> <007101cda7c1$6ed964c0$6801a8c0@JoanPC> In-Reply-To: <007101cda7c1$6ed964c0$6801a8c0@JoanPC> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121011 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd475808d95e2b83d25b780127141d4ec32 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:18:05 -0000 That sounds very plausible Joan. So if it IS the case that it defined in the protocol spec then WHY the heck is Anil pushing back so much. After all, it is quite simple/easy to add a DEFVAL line. Bert On 10/11/12 5:02 PM, Joan Cucchiara wrote: > > For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have > DEFVALs specified in the protocol (RFC6325). Not > all protocol specifications do specify default values as clearly as this specification does. When default values are specified in > the protocol (RFC) as is mostly the > situation being discussed here with the scalars, I think DEFVALs SHOULD be put > into the MIB. I would like to say MUST, but believe Bert and Juergen have > pointed out that there is precedence to flexible on this. > > Please note, however, if these DEFVALs which have been specified by the RFC6325 were > in the MIB, they could be interpreted/compiled by tools which process MIBs > and this reduces error and assists in promoting interoperability. All in all, better for > the MIB's deployment and better for the WG to promote the protocol. > > Thanks, > -Joan > > ----- Original Message ----- From: "Bert Wijnen (IETF)" > To: "Benoit Claise" ; "MIB Doctors (E-mail)" > Sent: Thursday, October 11, 2012 7:35 AM > Subject: Re: [MIB-DOCTORS] DEVAL for scalar object > > >> Agree. >> I consider it a nice to have for scalars, but we have >> approved quite a few MIB modules that did not have it >> for (all) scalars. So we betterbe a bit flexible on >> this point. We can recommend that they do it where it >> makes sense. I would not hold up a MIB module for too >> long if they resist/reject (certainly if they have >> good arguments). >> >> Bert >> >> On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >>> Hi, >>> >>> I think the issue boils down to the question whether the scalars are >>> dynamically created by an agent or not. e.e., they come into existance >>> as a side effect of setting some other object. In such situations, >>> DEFVALs are useful to document which value a management system may >>> expect to be held in the newly established scalar (but note also that >>> the DEFVAL clause is not binding; the value is used "at the discretion >>> of an agent when an object instance is created" - a conservative >>> management application will thus check the value anyway if it is >>> important). >>> >>> /js >>> >>> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>>> MIB doctors, >>>> >>>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your >>>> numerous review of this MIB, which I fully support. >>>> >>>> Now, we received some push back from Anil, the author, on the >>>> required DEFVAL for scalar. >>>> As I wrote below, I always considered the DEFVAL for scalar to be >>>> useful information, but I understand both arguments. >>>> Read the email exchange below. >>>> >>>> Which advice do we want to give in the future on this topic? >>>> >>>> I'm in favor of telling: >>>> - DEFVAL for scalar objects are nice-to-have, and it's good practice >>>> to have them >>>> This is in line with >>>> >>>> RFC 2578, section 7.9 says: >>>> Note that with this definition of the DEFVAL clause, it is >>>> appropriate to use it for any columnar object of a read-create >>>> table. >>>> It is also permitted to use it for scalar objects dynamically >>>> created >>>> by an agent, or for columnar objects of a read-write table >>>> dynamically created by an agent. >>>> >>>> - If you don't put DEFVAL for scalar objects, then insert in the >>>> description a pointer on where to find the information >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Benoit Claise's Discuss on >>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>>> From: Benoit Claise >>>> To: Anil Rijhsinghani >>>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>>> , Erik Nordmark , Ralph Droms >>>> , Bert Wijnen (IETF) , >>>> zebrose@alum.mit.edu, Joan Cucchiara , me >>>> >>>> >>>> >>>> >>>> Anil, Dan, >>>> >>>> I understand both arguments for and against DEFVAL for scalar. >>>> >>>> I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. >>>> >>>> 1. If you are the implementor, you must know the spec by heart, and >>>> obviously, these scalar DEFVAL's are not useful to you. >>>> 2. If you are the SNMP agent, it's true that the SNMPset contains >>>> the value to be set, so you don't need the DEFVAL. >>>> 3. If you are the network operator using the NMS GUI , it's pretty >>>> useful information to have default values. It's pretty nice when a >>>> NMS GUI contains the DEVAL value. Sure you can tell that, by looking >>>> at the specifications, someone will be able to get this value. In >>>> practice, is it done? So if the GUI developers could directly get >>>> the information from the DEFVAL, that's a plus. >>>> I've seen to many GUIs where the first config page allows to enter >>>> almost anything. And the network operator just puts random values in >>>> there. In the world of NetFlow, inserting non-sense timeout values >>>> produced some funny results. >>>> 4. If you are none of the above... Once upon a time, I was a NMS >>>> customer support engineer, and I read many MIB modules. >>>> And the DEFVAL always helped getting the default values. If nothing >>>> else, for troubleshooting. >>>> And no, I didn't know (and didn't want to know) all the protocol >>>> specification details of the feature/protocol to be managed. >>>> >>>> You see, there are multiple actors dealing with MIB modules. >>>> >>>> How to more forward? >>>>> By the way I have included a REFERENCE clause in most objects, >>>> guiding an implementor to the section of the protocol RFC where he >>>> can find more information about the object and its default, if >>>> applicable. >>>> That's good information already, and I could leave with that. It's >>>> actually just a (*) level of indirection >>>> >>>> (*) time consuming if I take the case 4 above, i.e. my customer >>>> support engineer. >>>> >>>> I want to publicly thanks Joan for the time spent on her review. >>>> Much appreciated. >>>> Now, I would like to have some consistency from the MIB doctors in >>>> terms of guidelines on this topic. Let me discuss with them. >>>> >>>> >>>> Regards, Benoit. >>>> >>>>> Dan, >>>>> >>>>> An SNMP set operation is used to change the value of a read-write >>>>> object, or to create a new row in a table. There is a distinct >>>>> difference between the applicability of DEFVAL in these two cases, >>>>> hence the "appropriate" versus "permitted" language in the >>>>> definition of the DEFVAL clause for these two cases. >>>>> >>>>> When a set operation is performed on a scalar object, it comes >>>>> with a value to write into it. The SNMP agent need not guess what >>>>> that value might be, nor does it need to rely on the MIB to tell >>>>> it what to do. >>>>> >>>>> When a set operation is performed to create a new row in a table, >>>>> it may specify the value of one or more columns in that row. If >>>>> the SNMP agent is going to create a row, and not all column >>>>> objects have been specified, it is left with a dilemma: what >>>>> should it set as the values of those column objects? This is what >>>>> the DEFVAL clause allows you to do: give the agent a default value >>>>> for unspecified column objects. Such a dilemma does not occur for >>>>> setting of scalar objects. >>>>> >>>>> If what you were saying is true, then every read-write object in >>>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>>> case. >>>>> >>>>> By the way I have included a REFERENCE clause in most objects, >>>>> guiding an implementor to the section of the protocol RFC where he >>>>> can find more information about the object and its default, if >>>>> applicable. >>>>> >>>>> If this doesn't convince you, we will have to agree to disagree on this. >>>>> >>>>> Regards, >>>>> Anil >>>>> >>>>> >>>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>>> >>>>> Hi Anil, >>>>> I need to disagree with you on this. The DEFVAL function is the >>>>> same for a scalar and for a columnar object – as you well put it >>>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>>> I do not understand your argument that the implementor should look >>>>> at the protocol specifications to in the case of scalar objects. >>>>> We are talking about writeable objects. Whatever the agent >>>>> initializes with will be sent to the instrumentation. In the >>>>> absence of a DEFVAL value anything can be written there. The same >>>>> as in the case of a columnar object the DEFVAL will indicate the >>>>> value the agent initializes with which will be the first value to >>>>> be sent to the instrumentation until a setRequest command changes >>>>> it. Why should the agent implementor need to look in the protocol >>>>> specifications and not help him defining DEFVAL clauses? >>>>> Regards, >>>>> Dan >>>>> *From: *Anil R [mailto:anil@charter.net] >>>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>>> *To: *Romascanu, Dan (Dan) >>>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; >>>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>>> *Subject: *Re: Benoit Claise's Discuss on >>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>> Dan, >>>> >From the description: >>>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>>> Sure I know it is permitted for scalar objects, as that will not >>>>> cause a compile error. >>>>> For columnar objects, it is actually useful, because a manager may >>>>> create an instance without specifying a columnar object. So it is >>>>> syntactically and practically useful to do so in such cases, >>>>> because the agent can deduce the missing value from the MIB >>>>> syntax. It makes the protocol more efficient. I know this is why >>>>> we added DEFVAL, based on my interaction at the time with the >>>>> original SNMP authors (Jeff Case, et al). >>>>> My point is that not only is specifying DEFVAL for a scalar >>>>> useless from an SNMP syntactical point of view - because an agent >>>>> cannot actually use it, other than an implementor reading the RFC >>>>> text - but it is actually dangerous to do so. An implementor TRILL >>>>> should be looking to the protocol specification (RFC6325 in this >>>>> case) to determine how the protocol works and what the needed >>>>> defaults are. >>>>> We don't to define defaults in two different RFCs if we can help it. >>>>> If the protocol decides to change a default, we shouldn't have to >>>>> go update the MIB. >>>>> Regards, >>>>> Anil >>>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>>> >>>>> >>>>> >>>>> Hi Anil, >>>>> I believe that you are wrong stating that DEFVAL clauses should >>>>> not be present in the definitions of scalar objects, or at least I >>>>> could not find such a recommendations in the RFCs that define the >>>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>>> Note that with this definition of the DEFVAL clause, it is >>>>> appropriate to use it for any columnar object of a read-create table. >>>>> It is also permitted to use it for scalar objects dynamically created >>>>> by an agent, or for columnar objects of a read-write table >>>>> dynamically created by an agent. >>>>> So when an agent is initialized it is good practice to define >>>>> default values for writeable objects (scalar or columnar) unless >>>>> we do not care what value the agent starts operating with. >>>>> Regards, >>>>> Dan >>>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>>> ] >>>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>>> *To: * Benoit Claise >>>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen >>>>> (IETF); _zebrose@alum.mit.edu_ ; >>>>> Romascanu, Dan (Dan); Joan Cucchiara >>>>> *Subject: * Re: Benoit Claise's Discuss on >>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>> Benoit, >>>>> I will make a good faith attempt at responding to these comments >>>>> yet again, although I have already responded to many of them >>>>> (other than new ones that just showed up in the latest round). >>>>> The DEFVAL comment is one which keeps coming back, disregarding my >>>>> many responses that this is not a useful construct for scalar >>>>> objects and its chief purpose is to give a default value to tables >>>>> objects missing in the creation of a table instance, as described >>>>> in its definition "The DEFVAL clause, which need not be present, >>>>> defines an acceptable default value which may be used when an >>>>> object instance is created." >>>>> DEFVAL need not be present even in table objects, but definitely >>>>> should not be present in scalar objects - but the latter is what >>>>> several of these comments are insisting upon. It is the protocol >>>>> specification that defines default values for protocol objects, >>>>> not MIBs. >>>>> Regards, >>>>> Anil >>>>> >>>> >>> >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >>> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > From bclaise@cisco.com Thu Oct 11 08:27:20 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4221F875C for ; Thu, 11 Oct 2012 08:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.86 X-Spam-Level: X-Spam-Status: No, score=-8.86 tagged_above=-999 required=5 tests=[AWL=1.738, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2NyFd5NG+5n for ; Thu, 11 Oct 2012 08:27:18 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7A95D21F875A for ; Thu, 11 Oct 2012 08:27:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9BFR3JF020527; Thu, 11 Oct 2012 17:27:04 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9BFR2R8009719; Thu, 11 Oct 2012 17:27:02 +0200 (CEST) Message-ID: <5076E546.90505@cisco.com> Date: Thu, 11 Oct 2012 17:27:02 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com><20121011111352.GA65010@elstar.local> <5076AF0E.1000209@bwijnen.net> <007101cda7c1$6ed964c0$6801a8c0@JoanPC> <5076E317.8070403@bwijnen.net> In-Reply-To: <5076E317.8070403@bwijnen.net> Content-Type: multipart/alternative; boundary="------------020506070805020704060900" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:27:20 -0000 This is a multi-part message in MIME format. --------------020506070805020704060900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2012 17:17, Bert Wijnen (IETF) wrote: > That sounds very plausible Joan. > So if it IS the case that it defined in the protocol spec > then WHY the heck is Anil pushing back so much. > After all, it is quite simple/easy to add a DEFVAL line. The time spent arguing is a bigger than just editing the DEFVAL. On top of that, Anil wrote: > By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable. If the RFC is now obsolete, the REFERENCE points to an obsoleted reference... Regards, Benoit. > Bert > > > On 10/11/12 5:02 PM, Joan Cucchiara wrote: >> >> For THIS specific review most scalars (one exception is >> rbridgeBaseTrillVersion) have >> DEFVALs specified in the protocol (RFC6325). Not >> all protocol specifications do specify default values as clearly as >> this specification does. When default values are specified in >> the protocol (RFC) as is mostly the >> situation being discussed here with the scalars, I think DEFVALs >> SHOULD be put >> into the MIB. I would like to say MUST, but believe Bert and >> Juergen have >> pointed out that there is precedence to flexible on this. >> >> Please note, however, if these DEFVALs which have been specified by >> the RFC6325 were >> in the MIB, they could be interpreted/compiled by tools which process >> MIBs >> and this reduces error and assists in promoting interoperability. >> All in all, better for >> the MIB's deployment and better for the WG to promote the protocol. >> >> Thanks, >> -Joan >> >> ----- Original Message ----- From: "Bert Wijnen (IETF)" >> >> To: "Benoit Claise" ; "MIB Doctors (E-mail)" >> >> Sent: Thursday, October 11, 2012 7:35 AM >> Subject: Re: [MIB-DOCTORS] DEVAL for scalar object >> >> >>> Agree. >>> I consider it a nice to have for scalars, but we have >>> approved quite a few MIB modules that did not have it >>> for (all) scalars. So we betterbe a bit flexible on >>> this point. We can recommend that they do it where it >>> makes sense. I would not hold up a MIB module for too >>> long if they resist/reject (certainly if they have >>> good arguments). >>> >>> Bert >>> >>> On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >>>> Hi, >>>> >>>> I think the issue boils down to the question whether the scalars are >>>> dynamically created by an agent or not. e.e., they come into existance >>>> as a side effect of setting some other object. In such situations, >>>> DEFVALs are useful to document which value a management system may >>>> expect to be held in the newly established scalar (but note also that >>>> the DEFVAL clause is not binding; the value is used "at the discretion >>>> of an agent when an object instance is created" - a conservative >>>> management application will thus check the value anyway if it is >>>> important). >>>> >>>> /js >>>> >>>> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>>>> MIB doctors, >>>>> >>>>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your >>>>> numerous review of this MIB, which I fully support. >>>>> >>>>> Now, we received some push back from Anil, the author, on the >>>>> required DEFVAL for scalar. >>>>> As I wrote below, I always considered the DEFVAL for scalar to be >>>>> useful information, but I understand both arguments. >>>>> Read the email exchange below. >>>>> >>>>> Which advice do we want to give in the future on this topic? >>>>> >>>>> I'm in favor of telling: >>>>> - DEFVAL for scalar objects are nice-to-have, and it's good practice >>>>> to have them >>>>> This is in line with >>>>> >>>>> RFC 2578, section 7.9 says: >>>>> Note that with this definition of the DEFVAL clause, it is >>>>> appropriate to use it for any columnar object of a >>>>> read-create >>>>> table. >>>>> It is also permitted to use it for scalar objects dynamically >>>>> created >>>>> by an agent, or for columnar objects of a read-write table >>>>> dynamically created by an agent. >>>>> >>>>> - If you don't put DEFVAL for scalar objects, then insert in the >>>>> description a pointer on where to find the information >>>>> >>>>> Regards, Benoit. >>>>> >>>>> >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: Benoit Claise's Discuss on >>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>>>> From: Benoit Claise >>>>> To: Anil Rijhsinghani >>>>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>>>> , Erik Nordmark , Ralph Droms >>>>> , Bert Wijnen (IETF) , >>>>> zebrose@alum.mit.edu, Joan Cucchiara , me >>>>> >>>>> >>>>> >>>>> >>>>> Anil, Dan, >>>>> >>>>> I understand both arguments for and against DEFVAL for scalar. >>>>> >>>>> I've been in favor of DEFVAL for scalar, and considered it a >>>>> nice-to-have. >>>>> >>>>> 1. If you are the implementor, you must know the spec by heart, and >>>>> obviously, these scalar DEFVAL's are not useful to you. >>>>> 2. If you are the SNMP agent, it's true that the SNMPset contains >>>>> the value to be set, so you don't need the DEFVAL. >>>>> 3. If you are the network operator using the NMS GUI , it's pretty >>>>> useful information to have default values. It's pretty nice when a >>>>> NMS GUI contains the DEVAL value. Sure you can tell that, by looking >>>>> at the specifications, someone will be able to get this value. In >>>>> practice, is it done? So if the GUI developers could directly get >>>>> the information from the DEFVAL, that's a plus. >>>>> I've seen to many GUIs where the first config page allows to enter >>>>> almost anything. And the network operator just puts random values in >>>>> there. In the world of NetFlow, inserting non-sense timeout values >>>>> produced some funny results. >>>>> 4. If you are none of the above... Once upon a time, I was a NMS >>>>> customer support engineer, and I read many MIB modules. >>>>> And the DEFVAL always helped getting the default values. If nothing >>>>> else, for troubleshooting. >>>>> And no, I didn't know (and didn't want to know) all the protocol >>>>> specification details of the feature/protocol to be managed. >>>>> >>>>> You see, there are multiple actors dealing with MIB modules. >>>>> >>>>> How to more forward? >>>>>> By the way I have included a REFERENCE clause in most objects, >>>>> guiding an implementor to the section of the protocol RFC where he >>>>> can find more information about the object and its default, if >>>>> applicable. >>>>> That's good information already, and I could leave with that. It's >>>>> actually just a (*) level of indirection >>>>> >>>>> (*) time consuming if I take the case 4 above, i.e. my customer >>>>> support engineer. >>>>> >>>>> I want to publicly thanks Joan for the time spent on her review. >>>>> Much appreciated. >>>>> Now, I would like to have some consistency from the MIB doctors in >>>>> terms of guidelines on this topic. Let me discuss with them. >>>>> >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> Dan, >>>>>> >>>>>> An SNMP set operation is used to change the value of a read-write >>>>>> object, or to create a new row in a table. There is a distinct >>>>>> difference between the applicability of DEFVAL in these two cases, >>>>>> hence the "appropriate" versus "permitted" language in the >>>>>> definition of the DEFVAL clause for these two cases. >>>>>> >>>>>> When a set operation is performed on a scalar object, it comes >>>>>> with a value to write into it. The SNMP agent need not guess what >>>>>> that value might be, nor does it need to rely on the MIB to tell >>>>>> it what to do. >>>>>> >>>>>> When a set operation is performed to create a new row in a table, >>>>>> it may specify the value of one or more columns in that row. If >>>>>> the SNMP agent is going to create a row, and not all column >>>>>> objects have been specified, it is left with a dilemma: what >>>>>> should it set as the values of those column objects? This is what >>>>>> the DEFVAL clause allows you to do: give the agent a default value >>>>>> for unspecified column objects. Such a dilemma does not occur for >>>>>> setting of scalar objects. >>>>>> >>>>>> If what you were saying is true, then every read-write object in >>>>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>>>> case. >>>>>> >>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>> guiding an implementor to the section of the protocol RFC where he >>>>>> can find more information about the object and its default, if >>>>>> applicable. >>>>>> >>>>>> If this doesn't convince you, we will have to agree to disagree >>>>>> on this. >>>>>> >>>>>> Regards, >>>>>> Anil >>>>>> >>>>>> >>>>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>>>> >>>>>> Hi Anil, >>>>>> I need to disagree with you on this. The DEFVAL function is the >>>>>> same for a scalar and for a columnar object – as you well put it >>>>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>>>> I do not understand your argument that the implementor should look >>>>>> at the protocol specifications to in the case of scalar objects. >>>>>> We are talking about writeable objects. Whatever the agent >>>>>> initializes with will be sent to the instrumentation. In the >>>>>> absence of a DEFVAL value anything can be written there. The same >>>>>> as in the case of a columnar object the DEFVAL will indicate the >>>>>> value the agent initializes with which will be the first value to >>>>>> be sent to the instrumentation until a setRequest command changes >>>>>> it. Why should the agent implementor need to look in the protocol >>>>>> specifications and not help him defining DEFVAL clauses? >>>>>> Regards, >>>>>> Dan >>>>>> *From: *Anil R [mailto:anil@charter.net] >>>>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>>>> *To: *Romascanu, Dan (Dan) >>>>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; >>>>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>>>> *Subject: *Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Dan, >>>>> >From the description: >>>>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>>>> Sure I know it is permitted for scalar objects, as that will not >>>>>> cause a compile error. >>>>>> For columnar objects, it is actually useful, because a manager may >>>>>> create an instance without specifying a columnar object. So it is >>>>>> syntactically and practically useful to do so in such cases, >>>>>> because the agent can deduce the missing value from the MIB >>>>>> syntax. It makes the protocol more efficient. I know this is why >>>>>> we added DEFVAL, based on my interaction at the time with the >>>>>> original SNMP authors (Jeff Case, et al). >>>>>> My point is that not only is specifying DEFVAL for a scalar >>>>>> useless from an SNMP syntactical point of view - because an agent >>>>>> cannot actually use it, other than an implementor reading the RFC >>>>>> text - but it is actually dangerous to do so. An implementor TRILL >>>>>> should be looking to the protocol specification (RFC6325 in this >>>>>> case) to determine how the protocol works and what the needed >>>>>> defaults are. >>>>>> We don't to define defaults in two different RFCs if we can help it. >>>>>> If the protocol decides to change a default, we shouldn't have to >>>>>> go update the MIB. >>>>>> Regards, >>>>>> Anil >>>>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Anil, >>>>>> I believe that you are wrong stating that DEFVAL clauses should >>>>>> not be present in the definitions of scalar objects, or at least I >>>>>> could not find such a recommendations in the RFCs that define the >>>>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>>>> Note that with this definition of the DEFVAL clause, it is >>>>>> appropriate to use it for any columnar object of a read-create >>>>>> table. >>>>>> It is also permitted to use it for scalar objects dynamically >>>>>> created >>>>>> by an agent, or for columnar objects of a read-write table >>>>>> dynamically created by an agent. >>>>>> So when an agent is initialized it is good practice to define >>>>>> default values for writeable objects (scalar or columnar) unless >>>>>> we do not care what value the agent starts operating with. >>>>>> Regards, >>>>>> Dan >>>>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>>>> ] >>>>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>>>> *To: * Benoit Claise >>>>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen >>>>>> (IETF); _zebrose@alum.mit.edu_ >>>>>> ; >>>>>> Romascanu, Dan (Dan); Joan Cucchiara >>>>>> *Subject: * Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Benoit, >>>>>> I will make a good faith attempt at responding to these comments >>>>>> yet again, although I have already responded to many of them >>>>>> (other than new ones that just showed up in the latest round). >>>>>> The DEFVAL comment is one which keeps coming back, disregarding my >>>>>> many responses that this is not a useful construct for scalar >>>>>> objects and its chief purpose is to give a default value to tables >>>>>> objects missing in the creation of a table instance, as described >>>>>> in its definition "The DEFVAL clause, which need not be present, >>>>>> defines an acceptable default value which may be used when an >>>>>> object instance is created." >>>>>> DEFVAL need not be present even in table objects, but definitely >>>>>> should not be present in scalar objects - but the latter is what >>>>>> several of these comments are insisting upon. It is the protocol >>>>>> specification that defines default values for protocol objects, >>>>>> not MIBs. >>>>>> Regards, >>>>>> Anil >>>>>> >>>>> >>>> >>>>> _______________________________________________ >>>>> MIB-DOCTORS mailing list >>>>> MIB-DOCTORS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> >> > > --------------020506070805020704060900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 11/10/2012 17:17, Bert Wijnen (IETF) wrote:
That sounds very plausible Joan.
So if it IS the case that it defined in the protocol spec
then WHY the heck is Anil pushing back so much.
After all, it is quite simple/easy to add a DEFVAL line.
The time spent arguing is a bigger than just editing the DEFVAL.
On top of that, Anil wrote:
> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.

If the RFC is now obsolete, the REFERENCE points to an obsoleted reference...

Regards, Benoit.
Bert


On 10/11/12 5:02 PM, Joan Cucchiara wrote:

For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have
DEFVALs specified in the protocol (RFC6325).   Not
all protocol specifications do specify default values as clearly as this specification does. When default values are specified in
the protocol (RFC) as is mostly the
situation being discussed here with the scalars, I think DEFVALs SHOULD be put
into the MIB.   I would like to say MUST, but believe Bert and Juergen have
pointed out that there is precedence to flexible on this.

Please note, however, if these DEFVALs which have been specified by the RFC6325 were
in the MIB, they could be interpreted/compiled by tools which process MIBs
and this reduces error and assists in promoting interoperability.   All in all, better for
the MIB's deployment and better for the WG to promote the protocol.

Thanks,
  -Joan

----- Original Message ----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: "Benoit Claise" <bclaise@cisco.com>; "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object


Agree.
I consider it a nice to have for scalars, but we have
approved quite a few MIB modules that did not have it
for (all) scalars. So we betterbe a bit flexible on
this point. We can recommend that they do it where it
makes sense. I would not hold up a MIB module for too
long if they resist/reject (certainly if they have
good arguments).

Bert

On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote:
Hi,

I think the issue boils down to the question whether the scalars are
dynamically created by an agent or not. e.e., they come into existance
as a side effect of setting some other object. In such situations,
DEFVALs are useful to document which value a management system may
expect to be held in the newly established scalar (but note also that
the DEFVAL clause is not binding; the value is used "at the discretion
of an agent when an object instance is created" - a conservative
management application will thus check the value anyway if it is
important).

/js

On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote:
MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your
numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the
required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be
useful information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice
to have them
     This is in line with

    RFC 2578, section 7.9 says:
        Note that with this definition of the DEFVAL clause, it is
        appropriate to use it for any columnar object of a read-create
    table.
        It is also permitted to use it for scalar objects dynamically
    created
        by an agent, or for columnar objects of a read-write table
        dynamically created by an agent.

- If you don't put DEFVAL for scalar objects, then insert in the
description a pointer on where to find the information

Regards, Benoit.




-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake
<d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, Ralph Droms
<rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <bertietf@bwijnen.net>,
zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me
<bclaise@cisco.com>



Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.

1. If you are the implementor, you must know the spec by heart, and
obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains
the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty
useful information to have default values. It's pretty nice when a
NMS GUI contains the DEVAL value. Sure you can tell that, by looking
at the specifications, someone will be able to get this value. In
practice, is it done? So if the GUI developers could directly get
the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter
almost anything. And the network operator just puts random values in
there. In the world of NetFlow, inserting non-sense timeout values
produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS
customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing
else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol
specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.
That's good information already, and I could leave with that. It's
actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer
support engineer.

I want to publicly thanks Joan for the time spent on her review.
Much appreciated.
Now, I would like to have some consistency from the MIB doctors in
terms of guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,

An SNMP set operation is used to change the value of a read-write
object, or to create a new row in a table. There is a distinct
difference between the applicability of DEFVAL in these two cases,
hence the "appropriate" versus "permitted" language in the
definition of the DEFVAL clause for these two cases.

When a set operation is performed on a scalar object, it comes
with a value to write into it. The SNMP agent need not guess what
that value might be,  nor does it need to rely on the MIB to tell
it what to do.

When a set operation is performed to create a new row in a table,
it may specify the value of one or more columns in that row. If
the SNMP agent is going to create a row, and not all column
objects have been specified, it is left with a dilemma: what
should it set as the values of those column objects? This is what
the DEFVAL clause allows you to do: give the agent a default value
for unspecified column objects. Such a dilemma does not occur for
setting of scalar objects.

If what you were saying is true, then every read-write object in
every MIB would need a DEFVAL clause. Clearly that is not the
case.

By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.

If this doesn't convince you, we will have to agree to disagree on this.

Regards,
Anil


On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:

Hi Anil,
I need to disagree with you on this. The DEFVAL function is the
same for a scalar and for a columnar object – as you well put it
‘the agent can deduce the missing value from the MIB syntax’.
I do not understand your argument that the implementor should look
at the protocol specifications to in the case of scalar objects.
We are talking about writeable objects. Whatever the agent
initializes with will be sent to the instrumentation. In the
absence of a DEFVAL value anything can be written there. The same
as in the case of a columnar object the DEFVAL will indicate the
value the agent initializes with which will be the first value to
be sent to the instrumentation until a setRequest command changes
it. Why should the agent implementor need to look in the protocol
specifications and not help him defining DEFVAL clauses?
Regards,
Dan
*From: *Anil R [mailto:anil@charter.net]
*Sent: *Wednesday, October 10, 2012 3:33 PM
*To: *Romascanu, Dan (Dan)
*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms;
Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara
*Subject: *Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Dan,
>From the description:
- as a columnar object, it is "appropriate" to use DEFVAL
- as a scalar object, it is "permitted" to use DEFVAL.
Sure I know it is permitted for scalar objects, as that will not
cause a compile error.
For columnar objects, it is actually useful, because a manager may
create an instance without specifying a columnar object. So it is
syntactically and practically useful to do so in such cases,
because the agent can deduce the missing value from the MIB
syntax. It makes the protocol more efficient. I know this is why
we added DEFVAL, based on my interaction at the time with the
original SNMP authors (Jeff Case, et al).
My point is that not only is specifying DEFVAL for a scalar
useless from an SNMP syntactical point of view - because an agent
cannot actually use it, other than an implementor reading the RFC
text - but it is actually dangerous to do so. An implementor TRILL
should be looking to the protocol specification (RFC6325 in this
case) to determine how the protocol works and what the needed
defaults are.
We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to
go update the MIB.
Regards,
Anil
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:



Hi Anil,
I believe that you are wrong stating that DEFVAL clauses should
not be present in the definitions of scalar objects, or at least I
could not find such a recommendations in the RFCs that define the
SMI. On the contrary, RFC 2578, section 7.9 says:
   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.
So when an agent is initialized it is good practice to define
default values for writeable objects (scalar or columnar) unless
we do not care what value the agent starts operating with.
Regards,
Dan
*From: *  Anil R [ _mailto:anil@charter.net_
<javascript:parent.wgMail.openComposeWindow('anil@charter.net')>]
*Sent: * Wednesday, October 10, 2012 2:40 PM
*To: *  Benoit Claise
*Cc: *  Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen
(IETF); _zebrose@alum.mit.edu_ <javascript:parent.wgMail.openComposeWindow('zebrose@alum.mit.edu')>;
Romascanu, Dan (Dan); Joan Cucchiara
*Subject: * Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Benoit,
I will make a good faith attempt at responding to these comments
yet again, although I have already responded to many of them
(other than new ones that just showed up in the latest round).
The DEFVAL comment is one which keeps coming back, disregarding my
many responses that this is not a useful construct for scalar
objects and its chief purpose is to give a default value to tables
objects missing in the creation of a table instance, as described
in its definition "The DEFVAL clause, which need not be present,
defines an acceptable default value which may be used when an
object instance is created."
DEFVAL need not be present even in table objects, but definitely
should not be present in scalar objects - but the latter is what
several of these comments are insisting upon. It is the protocol
specification that defines default values for protocol objects,
not MIBs.
Regards,
Anil



_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors






--------------020506070805020704060900-- From david.black@emc.com Wed Oct 10 09:37:45 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C31F0381 for ; Wed, 10 Oct 2012 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou5dggoxWllf for ; Wed, 10 Oct 2012 09:37:45 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8D321F8607 for ; Wed, 10 Oct 2012 09:37:44 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9AGbaBJ023712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 12:37:42 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 10 Oct 2012 12:37:24 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9AGbG4f032366; Wed, 10 Oct 2012 12:37:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Wed, 10 Oct 2012 12:37:19 -0400 From: "Black, David" To: Benoit Claise , Martin Stiemerling , "MIB Doctors (E-mail)" , Michael MacFaden Date: Wed, 10 Oct 2012 12:37:18 -0400 Thread-Topic: Request for MIB review of draft-ietf-storm-iscsimib Thread-Index: Ac2nAbkLNFycLLG0QyibNjjzOIKsKQAA39pw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DFAE83C@MX15A.corp.emc.com> References: <50758E1C.6070706@neclab.eu> <50759DA6.9020900@cisco.com> In-Reply-To: <50759DA6.9020900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 11 Oct 2012 08:31:07 -0700 Cc: Ronald Bonica , "Black, David" , "storm-chairs@tools.ietf.org" Subject: Re: [MIB-DOCTORS] Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:37:46 -0000 I observe that the storm WG did look at all of the suggested functional enhancements and made some decisions about which ones to include vs. not include. Please keep in mind that the "m" in "storm" stands for "maintenance". Thanks, --David (storm WG co-chair) > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Wednesday, October 10, 2012 12:09 PM > To: Martin Stiemerling; MIB Doctors (E-mail); Michael MacFaden > Cc: Ronald Bonica; storm-chairs@tools.ietf.org > Subject: Re: Request for MIB review of draft-ietf-storm-iscsimib >=20 > Hi Mike, >=20 > As far as I know, you did the review of draft-ietf-storm-iscsimib > Can you please have a look to see if this latest version addresses your > points at http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt >=20 > Regards, Benoit > > Hi Ron and Benoit, > > > > The MIB doctors did a review of draft-ietf-storm-iscsimib a while back > > and did comment on the text, but also on the MIB module itself. > > (https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib) > > > > The STORM working group has gone through the review and updated the > > draft to address these. > > > > Can you please ask the MIB doctors to review the ISCSI MIB module again= ? > > > > Thanks in advance, > > > > Martin > > >=20 From sam.aldrin@gmail.com Thu Oct 11 08:46:31 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362D921F86C9 for ; Thu, 11 Oct 2012 08:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlbEOWyEMLBs for ; Thu, 11 Oct 2012 08:46:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2921F86B5 for ; Thu, 11 Oct 2012 08:46:30 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1991532pbb.31 for ; Thu, 11 Oct 2012 08:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=raOmw4tnK289/pPl4aCQeInXVvxKWT9Iv+oQ8TvoUy8=; b=JuwRHG0/dxH1D+jY1gtFILs/I17IFCYDoXYG6EsjdlM00lTwsSpT0YDft1lLZvUF+B dcbaFN9wpv3RXMm4toSRVbFtXaN3SVXktJE7z+IKx/j9IrdSCBtKMWCwlx3ig6+vaMay 9DPRtNfUwh0vgDPf8uv+Wkmli4L8+fWRYCE61B+2k/YOgNkAwqsObohsMmITWfGrCi9O DlIwtzBxham0TztDmYzXzJQcbl9ZUVMoVdc06aF8kDKlatlayLvBwJKhXSlCwyh5xpRP eKCCqUpjbF6Y5uNJPQIfKDaIdpJtNTF2K8r7XIsuwbdUBZMTeR/wTUjKe97et1YyNmh1 vFEQ== Received: by 10.68.130.198 with SMTP id og6mr4534898pbb.163.1349970389714; Thu, 11 Oct 2012 08:46:29 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id pv9sm2909247pbb.67.2012.10.11.08.46.26 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:46:27 -0700 (PDT) References: <025601cd97f2$fea5c910$6801a8c0@JoanPC> <7331253D-81C3-4FC4-80E4-5413058FB1A7@gmail.com> <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> Mime-Version: 1.0 (1.0) In-Reply-To: <008701cda7c1$ee69a4c0$6801a8c0@JoanPC> Content-Type: multipart/alternative; boundary=Apple-Mail-229C5845-C690-4899-A0E8-A8518A56B00C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Sam Aldrin Date: Thu, 11 Oct 2012 08:46:25 -0700 To: Joan Cucchiara Cc: Venkatesan Mahalingam , "MIB Doctors \(E-mail\)" , venkatesan mahalingam , Kannan Sampath Subject: Re: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:46:31 -0000 --Apple-Mail-229C5845-C690-4899-A0E8-A8518A56B00C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks, Joan. Appreciate your help. Cheers Sam Sent from my iPad On Oct 11, 2012, at 8:06 AM, "Joan Cucchiara" wr= ote: > Sam, > =20 > Yes, I have been working on this MIB review and sorry for taking so long. > Getting some interrupts ;) but should be able to finish up within a week= . > =20 > Thanks for your email, > -Joan > =20 > ----- Original Message ----- > From: Sam Aldrin > To: Joan Cucchiara > Cc: MIB Doctors (E-mail) ; Thomas Nadeau ; Venkatesan Mahalingam ; venkate= san mahalingam ; Kannan Sampath > Sent: Wednesday, October 10, 2012 8:02 PM > Subject: Re: MPLS TP TE MIB - Edited for review comments >=20 > Hi Joan and MIB doctors, >=20 > I hope you have gotten a chance to review the MIB document. > Kindly let me know if you have any further comments. > Will be glad to address them. >=20 > thanks in advance > -sam > On Sep 21, 2012, at 5:16 AM, Joan Cucchiara wr= ote: >=20 >> Sam, >> =20 >> Yes please include MIB Drs on these emails (I have forwarded your email t= o them). >> =20 >> I will take a look at the spreadsheet and MIB soon - hopefully next week.= >> =20 >> Thanks for being so organized! >> -Joan >> =20 >> =20 >> =20 >> ----- Original Message ----- >> From: Sam Aldrin >> To: Joan Cucchiara >> Cc: Thomas Nadeau ; Venkatesan Mahalingam ; venkatesan mahalingam ; Kanna= n Sampath >> Sent: Sunday, September 16, 2012 2:16 AM >> Subject: MPLS TP TE MIB - Edited for review comments >>=20 >> Hi Joan, >>=20 >> How are you? thank you in advance for taking time to review the MIB draft= . Appreciate very much. >> Please find attachments of the following >> - New edited version of the draft >> - Excel sheet with all the comments listed and the status and comments f= or each of those >> - Emails regarding TP names from AD and WG chair (sent as separate emai= l) >> - Changes from last version. >>=20 >> Some more details: >>=20 >> We have edited the MIB draft to address the comments. Some of the comment= s are not closed till we agree to resolve them with a common solution or poi= nt. They are listed as open in the XLS sheet. Otherwise most of the comments= are addressed. Please do not take this as the document is complete with LC c= omments addressed. Only after all are addressed, we will take it to next lev= el. >>=20 >> W.r.t TP within the MIB object names, I am not sure when we agreed to cha= nge. If we have done it, we might have misspoke. Reason why we do not want t= o change is as follows. When we initially started off the MIB, it had T= P within every object name. But AD (Adrian Farell) and WG chair (Loa) have c= omeback and gave review comments to remove because MPLS TP is not another te= chnology rather it is MPLS. And also, the objects could be used not only for= TP but for bidirectional TE etc. Please find more details in the attached e= mails(actually forwarding separately) from them. >>=20 >> I haven't copied the email to MIB Dr's. If you want us to, we could do th= at. >>=20 >> Appreciate if you could review and give us your comments, within the XLS s= heet or email. Either way is fine. >> Also do let us know if we have missed any comments to track. >>=20 >> thanks in advance >> -sam >>=20 >> p.s. I'll be out of country for the next 8 days and email access is spars= e. >=20 --Apple-Mail-229C5845-C690-4899-A0E8-A8518A56B00C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thanks, Joan.
Appreciate your help.

Cheers
Sam

Sent from my iPad

On Oct 11, 2012, at 8:06 AM, "Joan Cucchiara" <jcucchiara@mindspring.com> wrote:

Sam,
 
Yes, I have been working on this MIB review and sorry for taking so long.
Getting some interrupts ;)   but should be able to finish up within a week.
 
Thanks for your email,
  -Joan
 
----- Original Message -----
From: Sam Aldrin
Sent: Wednesday, October 10, 2012 8:02 PM
Subject: Re: MPLS TP TE MIB - Edited for review comments

Hi Joan and MIB doctors,

I hope you have gotten a chance to review the MIB document.
Kindly let me know if you have any further comments.
Will be glad to address them.

thanks in advance
-sam
On Sep 21, 2012, at 5:16 AM, Joan Cucchiara <jcucchiara@mindspring.com> wrote:

Sam,
 
Yes please include MIB Drs on these emails (I have forwarded your email to them).
 
I will take a look at the spreadsheet and MIB soon - hopefully next week.
 
Thanks for being so organized!
  -Joan
 
 
 
----- Original Message -----
From: Sam Aldrin
Sent: Sunday, September 16, 2012 2:16 AM
Subject: MPLS TP TE MIB - Edited for review comments

Hi Joan,

How are you? thank you in advance for taking time to review the MIB draft. Appreciate very much.
Please find attachments of the following
  - New edited version of the draft
  - Excel sheet with all the comments listed and the status and comments for each of those
  - Emails regarding TP names from AD and WG chair (sent as separate email)
  - Changes from last version.

Some more details:

We have edited the MIB draft to address the comments. Some of the comments are not closed till we agree to resolve them with a common solution or point. They are listed as open in the XLS sheet. Otherwise most of the comments are addressed. Please do not take this as the document is complete with LC comments addressed. Only after all are addressed, we will take it to next level.

W.r.t TP within the MIB object names, I am not sure when we agreed to change. If we have done it, we might have misspoke. Reason why we do not want to change is as follows. When we initially started off the MIB, it had TP within every object name. But AD (Adrian Farell) and WG chair (Loa) have comeback and gave review comments to remove because MPLS TP is not another technology rather it is MPLS. And also, the objects could be used not only for TP but for bidirectional TE etc. Please find more details in the attached emails(actually forwarding separately) from them.

I haven't copied the email to MIB Dr's. If you want us to, we could do that.

Appreciate if you could review and give us your comments, within the XLS sheet or email. Either way is fine.
Also do let us know if we have missed any comments to track.

thanks in advance
-sam

p.s. I'll be out of country for the next 8 days and email access is sparse. <TP-TE-MIB-Comments.xls><draft-ietf-mpls-tp-te-mib-05.txt><Diff  draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-mib-05.txt.htm>

--Apple-Mail-229C5845-C690-4899-A0E8-A8518A56B00C-- From randy_presuhn@mindspring.com Thu Oct 11 10:34:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66E21F865B for ; Thu, 11 Oct 2012 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4mZPBdBTHDD for ; Thu, 11 Oct 2012 10:34:43 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id E018521F85C2 for ; Thu, 11 Oct 2012 10:34:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nNZ4h7s7MWH5NGlnFqRxBkNGZ2WIdNboxYKlIPpPDuqu4Q2JSqUxS+JB+0xYNJne; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.146.198] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TMMeg-000169-3Y; Thu, 11 Oct 2012 13:34:42 -0400 Message-ID: <001401cda7d6$b6324480$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Benoit Claise" , "MIB Doctors \(E-mail\)" References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com><20121011111352.GA65010@elstar.local> <5076AF0E.1000209@bwijnen.net> Date: Thu, 11 Oct 2012 10:34:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f14937ba1e5f323cd6549db95f1b4cecc6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.146.198 Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:34:43 -0000 Hi - > From: "Bert Wijnen (IETF)" > To: "Benoit Claise" ; "MIB Doctors (E-mail)" > Sent: Thursday, October 11, 2012 4:35 AM > Subject: Re: [MIB-DOCTORS] DEVAL for scalar object > > Agree. > I consider it a nice to have for scalars, but we have > approved quite a few MIB modules that did not have it > for (all) scalars. So we betterbe a bit flexible on > this point. We can recommend that they do it where it > makes sense. I would not hold up a MIB module for too > long if they resist/reject (certainly if they have > good arguments). > > Bert > > On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: > > Hi, > > > > I think the issue boils down to the question whether the scalars are > > dynamically created by an agent or not. e.e., they come into existance > > as a side effect of setting some other object. In such situations, > > DEFVALs are useful to document which value a management system may > > expect to be held in the newly established scalar (but note also that > > the DEFVAL clause is not binding; the value is used "at the discretion > > of an agent when an object instance is created" - a conservative > > management application will thus check the value anyway if it is > > important). > > > > /js I largely agree, but I think the case for including DEFVALs (because they're merely advisory) is strongest in the cases where if the instrumentation implementor (who is not always as familiar with the stuff being managed as one might like!!!) guesses incorrectly what value to instantiate, the results might have adverse operational impact. If it really doesn't matter what value the implementor picks, then a DEFVAL has little point. (Though in that case, one might also ask why the information is being made visible to management.) If the choice of value *does* matter operationally, then a DEFVAL is a very good idea. If it's a grey case, better safe than sorry, IMO. Randy From tnadeau@juniper.net Thu Oct 11 13:27:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4759B11E80A4 for ; Thu, 11 Oct 2012 13:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUj93395oTtL for ; Thu, 11 Oct 2012 13:27:41 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAA221F858E for ; Thu, 11 Oct 2012 13:27:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUHcrvMczFB79Lz5S2SNkmAdGsjF2RoeU@postini.com; Thu, 11 Oct 2012 13:27:41 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Oct 2012 13:27:21 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Oct 2012 13:27:20 -0700 Received: from TX2EHSOBE010.bigfish.com (65.55.88.14) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Oct 2012 13:28:57 -0700 Received: from mail264-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 11 Oct 2012 20:27:19 +0000 Received: from mail264-tx2 (localhost [127.0.0.1]) by mail264-tx2-R.bigfish.com (Postfix) with ESMTP id 8DD933AE010F for ; Thu, 11 Oct 2012 20:27:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371Id6eahc85eh542M1453Izz1202h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail264-tx2 (localhost.localdomain [127.0.0.1]) by mail264-tx2 (MessageSwitch) id 1349987237535950_20937; Thu, 11 Oct 2012 20:27:17 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.245]) by mail264-tx2.bigfish.com (Postfix) with ESMTP id 7F7BA53E0048; Thu, 11 Oct 2012 20:27:17 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Oct 2012 20:27:15 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.188]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0207.009; Thu, 11 Oct 2012 20:27:14 +0000 From: Thomas Nadeau To: Benoit Claise , "MIB Doctors (E-mail)" Thread-Topic: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)) Thread-Index: AQHNp5KUP8/HLMtSVE2zY9/y81AYl5e0S2KA Date: Thu, 11 Oct 2012 20:27:13 +0000 Message-ID: In-Reply-To: <507690D1.4070800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CC9CA36F10FEBtnadeaujunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 20:27:43 -0000 --_000_CC9CA36F10FEBtnadeaujunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >From my perspective, using the DEFVALs are orthogonal to being "an expert w= ith the spec" when implementing things; its a matter of convenience and als= o "fat finger"-proof. On the NMS side it also gives a great hint for a def= ault value in a provisioning field. I am honestly perplexed as to why Anil = is pushing back on the DEFVAL myself. I am with Joan on this one. I'd go fu= rther and require it in the description too, so as to explain why its there= (or a reference to the spec). --Tom From: Benoit Claise > Date: Thursday, October 11, 2012 5:26 AM To: "MIB Doctors (E-mail)" > Subject: [MIB-DOCTORS] DEVAL for scalar object (was: Re: Benoit Claise's Di= scuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)) MIB doctors, Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerou= s review of this MIB, which I fully support. Now, we received some push back from Anil, the author, on the required DEFV= AL for scalar. As I wrote below, I always considered the DEFVAL for scalar to be useful in= formation, but I understand both arguments. Read the email exchange below. Which advice do we want to give in the future on this topic? I'm in favor of telling: - DEFVAL for scalar objects are nice-to-have, and it's good practice to hav= e them This is in line with RFC 2578, section 7.9 says: Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. - If you don't put DEFVAL for scalar objects, then insert in the descriptio= n a pointer on where to find the information Regards, Benoit. -------- Original Message -------- Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib= -09: (with DISCUSS and COMMENT) Date: Thu, 11 Oct 2012 11:11:30 +0200 From: Benoit Claise To: Anil Rijhsinghani CC: Romascanu, Dan (Dan) , Donald Eastlake , Erik Nordma= rk , Ralph Droms , Bert Wijnen (IETF) , zebrose@alum.mit.edu, Joan Cucchiara , me Anil, Dan, I understand both arguments for and against DEFVAL for scalar. I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. 1. If you are the implementor, you must know the spec by heart, and obvious= ly, these scalar DEFVAL's are not useful to you. 2. If you are the SNMP agent, it's true that the SNMPset contains the value= to be set, so you don't need the DEFVAL. 3. If you are the network operator using the NMS GUI , it's pretty useful i= nformation to have default values. It's pretty nice when a NMS GUI contains= the DEVAL value. Sure you can tell that, by looking at the specifications,= someone will be able to get this value. In practice, is it done? So if the= GUI developers could directly get the information from the DEFVAL, that's = a plus. I've seen to many GUIs where the first config page allows to enter almost a= nything. And the network operator just puts random values in there. In the = world of NetFlow, inserting non-sense timeout values produced some funny re= sults. 4. If you are none of the above... Once upon a time, I was a NMS customer s= upport engineer, and I read many MIB modules. And the DEFVAL always helped getting the default values. If nothing else, f= or troubleshooting. And no, I didn't know (and didn't want to know) all the protocol specificat= ion details of the feature/protocol to be managed. You see, there are multiple actors dealing with MIB modules. How to more forward? > By the way I have included a REFERENCE clause in most objects, guiding an= implementor to the section of the protocol RFC where he can find more info= rmation about the object and its default, if applicable. That's good information already, and I could leave with that. It's actually= just a (*) level of indirection (*) time consuming if I take the case 4 above, i.e. my customer support eng= ineer. I want to publicly thanks Joan for the time spent on her review. Much appre= ciated. Now, I would like to have some consistency from the MIB doctors in terms of= guidelines on this topic. Let me discuss with them. Regards, Benoit. Dan, An SNMP set operation is used to change the value of a read-write object, o= r to create a new row in a table. There is a distinct difference between th= e applicability of DEFVAL in these two cases, hence the "appropriate" versu= s "permitted" language in the definition of the DEFVAL clause for these two= cases. When a set operation is performed on a scalar object, it comes with a value= to write into it. The SNMP agent need not guess what that value might be, = nor does it need to rely on the MIB to tell it what to do. When a set operation is performed to create a new row in a table, it may sp= ecify the value of one or more columns in that row. If the SNMP agent is go= ing to create a row, and not all column objects have been specified, it is = left with a dilemma: what should it set as the values of those column objec= ts? This is what the DEFVAL clause allows you to do: give the agent a defau= lt value for unspecified column objects. Such a dilemma does not occur for = setting of scalar objects. If what you were saying is true, then every read-write object in every MIB = would need a DEFVAL clause. Clearly that is not the case. By the way I have included a REFERENCE clause in most objects, guiding an i= mplementor to the section of the protocol RFC where he can find more inform= ation about the object and its default, if applicable. If this doesn't convince you, we will have to agree to disagree on this. Regards, Anil On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: Hi Anil, I need to disagree with you on this. The DEFVAL function is the same for a = scalar and for a columnar object =96 as you well put it =91the agent can d= educe the missing value from the MIB syntax=92. I do not understand your argument that the implementor should look at the p= rotocol specifications to in the case of scalar objects. We are talking abo= ut writeable objects. Whatever the agent initializes with will be sent to t= he instrumentation. In the absence of a DEFVAL value anything can be writte= n there. The same as in the case of a columnar object the DEFVAL will indic= ate the value the agent initializes with which will be the first value to b= e sent to the instrumentation until a setRequest command changes it. Why sh= ould the agent implementor need to look in the protocol specifications and = not help him defining DEFVAL clauses? Regards, Dan From: Anil R [mailto:anil@charter.net] Sent: Wednesday, October 10, 2012 3:33 PM To: Romascanu, Dan (Dan) Cc: Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen= (IETF); zebrose@alum.mit.edu; Joan Cucchiara Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (w= ith DISCUSS and COMMENT) Dan, >From the description: - as a columnar object, it is "appropriate" to use DEFVAL - as a scalar object, it is "permitted" to use DEFVAL. Sure I know it is permitted for scalar objects, as that will not cause a co= mpile error. For columnar objects, it is actually useful, because a manager may create a= n instance without specifying a columnar object. So it is syntactically and= practically useful to do so in such cases, because the agent can deduce th= e missing value from the MIB syntax. It makes the protocol more efficient. = I know this is why we added DEFVAL, based on my interaction at the time wit= h the original SNMP authors (Jeff Case, et al). My point is that not only is specifying DEFVAL for a scalar useless from an= SNMP syntactical point of view - because an agent cannot actually use it, = other than an implementor reading the RFC text - but it is actually dangero= us to do so. An implementor TRILL should be looking to the protocol specifi= cation (RFC6325 in this case) to determine how the protocol works and what = the needed defaults are. We don't to define defaults in two different RFCs if we can help it. If the protocol decides to change a default, we shouldn't have to go update= the MIB. Regards, Anil On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: Hi Anil, I believe that you are wrong stating that DEFVAL clauses should not be pres= ent in the definitions of scalar objects, or at least I could not find such= a recommendations in the RFCs that define the SMI. On the contrary, RFC 25= 78, section 7.9 says: Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. So when an agent is initialized it is good practice to define default value= s for writeable objects (scalar or columnar) unless we do not care what val= ue the agent starts operating with. Regards, Dan From: Anil R [ mailto:anil@charter.net] Sent: Wednesday, October 10, 2012 2:40 PM To: Benoit Claise Cc: Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF); ze= brose@alum.mit.edu; Romascanu, Dan (Dan); Joan Cucchiara Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: = (with DISCUSS and COMMENT) Benoit, I will make a good faith attempt at responding to these comments yet again,= although I have already responded to many of them (other than new ones tha= t just showed up in the latest round). The DEFVAL comment is one which keeps coming back, disregarding my many res= ponses that this is not a useful construct for scalar objects and its chief= purpose is to give a default value to tables objects missing in the creati= on of a table instance, as described in its definition "The DEFVAL clause, = which need not be present, defines an acceptable default value which may be= used when an object instance is created." DEFVAL need not be present even in table objects, but definitely should not= be present in scalar objects - but the latter is what several of these com= ments are insisting upon. It is the protocol specification that defines def= ault values for protocol objects, not MIBs. Regards, Anil --_000_CC9CA36F10FEBtnadeaujunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <350B002F3400644DBE88D1CAF6A56321@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

From m= y perspective, using the DEFVALs are orthogonal to being "an expert wi= th the spec" when implementing things; its a matter of convenience and= also "fat finger"-proof.  On the NMS side it also gives a great hint for a default value in a provisioning field. I am = honestly perplexed as to why Anil is pushing back on the DEFVAL myself. I a= m with Joan on this one. I'd go further and require it in the description t= oo, so as to explain why its there (or a reference to the spec).

--Tom<= /div>


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, October 11, 2012 5:= 26 AM
To: "MIB Doctors (E-mail)"= ; <mib-doctors@ietf.org><= br> Subject: [MIB-DOCTORS] DEVAL for sc= alar object (was: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-m= ib-09: (with DISCUSS and COMMENT))

MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerou= s review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the required DEFV= AL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be useful in= formation, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice to hav= e them
    This is in line with
RFC 2578, section 7.9 says:
 
   Note that with this definition = of the DEFVAL clause, it is
   appropriate to use it for any c= olumnar object of a read-create table.
   It is also permitted to use it = for scalar objects dynamically created
   by an agent, or for columnar ob= jects of a read-write table
   dynamically created by an agent= .
- If you don't put DEFVAL for scalar objects, then insert in the descriptio= n a pointer on where to find the information

Regards, Benoit.

 


-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with D= ISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake <d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, Ralph Droms <rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <bertietf@bwijnen.net>, zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me <bclaise@cisco.com>


Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.<= br>
1. If you are the implementor, you must know the spec by heart, and obvious= ly, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains the value= to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty useful i= nformation to have default values. It's pretty nice when a NMS GUI contains= the DEVAL value. Sure you can tell that, by looking at the specifications,= someone will be able to get this value. In practice, is it done? So if the GUI developers could directly ge= t the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter almost a= nything. And the network operator just puts random values in there. In the = world of NetFlow, inserting non-sense timeout values produced some funny re= sults.
4. If you are none of the above... Once upon a time, I was a NMS customer s= upport engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing else, f= or troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol specificat= ion details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
> By the way I have included a REFERENCE clause in most objec= ts, guiding an implementor to the section of the protocol RFC where he can = find more information about the object and its default, if applicable.
That's good information already, and I could leave with that. It's actually= just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer support eng= ineer.

I want to publicly thanks Joan for the time spent on her review. Much appre= ciated.
Now, I would like to have some consistency from the MIB doctors in terms of= guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,
An SNMP set operation is used to change the = value of a read-write object, or to create a new row in a table. There is a= distinct difference between the applicability of DEFVAL in these two cases, hence the "appropriate" versus &qu= ot;permitted" language in the definition of the DEFVAL clause for thes= e two cases.
When a set operation is performed on a scala= r object, it comes with a value to write into it. The SNMP agent need not g= uess what that value might be,  nor does it need to rely on the MIB to tell it what to do.
When a set operation is performed to create = a new row in a table, it may specify the value of one or more columns in th= at row. If the SNMP agent is going to create a row, and not all column objects have been specified, it is left with a d= ilemma: what should it set as the values of those column objects? This is w= hat the DEFVAL clause allows you to do: give the agent a default value for = unspecified column objects. Such a dilemma does not occur for setting of scalar objects.
If what you were saying is true, then every = read-write object in every MIB would need a DEFVAL clause. Clearly that is = not the case.
By the way I have included a REFERENCE claus= e in most objects, guiding an implementor to the section of the protocol RF= C where he can find more information about the object and its default, if applicable.
If this doesn't convince you, we will have t= o agree to disagree on this.
Regards,
Anil
On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, = Dan (Dan) wrote:
 Hi Anil,
 
I need to disagree with you on this. The DEF= VAL function is the same for a scalar and for a columnar object =96 as you = well put it  =91the agent can deduce the missing value from the MIB syntax=92.
 
I do not understand your argument that the i= mplementor should look at the protocol specifications to in the case of sca= lar objects. We are talking about writeable objects. Whatever the agent initializes with will be sent to the instrumen= tation. In the absence of a DEFVAL value anything can be written there. The= same as in the case of a columnar object the DEFVAL will indicate the valu= e the agent initializes with which will be the first value to be sent to the instrumentation until a setReque= st command changes it. Why should the agent implementor need to look in the= protocol specifications and not help him defining DEFVAL clauses?
 
Regards,
 
Dan
 
 
 
From: Anil R [mailto:anil@charter.net]
Sent: Wednesday, October 10, 2012 3:33 PM
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen= (IETF); zebrose@alum.mit.edu; Joan Cucchiara
Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with D= ISCUSS and COMMENT)
 
Dan,
 
From the description:
- as a columnar object, it is "appropri= ate" to use DEFVAL
- as a scalar object, it is "permitted&= quot; to use DEFVAL.
 
Sure I know it is permitted for scalar objec= ts, as that will not cause a compile error.
 
For columnar objects, it is actually useful,= because a manager may create an instance without specifying a columnar obj= ect. So it is syntactically and practically useful to do so in such cases, because the agent can deduce the missing va= lue from the MIB syntax. It makes the protocol more efficient. I know this = is why we added DEFVAL, based on my interaction at the time with the origin= al SNMP authors (Jeff Case, et al).
 
My point is that not only is specifying DEFV= AL for a scalar useless from an SNMP syntactical point of view - because an= agent cannot actually use it, other than an implementor reading the RFC text - but it is actually dangerous to do so. = An implementor TRILL should be looking to the protocol specification (RFC63= 25 in this case) to determine how the protocol works and what the needed de= faults are.
 
We don't to define defaults in two different= RFCs if we can help it.
If the protocol decides to change a default,= we shouldn't have to go update the MIB.
 
Regards,
Anil
 
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan = (Dan) wrote:



Hi Anil,
 
I believe that you are wrong stating that DE= FVAL clauses should not be present in the definitions of scalar objects, or= at least I could not find such a recommendations in the RFCs that define the SMI. On the contrary, RFC 2578, section 7.9 sa= ys:
 
   Note that with this definition = of the DEFVAL clause, it is
   appropriate to use it for any c= olumnar object of a read-create table.
   It is also permitted to use it = for scalar objects dynamically created
   by an agent, or for columnar ob= jects of a read-write table
   dynamically created by an agent= .
 
So when an agent is initialized it is good p= ractice to define default values for writeable objects (scalar or columnar)= unless we do not care what value the agent starts operating with.
 
 
Regards,
 
Dan
 
 
 
 
From:   Anil R [ mailto:anil@charter.net] &nbs= p;
Sent:   Wednesday, October 10, 2012 2:40 PM
To:   Benoit Claise
Cc:   Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF);=    zebrose@alum.mit.edu; Romascanu, Dan (Dan); Joan Cucchiara
Subject:   Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: = (with DISCUSS and COMMENT)
 
Benoit,
 
I will make a good faith attempt at respondi= ng to these comments yet again, although I have already responded to many o= f them (other than new ones that just showed up in the latest round).
 
The DEFVAL comment is one which keeps coming= back, disregarding my many responses that this is not a useful construct f= or scalar objects and its chief purpose is to give a default value to tables objects missing in the creation of a table = instance, as described in its definition "The DEFVAL clause, which nee= d not be present, defines an acceptable default value which may be used whe= n an object instance is created."
 
DEFVAL need not be present even in table obj= ects, but definitely should not be present in scalar objects - but the latt= er is what several of these comments are insisting upon. It is the protocol specification that defines default values for pro= tocol objects, not MIBs.
 
Regards,
Anil
 

--_000_CC9CA36F10FEBtnadeaujunipernet_-- From tnadeau@juniper.net Thu Oct 11 13:36:33 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA721F8687 for ; Thu, 11 Oct 2012 13:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ42WAfhPIbH for ; Thu, 11 Oct 2012 13:36:31 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id E722321F8628 for ; Thu, 11 Oct 2012 13:36:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUHctzv1ZC9nrDId/vzpInP1KsUAqJHaF@postini.com; Thu, 11 Oct 2012 13:36:31 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Oct 2012 13:32:11 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Oct 2012 13:32:10 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.205) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Oct 2012 13:38:33 -0700 Received: from mail104-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 11 Oct 2012 20:32:08 +0000 Received: from mail104-am1 (localhost [127.0.0.1]) by mail104-am1-R.bigfish.com (Postfix) with ESMTP id A9AC0340106 for ; Thu, 11 Oct 2012 20:32:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic85eh542M1453I4015Izz1202h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1349987526395358_11347; Thu, 11 Oct 2012 20:32:06 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.227]) by mail104-am1.bigfish.com (Postfix) with ESMTP id 54D714E0063; Thu, 11 Oct 2012 20:32:06 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Oct 2012 20:32:02 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.188]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0207.009; Thu, 11 Oct 2012 20:32:00 +0000 From: Thomas Nadeau To: Benoit Claise , "Bert Wijnen (IETF)" Thread-Topic: [MIB-DOCTORS] DEVAL for scalar object Thread-Index: AQHNp8FuQSyWhxSHkkGoN2TlqWXTnZe0N5uAgAACmwCAABIiAA== Date: Thu, 11 Oct 2012 20:32:00 +0000 Message-ID: In-Reply-To: <5076E546.90505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CC9CA4E011007tnadeaujunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%BWIJNEN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 20:36:33 -0000 --_000_CC9CA4E011007tnadeaujunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Benoit Claise > Date: Thursday, October 11, 2012 11:27 AM To: "Bert Wijnen (IETF)" = > Cc: "MIB Doctors (E-mail)" > Subject: Re: [MIB-DOCTORS] DEVAL for scalar object On 11/10/2012 17:17, Bert Wijnen (IETF) wrote: That sounds very plausible Joan. So if it IS the case that it defined in the protocol spec then WHY the heck is Anil pushing back so much. After all, it is quite simple/easy to add a DEFVAL line. The time spent arguing is a bigger than just editing the DEFVAL. On top of that, Anil wrote: > By the way I have included a REFERENCE clause in most objects, guiding an= implementor to the section of the protocol RFC where he can find more info= rmation about the object and its default, if applicable. If the RFC is now obsolete, the REFERENCE points to an obsoleted reference.= .. If the RFC in question is obsolete, then what protocol(s) is/are the MIB ma= naging?! --Tom Regards, Benoit. Bert On 10/11/12 5:02 PM, Joan Cucchiara wrote: For THIS specific review most scalars (one exception is rbridgeBaseTrillVer= sion) have DEFVALs specified in the protocol (RFC6325). Not all protocol specifications do specify default values as clearly as this sp= ecification does. When default values are specified in the protocol (RFC) as is mostly the situation being discussed here with the scalars, I think DEFVALs SHOULD be = put into the MIB. I would like to say MUST, but believe Bert and Juergen have pointed out that there is precedence to flexible on this. Please note, however, if these DEFVALs which have been specified by the RFC= 6325 were in the MIB, they could be interpreted/compiled by tools which process MIBs and this reduces error and assists in promoting interoperability. All in = all, better for the MIB's deployment and better for the WG to promote the protocol. Thanks, -Joan ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Benoit Claise" ; "MIB Doc= tors (E-mail)" Sent: Thursday, October 11, 2012 7:35 AM Subject: Re: [MIB-DOCTORS] DEVAL for scalar object Agree. I consider it a nice to have for scalars, but we have approved quite a few MIB modules that did not have it for (all) scalars. So we betterbe a bit flexible on this point. We can recommend that they do it where it makes sense. I would not hold up a MIB module for too long if they resist/reject (certainly if they have good arguments). Bert On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: Hi, I think the issue boils down to the question whether the scalars are dynamically created by an agent or not. e.e., they come into existance as a side effect of setting some other object. In such situations, DEFVALs are useful to document which value a management system may expect to be held in the newly established scalar (but note also that the DEFVAL clause is not binding; the value is used "at the discretion of an agent when an object instance is created" - a conservative management application will thus check the value anyway if it is important). /js On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: MIB doctors, Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your numerous review of this MIB, which I fully support. Now, we received some push back from Anil, the author, on the required DEFVAL for scalar. As I wrote below, I always considered the DEFVAL for scalar to be useful information, but I understand both arguments. Read the email exchange below. Which advice do we want to give in the future on this topic? I'm in favor of telling: - DEFVAL for scalar objects are nice-to-have, and it's good practice to have them This is in line with RFC 2578, section 7.9 says: Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. - If you don't put DEFVAL for scalar objects, then insert in the description a pointer on where to find the information Regards, Benoit. -------- Original Message -------- Subject: Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) Date: Thu, 11 Oct 2012 11:11:30 +0200 From: Benoit Claise To: Anil Rijhsinghani CC: Romascanu, Dan (Dan) , D= onald Eastlake , Erik Nordmark , Ralph Droms , Bert Wijnen (IETF) <= bertietf@bwijnen.net>, zebrose@alum.mit.edu, Joan Cucchiara , me Anil, Dan, I understand both arguments for and against DEFVAL for scalar. I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. 1. If you are the implementor, you must know the spec by heart, and obviously, these scalar DEFVAL's are not useful to you. 2. If you are the SNMP agent, it's true that the SNMPset contains the value to be set, so you don't need the DEFVAL. 3. If you are the network operator using the NMS GUI , it's pretty useful information to have default values. It's pretty nice when a NMS GUI contains the DEVAL value. Sure you can tell that, by looking at the specifications, someone will be able to get this value. In practice, is it done? So if the GUI developers could directly get the information from the DEFVAL, that's a plus. I've seen to many GUIs where the first config page allows to enter almost anything. And the network operator just puts random values in there. In the world of NetFlow, inserting non-sense timeout values produced some funny results. 4. If you are none of the above... Once upon a time, I was a NMS customer support engineer, and I read many MIB modules. And the DEFVAL always helped getting the default values. If nothing else, for troubleshooting. And no, I didn't know (and didn't want to know) all the protocol specification details of the feature/protocol to be managed. You see, there are multiple actors dealing with MIB modules. How to more forward? By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable. That's good information already, and I could leave with that. It's actually just a (*) level of indirection (*) time consuming if I take the case 4 above, i.e. my customer support engineer. I want to publicly thanks Joan for the time spent on her review. Much appreciated. Now, I would like to have some consistency from the MIB doctors in terms of guidelines on this topic. Let me discuss with them. Regards, Benoit. Dan, An SNMP set operation is used to change the value of a read-write object, or to create a new row in a table. There is a distinct difference between the applicability of DEFVAL in these two cases, hence the "appropriate" versus "permitted" language in the definition of the DEFVAL clause for these two cases. When a set operation is performed on a scalar object, it comes with a value to write into it. The SNMP agent need not guess what that value might be, nor does it need to rely on the MIB to tell it what to do. When a set operation is performed to create a new row in a table, it may specify the value of one or more columns in that row. If the SNMP agent is going to create a row, and not all column objects have been specified, it is left with a dilemma: what should it set as the values of those column objects? This is what the DEFVAL clause allows you to do: give the agent a default value for unspecified column objects. Such a dilemma does not occur for setting of scalar objects. If what you were saying is true, then every read-write object in every MIB would need a DEFVAL clause. Clearly that is not the case. By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable. If this doesn't convince you, we will have to agree to disagree on this. Regards, Anil On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: Hi Anil, I need to disagree with you on this. The DEFVAL function is the same for a scalar and for a columnar object =96 as you well put it =91the agent can deduce the missing value from the MIB syntax=92. I do not understand your argument that the implementor should look at the protocol specifications to in the case of scalar objects. We are talking about writeable objects. Whatever the agent initializes with will be sent to the instrumentation. In the absence of a DEFVAL value anything can be written there. The same as in the case of a columnar object the DEFVAL will indicate the value the agent initializes with which will be the first value to be sent to the instrumentation until a setRequest command changes it. Why should the agent implementor need to look in the protocol specifications and not help him defining DEFVAL clauses? Regards, Dan *From: *Anil R [mailto:anil@charter.net] *Sent: *Wednesday, October 10, 2012 3:33 PM *To: *Romascanu, Dan (Dan) *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan= Cucchiara *Subject: *Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) Dan, >From the description: - as a columnar object, it is "appropriate" to use DEFVAL - as a scalar object, it is "permitted" to use DEFVAL. Sure I know it is permitted for scalar objects, as that will not cause a compile error. For columnar objects, it is actually useful, because a manager may create an instance without specifying a columnar object. So it is syntactically and practically useful to do so in such cases, because the agent can deduce the missing value from the MIB syntax. It makes the protocol more efficient. I know this is why we added DEFVAL, based on my interaction at the time with the original SNMP authors (Jeff Case, et al). My point is that not only is specifying DEFVAL for a scalar useless from an SNMP syntactical point of view - because an agent cannot actually use it, other than an implementor reading the RFC text - but it is actually dangerous to do so. An implementor TRILL should be looking to the protocol specification (RFC6325 in this case) to determine how the protocol works and what the needed defaults are. We don't to define defaults in two different RFCs if we can help it. If the protocol decides to change a default, we shouldn't have to go update the MIB. Regards, Anil On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: Hi Anil, I believe that you are wrong stating that DEFVAL clauses should not be present in the definitions of scalar objects, or at least I could not find such a recommendations in the RFCs that define the SMI. On the contrary, RFC 2578, section 7.9 says: Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. So when an agent is initialized it is good practice to define default values for writeable objects (scalar or columnar) unless we do not care what value the agent starts operating with. Regards, Dan *From: * Anil R [ _mailto:anil@charter.net_ ] *Sent: * Wednesday, October 10, 2012 2:40 PM *To: * Benoit Claise *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen (IETF); _zebrose@alum.mit.edu_ ; Romascanu, Dan (Dan); Joan Cucchiara *Subject: * Re: Benoit Claise's Discuss on draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) Benoit, I will make a good faith attempt at responding to these comments yet again, although I have already responded to many of them (other than new ones that just showed up in the latest round). The DEFVAL comment is one which keeps coming back, disregarding my many responses that this is not a useful construct for scalar objects and its chief purpose is to give a default value to tables objects missing in the creation of a table instance, as described in its definition "The DEFVAL clause, which need not be present, defines an acceptable default value which may be used when an object instance is created." DEFVAL need not be present even in table objects, but definitely should not be present in scalar objects - but the latter is what several of these comments are insisting upon. It is the protocol specification that defines default values for protocol objects, not MIBs. Regards, Anil _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors --_000_CC9CA4E011007tnadeaujunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <586AC1B0F9C7F84CA34058974DB51168@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, October 11, 2012 11= :27 AM
To: "Bert Wijnen (IETF)" = <bertietf@bwijnen.net> Cc: "MIB Doctors (E-mail)"= ; <mib-doctors@ietf.org><= br> Subject: Re: [MIB-DOCTORS] DEVAL fo= r scalar object

On 11/10/2012 17:17, Bert Wijnen (IETF) wrot= e:
That so= unds very plausible Joan.
So if it IS the case that it defined in the protocol spec
then WHY the heck is Anil pushing back so much.
After all, it is quite simple/easy to add a DEFVAL line.
The time spent arguing is a bigger than just editing the DEFVAL.
On top of that, Anil wrote:
> By the way I have included a REFERENCE clause in most objec= ts, guiding an implementor to the section of the protocol RFC where he can = find more information about the object and its default, if applicable.

If the RFC is now obsolete, the REFERENCE points to an obsoleted reference.= ..

If the= RFC in question is obsolete, then what protocol(s) is/are the MIB managing= ?!

--Tom<= /div>



Regards, Benoit.
Bert

On 10/11/12 5:02 PM, Joan Cucchiara wrote:

For THIS specific review most scalars (one exception is rbridgeBaseTrillVer= sion) have
DEFVALs specified in the protocol (RFC6325).   Not
all protocol specifications do specify default values as clearly as this sp= ecification does. When default values are specified in
the protocol (RFC) as is mostly the
situation being discussed here with the scalars, I think DEFVALs SHOULD be = put
into the MIB.   I would like to say MUST, but believe Bert and Ju= ergen have
pointed out that there is precedence to flexible on this.

Please note, however, if these DEFVALs which have been specified by the RFC= 6325 were
in the MIB, they could be interpreted/compiled by tools which process MIBs =
and this reduces error and assists in promoting interoperability. &nbs= p; All in all, better for
the MIB's deployment and better for the WG to promote the protocol.

Thanks,
  -Joan

----- Original Message ----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: "Benoit Claise" <bclaise@cisco.com>; "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object


Agree.
I consider it a nice to have for scalars, but we have
approved quite a few MIB modules that did not have it
for (all) scalars. So we betterbe a bit flexible on
this point. We can recommend that they do it where it
makes sense. I would not hold up a MIB module for too
long if they resist/reject (certainly if they have
good arguments).

Bert

On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote:
Hi,

I think the issue boils down to the question whether the scalars are
dynamically created by an agent or not. e.e., they come into existance
as a side effect of setting some other object. In such situations,
DEFVALs are useful to document which value a management system may
expect to be held in the newly established scalar (but note also that
the DEFVAL clause is not binding; the value is used "at the discretion=
of an agent when an object instance is created" - a conservative
management application will thus check the value anyway if it is
important).

/js

On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote:
MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your
numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the
required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be
useful information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice
to have them
     This is in line with

    RFC 2578, section 7.9 says:
        Note that with this definition o= f the DEFVAL clause, it is
        appropriate to use it for any co= lumnar object of a read-create
    table.
        It is also permitted to use it f= or scalar objects dynamically
    created
        by an agent, or for columnar obj= ects of a read-write table
        dynamically created by an agent.=

- If you don't put DEFVAL for scalar objects, then insert in the
description a pointer on where to find the information

Regards, Benoit.




-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake
<d3e= 3e3@gmail.com>, Erik Nordmark <nor= dmark@acm.org>, Ralph Droms
&l= t;rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <= ;bertietf@bwijnen.net>,
= zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me
<bc= laise@cisco.com>



Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have. =

1. If you are the implementor, you must know the spec by heart, and
obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains
the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty
useful information to have default values. It's pretty nice when a
NMS GUI contains the DEVAL value. Sure you can tell that, by looking
at the specifications, someone will be able to get this value. In
practice, is it done? So if the GUI developers could directly get
the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter
almost anything. And the network operator just puts random values in
there. In the world of NetFlow, inserting non-sense timeout values
produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS
customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing
else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol
specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
By the way I have included a REFERENCE clause in = most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.
That's good information already, and I could leave with that. It's
actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer
support engineer.

I want to publicly thanks Joan for the time spent on her review.
Much appreciated.
Now, I would like to have some consistency from the MIB doctors in
terms of guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,

An SNMP set operation is used to change the value of a read-write
object, or to create a new row in a table. There is a distinct
difference between the applicability of DEFVAL in these two cases,
hence the "appropriate" versus "permitted" language in = the
definition of the DEFVAL clause for these two cases.

When a set operation is performed on a scalar object, it comes
with a value to write into it. The SNMP agent need not guess what
that value might be,  nor does it need to rely on the MIB to tell
it what to do.

When a set operation is performed to create a new row in a table,
it may specify the value of one or more columns in that row. If
the SNMP agent is going to create a row, and not all column
objects have been specified, it is left with a dilemma: what
should it set as the values of those column objects? This is what
the DEFVAL clause allows you to do: give the agent a default value
for unspecified column objects. Such a dilemma does not occur for
setting of scalar objects.

If what you were saying is true, then every read-write object in
every MIB would need a DEFVAL clause. Clearly that is not the
case.

By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.

If this doesn't convince you, we will have to agree to disagree on this.
Regards,
Anil


On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:

Hi Anil,
I need to disagree with you on this. The DEFVAL function is the
same for a scalar and for a columnar object =96 as you well put it
=91the agent can deduce the missing value from the MIB syntax=92.
I do not understand your argument that the implementor should look
at the protocol specifications to in the case of scalar objects.
We are talking about writeable objects. Whatever the agent
initializes with will be sent to the instrumentation. In the
absence of a DEFVAL value anything can be written there. The same
as in the case of a columnar object the DEFVAL will indicate the
value the agent initializes with which will be the first value to
be sent to the instrumentation until a setRequest command changes
it. Why should the agent implementor need to look in the protocol
specifications and not help him defining DEFVAL clauses?
Regards,
Dan
*From: *Anil R [mailto:anil@charter.net]
*Sent: *Wednesday, October 10, 2012 3:33 PM
*To: *Romascanu, Dan (Dan)
*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms;
Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara
*Subject: *Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Dan,
>From the description:
- as a columnar object, it is "appropriate&q= uot; to use DEFVAL
- as a scalar object, it is "permitted" to use DEFVAL.
Sure I know it is permitted for scalar objects, as that will not
cause a compile error.
For columnar objects, it is actually useful, because a manager may
create an instance without specifying a columnar object. So it is
syntactically and practically useful to do so in such cases,
because the agent can deduce the missing value from the MIB
syntax. It makes the protocol more efficient. I know this is why
we added DEFVAL, based on my interaction at the time with the
original SNMP authors (Jeff Case, et al).
My point is that not only is specifying DEFVAL for a scalar
useless from an SNMP syntactical point of view - because an agent
cannot actually use it, other than an implementor reading the RFC
text - but it is actually dangerous to do so. An implementor TRILL
should be looking to the protocol specification (RFC6325 in this
case) to determine how the protocol works and what the needed
defaults are.
We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to
go update the MIB.
Regards,
Anil
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:



Hi Anil,
I believe that you are wrong stating that DEFVAL clauses should
not be present in the definitions of scalar objects, or at least I
could not find such a recommendations in the RFCs that define the
SMI. On the contrary, RFC 2578, section 7.9 says:
   Note that with this definition of the DEFVAL clause, it is    appropriate to use it for any columnar object of a read-create= table.
   It is also permitted to use it for scalar objects dynamically = created
   by an agent, or for columnar objects of a read-write table    dynamically created by an agent.
So when an agent is initialized it is good practice to define
default values for writeable objects (scalar or columnar) unless
we do not care what value the agent starts operating with.
Regards,
Dan
*From: *  Anil R [ _mailto:anil@charter.net_
<javascript:parent.wgMail.openComposeWin= dow('anil@charter.net')>]
*Sent: * Wednesday, October 10, 2012 2:40 PM
*To: *  Benoit Claise
*Cc: *  Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen
(IETF); _zebrose@alum.mit.edu_ <javascript:parent.wgMail.openComposeWindow('zebrose@alum.mit.edu')><= /a>;
Romascanu, Dan (Dan); Joan Cucchiara
*Subject: * Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Benoit,
I will make a good faith attempt at responding to these comments
yet again, although I have already responded to many of them
(other than new ones that just showed up in the latest round).
The DEFVAL comment is one which keeps coming back, disregarding my
many responses that this is not a useful construct for scalar
objects and its chief purpose is to give a default value to tables
objects missing in the creation of a table instance, as described
in its definition "The DEFVAL clause, which need not be present,
defines an acceptable default value which may be used when an
object instance is created."
DEFVAL need not be present even in table objects, but definitely
should not be present in scalar objects - but the latter is what
several of these comments are insisting upon. It is the protocol
specification that defines default values for protocol objects,
not MIBs.
Regards,
Anil



_______________________________________________ <= br> MIB-DOCTORS mailing list
= MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
MIB-DOCTORS mailing list
= MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors





--_000_CC9CA4E011007tnadeaujunipernet_-- From glenn@cysols.com Thu Oct 11 15:52:26 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0CF21F85B4 for ; Thu, 11 Oct 2012 15:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV9cX-16GfEG for ; Thu, 11 Oct 2012 15:52:25 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD921F8540 for ; Thu, 11 Oct 2012 15:52:17 -0700 (PDT) Received: from [192.168.0.89] (cysvpn02.priv.cysol.co.jp [192.168.0.89]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.5/8.14.4) with ESMTP id q9BMqE3l066956 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Oct 2012 07:52:14 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <50774D9F.1090901@cysols.com> Date: Fri, 12 Oct 2012 07:52:15 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mib-doctors@ietf.org References: <50768D41.90205@cisco.com> <507690D1.4070800@cisco.com><20121011111352.GA65010@elstar.local> <5076AF0E.1000209@bwijnen.net> <007101cda7c1$6ed964c0$6801a8c0@JoanPC> <5076E317.8070403@bwijnen.net> In-Reply-To: <5076E317.8070403@bwijnen.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 22:52:26 -0000 I agree that the DEFVAL in in this case will make the document better. > On (2012/10/12 0:17), Bert Wijnen (IETF) wrote: > That sounds very plausible Joan. > So if it IS the case that it defined in the protocol spec > then WHY the heck is Anil pushing back so much. > After all, it is quite simple/easy to add a DEFVAL line. Right. With no hard feelings, Anil and/or the WG should explain that. Procedural issues like "You did not do say it before" or "there are precedences" do not count as good reasons. The focus is on producing a better document. The MIB-Doctor is trying to help make the document better. > > Bert > Glenn > > On 10/11/12 5:02 PM, Joan Cucchiara wrote: >> >> For THIS specific review most scalars (one exception is >> rbridgeBaseTrillVersion) have >> DEFVALs specified in the protocol (RFC6325). Not >> all protocol specifications do specify default values as clearly as >> this specification does. When default values are specified in >> the protocol (RFC) as is mostly the >> situation being discussed here with the scalars, I think DEFVALs >> SHOULD be put >> into the MIB. I would like to say MUST, but believe Bert and Juergen have >> pointed out that there is precedence to flexible on this. >> >> Please note, however, if these DEFVALs which have been specified by >> the RFC6325 were >> in the MIB, they could be interpreted/compiled by tools which process >> MIBs >> and this reduces error and assists in promoting interoperability. All >> in all, better for >> the MIB's deployment and better for the WG to promote the protocol. >> >> Thanks, >> -Joan >> >> ----- Original Message ----- From: "Bert Wijnen (IETF)" >> >> To: "Benoit Claise" ; "MIB Doctors (E-mail)" >> >> Sent: Thursday, October 11, 2012 7:35 AM >> Subject: Re: [MIB-DOCTORS] DEVAL for scalar object >> >> >>> Agree. >>> I consider it a nice to have for scalars, but we have >>> approved quite a few MIB modules that did not have it >>> for (all) scalars. So we betterbe a bit flexible on >>> this point. We can recommend that they do it where it >>> makes sense. I would not hold up a MIB module for too >>> long if they resist/reject (certainly if they have >>> good arguments). >>> >>> Bert >>> >>> On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >>>> Hi, >>>> >>>> I think the issue boils down to the question whether the scalars are >>>> dynamically created by an agent or not. e.e., they come into existance >>>> as a side effect of setting some other object. In such situations, >>>> DEFVALs are useful to document which value a management system may >>>> expect to be held in the newly established scalar (but note also that >>>> the DEFVAL clause is not binding; the value is used "at the discretion >>>> of an agent when an object instance is created" - a conservative >>>> management application will thus check the value anyway if it is >>>> important). >>>> >>>> /js >>>> >>>> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>>>> MIB doctors, >>>>> >>>>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your >>>>> numerous review of this MIB, which I fully support. >>>>> >>>>> Now, we received some push back from Anil, the author, on the >>>>> required DEFVAL for scalar. >>>>> As I wrote below, I always considered the DEFVAL for scalar to be >>>>> useful information, but I understand both arguments. >>>>> Read the email exchange below. >>>>> >>>>> Which advice do we want to give in the future on this topic? >>>>> >>>>> I'm in favor of telling: >>>>> - DEFVAL for scalar objects are nice-to-have, and it's good practice >>>>> to have them >>>>> This is in line with >>>>> >>>>> RFC 2578, section 7.9 says: >>>>> Note that with this definition of the DEFVAL clause, it is >>>>> appropriate to use it for any columnar object of a read-create >>>>> table. >>>>> It is also permitted to use it for scalar objects dynamically >>>>> created >>>>> by an agent, or for columnar objects of a read-write table >>>>> dynamically created by an agent. >>>>> >>>>> - If you don't put DEFVAL for scalar objects, then insert in the >>>>> description a pointer on where to find the information >>>>> >>>>> Regards, Benoit. >>>>> >>>>> >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: Benoit Claise's Discuss on >>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>>>> From: Benoit Claise >>>>> To: Anil Rijhsinghani >>>>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>>>> , Erik Nordmark , Ralph Droms >>>>> , Bert Wijnen (IETF) , >>>>> zebrose@alum.mit.edu, Joan Cucchiara , me >>>>> >>>>> >>>>> >>>>> >>>>> Anil, Dan, >>>>> >>>>> I understand both arguments for and against DEFVAL for scalar. >>>>> >>>>> I've been in favor of DEFVAL for scalar, and considered it a >>>>> nice-to-have. >>>>> >>>>> 1. If you are the implementor, you must know the spec by heart, and >>>>> obviously, these scalar DEFVAL's are not useful to you. >>>>> 2. If you are the SNMP agent, it's true that the SNMPset contains >>>>> the value to be set, so you don't need the DEFVAL. >>>>> 3. If you are the network operator using the NMS GUI , it's pretty >>>>> useful information to have default values. It's pretty nice when a >>>>> NMS GUI contains the DEVAL value. Sure you can tell that, by looking >>>>> at the specifications, someone will be able to get this value. In >>>>> practice, is it done? So if the GUI developers could directly get >>>>> the information from the DEFVAL, that's a plus. >>>>> I've seen to many GUIs where the first config page allows to enter >>>>> almost anything. And the network operator just puts random values in >>>>> there. In the world of NetFlow, inserting non-sense timeout values >>>>> produced some funny results. >>>>> 4. If you are none of the above... Once upon a time, I was a NMS >>>>> customer support engineer, and I read many MIB modules. >>>>> And the DEFVAL always helped getting the default values. If nothing >>>>> else, for troubleshooting. >>>>> And no, I didn't know (and didn't want to know) all the protocol >>>>> specification details of the feature/protocol to be managed. >>>>> >>>>> You see, there are multiple actors dealing with MIB modules. >>>>> >>>>> How to more forward? >>>>>> By the way I have included a REFERENCE clause in most objects, >>>>> guiding an implementor to the section of the protocol RFC where he >>>>> can find more information about the object and its default, if >>>>> applicable. >>>>> That's good information already, and I could leave with that. It's >>>>> actually just a (*) level of indirection >>>>> >>>>> (*) time consuming if I take the case 4 above, i.e. my customer >>>>> support engineer. >>>>> >>>>> I want to publicly thanks Joan for the time spent on her review. >>>>> Much appreciated. >>>>> Now, I would like to have some consistency from the MIB doctors in >>>>> terms of guidelines on this topic. Let me discuss with them. >>>>> >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> Dan, >>>>>> >>>>>> An SNMP set operation is used to change the value of a read-write >>>>>> object, or to create a new row in a table. There is a distinct >>>>>> difference between the applicability of DEFVAL in these two cases, >>>>>> hence the "appropriate" versus "permitted" language in the >>>>>> definition of the DEFVAL clause for these two cases. >>>>>> >>>>>> When a set operation is performed on a scalar object, it comes >>>>>> with a value to write into it. The SNMP agent need not guess what >>>>>> that value might be, nor does it need to rely on the MIB to tell >>>>>> it what to do. >>>>>> >>>>>> When a set operation is performed to create a new row in a table, >>>>>> it may specify the value of one or more columns in that row. If >>>>>> the SNMP agent is going to create a row, and not all column >>>>>> objects have been specified, it is left with a dilemma: what >>>>>> should it set as the values of those column objects? This is what >>>>>> the DEFVAL clause allows you to do: give the agent a default value >>>>>> for unspecified column objects. Such a dilemma does not occur for >>>>>> setting of scalar objects. >>>>>> >>>>>> If what you were saying is true, then every read-write object in >>>>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>>>> case. >>>>>> >>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>> guiding an implementor to the section of the protocol RFC where he >>>>>> can find more information about the object and its default, if >>>>>> applicable. >>>>>> >>>>>> If this doesn't convince you, we will have to agree to disagree on >>>>>> this. >>>>>> >>>>>> Regards, >>>>>> Anil >>>>>> >>>>>> >>>>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>>>> >>>>>> Hi Anil, >>>>>> I need to disagree with you on this. The DEFVAL function is the >>>>>> same for a scalar and for a columnar object – as you well put it >>>>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>>>> I do not understand your argument that the implementor should look >>>>>> at the protocol specifications to in the case of scalar objects. >>>>>> We are talking about writeable objects. Whatever the agent >>>>>> initializes with will be sent to the instrumentation. In the >>>>>> absence of a DEFVAL value anything can be written there. The same >>>>>> as in the case of a columnar object the DEFVAL will indicate the >>>>>> value the agent initializes with which will be the first value to >>>>>> be sent to the instrumentation until a setRequest command changes >>>>>> it. Why should the agent implementor need to look in the protocol >>>>>> specifications and not help him defining DEFVAL clauses? >>>>>> Regards, >>>>>> Dan >>>>>> *From: *Anil R [mailto:anil@charter.net] >>>>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>>>> *To: *Romascanu, Dan (Dan) >>>>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms; >>>>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>>>> *Subject: *Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Dan, >>>>> >From the description: >>>>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>>>> Sure I know it is permitted for scalar objects, as that will not >>>>>> cause a compile error. >>>>>> For columnar objects, it is actually useful, because a manager may >>>>>> create an instance without specifying a columnar object. So it is >>>>>> syntactically and practically useful to do so in such cases, >>>>>> because the agent can deduce the missing value from the MIB >>>>>> syntax. It makes the protocol more efficient. I know this is why >>>>>> we added DEFVAL, based on my interaction at the time with the >>>>>> original SNMP authors (Jeff Case, et al). >>>>>> My point is that not only is specifying DEFVAL for a scalar >>>>>> useless from an SNMP syntactical point of view - because an agent >>>>>> cannot actually use it, other than an implementor reading the RFC >>>>>> text - but it is actually dangerous to do so. An implementor TRILL >>>>>> should be looking to the protocol specification (RFC6325 in this >>>>>> case) to determine how the protocol works and what the needed >>>>>> defaults are. >>>>>> We don't to define defaults in two different RFCs if we can help it. >>>>>> If the protocol decides to change a default, we shouldn't have to >>>>>> go update the MIB. >>>>>> Regards, >>>>>> Anil >>>>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Anil, >>>>>> I believe that you are wrong stating that DEFVAL clauses should >>>>>> not be present in the definitions of scalar objects, or at least I >>>>>> could not find such a recommendations in the RFCs that define the >>>>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>>>> Note that with this definition of the DEFVAL clause, it is >>>>>> appropriate to use it for any columnar object of a read-create table. >>>>>> It is also permitted to use it for scalar objects dynamically created >>>>>> by an agent, or for columnar objects of a read-write table >>>>>> dynamically created by an agent. >>>>>> So when an agent is initialized it is good practice to define >>>>>> default values for writeable objects (scalar or columnar) unless >>>>>> we do not care what value the agent starts operating with. >>>>>> Regards, >>>>>> Dan >>>>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>>>> ] >>>>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>>>> *To: * Benoit Claise >>>>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen >>>>>> (IETF); _zebrose@alum.mit.edu_ >>>>>> ; >>>>>> Romascanu, Dan (Dan); Joan Cucchiara >>>>>> *Subject: * Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Benoit, >>>>>> I will make a good faith attempt at responding to these comments >>>>>> yet again, although I have already responded to many of them >>>>>> (other than new ones that just showed up in the latest round). >>>>>> The DEFVAL comment is one which keeps coming back, disregarding my >>>>>> many responses that this is not a useful construct for scalar >>>>>> objects and its chief purpose is to give a default value to tables >>>>>> objects missing in the creation of a table instance, as described >>>>>> in its definition "The DEFVAL clause, which need not be present, >>>>>> defines an acceptable default value which may be used when an >>>>>> object instance is created." >>>>>> DEFVAL need not be present even in table objects, but definitely >>>>>> should not be present in scalar objects - but the latter is what >>>>>> several of these comments are insisting upon. It is the protocol >>>>>> specification that defines default values for protocol objects, >>>>>> not MIBs. >>>>>> Regards, >>>>>> Anil >>>>>> >>>>> >>>> >>>>> _______________________________________________ >>>>> MIB-DOCTORS mailing list >>>>> MIB-DOCTORS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>>> >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> >> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bclaise@cisco.com Sun Oct 14 22:50:55 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20221F8588 for ; Sun, 14 Oct 2012 22:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=3.469, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwQDoMhL5HYM for ; Sun, 14 Oct 2012 22:50:50 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6D21F8569 for ; Sun, 14 Oct 2012 22:50:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9F5oldB004214; Sun, 14 Oct 2012 22:50:47 -0700 (PDT) Received: from [10.21.166.126] ([10.21.166.126]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9F5ojMr008544; Sun, 14 Oct 2012 22:50:45 -0700 (PDT) Message-ID: <507B2F51.2040604@cisco.com> Date: Sun, 14 Oct 2012 23:32:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Thomas Nadeau References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030808080801020003010505" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:50:55 -0000 This is a multi-part message in MIME format. --------------030808080801020003010505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2012 22:32, Thomas Nadeau wrote: > > > From: Benoit Claise > > Date: Thursday, October 11, 2012 11:27 AM > To: "Bert Wijnen (IETF)" > > Cc: "MIB Doctors (E-mail)" > > Subject: Re: [MIB-DOCTORS] DEVAL for scalar object > > On 11/10/2012 17:17, Bert Wijnen (IETF) wrote: >> That sounds very plausible Joan. >> So if it IS the case that it defined in the protocol spec >> then WHY the heck is Anil pushing back so much. >> After all, it is quite simple/easy to add a DEFVAL line. > The time spent arguing is a bigger than just editing the DEFVAL. > On top of that, Anil wrote: > > By the way I have included a REFERENCE clause in most objects, > guiding an implementor to the section of the protocol RFC where he > can find more information about the object and its default, if > applicable. > > If the RFC is now obsolete, the REFERENCE points to an obsoleted > reference... > > > If the RFC in question is obsolete, then what protocol(s) is/are the > MIB managing?! Point taken ;-) Regards, Benoit > > --Tom > > > > Regards, Benoit. >> Bert >> >> >> On 10/11/12 5:02 PM, Joan Cucchiara wrote: >>> >>> For THIS specific review most scalars (one exception is >>> rbridgeBaseTrillVersion) have >>> DEFVALs specified in the protocol (RFC6325). Not >>> all protocol specifications do specify default values as clearly >>> as this specification does. When default values are specified in >>> the protocol (RFC) as is mostly the >>> situation being discussed here with the scalars, I think DEFVALs >>> SHOULD be put >>> into the MIB. I would like to say MUST, but believe Bert and >>> Juergen have >>> pointed out that there is precedence to flexible on this. >>> >>> Please note, however, if these DEFVALs which have been specified >>> by the RFC6325 were >>> in the MIB, they could be interpreted/compiled by tools which >>> process MIBs >>> and this reduces error and assists in promoting >>> interoperability. All in all, better for >>> the MIB's deployment and better for the WG to promote the protocol. >>> >>> Thanks, >>> -Joan >>> >>> ----- Original Message ----- From: "Bert Wijnen (IETF)" >>> >>> To: "Benoit Claise" ; "MIB Doctors (E-mail)" >>> >>> Sent: Thursday, October 11, 2012 7:35 AM >>> Subject: Re: [MIB-DOCTORS] DEVAL for scalar object >>> >>> >>>> Agree. >>>> I consider it a nice to have for scalars, but we have >>>> approved quite a few MIB modules that did not have it >>>> for (all) scalars. So we betterbe a bit flexible on >>>> this point. We can recommend that they do it where it >>>> makes sense. I would not hold up a MIB module for too >>>> long if they resist/reject (certainly if they have >>>> good arguments). >>>> >>>> Bert >>>> >>>> On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >>>>> Hi, >>>>> >>>>> I think the issue boils down to the question whether the >>>>> scalars are >>>>> dynamically created by an agent or not. e.e., they come into >>>>> existance >>>>> as a side effect of setting some other object. In such >>>>> situations, >>>>> DEFVALs are useful to document which value a management system >>>>> may >>>>> expect to be held in the newly established scalar (but note >>>>> also that >>>>> the DEFVAL clause is not binding; the value is used "at the >>>>> discretion >>>>> of an agent when an object instance is created" - a conservative >>>>> management application will thus check the value anyway if it is >>>>> important). >>>>> >>>>> /js >>>>> >>>>> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>>>>> MIB doctors, >>>>>> >>>>>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks >>>>>> for your >>>>>> numerous review of this MIB, which I fully support. >>>>>> >>>>>> Now, we received some push back from Anil, the author, on the >>>>>> required DEFVAL for scalar. >>>>>> As I wrote below, I always considered the DEFVAL for scalar >>>>>> to be >>>>>> useful information, but I understand both arguments. >>>>>> Read the email exchange below. >>>>>> >>>>>> Which advice do we want to give in the future on this topic? >>>>>> >>>>>> I'm in favor of telling: >>>>>> - DEFVAL for scalar objects are nice-to-have, and it's good >>>>>> practice >>>>>> to have them >>>>>> This is in line with >>>>>> >>>>>> RFC 2578, section 7.9 says: >>>>>> Note that with this definition of the DEFVAL clause, >>>>>> it is >>>>>> appropriate to use it for any columnar object of a >>>>>> read-create >>>>>> table. >>>>>> It is also permitted to use it for scalar objects >>>>>> dynamically >>>>>> created >>>>>> by an agent, or for columnar objects of a read-write >>>>>> table >>>>>> dynamically created by an agent. >>>>>> >>>>>> - If you don't put DEFVAL for scalar objects, then insert in the >>>>>> description a pointer on where to find the information >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>>>>> From: Benoit Claise >>>>>> To: Anil Rijhsinghani >>>>>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>>>>> , Erik Nordmark , Ralph >>>>>> Droms >>>>>> , Bert Wijnen (IETF) >>>>>> , >>>>>> zebrose@alum.mit.edu, Joan Cucchiara >>>>>> , me >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Anil, Dan, >>>>>> >>>>>> I understand both arguments for and against DEFVAL for scalar. >>>>>> >>>>>> I've been in favor of DEFVAL for scalar, and considered it a >>>>>> nice-to-have. >>>>>> >>>>>> 1. If you are the implementor, you must know the spec by >>>>>> heart, and >>>>>> obviously, these scalar DEFVAL's are not useful to you. >>>>>> 2. If you are the SNMP agent, it's true that the SNMPset >>>>>> contains >>>>>> the value to be set, so you don't need the DEFVAL. >>>>>> 3. If you are the network operator using the NMS GUI , it's >>>>>> pretty >>>>>> useful information to have default values. It's pretty nice >>>>>> when a >>>>>> NMS GUI contains the DEVAL value. Sure you can tell that, by >>>>>> looking >>>>>> at the specifications, someone will be able to get this >>>>>> value. In >>>>>> practice, is it done? So if the GUI developers could directly >>>>>> get >>>>>> the information from the DEFVAL, that's a plus. >>>>>> I've seen to many GUIs where the first config page allows to >>>>>> enter >>>>>> almost anything. And the network operator just puts random >>>>>> values in >>>>>> there. In the world of NetFlow, inserting non-sense timeout >>>>>> values >>>>>> produced some funny results. >>>>>> 4. If you are none of the above... Once upon a time, I was a NMS >>>>>> customer support engineer, and I read many MIB modules. >>>>>> And the DEFVAL always helped getting the default values. If >>>>>> nothing >>>>>> else, for troubleshooting. >>>>>> And no, I didn't know (and didn't want to know) all the protocol >>>>>> specification details of the feature/protocol to be managed. >>>>>> >>>>>> You see, there are multiple actors dealing with MIB modules. >>>>>> >>>>>> How to more forward? >>>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>> guiding an implementor to the section of the protocol RFC >>>>>> where he >>>>>> can find more information about the object and its default, if >>>>>> applicable. >>>>>> That's good information already, and I could leave with that. >>>>>> It's >>>>>> actually just a (*) level of indirection >>>>>> >>>>>> (*) time consuming if I take the case 4 above, i.e. my customer >>>>>> support engineer. >>>>>> >>>>>> I want to publicly thanks Joan for the time spent on her review. >>>>>> Much appreciated. >>>>>> Now, I would like to have some consistency from the MIB >>>>>> doctors in >>>>>> terms of guidelines on this topic. Let me discuss with them. >>>>>> >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>>> Dan, >>>>>>> >>>>>>> An SNMP set operation is used to change the value of a >>>>>>> read-write >>>>>>> object, or to create a new row in a table. There is a distinct >>>>>>> difference between the applicability of DEFVAL in these two >>>>>>> cases, >>>>>>> hence the "appropriate" versus "permitted" language in the >>>>>>> definition of the DEFVAL clause for these two cases. >>>>>>> >>>>>>> When a set operation is performed on a scalar object, it comes >>>>>>> with a value to write into it. The SNMP agent need not guess >>>>>>> what >>>>>>> that value might be, nor does it need to rely on the MIB to >>>>>>> tell >>>>>>> it what to do. >>>>>>> >>>>>>> When a set operation is performed to create a new row in a >>>>>>> table, >>>>>>> it may specify the value of one or more columns in that row. If >>>>>>> the SNMP agent is going to create a row, and not all column >>>>>>> objects have been specified, it is left with a dilemma: what >>>>>>> should it set as the values of those column objects? This is >>>>>>> what >>>>>>> the DEFVAL clause allows you to do: give the agent a default >>>>>>> value >>>>>>> for unspecified column objects. Such a dilemma does not >>>>>>> occur for >>>>>>> setting of scalar objects. >>>>>>> >>>>>>> If what you were saying is true, then every read-write >>>>>>> object in >>>>>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>>>>> case. >>>>>>> >>>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>>> guiding an implementor to the section of the protocol RFC >>>>>>> where he >>>>>>> can find more information about the object and its default, if >>>>>>> applicable. >>>>>>> >>>>>>> If this doesn't convince you, we will have to agree to >>>>>>> disagree on this. >>>>>>> >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>>>>> >>>>>>> Hi Anil, >>>>>>> I need to disagree with you on this. The DEFVAL function is the >>>>>>> same for a scalar and for a columnar object – as you well >>>>>>> put it >>>>>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>>>>> I do not understand your argument that the implementor >>>>>>> should look >>>>>>> at the protocol specifications to in the case of scalar >>>>>>> objects. >>>>>>> We are talking about writeable objects. Whatever the agent >>>>>>> initializes with will be sent to the instrumentation. In the >>>>>>> absence of a DEFVAL value anything can be written there. The >>>>>>> same >>>>>>> as in the case of a columnar object the DEFVAL will indicate >>>>>>> the >>>>>>> value the agent initializes with which will be the first >>>>>>> value to >>>>>>> be sent to the instrumentation until a setRequest command >>>>>>> changes >>>>>>> it. Why should the agent implementor need to look in the >>>>>>> protocol >>>>>>> specifications and not help him defining DEFVAL clauses? >>>>>>> Regards, >>>>>>> Dan >>>>>>> *From: *Anil R [mailto:anil@charter.net] >>>>>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>>>>> *To: *Romascanu, Dan (Dan) >>>>>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph >>>>>>> Droms; >>>>>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>>>>> *Subject: *Re: Benoit Claise's Discuss on >>>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>>> Dan, >>>>>> >From the description: >>>>>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>>>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>>>>> Sure I know it is permitted for scalar objects, as that will >>>>>>> not >>>>>>> cause a compile error. >>>>>>> For columnar objects, it is actually useful, because a >>>>>>> manager may >>>>>>> create an instance without specifying a columnar object. So >>>>>>> it is >>>>>>> syntactically and practically useful to do so in such cases, >>>>>>> because the agent can deduce the missing value from the MIB >>>>>>> syntax. It makes the protocol more efficient. I know this is >>>>>>> why >>>>>>> we added DEFVAL, based on my interaction at the time with the >>>>>>> original SNMP authors (Jeff Case, et al). >>>>>>> My point is that not only is specifying DEFVAL for a scalar >>>>>>> useless from an SNMP syntactical point of view - because an >>>>>>> agent >>>>>>> cannot actually use it, other than an implementor reading >>>>>>> the RFC >>>>>>> text - but it is actually dangerous to do so. An implementor >>>>>>> TRILL >>>>>>> should be looking to the protocol specification (RFC6325 in >>>>>>> this >>>>>>> case) to determine how the protocol works and what the needed >>>>>>> defaults are. >>>>>>> We don't to define defaults in two different RFCs if we can >>>>>>> help it. >>>>>>> If the protocol decides to change a default, we shouldn't >>>>>>> have to >>>>>>> go update the MIB. >>>>>>> Regards, >>>>>>> Anil >>>>>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Anil, >>>>>>> I believe that you are wrong stating that DEFVAL clauses should >>>>>>> not be present in the definitions of scalar objects, or at >>>>>>> least I >>>>>>> could not find such a recommendations in the RFCs that >>>>>>> define the >>>>>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>>>>> Note that with this definition of the DEFVAL clause, it is >>>>>>> appropriate to use it for any columnar object of a >>>>>>> read-create table. >>>>>>> It is also permitted to use it for scalar objects >>>>>>> dynamically created >>>>>>> by an agent, or for columnar objects of a read-write table >>>>>>> dynamically created by an agent. >>>>>>> So when an agent is initialized it is good practice to define >>>>>>> default values for writeable objects (scalar or columnar) >>>>>>> unless >>>>>>> we do not care what value the agent starts operating with. >>>>>>> Regards, >>>>>>> Dan >>>>>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>>>>> ] >>>>>>> >>>>>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>>>>> *To: * Benoit Claise >>>>>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert >>>>>>> Wijnen >>>>>>> (IETF); _zebrose@alum.mit.edu_ >>>>>>> >>>>>>> ; >>>>>>> Romascanu, Dan (Dan); Joan Cucchiara >>>>>>> *Subject: * Re: Benoit Claise's Discuss on >>>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>>> Benoit, >>>>>>> I will make a good faith attempt at responding to these >>>>>>> comments >>>>>>> yet again, although I have already responded to many of them >>>>>>> (other than new ones that just showed up in the latest round). >>>>>>> The DEFVAL comment is one which keeps coming back, >>>>>>> disregarding my >>>>>>> many responses that this is not a useful construct for scalar >>>>>>> objects and its chief purpose is to give a default value to >>>>>>> tables >>>>>>> objects missing in the creation of a table instance, as >>>>>>> described >>>>>>> in its definition "The DEFVAL clause, which need not be >>>>>>> present, >>>>>>> defines an acceptable default value which may be used when an >>>>>>> object instance is created." >>>>>>> DEFVAL need not be present even in table objects, but >>>>>>> definitely >>>>>>> should not be present in scalar objects - but the latter is >>>>>>> what >>>>>>> several of these comments are insisting upon. It is the >>>>>>> protocol >>>>>>> specification that defines default values for protocol objects, >>>>>>> not MIBs. >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>>> MIB-DOCTORS mailing list >>>>>> MIB-DOCTORS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>> >>>>> >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>> >>> >> >> > --------------030808080801020003010505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/10/2012 22:32, Thomas Nadeau wrote:


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, October 11, 2012 11:27 AM
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object

On 11/10/2012 17:17, Bert Wijnen (IETF) wrote:
That sounds very plausible Joan.
So if it IS the case that it defined in the protocol spec
then WHY the heck is Anil pushing back so much.
After all, it is quite simple/easy to add a DEFVAL line.
The time spent arguing is a bigger than just editing the DEFVAL.
On top of that, Anil wrote:
> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.

If the RFC is now obsolete, the REFERENCE points to an obsoleted reference...

If the RFC in question is obsolete, then what protocol(s) is/are the MIB managing?!
Point taken ;-)

Regards, Benoit

--Tom



Regards, Benoit.
Bert


On 10/11/12 5:02 PM, Joan Cucchiara wrote:

For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have
DEFVALs specified in the protocol (RFC6325).   Not
all protocol specifications do specify default values as clearly as this specification does. When default values are specified in
the protocol (RFC) as is mostly the
situation being discussed here with the scalars, I think DEFVALs SHOULD be put
into the MIB.   I would like to say MUST, but believe Bert and Juergen have
pointed out that there is precedence to flexible on this.

Please note, however, if these DEFVALs which have been specified by the RFC6325 were
in the MIB, they could be interpreted/compiled by tools which process MIBs
and this reduces error and assists in promoting interoperability.   All in all, better for
the MIB's deployment and better for the WG to promote the protocol.

Thanks,
  -Joan

----- Original Message ----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: "Benoit Claise" <bclaise@cisco.com>; "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object


Agree.
I consider it a nice to have for scalars, but we have
approved quite a few MIB modules that did not have it
for (all) scalars. So we betterbe a bit flexible on
this point. We can recommend that they do it where it
makes sense. I would not hold up a MIB module for too
long if they resist/reject (certainly if they have
good arguments).

Bert

On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote:
Hi,

I think the issue boils down to the question whether the scalars are
dynamically created by an agent or not. e.e., they come into existance
as a side effect of setting some other object. In such situations,
DEFVALs are useful to document which value a management system may
expect to be held in the newly established scalar (but note also that
the DEFVAL clause is not binding; the value is used "at the discretion
of an agent when an object instance is created" - a conservative
management application will thus check the value anyway if it is
important).

/js

On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote:
MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your
numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the
required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be
useful information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice
to have them
     This is in line with

    RFC 2578, section 7.9 says:
        Note that with this definition of the DEFVAL clause, it is
        appropriate to use it for any columnar object of a read-create
    table.
        It is also permitted to use it for scalar objects dynamically
    created
        by an agent, or for columnar objects of a read-write table
        dynamically created by an agent.

- If you don't put DEFVAL for scalar objects, then insert in the
description a pointer on where to find the information

Regards, Benoit.




-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake
<d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, Ralph Droms
<rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <bertietf@bwijnen.net>,
zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me
<bclaise@cisco.com>



Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.

1. If you are the implementor, you must know the spec by heart, and
obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains
the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty
useful information to have default values. It's pretty nice when a
NMS GUI contains the DEVAL value. Sure you can tell that, by looking
at the specifications, someone will be able to get this value. In
practice, is it done? So if the GUI developers could directly get
the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter
almost anything. And the network operator just puts random values in
there. In the world of NetFlow, inserting non-sense timeout values
produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS
customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing
else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol
specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.
That's good information already, and I could leave with that. It's
actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer
support engineer.

I want to publicly thanks Joan for the time spent on her review.
Much appreciated.
Now, I would like to have some consistency from the MIB doctors in
terms of guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,

An SNMP set operation is used to change the value of a read-write
object, or to create a new row in a table. There is a distinct
difference between the applicability of DEFVAL in these two cases,
hence the "appropriate" versus "permitted" language in the
definition of the DEFVAL clause for these two cases.

When a set operation is performed on a scalar object, it comes
with a value to write into it. The SNMP agent need not guess what
that value might be,  nor does it need to rely on the MIB to tell
it what to do.

When a set operation is performed to create a new row in a table,
it may specify the value of one or more columns in that row. If
the SNMP agent is going to create a row, and not all column
objects have been specified, it is left with a dilemma: what
should it set as the values of those column objects? This is what
the DEFVAL clause allows you to do: give the agent a default value
for unspecified column objects. Such a dilemma does not occur for
setting of scalar objects.

If what you were saying is true, then every read-write object in
every MIB would need a DEFVAL clause. Clearly that is not the
case.

By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.

If this doesn't convince you, we will have to agree to disagree on this.

Regards,
Anil


On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:

Hi Anil,
I need to disagree with you on this. The DEFVAL function is the
same for a scalar and for a columnar object – as you well put it
‘the agent can deduce the missing value from the MIB syntax’.
I do not understand your argument that the implementor should look
at the protocol specifications to in the case of scalar objects.
We are talking about writeable objects. Whatever the agent
initializes with will be sent to the instrumentation. In the
absence of a DEFVAL value anything can be written there. The same
as in the case of a columnar object the DEFVAL will indicate the
value the agent initializes with which will be the first value to
be sent to the instrumentation until a setRequest command changes
it. Why should the agent implementor need to look in the protocol
specifications and not help him defining DEFVAL clauses?
Regards,
Dan
*From: *Anil R [mailto:anil@charter.net]
*Sent: *Wednesday, October 10, 2012 3:33 PM
*To: *Romascanu, Dan (Dan)
*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms;
Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara
*Subject: *Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Dan,
>From the description:
- as a columnar object, it is "appropriate" to use DEFVAL
- as a scalar object, it is "permitted" to use DEFVAL.
Sure I know it is permitted for scalar objects, as that will not
cause a compile error.
For columnar objects, it is actually useful, because a manager may
create an instance without specifying a columnar object. So it is
syntactically and practically useful to do so in such cases,
because the agent can deduce the missing value from the MIB
syntax. It makes the protocol more efficient. I know this is why
we added DEFVAL, based on my interaction at the time with the
original SNMP authors (Jeff Case, et al).
My point is that not only is specifying DEFVAL for a scalar
useless from an SNMP syntactical point of view - because an agent
cannot actually use it, other than an implementor reading the RFC
text - but it is actually dangerous to do so. An implementor TRILL
should be looking to the protocol specification (RFC6325 in this
case) to determine how the protocol works and what the needed
defaults are.
We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to
go update the MIB.
Regards,
Anil
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:



Hi Anil,
I believe that you are wrong stating that DEFVAL clauses should
not be present in the definitions of scalar objects, or at least I
could not find such a recommendations in the RFCs that define the
SMI. On the contrary, RFC 2578, section 7.9 says:
   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.
So when an agent is initialized it is good practice to define
default values for writeable objects (scalar or columnar) unless
we do not care what value the agent starts operating with.
Regards,
Dan
*From: *  Anil R [ _mailto:anil@charter.net_
<javascript:parent.wgMail.openComposeWindow('anil@charter.net')>]
*Sent: * Wednesday, October 10, 2012 2:40 PM
*To: *  Benoit Claise
*Cc: *  Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen
(IETF); _zebrose@alum.mit.edu_ <javascript:parent.wgMail.openComposeWindow('zebrose@alum.mit.edu')>;
Romascanu, Dan (Dan); Joan Cucchiara
*Subject: * Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Benoit,
I will make a good faith attempt at responding to these comments
yet again, although I have already responded to many of them
(other than new ones that just showed up in the latest round).
The DEFVAL comment is one which keeps coming back, disregarding my
many responses that this is not a useful construct for scalar
objects and its chief purpose is to give a default value to tables
objects missing in the creation of a table instance, as described
in its definition "The DEFVAL clause, which need not be present,
defines an acceptable default value which may be used when an
object instance is created."
DEFVAL need not be present even in table objects, but definitely
should not be present in scalar objects - but the latter is what
several of these comments are insisting upon. It is the protocol
specification that defines default values for protocol objects,
not MIBs.
Regards,
Anil



_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

--------------030808080801020003010505-- From bclaise@cisco.com Sun Oct 14 22:51:03 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F14921F85AC for ; Sun, 14 Oct 2012 22:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.703 X-Spam-Level: X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[AWL=3.895, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7WQjFFtHTS0 for ; Sun, 14 Oct 2012 22:51:01 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9321F8569 for ; Sun, 14 Oct 2012 22:51:01 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9F5ow8A004227; Sun, 14 Oct 2012 22:50:58 -0700 (PDT) Received: from [10.21.166.126] ([10.21.166.126]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9F5orQV008650; Sun, 14 Oct 2012 22:50:54 -0700 (PDT) Message-ID: <507BA43C.7090805@cisco.com> Date: Sun, 14 Oct 2012 22:50:52 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Thomas Nadeau References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030700030702030800030705" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] DEVAL for scalar object X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:51:03 -0000 This is a multi-part message in MIME format. --------------030700030702030800030705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Tom, > > > From: Benoit Claise > > Date: Thursday, October 11, 2012 11:27 AM > To: "Bert Wijnen (IETF)" > > Cc: "MIB Doctors (E-mail)" > > Subject: Re: [MIB-DOCTORS] DEVAL for scalar object > > On 11/10/2012 17:17, Bert Wijnen (IETF) wrote: >> That sounds very plausible Joan. >> So if it IS the case that it defined in the protocol spec >> then WHY the heck is Anil pushing back so much. >> After all, it is quite simple/easy to add a DEFVAL line. > The time spent arguing is a bigger than just editing the DEFVAL. > On top of that, Anil wrote: > > By the way I have included a REFERENCE clause in most objects, > guiding an implementor to the section of the protocol RFC where he > can find more information about the object and its default, if > applicable. > > If the RFC is now obsolete, the REFERENCE points to an obsoleted > reference... > > > If the RFC in question is obsolete, then what protocol(s) is/are the > MIB managing?! Point taken ;-) I was more thinking about the second maturity level fro, RFC6410 Regards, Benoit > > --Tom > > > > Regards, Benoit. >> Bert >> >> >> On 10/11/12 5:02 PM, Joan Cucchiara wrote: >>> >>> For THIS specific review most scalars (one exception is >>> rbridgeBaseTrillVersion) have >>> DEFVALs specified in the protocol (RFC6325). Not >>> all protocol specifications do specify default values as clearly >>> as this specification does. When default values are specified in >>> the protocol (RFC) as is mostly the >>> situation being discussed here with the scalars, I think DEFVALs >>> SHOULD be put >>> into the MIB. I would like to say MUST, but believe Bert and >>> Juergen have >>> pointed out that there is precedence to flexible on this. >>> >>> Please note, however, if these DEFVALs which have been specified >>> by the RFC6325 were >>> in the MIB, they could be interpreted/compiled by tools which >>> process MIBs >>> and this reduces error and assists in promoting >>> interoperability. All in all, better for >>> the MIB's deployment and better for the WG to promote the protocol. >>> >>> Thanks, >>> -Joan >>> >>> ----- Original Message ----- From: "Bert Wijnen (IETF)" >>> >>> To: "Benoit Claise" ; "MIB Doctors (E-mail)" >>> >>> Sent: Thursday, October 11, 2012 7:35 AM >>> Subject: Re: [MIB-DOCTORS] DEVAL for scalar object >>> >>> >>>> Agree. >>>> I consider it a nice to have for scalars, but we have >>>> approved quite a few MIB modules that did not have it >>>> for (all) scalars. So we betterbe a bit flexible on >>>> this point. We can recommend that they do it where it >>>> makes sense. I would not hold up a MIB module for too >>>> long if they resist/reject (certainly if they have >>>> good arguments). >>>> >>>> Bert >>>> >>>> On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote: >>>>> Hi, >>>>> >>>>> I think the issue boils down to the question whether the >>>>> scalars are >>>>> dynamically created by an agent or not. e.e., they come into >>>>> existance >>>>> as a side effect of setting some other object. In such >>>>> situations, >>>>> DEFVALs are useful to document which value a management system >>>>> may >>>>> expect to be held in the newly established scalar (but note >>>>> also that >>>>> the DEFVAL clause is not binding; the value is used "at the >>>>> discretion >>>>> of an agent when an object instance is created" - a conservative >>>>> management application will thus check the value anyway if it is >>>>> important). >>>>> >>>>> /js >>>>> >>>>> On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote: >>>>>> MIB doctors, >>>>>> >>>>>> Joan did the review of draft-ietf-trill-rbridge-mib.Thanks >>>>>> for your >>>>>> numerous review of this MIB, which I fully support. >>>>>> >>>>>> Now, we received some push back from Anil, the author, on the >>>>>> required DEFVAL for scalar. >>>>>> As I wrote below, I always considered the DEFVAL for scalar >>>>>> to be >>>>>> useful information, but I understand both arguments. >>>>>> Read the email exchange below. >>>>>> >>>>>> Which advice do we want to give in the future on this topic? >>>>>> >>>>>> I'm in favor of telling: >>>>>> - DEFVAL for scalar objects are nice-to-have, and it's good >>>>>> practice >>>>>> to have them >>>>>> This is in line with >>>>>> >>>>>> RFC 2578, section 7.9 says: >>>>>> Note that with this definition of the DEFVAL clause, >>>>>> it is >>>>>> appropriate to use it for any columnar object of a >>>>>> read-create >>>>>> table. >>>>>> It is also permitted to use it for scalar objects >>>>>> dynamically >>>>>> created >>>>>> by an agent, or for columnar objects of a read-write >>>>>> table >>>>>> dynamically created by an agent. >>>>>> >>>>>> - If you don't put DEFVAL for scalar objects, then insert in the >>>>>> description a pointer on where to find the information >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: Benoit Claise's Discuss on >>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>> Date: Thu, 11 Oct 2012 11:11:30 +0200 >>>>>> From: Benoit Claise >>>>>> To: Anil Rijhsinghani >>>>>> CC: Romascanu, Dan (Dan) , Donald Eastlake >>>>>> , Erik Nordmark , Ralph >>>>>> Droms >>>>>> , Bert Wijnen (IETF) >>>>>> , >>>>>> zebrose@alum.mit.edu, Joan Cucchiara >>>>>> , me >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Anil, Dan, >>>>>> >>>>>> I understand both arguments for and against DEFVAL for scalar. >>>>>> >>>>>> I've been in favor of DEFVAL for scalar, and considered it a >>>>>> nice-to-have. >>>>>> >>>>>> 1. If you are the implementor, you must know the spec by >>>>>> heart, and >>>>>> obviously, these scalar DEFVAL's are not useful to you. >>>>>> 2. If you are the SNMP agent, it's true that the SNMPset >>>>>> contains >>>>>> the value to be set, so you don't need the DEFVAL. >>>>>> 3. If you are the network operator using the NMS GUI , it's >>>>>> pretty >>>>>> useful information to have default values. It's pretty nice >>>>>> when a >>>>>> NMS GUI contains the DEVAL value. Sure you can tell that, by >>>>>> looking >>>>>> at the specifications, someone will be able to get this >>>>>> value. In >>>>>> practice, is it done? So if the GUI developers could directly >>>>>> get >>>>>> the information from the DEFVAL, that's a plus. >>>>>> I've seen to many GUIs where the first config page allows to >>>>>> enter >>>>>> almost anything. And the network operator just puts random >>>>>> values in >>>>>> there. In the world of NetFlow, inserting non-sense timeout >>>>>> values >>>>>> produced some funny results. >>>>>> 4. If you are none of the above... Once upon a time, I was a NMS >>>>>> customer support engineer, and I read many MIB modules. >>>>>> And the DEFVAL always helped getting the default values. If >>>>>> nothing >>>>>> else, for troubleshooting. >>>>>> And no, I didn't know (and didn't want to know) all the protocol >>>>>> specification details of the feature/protocol to be managed. >>>>>> >>>>>> You see, there are multiple actors dealing with MIB modules. >>>>>> >>>>>> How to more forward? >>>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>> guiding an implementor to the section of the protocol RFC >>>>>> where he >>>>>> can find more information about the object and its default, if >>>>>> applicable. >>>>>> That's good information already, and I could leave with that. >>>>>> It's >>>>>> actually just a (*) level of indirection >>>>>> >>>>>> (*) time consuming if I take the case 4 above, i.e. my customer >>>>>> support engineer. >>>>>> >>>>>> I want to publicly thanks Joan for the time spent on her review. >>>>>> Much appreciated. >>>>>> Now, I would like to have some consistency from the MIB >>>>>> doctors in >>>>>> terms of guidelines on this topic. Let me discuss with them. >>>>>> >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>>> Dan, >>>>>>> >>>>>>> An SNMP set operation is used to change the value of a >>>>>>> read-write >>>>>>> object, or to create a new row in a table. There is a distinct >>>>>>> difference between the applicability of DEFVAL in these two >>>>>>> cases, >>>>>>> hence the "appropriate" versus "permitted" language in the >>>>>>> definition of the DEFVAL clause for these two cases. >>>>>>> >>>>>>> When a set operation is performed on a scalar object, it comes >>>>>>> with a value to write into it. The SNMP agent need not guess >>>>>>> what >>>>>>> that value might be, nor does it need to rely on the MIB to >>>>>>> tell >>>>>>> it what to do. >>>>>>> >>>>>>> When a set operation is performed to create a new row in a >>>>>>> table, >>>>>>> it may specify the value of one or more columns in that row. If >>>>>>> the SNMP agent is going to create a row, and not all column >>>>>>> objects have been specified, it is left with a dilemma: what >>>>>>> should it set as the values of those column objects? This is >>>>>>> what >>>>>>> the DEFVAL clause allows you to do: give the agent a default >>>>>>> value >>>>>>> for unspecified column objects. Such a dilemma does not >>>>>>> occur for >>>>>>> setting of scalar objects. >>>>>>> >>>>>>> If what you were saying is true, then every read-write >>>>>>> object in >>>>>>> every MIB would need a DEFVAL clause. Clearly that is not the >>>>>>> case. >>>>>>> >>>>>>> By the way I have included a REFERENCE clause in most objects, >>>>>>> guiding an implementor to the section of the protocol RFC >>>>>>> where he >>>>>>> can find more information about the object and its default, if >>>>>>> applicable. >>>>>>> >>>>>>> If this doesn't convince you, we will have to agree to >>>>>>> disagree on this. >>>>>>> >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote: >>>>>>> >>>>>>> Hi Anil, >>>>>>> I need to disagree with you on this. The DEFVAL function is the >>>>>>> same for a scalar and for a columnar object – as you well >>>>>>> put it >>>>>>> ‘the agent can deduce the missing value from the MIB syntax’. >>>>>>> I do not understand your argument that the implementor >>>>>>> should look >>>>>>> at the protocol specifications to in the case of scalar >>>>>>> objects. >>>>>>> We are talking about writeable objects. Whatever the agent >>>>>>> initializes with will be sent to the instrumentation. In the >>>>>>> absence of a DEFVAL value anything can be written there. The >>>>>>> same >>>>>>> as in the case of a columnar object the DEFVAL will indicate >>>>>>> the >>>>>>> value the agent initializes with which will be the first >>>>>>> value to >>>>>>> be sent to the instrumentation until a setRequest command >>>>>>> changes >>>>>>> it. Why should the agent implementor need to look in the >>>>>>> protocol >>>>>>> specifications and not help him defining DEFVAL clauses? >>>>>>> Regards, >>>>>>> Dan >>>>>>> *From: *Anil R [mailto:anil@charter.net] >>>>>>> *Sent: *Wednesday, October 10, 2012 3:33 PM >>>>>>> *To: *Romascanu, Dan (Dan) >>>>>>> *Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph >>>>>>> Droms; >>>>>>> Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara >>>>>>> *Subject: *Re: Benoit Claise's Discuss on >>>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>>> Dan, >>>>>> >From the description: >>>>>>> - as a columnar object, it is "appropriate" to use DEFVAL >>>>>>> - as a scalar object, it is "permitted" to use DEFVAL. >>>>>>> Sure I know it is permitted for scalar objects, as that will >>>>>>> not >>>>>>> cause a compile error. >>>>>>> For columnar objects, it is actually useful, because a >>>>>>> manager may >>>>>>> create an instance without specifying a columnar object. So >>>>>>> it is >>>>>>> syntactically and practically useful to do so in such cases, >>>>>>> because the agent can deduce the missing value from the MIB >>>>>>> syntax. It makes the protocol more efficient. I know this is >>>>>>> why >>>>>>> we added DEFVAL, based on my interaction at the time with the >>>>>>> original SNMP authors (Jeff Case, et al). >>>>>>> My point is that not only is specifying DEFVAL for a scalar >>>>>>> useless from an SNMP syntactical point of view - because an >>>>>>> agent >>>>>>> cannot actually use it, other than an implementor reading >>>>>>> the RFC >>>>>>> text - but it is actually dangerous to do so. An implementor >>>>>>> TRILL >>>>>>> should be looking to the protocol specification (RFC6325 in >>>>>>> this >>>>>>> case) to determine how the protocol works and what the needed >>>>>>> defaults are. >>>>>>> We don't to define defaults in two different RFCs if we can >>>>>>> help it. >>>>>>> If the protocol decides to change a default, we shouldn't >>>>>>> have to >>>>>>> go update the MIB. >>>>>>> Regards, >>>>>>> Anil >>>>>>> On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Anil, >>>>>>> I believe that you are wrong stating that DEFVAL clauses should >>>>>>> not be present in the definitions of scalar objects, or at >>>>>>> least I >>>>>>> could not find such a recommendations in the RFCs that >>>>>>> define the >>>>>>> SMI. On the contrary, RFC 2578, section 7.9 says: >>>>>>> Note that with this definition of the DEFVAL clause, it is >>>>>>> appropriate to use it for any columnar object of a >>>>>>> read-create table. >>>>>>> It is also permitted to use it for scalar objects >>>>>>> dynamically created >>>>>>> by an agent, or for columnar objects of a read-write table >>>>>>> dynamically created by an agent. >>>>>>> So when an agent is initialized it is good practice to define >>>>>>> default values for writeable objects (scalar or columnar) >>>>>>> unless >>>>>>> we do not care what value the agent starts operating with. >>>>>>> Regards, >>>>>>> Dan >>>>>>> *From: * Anil R [ _mailto:anil@charter.net_ >>>>>>> ] >>>>>>> >>>>>>> *Sent: * Wednesday, October 10, 2012 2:40 PM >>>>>>> *To: * Benoit Claise >>>>>>> *Cc: * Donald Eastlake; Erik Nordmark; Ralph Droms; Bert >>>>>>> Wijnen >>>>>>> (IETF); _zebrose@alum.mit.edu_ >>>>>>> >>>>>>> ; >>>>>>> Romascanu, Dan (Dan); Joan Cucchiara >>>>>>> *Subject: * Re: Benoit Claise's Discuss on >>>>>>> draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT) >>>>>>> Benoit, >>>>>>> I will make a good faith attempt at responding to these >>>>>>> comments >>>>>>> yet again, although I have already responded to many of them >>>>>>> (other than new ones that just showed up in the latest round). >>>>>>> The DEFVAL comment is one which keeps coming back, >>>>>>> disregarding my >>>>>>> many responses that this is not a useful construct for scalar >>>>>>> objects and its chief purpose is to give a default value to >>>>>>> tables >>>>>>> objects missing in the creation of a table instance, as >>>>>>> described >>>>>>> in its definition "The DEFVAL clause, which need not be >>>>>>> present, >>>>>>> defines an acceptable default value which may be used when an >>>>>>> object instance is created." >>>>>>> DEFVAL need not be present even in table objects, but >>>>>>> definitely >>>>>>> should not be present in scalar objects - but the latter is >>>>>>> what >>>>>>> several of these comments are insisting upon. It is the >>>>>>> protocol >>>>>>> specification that defines default values for protocol objects, >>>>>>> not MIBs. >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>>> MIB-DOCTORS mailing list >>>>>> MIB-DOCTORS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>> >>>>> >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>> >>> >> >> > --------------030700030702030800030705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Tom,


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, October 11, 2012 11:27 AM
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object

On 11/10/2012 17:17, Bert Wijnen (IETF) wrote:
That sounds very plausible Joan.
So if it IS the case that it defined in the protocol spec
then WHY the heck is Anil pushing back so much.
After all, it is quite simple/easy to add a DEFVAL line.
The time spent arguing is a bigger than just editing the DEFVAL.
On top of that, Anil wrote:
> By the way I have included a REFERENCE clause in most objects, guiding an implementor to the section of the protocol RFC where he can find more information about the object and its default, if applicable.

If the RFC is now obsolete, the REFERENCE points to an obsoleted reference...

If the RFC in question is obsolete, then what protocol(s) is/are the MIB managing?!
Point taken ;-)
I was more thinking about the second maturity level fro, RFC6410

Regards, Benoit

--Tom



Regards, Benoit.
Bert


On 10/11/12 5:02 PM, Joan Cucchiara wrote:

For THIS specific review most scalars (one exception is rbridgeBaseTrillVersion) have
DEFVALs specified in the protocol (RFC6325).   Not
all protocol specifications do specify default values as clearly as this specification does. When default values are specified in
the protocol (RFC) as is mostly the
situation being discussed here with the scalars, I think DEFVALs SHOULD be put
into the MIB.   I would like to say MUST, but believe Bert and Juergen have
pointed out that there is precedence to flexible on this.

Please note, however, if these DEFVALs which have been specified by the RFC6325 were
in the MIB, they could be interpreted/compiled by tools which process MIBs
and this reduces error and assists in promoting interoperability.   All in all, better for
the MIB's deployment and better for the WG to promote the protocol.

Thanks,
  -Joan

----- Original Message ----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: "Benoit Claise" <bclaise@cisco.com>; "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Sent: Thursday, October 11, 2012 7:35 AM
Subject: Re: [MIB-DOCTORS] DEVAL for scalar object


Agree.
I consider it a nice to have for scalars, but we have
approved quite a few MIB modules that did not have it
for (all) scalars. So we betterbe a bit flexible on
this point. We can recommend that they do it where it
makes sense. I would not hold up a MIB module for too
long if they resist/reject (certainly if they have
good arguments).

Bert

On 10/11/12 1:13 PM, Juergen Schoenwaelder wrote:
Hi,

I think the issue boils down to the question whether the scalars are
dynamically created by an agent or not. e.e., they come into existance
as a side effect of setting some other object. In such situations,
DEFVALs are useful to document which value a management system may
expect to be held in the newly established scalar (but note also that
the DEFVAL clause is not binding; the value is used "at the discretion
of an agent when an object instance is created" - a conservative
management application will thus check the value anyway if it is
important).

/js

On Thu, Oct 11, 2012 at 11:26:41AM +0200, Benoit Claise wrote:
MIB doctors,

Joan did the review of draft-ietf-trill-rbridge-mib.Thanks for your
numerous review of this MIB, which I fully support.

Now, we received some push back from Anil, the author, on the
required DEFVAL for scalar.
As I wrote below, I always considered the DEFVAL for scalar to be
useful information, but I understand both arguments.
Read the email exchange below.

Which advice do we want to give in the future on this topic?

I'm in favor of telling:
- DEFVAL for scalar objects are nice-to-have, and it's good practice
to have them
     This is in line with

    RFC 2578, section 7.9 says:
        Note that with this definition of the DEFVAL clause, it is
        appropriate to use it for any columnar object of a read-create
    table.
        It is also permitted to use it for scalar objects dynamically
    created
        by an agent, or for columnar objects of a read-write table
        dynamically created by an agent.

- If you don't put DEFVAL for scalar objects, then insert in the
description a pointer on where to find the information

Regards, Benoit.




-------- Original Message --------
Subject: Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Date: Thu, 11 Oct 2012 11:11:30 +0200
From: Benoit Claise <bclaise@cisco.com>
To: Anil Rijhsinghani <anil@charter.net>
CC: Romascanu, Dan (Dan) <dromasca@avaya.com>, Donald Eastlake
<d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>, Ralph Droms
<rdroms.ietf@gmail.com>, Bert Wijnen (IETF) <bertietf@bwijnen.net>,
zebrose@alum.mit.edu, Joan Cucchiara <jcucchiara@mindspring.com>, me
<bclaise@cisco.com>



Anil, Dan,

I understand both arguments for and against DEFVAL for scalar.

I've been in favor of DEFVAL for scalar, and considered it a nice-to-have.

1. If you are the implementor, you must know the spec by heart, and
obviously, these scalar DEFVAL's are not useful to you.
2. If you are the SNMP agent, it's true that the SNMPset contains
the value to be set, so you don't need the DEFVAL.
3. If you are the network operator using the NMS GUI , it's pretty
useful information to have default values. It's pretty nice when a
NMS GUI contains the DEVAL value. Sure you can tell that, by looking
at the specifications, someone will be able to get this value. In
practice, is it done? So if the GUI developers could directly get
the information from the DEFVAL, that's a plus.
I've seen to many GUIs where the first config page allows to enter
almost anything. And the network operator just puts random values in
there. In the world of NetFlow, inserting non-sense timeout values
produced some funny results.
4. If you are none of the above... Once upon a time, I was a NMS
customer support engineer, and I read many MIB modules.
And the DEFVAL always helped getting the default values. If nothing
else, for troubleshooting.
And no, I didn't know (and didn't want to know) all the protocol
specification details of the feature/protocol to be managed.

You see, there are multiple actors dealing with MIB modules.

How to more forward?
By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.
That's good information already, and I could leave with that. It's
actually just a (*) level of indirection

(*) time consuming if I take the case 4 above, i.e. my customer
support engineer.

I want to publicly thanks Joan for the time spent on her review.
Much appreciated.
Now, I would like to have some consistency from the MIB doctors in
terms of guidelines on this topic. Let me discuss with them.


Regards, Benoit.

Dan,

An SNMP set operation is used to change the value of a read-write
object, or to create a new row in a table. There is a distinct
difference between the applicability of DEFVAL in these two cases,
hence the "appropriate" versus "permitted" language in the
definition of the DEFVAL clause for these two cases.

When a set operation is performed on a scalar object, it comes
with a value to write into it. The SNMP agent need not guess what
that value might be,  nor does it need to rely on the MIB to tell
it what to do.

When a set operation is performed to create a new row in a table,
it may specify the value of one or more columns in that row. If
the SNMP agent is going to create a row, and not all column
objects have been specified, it is left with a dilemma: what
should it set as the values of those column objects? This is what
the DEFVAL clause allows you to do: give the agent a default value
for unspecified column objects. Such a dilemma does not occur for
setting of scalar objects.

If what you were saying is true, then every read-write object in
every MIB would need a DEFVAL clause. Clearly that is not the
case.

By the way I have included a REFERENCE clause in most objects,
guiding an implementor to the section of the protocol RFC where he
can find more information about the object and its default, if
applicable.

If this doesn't convince you, we will have to agree to disagree on this.

Regards,
Anil


On Wed, Oct 10, 2012 at 9:41 AM, Romascanu, Dan (Dan) wrote:

Hi Anil,
I need to disagree with you on this. The DEFVAL function is the
same for a scalar and for a columnar object – as you well put it
‘the agent can deduce the missing value from the MIB syntax’.
I do not understand your argument that the implementor should look
at the protocol specifications to in the case of scalar objects.
We are talking about writeable objects. Whatever the agent
initializes with will be sent to the instrumentation. In the
absence of a DEFVAL value anything can be written there. The same
as in the case of a columnar object the DEFVAL will indicate the
value the agent initializes with which will be the first value to
be sent to the instrumentation until a setRequest command changes
it. Why should the agent implementor need to look in the protocol
specifications and not help him defining DEFVAL clauses?
Regards,
Dan
*From: *Anil R [mailto:anil@charter.net]
*Sent: *Wednesday, October 10, 2012 3:33 PM
*To: *Romascanu, Dan (Dan)
*Cc: *Benoit Claise; Donald Eastlake; Erik Nordmark; Ralph Droms;
Bert Wijnen (IETF); zebrose@alum.mit.edu; Joan Cucchiara
*Subject: *Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Dan,
>From the description:
- as a columnar object, it is "appropriate" to use DEFVAL
- as a scalar object, it is "permitted" to use DEFVAL.
Sure I know it is permitted for scalar objects, as that will not
cause a compile error.
For columnar objects, it is actually useful, because a manager may
create an instance without specifying a columnar object. So it is
syntactically and practically useful to do so in such cases,
because the agent can deduce the missing value from the MIB
syntax. It makes the protocol more efficient. I know this is why
we added DEFVAL, based on my interaction at the time with the
original SNMP authors (Jeff Case, et al).
My point is that not only is specifying DEFVAL for a scalar
useless from an SNMP syntactical point of view - because an agent
cannot actually use it, other than an implementor reading the RFC
text - but it is actually dangerous to do so. An implementor TRILL
should be looking to the protocol specification (RFC6325 in this
case) to determine how the protocol works and what the needed
defaults are.
We don't to define defaults in two different RFCs if we can help it.
If the protocol decides to change a default, we shouldn't have to
go update the MIB.
Regards,
Anil
On Oct 10, 2012, at 8:59 AM, Romascanu, Dan (Dan) wrote:



Hi Anil,
I believe that you are wrong stating that DEFVAL clauses should
not be present in the definitions of scalar objects, or at least I
could not find such a recommendations in the RFCs that define the
SMI. On the contrary, RFC 2578, section 7.9 says:
   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.
So when an agent is initialized it is good practice to define
default values for writeable objects (scalar or columnar) unless
we do not care what value the agent starts operating with.
Regards,
Dan
*From: *  Anil R [ _mailto:anil@charter.net_
<javascript:parent.wgMail.openComposeWindow('anil@charter.net')>]
*Sent: * Wednesday, October 10, 2012 2:40 PM
*To: *  Benoit Claise
*Cc: *  Donald Eastlake; Erik Nordmark; Ralph Droms; Bert Wijnen
(IETF); _zebrose@alum.mit.edu_ <javascript:parent.wgMail.openComposeWindow('zebrose@alum.mit.edu')>;
Romascanu, Dan (Dan); Joan Cucchiara
*Subject: * Re: Benoit Claise's Discuss on
draft-ietf-trill-rbridge-mib-09: (with DISCUSS and COMMENT)
Benoit,
I will make a good faith attempt at responding to these comments
yet again, although I have already responded to many of them
(other than new ones that just showed up in the latest round).
The DEFVAL comment is one which keeps coming back, disregarding my
many responses that this is not a useful construct for scalar
objects and its chief purpose is to give a default value to tables
objects missing in the creation of a table instance, as described
in its definition "The DEFVAL clause, which need not be present,
defines an acceptable default value which may be used when an
object instance is created."
DEFVAL need not be present even in table objects, but definitely
should not be present in scalar objects - but the latter is what
several of these comments are insisting upon. It is the protocol
specification that defines default values for protocol objects,
not MIBs.
Regards,
Anil



_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


--------------030700030702030800030705-- From bclaise@cisco.com Fri Oct 19 06:21:33 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC921F868A; Fri, 19 Oct 2012 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmtBO0phhMgw; Fri, 19 Oct 2012 06:21:30 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id CC6DD21F8686; Fri, 19 Oct 2012 06:21:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JDLTPv017842; Fri, 19 Oct 2012 09:21:30 -0400 (EDT) Received: from [10.21.166.15] ([10.21.166.15]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JDLSJJ022757; Fri, 19 Oct 2012 09:21:29 -0400 (EDT) Message-ID: <508153D9.6020705@cisco.com> Date: Fri, 19 Oct 2012 06:21:29 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> In-Reply-To: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: PRELIMINARY Agenda and Package for the October 25, 2012 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:21:33 -0000 Dear all, Please find below the agenda of the October25th IESG telechat. Please send your questions, comments and concerns before October 24th COB. Regards, Benoit -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ccamp-rfc5787bis-06 ASON Routing for OSPFv2 Protocols (Proposed Standard) Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-ccamp-gmpls-ted-mib-14 Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS (Proposed Standard) Note: Lou Berger (lberger@labn.net) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-appsawg-media-type-suffix-regs-06 Additional Media Type Structured Syntax Suffixes (Proposed Standard) Note: Murray Kucherawy is the document shepherd. Token: Barry Leiba o draft-ietf-pkix-rfc5280-clarifications-10 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Proposed Standard) Note: Steve Kent (kent@bbn.com) is the Document Shepherd Token: Sean Turner o draft-ietf-dhc-client-id-06 Client Identifier Option in DHCP Server Replies (Proposed Standard) Note: Ted Lemon (Ted.Lemon@nominum.com) is the Document Shepherd. Token: Ralph Droms o draft-ietf-geopriv-local-civic-09 Specifying Civic Address Extensions in PIDF-LO (Proposed Standard) Note: Alissa Cooper (acooper@cdt.org) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-snell-http-prefer-15 Prefer Header for HTTP (Proposed Standard) Note: Mark Nottingham is the document shepherd. Token: Barry Leiba o draft-gp-intarea-obsolete-ipv4-options-iana-02 Formally Deprecating some IPv4 Options (Proposed Standard) Note: Scott Bradner (sob@harvard.edu) is the document shepherd. Token: Ronald Bonica 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-softwire-dslite-deployment-06 Deployment Considerations for Dual-Stack Lite (Informational) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd. Token: Ralph Droms o draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions (Informational) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd. Token: Ralph Droms 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-secure-cookie-session-protocol-00 IETF conflict review for draft-secure-cookie-session-protocol (None) Token: Barry Leiba 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Bidirectional Forwarding Detection (bfd) From bclaise@cisco.com Fri Oct 19 14:08:51 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4638C21F8753 for ; Fri, 19 Oct 2012 14:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[AWL=3.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMemOZhsKMSM for ; Fri, 19 Oct 2012 14:08:50 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6A21F8742 for ; Fri, 19 Oct 2012 14:08:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JL8k7j028103; Fri, 19 Oct 2012 14:08:46 -0700 (PDT) Received: from [10.154.36.157] ([10.154.36.157]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JL8kQ3025086; Fri, 19 Oct 2012 14:08:46 -0700 (PDT) Message-ID: <5081C15E.7010209@cisco.com> Date: Fri, 19 Oct 2012 14:08:46 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel Subject: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:08:51 -0000 Dear all, Did one MIB doctor review this MIB module? Except Tom obviously ;-) Tom, based on your MIB doctor experience, any controversial points in the MIB module? Regards, Benoit. From tnadeau@juniper.net Fri Oct 19 14:12:41 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9E21F8753 for ; Fri, 19 Oct 2012 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n15s+ZkWzlvm for ; Fri, 19 Oct 2012 14:12:41 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BE10621F8748 for ; Fri, 19 Oct 2012 14:12:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUIHCRswe6bA3ppRdgyYHYLO7wON83j2x@postini.com; Fri, 19 Oct 2012 14:12:40 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 19 Oct 2012 14:10:09 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 19 Oct 2012 14:10:08 -0700 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Oct 2012 14:12:27 -0700 Received: from mail39-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 19 Oct 2012 21:10:06 +0000 Received: from mail39-db3 (localhost [127.0.0.1]) by mail39-db3-R.bigfish.com (Postfix) with ESMTP id 1BBE31801D9 for ; Fri, 19 Oct 2012 21:10:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1155h) Received: from mail39-db3 (localhost.localdomain [127.0.0.1]) by mail39-db3 (MessageSwitch) id 1350681003961999_24028; Fri, 19 Oct 2012 21:10:03 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.253]) by mail39-db3.bigfish.com (Postfix) with ESMTP id E8C7D4E008B; Fri, 19 Oct 2012 21:10:03 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Oct 2012 21:10:03 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.188]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0224.004; Fri, 19 Oct 2012 21:10:02 +0000 From: Thomas Nadeau To: Benoit Claise , "MIB Doctors (E-mail)" Thread-Topic: draft-ietf-ccamp-gmpls-ted-mib-14 review Thread-Index: AQHNrj32pdw2QKuKCEOFO3Amm/PfRpfA3KgA Date: Fri, 19 Oct 2012 21:10:02 +0000 Message-ID: In-Reply-To: <5081C15E.7010209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:12:41 -0000 Can I recuse myself? *) On 10/19/12 5:08 PM, "Benoit Claise" wrote: >Dear all, > >Did one MIB doctor review this MIB module? Except Tom obviously ;-) >Tom, based on your MIB doctor experience, any controversial points in >the MIB module? > >Regards, Benoit. > From bclaise@cisco.com Fri Oct 19 14:13:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E921F8753 for ; Fri, 19 Oct 2012 14:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[AWL=3.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMx5crhCe+UZ for ; Fri, 19 Oct 2012 14:13:05 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id E665B21F8748 for ; Fri, 19 Oct 2012 14:13:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JLD5YH028529; Fri, 19 Oct 2012 14:13:05 -0700 (PDT) Received: from [10.154.36.157] ([10.154.36.157]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JLD5a3005175; Fri, 19 Oct 2012 14:13:05 -0700 (PDT) Message-ID: <5081C261.4020008@cisco.com> Date: Fri, 19 Oct 2012 14:13:05 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Thomas Nadeau References: <5081C15E.7010209@cisco.com> In-Reply-To: <5081C15E.7010209@cisco.com> Content-Type: multipart/alternative; boundary="------------050300010103070108030302" Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:13:06 -0000 This is a multi-part message in MIME format. --------------050300010103070108030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Dear all, > > Did one MIB doctor review this MIB module? Except Tom obviously ;-) Answering my own question, thanks Dan for the MIB doctor review _on the top of the OPS-DIR review_. Regards, Benoit Reminder for Benoit: next time, look first in your OPS-DIR folder before sending emails! > Tom, based on your MIB doctor experience, any controversial points in > the MIB module? > > Regards, Benoit. --------------050300010103070108030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear all,

Did one MIB doctor review this MIB module? Except Tom obviously ;-)
Answering my own question, thanks Dan for the MIB doctor review on the top of the OPS-DIR review.

Regards, Benoit
Reminder for Benoit: next time, look first in your OPS-DIR folder before sending emails!


Tom, based on your MIB doctor experience, any controversial points in the MIB module?

Regards, Benoit.

--------------050300010103070108030302-- From dromasca@avaya.com Fri Oct 19 14:38:05 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877E21F87DD for ; Fri, 19 Oct 2012 14:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.348 X-Spam-Level: X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HFzmCAJy7sI for ; Fri, 19 Oct 2012 14:38:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id CC67921F87DA for ; Fri, 19 Oct 2012 14:38:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgKAHvHgVDGmAcF/2dsb2JhbABFuTyHOoEIgiABAQEBAgESChEDSQUHBAIBCAQBCAEDBAEBCwYMDAYBTggBAQQBEggah1wGnyOdF4taGoV1YAOIJZNQijKCcYFh X-IronPort-AV: E=Sophos;i="4.80,617,1344225600"; d="scan'208,217";a="329384017" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Oct 2012 17:31:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Oct 2012 17:28:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDAE41.FD49EE60" Date: Fri, 19 Oct 2012 23:35:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review Thread-Index: Ac2uPoyQXrUwmLFpR9etmdHR3EofrAAAyu7L References: <5081C15E.7010209@cisco.com> <5081C261.4020008@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , "MIB Doctors (E-mail)" , "Thomas Nadeau" Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:38:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDAE41.FD49EE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit,=20 Actually my review was not a full MIB Doctor review, but an OPS-DIR = review. I checked compilation (using smilib) but not much more.=20 Regards, Dan -----Original Message----- From: mib-doctors-bounces@ietf.org on behalf of Benoit Claise Sent: Fri 10/19/2012 11:13 PM To: MIB Doctors (E-mail); Thomas Nadeau Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review =20 > Dear all, > > Did one MIB doctor review this MIB module? Except Tom obviously ;-) Answering my own question, thanks Dan for the MIB doctor review _on the=20 top of the OPS-DIR review_. Regards, Benoit Reminder for Benoit: next time, look first in your OPS-DIR folder before = sending emails! > Tom, based on your MIB doctor experience, any controversial points in=20 > the MIB module? > > Regards, Benoit. ------_=_NextPart_001_01CDAE41.FD49EE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 = review

Hi Benoit,

Actually my review was not a full MIB Doctor review, but an OPS-DIR = review. I checked compilation (using smilib) but not much more.

Regards,

Dan



-----Original Message-----
From: mib-doctors-bounces@ietf.org on behalf of Benoit Claise
Sent: Fri 10/19/2012 11:13 PM
To: MIB Doctors (E-mail); Thomas Nadeau
Cc: Adrian Farrel
Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review


> Dear all,
>
> Did one MIB doctor review this MIB module? Except Tom obviously = ;-)
Answering my own question, thanks Dan for the MIB doctor review _on = the
top of the OPS-DIR review_.

Regards, Benoit
Reminder for Benoit: next time, look first in your OPS-DIR folder = before
sending emails!


> Tom, based on your MIB doctor experience, any controversial points = in
> the MIB module?
>
> Regards, Benoit.

------_=_NextPart_001_01CDAE41.FD49EE60-- From adrian@olddog.co.uk Sat Oct 20 04:27:51 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272A921F8585 for ; Sat, 20 Oct 2012 04:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXuLZeisEDJB for ; Sat, 20 Oct 2012 04:27:50 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id B39F521F8562 for ; Sat, 20 Oct 2012 04:27:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9KBRift022265; Sat, 20 Oct 2012 12:27:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9KBRhob022251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 12:27:44 +0100 From: "Adrian Farrel" To: "'Benoit Claise'" , "'MIB Doctors \(E-mail\)'" , "'Thomas Nadeau'" References: <5081C15E.7010209@cisco.com> In-Reply-To: <5081C15E.7010209@cisco.com> Date: Sat, 20 Oct 2012 12:27:46 +0100 Message-ID: <0b3201cdaeb5$ee7067b0$cb513710$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF5c2vQs4+2mcZcPqyoGwtYM9MrL5hqgyXg Content-Language: en-gb Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 11:27:51 -0000 Hello, The Ballot write-up says Implementation status is unknown (as is often the case). The document has been through many review cycles, including review by a MIB Doctor and by the AD. Details are on the WG list. Similar text shows in the shepherd write-up. Looking at the CCAMP mail archive, it looks like Joan did the review. Cheers, Adrian > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: 19 October 2012 22:09 > To: MIB Doctors (E-mail); Thomas Nadeau > Cc: Adrian Farrel > Subject: draft-ietf-ccamp-gmpls-ted-mib-14 review > > Dear all, > > Did one MIB doctor review this MIB module? Except Tom obviously ;-) > Tom, based on your MIB doctor experience, any controversial points in > the MIB module? > > Regards, Benoit. From jcucchiara@mindspring.com Mon Oct 22 13:30:28 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0431321F8443 for ; Mon, 22 Oct 2012 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTlpG5bfTz2H for ; Mon, 22 Oct 2012 13:30:27 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1426821F8442 for ; Mon, 22 Oct 2012 13:30:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZbKVaMUFZlGRMEMxEBubtssXoxBEqWPP64mAXSyxS9Navv5HFztCo2qEoQOtn8hg; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TQOdm-0003pd-0Z; Mon, 22 Oct 2012 16:30:26 -0400 Message-ID: <010401cdb094$1106f750$6801a8c0@JoanPC> From: "Joan Cucchiara" To: , "'Benoit Claise'" , "'MIB Doctors \(E-mail\)'" , "'Thomas Nadeau'" References: <5081C15E.7010209@cisco.com> <0b3201cdaeb5$ee7067b0$cb513710$@olddog.co.uk> Date: Mon, 22 Oct 2012 16:30:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654eabd08ccf72c7a921b726824ddf71ee18f1403e8a44865d0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:30:28 -0000 Hello, I did reviews for versions 5, 6 and 7. The comments on version 7 were discussed on the list between the authors and myself. Thanks, -Joan ----- Original Message ----- From: "Adrian Farrel" To: "'Benoit Claise'" ; "'MIB Doctors (E-mail)'" ; "'Thomas Nadeau'" Sent: Saturday, October 20, 2012 7:27 AM Subject: Re: [MIB-DOCTORS] draft-ietf-ccamp-gmpls-ted-mib-14 review > Hello, > > The Ballot write-up says > Implementation status is unknown (as is often the case). > The document has been through many review cycles, > including review by a MIB Doctor and by the AD. Details > are on the WG list. > > Similar text shows in the shepherd write-up. > > Looking at the CCAMP mail archive, it looks like Joan did the review. > > Cheers, > Adrian > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: 19 October 2012 22:09 >> To: MIB Doctors (E-mail); Thomas Nadeau >> Cc: Adrian Farrel >> Subject: draft-ietf-ccamp-gmpls-ted-mib-14 review >> >> Dear all, >> >> Did one MIB doctor review this MIB module? Except Tom obviously ;-) >> Tom, based on your MIB doctor experience, any controversial points in >> the MIB module? >> >> Regards, Benoit. > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Sun Oct 28 18:32:49 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533121F84A6 for ; Sun, 28 Oct 2012 18:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKfkq74FGsMz for ; Sun, 28 Oct 2012 18:32:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C959821F8473 for ; Sun, 28 Oct 2012 18:32:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9T1WkYV028852 for ; Mon, 29 Oct 2012 02:32:46 +0100 (CET) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9T1WjYe012655 for ; Mon, 29 Oct 2012 02:32:45 +0100 (CET) Message-ID: <508DDCBD.8020803@cisco.com> Date: Sun, 28 Oct 2012 20:32:45 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------090900060501000200030709" Subject: [MIB-DOCTORS] Fwd: 10 MIB-DOCTORS moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 01:32:49 -0000 This is a multi-part message in MIME format. --------------090900060501000200030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MIB doctors, There are more and more requests to join the MIB-doctors mailer. And each time, I have to reply that this is a closed mailing list. I haven't found an option in the admin tool to say that this is a closed mailing list (if someone knows about this ...). So I changed the text at https://www.ietf.org/mailman/listinfo/mib-doctors This is a CLOSED MAILING LIST, for MIB DOCTORS at the IETF. You will not be subscribed with the automatic procedure below. Send an email to the the list owner (bclaise@cisco.com), justifying why you should become a MIB DOCTOR first. If the answer is positive, then subscribe to MIB-DOCTORS by filling out the following form. The rest of the text is auto-generated, so I can't change it. Regards, Benoit -------- Original Message -------- Subject: 10 MIB-DOCTORS moderator request(s) waiting Date: Sun, 28 Oct 2012 08:00:10 -0700 From: mib-doctors-bounces@ietf.org To: mib-doctors-owner@ietf.org The MIB-DOCTORS@ietf.org mailing list has 10 request(s) waiting for your consideration at: https://www.ietf.org/mailman/admindb/mib-doctors Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending subscriptions: expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 10:54:38 2012 bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:49:02 2012 mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:04:21 2012 jboyanich@gmail.com (Elizabeth Jenkins) Thu Oct 25 04:50:05 2012 rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:37:15 2012 jboyanich@gmail.com (Ryan Rodriguez) Thu Oct 25 08:04:01 2012 Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:37:16 2012 eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:18:33 2012 randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:11:21 2012 hesed6@aol.com (Zachary Washington) Sat Oct 27 20:05:38 2012 --------------090900060501000200030709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MIB doctors,

There are more and more requests to join the MIB-doctors mailer.
And each time, I have to reply that this is a closed mailing list. I haven't found an option in the admin tool to say that this is a closed mailing list (if someone knows about this ...).
So I changed the text at https://www.ietf.org/mailman/listinfo/mib-doctors
This is a CLOSED MAILING LIST, for MIB DOCTORS at the IETF. You will not be subscribed with the automatic procedure below. Send an email to the the list owner (bclaise@cisco.com), justifying why you should become a MIB DOCTOR first. If the answer is positive, then subscribe to MIB-DOCTORS by filling out the following form.
The rest of the text is auto-generated, so I can't change it.

Regards, Benoit

-------- Original Message --------
Subject: 10 MIB-DOCTORS moderator request(s) waiting
Date: Sun, 28 Oct 2012 08:00:10 -0700
From: mib-doctors-bounces@ietf.org
To: mib-doctors-owner@ietf.org 


The MIB-DOCTORS@ietf.org mailing list has 10 request(s) waiting for
your consideration at:

	https://www.ietf.org/mailman/admindb/mib-doctors
	
Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.

Pending subscriptions:
    expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 10:54:38 2012
    bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:49:02 2012
    mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:04:21 2012
    jboyanich@gmail.com (Elizabeth Jenkins) Thu Oct 25 04:50:05 2012
    rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:37:15 2012
    jboyanich@gmail.com (Ryan Rodriguez) Thu Oct 25 08:04:01 2012
    Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:37:16 2012
    eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:18:33 2012
    randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:11:21 2012
    hesed6@aol.com (Zachary Washington) Sat Oct 27 20:05:38 2012



--------------090900060501000200030709-- From bertietf@bwijnen.net Mon Oct 29 01:15:25 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55221F84FA; Mon, 29 Oct 2012 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5eP9EAqdXyf; Mon, 29 Oct 2012 01:15:23 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63621F84F5; Mon, 29 Oct 2012 01:15:19 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TSkVA-0001cI-SV; Mon, 29 Oct 2012 09:15:18 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest198.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TSkVA-0000xn-G9; Mon, 29 Oct 2012 09:15:16 +0100 Message-ID: <508E3B1D.70200@bwijnen.net> Date: Mon, 29 Oct 2012 09:15:25 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Benoit Claise , YANG Doctors , MIB Doctors References: <508DDD6B.2020700@cisco.com> In-Reply-To: <508DDD6B.2020700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121029 clean X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.5 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0301] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49784559ca51c2349a8f3e00662ab975b Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:15:25 -0000 It is the same list as for the MIB doctors. It is all in a couple of days. I do not recognize any of those people? Does anyone? Just ignore them without msgs?? Bert On 10/29/12 2:35 AM, Benoit Claise wrote: > YANG doctors, > > There are more and more requests to join the YANG-doctors mailer. > And each time, I have to reply that this is a closed mailing list. I haven't found an option in the admin tool to say that this is a > closed mailing list (if someone knows about this ...). > So I changed the text at https://www.ietf.org/mailman/listinfo/yang-doctors > > This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You will not be subscribed with the automatic procedure below. Send > an email to the the list owner (bclaise@cisco.com), justifying why you should become a YANG DOCTOR first. If the answer is > positive, then subscribe to yang-doctors by filling out the following form. > > The rest of the text is auto-generated, so I can't change it. > > Regards, Benoit > > -------- Original Message -------- > Subject: 10 yang-doctors moderator request(s) waiting > Date: Sun, 28 Oct 2012 08:00:09 -0700 > From: yang-doctors-bounces@ietf.org > To: yang-doctors-owner@ietf.org > > > > Theyang-doctors@ietf.org mailing list has 10 request(s) waiting for > your consideration at: > > https://www.ietf.org/mailman/admindb/yang-doctors > > Please attend to this at your earliest convenience. This notice of > pending requests, if any, will be sent out daily. > > Pending subscriptions: > expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 11:08:39 2012 > bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:52:03 2012 > 3475980121@vtext.com (Willie Adams) Wed Oct 24 13:57:59 2012 > mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:07:34 2012 > rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:40:12 2012 > Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:44:06 2012 > bgranat@granatedit.com (Kevin Murphy) Sat Oct 27 09:09:05 2012 > eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:33:15 2012 > randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:14:24 2012 > hesed6@aol.com (Zachary Washington) Sat Oct 27 20:20:31 2012 > > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > From andy@yumaworks.com Mon Oct 29 07:27:57 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A540E21F8526 for ; Mon, 29 Oct 2012 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD0Q2Miu3BtC for ; Mon, 29 Oct 2012 07:27:57 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6799E21F8557 for ; Mon, 29 Oct 2012 07:27:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4259738lam.31 for ; Mon, 29 Oct 2012 07:27:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9PUnHb1w51szRvUSShRyUc7zJU3E9UCowYyhCmPjxHU=; b=NH2X1ijx5PQ1jmNZXXvhtrEf3mImQJU3EVhn6oV3oIOkRD0KTWzVtheX4Bv8pamQEu Hy7r3xMIozT/NqeEMiPCZwCzhMmZpgPyzFCGGqOVFLGZTZW8xxgbf3xGlF8DpejYOjAl l1JCVA4sjcxPpT3BbsDBGu3IUv2DL5YLaTb64pcGpdvBdWUxi1PQ3q8GEBCr2u3Z2+tz ZgkY3S4GnNOhwlvG46rBYRY6mXEefT855eSV6QaxCyK1g+5K/hnjEfZ+HNEF7CnjWw9r j3NBaftsUl8dqLQvlMgVCzsw0ojXuBFxS5dj0J+u23mUSq2V09UuGU/ZeyLRXwNaCr77 A0aQ== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr27555455lab.22.1351520875110; Mon, 29 Oct 2012 07:27:55 -0700 (PDT) Received: by 10.112.36.5 with HTTP; Mon, 29 Oct 2012 07:27:55 -0700 (PDT) In-Reply-To: <508E3B1D.70200@bwijnen.net> References: <508DDD6B.2020700@cisco.com> <508E3B1D.70200@bwijnen.net> Date: Mon, 29 Oct 2012 07:27:55 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=f46d040711c5aae1b104cd337905 X-Gm-Message-State: ALoCoQm+RSe/zkCscVcqTBAvCkSmY7aTyeot3VAKyCC2NGZ4RW8eiFWZClPdyBBn9NzVBclS2iIo Cc: YANG Doctors , MIB Doctors Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:27:57 -0000 --f46d040711c5aae1b104cd337905 Content-Type: text/plain; charset=UTF-8 Notice how none of the names even slightly match their email address? As if a script randomly generated these requests? Andy On Mon, Oct 29, 2012 at 1:15 AM, Bert Wijnen (IETF) wrote: > It is the same list as for the MIB doctors. > It is all in a couple of days. > I do not recognize any of those people? > Does anyone? > > Just ignore them without msgs?? > > Bert > > On 10/29/12 2:35 AM, Benoit Claise wrote: > >> YANG doctors, >> >> There are more and more requests to join the YANG-doctors mailer. >> And each time, I have to reply that this is a closed mailing list. I >> haven't found an option in the admin tool to say that this is a >> closed mailing list (if someone knows about this ...). >> So I changed the text at https://www.ietf.org/mailman/** >> listinfo/yang-doctors >> >> This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You will >> not be subscribed with the automatic procedure below. Send >> an email to the the list owner (bclaise@cisco.com), justifying why >> you should become a YANG DOCTOR first. If the answer is >> positive, then subscribe to yang-doctors by filling out the following >> form. >> >> The rest of the text is auto-generated, so I can't change it. >> >> Regards, Benoit >> >> -------- Original Message -------- >> Subject: 10 yang-doctors moderator request(s) waiting >> Date: Sun, 28 Oct 2012 08:00:09 -0700 >> From: yang-doctors-bounces@ietf.org >> To: yang-doctors-owner@ietf.org >> >> >> >> Theyang-doctors@ietf.org mailing list has 10 request(s) waiting for >> your consideration at: >> >> https://www.ietf.org/mailman/**admindb/yang-doctors >> >> Please attend to this at your earliest convenience. This notice of >> pending requests, if any, will be sent out daily. >> >> Pending subscriptions: >> expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 11:08:39 2012 >> bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:52:03 2012 >> 3475980121@vtext.com (Willie Adams) Wed Oct 24 13:57:59 2012 >> mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:07:34 2012 >> rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:40:12 2012 >> Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:44:06 >> 2012 >> bgranat@granatedit.com (Kevin Murphy) Sat Oct 27 09:09:05 2012 >> eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:33:15 >> 2012 >> randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:14:24 2012 >> hesed6@aol.com (Zachary Washington) Sat Oct 27 20:20:31 2012 >> >> >> >> >> >> >> >> ______________________________**_________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/**listinfo/yang-doctors >> >> ______________________________**_________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/**listinfo/mib-doctors > --f46d040711c5aae1b104cd337905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Notice how none of the names even slightly match their email address?
A= s if a script randomly generated these requests?

<= br>
Andy


On Mon, Oct= 29, 2012 at 1:15 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net><= /span> wrote:
It is the same list as for the MIB doctors.<= br> It is all in a couple of days.
I do not recognize any of those people?
Does anyone?

Just ignore them without msgs??

Bert

On 10/29/12 2:35 AM, Benoit Claise wrote:
YANG doctors,

There are more and more requests to join the YANG-doctors mailer.
And each time, I have to reply that this is a closed mailing list. I haven&= #39;t found an option in the admin tool to say that this is a
closed mailing list (if someone knows about this ...).
So I changed the text at https://www.ietf.org/mailman/listinfo= /yang-doctors

=C2=A0 =C2=A0 This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. = You will not be subscribed with the automatic procedure below. Send
=C2=A0 =C2=A0 an email to the the list owner (bclaise@cisco.com), justifying why you should= become a YANG DOCTOR first. If the answer is
=C2=A0 =C2=A0 positive, then subscribe to yang-doctors by filling out the f= ollowing form.

The rest of the text is auto-generated, so I can't change it.

Regards, Benoit

-------- Original Message --------
Subject: =C2=A0 =C2=A0 =C2=A0 =C2=A010 yang-doctors moderator request(s) wa= iting
Date: =C2=A0 Sun, 28 Oct 2012 08:00:09 -0700
From: =C2=A0 yang-doctors-bounces@ietf.org
To: =C2=A0 =C2=A0 yang-doctors-owner@ietf.org



Theyang-docto= rs@ietf.org =C2=A0mailing list has 10 request(s) waiting for
your consideration at:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/admind= b/yang-doctors
=C2=A0 =C2=A0 =C2=A0 =C2=A0
Please attend to this at your earliest convenience. =C2=A0This notice of pending requests, if any, will be sent out daily.

Pending subscriptions:
=C2=A0 =C2=A0 =C2=A0expdweddingpaper@gmail.com =C2=A0(Edward Miller) Tue Oct 23 11= :08:39 2012
=C2=A0 =C2=A0 =C2=A0= bangdiw@yahoo.com =C2=A0(Sarah Anderson) Tue Oct 23 21:52:03 2012
=C2=A0 =C2=A0 =C2=A03475980121@vtext.com =C2=A0(Willie Adams) Wed Oct 24 13:57:59 2012 =C2=A0 =C2=A0 =C2=A0mark.escott@hotmail.com =C2=A0(Linda Diaz) Wed Oct 24 15:07:34 20= 12
=C2=A0 =C2=A0 =C2=A0rowankok@hotmail.com =C2=A0(Rebecca Price) Thu Oct 25 07:40:12 2012<= br> =C2=A0 =C2=A0 =C2=A0Carlotajcepria94@yahoo.com =C2=A0(Gloria Russell) Thu Oct 25 0= 9:44:06 2012
=C2=A0 =C2=A0 =C2=A0bgranat@granatedit.com =C2=A0(Kevin Murphy) Sat Oct 27 09:09:05 20= 12
=C2=A0 =C2=A0 =C2=A0eveleenkalkof028c0@yahoo.com =C2=A0(Johnny Wright) Sat Oct = 27 14:33:15 2012
=C2=A0 =C2=A0 =C2=A0randy_45@rocketmail.com =C2=A0(Kathleen Hughes) Sat Oct 27 17:14:= 24 2012
=C2=A0 =C2=A0 =C2=A0hes= ed6@aol.com =C2=A0(Zachary Washington) Sat Oct 27 20:20:31 2012







_______________________________________________
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-doctors

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.= org
https://www.ietf.org/mailman/listinfo/mib-doctors

--f46d040711c5aae1b104cd337905-- From bclaise@cisco.com Mon Oct 29 07:42:57 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09DC21F84B2; Mon, 29 Oct 2012 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6evy-nk1Tuvt; Mon, 29 Oct 2012 07:42:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B86BA21F84B1; Mon, 29 Oct 2012 07:42:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9TEgs8M023789; Mon, 29 Oct 2012 15:42:55 +0100 (CET) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9TEgsPH013644; Mon, 29 Oct 2012 15:42:54 +0100 (CET) Message-ID: <508E95EE.7030900@cisco.com> Date: Mon, 29 Oct 2012 15:42:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andy Bierman References: <508DDD6B.2020700@cisco.com> <508E3B1D.70200@bwijnen.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090505080200000502010301" Cc: YANG Doctors , MIB Doctors Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:42:58 -0000 This is a multi-part message in MIME format. --------------090505080200000502010301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andy, > Notice how none of the names even slightly match their email address? I noticed that as well. > As if a script randomly generated these requests? Is this the way spam works these days? Regards, Benoit > > > Andy > > > On Mon, Oct 29, 2012 at 1:15 AM, Bert Wijnen (IETF) > > wrote: > > It is the same list as for the MIB doctors. > It is all in a couple of days. > I do not recognize any of those people? > Does anyone? > > Just ignore them without msgs?? > > Bert > > On 10/29/12 2:35 AM, Benoit Claise wrote: > > YANG doctors, > > There are more and more requests to join the YANG-doctors mailer. > And each time, I have to reply that this is a closed mailing > list. I haven't found an option in the admin tool to say that > this is a > closed mailing list (if someone knows about this ...). > So I changed the text at > https://www.ietf.org/mailman/listinfo/yang-doctors > > This is a CLOSED MAILING LIST, for YANG DOCTORS at the > IETF. You will not be subscribed with the automatic procedure > below. Send > an email to the the list owner (bclaise@cisco.com > ), justifying why you should become > a YANG DOCTOR first. If the answer is > positive, then subscribe to yang-doctors by filling out > the following form. > > The rest of the text is auto-generated, so I can't change it. > > Regards, Benoit > > -------- Original Message -------- > Subject: 10 yang-doctors moderator request(s) waiting > Date: Sun, 28 Oct 2012 08:00:09 -0700 > From: yang-doctors-bounces@ietf.org > > To: yang-doctors-owner@ietf.org > > > > > Theyang-doctors@ietf.org > mailing list has 10 request(s) waiting for > your consideration at: > > https://www.ietf.org/mailman/admindb/yang-doctors > > Please attend to this at your earliest convenience. This > notice of > pending requests, if any, will be sent out daily. > > Pending subscriptions: > expdweddingpaper@gmail.com > (Edward Miller) Tue Oct 23 11:08:39 2012 > bangdiw@yahoo.com (Sarah Anderson) > Tue Oct 23 21:52:03 2012 > 3475980121@vtext.com (Willie > Adams) Wed Oct 24 13:57:59 2012 > mark.escott@hotmail.com > (Linda Diaz) Wed Oct 24 15:07:34 2012 > rowankok@hotmail.com (Rebecca > Price) Thu Oct 25 07:40:12 2012 > Carlotajcepria94@yahoo.com > (Gloria Russell) Thu Oct 25 09:44:06 2012 > bgranat@granatedit.com (Kevin > Murphy) Sat Oct 27 09:09:05 2012 > eveleenkalkof028c0@yahoo.com > (Johnny Wright) Sat Oct > 27 14:33:15 2012 > randy_45@rocketmail.com > (Kathleen Hughes) Sat Oct 27 17:14:24 2012 > hesed6@aol.com (Zachary Washington) > Sat Oct 27 20:20:31 2012 > > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > --------------090505080200000502010301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Andy,
Notice how none of the names even slightly match their email address?
I noticed that as well.
As if a script randomly generated these requests?
Is this the way spam works these days?

Regards, Benoit


Andy


On Mon, Oct 29, 2012 at 1:15 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:
It is the same list as for the MIB doctors.
It is all in a couple of days.
I do not recognize any of those people?
Does anyone?

Just ignore them without msgs??

Bert

On 10/29/12 2:35 AM, Benoit Claise wrote:
YANG doctors,

There are more and more requests to join the YANG-doctors mailer.
And each time, I have to reply that this is a closed mailing list. I haven't found an option in the admin tool to say that this is a
closed mailing list (if someone knows about this ...).
So I changed the text at https://www.ietf.org/mailman/listinfo/yang-doctors

    This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You will not be subscribed with the automatic procedure below. Send
    an email to the the list owner (bclaise@cisco.com), justifying why you should become a YANG DOCTOR first. If the answer is
    positive, then subscribe to yang-doctors by filling out the following form.

The rest of the text is auto-generated, so I can't change it.

Regards, Benoit

-------- Original Message --------
Subject:        10 yang-doctors moderator request(s) waiting
Date:   Sun, 28 Oct 2012 08:00:09 -0700
From:   yang-doctors-bounces@ietf.org
To:     yang-doctors-owner@ietf.org



Theyang-doctors@ietf.org  mailing list has 10 request(s) waiting for
your consideration at:

        https://www.ietf.org/mailman/admindb/yang-doctors
       
Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.

Pending subscriptions:
     expdweddingpaper@gmail.com  (Edward Miller) Tue Oct 23 11:08:39 2012
     bangdiw@yahoo.com  (Sarah Anderson) Tue Oct 23 21:52:03 2012
     3475980121@vtext.com  (Willie Adams) Wed Oct 24 13:57:59 2012
     mark.escott@hotmail.com  (Linda Diaz) Wed Oct 24 15:07:34 2012
     rowankok@hotmail.com  (Rebecca Price) Thu Oct 25 07:40:12 2012
     Carlotajcepria94@yahoo.com  (Gloria Russell) Thu Oct 25 09:44:06 2012
     bgranat@granatedit.com  (Kevin Murphy) Sat Oct 27 09:09:05 2012
     eveleenkalkof028c0@yahoo.com  (Johnny Wright) Sat Oct 27 14:33:15 2012
     randy_45@rocketmail.com  (Kathleen Hughes) Sat Oct 27 17:14:24 2012
     hesed6@aol.com  (Zachary Washington) Sat Oct 27 20:20:31 2012







_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


--------------090505080200000502010301-- From andy@yumaworks.com Mon Oct 29 07:50:33 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB421F8709 for ; Mon, 29 Oct 2012 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvhe15D1Oeue for ; Mon, 29 Oct 2012 07:50:32 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1750821F8661 for ; Mon, 29 Oct 2012 07:50:31 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4279234lam.31 for ; Mon, 29 Oct 2012 07:50:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8C2+ZtYgxmJNH8uwMk//cOUxnvIsKZsFr2HlF+1uCqk=; b=f7NdRTIoYGBs9RETHLZKQAoprOc2qzNUGAXjX/txy6us6K2BYrj6PeKZurwGKCFvB0 TMDXQ8JEWDu2XpCnMolidY0ne2zneCPAnhuMknPjFpLnHEutM1yuY7naSftR0A8n+Qnn EyPrCLX+wo2wg5qTFiBgcSyaHcTKzvK9ZuFZmhI4xrhvk5fDo7OqpgNonYHe7V8rnu1u CbBbHu7ku8Zhhxplk/LddHV4C0S8XlfHQ0bjthSr9/Fd09UZJcGbkFoJBqkQ4fYiCF+l JDorIERXNne3nSt4spCwwppKMf/2Y743aDGvZ2sWUVnwdHASCcBUUFfzagnnxmwCfjvl gwng== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr27512855lab.30.1351522231026; Mon, 29 Oct 2012 07:50:31 -0700 (PDT) Received: by 10.112.36.5 with HTTP; Mon, 29 Oct 2012 07:50:30 -0700 (PDT) In-Reply-To: <508E95EE.7030900@cisco.com> References: <508DDD6B.2020700@cisco.com> <508E3B1D.70200@bwijnen.net> <508E95EE.7030900@cisco.com> Date: Mon, 29 Oct 2012 07:50:30 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=e89a8f2346657c860404cd33ca98 X-Gm-Message-State: ALoCoQlyWV5qigYkOdrV9zbSFcc0ET7qcDy+/fTbLvJ3VfeXNpOMz+s2amhsxdvqtGQQh7LzFqVf Cc: YANG Doctors , MIB Doctors Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:50:33 -0000 --e89a8f2346657c860404cd33ca98 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 29, 2012 at 7:42 AM, Benoit Claise wrote: > Andy, > > Notice how none of the names even slightly match their email address? > > I noticed that as well. > > As if a script randomly generated these requests? > > Is this the way spam works these days? > > Yes -- that's why all the registration forms are going to CAPTCHA > Regards, Benoit > Andy > > > Andy > > > On Mon, Oct 29, 2012 at 1:15 AM, Bert Wijnen (IETF) wrote: > >> It is the same list as for the MIB doctors. >> It is all in a couple of days. >> I do not recognize any of those people? >> Does anyone? >> >> Just ignore them without msgs?? >> >> Bert >> >> On 10/29/12 2:35 AM, Benoit Claise wrote: >> >>> YANG doctors, >>> >>> There are more and more requests to join the YANG-doctors mailer. >>> And each time, I have to reply that this is a closed mailing list. I >>> haven't found an option in the admin tool to say that this is a >>> closed mailing list (if someone knows about this ...). >>> So I changed the text at >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> >>> This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You >>> will not be subscribed with the automatic procedure below. Send >>> an email to the the list owner (bclaise@cisco.com), justifying why >>> you should become a YANG DOCTOR first. If the answer is >>> positive, then subscribe to yang-doctors by filling out the >>> following form. >>> >>> The rest of the text is auto-generated, so I can't change it. >>> >>> Regards, Benoit >>> >>> -------- Original Message -------- >>> Subject: 10 yang-doctors moderator request(s) waiting >>> Date: Sun, 28 Oct 2012 08:00:09 -0700 >>> From: yang-doctors-bounces@ietf.org >>> To: yang-doctors-owner@ietf.org >>> >>> >>> >>> Theyang-doctors@ietf.org mailing list has 10 request(s) waiting for >>> your consideration at: >>> >>> https://www.ietf.org/mailman/admindb/yang-doctors >>> >>> Please attend to this at your earliest convenience. This notice of >>> pending requests, if any, will be sent out daily. >>> >>> Pending subscriptions: >>> expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 11:08:39 >>> 2012 >>> bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:52:03 2012 >>> 3475980121@vtext.com (Willie Adams) Wed Oct 24 13:57:59 2012 >>> mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:07:34 2012 >>> rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:40:12 2012 >>> Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:44:06 >>> 2012 >>> bgranat@granatedit.com (Kevin Murphy) Sat Oct 27 09:09:05 2012 >>> eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:33:15 >>> 2012 >>> randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:14:24 2012 >>> hesed6@aol.com (Zachary Washington) Sat Oct 27 20:20:31 2012 >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> >>> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > > --e89a8f2346657c860404cd33ca98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 29, 2012 at 7:42 AM, Benoit = Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Andy,
Notice how none of the names even slightly ma= tch their email address?
I noticed that as well.
As if a script randomly generated these requests?
Is this the way spam works these days?


Yes -- that's why all th= e registration forms are going to CAPTCHA

=C2=A0
Regards, Benoit

Andy
=C2=A0


Andy


On Mon, Oct 29, 2012 at 1:15 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:
It is the same list as for the MIB doctors.
It is all in a couple of days.
I do not recognize any of those people?
Does anyone?

Just ignore them without msgs??

Bert

On 10/29/12 2:35 AM, Benoit Claise wrote:
YANG doctors,

There are more and more requests to join the YANG-doctors mailer.
And each time, I have to reply that this is a closed mailing list. I haven't found an option in the admin tool to say that this is a
closed mailing list (if someone knows about this ...).
So I changed the text at https://www.ietf.org/mailman/l= istinfo/yang-doctors

=C2=A0 =C2=A0 This is a CLOSED MAILING LIST, for YANG DOCTORS= at the IETF. You will not be subscribed with the automatic procedure below. Send
=C2=A0 =C2=A0 an email to the the list owner (bclaise@cisco.com), justifying = why you should become a YANG DOCTOR first. If the answer is
=C2=A0 =C2=A0 positive, then subscribe to yang-doctors by fil= ling out the following form.

The rest of the text is auto-generated, so I can't change it.

Regards, Benoit

-------- Original Message --------
Subject: =C2=A0 =C2=A0 =C2=A0 =C2=A010 yang-doctors moderator= request(s) waiting
Date: =C2=A0 Sun, 28 Oct 2012 08:00:09 -0700
From: =C2=A0 yang-doctors-bounces@ietf.org
To: =C2=A0 =C2=A0 yang-doctors-owner@ietf.org



Theyang-doctors@ietf.org =C2=A0mailing list has 10 request(s) waiting for
your consideration at:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /admindb/yang-doctors
=C2=A0 =C2=A0 =C2=A0 =C2=A0
Please attend to this at your earliest convenience. =C2=A0Thi= s notice of
pending requests, if any, will be sent out daily.

Pending subscriptions:
=C2=A0 =C2=A0 =C2=A0expdweddingpaper@gmail.com =C2=A0(Edward Miller) Tue Oct 23 11:08:39 2012
=C2=A0 =C2=A0 =C2=A0bangdiw@yahoo.com =C2=A0(Sarah Anderson) Tue Oct 23 21:52:03 2012
=C2=A0 =C2=A0 =C2=A03475980121@vtext.com =C2=A0(Willie Adams) Wed Oct 24 13:57:59 2012
=C2=A0 =C2=A0 =C2=A0mark.escott@hotmail.com =C2=A0(Linda Diaz) Wed Oct 24 15:07:34 2012
=C2=A0 =C2=A0 =C2=A0rowankok@hotmail.com =C2=A0(Rebecca Price) Thu Oct 25 07:40:12 2012
=C2=A0 =C2=A0 =C2=A0Carlotajcepria94@yahoo.com =C2=A0(Gloria Russell) Thu Oct 25 09:44:06 2012
=C2=A0 =C2=A0 =C2=A0bgranat@granatedit.com =C2=A0(Kevin Murphy) Sat Oct 27 09:09:05 2012
=C2=A0 =C2=A0 =C2=A0eveleenkalkof028c0@yahoo.com =C2=A0(Johnny Wright) Sat Oct 27 14:33:15 2012
=C2=A0 =C2=A0 =C2=A0randy_45@rocketmail.com =C2=A0(Kathleen Hughes) Sat Oct 27 17:14:24 2012
=C2=A0 =C2=A0 =C2=A0hesed6@aol.com =C2=A0(Zachary Washington) Sat Oct 27 20:20:31 2012







_______________________________________________
yang-doctors mailing list
ya= ng-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors<= br>
_______________________________________________
MIB-DOCTORS mailing list
MIB-D= OCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



--e89a8f2346657c860404cd33ca98-- From ietfdbh@comcast.net Mon Oct 29 12:48:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59821F8557 for ; Mon, 29 Oct 2012 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+PwIV8d+DHc for ; Mon, 29 Oct 2012 12:48:05 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 1800B21F8554 for ; Mon, 29 Oct 2012 12:48:05 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id H6GW1k0111HzFnQ547o9hw; Mon, 29 Oct 2012 19:48:09 +0000 Received: from [192.168.0.16] ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id H7o51k0023Ecudz3a7o6UD; Mon, 29 Oct 2012 19:48:08 +0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 29 Oct 2012 15:47:59 -0400 From: David Harrington To: "Bert Wijnen (IETF)" , Benoit Claise , YANG Doctors , MIB Doctors Message-ID: Thread-Topic: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting In-Reply-To: <508E3B1D.70200@bwijnen.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:48:06 -0000 I don't recognize any of the names or the domains (other than the obvious). I recommend ignoring the requests. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 10/29/12 4:15 AM, "Bert Wijnen (IETF)" wrote: >It is the same list as for the MIB doctors. >It is all in a couple of days. >I do not recognize any of those people? >Does anyone? > >Just ignore them without msgs?? > >Bert > >On 10/29/12 2:35 AM, Benoit Claise wrote: >> YANG doctors, >> >> There are more and more requests to join the YANG-doctors mailer. >> And each time, I have to reply that this is a closed mailing list. I >>haven't found an option in the admin tool to say that this is a >> closed mailing list (if someone knows about this ...). >> So I changed the text at >>https://www.ietf.org/mailman/listinfo/yang-doctors >> >> This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You >>will not be subscribed with the automatic procedure below. Send >> an email to the the list owner (bclaise@cisco.com), justifying why >>you should become a YANG DOCTOR first. If the answer is >> positive, then subscribe to yang-doctors by filling out the >>following form. >> >> The rest of the text is auto-generated, so I can't change it. >> >> Regards, Benoit >> >> -------- Original Message -------- >> Subject: 10 yang-doctors moderator request(s) waiting >> Date: Sun, 28 Oct 2012 08:00:09 -0700 >> From: yang-doctors-bounces@ietf.org >> To: yang-doctors-owner@ietf.org >> >> >> >> Theyang-doctors@ietf.org mailing list has 10 request(s) waiting for >> your consideration at: >> >> https://www.ietf.org/mailman/admindb/yang-doctors >> >> Please attend to this at your earliest convenience. This notice of >> pending requests, if any, will be sent out daily. >> >> Pending subscriptions: >> expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 11:08:39 >>2012 >> bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:52:03 2012 >> 3475980121@vtext.com (Willie Adams) Wed Oct 24 13:57:59 2012 >> mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:07:34 2012 >> rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:40:12 2012 >> Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:44:06 >>2012 >> bgranat@granatedit.com (Kevin Murphy) Sat Oct 27 09:09:05 2012 >> eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:33:15 >>2012 >> randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:14:24 2012 >> hesed6@aol.com (Zachary Washington) Sat Oct 27 20:20:31 2012 >> >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >> >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Mon Oct 29 13:35:48 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08B921F86FB; Mon, 29 Oct 2012 13:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOTY+L7F07Ib; Mon, 29 Oct 2012 13:35:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0041A21F86F0; Mon, 29 Oct 2012 13:35:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9TKZcDv026405; Mon, 29 Oct 2012 21:35:38 +0100 (CET) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9TKZa0A029022; Mon, 29 Oct 2012 21:35:37 +0100 (CET) Message-ID: <508EE898.8090200@cisco.com> Date: Mon, 29 Oct 2012 21:35:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , MIB Doctors Subject: Re: [MIB-DOCTORS] [yang-doctors] Fwd: 10 yang-doctors moderator request(s) waiting X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:35:48 -0000 > I don't recognize any of the names or the domains (other than the obvious). > I recommend ignoring the requests. Right, but I start to see 3 ... 4 ... 5 requests a day. I'll see if I can block any subscriptions, except from the sys admin Regards, Benoit > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 10/29/12 4:15 AM, "Bert Wijnen (IETF)" wrote: > >> It is the same list as for the MIB doctors. >> It is all in a couple of days. >> I do not recognize any of those people? >> Does anyone? >> >> Just ignore them without msgs?? >> >> Bert >> >> On 10/29/12 2:35 AM, Benoit Claise wrote: >>> YANG doctors, >>> >>> There are more and more requests to join the YANG-doctors mailer. >>> And each time, I have to reply that this is a closed mailing list. I >>> haven't found an option in the admin tool to say that this is a >>> closed mailing list (if someone knows about this ...). >>> So I changed the text at >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> >>> This is a CLOSED MAILING LIST, for YANG DOCTORS at the IETF. You >>> will not be subscribed with the automatic procedure below. Send >>> an email to the the list owner (bclaise@cisco.com), justifying why >>> you should become a YANG DOCTOR first. If the answer is >>> positive, then subscribe to yang-doctors by filling out the >>> following form. >>> >>> The rest of the text is auto-generated, so I can't change it. >>> >>> Regards, Benoit >>> >>> -------- Original Message -------- >>> Subject: 10 yang-doctors moderator request(s) waiting >>> Date: Sun, 28 Oct 2012 08:00:09 -0700 >>> From: yang-doctors-bounces@ietf.org >>> To: yang-doctors-owner@ietf.org >>> >>> >>> >>> Theyang-doctors@ietf.org mailing list has 10 request(s) waiting for >>> your consideration at: >>> >>> https://www.ietf.org/mailman/admindb/yang-doctors >>> >>> Please attend to this at your earliest convenience. This notice of >>> pending requests, if any, will be sent out daily. >>> >>> Pending subscriptions: >>> expdweddingpaper@gmail.com (Edward Miller) Tue Oct 23 11:08:39 >>> 2012 >>> bangdiw@yahoo.com (Sarah Anderson) Tue Oct 23 21:52:03 2012 >>> 3475980121@vtext.com (Willie Adams) Wed Oct 24 13:57:59 2012 >>> mark.escott@hotmail.com (Linda Diaz) Wed Oct 24 15:07:34 2012 >>> rowankok@hotmail.com (Rebecca Price) Thu Oct 25 07:40:12 2012 >>> Carlotajcepria94@yahoo.com (Gloria Russell) Thu Oct 25 09:44:06 >>> 2012 >>> bgranat@granatedit.com (Kevin Murphy) Sat Oct 27 09:09:05 2012 >>> eveleenkalkof028c0@yahoo.com (Johnny Wright) Sat Oct 27 14:33:15 >>> 2012 >>> randy_45@rocketmail.com (Kathleen Hughes) Sat Oct 27 17:14:24 2012 >>> hesed6@aol.com (Zachary Washington) Sat Oct 27 20:20:31 2012 >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > > From jcucchiara@mindspring.com Tue Oct 30 23:36:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7989F21F867D; Tue, 30 Oct 2012 23:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJHjXbdr-oIi; Tue, 30 Oct 2012 23:36:42 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69D21F8679; Tue, 30 Oct 2012 23:36:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fxaLPswRF7OdfjfRo7oP+IR/L9CqrpHNLA4tW7an6dVe53TAfgHIZHzRxrS04Pz2; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TTRuq-0001AU-4o; Wed, 31 Oct 2012 02:36:40 -0400 Message-ID: <008801cdb732$13fc1db0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Loa Andersson" , , "MIB Doctors \(E-mail\)" References: <50782094.5050104@pi.nu> Date: Wed, 31 Oct 2012 01:36:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26547b52e12a19be81aa59ca605b5933bb40387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: MPLS-TP ad hoc team , draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org Subject: [MIB-DOCTORS] MIB DR. review of draft-ietf-mpls-tp-oam-id-mib-01.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 06:36:43 -0000 Hello, Please accept this MIB review as part of the WG LC comments. Compiler output which is followed by General Comments and then more specific comments. Thank you, -Joan smicngPRO E: f(MPLS-OAM-ID-STD-MIB.my), (111,8) Row "mplsOamIdMegEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create E: f(MPLS-OAM-ID-STD-MIB.my), (162,17) Index item "mplsOamIdMegIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (240,19) Size of default value for "mplsOamIdMegIdIcc" is outside allowed range E: f(MPLS-OAM-ID-STD-MIB.my), (257,19) Size of default value for "mplsOamIdMegIdUmc" is outside allowed range E: f(MPLS-OAM-ID-STD-MIB.my), (433,23) Index item "mplsOamIdMegIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (434,23) Index item "mplsOamIdMeIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (435,23) Index item "mplsOamIdMeMpIndex" must be defined with syntax that includes a range Compiles cleanly with smilint. GENERAL COMMENTS -------------------------------------- 0) The draft proposes supporting LSPs, pseudowires and sections. Was the LC posted on pwe3 WG? 1) The MIB Module and Managed Objects do not reflect that this is MPLS-TP, why is that? 2) Terminology is not consistent with rfc5654 or rfc5860. They use the terms MPLS in Transport Networks, or MPLS Transport Profile, and this draft refers to this as "MPLS based Transport Profile". Please be consistent with these RFCs. 3) In general need more REFERENCES and more specific REFERENCES. Specifying an entire RFC is not nearly as helpful as specifying a section or subsection of an rfc. 4) Inconsistent use of RFC names. For example in Section 3.2 "This document uses terminology from the MPLS architecture document [RFC3031], MPLS Traffic Engineering Management information [RFC3812], MPLS Label Switch Router MIB [RFC3813] ....and MPLS-TP Identifiers document [RFC6370]." Sometimes a very informal name for document title, sometimes part of a title and sometimes the full title. Please consistently give the full title, so: MPLS Label Switching Architecture [RFC3031], MPLS Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [RFC3812] and so forth. 5) Similar to the above, please reference MIB Modules by the Module Name. Someplaces do this, but some say MPLS Traffic Engineering MIB or LSR MIB. Again, please just be consistent. 6) Please capitalize the MIB. SPECIFIC COMMENTS ------------------------------- Section 5.1 s/in this table for MPLS tunnel/ in this table for MPLS tunnels/ Section 6. Please rework the title of this Section. It is awkward to read. s/for MPLS co-routed/ for an MPLS co-routed/ s/of MPLS tunnel/of an MPLS tunnel/ MIB MODULE ------------ *) DESCRIPTION "MPLS OAM Identifiers mib objects for LSPs and Pseudowires" s/mib/MIB/ *) Why is there no IndexNext scalar to assist operators in configuring the mplsOamIdMegTable? *) mplsOamIdMegIndex May want to consider starting the index at 1 per the rfc4181 Section 4.6.1.1 *) Mix of read-write and read-create in this table, and when creating a row (i.e. utilizing RowStatus, should use read-create.) *) some of these SnmpAdminString values say that NULL is acceptable, so maybe SIZE starting at 0 ? *) mplsOamIdMegServiceType DESCRIPTION clause is awkward. Indicates the service type for the MEG? What is the "service pointer", could you please state which object and be very specific, i.e. points to an entry in the mplsTunnelTable [RFC3812], etc. Same issue with the next 2 paragraphs. * Order of these objects. Typically, all objects are appear before StorageType and RowStatus. I don't believe this is mandatory, but certainly, convention. If objects are added after RowStatus that usually happens for revisions of the RFC. *) mplsOamIdMeTable Are entries in this table created dynamically and/or manually? Please clarify. *) mplsOamIdMeIndex and mplsOamIdMeMpIndex Same comment as above with regard to a IndexNext scalar and starting these indices at 1 as suggested by rfc4181 Section 4.6.1.1 *) mplsOamIdMeMpIfIndex Please include in the DESCRIPTION which ifType is associated with the various possiblities for this value. *) mplsOamIdMeMepDirection The DESCRIPTION is confusing. If the mplsOamIdMeMpType is not mep(1), what happens if this value is set? What happens upon a get request? *) mplsOamIdMeProactiveOamPhbTCValue/mplsOamIdMeOnDemandOamPhbTCValue Was the intention to make this a TC? Is this something that IANA should administer? *) same comments as before with regards to the order of StorageType and RowStatus objects. *) Notifications Why are these accessible-for-notify objects not included as part of the Tables? I think they would be relevant and helpful in monitoring. The mplsOamIdDefectCondition When is this supposed to be sent? I think the DESCRIPTION should be specific about when this notification is triggered. *) OID layout is not as suggested by rfc4181 \-2 mplsOamIdConformance \-v-1 mplsOamIdGroups | \-v-1 mplsOamIdMegGroup | |-2 mplsOamIdMeGroup | |-3 mplsOamIdNotificationObjectsGroup | \-4 mplsOamIdNotificationGroup \-2 mplsOamIdCompliances \---1 mplsOamIdModuleFullCompliance rfc4181, Appendix D. xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) *) Compliance There is no read-only compliance. Has it been made clear to the WGs (MPLS and PWE3) that SNMP sets will need to be supported in order to be compliant with the MIB? 8. Security Considerations This section needs to be completed. Please rework this section. 9.IANA Considerations This section needs to be completed. 10.2 Informative References What order are these in? -- end -- ----- Original Message ----- From: "Loa Andersson" To: Cc: "MPLS-TP ad hoc team" ; Sent: Friday, October 12, 2012 8:52 AM Subject: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-oam-id-mib-01. > > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). > > Please send both technical comments, and if you are happy with the > document as is also indications of support. > > This working group last call will end on October 28. > > /Loa > for the wg co-chairs > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls