From moulchan@cisco.com Mon May 14 04:45: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 475C221F86EB; Mon, 14 May 2012 04:45:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3HvXwpOQfxK; Mon, 14 May 2012 04:45:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5D21F86C3; Mon, 14 May 2012 04:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1999; q=dns/txt; s=iport; t=1336995927; x=1338205527; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rzZin9MibtR5iXtvXlXGLTPE3SYLVNjUFGdJCYA3LgA=; b=UFsc9l84Q4z1QCO2FzXFTzB20BjedoYOpLASdA5h3rEMvsCymbA34uN7 jD8tlapDOfJvgPXaKZHdmOG6eRTc5uTYga4mtz+ERaORA6unUhDiwkoF+ wLIK6xyvt/ar4qsD4s5T3ZJ7Yxbi+U5BdP8YQanplAUuP7kEKyVn3Drqt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACrvsE+tJXG8/2dsb2JhbABBA7NygQeCFQEBAQQSAR0KNAsMAgICAQgOAgEEAQELBhcBBgEaKwkIAQEEEwgBGYdsC5pIn14EixYZgkSCSGMEiGSbcIFpgweBQQ X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="82981702" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 May 2012 11:45:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4EBjQuM029108; Mon, 14 May 2012 11:45:26 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 06:45:26 -0500 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, 14 May 2012 06:45:23 -0500 Message-ID: In-Reply-To: <20120419102636.GA62360@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aA References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 May 2012 11:45:26.0689 (UTC) FILETIME=[0E023110:01CD31C7] Cc: eman@ietf.org, MIB Doctors Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? 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, 14 May 2012 11:45:28 -0000 Hello all, Thanks for the responses - which seem to address how we can handle the questions (wrt to ENTITY MIB) that came back at the WG meeting. =20 >From a process point of view, will there be an informational rfc - that lists the new requirements and the how those can be addressed within ENTITY-MIB framework ?=20 Thanks Mouli=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, April 19, 2012 3:57 PM To: Mouli Chandramouli (moulchan) Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org Subject: Re: [eman] Entity MIBv4? On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) wrote: =20 > > > - representation of UUID compliant with rfc 4122 ? > >=20 > > Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > object. If so, I am not sure you need the extra URN verbosity. > >=20 > [[DR]] This is the only issue that seems open in my view - meaning the > slides and discussions at the meeting did not seem to lead to a > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > representation and also another entPhysicalUri format will be needed? >=20 > [ycm] Two possible approaches for UUID representation as given in the > mailing list and slides=20 > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html The question is whether it is wise to encode a UUID, which is essentially 16 binary octets, in a representation that requires 45 octets. I am pretty optimistic that a DISPLAY-HINT definition can be provided that renders 16 binary octets into something like "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon May 14 05:03: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 4264E21F861E; Mon, 14 May 2012 05:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXYkp+ixw2xf; Mon, 14 May 2012 05:03: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 DA5FF21F8642; Mon, 14 May 2012 05:03:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK3zsE/GmAcF/2dsb2JhbABBA7NygQeCFQEBAQECARIeCjQLBQcCAgIBCA0DAQQBAQEKBgwLAQYBGisJCAEBBAESCAEZh2cFC51FnGoEixYZgkSCSGMEnBSKKYJrgV0 X-IronPort-AV: E=Sophos;i="4.75,585,1330923600"; d="scan'208";a="306342632" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2012 08:01:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 May 2012 08:01:28 -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, 14 May 2012 14:02:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aAAACuLFA= References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? 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, 14 May 2012 12:03:05 -0000 Do we need an informational RFC? I thought that having a 'Changes from RFC4133' section in the text part of the rfc4133bis document that lists the changes and the motivation for the changes would be sufficient.=20 Dan > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Monday, May 14, 2012 2:45 PM > To: Juergen Schoenwaelder > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > Hello all, >=20 > Thanks for the responses - which seem to address how we can handle the > questions (wrt to ENTITY MIB) that came back at the WG meeting. >=20 > From a process point of view, will there be an informational rfc - > that lists the new requirements and the how those can be addressed > within ENTITY-MIB framework ? >=20 > Thanks > Mouli >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 19, 2012 3:57 PM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) > wrote: >=20 > > > > - representation of UUID compliant with rfc 4122 ? > > > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC > 4122 > > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > > object. If so, I am not sure you need the extra URN verbosity. > > > > > [[DR]] This is the only issue that seems open in my view - meaning > the > > slides and discussions at the meeting did not seem to lead to a > > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > > representation and also another entPhysicalUri format will be needed? > > > > [ycm] Two possible approaches for UUID representation as given in the > > mailing list and slides > > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html >=20 > The question is whether it is wise to encode a UUID, which is > essentially 16 binary octets, in a representation that requires 45 > octets. I am pretty optimistic that a DISPLAY-HINT definition can be > provided that renders 16 binary octets into something like > "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From moulchan@cisco.com Mon May 14 05:05:47 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 28C5421F8655; Mon, 14 May 2012 05:05:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaSgJy3UClKU; Mon, 14 May 2012 05:05:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC021F861E; Mon, 14 May 2012 05:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2925; q=dns/txt; s=iport; t=1336997146; x=1338206746; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CJr9DSil2YTRmPGasgBO8xXQya6ftWZjb9IwOB1kNMY=; b=Qr6JZ2PdYNYcBfQJHuE0stcZ7V26RcnqpPoKsPbB536ETNuJrYl4HGRR 3HrfFzzx7JHNwLgGyln439p5DoGmbpdeivWzx5FWq5fzy5n0DHakBpRQe aATNrfFKkBqMsEcQvWuUsWR9D5szisMNg9uXh3fjhUw2UJ5bkG9vhnJvV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAD0sE+tJXHB/2dsb2JhbABBA7NygQeCFQEBAQMBEgEdCjQLBQcCAgIBCBABBAEBAQoGFwEGARorCQgBAQQBEggBGYdnBQuaUJ9iBIsWGYJEgkhjBIhkm3CBaYMHgUE X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="82944235" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2012 12:05:46 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4EC5j10028452; Mon, 14 May 2012 12:05:45 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 07:05:42 -0500 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, 14 May 2012 07:05:39 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aAAACuLFAAAC58gA== References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 May 2012 12:05:42.0955 (UTC) FILETIME=[E2F5A7B0:01CD31C9] Cc: MIB Doctors , eman@ietf.org Subject: Re: [MIB-DOCTORS] [eman] Entity MIBv4? 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, 14 May 2012 12:05:47 -0000 Thanks Dan. Your suggestion of rfc4133bis makes sense.=20 Regards Mouli=20 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, May 14, 2012 5:33 PM To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder Cc: MIB Doctors; eman@ietf.org Subject: RE: [eman] Entity MIBv4? Do we need an informational RFC? I thought that having a 'Changes from RFC4133' section in the text part of the rfc4133bis document that lists the changes and the motivation for the changes would be sufficient.=20 Dan > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Monday, May 14, 2012 2:45 PM > To: Juergen Schoenwaelder > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > Hello all, >=20 > Thanks for the responses - which seem to address how we can handle the > questions (wrt to ENTITY MIB) that came back at the WG meeting. >=20 > From a process point of view, will there be an informational rfc - > that lists the new requirements and the how those can be addressed > within ENTITY-MIB framework ? >=20 > Thanks > Mouli >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 19, 2012 3:57 PM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) > wrote: >=20 > > > > - representation of UUID compliant with rfc 4122 ? > > > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC > 4122 > > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > > object. If so, I am not sure you need the extra URN verbosity. > > > > > [[DR]] This is the only issue that seems open in my view - meaning > the > > slides and discussions at the meeting did not seem to lead to a > > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > > representation and also another entPhysicalUri format will be needed? > > > > [ycm] Two possible approaches for UUID representation as given in the > > mailing list and slides > > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html >=20 > The question is whether it is wise to encode a UUID, which is > essentially 16 binary octets, in a representation that requires 45 > octets. I am pretty optimistic that a DISPLAY-HINT definition can be > provided that renders 16 binary octets into something like > "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From bclaise@cisco.com Wed May 16 03:53:44 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 73B8D21F8746 for ; Wed, 16 May 2012 03:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.576 X-Spam-Level: X-Spam-Status: No, score=-8.576 tagged_above=-999 required=5 tests=[AWL=2.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHx1jK2i6Rb1 for ; Wed, 16 May 2012 03:53:43 -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 57BF821F8740 for ; Wed, 16 May 2012 03:53: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 q4GArcL2019767; Wed, 16 May 2012 12:53:39 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4GArcCO009038; Wed, 16 May 2012 12:53:38 +0200 (CEST) Message-ID: <4FB38732.3060500@cisco.com> Date: Wed, 16 May 2012 12:53:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> In-Reply-To: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet-chairs@tools.ietf.org, mib-doctors@ietf.org, draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 16 May 2012 10:53:44 -0000 Hi MIB doctors, My bad for not following up on this one. I will follow more closely from now on. Can we please have a volunteer to review this MIB module, which is on the IESG telechat for next Thursday. Regards, Benoit. > Hi MIB Doctors, > > Heads up to give you extra review time. > > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ is going to IETF > last call very soon and would benefit significantly from a MIB Doctor review by > the end of the last call. > > Thanks for the work you do. > > Adrian > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From bclaise@cisco.com Mon May 21 03:09: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 2CAFE21F84A2 for ; Mon, 21 May 2012 03:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqcywri8WAee for ; Mon, 21 May 2012 03:09:32 -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 267C721F8518 for ; Mon, 21 May 2012 03:09:28 -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 q4LA9OFO021334; Mon, 21 May 2012 12:09:24 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4LA9NBO018857; Mon, 21 May 2012 12:09:23 +0200 (CEST) Message-ID: <4FBA1453.7020308@cisco.com> Date: Mon, 21 May 2012 12:09:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> <4FB38732.3060500@cisco.com> In-Reply-To: <4FB38732.3060500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet-chairs@tools.ietf.org, mib-doctors@ietf.org, draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 21 May 2012 10:09:33 -0000 Hi MIB doctors, We would really benefit from your expertise here. Can we please have a volunteer. If we don't find someone by the end of the day (on telechat for this Thursday), I'm afraid that I will have to defer this draft to the next telechat... Regards, Benoit. > Hi MIB doctors, > > My bad for not following up on this one. I will follow more closely > from now on. > Can we please have a volunteer to review this MIB module, which is on > the IESG telechat for next Thursday. > > Regards, Benoit. >> Hi MIB Doctors, >> >> Heads up to give you extra review time. >> >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ is going >> to IETF >> last call very soon and would benefit significantly from a MIB Doctor >> review by >> the end of the last call. >> >> Thanks for the work you do. >> >> 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 > > From bclaise@cisco.com Mon May 21 15:15:29 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 AF4B521F854B for ; Mon, 21 May 2012 15:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFAuuPY8R2vM for ; Mon, 21 May 2012 15:15:28 -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 8769E21F8475 for ; Mon, 21 May 2012 15:15:28 -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 q4LMFREY010382; Tue, 22 May 2012 00:15:27 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4LMFQXw005724; Tue, 22 May 2012 00:15:26 +0200 (CEST) Message-ID: <4FBABE7E.3090203@cisco.com> Date: Tue, 22 May 2012 00:15:26 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> <4FB38732.3060500@cisco.com> <4FBA1453.7020308@cisco.com> In-Reply-To: <4FBA1453.7020308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet-chairs@tools.ietf.org, mib-doctors@ietf.org, draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 21 May 2012 22:15:29 -0000 Dear all, I have deferred this draft for the next telechat. Regards, Benoit. > Hi MIB doctors, > > We would really benefit from your expertise here. > Can we please have a volunteer. > If we don't find someone by the end of the day (on telechat for this > Thursday), I'm afraid that I will have to defer this draft to the next > telechat... > > Regards, Benoit. > >> Hi MIB doctors, >> >> My bad for not following up on this one. I will follow more closely >> from now on. >> Can we please have a volunteer to review this MIB module, which is on >> the IESG telechat for next Thursday. >> >> Regards, Benoit. >>> Hi MIB Doctors, >>> >>> Heads up to give you extra review time. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ is going >>> to IETF >>> last call very soon and would benefit significantly from a MIB >>> Doctor review by >>> the end of the last call. >>> >>> Thanks for the work you do. >>> >>> 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 Mon May 21 15:21:40 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 65FD121F84DD for ; Mon, 21 May 2012 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3LaseU8wVEj for ; Mon, 21 May 2012 15:21:40 -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 8EDC221F84A7 for ; Mon, 21 May 2012 15:21:39 -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 q4LMLcfe010934; Tue, 22 May 2012 00:21:38 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4LMLceW008877; Tue, 22 May 2012 00:21:38 +0200 (CEST) Message-ID: <4FBABFF1.2010002@cisco.com> Date: Tue, 22 May 2012 00:21:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Ron Bonica Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Volunteers for MIB 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, 21 May 2012 22:21:40 -0000 Dear all, [restricting the email to just mib-doctors] First of all, my apologies for not following up the email from Adrian on March 29th, subject "Heads-up MIB review impending". This concerns the MIB doctor review of https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ Now, how do we share the load amongst MIB doctors? - round robin? - we keep track of history and ask a specific person (like Tina Tsu does for OPS-DIR). I could do that job - I just an email to the list, asking for a volunteer? - something else? Please let me know. Also, we really need a reviewer for https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ Regards, Benoit. From dbharrington@comcast.net Mon May 21 22:43: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 55E1821F8564 for ; Mon, 21 May 2012 22:43:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsEf8wfUsjKR for ; Mon, 21 May 2012 22:43:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5998B21F855F for ; Mon, 21 May 2012 22:43:47 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id CtjU1j0021ap0As53tjmrF; Tue, 22 May 2012 05:43:46 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta22.westchester.pa.mail.comcast.net with comcast id Ctjk1j0043Ecudz3itjlKw; Tue, 22 May 2012 05:43:46 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Tue, 22 May 2012 01:43:43 -0400 From: David Harrington To: Benoit Claise , "MIB Doctors (E-mail)" , Ron Bonica Message-ID: Thread-Topic: [MIB-DOCTORS] Volunteers for MIB review In-Reply-To: <4FBABFF1.2010002@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 05:43:48 -0000 Hi Benoit, I will try to help you understand how the MIB Doctors work, so you know. You might also ask Dan and Bert how they handled this. I am a member of the secdir, opsdir, tsvdir, and MIB Doctors directorates. Secdir reviews are pretty easy; you check whether they have documented considerations of authentication, authorization, integrity, confidentiality, and replay. Occasionally there is something a bit more in depth about specific vulnerabilities, but not often. Opsdir is pretty easy; you check whether external operational needs have been addressed, such as DNS, network management, and so on have been mentioned. Tsvdir is pretty easy; you check whether congestion has been addressed (TCP good; UDP bad), whether timers and message replay and port assignments have been discussed appropriately. A MIB review is huge in comparison; You might know all this already, but I'll mention it just for comparison with other review team requirements. You need to check the MIB module syntax using tools like libsmi. Then the real work starts. You need to check for database design anomalies, such as deletion anomalies, addition anomalies, fate-sharing between tables, persistence, etc. You need to study the technology being managed to determine whether appropriate counters have been defined, and tables of relevant information, etc. You need to consider implementation issues, such as whether the information is readily available to put into a MIB; Fast-track switching can have a big effect. You need to consider whether updating counters will impact performance of the managed technology; you need to consider code footpriint, and so on. You need to consider the guidelines for review that discuss how to check boilerplates, type expansions, naming conventions, security considerations, textual conventions, proper handling of references, etc. A solid MIB review can take days, and the MIB Doctor stays assigned to the document while it goes through the approval process. The Directorates wiki page shows nineteen MIB Doctors. For nine of the names, I don't remember the last time I saw them at an IETF or an email from them to an IETF list (Frank Strauss? Glenn Waters? Steve Waldbusser? Dave Perkins? Sharon Chisholm? Harrie? Mike Heard?) Another four or five are still active in IETF, but almost never do MIB reviews because they're focused on other work (Andy, John Flick, Shawn, me) I don't know why we keep the list of nineteen on this page. So realistically, you have an active MIB Doctor review team of about six people (Bert, Juergen, Mike MacFaden, Randy, Joan, and Orly) And they realistically need to pick and choose which modules they review because they are so time-intensive. I am not volunteering for this MIB module, since I don't have the time to learn about manet. I recommend trying to grow the MIB Doctors, but I expect this will be very hard. You might try to recruit some operators who use SNMP tools to provide a "usefulness" design review. I don't know if there is anyway to reduce the burden of a MIB review. Tools seem a likely approach. The libsmi tools are good, but can only analyze fairly static features (syntax). Maybe another round of tools usable by MIB writers could help analyze table relationships and check for counter persistence text. If you can get agreement from the MIB Doctors to formalize some additional guidelines, further checking might be able to be automated. But part of the problem of MIB reviews is that there are already so many rules to follow and review. Getting tools like libsmi accepted by the tools team, worked on during code sprints, or adding automated MIB review to datatracker functionality might help. (There are other syntax checkers/process checkers that could also be good added to tools team responsibility, such as mime type registration syntax and completeness.) I know I haven't helped solve the problem of a lack of volunteer for the nhdp mib, but hopefully you better understand why nobody is stepping forward. -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/21/12 6:21 PM, "Benoit Claise" wrote: >Dear all, > >[restricting the email to just mib-doctors] > >First of all, my apologies for not following up the email from Adrian on >March 29th, subject "Heads-up MIB review impending". >This concerns the MIB doctor review of >https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > >Now, how do we share the load amongst MIB doctors? >- round robin? >- we keep track of history and ask a specific person (like Tina Tsu does >for OPS-DIR). I could do that job >- I just an email to the list, asking for a volunteer? >- something else? > >Please let me know. >Also, we really need a reviewer for >https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > >Regards, Benoit. > > >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From bertietf@bwijnen.net Tue May 22 00:17: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 C170611E8079 for ; Tue, 22 May 2012 00:17:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrDK-rxLpCM5 for ; Tue, 22 May 2012 00:17:55 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id EE42A11E8072 for ; Tue, 22 May 2012 00:17:53 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SWjLp-0007Uk-5R; Tue, 22 May 2012 09:17:50 +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 1SWjLp-0002EY-0R; Tue, 22 May 2012 09:17:49 +0200 Message-ID: <4FBB3D9C.5000503@bwijnen.net> Date: Tue, 22 May 2012 09:17:48 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Benoit Claise References: <4FBABFF1.2010002@cisco.com> In-Reply-To: <4FBABFF1.2010002@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 #7816066, check: 20120522 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: 86ab03e524994f79ca2c75a176445dd470cfefea9f2a476d07f570448b818d5f Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 07:17:55 -0000 Hi Benoit. Last week, and also coming weeks I am pretty busy, so I could not step up. Yet I did a very quick browse through the document, but this was basically to do a first assessment if the MIB is in really bad state (in which case there will be a lot of work and a long period during which the work may come back) or in reasonable shape, in which case the work is far less and may not take too long to come to closure. This MIB document seems quite reasonable at first sight. But still it will take some time to do a proper review. I also saw DBH comments/explanation. I think it would be good if we could do such in depth reviews as Dave suggests, but at the other hand, I feel that it is subject matter experts that need to worry about a lot of the topics about design and impact on the technology. I know that when I do a review, that I often dive somewhat into the documents that describe the technology, and then sometimes that raises questions that I will pose and that causes follow up etc. When I was AD, and when/if I couldn't get reviewers (although at the time we had a larger base of *active* MIB doctors), then I would do the basic checks myself, make sure SYNTAX was OK, make sure there were no gaping holes. That sometimes (actually often) took quite some time. Yep... I understand. But even if you get to this stage, I am not sure you absolutely have to go into as much details as Dave suggests. There are (after all) so many different technologies in IETF that it is kind of impossible to understand them all in great detail. I guess that is up to you to decide. Maybe Dan has some perspective here as well. Bert On 5/22/12 12:21 AM, Benoit Claise wrote: > Dear all, > > [restricting the email to just mib-doctors] > > First of all, my apologies for not following up the email from Adrian on March 29th, subject "Heads-up MIB review impending". > This concerns the MIB doctor review of https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > > Now, how do we share the load amongst MIB doctors? > - round robin? > - we keep track of history and ask a specific person (like Tina Tsu does for OPS-DIR). I could do that job > - I just an email to the list, asking for a volunteer? > - something else? > > Please let me know. > Also, we really need a reviewer for https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > Regards, Benoit. > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From dromasca@avaya.com Tue May 22 01:17:21 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 6F95321F8564 for ; Tue, 22 May 2012 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIVK7TaRYINk for ; Tue, 22 May 2012 01:17:20 -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 6613D21F8552 for ; Tue, 22 May 2012 01:17:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUMAD9Lu0/GmAcF/2dsb2JhbABErEyHSoEHghUBAQEBAgEBAQEPCxMKMQIBBgUFBwQCAQgNBAQBAQEKBgwLAQYBJh8JCAEBBAESCBqHZwULoQadGwSLCBmEQWIDmwyJf4JrgV0 X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="307555609" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 May 2012 04:15:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 May 2012 04:15:15 -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: Tue, 22 May 2012 10:17:12 +0200 Message-ID: In-Reply-To: <4FBB3D9C.5000503@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Volunteers for MIB review Thread-Index: Ac036wziomjxlsjiSO+vBjhi10+GjgABcuxQ References: <4FBABFF1.2010002@cisco.com> <4FBB3D9C.5000503@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Benoit Claise" Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 08:17:21 -0000 Hi Benoit,=20 My perspective is very close to Bert's and David's. Indeed, proper MIB Doctor review requires good understanding or fast learning of the technology that is supposed to be managed, and this takes time. I would argue that you need this also for a proper security or OPS review, but the argument is marginal for what we discuss here. For that reason while I was on the IESG I asked my fellow ADs to require MIB doctor review BEFORE the IETF LC, so that the search for a MIB Doctor starts earlier than the moment the Last Call sand-clock (typically two or four weeks) is runing. You may want to do the same.=20 Concerning the MIB Doctors team composition. I did a clean-up a few years ago and the remaining members were those who committed to continue to be active with a couple of exceptions - Frank Strauss was never an active reviewer but he contributed the libsmi, Mike Heard and Andy Bierman said that they did not have the time for reviews but would stay on the list and answers questions occasionally, which they did now and then and this was useful. You may want to do another round of questions, see who wants to stay active, who opts out. Harrie actually answered at least one call for reviewers in the last year, you can also add my name to the list, with eight active reviewers the situation is not that bad, this will lead to 2-3 reviews each year. You can of course try to recruit new participants.=20 You may move from a asking for volunteers model to a round-robin assignment, or at least use such an algorithm if a volunteer does not show up after a few days.=20 Concerning the style of the reviews, I am again agreeing to what Bert and David say, and I would add that in my reviews I also ask about the need to reduce complexity hence the number of objects so that the agent code can be implemented and the manager can access easily the objects essential to the day-to-day operations.=20 Concerning this MIB module - Bob Cole consulted with me, maybe also with other MIB doctors while in design phase, so there was some level of exposure and discussions prior to the MIB module hitting the IESG.=20 I hope this helps.=20 Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, May 22, 2012 10:18 AM > To: Benoit Claise > Cc: MIB Doctors (E-mail); Ron Bonica > Subject: Re: [MIB-DOCTORS] Volunteers for MIB review >=20 > Hi Benoit. >=20 > Last week, and also coming weeks I am pretty busy, so I could > not step up. Yet I did a very quick browse through the document, > but this was basically to do a first assessment if the MIB is > in really bad state (in which case there will be a lot of work > and a long period during which the work may come back) or in > reasonable shape, in which case the work is far less and may not > take too long to come to closure. > This MIB document seems quite reasonable at first sight. > But still it will take some time to do a proper review. >=20 > I also saw DBH comments/explanation. > I think it would be good if we could do such in depth reviews as > Dave suggests, but at the other hand, I feel that it is subject > matter experts that need to worry about a lot of the topics > about design and impact on the technology. > I know that when I do a review, that I often dive somewhat into the > documents that describe the technology, and then sometimes that raises > questions that I will pose and that causes follow up etc. >=20 > When I was AD, and when/if I couldn't get reviewers (although at the > time we had a larger base of *active* MIB doctors), then I would do > the basic checks myself, make sure SYNTAX was OK, make sure there > were no gaping holes. That sometimes (actually often) took quite some > time. Yep... I understand. >=20 > But even if you get to this stage, I am not sure you absolutely have to > go into as much details as Dave suggests. There are (after all) so many > different technologies in IETF that it is kind of impossible to > understand them all in great detail. > I guess that is up to you to decide. >=20 > Maybe Dan has some perspective here as well. >=20 > Bert >=20 > On 5/22/12 12:21 AM, Benoit Claise wrote: > > Dear all, > > > > [restricting the email to just mib-doctors] > > > > First of all, my apologies for not following up the email from Adrian > on March 29th, subject "Heads-up MIB review impending". > > This concerns the MIB doctor review of > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > > > > > Now, how do we share the load amongst MIB doctors? > > - round robin? > > - we keep track of history and ask a specific person (like Tina Tsu > does for OPS-DIR). I could do that job > > - I just an email to the list, asking for a volunteer? > > - something else? > > > > Please let me know. > > Also, we really need a reviewer for > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > > > Regards, Benoit. > > > > > > _______________________________________________ > > 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 Tue May 22 01:19: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 4A0E021F8564; Tue, 22 May 2012 01:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.051 X-Spam-Level: X-Spam-Status: No, score=-10.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOGJhHokMgEM; Tue, 22 May 2012 01:19:09 -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 705D321F85CE; Tue, 22 May 2012 01:19: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 q4M8J6hj010897; Tue, 22 May 2012 10:19:06 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4M8J5bi014917; Tue, 22 May 2012 10:19:05 +0200 (CEST) Message-ID: <4FBB4BEE.7030707@cisco.com> Date: Tue, 22 May 2012 10:18:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.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: <20120521221709.2320.26079.idtracker@ietfa.amsl.com> In-Reply-To: <20120521221709.2320.26079.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120521221709.2320.26079.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Agenda and Package for the May 24, 2012 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: Tue, 22 May 2012 08:19:11 -0000 Dear all, Please find below the agenda of the May 24th IESG telechat. Please send your questions, comments and concerns before May 23rd COB. Thanks and Regards, Benoit. -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-pwe3-redundancy-bit-07 Pseudowire Preferential Forwarding Status Bit (Proposed Standard) Note: Andy Malis (amalis@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-manet-nhdp-mib-13 Definition of Managed Objects for the Neighborhood Discovery Protocol (Proposed Standard) Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-pkix-cmp-transport-protocols-19 Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP (Proposed Standard) Note: Steve Kent (kent@bbn.com) is the Document Shepherd. Token: Sean Turner o draft-ietf-netext-access-network-option-10 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 (Proposed Standard) Note: Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd. Token: Brian Haberman 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items o draft-snell-atompub-tombstones-15 The Atom "deleted-entry" Element (Proposed Standard) Note: This document switched from Informational to Standards Track,because of Robert's DISCUSS suggestion.  But that happenedacross the transition to new IESG members, so the documentneeds two more positions.  ADs with no positions, please addyour ballot, and I'll put this back on the telechat for 24 May. Token: Barry Leiba 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ledbat-congestion-09 Low Extra Delay Background Transport (LEDBAT) (Experimental) Note: Murari Sridharan (muraris@microsoft.com) is the Document Shepherd. Token: Wesley Eddy o draft-ietf-pwe3-redundancy-08 Pseudowire Redundancy (Informational) Note: Andy Malis (amalis@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-ccamp-assoc-info-03 Usage of The RSVP Association Object (Informational) Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd. Token: Adrian Farrel 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-claise-export-application-info-in-ipfix-07 Export of Application Information in IPFIX (Informational) Note: Individual Submission, AD-sponsored, Nevil Brownlee is the document shepherd, Token: Ronald Bonica 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-irtf-rrg-ilnp-v4opts-03 IPv4 Options for ILNPv4 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms o draft-irtf-rrg-ilnp-noncev6-03 IPv6 Nonce Destination Option for ILNPv6 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Brian Haberman o draft-irtf-rrg-ilnp-icmpv6-03 ICMP Locator Update message for ILNPv6 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Brian Haberman o draft-irtf-rrg-ilnp-icmpv4-03 ICMP Locator Update message for ILNPv4 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms o draft-irtf-rrg-ilnp-eng-03 ILNP Engineering Considerations (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Sean Turner o draft-irtf-rrg-ilnp-dns-03 DNS Resource Records for ILNP (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms o draft-irtf-rrg-ilnp-arch-03 ILNP Architectural Description (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Adrian Farrel o draft-irtf-rrg-ilnp-adv-03 Optional Advanced Deployment Scenarios for ILNP (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Stephen Farrell 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Simple Cloud Identity Management (scim) Token: Barry Leiba 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Protocol to Access WS database (paws) Token: Pete Resnick 4.2.2 Proposed for Approval o Behavior Engineering for Hindrance Avoidance (behave) Token: Wesley Eddy o Network File System Version 4 (nfsv4) Token: Martin Stiemerling o Multipath TCP (mptcp) Token: Wesley Eddy From bertietf@bwijnen.net Tue May 22 02:11: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 6868E21F852C for ; Tue, 22 May 2012 02:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyl9htC-+TLg for ; Tue, 22 May 2012 02:11:32 -0700 (PDT) Received: from relay57.tele2.vuurwerk.nl (relay57.tele2.vuurwerk.nl [62.250.3.57]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2A21F853C for ; Tue, 22 May 2012 02:11:32 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1SWl7m-0002Tl-5D; Tue, 22 May 2012 11:11:26 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Benoit Claise" , "Adrian Farrel" References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk><4FB38732.3060500@cisco.com> <4FBA1453.7020308@cisco.com> <4FBABE7E.3090203@cisco.com> In-Reply-To: <4FBABE7E.3090203@cisco.com> Date: Tue, 22 May 2012 11:11:20 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: manet-chairs@tools.ietf.org, "MIB Doctors \(E-mail\)" , draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 22 May 2012 09:11:33 -0000 This is by no means a full MIB review, but I did a quick SMICng SYNTAX check: W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification "nhdpNbrStateChange" is an index for a table W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification "nhdp2HopNbrStateChange" is an index for a table W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification "nhdpIfRxBadPacket" is anindex for a table W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification "nhdpIfStateChange" is anindex for a table W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup" in MANDATORY-GROUPS for module "NHDP-MIB" The first Warning got me to look at: nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE SYNTAX NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Removed Interface Address Set consists of Removed Interface Address Tuples, one per network address: (IR_local_iface_addr, IR_time) The association between these addrs and the router's Interface is found in the Standard MIB II's IP address table (RFC1213)." REFERENCE "RFC6130." INDEX { nhdpLibRemovedIfAddrSetIpAddrType, nhdpLibRemovedIfAddrSetIpAddr } ::= { nhdpLibRemovedIfAddrSetTable 1 } NhdpLibRemovedIfAddrSetEntry ::= SEQUENCE { nhdpLibRemovedIfAddrSetIpAddrType InetAddressType, nhdpLibRemovedIfAddrSetIpAddr InetAddress, nhdpLibRemovedIfAddrSetIpAddrPrefixLen InetAddressPrefixLength, nhdpLibRemovedIfAddrSetIfIndex InterfaceIndexOrZero, nhdpLibRemovedIfAddrSetIRTime TimeStamp } nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::= { nhdpLibRemovedIfAddrSetEntry 1 } nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpLibRemovedIfAddrSetIpAddr is a recently used address of an interface of this router." REFERENCE "RFC6130." ::= { nhdpLibRemovedIfAddrSetEntry 2 } And I note that: - the 2 INDEX obbjects are defined read-only. Normally they would be not-accessible!!! See RFC2578 - If this is ALWAYS true: nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." Then you could do: nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only Otherwise you would have to add something to description clause to warn implementers that they should consider OID size. The third warning: W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item Seems a valid warning. But I am not 100% sure. I'd have to go and study more detauil to determine. Anyways, these "inconsistent indexing" warnings are indeed just warnings. It may be OK, but it would be good to check and make sure that this results in proper (i.e. unique) indexing values and that the indexing is indeed as intended. Sorry, not enough time to check more details now. Bert ----- Original Message ----- From: "Benoit Claise" To: Cc: ; ; Sent: Tuesday, May 22, 2012 12:15 AM Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending > Dear all, > > I have deferred this draft for the next telechat. > > Regards, Benoit. >> Hi MIB doctors, >> >> We would really benefit from your expertise here. >> Can we please have a volunteer. >> If we don't find someone by the end of the day (on telechat for this >> Thursday), I'm afraid that I will have to defer this draft to the next >> telechat... >> >> Regards, Benoit. >> >>> Hi MIB doctors, >>> >>> My bad for not following up on this one. I will follow more closely from now >>> on. >>> Can we please have a volunteer to review this MIB module, which is on the >>> IESG telechat for next Thursday. >>> >>> Regards, Benoit. >>>> Hi MIB Doctors, >>>> >>>> Heads up to give you extra review time. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ is going to >>>> IETF >>>> last call very soon and would benefit significantly from a MIB Doctor >>>> review by >>>> the end of the last call. >>>> >>>> Thanks for the work you do. >>>> >>>> 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 From bclaise@cisco.com Tue May 22 03:31:00 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 975F621F853F for ; Tue, 22 May 2012 03:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGNfudnqlXfS for ; Tue, 22 May 2012 03:30:59 -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 6537421F853E for ; Tue, 22 May 2012 03:30:59 -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 q4MAPSnk026738; Tue, 22 May 2012 12:25:28 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MAPRIp010149; Tue, 22 May 2012 12:25:27 +0200 (CEST) Message-ID: <4FBB6997.6040108@cisco.com> Date: Tue, 22 May 2012 12:25:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FBABFF1.2010002@cisco.com> <4FBB3D9C.5000503@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 10:31:00 -0000 Dan, Bert, Dave, Thanks for your feedback. Let me try to decompose the problem into multiple smaller ones. 1. Require MIB doctor review BEFORE the IETF LC. I'll take that action item to stress this my fellow AD. This would allow some more time for planning the review,. 2. Finding a volunteer earlier on the process. I'll take the action item to follow up sooner in the process. 3. Learning a new technology, specifically from IETF RFCs and drafts, is time consuming (I've been learning that these days ;-) ), and could be a blocking factor to volunteer to review MIB modules. Let me propose something: let's request, part of the MIB doctor, a transfer of information webex, with the document authors and/or WG chairs and/or responsible AD. Basically, the message would be: "you want to benefit from the MIB-doctors expertise, teach them first your technology, and how you would like to manage it!" Personally, when I received a 1/2h introduction on a new technology, the documents were way more easier and time-consuming to read. I could enforce this new rule. 4. MIB doctor team composition: clean-up required? It would be ideal to only have active reviewers on the list. However, if all the participants are contributing one way or the other (libsmi, answering questions occasionally), we should keep everybody in the list. If someone would like to opt-out, let me know. 5. Growing the MIB doctor team. If you have some names or mailing list in mind, let me know. I will send this request internally in my company: we have our internal MIB-police team. Maybe, we'll get one extra person... 6. Fair distribution of load I could keep a history of the distribution, if that helps. Please share your thoughts. Regards, Benoit. > Hi Benoit, > > My perspective is very close to Bert's and David's. Indeed, proper MIB > Doctor review requires good understanding or fast learning of the > technology that is supposed to be managed, and this takes time. I would > argue that you need this also for a proper security or OPS review, but > the argument is marginal for what we discuss here. For that reason while > I was on the IESG I asked my fellow ADs to require MIB doctor review > BEFORE the IETF LC, so that the search for a MIB Doctor starts earlier > than the moment the Last Call sand-clock (typically two or four weeks) > is runing. You may want to do the same. > > Concerning the MIB Doctors team composition. I did a clean-up a few > years ago and the remaining members were those who committed to continue > to be active with a couple of exceptions - Frank Strauss was never an > active reviewer but he contributed the libsmi, Mike Heard and Andy > Bierman said that they did not have the time for reviews but would stay > on the list and answers questions occasionally, which they did now and > then and this was useful. You may want to do another round of questions, > see who wants to stay active, who opts out. Harrie actually answered at > least one call for reviewers in the last year, you can also add my name > to the list, with eight active reviewers the situation is not that bad, > this will lead to 2-3 reviews each year. You can of course try to > recruit new participants. > > You may move from a asking for volunteers model to a round-robin > assignment, or at least use such an algorithm if a volunteer does not > show up after a few days. > > Concerning the style of the reviews, I am again agreeing to what Bert > and David say, and I would add that in my reviews I also ask about the > need to reduce complexity hence the number of objects so that the agent > code can be implemented and the manager can access easily the objects > essential to the day-to-day operations. > > Concerning this MIB module - Bob Cole consulted with me, maybe also with > other MIB doctors while in design phase, so there was some level of > exposure and discussions prior to the MIB module hitting the IESG. > > I hope this helps. > > Regards, > > Dan > > >> -----Original Message----- >> From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- >> bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) >> Sent: Tuesday, May 22, 2012 10:18 AM >> To: Benoit Claise >> Cc: MIB Doctors (E-mail); Ron Bonica >> Subject: Re: [MIB-DOCTORS] Volunteers for MIB review >> >> Hi Benoit. >> >> Last week, and also coming weeks I am pretty busy, so I could >> not step up. Yet I did a very quick browse through the document, >> but this was basically to do a first assessment if the MIB is >> in really bad state (in which case there will be a lot of work >> and a long period during which the work may come back) or in >> reasonable shape, in which case the work is far less and may not >> take too long to come to closure. >> This MIB document seems quite reasonable at first sight. >> But still it will take some time to do a proper review. >> >> I also saw DBH comments/explanation. >> I think it would be good if we could do such in depth reviews as >> Dave suggests, but at the other hand, I feel that it is subject >> matter experts that need to worry about a lot of the topics >> about design and impact on the technology. >> I know that when I do a review, that I often dive somewhat into the >> documents that describe the technology, and then sometimes that raises >> questions that I will pose and that causes follow up etc. >> >> When I was AD, and when/if I couldn't get reviewers (although at the >> time we had a larger base of *active* MIB doctors), then I would do >> the basic checks myself, make sure SYNTAX was OK, make sure there >> were no gaping holes. That sometimes (actually often) took quite some >> time. Yep... I understand. >> >> But even if you get to this stage, I am not sure you absolutely have > to >> go into as much details as Dave suggests. There are (after all) so > many >> different technologies in IETF that it is kind of impossible to >> understand them all in great detail. >> I guess that is up to you to decide. >> >> Maybe Dan has some perspective here as well. >> >> Bert >> >> On 5/22/12 12:21 AM, Benoit Claise wrote: >>> Dear all, >>> >>> [restricting the email to just mib-doctors] >>> >>> First of all, my apologies for not following up the email from > Adrian >> on March 29th, subject "Heads-up MIB review impending". >>> This concerns the MIB doctor review of >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ >>> >>> Now, how do we share the load amongst MIB doctors? >>> - round robin? >>> - we keep track of history and ask a specific person (like Tina Tsu >> does for OPS-DIR). I could do that job >>> - I just an email to the list, asking for a volunteer? >>> - something else? >>> >>> Please let me know. >>> Also, we really need a reviewer for >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ >>> Regards, Benoit. >>> >>> >>> _______________________________________________ >>> 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 dromasca@avaya.com Tue May 22 03:57:27 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 4EEF621F8593 for ; Tue, 22 May 2012 03:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQTYkcagY7B0 for ; Tue, 22 May 2012 03:57:26 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4131221F857F for ; Tue, 22 May 2012 03:57:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUMAGxwu0+HCzI1/2dsb2JhbABErE2HRYEHghUBAQEBAgEBAQEPCxMKMQIBBgUFBwQCAQgNAQMEAQEBCgYMCwEGASYfCQgBAQQKCQgah2cFC6B6nRgEiwgZhEFiA5sMiX+Ca4Fd X-IronPort-AV: E=Sophos;i="4.75,638,1330923600"; d="scan'208";a="348856312" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 May 2012 06:55:45 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2012 06:39:40 -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: Tue, 22 May 2012 12:57:21 +0200 Message-ID: In-Reply-To: <4FBB6997.6040108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Volunteers for MIB review Thread-Index: Ac04BTgIEJaINIL3R7WdUhZbdboYsAABAeLg References: <4FBABFF1.2010002@cisco.com> <4FBB3D9C.5000503@bwijnen.net> <4FBB6997.6040108@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 10:57:27 -0000 Hi Benoit,=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, May 22, 2012 1:25 PM > To: Romascanu, Dan (Dan) > Cc: Bert Wijnen (IETF); MIB Doctors (E-mail); Ron Bonica > Subject: Re: [MIB-DOCTORS] Volunteers for MIB review >=20 > Dan, Bert, Dave, >=20 > Thanks for your feedback. > Let me try to decompose the problem into multiple smaller ones. >=20 > 1. Require MIB doctor review BEFORE the IETF LC. > I'll take that action item to stress this my fellow AD. > This would allow some more time for planning the review,. >=20 > 2. Finding a volunteer earlier on the process. > I'll take the action item to follow up sooner in the process. >=20 > 3. Learning a new technology, specifically from IETF RFCs and drafts, > is > time consuming (I've been learning that these days ;-) ), and could be > a > blocking factor to volunteer to review MIB modules. > Let me propose something: let's request, part of the MIB doctor, a > transfer of information webex, with the document authors and/or WG > chairs and/or responsible AD. Basically, the message would be: "you > want > to benefit from the MIB-doctors expertise, teach them first your > technology, and how you would like to manage it!" > Personally, when I received a 1/2h introduction on a new technology, > the > documents were way more easier and time-consuming to read. I could > enforce this new rule. >=20 [[DR]] I would be cautious to ask too much upfront, people may be discouraged, we do not want that to happen. Rather work on a case-to-case mode, some people will already have some knowledge, other need to ask, some may get help without bothering you, let us use AD escalation only when requests for private transfer of information are not answered. > 4. MIB doctor team composition: clean-up required? > It would be ideal to only have active reviewers on the list. However, > if > all the participants are contributing one way or the other (libsmi, > answering questions occasionally), we should keep everybody in the > list. > If someone would like to opt-out, let me know. >=20 [[DR]] Maybe you should ask folks who did not participate in any discussion in the last few years whether they are still interested to be on the list. I did not see any contribution from Steve Waldbusser or Sharon Chisholm for many years. If you send them such messages either a. the address bounces and you take them out, or b. they say they opt out, the same, or c. they say they want to stay and maybe even get a review from time to time. > 5. Growing the MIB doctor team. > If you have some names or mailing list in mind, let me know. > I will send this request internally in my company: we have our internal > MIB-police team. Maybe, we'll get one extra person... >=20 [[DR]] Maybe Bob Cole could be recruited. Is Randy Presuhn a MIB Doctor? Worth asking him if he is not.=20 > 6. Fair distribution of load > I could keep a history of the distribution, if that helps. >=20 > Please share your thoughts. >=20 > Regards, Benoit. >=20 >=20 > > Hi Benoit, > > > > My perspective is very close to Bert's and David's. Indeed, proper > MIB > > Doctor review requires good understanding or fast learning of the > > technology that is supposed to be managed, and this takes time. I > would > > argue that you need this also for a proper security or OPS review, > but > > the argument is marginal for what we discuss here. For that reason > while > > I was on the IESG I asked my fellow ADs to require MIB doctor review > > BEFORE the IETF LC, so that the search for a MIB Doctor starts > earlier > > than the moment the Last Call sand-clock (typically two or four > weeks) > > is runing. You may want to do the same. > > > > Concerning the MIB Doctors team composition. I did a clean-up a few > > years ago and the remaining members were those who committed to > continue > > to be active with a couple of exceptions - Frank Strauss was never an > > active reviewer but he contributed the libsmi, Mike Heard and Andy > > Bierman said that they did not have the time for reviews but would > stay > > on the list and answers questions occasionally, which they did now > and > > then and this was useful. You may want to do another round of > questions, > > see who wants to stay active, who opts out. Harrie actually answered > at > > least one call for reviewers in the last year, you can also add my > name > > to the list, with eight active reviewers the situation is not that > bad, > > this will lead to 2-3 reviews each year. You can of course try to > > recruit new participants. > > > > You may move from a asking for volunteers model to a round-robin > > assignment, or at least use such an algorithm if a volunteer does not > > show up after a few days. > > > > Concerning the style of the reviews, I am again agreeing to what Bert > > and David say, and I would add that in my reviews I also ask about > the > > need to reduce complexity hence the number of objects so that the > agent > > code can be implemented and the manager can access easily the objects > > essential to the day-to-day operations. > > > > Concerning this MIB module - Bob Cole consulted with me, maybe also > with > > other MIB doctors while in design phase, so there was some level of > > exposure and discussions prior to the MIB module hitting the IESG. > > > > I hope this helps. > > > > Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > >> bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > >> Sent: Tuesday, May 22, 2012 10:18 AM > >> To: Benoit Claise > >> Cc: MIB Doctors (E-mail); Ron Bonica > >> Subject: Re: [MIB-DOCTORS] Volunteers for MIB review > >> > >> Hi Benoit. > >> > >> Last week, and also coming weeks I am pretty busy, so I could > >> not step up. Yet I did a very quick browse through the document, > >> but this was basically to do a first assessment if the MIB is > >> in really bad state (in which case there will be a lot of work > >> and a long period during which the work may come back) or in > >> reasonable shape, in which case the work is far less and may not > >> take too long to come to closure. > >> This MIB document seems quite reasonable at first sight. > >> But still it will take some time to do a proper review. > >> > >> I also saw DBH comments/explanation. > >> I think it would be good if we could do such in depth reviews as > >> Dave suggests, but at the other hand, I feel that it is subject > >> matter experts that need to worry about a lot of the topics > >> about design and impact on the technology. > >> I know that when I do a review, that I often dive somewhat into the > >> documents that describe the technology, and then sometimes that > raises > >> questions that I will pose and that causes follow up etc. > >> > >> When I was AD, and when/if I couldn't get reviewers (although at the > >> time we had a larger base of *active* MIB doctors), then I would do > >> the basic checks myself, make sure SYNTAX was OK, make sure there > >> were no gaping holes. That sometimes (actually often) took quite > some > >> time. Yep... I understand. > >> > >> But even if you get to this stage, I am not sure you absolutely have > > to > >> go into as much details as Dave suggests. There are (after all) so > > many > >> different technologies in IETF that it is kind of impossible to > >> understand them all in great detail. > >> I guess that is up to you to decide. > >> > >> Maybe Dan has some perspective here as well. > >> > >> Bert > >> > >> On 5/22/12 12:21 AM, Benoit Claise wrote: > >>> Dear all, > >>> > >>> [restricting the email to just mib-doctors] > >>> > >>> First of all, my apologies for not following up the email from > > Adrian > >> on March 29th, subject "Heads-up MIB review impending". > >>> This concerns the MIB doctor review of > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > >>> > >>> Now, how do we share the load amongst MIB doctors? > >>> - round robin? > >>> - we keep track of history and ask a specific person (like Tina Tsu > >> does for OPS-DIR). I could do that job > >>> - I just an email to the list, asking for a volunteer? > >>> - something else? > >>> > >>> Please let me know. > >>> Also, we really need a reviewer for > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > >>> Regards, Benoit. > >>> > >>> > >>> _______________________________________________ > >>> 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 dromasca@avaya.com Tue May 22 05:21: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 7868D21F85F6; Tue, 22 May 2012 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ1NmIlhRJc8; Tue, 22 May 2012 05:21:19 -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 8779F21F846C; Tue, 22 May 2012 05:21:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGuDu0+HCzI1/2dsb2JhbABDtBKBB4IVAQEBAQIBAQEBDx4KLQcLBQcEAgEIDQQEAQELAgQMCwEGASYfCQgBAQQTCAESB4dnBQucOp0aiwgZhEFiA5sMiX+Ca4Fd X-IronPort-AV: E=Sophos;i="4.75,638,1330923600"; d="scan'208";a="307581510" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 May 2012 08:19:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2012 08:03:31 -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: Tue, 22 May 2012 14:21:10 +0200 Message-ID: In-Reply-To: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) Thread-Index: Ac0yw5+43gY6yitHR8y91/PDlWeIXgFUImpw References: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> From: "Romascanu, Dan (Dan)" To: Cc: "MIB Doctors \(E-mail\)" , IETF IPFIX Working Group Subject: Re: [MIB-DOCTORS] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) 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, 22 May 2012 12:21:20 -0000 Hi,=20 Two comments:=20 1. If I got it right, Information Elements will be defined specifically to meet logging requirements. It would be good to be explicit on this in the deliverables list as well.=20 2. It is not clear what the plans are concerning the MIB module(s). Will there be two separate MIB modules to be used as needed with the existing MIB module defined in RFC 4008? Or eventually there will be one MIB module that updates the one defined in 4008 and adds NAT64 and CGNs capabilities.=20 Thanks and Regards, Dan > -----Original Message----- > From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On > Behalf Of IESG Secretary > Sent: Tuesday, May 15, 2012 8:53 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Recharter of Behavior Engineering > forHindrance Avoidance (behave) >=20 > A modified charter has been submitted for the Behavior Engineering for > Hindrance Avoidance (behave) working group in the Transport Area of the > IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May > 22, 2012. >=20 > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active > Last updated: 2012-05-10 >=20 > Chairs: > Dan Wing > Dave Thaler >=20 > Transport Area Directors: > Wesley Eddy > Martin Stiemerling >=20 > Transport Area Advisor: > Wesley Eddy >=20 > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/behave > Archive: http://www.ietf.org/mail-archive/web/behave >=20 > Description of Working Group >=20 > The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 > NATs to function in as deterministic a fashion as possible. >=20 > To support deployments where communicating hosts require using > different address families (IPv4 or IPv6), address family translation > is > needed to establish communication. In BEHAVE's specification work on > this topic it will coordinate with the V6ops WG on requirements and > operational considerations. >=20 > "An IPv4 network" or "an IPv6 network" in the descriptions below refer > to a network with a clearly identifiable administrative domain (e.g., > an > enterprise campus network, a mobile operator's cellular network, a > residential subscriber network, etc.). It will also be that network > that > deploys the necessary equipment for translation. >=20 > BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 > Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network > to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >=20 > Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible. >=20 > In addition, when a NAT (such as a NAT64 in the "An IPv6 network to > IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber > fairness issues arise. As such, BEHAVE will complete its work on > Carrier Grade NAT requirements for such scenarios, and update the NAT > MIB as needed to meet such requirements. BEHAVE will not, however, > standardize IPv4-specific behavioral mechanisms. >=20 > The following scenarios remain in scope for discussion, but will not be > solved by BEHAVE: >=20 > * An IPv4 network to IPv6 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network using either > public or private IPv4 address space. >=20 > * IPv4 Internet to an IPv6 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network where selected > IPv6 hosts and services are to be reachable. >=20 > This group will also provide reviews of any work by the MBoneD WG on > multicast translation, including control traffic (IGMP and MLD), > Single > Source Multicast (SSM) and Any Source Multicast (ASM). >=20 > If the WG deems it necessary, BEHAVE will revise RFCs previously > published by BEHAVE. >=20 > Goals and Milestones >=20 > Done Submit BCP that defines unicast UDP behavioral requirements for > NATs to IESG > Done Submit a BCP that defines TCP behavioral requirements for NATs > to IESG > Done Submit a BCP that defines ICMP behavioral requirements for NATs > to IESG > Done Submit informational that discusses current NAT traversal > techniques used by applications > Done Submit BCP that defines multicast UDP > Done Submit revision of RFC 3489 to IESG behavioral requirements for > NATs to IESG > Done Submit informational document for rfc3489bis test vectors > Done Submit experimental document that describes how an application > can determine the type of NAT it is behind > Done Submit BCP document for DCCP NAT behavior > Done Determine relative prioritization of the four translation cases. > Documented in IETF74 minutes. > Done Determine what solutions(s) and components are needed to solve > each of the four cases. Create new milestones for the > solution(s) and the components. Documented in IETF74 minutes. > Done Submit to IESG: relaying of a TCP bytestream (std) > Done Submit to IESG: relay protocol (std) > Done Submit to IESG: TURN-URI document (std) > Done Submit to IESG: IPv6 relay protocol (std) > Done Submit to IESG: framework for IPv6/IPv4 translation (info) > Done Submit to IESG: stateless IPv6/IPv4 translation (std) > Done Submit to IESG: stateful IPv6/IPv4 translation (std) > Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > Done Determine need and scope of multicast 6/4 translation > Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > Jul 2012 Submit to IESG: large scale NAT requirements (BCP) > Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 > translation (info) > Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for > local networks (std) > Done Submit to IESG: host-based NAT46 translation for IPv4-only > applications to access IPv6-only servers (std) > Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) > Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) > Nov 2012 Submit to IESG: IPFIX information elements (std) > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work From bclaise@cisco.com Tue May 22 09:02: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 70EFF21F864D for ; Tue, 22 May 2012 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNbTXRS+Kffl for ; Tue, 22 May 2012 09:02:20 -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 9AB9B21F861E for ; Tue, 22 May 2012 09:02:19 -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 q4MG2IsI006720 for ; Tue, 22 May 2012 18:02:18 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MG2G1O022285; Tue, 22 May 2012 18:02:17 +0200 (CEST) Message-ID: <4FBBB887.2030805@cisco.com> Date: Tue, 22 May 2012 18:02:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [MIB-DOCTORS] A new MIB doctor: Patrick Gilii 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, 22 May 2012 16:02:20 -0000 Dear all, I've very happy to announce that we have a new MIB doctor: Patrick Gili. Does he know about MIB? Oh yes! When I asked Patrick to volunteer for the MIB doctor work, his answer was: "I wouldn’t mind reviewing a few more MIB modules a year (I think I review about 600 a year through the mib-police)" Note: mib-police is the Cisco internal process equivalent to MIB doctors. Thanks Patrick. Regards, Benoit. From j.schoenwaelder@jacobs-university.de Tue May 22 09:05: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 11E5721F85C9 for ; Tue, 22 May 2012 09:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3u0o-YXSqui for ; Tue, 22 May 2012 09:05:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 355D921F855D for ; Tue, 22 May 2012 09:05:47 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8828920C19; Tue, 22 May 2012 18:05:46 +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 HDc0kz7fGJcs; Tue, 22 May 2012 18:05:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FD9120AFA; Tue, 22 May 2012 18:05:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 58CD41F239F1; Tue, 22 May 2012 18:05:45 +0200 (CEST) Date: Tue, 22 May 2012 18:05:45 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120522160545.GA26870@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" References: <4FBBB887.2030805@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FBBB887.2030805@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] A new MIB doctor: Patrick Gilii 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: Tue, 22 May 2012 16:05:48 -0000 On Tue, May 22, 2012 at 06:02:15PM +0200, Benoit Claise wrote: > Dear all, > > I've very happy to announce that we have a new MIB doctor: Patrick Gili. > Does he know about MIB? Oh yes! When I asked Patrick to volunteer > for the MIB doctor work, his answer was: "I wouldn’t mind reviewing > a few more MIB modules a year (I think I review about 600 a year > through the mib-police)" This is more than 2 MIB modules per work day. Really? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue May 22 09:13: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 5BB6621F8606 for ; Tue, 22 May 2012 09:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdOXs8iWeboT for ; Tue, 22 May 2012 09:13:05 -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 A592E21F85F9 for ; Tue, 22 May 2012 09:13:04 -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 q4MGD3lP007867 for ; Tue, 22 May 2012 18:13:03 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MGD01d000313; Tue, 22 May 2012 18:13:00 +0200 (CEST) Message-ID: <4FBBBB0C.5060605@cisco.com> Date: Tue, 22 May 2012 18:13:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <4FBBB887.2030805@cisco.com> In-Reply-To: <4FBBB887.2030805@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MIB-DOCTORS] A new MIB doctor: Patrick Gilii -> Patrick Gili 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, 22 May 2012 16:13:05 -0000 Sorry Patrick Gili for misspelling your name :-( Regards, Benoit. > Dear all, > > I've very happy to announce that we have a new MIB doctor: Patrick Gili. > Does he know about MIB? Oh yes! When I asked Patrick to volunteer for > the MIB doctor work, his answer was: "I wouldn’t mind reviewing a few > more MIB modules a year (I think I review about 600 a year through the > mib-police)" > Note: mib-police is the Cisco internal process equivalent to MIB doctors. > > Thanks Patrick. > > Regards, Benoit. > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From andy@netconfcentral.org Tue May 22 10: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 20EF521F867B for ; Tue, 22 May 2012 10:08: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ6e4L9VcmhU for ; Tue, 22 May 2012 10:08:50 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4262321F867A for ; Tue, 22 May 2012 10:08:49 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4MH8n17006570 for ; Tue, 22 May 2012 13:08:49 -0400 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.168.164] ([75.84.168.164:43144] helo=[192.168.0.167]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 58/B7-11572-028CBBF4; Tue, 22 May 2012 13:08:49 -0400 Message-ID: <4FBBC821.4010809@netconfcentral.org> Date: Tue, 22 May 2012 10:08:49 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Benoit Claise References: <4FBBB887.2030805@cisco.com> In-Reply-To: <4FBBB887.2030805@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] A new MIB doctor: Patrick Gilii 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, 22 May 2012 17:08:51 -0000 On 05/22/2012 09:02 AM, Benoit Claise wrote: > Dear all, > > I've very happy to announce that we have a new MIB doctor: Patrick Gili. > Does he know about MIB? Oh yes! When I asked Patrick to volunteer for the MIB doctor work, his answer was: "I wouldn’t mind reviewing a few more MIB modules a year (I think I review about 600 a year > through the mib-police)" > Note: mib-police is the Cisco internal process equivalent to MIB doctors. > Welcome aboard. Thanks for taking over this difficult job. (I literally had to quit my job to leave Cisco mib-police ;-) I told Karen Donoghue I will review the TIC-TOC MIB, which will be my first MIB review in years! I suppose if you ran "smilint -format=yang" on the MIB modules, you could trick me into reviewing MIBs by pretending they are YANG modules :-) > Thanks Patrick. > > Regards, Benoit. > Andy From bertietf@bwijnen.net Tue May 22 11:33:27 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 0CC4621F8645 for ; Tue, 22 May 2012 11:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn533O8eHp0I for ; Tue, 22 May 2012 11:33:26 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B521F85E6 for ; Tue, 22 May 2012 11:33:24 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SWttX-0003V7-Bi; Tue, 22 May 2012 20:33:21 +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 1SWttX-0002hw-46; Tue, 22 May 2012 20:33:19 +0200 Message-ID: <4FBBDBEE.5070104@bwijnen.net> Date: Tue, 22 May 2012 20:33:18 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ulrich Herberg References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> <4FB38732.3060500@cisco.com> <4FBA1453.7020308@cisco.com> <4FBABE7E.3090203@cisco.com> In-Reply-To: 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 #7816066, check: 20120522 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: 86ab03e524994f79ca2c75a176445dd4c921d51e545af8b413aed4934a7a332e Cc: Adrian Farrel , draft-ietf-manet-nhdp-mib@tools.ietf.org, manet-chairs@tools.ietf.org, "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 22 May 2012 18:33:27 -0000 Unfortunately, there is not a free version (at least not current) available as far as I know. I don;t understand why the author does not just make it open source and available to everyone. But that is his call I guess. Oh by the way, you also already user { mib-2 998 } for the MIB OID!!! that is not proper! You should use xxx or some such instead of 998 (as you indicate in the rfc-editor comment ;-) Bert On 5/22/12 7:03 PM, Ulrich Herberg wrote: > Bert, > > thank you very much for this first review. We will work on fixing these and spin a new version. > > By the way, is there a free version of SMICng available? I only have smilint. > > Best regards > Ulrich > > On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) > wrote: > > This is by no means a full MIB review, but I did a quick SMICng SYNTAX check: > > W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing > that may create variables with more than 128 sub-ids > W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that may > create variables with more than 128 sub-ids > W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a > consistent indexing scheme - index item nhdpDiscIfIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a > consistent indexing scheme - index item nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not have > a consistent indexing scheme - index item nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a > consistent indexing scheme - index item nhdpDiscIfIndex from base row > nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not > have a consistent indexing scheme - index item nhdpDiscRouterIndex from > base row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a > consistent indexing scheme - index item nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification > "nhdpNbrStateChange" is an index for a table > W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification > "nhdp2HopNbrStateChange" is an index for a table > W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification > "nhdpIfRxBadPacket" is anindex for a table > W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification > "nhdpIfStateChange" is anindex for a table > W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup" > in MANDATORY-GROUPS for module "NHDP-MIB" > > > The first Warning got me to look at: > nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE > SYNTAX NhdpLibRemovedIfAddrSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A router's Removed Interface Address Set consists > of Removed Interface Address Tuples, one per network > address: > > (IR_local_iface_addr, IR_time) > > The association between these addrs and > the router's Interface is found in the > > Standard MIB II's IP address table > (RFC1213)." > REFERENCE > "RFC6130." > INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype, > nhdpLibRemovedIfAddrSetIpAddr } > ::= { nhdpLibRemovedIfAddrSetTable 1 } > > NhdpLibRemovedIfAddrSetEntry ::= > SEQUENCE { > nhdpLibRemovedIfAddrSetIpAddrT__ype > InetAddressType, > nhdpLibRemovedIfAddrSetIpAddr > InetAddress, > nhdpLibRemovedIfAddrSetIpAddrP__refixLen > InetAddressPrefixLength, > nhdpLibRemovedIfAddrSetIfIndex > InterfaceIndexOrZero, > nhdpLibRemovedIfAddrSetIRTime > TimeStamp > } > > nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the nhdpLibRemovedIfAddrSetIpAddr > in the InetAddress MIB (RFC4001). > > Only the values ipv4(1) and > ipv6(2) are supported." > REFERENCE > "RFC6130." > ::= { nhdpLibRemovedIfAddrSetEntry 1 } > > nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "nhdpLibRemovedIfAddrSetIpAddr is a > recently used address of an interface of > this router." > REFERENCE > "RFC6130." > ::= { nhdpLibRemovedIfAddrSetEntry 2 } > > And I note that: > > - the 2 INDEX obbjects are defined read-only. Normally they would be > not-accessible!!! See RFC2578 > - If this is ALWAYS true: > nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the nhdpLibRemovedIfAddrSetIpAddr > in the InetAddress MIB (RFC4001). > > Only the values ipv4(1) and > ipv6(2) are supported." > Then you could do: > nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(4|16)) > MAX-ACCESS read-only > Otherwise you would have to add something to description clause to > warn implementers that they should consider OID size. > > The third warning: > W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a > consistent indexing scheme - index item nhdpDiscIfIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > Seems a valid warning. But I am not 100% sure. I'd have to go and study > more detauil to determine. > Anyways, these "inconsistent indexing" warnings are indeed just > warnings. It may be OK, but it would be good to check and make sure > that this results in proper (i.e. unique) indexing values and that the > indexing is indeed as intended. > > Sorry, not enough time to check more details now. > > Bert > > ----- Original Message ----- From: "Benoit Claise" > > > To: > > Cc: >; >; > > > Sent: Tuesday, May 22, 2012 12:15 AM > > Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending > > > Dear all, > > I have deferred this draft for the next telechat. > > Regards, Benoit. > > Hi MIB doctors, > > We would really benefit from your expertise here. > Can we please have a volunteer. > If we don't find someone by the end of the day (on telechat for this > Thursday), I'm afraid that I will have to defer this draft to the next > telechat... > > Regards, Benoit. > > Hi MIB doctors, > > My bad for not following up on this one. I will follow more closely from now > on. > Can we please have a volunteer to review this MIB module, which is on the > IESG telechat for next Thursday. > > Regards, Benoit. > > Hi MIB Doctors, > > Heads up to give you extra review time. > > https://datatracker.ietf.org/__doc/draft-ietf-manet-nhdp-mib/ > is going to > IETF > last call very soon and would benefit significantly from a MIB Doctor > review by > the end of the last call. > > Thanks for the work you do. > > 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 > > > From tnadeau@juniper.net Tue May 22 11:35:59 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 450F921F8685 for ; Tue, 22 May 2012 11:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R64+wvHD2uQa for ; Tue, 22 May 2012 11:35:58 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1E21F867E for ; Tue, 22 May 2012 11:35:57 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT7vcjHb6DvRzZielcdVlCTJelZ4G3+rm@postini.com; Tue, 22 May 2012 11:35:58 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 May 2012 11:35:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 22 May 2012 14:34:35 -0400 From: Thomas Nadeau To: Benoit Claise , "MIB Doctors (E-mail)" Date: Tue, 22 May 2012 14:34:34 -0400 Thread-Topic: A new MIB doctor: Tom Nadeau Thread-Index: Ac04SYmg20sB5ETDTHyoyFb3Smr/xA== Message-ID: In-Reply-To: <4FBBDBD7.8090906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica Subject: Re: [MIB-DOCTORS] A new MIB doctor: Tom Nadeau 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, 22 May 2012 18:35:59 -0000 I too like Patrick and Andy, used to be a Cisco MIB Doctor and couldn't escape that job really until I left the company. Now it seems to have found me again. *) Anyways, glad to help out when I can. Look forward to working with you all. --Tom On 5/22/12 2:32 PM, "Benoit Claise" wrote: >Dear all, > >I've very happy to announce that we have a new MIB doctor: Tom Nadeau >Tom has been writing many MIB modules, even if he tries to hide himself >under different names ;-) > http://www.arkko.com/tools/allstats/thomasd.nadeau.html > http://www.arkko.com/tools/allstats/thomasnadeau.html > http://www.arkko.com/tools/allstats/tomnadeau.html > >Thanks Tom for volunteering > >Regards, Benoit. > From bclaise@cisco.com Tue May 22 11:44:14 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 4325B21F8618 for ; Tue, 22 May 2012 11:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4RSmyRpJNLq for ; Tue, 22 May 2012 11:44:13 -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 B4AC221F861A for ; Tue, 22 May 2012 11:44:12 -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 q4MIWu4a021513; Tue, 22 May 2012 20:32:56 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MIWtnJ022727; Tue, 22 May 2012 20:32:55 +0200 (CEST) Message-ID: <4FBBDBD7.8090906@cisco.com> Date: Tue, 22 May 2012 20:32:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <4FBBBB0C.5060605@cisco.com> In-Reply-To: <4FBBBB0C.5060605@cisco.com> X-Forwarded-Message-Id: <4FBBBB0C.5060605@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: [MIB-DOCTORS] A new MIB doctor: Tom Nadeau 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, 22 May 2012 18:44:14 -0000 Dear all, I've very happy to announce that we have a new MIB doctor: Tom Nadeau Tom has been writing many MIB modules, even if he tries to hide himself under different names ;-) http://www.arkko.com/tools/allstats/thomasd.nadeau.html http://www.arkko.com/tools/allstats/thomasnadeau.html http://www.arkko.com/tools/allstats/tomnadeau.html Thanks Tom for volunteering Regards, Benoit. From adrian@olddog.co.uk Tue May 22 13:57: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 9125A21F86A3 for ; Tue, 22 May 2012 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXz6eDfwDR7b for ; Tue, 22 May 2012 13:57:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8F821F8692 for ; Tue, 22 May 2012 13:57:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4MKvkIM018870; Tue, 22 May 2012 21:57:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4MKvfeT018838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 May 2012 21:57:44 +0100 From: "Adrian Farrel" To: "'Ulrich Herberg'" , "'Bert Wijnen \(IETF\)'" References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> <4FB38732.3060500@cisco.com> <4FBA1453.7020308@cisco.com> <4FBABE7E.3090203@cisco.com> <4FBBDBEE.5070104@bwijnen.net> In-Reply-To: Date: Tue, 22 May 2012 21:57:39 +0100 Message-ID: <165b01cd385d$88067150$981353f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_165C_01CD3865.E9D47640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFd470jgM2PCzBnlk+1C+U2/PHhDwHUZ33SAfJnvh4ChNO7FgLW+jIXAolN81MCQoHtMwK0le5wly/ag7A= Content-Language: en-gb Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-nhdp-mib@tools.ietf.org, "'MIB Doctors \(E-mail\)'" Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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: Tue, 22 May 2012 20:57:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_165C_01CD3865.E9D47640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ulrich, just in case you are no aware of http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/ Adrian From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: 22 May 2012 19:37 To: Bert Wijnen (IETF) Cc: Benoit Claise; Adrian Farrel; manet-chairs@tools.ietf.org; MIB Doctors (E-mail); draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending Bert, On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) wrote: Unfortunately, there is not a free version (at least not current) available as far as I know. I don;t understand why the author does not just make it open source and available to everyone. But that is his call I guess. Okay, I see. My company will likely not pay for that, and personally I'd rather go to vacations than buy a MIB compiler ;-) Oh by the way, you also already user { mib-2 998 } for the MIB OID!!! that is not proper! You should use xxx or some such instead of 998 (as you indicate in the rfc-editor comment ;-) I know, that has been discovered in the IESG LC. The reason why we did not put xxxx there is that smilint complains otherwise and fails to compile. It will be fixed in the next revision of the draft (or in the RFC editor queue). Best Ulrich Bert On 5/22/12 7:03 PM, Ulrich Herberg wrote: Bert, thank you very much for this first review. We will work on fixing these and spin a new version. By the way, is there a free version of SMICng available? I only have smilint. Best regards Ulrich On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) > wrote: This is by no means a full MIB review, but I did a quick SMICng SYNTAX check: W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification "nhdpNbrStateChange" is an index for a table W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification "nhdp2HopNbrStateChange" is an index for a table W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification "nhdpIfRxBadPacket" is anindex for a table W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification "nhdpIfStateChange" is anindex for a table W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup" in MANDATORY-GROUPS for module "NHDP-MIB" The first Warning got me to look at: nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE SYNTAX NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Removed Interface Address Set consists of Removed Interface Address Tuples, one per network address: (IR_local_iface_addr, IR_time) The association between these addrs and the router's Interface is found in the Standard MIB II's IP address table (RFC1213)." REFERENCE "RFC6130." INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype, nhdpLibRemovedIfAddrSetIpAddr } ::= { nhdpLibRemovedIfAddrSetTable 1 } NhdpLibRemovedIfAddrSetEntry ::= SEQUENCE { nhdpLibRemovedIfAddrSetIpAddrT__ype InetAddressType, nhdpLibRemovedIfAddrSetIpAddr InetAddress, nhdpLibRemovedIfAddrSetIpAddrP__refixLen InetAddressPrefixLength, nhdpLibRemovedIfAddrSetIfIndex InterfaceIndexOrZero, nhdpLibRemovedIfAddrSetIRTime TimeStamp } nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::= { nhdpLibRemovedIfAddrSetEntry 1 } nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpLibRemovedIfAddrSetIpAddr is a recently used address of an interface of this router." REFERENCE "RFC6130." ::= { nhdpLibRemovedIfAddrSetEntry 2 } And I note that: - the 2 INDEX obbjects are defined read-only. Normally they would be not-accessible!!! See RFC2578 - If this is ALWAYS true: nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." Then you could do: nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only Otherwise you would have to add something to description clause to warn implementers that they should consider OID size. The third warning: W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item Seems a valid warning. But I am not 100% sure. I'd have to go and study more detauil to determine. Anyways, these "inconsistent indexing" warnings are indeed just warnings. It may be OK, but it would be good to check and make sure that this results in proper (i.e. unique) indexing values and that the indexing is indeed as intended. Sorry, not enough time to check more details now. Bert ----- Original Message ----- From: "Benoit Claise" > To: > Cc: >; >; > Sent: Tuesday, May 22, 2012 12:15 AM Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending Dear all, I have deferred this draft for the next telechat. Regards, Benoit. Hi MIB doctors, We would really benefit from your expertise here. Can we please have a volunteer. If we don't find someone by the end of the day (on telechat for this Thursday), I'm afraid that I will have to defer this draft to the next telechat... Regards, Benoit. Hi MIB doctors, My bad for not following up on this one. I will follow more closely from now on. Can we please have a volunteer to review this MIB module, which is on the IESG telechat for next Thursday. Regards, Benoit. Hi MIB Doctors, Heads up to give you extra review time. https://datatracker.ietf.org/__doc/draft-ietf-manet-nhdp-mib/ is going to IETF last call very soon and would benefit significantly from a MIB Doctor review by the end of the last call. Thanks for the work you do. 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 ------=_NextPart_000_165C_01CD3865.E9D47640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ulrich,

 

just in case you are no aware = of = http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/

 

Adrian

 

From: Ulrich Herberg = [mailto:ulrich@herberg.name]
Sent: 22 May 2012 = 19:37
To: Bert Wijnen (IETF)
Cc: Benoit Claise; = Adrian Farrel; manet-chairs@tools.ietf.org; MIB Doctors (E-mail); = draft-ietf-manet-nhdp-mib@tools.ietf.org
Subject: Re: = [MIB-DOCTORS] Heads-up MIB review = impending

 

Bert,

On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) = <bertietf@bwijnen.net> wrote:

Unfortunately, there is not a free version (at least = not current)
available as far as I know. I don;t understand why the = author does not
just make it open source and available to = everyone.
But that is his call I guess.


Okay, I see. My company will likely not pay for = that, and personally I'd rather go to vacations than buy a MIB compiler = ;-)

 


Oh by = the way, you also already user { mib-2 998 } for the MIB OID!!!
that = is not proper! You should use xxx or some such instead of 998
(as you = indicate in the rfc-editor comment = ;-)


I know, = that has been discovered in the IESG LC. The reason why we did not put = xxxx there is that smilint complains otherwise and fails to compile. It = will be fixed in the next revision of the draft (or in the RFC editor = queue).

Best
Ulrich
 


Bert



On 5/22/12 7:03 PM, Ulrich Herberg = wrote:

Bert,

thank you very much for this = first review. We will work on fixing these and spin a new = version.

By the way, is there a free version of SMICng available? = I only have smilint.

Best = regards
Ulrich

On = Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net <mailto:bertietf@bwijnen.net>> wrote:

  =  This is by no means a full MIB review, but I did a quick SMICng = SYNTAX check:

   W: f(nhdp.mi2), (778,5) Row = "nhdpLibRemovedIfAddrSetEntry" has indexing
    =     that  may create variables with more than 128 = sub-ids
   W: f(nhdp.mi2), (1221,5) Row = "nhdpIib2HopSetEntry" has indexing that may
    =     create variables with more than 128 sub-ids
  =  W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does = not have a
        consistent  indexing = scheme - index item nhdpDiscIfIndex from base
      =   row nhdpDiscIfSetEntry  is not defined as an index = item
   W: f(nhdp.mi2), (1376,15) Row = "nhdpNibNeighborSetEntry" does not have a
    =     consistent indexing scheme - index item = nhdpDiscRouterIndex from base
        row = nhdpDiscIfSetEntry is not defined as an index item
   W: = f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does = not have
        a consistent indexing scheme - = index item nhdpDiscRouterIndex from base
        = row nhdpDiscIfSetEntry is not defined as an index item
  =  W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" = does not have a
        consistent indexing = scheme - index item nhdpDiscIfIndex from base row
    =     nhdpDiscIfSetEntry is not defined as an index = item
   W: f(nhdp.mi2), (1690,16) Row = "nhdpDiscNeighborSetPerfEntry" does not
    =     have a consistent indexing scheme - index item = nhdpDiscRouterIndex from
        base row = nhdpDiscIfSetEntry is not defined as an index item
   W: = f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not = have a
        consistent indexing scheme - index = item nhdpDiscRouterIndex from base
        row = nhdpDiscIfSetEntry is not defined as an index item
   W: = f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in = notification
   "nhdpNbrStateChange" is an index = for a table
   W: f(nhdp.mi2), (1956,21) Variable = "nhdpIfIndex" in notification
  =  "nhdp2HopNbrStateChange" is an index for a = table
   W: f(nhdp.mi2), (1973,21) Variable = "nhdpIfIndex" in notification
  =  "nhdpIfRxBadPacket" is anindex for a table
  =  W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in = notification
   "nhdpIfStateChange" is anindex = for a table
   W: f(nhdp.mi2), (2142,22) Duplicate item = "nhdpPerformanceGroup"
        in = MANDATORY-GROUPS for module "NHDP-MIB"


  =  The first  Warning got me to look at:
      = nhdpLibRemovedIfAddrSetEntry  OBJECT-TYPE
      =    SYNTAX     =  NhdpLibRemovedIfAddrSetEntry
        =  MAX-ACCESS  not-accessible
        =  STATUS      current
        =  DESCRIPTION
   "A router's Removed Interface = Address Set consists
            of = Removed Interface Address Tuples, one per network
    =         address:

        =     (IR_local_iface_addr, IR_time)

      =       The association between these addrs and
  =           the router's Interface is found in = the

            Standard MIB II's = IP address table
            = (RFC1213)."
        =  REFERENCE
  =  "RFC6130."

         INDEX { = nhdpLibRemovedIfAddrSetIpAddrT__ype,


              =    nhdpLibRemovedIfAddrSetIpAddr }
      = ::=3D { nhdpLibRemovedIfAddrSetTable 1 }

      = NhdpLibRemovedIfAddrSetEntry ::=3D
        =  SEQUENCE {

    =         = nhdpLibRemovedIfAddrSetIpAddrT__ype
        =       InetAddressType,
        =     nhdpLibRemovedIfAddrSetIpAddr
      =         InetAddress,
        =     = nhdpLibRemovedIfAddrSetIpAddrP__refixLen


    =           InetAddressPrefixLength,
  =           = nhdpLibRemovedIfAddrSetIfIndex
          =     InterfaceIndexOrZero,
        =     nhdpLibRemovedIfAddrSetIRTime
      =         TimeStamp
        =    }

    =  nhdpLibRemovedIfAddrSetIpAddrT__ype =  OBJECT-TYPE


        SYNTAX     =  InetAddressType
        MAX-ACCESS =  read-only
        STATUS     =  current
        DESCRIPTION
  =  "The type of the nhdpLibRemovedIfAddrSetIpAddr
  =           in the InetAddress MIB = (RFC4001).

            Only the = values ipv4(1) and
            ipv6(2) = are supported."
        REFERENCE
  =  "RFC6130."
     ::=3D { = nhdpLibRemovedIfAddrSetEntry 1 }

    =  nhdpLibRemovedIfAddrSetIpAddr  OBJECT-TYPE
    =     SYNTAX      InetAddress
    =     MAX-ACCESS  read-only
        = STATUS      current
        = DESCRIPTION
   "nhdpLibRemovedIfAddrSetIpAddr is = a
            recently used address of = an interface of
            this = router."
        REFERENCE
  =  "RFC6130."
     ::=3D { = nhdpLibRemovedIfAddrSetEntry 2 }

   And I note = that:

   - the 2 INDEX obbjects are defined read-only. = Normally they would be
     not-accessible!!! See = RFC2578
   - If this is ALWAYS = true:

    =    nhdpLibRemovedIfAddrSetIpAddrT__ype =  OBJECT-TYPE


          = SYNTAX      InetAddressType
      =     MAX-ACCESS  read-only
        =   STATUS      current
        =   DESCRIPTION
   "The type of the = nhdpLibRemovedIfAddrSetIpAddr
          =   in the InetAddress MIB (RFC4001).

      =       Only the values ipv4(1) and
      =       ipv6(2) are supported."
    =  Then you could do:
      =  nhdpLibRemovedIfAddrSetIpAddr  OBJECT-TYPE
    =       SYNTAX      InetAddress = (SIZE(4|16))
          MAX-ACCESS =  read-only
     Otherwise you would have to add = something to description clause to
     warn = implementers that they should consider OID size.

   The = third warning:
     W: f(nhdp.mi2), (1117,16) Row = "nhdpIibLinkSetEntry" does not have a
      =     consistent  indexing scheme - index item = nhdpDiscIfIndex from base
          row = nhdpDiscIfSetEntry  is not defined as an index item
  =  Seems a valid warning. But I am not 100% sure. I'd have to go and = study
   more detauil to determine.
  =  Anyways, these "inconsistent indexing" warnings are = indeed just
   warnings. It may be OK, but it would be good = to check and make sure
   that this results in proper (i.e. = unique) indexing values and that the
   indexing is indeed = as intended.

   Sorry, not enough time to check more = details now.

   Bert

   ----- Original Message ----- From: = "Benoit Claise" <bclaise@cisco.com <mailto:bclaise@cisco.com>>

   To: = <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>
   Cc: = <manet-chairs@tools.ietf.org <mailto:manet-chairs@tools.ietf.org>>; <mib-doctors@ietf.org <mailto:mib-doctors@ietf.org>>;
  =  <draft-ietf-manet-nhdp-mib@__tools.ietf.org <mailto:draft-ietf-manet-nhdp-mib@tools.ietf.org>>


   Sent: Tuesday, May 22, = 2012 12:15 AM

   Subject: Re: [MIB-DOCTORS] Heads-up = MIB review impending


       Dear = all,

       I have deferred this draft for = the next telechat.

       Regards, = Benoit.

           Hi MIB = doctors,

           We would really = benefit from your expertise here.
          =  Can we please have a volunteer.
        =    If we don't find someone by the end of the day (on telechat = for this
           Thursday), I'm = afraid that I will have to defer this draft to the next
    =        telechat...

      =      Regards, Benoit.

        =        Hi MIB doctors,

      =          My bad for not following up on this = one. I will follow more closely from now
        =        on.
          =      Can we please have a volunteer to review this MIB = module, which is on the
            =    IESG telechat for next Thursday.

    =            Regards, Benoit.

  =                  Hi MIB = Doctors,

                =    Heads up to give you extra review = time.

      =              https://datatracker.ietf.org/__doc/draft-ietf-manet-nhd= p-mib/


          =          <https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-= mib/> is going to
            =        IETF
          =          last call very soon and would benefit = significantly from a MIB Doctor
          =          review by
      =              the end of the last = call.

                =    Thanks for the work you do.

      =             =  Adrian

            =       =  _________________________________________________
    =                MIB-DOCTORS = mailing list
                =    MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
      =              https://www.ietf.org/mailman/__listinfo/mib-doctors= <https://www.ietf.org/mailman/listinfo/mib-doctors&g= t;



              =  _________________________________________________
    =            MIB-DOCTORS mailing = list
               MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
      =          https://www.ietf.org/mailman/__listinfo/mib-doctors= <https://www.ietf.org/mailman/listinfo/mib-doctors&g= t;



          =  _________________________________________________
    =        MIB-DOCTORS mailing list
    =        MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
      =      https://www.ietf.org/mailman/__listinfo/mib-doctors= <https://www.ietf.org/mailman/listinfo/mib-doctors&g= t;



      =  _________________________________________________
    =    MIB-DOCTORS mailing list
       MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
      =  https://www.ietf.org/mailman/__listinfo/mib-doctors= <https://www.ietf.org/mailman/listinfo/mib-doctors&g= t;


 

------=_NextPart_000_165C_01CD3865.E9D47640-- From bclaise@cisco.com Tue May 22 15:59:14 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 2589921F86C6 for ; Tue, 22 May 2012 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro0f4rIymvz3 for ; Tue, 22 May 2012 15:59:13 -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 1A65921F86CA for ; Tue, 22 May 2012 15:59:12 -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 q4MMx8Jf017112; Wed, 23 May 2012 00:59:08 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MMx49n014649; Wed, 23 May 2012 00:59:04 +0200 (CEST) Message-ID: <4FBC1A37.6030503@cisco.com> Date: Wed, 23 May 2012 00:59:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.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: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 22:59:14 -0000 On 22/05/2012 07:43, David Harrington wrote: > Hi Benoit, > > I will try to help you understand how the MIB Doctors work, so you know. > You might also ask Dan and Bert how they handled this. > > I am a member of the secdir, opsdir, tsvdir, and MIB Doctors directorates. > Secdir reviews are pretty easy; you check whether they have documented > considerations of authentication, authorization, integrity, > confidentiality, and replay. Occasionally there is something a bit more in > depth about specific vulnerabilities, but not often. > Opsdir is pretty easy; you check whether external operational needs have > been addressed, such as DNS, network management, and so on have been > mentioned. > Tsvdir is pretty easy; you check whether congestion has been addressed > (TCP good; UDP bad), whether timers and message replay and port > assignments have been discussed appropriately. > > A MIB review is huge in comparison; You might know all this already, but > I'll mention it just for comparison with other review team requirements. > You need to check the MIB module syntax using tools like libsmi. > Then the real work starts. You need to check for database design > anomalies, such as deletion anomalies, addition anomalies, fate-sharing > between tables, persistence, etc. > You need to study the technology being managed to determine whether > appropriate counters have been defined, and tables of relevant > information, etc. > You need to consider implementation issues, such as whether the > information is readily available to put into a MIB; Fast-track switching > can have a big effect. You need to consider whether updating counters will > impact performance of the managed technology; you need to consider code > footpriint, and so on. > You need to consider the guidelines for review that discuss how to check > boilerplates, type expansions, naming conventions, security > considerations, textual conventions, proper handling of references, etc. > A solid MIB review can take days, and the MIB Doctor stays assigned to the > document while it goes through the approval process. > > The Directorates wiki page shows nineteen MIB Doctors. > For nine of the names, I don't remember the last time I saw them at an > IETF or an email from them to an IETF list (Frank Strauss? Glenn Waters? > Steve Waldbusser? Dave Perkins? Sharon Chisholm? Harrie? Mike Heard?) Sharon Chisholm , Mike Heard , and Shawn Routhier are actually not part of the MIB-doctor mailer. So the http://www.ietf.org/iesg/directorate/mib-doctors.html is another thing I'll have to change. Regards, Benoit. > Another four or five are still active in IETF, but almost never do MIB > reviews because they're focused on other work (Andy, John Flick, Shawn, me) > I don't know why we keep the list of nineteen on this page. > > So realistically, you have an active MIB Doctor review team of about six > people (Bert, Juergen, Mike MacFaden, Randy, Joan, and Orly) > And they realistically need to pick and choose which modules they review > because they are so time-intensive. > > I am not volunteering for this MIB module, since I don't have the time to > learn about manet. > I recommend trying to grow the MIB Doctors, but I expect this will be very > hard. > You might try to recruit some operators who use SNMP tools to provide a > "usefulness" design review. > > I don't know if there is anyway to reduce the burden of a MIB review. > Tools seem a likely approach. > The libsmi tools are good, but can only analyze fairly static features > (syntax). > Maybe another round of tools usable by MIB writers could help analyze > table relationships and check for counter persistence text. > If you can get agreement from the MIB Doctors to formalize some additional > guidelines, further checking might be able to be automated. > But part of the problem of MIB reviews is that there are already so many > rules to follow and review. > Getting tools like libsmi accepted by the tools team, worked on during > code sprints, or adding automated MIB review to datatracker functionality > might help. > (There are other syntax checkers/process checkers that could also be good > added to tools team responsibility, such as mime type registration syntax > and completeness.) > > I know I haven't helped solve the problem of a lack of volunteer for the > nhdp mib, but hopefully you better understand why nobody is stepping > forward. > From bclaise@cisco.com Tue May 22 16:06:39 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 F007021F86C4 for ; Tue, 22 May 2012 16:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hLyspHEz9ef for ; Tue, 22 May 2012 16:06:39 -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 0EDDD21F86B8 for ; Tue, 22 May 2012 16:06:38 -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 q4MMN52e013728; Wed, 23 May 2012 00:23:05 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MMN369027018; Wed, 23 May 2012 00:23:03 +0200 (CEST) Message-ID: <4FBC11C7.2070407@cisco.com> Date: Wed, 23 May 2012 00:23:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <4FBBDBD7.8090906@cisco.com> In-Reply-To: <4FBBDBD7.8090906@cisco.com> X-Forwarded-Message-Id: <4FBBDBD7.8090906@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: [MIB-DOCTORS] A new MIB doctor: Bob Cole 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, 22 May 2012 23:06:40 -0000 Dear all, I've very happy to announce that we have a new MIB doctor: Bob Cole Thanks Bob for helping out Regards, Benoit. From bclaise@cisco.com Tue May 22 16:06: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 B956821F86C9 for ; Tue, 22 May 2012 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leFZZCbvgD4i for ; Tue, 22 May 2012 16:06:40 -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 2D4AB21F86B8 for ; Tue, 22 May 2012 16:06:40 -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 q4MMPO4Z013937; Wed, 23 May 2012 00:25:25 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MMPNse028119; Wed, 23 May 2012 00:25:24 +0200 (CEST) Message-ID: <4FBC1253.9050501@cisco.com> Date: Wed, 23 May 2012 00:25:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FBABFF1.2010002@cisco.com> <4FBB3D9C.5000503@bwijnen.net> <4FBB6997.6040108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Tue, 22 May 2012 23:06:41 -0000 Hi Dan, See in-line. > Hi Benoit, > > See in-line. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, May 22, 2012 1:25 PM >> To: Romascanu, Dan (Dan) >> Cc: Bert Wijnen (IETF); MIB Doctors (E-mail); Ron Bonica >> Subject: Re: [MIB-DOCTORS] Volunteers for MIB review >> >> Dan, Bert, Dave, >> >> Thanks for your feedback. >> Let me try to decompose the problem into multiple smaller ones. >> >> 1. Require MIB doctor review BEFORE the IETF LC. >> I'll take that action item to stress this my fellow AD. >> This would allow some more time for planning the review,. >> >> 2. Finding a volunteer earlier on the process. >> I'll take the action item to follow up sooner in the process. >> >> 3. Learning a new technology, specifically from IETF RFCs and drafts, >> is >> time consuming (I've been learning that these days ;-) ), and could be >> a >> blocking factor to volunteer to review MIB modules. >> Let me propose something: let's request, part of the MIB doctor, a >> transfer of information webex, with the document authors and/or WG >> chairs and/or responsible AD. Basically, the message would be: "you >> want >> to benefit from the MIB-doctors expertise, teach them first your >> technology, and how you would like to manage it!" >> Personally, when I received a 1/2h introduction on a new technology, >> the >> documents were way more easier and time-consuming to read. I could >> enforce this new rule. >> > [[DR]] I would be cautious to ask too much upfront, people may be > discouraged, we do not want that to happen. Rather work on a > case-to-case mode, some people will already have some knowledge, other > need to ask, some may get help without bothering you, let us use AD > escalation only when requests for private transfer of information are > not answered. Understood. Let's not formalize the process, but let's keep that as an option. > >> 4. MIB doctor team composition: clean-up required? >> It would be ideal to only have active reviewers on the list. However, >> if >> all the participants are contributing one way or the other (libsmi, >> answering questions occasionally), we should keep everybody in the >> list. >> If someone would like to opt-out, let me know. >> > [[DR]] Maybe you should ask folks who did not participate in any > discussion in the last few years whether they are still interested to be > on the list. I did not see any contribution from Steve Waldbusser or > Sharon Chisholm for many years. Let me follow up. > If you send them such messages either a. > the address bounces and you take them out, or b. they say they opt out, > the same, or c. they say they want to stay and maybe even get a review > from time to time. > >> 5. Growing the MIB doctor team. >> If you have some names or mailing list in mind, let me know. >> I will send this request internally in my company: we have our > internal >> MIB-police team. Maybe, we'll get one extra person... >> > [[DR]] Maybe Bob Cole could be recruited. Bob kindly accepted. > Is Randy Presuhn a MIB > Doctor? Worth asking him if he is not. And Randy is already a MIB doctor. We now have three new MIB doctors, and I'm still waiting for an answer from Chris Elliott. I believe that the "Growing the MIB doctor team" is now solved unless you have some other people in mind. Regards, Benoit. > >> 6. Fair distribution of load >> I could keep a history of the distribution, if that helps. >> >> Please share your thoughts. >> >> Regards, Benoit. >> >> >>> Hi Benoit, >>> >>> My perspective is very close to Bert's and David's. Indeed, proper >> MIB >>> Doctor review requires good understanding or fast learning of the >>> technology that is supposed to be managed, and this takes time. I >> would >>> argue that you need this also for a proper security or OPS review, >> but >>> the argument is marginal for what we discuss here. For that reason >> while >>> I was on the IESG I asked my fellow ADs to require MIB doctor review >>> BEFORE the IETF LC, so that the search for a MIB Doctor starts >> earlier >>> than the moment the Last Call sand-clock (typically two or four >> weeks) >>> is runing. You may want to do the same. >>> >>> Concerning the MIB Doctors team composition. I did a clean-up a few >>> years ago and the remaining members were those who committed to >> continue >>> to be active with a couple of exceptions - Frank Strauss was never > an >>> active reviewer but he contributed the libsmi, Mike Heard and Andy >>> Bierman said that they did not have the time for reviews but would >> stay >>> on the list and answers questions occasionally, which they did now >> and >>> then and this was useful. You may want to do another round of >> questions, >>> see who wants to stay active, who opts out. Harrie actually answered >> at >>> least one call for reviewers in the last year, you can also add my >> name >>> to the list, with eight active reviewers the situation is not that >> bad, >>> this will lead to 2-3 reviews each year. You can of course try to >>> recruit new participants. >>> >>> You may move from a asking for volunteers model to a round-robin >>> assignment, or at least use such an algorithm if a volunteer does > not >>> show up after a few days. >>> >>> Concerning the style of the reviews, I am again agreeing to what > Bert >>> and David say, and I would add that in my reviews I also ask about >> the >>> need to reduce complexity hence the number of objects so that the >> agent >>> code can be implemented and the manager can access easily the > objects >>> essential to the day-to-day operations. >>> >>> Concerning this MIB module - Bob Cole consulted with me, maybe also >> with >>> other MIB doctors while in design phase, so there was some level of >>> exposure and discussions prior to the MIB module hitting the IESG. >>> >>> I hope this helps. >>> >>> Regards, >>> >>> Dan >>> >>> >>>> -----Original Message----- >>>> From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- >>>> bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) >>>> Sent: Tuesday, May 22, 2012 10:18 AM >>>> To: Benoit Claise >>>> Cc: MIB Doctors (E-mail); Ron Bonica >>>> Subject: Re: [MIB-DOCTORS] Volunteers for MIB review >>>> >>>> Hi Benoit. >>>> >>>> Last week, and also coming weeks I am pretty busy, so I could >>>> not step up. Yet I did a very quick browse through the document, >>>> but this was basically to do a first assessment if the MIB is >>>> in really bad state (in which case there will be a lot of work >>>> and a long period during which the work may come back) or in >>>> reasonable shape, in which case the work is far less and may not >>>> take too long to come to closure. >>>> This MIB document seems quite reasonable at first sight. >>>> But still it will take some time to do a proper review. >>>> >>>> I also saw DBH comments/explanation. >>>> I think it would be good if we could do such in depth reviews as >>>> Dave suggests, but at the other hand, I feel that it is subject >>>> matter experts that need to worry about a lot of the topics >>>> about design and impact on the technology. >>>> I know that when I do a review, that I often dive somewhat into the >>>> documents that describe the technology, and then sometimes that >> raises >>>> questions that I will pose and that causes follow up etc. >>>> >>>> When I was AD, and when/if I couldn't get reviewers (although at > the >>>> time we had a larger base of *active* MIB doctors), then I would do >>>> the basic checks myself, make sure SYNTAX was OK, make sure there >>>> were no gaping holes. That sometimes (actually often) took quite >> some >>>> time. Yep... I understand. >>>> >>>> But even if you get to this stage, I am not sure you absolutely > have >>> to >>>> go into as much details as Dave suggests. There are (after all) so >>> many >>>> different technologies in IETF that it is kind of impossible to >>>> understand them all in great detail. >>>> I guess that is up to you to decide. >>>> >>>> Maybe Dan has some perspective here as well. >>>> >>>> Bert >>>> >>>> On 5/22/12 12:21 AM, Benoit Claise wrote: >>>>> Dear all, >>>>> >>>>> [restricting the email to just mib-doctors] >>>>> >>>>> First of all, my apologies for not following up the email from >>> Adrian >>>> on March 29th, subject "Heads-up MIB review impending". >>>>> This concerns the MIB doctor review of >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ >>>>> Now, how do we share the load amongst MIB doctors? >>>>> - round robin? >>>>> - we keep track of history and ask a specific person (like Tina > Tsu >>>> does for OPS-DIR). I could do that job >>>>> - I just an email to the list, asking for a volunteer? >>>>> - something else? >>>>> >>>>> Please let me know. >>>>> Also, we really need a reviewer for >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ >>>>> Regards, Benoit. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Tue May 22 16:59: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 0B3B821F86C6 for ; Tue, 22 May 2012 16:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.547 X-Spam-Level: X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXMrA32qjwQC for ; Tue, 22 May 2012 16:59:09 -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 363AF21F86A4 for ; Tue, 22 May 2012 16:59:09 -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 q4MNnO1L021830; Wed, 23 May 2012 01:49:24 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4MNnOsJ009437; Wed, 23 May 2012 01:49:24 +0200 (CEST) Message-ID: <4FBC2603.90902@cisco.com> Date: Wed, 23 May 2012 01:49:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <4FBC11C7.2070407@cisco.com> In-Reply-To: <4FBC11C7.2070407@cisco.com> X-Forwarded-Message-Id: <4FBC11C7.2070407@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] A new MIB doctor: Chris Elliott 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, 22 May 2012 23:59:10 -0000 Dear all, I've very happy to announce that we have a new MIB doctor: yChris Elliott With a little bit of arm twisting (private joke), I was able to convince my good old friend. However, Chris is pretty busy right now, and would only start participating after the summer. Thanks Chris for helping out Regards, Benoit. From dromasca@avaya.com Tue May 22 22:43:23 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 C14DB21F85A2 for ; Tue, 22 May 2012 22:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNEXWFOyVjvz for ; Tue, 22 May 2012 22:43:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF321F85A1 for ; Tue, 22 May 2012 22:43:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAJAE94vE/GmAcF/2dsb2JhbABDrGmHRoEHghUBAQEBAgESHgo/DAQCAQgNAQcBDAYMCwEGAUURAQEEARIIARmHZwULnX+dAIsOhF5iA5sNiX+CbIFd X-IronPort-AV: E=Sophos;i="4.75,643,1330923600"; d="scan'208";a="349035660" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 May 2012 01:41:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2012 01:41:19 -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: Wed, 23 May 2012 07:43:17 +0200 Message-ID: In-Reply-To: <4FBC1A37.6030503@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Volunteers for MIB review Thread-Index: Ac04boTOzgc768wxSeuJisaBixnFHAANwUlw References: <4FBC1A37.6030503@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , "David Harrington" Cc: "MIB Doctors \(E-mail\)" , Ron Bonica Subject: Re: [MIB-DOCTORS] Volunteers for MIB 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: Wed, 23 May 2012 05:43:23 -0000 > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Wednesday, May 23, 2012 1:59 AM > To: David Harrington ... > > The Directorates wiki page shows nineteen MIB Doctors. > > For nine of the names, I don't remember the last time I saw them at > an > > IETF or an email from them to an IETF list (Frank Strauss? Glenn > Waters? > > Steve Waldbusser? Dave Perkins? Sharon Chisholm? Harrie? Mike Heard?) > Sharon Chisholm , Mike Heard , > and > Shawn Routhier are actually not part of > the MIB-doctor mailer. > So the http://www.ietf.org/iesg/directorate/mib-doctors.html is another > thing I'll have to change. >=20 > Regards, Benoit. >=20 [[DR]] Mea culpa, I forgot about that page and did not update it for ages. Probably three years at least, as Bert is no longer with AL for quite a while, and Nortel does not exist for quite a while. Shawn agreed to continue on MIB Doctors last time I exchanged mails with him, you may want to confirm this. I did not communicate with Glenn and Sharon for a while, I do not know if the Nortel addresses work any longer.=20 Congratulations for the successful recruiting campaign, and welcome to the new members! Regards, Dan From tnadeau@juniper.net Wed May 23 05:14: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 1806021F86F5 for ; Wed, 23 May 2012 05:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QaVeUDjSaDF for ; Wed, 23 May 2012 05:14:24 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF621F86F4 for ; Wed, 23 May 2012 05:14:24 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT7zUn6HyBoZzEHMijY0DqeQGaYmbaz6s@postini.com; Wed, 23 May 2012 05:14:24 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 May 2012 05:12:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 23 May 2012 08:12:39 -0400 From: Thomas Nadeau To: "MIB Doctors (E-mail)" Date: Wed, 23 May 2012 08:12:36 -0400 Thread-Topic: SmicNG for MIB Doctor Use Thread-Index: Ac043VhpIPTOXKUSSmOhCl8UhKELag== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 12:14:25 -0000 Guys, A process question. How do we get access to SmicNG? Is there a web-based version we can use or are MIB Doctors given a license to run it locally? Also, do we keep some internal web page of who is reviewing what to keep track of review status? Finally, what is the process for how reviews are assigned, processed and released? Forgive me for asking. If there is a FAQ, please point me at it. *) --Tom From bertietf@bwijnen.net Wed May 23 05:25:50 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 919E521F86D5 for ; Wed, 23 May 2012 05:25:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTUXaxri1R3q for ; Wed, 23 May 2012 05:25:50 -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 EDAB021F8704 for ; Wed, 23 May 2012 05:25:49 -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 1SXAdP-0006Z3-KV; Wed, 23 May 2012 14:25:49 +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 1SXAdP-0003Oy-68; Wed, 23 May 2012 14:25:47 +0200 Message-ID: <4FBCD74A.9030200@bwijnen.net> Date: Wed, 23 May 2012 14:25:46 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Thomas Nadeau References: In-Reply-To: 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: 20120523 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: 86ab03e524994f79ca2c75a176445dd41e425328aa074b7964004ac3341178d2 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 12:25:50 -0000 The author of SMICng, David Perkins, is to be asked. I would think that it would in fact be great for him to make it at least available for MIB doctors to do IETF MIB review/checking. I have asked him several times in the past (when I was AD, but also later). I believe Dan has asked him too. But as far as I know, he has not done so yet. Last email address I have for him: dperkins3600@gmail.com Bert On 5/23/12 2:12 PM, Thomas Nadeau wrote: > > Guys, > > A process question. How do we get access to SmicNG? Is there a > web-based version we can use or are MIB Doctors given a license to run it > locally? > > Also, do we keep some internal web page of who is reviewing what to keep > track of review status? > > Finally, what is the process for how reviews are assigned, processed and > released? Forgive me for asking. If there is a FAQ, please point me at it. > *) > > --Tom > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From tnadeau@juniper.net Wed May 23 05:33: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 42D1621F870F for ; Wed, 23 May 2012 05:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICW+WCFknkWk for ; Wed, 23 May 2012 05:33:04 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 44D8721F85FB for ; Wed, 23 May 2012 05:33:04 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT7zY3syx2muUo2zeYWmtSxldb78vJGb4@postini.com; Wed, 23 May 2012 05:33:04 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; Wed, 23 May 2012 05:31:25 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 23 May 2012 05:31:25 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 23 May 2012 08:31:24 -0400 From: Thomas Nadeau To: "Bert Wijnen (IETF)" Date: Wed, 23 May 2012 08:31:22 -0400 Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use Thread-Index: Ac043/b12KpkYHYISFaEihOHZnm8IA== Message-ID: In-Reply-To: <4FBCD74A.9030200@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 12:33:05 -0000 I guess the next logical question then would be to ask, if there is such reluctance to let this community use SMICng gratis (which his clearly non-profit organization), should we standardize on a different (more readily available) MIB compiler for our checks? Apologies if this has been already discussed here. I am just trying to sort this out so I don't have to figure it out after I am assigned something to review, and discover that I cannot compile it - or that we are all using different MIB compilers and get slightly different results. --Tom On 5/23/12 8:25 AM, "Bert Wijnen (IETF)" wrote: >The author of SMICng, David Perkins, is to be asked. >I would think that it would in fact be great for him >to make it at least available for MIB doctors to do >IETF MIB review/checking. > >I have asked him several times in the past (when I was AD, >but also later). I believe Dan has asked him too. > >But as far as I know, he has not done so yet. > >Last email address I have for him: dperkins3600@gmail.com >Bert > >On 5/23/12 2:12 PM, Thomas Nadeau wrote: >> >> Guys, >> >> A process question. How do we get access to SmicNG? Is there a >> web-based version we can use or are MIB Doctors given a license to run >>it >> locally? >> >> Also, do we keep some internal web page of who is reviewing what to >>keep >> track of review status? >> >> Finally, what is the process for how reviews are assigned, processed >>and >> released? Forgive me for asking. If there is a FAQ, please point me at >>it. >> *) >> >> --Tom >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> From j.schoenwaelder@jacobs-university.de Wed May 23 05:54: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 346EA21F873C for ; Wed, 23 May 2012 05:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxv7GDDbfaxn for ; Wed, 23 May 2012 05:54:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8B21F873B for ; Wed, 23 May 2012 05:54:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3378B20C84; Wed, 23 May 2012 14:54:01 +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 gpDTtIR4_lRq; Wed, 23 May 2012 14:54:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B10DA20C81; Wed, 23 May 2012 14:54:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4A0F1F25DB4; Wed, 23 May 2012 14:53:59 +0200 (CEST) Date: Wed, 23 May 2012 14:53:59 +0200 From: Juergen Schoenwaelder To: Thomas Nadeau Message-ID: <20120523125359.GA1544@elstar.local> Mail-Followup-To: Thomas Nadeau , "Bert Wijnen (IETF)" , "MIB Doctors (E-mail)" References: <4FBCD74A.9030200@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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: Wed, 23 May 2012 12:54:03 -0000 On Wed, May 23, 2012 at 08:31:22AM -0400, Thomas Nadeau wrote: > > I guess the next logical question then would be to ask, if there is such > reluctance to let this community use SMICng gratis (which his clearly > non-profit organization), should we standardize on a different (more > readily available) MIB compiler for our checks? Apologies if this has > been already discussed here. I am just trying to sort this out so I don't > have to figure it out after I am assigned something to review, and > discover that I cannot compile it - or that we are all using different MIB > compilers and get slightly different results. smilint (part of the libsmi package) is open source, packaged for many Unix distributions, some people even run a Windows cross-compiled version. There is also a web frontend: http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/ There are certain things smicng warns about that smilint does not detect and vice versa. Since smilint is open source, if something important is missing, there is a way to add it. The libsmi package also has a tool smidiff that compares to revisions of a MIB modules. This is needed less frequently but once you have to look at a revision, it is neat to have a tool that checks whether many of the SMIv2 update rules have been followed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Wed May 23 06:46:00 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 136AC21F857F for ; Wed, 23 May 2012 06:46:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP2qD0P9v-22 for ; Wed, 23 May 2012 06:45:57 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC4521F8557 for ; Wed, 23 May 2012 06:45:54 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4NDjr7C030960 for ; Wed, 23 May 2012 09:45:53 -0400 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.168.164] ([75.84.168.164:50578] helo=[192.168.0.167]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 6D/EB-06474-01AECBF4; Wed, 23 May 2012 09:45:53 -0400 Message-ID: <4FBCEA10.50000@netconfcentral.org> Date: Wed, 23 May 2012 06:45:52 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Thomas Nadeau References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 13:46:00 -0000 On 05/23/2012 05:31 AM, Thomas Nadeau wrote: > > I guess the next logical question then would be to ask, if there is such > reluctance to let this community use SMICng gratis (which his clearly > non-profit organization), should we standardize on a different (more > readily available) MIB compiler for our checks? Apologies if this has > been already discussed here. I am just trying to sort this out so I don't > have to figure it out after I am assigned something to review, and > discover that I cannot compile it - or that we are all using different MIB > compilers and get slightly different results. > I have not used SMICng in 10 years. I like smilint much better. It is easier to use and it is open-source code. > --Tom > Andy > > On 5/23/12 8:25 AM, "Bert Wijnen (IETF)" wrote: > >> The author of SMICng, David Perkins, is to be asked. >> I would think that it would in fact be great for him >> to make it at least available for MIB doctors to do >> IETF MIB review/checking. >> >> I have asked him several times in the past (when I was AD, >> but also later). I believe Dan has asked him too. >> >> But as far as I know, he has not done so yet. >> >> Last email address I have for him: dperkins3600@gmail.com >> Bert >> >> On 5/23/12 2:12 PM, Thomas Nadeau wrote: >>> >>> Guys, >>> >>> A process question. How do we get access to SmicNG? Is there a >>> web-based version we can use or are MIB Doctors given a license to run >>> it >>> locally? >>> >>> Also, do we keep some internal web page of who is reviewing what to >>> keep >>> track of review status? >>> >>> Finally, what is the process for how reviews are assigned, processed >>> and >>> released? Forgive me for asking. If there is a FAQ, please point me at >>> it. >>> *) >>> >>> --Tom >>> >>> _______________________________________________ >>> 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 tnadeau@juniper.net Wed May 23 06:50:01 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 506BD21F8503 for ; Wed, 23 May 2012 06:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-5K82FuXPsM for ; Wed, 23 May 2012 06:50:00 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDC21F84D0 for ; Wed, 23 May 2012 06:49:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT7zrA9Z8eUm42kuWc/NJ4JrEWrgIWEdg@postini.com; Wed, 23 May 2012 06:50:00 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 May 2012 06:49:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 23 May 2012 09:49:24 -0400 From: Thomas Nadeau To: Andy Bierman Date: Wed, 23 May 2012 09:49:22 -0400 Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use Thread-Index: Ac046tyfSpUclNSMQr2/z9wE+0Bq9g== Message-ID: In-Reply-To: <4FBCEA10.50000@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 13:50:01 -0000 On 5/23/12 9:45 AM, "Andy Bierman" wrote: >On 05/23/2012 05:31 AM, Thomas Nadeau wrote: >> >> I guess the next logical question then would be to ask, if there is >>such >> reluctance to let this community use SMICng gratis (which his clearly >> non-profit organization), should we standardize on a different (more >> readily available) MIB compiler for our checks? Apologies if this has >> been already discussed here. I am just trying to sort this out so I >>don't >> have to figure it out after I am assigned something to review, and >> discover that I cannot compile it - or that we are all using different >>MIB >> compilers and get slightly different results. >> > >I have not used SMICng in 10 years. >I like smilint much better. >It is easier to use and it is open-source code. I personally agree with you. I really like Smilint. However, is this the consensus of MIB doctors, and is what we should use then for reviews? --Tom > > >> --Tom >> > >Andy > >> >> On 5/23/12 8:25 AM, "Bert Wijnen (IETF)" wrote: >> >>> The author of SMICng, David Perkins, is to be asked. >>> I would think that it would in fact be great for him >>> to make it at least available for MIB doctors to do >>> IETF MIB review/checking. >>> >>> I have asked him several times in the past (when I was AD, >>> but also later). I believe Dan has asked him too. >>> >>> But as far as I know, he has not done so yet. >>> >>> Last email address I have for him: dperkins3600@gmail.com >>> Bert >>> >>> On 5/23/12 2:12 PM, Thomas Nadeau wrote: >>>> >>>> Guys, >>>> >>>> A process question. How do we get access to SmicNG? Is there a >>>> web-based version we can use or are MIB Doctors given a license to run >>>> it >>>> locally? >>>> >>>> Also, do we keep some internal web page of who is reviewing what to >>>> keep >>>> track of review status? >>>> >>>> Finally, what is the process for how reviews are assigned, processed >>>> and >>>> released? Forgive me for asking. If there is a FAQ, please point me at >>>> it. >>>> *) >>>> >>>> --Tom >>>> >>>> _______________________________________________ >>>> 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 Wed May 23 08:28: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 3DD0A21F8770; Wed, 23 May 2012 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_SUB_OBFU_OTHER=0.135, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdJYqZdWNzOb; Wed, 23 May 2012 08:28:07 -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 529CD21F876E; Wed, 23 May 2012 08:28:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RwNjgMcaYBBRCvfMhRvI9wf5lAh8+OnXS1oy4cNaUDDETxdOyHIb2eLYs1XmCGBs; h=Received:Message-ID:From:To:Cc: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-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXDTk-0000KE-F7; Wed, 23 May 2012 11:28:00 -0400 Message-ID: <016901cd38f8$eb6063a0$6701a8c0@JoanPC> From: "Joan Cucchiara" To: , "Thomas Nadeau" , , "Kannan KV Sampath" , "Sami Boutros" , Date: Wed, 23 May 2012 11:30:01 -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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654f71ab506a65ff4cfdc17fc4a35c05fb0a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Swallow George , mpls@ietf.org, "MIB Doctors \(E-mail\)" , Ross Callon , Martin Vigoureux , Loa Andersson Subject: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.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, 23 May 2012 15:28:08 -0000 Hello Authors, Thank you for proposing this solution. Please see my notes below. Thank you, -Joan 1) Coherency of document: A) Is document useful and likely to be used/useful in operational networks? This document contains a MIB Module with 2 tables. The tables allow creation of TP IDs of MPLS LSPs and Pseudowires. Also a pointer to rows in other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB (RFC3012) or pseudowire in the PWE-STD-MIB (RFC5601). Since many vendors and operators support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with the authors that the architecture of this MIB is a viable approach. In other words, the authors are leveraging off of existing MIB implementations. They are doing this in a way which adheres to the rules of SMIv2 and I do think that the MIB is likely to be used/useful in operational networks. B) Is document technically sound? >From a MIB perspective, no: I) Many objects are of type "DisplayString" which is used in SMIv1 but not in SMIv2. As the MIB Common TC doc specifies: https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs "Note 2. DisplayString does not support internationalized text. It MUST NOT be used for objects that are required to hold internationalized text (which is always the case if the object is intended for use by humans [RFC2277]). Designers SHOULD consider using SnmpAdminString, Utf8String, or LongUtf8String for such objects." II) The term "Trap" is used in both the document and the MIB. This needs to be replaced by the term "Notification". Traps a mechanism in SNMPv1. Please see RFC3584. 2) Is document ready for WG adoption? I would ask that changes to remove DisplayString and use a TC which supports internationalization be done, and the term Trap removed prior to WG adoption for reasons stated above. This request should only take a few minutes of editing, but will bring the document upto SMIv2. Additionally, a few comments (mostly as fyi): I) this MIB contains configuration (read-create) objects. II) the document proposes to root the MIB under mplsStdMIB which was the convention for the set of MPLS MIBs in 2004 but guidelines have changed since then. III) The use of the accessible-for-notify and imports of IFMIB tables do not seem necessary in the MIB's current state. As the MIB is updated, this should be removed or clarified. From jcucchiara@mindspring.com Wed May 23 09:08:59 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 4452821F876E for ; Wed, 23 May 2012 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeqftLwjkA4O for ; Wed, 23 May 2012 09:08:58 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05021F86EC for ; Wed, 23 May 2012 09:08:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bciN1CH6DANNoqASWEfJD6dGIFY+vY8UPSVhLqpFiOmL1Y4mNw7Oru+osFMpBQdw; h=Received:Message-ID:From:To: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-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXE7O-0008RI-4D for mib-doctors@ietf.org; Wed, 23 May 2012 12:08:58 -0400 Message-ID: <096801cd38fe$a4815380$6701a8c0@JoanPC> From: "Joan Cucchiara" To: "MIB Doctors \(E-mail\)" Date: Wed, 23 May 2012 12:10:59 -0400 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654f71ab506a65ff4cf97bb2cc4a1fc93db3d063210bc784f5e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Subject: [MIB-DOCTORS] Fw: Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.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, 23 May 2012 16:08:59 -0000 Hello MIB Drs., I was asked to take a look at this document for an initial review prior to WG adoption as part of the MPLS review team effort. To quote from Loa's email regarding the MPLS review team: "The reviewers will be asked to comment on whether the document is coherent, if is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? Reviews should be sent to the document authors, WG co-chairs and secretary, and be CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs." I value the MIB doctors' input and consistency in MIB reviews, even with initial reviews, so wanted to cc this group also. Please feel free to comment on this (or other future reviews), but please keep in mind that these MPLS review team reviews have the above objectives. Thanks, -Joan ----- Original Message ----- From: "Joan Cucchiara" To: ; "Thomas Nadeau" ; ; "Kannan KV Sampath" ; "Sami Boutros" ; Cc: "Joan Cucchiara" ; ; "Loa Andersson" ; "Swallow George" ; "Ross Callon" ; "Martin Vigoureux" ; "MIB Doctors (E-mail)" Sent: Wednesday, May 23, 2012 11:30 AM Subject: Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt > > Hello Authors, > > Thank you for proposing this solution. > Please see my notes below. > > Thank you, > -Joan > > 1) Coherency of document: > A) Is document useful and likely to be used/useful in operational > networks? > > This document contains a MIB Module with 2 tables. The tables allow > creation of > TP IDs of MPLS LSPs and Pseudowires. Also a pointer to rows in > other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB > (RFC3012) or > pseudowire in the PWE-STD-MIB (RFC5601). Since many vendors and > operators > support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with the > authors that the architecture of this MIB is a viable approach. > > In other words, the authors are leveraging off of existing MIB > implementations. > They are doing this in a way which adheres to the rules of SMIv2 and I do > think that the MIB is likely to be used/useful in operational networks. > > > B) Is document technically sound? > > From a MIB perspective, no: > > I) Many objects are of type "DisplayString" which is used > in SMIv1 but not in SMIv2. > > As the MIB Common TC doc specifies: > > https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs > > > "Note 2. DisplayString does not support internationalized text. > It MUST NOT be used for objects that are required to > hold internationalized text (which is always the case > if the object is intended for use by humans [RFC2277]). > Designers SHOULD consider using SnmpAdminString, > Utf8String, or LongUtf8String for such objects." > > II) The term "Trap" is used in both the document and the MIB. > This needs to be replaced by the term "Notification". Traps a mechanism > in SNMPv1. Please see RFC3584. > > > > 2) Is document ready for WG adoption? > > I would ask that changes to remove DisplayString and use a TC which > supports internationalization be done, and the term Trap removed > prior to WG adoption for reasons stated above. > > This request should only take a few minutes of editing, but will bring the > document upto SMIv2. > > Additionally, a few comments (mostly as fyi): > > I) this MIB contains configuration (read-create) objects. > > II) the document proposes to root the MIB under mplsStdMIB which was > the convention for the set of MPLS MIBs in 2004 but guidelines have > changed since then. > > III) The use of the accessible-for-notify and imports of > IFMIB tables do not seem necessary in the MIB's current state. > As the MIB is updated, this should be removed or clarified. > > From randy_presuhn@mindspring.com Wed May 23 10:55:17 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 43D1321F85D6 for ; Wed, 23 May 2012 10:55:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMc5SuG21W6Z for ; Wed, 23 May 2012 10:55:16 -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 CBB6121F852C for ; Wed, 23 May 2012 10:55:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BddZp88XKvHImdUwGS5iCl/h45crw3m+AIvmFNej5bivAj5m3slCvcM0n2kPLc3F; 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.105] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXFmG-0001mG-2j for mib-doctors@ietf.org; Wed, 23 May 2012 13:55:16 -0400 Message-ID: <005401cd390d$917a93a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: Date: Wed, 23 May 2012 10:57:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f888c3408d537cf5c870033e09f7a5c54ee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.146.105 Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 17:55:17 -0000 Hi - > From: "Thomas Nadeau" > To: "Andy Bierman" > Cc: "MIB Doctors (E-mail)" > Sent: Wednesday, May 23, 2012 6:49 AM > Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use ... > I personally agree with you. I really like Smilint. However, is this the > consensus of MIB doctors, and is what we should use then for reviews? I think *not* standardizing on a particular toolset is the right way to go. The differences in what the various tools "catch" (rightly or wrongly) keep us honest, especially about the greyer parts of the specifications. (And yes, on those rare occasions when I do a review, I generally use Smilint.) Randy From tnadeau@juniper.net Wed May 23 12:56:34 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 AF60E11E80A3 for ; Wed, 23 May 2012 12:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XDN4xCHuUCv for ; Wed, 23 May 2012 12:56:34 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0211E8076 for ; Wed, 23 May 2012 12:56:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT71A8HzZKrvapz95/youi281vpbdE8El@postini.com; Wed, 23 May 2012 12:56:34 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; Wed, 23 May 2012 12:53:48 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 23 May 2012 12:53:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 23 May 2012 15:53:47 -0400 From: Thomas Nadeau To: Randy Presuhn , "MIB Doctors (E-mail)" Date: Wed, 23 May 2012 15:53:44 -0400 Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use Thread-Index: Ac05HcOAE0p1MjNxQ9WRfaBMvdmG6A== Message-ID: In-Reply-To: <005401cd390d$917a93a0$6b01a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 23 May 2012 19:56:34 -0000 On 5/23/12 1:57 PM, "Randy Presuhn" wrote: >Hi - > >> From: "Thomas Nadeau" >> To: "Andy Bierman" >> Cc: "MIB Doctors (E-mail)" >> Sent: Wednesday, May 23, 2012 6:49 AM >> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use >... >> I personally agree with you. I really like Smilint. However, is this the >> consensus of MIB doctors, and is what we should use then for reviews? > >I think *not* standardizing on a particular toolset is the right way to >go. >The differences in what the various tools "catch" (rightly or wrongly) >keep us honest, especially about the greyer parts of the specifications. > >(And yes, on those rare occasions when I do a review, I generally use >Smilint.) I appreciate your point about coverage, but the issue is getting access to SmicNG for all of us. Unless reviews are divided up so that at least one person=20 has access to it, then it will be difficult to get that coverage. One thing that might be useful even if we can't get access to running SmicNG locally, is perhaps a web-based version that is restricted to just IETF MIB Doctors. That way we install it once, but only this closed user group gets access to run it. That might be acceptable to the author? --Tom > >Randy > >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From tnadeau@juniper.net Wed May 23 14:17: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 0D9F011E8080; Wed, 23 May 2012 14:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvBuNlRAsx+M; Wed, 23 May 2012 14:17:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5875111E8098; Wed, 23 May 2012 14:16:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT71TxB8OuOPEYE1D8xq5aoslKlBzrrfG@postini.com; Wed, 23 May 2012 14:17:05 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 May 2012 14:16:40 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 23 May 2012 17:16:39 -0400 From: Thomas Nadeau To: Joan Cucchiara , "aldrin.ietf@gmail.com" , "venkat.mahalingams@gmail.com" , Kannan KV Sampath , Sami Boutros , "ppan@infinera.com" Date: Wed, 23 May 2012 17:16:37 -0400 Thread-Topic: Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt Thread-Index: Ac05KVd9uIlVDLQ1T3KippJ4im05fg== Message-ID: In-Reply-To: <016901cd38f8$eb6063a0$6701a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Swallow George , "mpls@ietf.org" , "MIB Doctors \(E-mail\)" , Ross Callon , Martin Vigoureux , Loa Andersson Subject: Re: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.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, 23 May 2012 21:17:06 -0000 Hi Joan! Thanks for the review. Comments inline start with TOM: On 5/23/12 11:30 AM, "Joan Cucchiara" wrote: > >Hello Authors, > >Thank you for proposing this solution. >Please see my notes below. > >Thank you, > -Joan > >1) Coherency of document: >A) Is document useful and likely to be used/useful in operational >networks? > >This document contains a MIB Module with 2 tables. The tables allow >creation of >TP IDs of MPLS LSPs and Pseudowires. Also a pointer to rows in >other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB >(RFC3012)=20 >or >pseudowire in the PWE-STD-MIB (RFC5601). Since many vendors and >operators >support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with the >authors that the architecture of this MIB is a viable approach. > >In other words, the authors are leveraging off of existing MIB >implementations. >They are doing this in a way which adheres to the rules of SMIv2 and I do >think that the MIB is likely to be used/useful in operational networks. > > >B) Is document technically sound? > >From a MIB perspective, no: > >I) Many objects are of type "DisplayString" which is used >in SMIv1 but not in SMIv2. > >As the MIB Common TC doc specifies: > >https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs > > > "Note 2. DisplayString does not support internationalized text. > It MUST NOT be used for objects that are required to > hold internationalized text (which is always the case > if the object is intended for use by humans [RFC2277]). > Designers SHOULD consider using SnmpAdminString, > Utf8String, or LongUtf8String for such objects." > >II) The term "Trap" is used in both the document and the MIB. >This needs to be replaced by the term "Notification". Traps a mechanism >in SNMPv1. Please see RFC3584. TOM: Ooops! We will fix this. >2) Is document ready for WG adoption? > >I would ask that changes to remove DisplayString and use a TC which >supports internationalization be done, and the term Trap removed >prior to WG adoption for reasons stated above. > >This request should only take a few minutes of editing, but will bring >the=20 >document upto SMIv2. TOM: Agree. There is no big issue fixing this. We will need to re-spin the draft in a WG-approved format anyways, so we can fix this during those edits. > >Additionally, a few comments (mostly as fyi): > >I) this MIB contains configuration (read-create) objects. > >II) the document proposes to root the MIB under mplsStdMIB which was >the convention for the set of MPLS MIBs in 2004 but guidelines have >changed since then. > >III) The use of the accessible-for-notify and imports of >IFMIB tables do not seem necessary in the MIB's current state. >As the MIB is updated, this should be removed or clarified. TOM: Cool. --Tom > > From randy_presuhn@mindspring.com Wed May 23 17:30:30 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 7950B21F8630 for ; Wed, 23 May 2012 17:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7kSxWWYyVHT for ; Wed, 23 May 2012 17:30:30 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id F236221F862F for ; Wed, 23 May 2012 17:30:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Sb911dZalRc5tqi9A4/Pi7f9bBCWEjO/j8OXGJlRyuZa18daT6TMEUFMcACsnB90; 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 [76.254.51.49] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXLwi-0004z8-Rg for mib-doctors@ietf.org; Wed, 23 May 2012 20:30:29 -0400 Message-ID: <002f01cd3944$c7a5bea0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: Date: Wed, 23 May 2012 17:33:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88d982eb710f943107f247b6524ea7e75b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.49 Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 00:30:30 -0000 Hi - > From: "Thomas Nadeau" ... > I appreciate your point about coverage, but the issue is getting > access to SmicNG for all of us. Unless reviews are divided up so that at > least one person > has access to it, then it will be difficult to get that coverage. Just as I don't see a need to standardize on *a* tool, I also don't see a need to *require* reviewers to use multiple tools. The technology is mature enough that, for purposes of a review, whatever tool the reviewer happens to choose should be sufficient. From my perspective, compiler coverage isn't a significant issue here. Randy From glenn@cysols.com Wed May 23 19:24: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 93DFA21F86B8 for ; Wed, 23 May 2012 19:24:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDFHwFllVMGv for ; Wed, 23 May 2012 19:24:55 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by ietfa.amsl.com (Postfix) with ESMTP id EEAF621F86B6 for ; Wed, 23 May 2012 19:24:54 -0700 (PDT) Received: from [192.168.0.193] (COOKIE.win2004.cysol.co.jp [192.168.0.193]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id q4O2OlGx001037 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 24 May 2012 11:24:48 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4FBD9BEA.3070103@cysols.com> Date: Thu, 24 May 2012 11:24:42 +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: <002f01cd3944$c7a5bea0$6b01a8c0@oemcomputer> In-Reply-To: <002f01cd3944$c7a5bea0$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 02:24:55 -0000 Hi, It is not really a need to standardize on *a* tool. The RFC editors use SmicNG. So, at some stage, generally the final stage, questions on errors/warnings from SmicNG do arise. These require some extra cycles of processing among editors/authors/ ADs. Glenn PS. One instance of warning not caught in smilint, but caught in SmicNG and not suppressible by using -C0F and option "Z" of SmicNG is: W: f(rfc6475b.mi2), (435,8) Sequence"PMip6MagHomeNetworkPrefixEntry" and Row "pmip6MagHomeNetworkPrefixEntry" should have related names. (2012/05/24 9:33), Randy Presuhn wrote: > Hi - > >> From: "Thomas Nadeau" > ... >> I appreciate your point about coverage, but the issue is getting >> access to SmicNG for all of us. Unless reviews are divided up so that at >> least one person >> has access to it, then it will be difficult to get that coverage. > > Just as I don't see a need to standardize on *a* tool, I also don't see > a need to *require* reviewers to use multiple tools. The technology is > mature enough that, for purposes of a review, whatever tool the reviewer > happens to choose should be sufficient. From my perspective, compiler > coverage isn't a significant issue here. > > Randy > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From dbharrington@comcast.net Wed May 23 19:31: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 32C7D11E80C5 for ; Wed, 23 May 2012 19:31:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ2-iQNJsiE2 for ; Wed, 23 May 2012 19:30:59 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7227D21F853F for ; Wed, 23 May 2012 19:30:59 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id De051j00227AodY5DeWzi6; Thu, 24 May 2012 02:30:59 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta19.westchester.pa.mail.comcast.net with comcast id DeWv1j0073Ecudz3feWwpq; Thu, 24 May 2012 02:30:59 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 23 May 2012 22:30:54 -0400 From: David Harrington To: Thomas Nadeau , Andy Bierman Message-ID: Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 02:31:04 -0000 Smilint is my preferred checker. I used to use smicng as a secondary, but stopped when I changed computers. Smicng DOES provide slightly different warnings, not all of which reflect MIB Doctor consensus. -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/23/12 9:49 AM, "Thomas Nadeau" wrote: > > >On 5/23/12 9:45 AM, "Andy Bierman" wrote: > >>On 05/23/2012 05:31 AM, Thomas Nadeau wrote: >>> >>> I guess the next logical question then would be to ask, if there is >>>such >>> reluctance to let this community use SMICng gratis (which his clearly >>> non-profit organization), should we standardize on a different (more >>> readily available) MIB compiler for our checks? Apologies if this has >>> been already discussed here. I am just trying to sort this out so I >>>don't >>> have to figure it out after I am assigned something to review, and >>> discover that I cannot compile it - or that we are all using different >>>MIB >>> compilers and get slightly different results. >>> >> >>I have not used SMICng in 10 years. >>I like smilint much better. >>It is easier to use and it is open-source code. > > I personally agree with you. I really like Smilint. However, is this the >consensus of MIB doctors, and is what we should use then for reviews? > > --Tom > > > > >> >> >>> --Tom >>> >> >>Andy >> >>> >>> On 5/23/12 8:25 AM, "Bert Wijnen (IETF)" wrote: >>> >>>> The author of SMICng, David Perkins, is to be asked. >>>> I would think that it would in fact be great for him >>>> to make it at least available for MIB doctors to do >>>> IETF MIB review/checking. >>>> >>>> I have asked him several times in the past (when I was AD, >>>> but also later). I believe Dan has asked him too. >>>> >>>> But as far as I know, he has not done so yet. >>>> >>>> Last email address I have for him: dperkins3600@gmail.com >>>> Bert >>>> >>>> On 5/23/12 2:12 PM, Thomas Nadeau wrote: >>>>> >>>>> Guys, >>>>> >>>>> A process question. How do we get access to SmicNG? Is there a >>>>> web-based version we can use or are MIB Doctors given a license to >>>>>run >>>>> it >>>>> locally? >>>>> >>>>> Also, do we keep some internal web page of who is reviewing what to >>>>> keep >>>>> track of review status? >>>>> >>>>> Finally, what is the process for how reviews are assigned, processed >>>>> and >>>>> released? Forgive me for asking. If there is a FAQ, please point me >>>>>at >>>>> it. >>>>> *) >>>>> >>>>> --Tom >>>>> >>>>> _______________________________________________ >>>>> 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 dbharrington@comcast.net Thu May 24 00:41:30 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 B278621F8555 for ; Thu, 24 May 2012 00:41:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+qhHBLO3K1N for ; Thu, 24 May 2012 00:41:30 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id E770721F8559 for ; Thu, 24 May 2012 00:41:29 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id DjhM1j0021ZXKqc51jhVjT; Thu, 24 May 2012 07:41:29 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta21.westchester.pa.mail.comcast.net with comcast id DjhS1j00W3Ecudz3hjhTjx; Thu, 24 May 2012 07:41:29 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 24 May 2012 03:41:25 -0400 From: David Harrington To: Thomas Nadeau , Randy Presuhn , "MIB Doctors (E-mail)" Message-ID: Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 07:41:30 -0000 Hi, DaveP gave me a license for my MIB Doctor review work a few years ago. I think he is willing to give licenses to any MIB Doctor that requests it. I am not sure what his email is currently. SMICng has not been updated in years. I wouldn't hold your breath waiting for Dave to produce a web-based version. I have a vague recollection that Dave sold the product to somebody (Chris Wellens??), so Dave might be constrained in what he can offer. Maybe Dave can be convinced to grant a license to MIB Doctors. Maybe we can convince the tools team to produce a web front-end restricted to MIB Doctors, or a locked web-front-end can be produced during a code sprint. If the RFC Editor uses SMICng, maybe we can get that made accessible to MIB Doctors (with appropriate licensing from Dave). -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/23/12 3:53 PM, "Thomas Nadeau" wrote: > > >On 5/23/12 1:57 PM, "Randy Presuhn" wrote: > >>Hi - >> >>> From: "Thomas Nadeau" >>> To: "Andy Bierman" >>> Cc: "MIB Doctors (E-mail)" >>> Sent: Wednesday, May 23, 2012 6:49 AM >>> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use >>... >>> I personally agree with you. I really like Smilint. However, is this >>>the >>> consensus of MIB doctors, and is what we should use then for reviews? >> >>I think *not* standardizing on a particular toolset is the right way to >>go. >>The differences in what the various tools "catch" (rightly or wrongly) >>keep us honest, especially about the greyer parts of the specifications. >> >>(And yes, on those rare occasions when I do a review, I generally use >>Smilint.) > > I appreciate your point about coverage, but the issue is getting >access to SmicNG for all of us. Unless reviews are divided up so that at >least one person >has access to it, then it will be difficult to get that coverage. > > One thing that might be useful even if we can't get access to running >SmicNG locally, is perhaps a web-based version that is restricted to just >IETF MIB Doctors. That way we install it once, but only this closed user >group gets access to run it. That might be acceptable to the author? > > --Tom > > > >> >>Randy >> >>_______________________________________________ >>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 dbharrington@comcast.net Thu May 24 00:57: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 8D66221F864D for ; Thu, 24 May 2012 00:57:04 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IxJNExWLNJ7 for ; Thu, 24 May 2012 00:57:03 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 6271A21F8649 for ; Thu, 24 May 2012 00:57:03 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id Djx21j0021GhbT85Fjx2q6; Thu, 24 May 2012 07:57:02 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta07.westchester.pa.mail.comcast.net with comcast id Djww1j00C3Ecudz3TjwxX1; Thu, 24 May 2012 07:57:02 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 24 May 2012 03:56:55 -0400 From: David Harrington To: Thomas Nadeau , "MIB Doctors (E-mail)" Message-ID: Thread-Topic: some advice to the new recruits In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [MIB-DOCTORS] some advice to the new recruits 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, 24 May 2012 07:57:04 -0000 Hi, I agree with Randy that which tool you use is not that important. What is important is that reviewers are fairly consistent. The new recruits should be aware of RFC4181 (and RFC4841). Those are the basic criteria we expect all incoming MIB modules to meet. To a degree, these guidelines were produced to prevent "reviewer pet peeves" from causing vastly different review requirements from different reviewers. The MIB Doctors need some consistency in what is required. Smilint captures many of these guidelines. SMICng is a good tool, but was produced before the MIB Doctors agreed to these guidelines, and some SMICng warnings do not represent MIB Doctor consensus. I recommend the recruits look at these guidelines from early MIB modules: "To be consistent with IAB directives and good engineering practices, an explicit attempt was made to keep this MIB module as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. " The MIB Doctors have not produced guidelines on a bunch of issues we look for, such as database normalization and object/table persistence. I recommend the recruits look over past reviews to see the types of problems that are found, and corrected. -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/23/12 3:53 PM, "Thomas Nadeau" wrote: > > >On 5/23/12 1:57 PM, "Randy Presuhn" wrote: > >>Hi - >> >>> From: "Thomas Nadeau" >>> To: "Andy Bierman" >>> Cc: "MIB Doctors (E-mail)" >>> Sent: Wednesday, May 23, 2012 6:49 AM >>> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use >>... >>> I personally agree with you. I really like Smilint. However, is this >>>the >>> consensus of MIB doctors, and is what we should use then for reviews? >> >>I think *not* standardizing on a particular toolset is the right way to >>go. >>The differences in what the various tools "catch" (rightly or wrongly) >>keep us honest, especially about the greyer parts of the specifications. >> >>(And yes, on those rare occasions when I do a review, I generally use >>Smilint.) > > I appreciate your point about coverage, but the issue is getting >access to SmicNG for all of us. Unless reviews are divided up so that at >least one person >has access to it, then it will be difficult to get that coverage. > > One thing that might be useful even if we can't get access to running >SmicNG locally, is perhaps a web-based version that is restricted to just >IETF MIB Doctors. That way we install it once, but only this closed user >group gets access to run it. That might be acceptable to the author? > > --Tom > > > >> >>Randy >> >>_______________________________________________ >>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 j.schoenwaelder@jacobs-university.de Thu May 24 01:11:32 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 BA3DD21F852A for ; Thu, 24 May 2012 01:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKKb-wcOKWhd for ; Thu, 24 May 2012 01:11:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF621F84B6 for ; Thu, 24 May 2012 01:11:26 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 373BC20C6C; Thu, 24 May 2012 10:11:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x3LZIv-Fs80R; Thu, 24 May 2012 10:11:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7620120C61; Thu, 24 May 2012 10:11:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6DB431F271A3; Thu, 24 May 2012 10:11:24 +0200 (CEST) Date: Thu, 24 May 2012 10:11:23 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20120524081123.GA5926@elstar.local> Mail-Followup-To: David Harrington , Thomas Nadeau , Randy Presuhn , "MIB Doctors (E-mail)" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 08:11:33 -0000 On Thu, May 24, 2012 at 03:41:25AM -0400, David Harrington wrote: > SMICng has not been updated in years. I wouldn't hold your breath > waiting for Dave to produce a web-based version. My usage of SMICng dates back to last century ;-) and back then I found SMICng difficult to use because I had to produce files to tell SMICng how to compile a MIB module properly. If this is still the case, I likely would not use it even if I would get a free license or a web frontend because writing those files was something I really disliked doing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tnadeau@juniper.net Thu May 24 05:41: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 A3D4221F8634 for ; Thu, 24 May 2012 05:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkplLOfnDH-V for ; Thu, 24 May 2012 05:41:28 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id CF8D221F8643 for ; Thu, 24 May 2012 05:41:27 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT74sdfHXYheq0yof//6NRED7rwAklJXV@postini.com; Thu, 24 May 2012 05:41:27 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 05:39:09 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 24 May 2012 05:39:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 24 May 2012 08:39:08 -0400 From: Thomas Nadeau To: David Harrington , Randy Presuhn , "MIB Doctors (E-mail)" Date: Thu, 24 May 2012 08:39:04 -0400 Thread-Topic: [MIB-DOCTORS] SmicNG for MIB Doctor Use Thread-Index: Ac05qjYq/4pTvFLJSX6d7wPC6YqWKw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 12:41:28 -0000 On 5/24/12 3:41 AM, "David Harrington" wrote: >Hi, > >DaveP gave me a license for my MIB Doctor review work a few years ago. >I think he is willing to give licenses to any MIB Doctor that requests it. >I am not sure what his email is currently. > >SMICng has not been updated in years. >I wouldn't hold your breath waiting for Dave to produce a web-based >version. >I have a vague recollection that Dave sold the product to somebody (Chris >Wellens??), so Dave might be constrained in what he can offer. > > >Maybe Dave can be convinced to grant a license to MIB Doctors. >Maybe we can convince the tools team to produce a web front-end restricted >to MIB Doctors, or a locked web-front-end can be produced during a code >sprint. That'd be ideal. >If the RFC Editor uses SMICng, maybe we can get that made accessible to >MIB Doctors (with appropriate licensing from Dave). Yes. That is what I was thinking; just extend the license. Although it would seem that its already appropriate for us to use it on behalf of the RFC Editor IMHO, and making it web-accessible but in a locked/restricted manner to this closed list of people is also appropriate. --Tom > >--=20 >David Harrington >dbharrington@comcast.net >+1-603-828-1401 > > > > > > > >On 5/23/12 3:53 PM, "Thomas Nadeau" wrote: > >> >> >>On 5/23/12 1:57 PM, "Randy Presuhn" wrote: >> >>>Hi - >>> >>>> From: "Thomas Nadeau" >>>> To: "Andy Bierman" >>>> Cc: "MIB Doctors (E-mail)" >>>> Sent: Wednesday, May 23, 2012 6:49 AM >>>> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use >>>... >>>> I personally agree with you. I really like Smilint. However, is this >>>>the >>>> consensus of MIB doctors, and is what we should use then for reviews? >>> >>>I think *not* standardizing on a particular toolset is the right way to >>>go. >>>The differences in what the various tools "catch" (rightly or wrongly) >>>keep us honest, especially about the greyer parts of the specifications. >>> >>>(And yes, on those rare occasions when I do a review, I generally use >>>Smilint.) >> >> I appreciate your point about coverage, but the issue is getting >>access to SmicNG for all of us. Unless reviews are divided up so that at >>least one person=20 >>has access to it, then it will be difficult to get that coverage. >> >> One thing that might be useful even if we can't get access to running >>SmicNG locally, is perhaps a web-based version that is restricted to just >>IETF MIB Doctors. That way we install it once, but only this closed user >>group gets access to run it. That might be acceptable to the author? >> >> --Tom >> >> >> >>> >>>Randy >>> >>>_______________________________________________ >>>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 May 24 08:05: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 1FACF21F8649; Thu, 24 May 2012 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFRIxcmL2-D5; Thu, 24 May 2012 08:05: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 E3BD321F8648; Thu, 24 May 2012 08:05: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 q4OF5qMn010051; Thu, 24 May 2012 17:05:52 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4OF5pI2021081; Thu, 24 May 2012 17:05:52 +0200 (CEST) Message-ID: <4FBE4E4F.9080503@cisco.com> Date: Thu, 24 May 2012 17:05:51 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Wesley Eddy References: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , iesg@ietf.org, IETF IPFIX Working Group Subject: Re: [MIB-DOCTORS] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) 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, 24 May 2012 15:05:58 -0000 Hi Dan, Wes, > Hi, > > Two comments: > > 1. If I got it right, Information Elements will be defined specifically > to meet logging requirements. It would be good to be explicit on this in > the deliverables list as well. Isn't it: Nov 2012 Submit to IESG: IPFIX information elements (std)? > > 2. It is not clear what the plans are concerning the MIB module(s). Will > there be two separate MIB modules to be used as needed with the existing > MIB module defined in RFC 4008? Or eventually there will be one MIB > module that updates the one defined in 4008 and adds NAT64 and CGNs > capabilities. If you're concerned about two deliverables Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) While there is apparently one entry in the charter text: Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, I have the same concern. Regards, Benoit. > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On >> Behalf Of IESG Secretary >> Sent: Tuesday, May 15, 2012 8:53 PM >> To: new-work@ietf.org >> Subject: [new-work] WG Review: Recharter of Behavior Engineering >> forHindrance Avoidance (behave) >> >> A modified charter has been submitted for the Behavior Engineering for >> Hindrance Avoidance (behave) working group in the Transport Area of > the >> IETF. The IESG has not made any determination as yet. The modified >> charter is provided below for informational purposes only. Please > send >> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May >> 22, 2012. >> >> Behavior Engineering for Hindrance Avoidance (behave) >> ----------------------------------------------------- >> Current Status: Active >> Last updated: 2012-05-10 >> >> Chairs: >> Dan Wing >> Dave Thaler >> >> Transport Area Directors: >> Wesley Eddy >> Martin Stiemerling >> >> Transport Area Advisor: >> Wesley Eddy >> >> Mailing Lists: >> General Discussion: behave@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/behave >> Archive: http://www.ietf.org/mail-archive/web/behave >> >> Description of Working Group >> >> The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 >> NATs to function in as deterministic a fashion as possible. >> >> To support deployments where communicating hosts require using >> different address families (IPv4 or IPv6), address family translation >> is >> needed to establish communication. In BEHAVE's specification work on >> this topic it will coordinate with the V6ops WG on requirements and >> operational considerations. >> >> "An IPv4 network" or "an IPv6 network" in the descriptions below refer >> to a network with a clearly identifiable administrative domain (e.g., >> an >> enterprise campus network, a mobile operator's cellular network, a >> residential subscriber network, etc.). It will also be that network >> that >> deploys the necessary equipment for translation. >> >> BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 >> Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network >> to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >> >> Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be >> consistent with the management aspects of its IPv6/IPv4 NAT solutions, >> and specify IPFIX information elements to meet logging requirements, >> reusing existing elements, if possible. >> >> In addition, when a NAT (such as a NAT64 in the "An IPv6 network to >> IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber >> fairness issues arise. As such, BEHAVE will complete its work on >> Carrier Grade NAT requirements for such scenarios, and update the NAT >> MIB as needed to meet such requirements. BEHAVE will not, however, >> standardize IPv4-specific behavioral mechanisms. >> >> The following scenarios remain in scope for discussion, but will not > be >> solved by BEHAVE: >> >> * An IPv4 network to IPv6 Internet, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv4 network using either >> public or private IPv4 address space. >> >> * IPv4 Internet to an IPv6 network, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv6 network where selected >> IPv6 hosts and services are to be reachable. >> >> This group will also provide reviews of any work by the MBoneD WG on >> multicast translation, including control traffic (IGMP and MLD), >> Single >> Source Multicast (SSM) and Any Source Multicast (ASM). >> >> If the WG deems it necessary, BEHAVE will revise RFCs previously >> published by BEHAVE. >> >> Goals and Milestones >> >> Done Submit BCP that defines unicast UDP behavioral requirements for >> NATs to IESG >> Done Submit a BCP that defines TCP behavioral requirements for NATs >> to IESG >> Done Submit a BCP that defines ICMP behavioral requirements for NATs >> to IESG >> Done Submit informational that discusses current NAT traversal >> techniques used by applications >> Done Submit BCP that defines multicast UDP >> Done Submit revision of RFC 3489 to IESG behavioral requirements for >> NATs to IESG >> Done Submit informational document for rfc3489bis test vectors >> Done Submit experimental document that describes how an application >> can determine the type of NAT it is behind >> Done Submit BCP document for DCCP NAT behavior >> Done Determine relative prioritization of the four translation cases. >> Documented in IETF74 minutes. >> Done Determine what solutions(s) and components are needed to solve >> each of the four cases. Create new milestones for the >> solution(s) and the components. Documented in IETF74 minutes. >> Done Submit to IESG: relaying of a TCP bytestream (std) >> Done Submit to IESG: relay protocol (std) >> Done Submit to IESG: TURN-URI document (std) >> Done Submit to IESG: IPv6 relay protocol (std) >> Done Submit to IESG: framework for IPv6/IPv4 translation (info) >> Done Submit to IESG: stateless IPv6/IPv4 translation (std) >> Done Submit to IESG: stateful IPv6/IPv4 translation (std) >> Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) >> Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) >> Done Determine need and scope of multicast 6/4 translation >> Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) >> Jul 2012 Submit to IESG: large scale NAT requirements (BCP) >> Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 >> translation (info) >> Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for >> local networks (std) >> Done Submit to IESG: host-based NAT46 translation for IPv4-only >> applications to access IPv6-only servers (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) >> Nov 2012 Submit to IESG: IPFIX information elements (std) >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work > From andy@netconfcentral.org Thu May 24 10:12:14 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 2A6FD21F862B for ; Thu, 24 May 2012 10:12:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcH5lbbaWMms for ; Thu, 24 May 2012 10:12:13 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 82FEF21F862A for ; Thu, 24 May 2012 10:12:13 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4OHCBiT014215 for ; Thu, 24 May 2012 13:12:11 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.168.164] ([75.84.168.164:49359] helo=[192.168.0.168]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 92/5F-25796-BEB6EBF4; Thu, 24 May 2012 13:12:11 -0400 Message-ID: <4FBE6BEA.5090904@netconfcentral.org> Date: Thu, 24 May 2012 10:12:10 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: David Harrington , Thomas Nadeau , Randy Presuhn , "MIB Doctors (E-mail)" References: <20120524081123.GA5926@elstar.local> In-Reply-To: <20120524081123.GA5926@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 24 May 2012 17:12:14 -0000 On 05/24/2012 01:11 AM, Juergen Schoenwaelder wrote: > On Thu, May 24, 2012 at 03:41:25AM -0400, David Harrington wrote: > >> SMICng has not been updated in years. I wouldn't hold your breath >> waiting for Dave to produce a web-based version. > > My usage of SMICng dates back to last century ;-) and back then I > found SMICng difficult to use because I had to produce files to tell > SMICng how to compile a MIB module properly. If this is still the > case, I likely would not use it even if I would get a free license or > a web frontend because writing those files was something I really > disliked doing. > +1 The reason I pushed so hard to standardize the .yang and .yin file extensions in YANG was based on all the tedious renaming I had to do with MIB modules. Just about every MIB tool expects a different file naming convention. > /js > Andy From macfaden@gmail.com Thu May 24 22:03: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 7865B21F856C for ; Thu, 24 May 2012 22:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alPvjcu3J+1j for ; Thu, 24 May 2012 22:03:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6B21F8568 for ; Thu, 24 May 2012 22:03:11 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so403010wib.13 for ; Thu, 24 May 2012 22:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9BlkDb8CRqtvGfW/ntcA2OTdA15/QHgTNsd2g2xQCDY=; b=CQBVqnhIWyo3jvSb5tHp0C7vYdkBTkXahK/VVnG6f7OoaAY8Ufy/hbGlXJGy4aUFp6 oNKM9nL+hrn8skbf/qIZ78GyBmyNDGzMrdPC+9JWE8i8TuzQrWeLC4IaKXgjyXce3J4s I/sctku6kix9mQ/rrt61NCirBkAnq7Sz018Ro2MNqRSlBj/rzT3x3ZqNAtHfbWLuR9Bo Xcod3IdmJUx+W4lHs4XUJwmfpzYC16Ko7YUx2HmJkdo7c9ugQeA0WjcETZp7ecmZFd4Y 86iT92/5JQK9Ssf8i6xFLO6AtGfr/4SK+Cb9mS012XWVqsLhPXJkUCy0vut375LMHOwx 5m+g== MIME-Version: 1.0 Received: by 10.216.228.150 with SMTP id f22mr866451weq.192.1337922190972; Thu, 24 May 2012 22:03:10 -0700 (PDT) Sender: macfaden@gmail.com Received: by 10.180.7.163 with HTTP; Thu, 24 May 2012 22:03:10 -0700 (PDT) Received: by 10.180.7.163 with HTTP; Thu, 24 May 2012 22:03:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 May 2012 22:03:10 -0700 X-Google-Sender-Auth: hcVBJFXcgXB9l0sw1bX1QdImFiQ Message-ID: From: Michael MacFaden To: David Harrington Content-Type: multipart/alternative; boundary=001636eeeb36ee1a4404c0d54837 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 25 May 2012 05:03:13 -0000 --001636eeeb36ee1a4404c0d54837 Content-Type: text/plain; charset=ISO-8859-1 I forwarded this email to David, will find out shortly. Mike On May 24, 2012 12:41 AM, "David Harrington" wrote: > Hi, > > DaveP gave me a license for my MIB Doctor review work a few years ago. > I think he is willing to give licenses to any MIB Doctor that requests it. > I am not sure what his email is currently. > > SMICng has not been updated in years. > I wouldn't hold your breath waiting for Dave to produce a web-based > version. > I have a vague recollection that Dave sold the product to somebody (Chris > Wellens??), so Dave might be constrained in what he can offer. > > > Maybe Dave can be convinced to grant a license to MIB Doctors. > Maybe we can convince the tools team to produce a web front-end restricted > to MIB Doctors, or a locked web-front-end can be produced during a code > sprint. > If the RFC Editor uses SMICng, maybe we can get that made accessible to > MIB Doctors (with appropriate licensing from Dave). > > -- > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > > > > > > On 5/23/12 3:53 PM, "Thomas Nadeau" wrote: > > > > > > >On 5/23/12 1:57 PM, "Randy Presuhn" wrote: > > > >>Hi - > >> > >>> From: "Thomas Nadeau" > >>> To: "Andy Bierman" > >>> Cc: "MIB Doctors (E-mail)" > >>> Sent: Wednesday, May 23, 2012 6:49 AM > >>> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use > >>... > >>> I personally agree with you. I really like Smilint. However, is this > >>>the > >>> consensus of MIB doctors, and is what we should use then for reviews? > >> > >>I think *not* standardizing on a particular toolset is the right way to > >>go. > >>The differences in what the various tools "catch" (rightly or wrongly) > >>keep us honest, especially about the greyer parts of the specifications. > >> > >>(And yes, on those rare occasions when I do a review, I generally use > >>Smilint.) > > > > I appreciate your point about coverage, but the issue is getting > >access to SmicNG for all of us. Unless reviews are divided up so that at > >least one person > >has access to it, then it will be difficult to get that coverage. > > > > One thing that might be useful even if we can't get access to > running > >SmicNG locally, is perhaps a web-based version that is restricted to just > >IETF MIB Doctors. That way we install it once, but only this closed user > >group gets access to run it. That might be acceptable to the author? > > > > --Tom > > > > > > > >> > >>Randy > >> > >>_______________________________________________ > >>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 > --001636eeeb36ee1a4404c0d54837 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I forwarded this email to David, will find out shortly.

Mike

On May 24, 2012 12:41 AM, "David Harrington= " <dbharrington@comcast= .net> wrote:
Hi,

DaveP gave me a license for my MIB Doctor review work a few years ago.
I think he is willing to give licenses to any MIB Doctor that requests it.<= br> I am not sure what his email is currently.

SMICng has not been updated in years.
I wouldn't hold your breath waiting for Dave to produce a web-based
version.
I have a vague recollection that Dave sold the product to somebody (Chris Wellens??), so Dave might be constrained in what he can offer.


Maybe Dave can be convinced to grant a license to MIB Doctors.
Maybe we can convince the tools team to produce a web front-end restricted<= br> to MIB Doctors, or a locked web-front-end can be produced during a code
sprint.
If the RFC Editor uses SMICng, maybe we can get that made accessible to
MIB Doctors (with appropriate licensing from Dave).

--
David Harrington
dbharrington@comcast.net +1-603-828-1401







On 5/23/12 3:53 PM, "Thomas Nadeau" <tnadeau@juniper.net> wrote:

>
>
>On 5/23/12 1:57 PM, "Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
>
>>Hi -
>>
>>> From: "Thomas Nadeau" <tnadeau@juniper.net>
>>> To: "Andy Bierman" <andy@netconfcentral.org>
>>> Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
>>> Sent: Wednesday, May 23, 2012 6:49 AM
>>> Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use
>>...
>>> I personally agree with you. I really like Smilint. However, i= s this
>>>the
>>> consensus of MIB doctors, and is what we should use then for r= eviews?
>>
>>I think *not* standardizing on a particular toolset is the right wa= y to
>>go.
>>The differences in what the various tools "catch" (rightl= y or wrongly)
>>keep us honest, especially about the greyer parts of the specificat= ions.
>>
>>(And yes, on those rare occasions when I do a review, I generally u= se
>>Smilint.)
>
> =A0 =A0 =A0 I appreciate your point about coverage, but the issue is g= etting
>access to SmicNG for all of us. Unless reviews are divided up so that a= t
>least one person
>has access to it, then it will be difficult to get that coverage.
>
> =A0 =A0 =A0 One thing that might be useful even if we can't get ac= cess to running
>SmicNG locally, is perhaps a web-based version that is restricted to ju= st
>IETF MIB Doctors. That way we install it once, but only this closed use= r
>group gets access to run it. =A0That might be acceptable to the author?=
>
> =A0 =A0 =A0 --Tom
>
>
>
>>
>>Randy
>>
>>_______________________________________________
>>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
--001636eeeb36ee1a4404c0d54837-- From bclaise@cisco.com Fri May 25 06:02: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 02B9F21F8690 for ; Fri, 25 May 2012 06:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLRzKh2W7mbO for ; Fri, 25 May 2012 06:02:07 -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 2371121F8674 for ; Fri, 25 May 2012 06:02:06 -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 q4PD22EK027380; Fri, 25 May 2012 15:02:02 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4PD20oD003891; Fri, 25 May 2012 15:02:01 +0200 (CEST) Message-ID: <4FBF82C8.2030206@cisco.com> Date: Fri, 25 May 2012 15:02:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020607040407020004020808" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SmicNG for MIB Doctor Use 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, 25 May 2012 13:02:08 -0000 This is a multi-part message in MIME format. --------------020607040407020004020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Note that dperkins@dsperkins.com is subscribed to this mib-doctors. A few days ago, I have asked Dave, on that email address, if he still wants to help with mib-doctors. No answer so far... Regards, Benoit. > Hi, > > DaveP gave me a license for my MIB Doctor review work a few years ago. > I think he is willing to give licenses to any MIB Doctor that requests it. > I am not sure what his email is currently. > > SMICng has not been updated in years. > I wouldn't hold your breath waiting for Dave to produce a web-based > version. > I have a vague recollection that Dave sold the product to somebody (Chris > Wellens??), so Dave might be constrained in what he can offer. > > > Maybe Dave can be convinced to grant a license to MIB Doctors. > Maybe we can convince the tools team to produce a web front-end restricted > to MIB Doctors, or a locked web-front-end can be produced during a code > sprint. > If the RFC Editor uses SMICng, maybe we can get that made accessible to > MIB Doctors (with appropriate licensing from Dave). > --------------020607040407020004020808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Note that dperkins@dsperkins.com is subscribed to this mib-doctors.
A few days ago, I have asked Dave, on that email address, if he still wants to help with mib-doctors. No answer so far...

Regards, Benoit.
Hi,

DaveP gave me a license for my MIB Doctor review work a few years ago.
I think he is willing to give licenses to any MIB Doctor that requests it.
I am not sure what his email is currently.

SMICng has not been updated in years.
I wouldn't hold your breath waiting for Dave to produce a web-based
version.
I have a vague recollection that Dave sold the product to somebody (Chris
Wellens??), so Dave might be constrained in what he can offer.


Maybe Dave can be convinced to grant a license to MIB Doctors.
Maybe we can convince the tools team to produce a web front-end restricted
to MIB Doctors, or a locked web-front-end can be produced during a code
sprint.
If the RFC Editor uses SMICng, maybe we can get that made accessible to
MIB Doctors (with appropriate licensing from Dave).

--------------020607040407020004020808-- From bclaise@cisco.com Fri May 25 06:07: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 C975D21F8698 for ; Fri, 25 May 2012 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oalKWjuNga-w for ; Fri, 25 May 2012 06:07:41 -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 07EC921F8673 for ; Fri, 25 May 2012 06:07:40 -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 q4PD7cqn028117; Fri, 25 May 2012 15:07:38 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4PD7b2R008135; Fri, 25 May 2012 15:07:38 +0200 (CEST) Message-ID: <4FBF8419.1050509@cisco.com> Date: Fri, 25 May 2012 15:07:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.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: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] some advice to the new recruits 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, 25 May 2012 13:07:41 -0000 Thanks Dave for that email. One more thing I would add is that the MIB-doctors email archives are available online. We should advertise this. That's a great source of information for anybody who wants to write a MIB module. Regards, Benoit. > Hi, > > I agree with Randy that which tool you use is not that important. > What is important is that reviewers are fairly consistent. > > The new recruits should be aware of RFC4181 (and RFC4841). > Those are the basic criteria we expect all incoming MIB modules to meet. > To a degree, these guidelines were produced to prevent "reviewer pet > peeves" from causing vastly different review requirements from different > reviewers. > The MIB Doctors need some consistency in what is required. > Smilint captures many of these guidelines. > SMICng is a good tool, but was produced before the MIB Doctors agreed to > these guidelines, and some SMICng warnings do not represent MIB Doctor > consensus. > > > I recommend the recruits look at these guidelines from early MIB modules: > "To be consistent with IAB directives and good engineering practices, > an explicit attempt was made to keep this MIB module as simple as > possible. This was accomplished by applying the following criteria > to objects proposed for inclusion: > > 1. Start with a small set of essential objects and add only as > further objects are needed. > > 2. Require that objects be essential for either fault or > configuration management. > > 3. Consider evidence of current use and/or utility. > > 4. Limit the total number of objects. > > 5. Exclude objects that are simply derivable from others in this or > other MIB modules. > > 6. Avoid causing critical sections to be heavily instrumented. The > guideline that was followed is one counter per critical section > per layer. > " > > The MIB Doctors have not produced guidelines on a bunch of issues we look > for, such as database normalization and object/table persistence. > I recommend the recruits look over past reviews to see the types of > problems that are found, and corrected. > > > > From bertietf@bwijnen.net Fri May 25 06:13: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 56CFB21F8686 for ; Fri, 25 May 2012 06:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.574 X-Spam-Level: X-Spam-Status: No, score=-99.574 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IdFPochoGwO for ; Fri, 25 May 2012 06:13:20 -0700 (PDT) Received: from relay57.tele2.vuurwerk.nl (relay57.tele2.vuurwerk.nl [62.250.3.57]) by ietfa.amsl.com (Postfix) with ESMTP id D542B21F867D for ; Fri, 25 May 2012 06:13:19 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1SXuKU-0001Wc-B2; Fri, 25 May 2012 15:13:18 +0200 Message-ID: <94399F574C2A48EDB18D43447ABF8CB7@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Benoit Claise" References: <4FBF8419.1050509@cisco.com> In-Reply-To: <4FBF8419.1050509@cisco.com> Date: Fri, 25 May 2012 15:13:08 +0200 Organization: Consultant 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 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] some advice to the new recruits 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, 25 May 2012 13:13:20 -0000 Inline ----- Original Message ----- From: "Benoit Claise" To: "David Harrington" Cc: "MIB Doctors (E-mail)" Sent: Friday, May 25, 2012 3:07 PM Subject: Re: [MIB-DOCTORS] some advice to the new recruits > Thanks Dave for that email. > > One more thing I would add is that the MIB-doctors email archives are > available online. > We should advertise this. That's a great source of information for > anybody who wants to write a MIB module. > I guess it is. BUT..... would you ever try to go through such an archive if you are writing a MIB module??? I doubt many (any?) people will have the patience to do that. Nevertheless, sure we can advertise it. And, I'd like to be pleasantly surprised. Bert > Regards, Benoit. > From bclaise@cisco.com Fri May 25 06:16:18 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 16C7A21F867D for ; Fri, 25 May 2012 06:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY1837Ha6OYi for ; Fri, 25 May 2012 06:16:16 -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 987C221F8686 for ; Fri, 25 May 2012 06:16:15 -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 q4PDGCuP029122; Fri, 25 May 2012 15:16:12 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4PDGBSM016066; Fri, 25 May 2012 15:16:11 +0200 (CEST) Message-ID: <4FBF861B.6030502@cisco.com> Date: Fri, 25 May 2012 15:16:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ulrich Herberg References: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> <4FB38732.3060500@cisco.com> <4FBA1453.7020308@cisco.com> <4FBABE7E.3090203@cisco.com> <4FBBDBEE.5070104@bwijnen.net> <165b01cd385d$88067150$981353f0$@olddog.co.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207050203050701030903" Cc: "MIB Doctors \(E-mail\)" , draft-ietf-manet-nhdp-mib@tools.ietf.org, manet-chairs@tools.ietf.org, adrian@olddog.co.uk Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending 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, 25 May 2012 13:16:18 -0000 This is a multi-part message in MIME format. --------------060207050203050701030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, On the top of the quick SMICng SYNTAX check done by Bert Wijnen, Tom Nadeau accepted to review this MIB module. Quoting Tom, "but not until late next week". This will be on time for the next IESG telechat. Thanks Tom. Regards, Benoit. > Adrian, > > thanks, I did not know that service. It seems to be a web interface > for smilint and related tools. But apparently, the SMICng tool > discoveres some more problems which smilint did not warn (e.g., the > max-access of the index objects). > > Best > Ulrich > > On Tue, May 22, 2012 at 1:57 PM, Adrian Farrel > wrote: > > Ulrich, > > just in case you are no aware of > http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/ > > Adrian > > *From:*Ulrich Herberg [mailto:ulrich@herberg.name > ] > *Sent:* 22 May 2012 19:37 > *To:* Bert Wijnen (IETF) > *Cc:* Benoit Claise; Adrian Farrel; manet-chairs@tools.ietf.org > ; MIB Doctors (E-mail); > draft-ietf-manet-nhdp-mib@tools.ietf.org > > > > *Subject:* Re: [MIB-DOCTORS] Heads-up MIB review impending > > Bert, > > On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) > > wrote: > > Unfortunately, there is not a free version (at least not current) > available as far as I know. I don;t understand why the author does not > just make it open source and available to everyone. > But that is his call I guess. > > > Okay, I see. My company will likely not pay for that, and > personally I'd rather go to vacations than buy a MIB compiler ;-) > > > Oh by the way, you also already user { mib-2 998 } for the MIB > OID!!! > that is not proper! You should use xxx or some such instead of 998 > (as you indicate in the rfc-editor comment ;-) > > > I know, that has been discovered in the IESG LC. The reason why we > did not put xxxx there is that smilint complains otherwise and > fails to compile. It will be fixed in the next revision of the > draft (or in the RFC editor queue). > > Best > Ulrich > > > Bert > > > > On 5/22/12 7:03 PM, Ulrich Herberg wrote: > > Bert, > > thank you very much for this first review. We will work on > fixing these and spin a new version. > > By the way, is there a free version of SMICng available? I > only have smilint. > > Best regards > Ulrich > > On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) > > >> wrote: > > This is by no means a full MIB review, but I did a > quick SMICng SYNTAX check: > > W: f(nhdp.mi2), (778,5) Row > "nhdpLibRemovedIfAddrSetEntry" has indexing > that may create variables with more than 128 sub-ids > W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has > indexing that may > create variables with more than 128 sub-ids > W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" > does not have a > consistent indexing scheme - index item > nhdpDiscIfIndex from base > row nhdpDiscIfSetEntry is not defined as an index > item > W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" > does not have a > consistent indexing scheme - index item > nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1425,16) Row > "nhdpNibLostNeighborSetEntry" does not have > a consistent indexing scheme - index item > nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" > does not have a > consistent indexing scheme - index item > nhdpDiscIfIndex from base row > nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1690,16) Row > "nhdpDiscNeighborSetPerfEntry" does not > have a consistent indexing scheme - index item > nhdpDiscRouterIndex from > base row nhdpDiscIfSetEntry is not defined as an > index item > W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" > does not have a > consistent indexing scheme - index item > nhdpDiscRouterIndex from base > row nhdpDiscIfSetEntry is not defined as an index item > W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in > notification > "nhdpNbrStateChange" is an index for a table > W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in > notification > "nhdp2HopNbrStateChange" is an index for a table > W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in > notification > "nhdpIfRxBadPacket" is anindex for a table > W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in > notification > "nhdpIfStateChange" is anindex for a table > W: f(nhdp.mi2), (2142,22) Duplicate item > "nhdpPerformanceGroup" > in MANDATORY-GROUPS for module "NHDP-MIB" > > > The first Warning got me to look at: > nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE > SYNTAX NhdpLibRemovedIfAddrSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A router's Removed Interface Address Set consists > of Removed Interface Address Tuples, one per > network > address: > > (IR_local_iface_addr, IR_time) > > The association between these addrs and > the router's Interface is found in the > > Standard MIB II's IP address table > (RFC1213)." > REFERENCE > "RFC6130." > > INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype, > > > nhdpLibRemovedIfAddrSetIpAddr } > ::= { nhdpLibRemovedIfAddrSetTable 1 } > > NhdpLibRemovedIfAddrSetEntry ::= > SEQUENCE { > > nhdpLibRemovedIfAddrSetIpAddrT__ype > InetAddressType, > nhdpLibRemovedIfAddrSetIpAddr > InetAddress, > nhdpLibRemovedIfAddrSetIpAddrP__refixLen > > > InetAddressPrefixLength, > nhdpLibRemovedIfAddrSetIfIndex > InterfaceIndexOrZero, > nhdpLibRemovedIfAddrSetIRTime > TimeStamp > } > > nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE > > > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the nhdpLibRemovedIfAddrSetIpAddr > in the InetAddress MIB (RFC4001). > > Only the values ipv4(1) and > ipv6(2) are supported." > REFERENCE > "RFC6130." > ::= { nhdpLibRemovedIfAddrSetEntry 1 } > > nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "nhdpLibRemovedIfAddrSetIpAddr is a > recently used address of an interface of > this router." > REFERENCE > "RFC6130." > ::= { nhdpLibRemovedIfAddrSetEntry 2 } > > And I note that: > > - the 2 INDEX obbjects are defined read-only. Normally > they would be > not-accessible!!! See RFC2578 > - If this is ALWAYS true: > > nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE > > > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the nhdpLibRemovedIfAddrSetIpAddr > in the InetAddress MIB (RFC4001). > > Only the values ipv4(1) and > ipv6(2) are supported." > Then you could do: > nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE > SYNTAX InetAddress (SIZE(4|16)) > MAX-ACCESS read-only > Otherwise you would have to add something to > description clause to > warn implementers that they should consider OID size. > > The third warning: > W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" > does not have a > consistent indexing scheme - index item > nhdpDiscIfIndex from base > row nhdpDiscIfSetEntry is not defined as an > index item > Seems a valid warning. But I am not 100% sure. I'd have > to go and study > more detauil to determine. > Anyways, these "inconsistent indexing" warnings are > indeed just > warnings. It may be OK, but it would be good to check > and make sure > that this results in proper (i.e. unique) indexing > values and that the > indexing is indeed as intended. > > Sorry, not enough time to check more details now. > > Bert > > ----- Original Message ----- From: "Benoit Claise" > > >> > > To: > >> > Cc: > >>; > > >>; > > >> > > > Sent: Tuesday, May 22, 2012 12:15 AM > > Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending > > > Dear all, > > I have deferred this draft for the next telechat. > > Regards, Benoit. > > Hi MIB doctors, > > We would really benefit from your expertise here. > Can we please have a volunteer. > If we don't find someone by the end of the day > (on telechat for this > Thursday), I'm afraid that I will have to defer > this draft to the next > telechat... > > Regards, Benoit. > > Hi MIB doctors, > > My bad for not following up on this one. I > will follow more closely from now > on. > Can we please have a volunteer to review > this MIB module, which is on the > IESG telechat for next Thursday. > > Regards, Benoit. > > Hi MIB Doctors, > > Heads up to give you extra review time. > > https://datatracker.ietf.org/__doc/draft-ietf-manet-nhdp-mib/ > > > > is going to > IETF > last call very soon and would benefit > significantly from a MIB Doctor > review by > the end of the last call. > > Thanks for the work you do. > > 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 > > > > --------------060207050203050701030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

On the top of the quick SMICng SYNTAX check done by Bert Wijnen, Tom Nadeau accepted to review this MIB module.
Quoting Tom, "but not until late next week".
This will be on time for the next IESG telechat.

Thanks Tom.

Regards, Benoit.

Adrian,

thanks, I did not know that service. It seems to be a web interface for smilint and related tools. But apparently, the SMICng tool discoveres some more problems which smilint did not warn (e.g., the max-access of the index objects).

Best
Ulrich

On Tue, May 22, 2012 at 1:57 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Ulrich,

 

just in case you are no aware of http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/

 

Adrian

 

From: Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: 22 May 2012 19:37
To: Bert Wijnen (IETF)
Cc: Benoit Claise; Adrian Farrel; manet-chairs@tools.ietf.org; MIB Doctors (E-mail); draft-ietf-manet-nhdp-mib@tools.ietf.org


Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending

 

Bert,

On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:

Unfortunately, there is not a free version (at least not current)
available as far as I know. I don;t understand why the author does not
just make it open source and available to everyone.
But that is his call I guess.


Okay, I see. My company will likely not pay for that, and personally I'd rather go to vacations than buy a MIB compiler ;-)

 


Oh by the way, you also already user { mib-2 998 } for the MIB OID!!!
that is not proper! You should use xxx or some such instead of 998
(as you indicate in the rfc-editor comment ;-)


I know, that has been discovered in the IESG LC. The reason why we did not put xxxx there is that smilint complains otherwise and fails to compile. It will be fixed in the next revision of the draft (or in the RFC editor queue).

Best
Ulrich
 


Bert



On 5/22/12 7:03 PM, Ulrich Herberg wrote:

Bert,

thank you very much for this first review. We will work on fixing these and spin a new version.

By the way, is there a free version of SMICng available? I only have smilint.

Best regards
Ulrich

On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net <mailto:bertietf@bwijnen.net>> wrote:

   This is by no means a full MIB review, but I did a quick SMICng SYNTAX check:

   W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing
        that  may create variables with more than 128 sub-ids
   W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that may
        create variables with more than 128 sub-ids
   W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a
        consistent  indexing scheme - index item nhdpDiscIfIndex from base
        row nhdpDiscIfSetEntry  is not defined as an index item
   W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a
        consistent indexing scheme - index item nhdpDiscRouterIndex from base
        row nhdpDiscIfSetEntry is not defined as an index item
   W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not have
        a consistent indexing scheme - index item nhdpDiscRouterIndex from base
        row nhdpDiscIfSetEntry is not defined as an index item
   W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a
        consistent indexing scheme - index item nhdpDiscIfIndex from base row
        nhdpDiscIfSetEntry is not defined as an index item
   W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not
        have a consistent indexing scheme - index item nhdpDiscRouterIndex from
        base row nhdpDiscIfSetEntry is not defined as an index item
   W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a
        consistent indexing scheme - index item nhdpDiscRouterIndex from base
        row nhdpDiscIfSetEntry is not defined as an index item
   W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification
   "nhdpNbrStateChange" is an index for a table
   W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification
   "nhdp2HopNbrStateChange" is an index for a table
   W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification
   "nhdpIfRxBadPacket" is anindex for a table
   W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification
   "nhdpIfStateChange" is anindex for a table
   W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup"
        in MANDATORY-GROUPS for module "NHDP-MIB"


   The first  Warning got me to look at:
      nhdpLibRemovedIfAddrSetEntry  OBJECT-TYPE
         SYNTAX      NhdpLibRemovedIfAddrSetEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
   "A router's Removed Interface Address Set consists
            of Removed Interface Address Tuples, one per network
            address:

            (IR_local_iface_addr, IR_time)

            The association between these addrs and
            the router's Interface is found in the

            Standard MIB II's IP address table
            (RFC1213)."
         REFERENCE
   "RFC6130."

         INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype,


                 nhdpLibRemovedIfAddrSetIpAddr }
      ::= { nhdpLibRemovedIfAddrSetTable 1 }

      NhdpLibRemovedIfAddrSetEntry ::=
         SEQUENCE {

            nhdpLibRemovedIfAddrSetIpAddrT__ype
              InetAddressType,
            nhdpLibRemovedIfAddrSetIpAddr
              InetAddress,
            nhdpLibRemovedIfAddrSetIpAddrP__refixLen


              InetAddressPrefixLength,
            nhdpLibRemovedIfAddrSetIfIndex
              InterfaceIndexOrZero,
            nhdpLibRemovedIfAddrSetIRTime
              TimeStamp
           }

     nhdpLibRemovedIfAddrSetIpAddrT__ype  OBJECT-TYPE


        SYNTAX      InetAddressType
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
   "The type of the nhdpLibRemovedIfAddrSetIpAddr
            in the InetAddress MIB (RFC4001).

            Only the values ipv4(1) and
            ipv6(2) are supported."
        REFERENCE
   "RFC6130."
     ::= { nhdpLibRemovedIfAddrSetEntry 1 }

     nhdpLibRemovedIfAddrSetIpAddr  OBJECT-TYPE
        SYNTAX      InetAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
   "nhdpLibRemovedIfAddrSetIpAddr is a
            recently used address of an interface of
            this router."
        REFERENCE
   "RFC6130."
     ::= { nhdpLibRemovedIfAddrSetEntry 2 }

   And I note that:

   - the 2 INDEX obbjects are defined read-only. Normally they would be
     not-accessible!!! See RFC2578
   - If this is ALWAYS true:

       nhdpLibRemovedIfAddrSetIpAddrT__ype  OBJECT-TYPE


          SYNTAX      InetAddressType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
   "The type of the nhdpLibRemovedIfAddrSetIpAddr
            in the InetAddress MIB (RFC4001).

            Only the values ipv4(1) and
            ipv6(2) are supported."
     Then you could do:
       nhdpLibRemovedIfAddrSetIpAddr  OBJECT-TYPE
          SYNTAX      InetAddress (SIZE(4|16))
          MAX-ACCESS  read-only
     Otherwise you would have to add something to description clause to
     warn implementers that they should consider OID size.

   The third warning:
     W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a
          consistent  indexing scheme - index item nhdpDiscIfIndex from base
          row nhdpDiscIfSetEntry  is not defined as an index item
   Seems a valid warning. But I am not 100% sure. I'd have to go and study
   more detauil to determine.
   Anyways, these "inconsistent indexing" warnings are indeed just
   warnings. It may be OK, but it would be good to check and make sure
   that this results in proper (i.e. unique) indexing values and that the
   indexing is indeed as intended.

   Sorry, not enough time to check more details now.

   Bert

   ----- Original Message ----- From: "Benoit Claise" <bclaise@cisco.com <mailto:bclaise@cisco.com>>

   To: <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>
   Cc: <manet-chairs@tools.ietf.org <mailto:manet-chairs@tools.ietf.org>>; <mib-doctors@ietf.org <mailto:mib-doctors@ietf.org>>;
   <draft-ietf-manet-nhdp-mib@__tools.ietf.org <mailto:draft-ietf-manet-nhdp-mib@tools.ietf.org>>


   Sent: Tuesday, May 22, 2012 12:15 AM

   Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending


       Dear all,

       I have deferred this draft for the next telechat.

       Regards, Benoit.

           Hi MIB doctors,

           We would really benefit from your expertise here.
           Can we please have a volunteer.
           If we don't find someone by the end of the day (on telechat for this
           Thursday), I'm afraid that I will have to defer this draft to the next
           telechat...

           Regards, Benoit.

               Hi MIB doctors,

               My bad for not following up on this one. I will follow more closely from now
               on.
               Can we please have a volunteer to review this MIB module, which is on the
               IESG telechat for next Thursday.

               Regards, Benoit.

                   Hi MIB Doctors,

                   Heads up to give you extra review time.

                   https://datatracker.ietf.org/__doc/draft-ietf-manet-nhdp-mib/


                   <https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/> is going to
                   IETF
                   last call very soon and would benefit significantly from a MIB Doctor
                   review by
                   the end of the last call.

                   Thanks for the work you do.

                   Adrian

                   _________________________________________________
                   MIB-DOCTORS mailing list
                   MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
                   https://www.ietf.org/mailman/__listinfo/mib-doctors <https://www.ietf.org/mailman/listinfo/mib-doctors>



               _________________________________________________
               MIB-DOCTORS mailing list
               MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
               https://www.ietf.org/mailman/__listinfo/mib-doctors <https://www.ietf.org/mailman/listinfo/mib-doctors>



           _________________________________________________
           MIB-DOCTORS mailing list
           MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
           https://www.ietf.org/mailman/__listinfo/mib-doctors <https://www.ietf.org/mailman/listinfo/mib-doctors>



       _________________________________________________
       MIB-DOCTORS mailing list
       MIB-DOCTORS@ietf.org <mailto:MIB-DOCTORS@ietf.org>
       https://www.ietf.org/mailman/__listinfo/mib-doctors <https://www.ietf.org/mailman/listinfo/mib-doctors>


 



--------------060207050203050701030903-- From dbharrington@comcast.net Fri May 25 07:36: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 1566521F86B6 for ; Fri, 25 May 2012 07:36:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heiDQ5JDsJeK for ; Fri, 25 May 2012 07:36:05 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 421FA21F86C5 for ; Fri, 25 May 2012 07:36:05 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id EC8R1j0041swQuc5DEc4op; Fri, 25 May 2012 14:36:04 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta15.westchester.pa.mail.comcast.net with comcast id EEc11j00R3Ecudz3bEc3D6; Fri, 25 May 2012 14:36:04 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 25 May 2012 10:36:01 -0400 From: David Harrington To: "Bert Wijnen (IETF)" , Benoit Claise Message-ID: Thread-Topic: [MIB-DOCTORS] some advice to the new recruits In-Reply-To: <94399F574C2A48EDB18D43447ABF8CB7@BertLaptop> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] some advice to the new recruits 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, 25 May 2012 14:36:06 -0000 Hi, I don't agree this would be a good archive for people wanting to learn to write a MIB. This email list is for MIB Doctors. The discussion tends to be about reaching agreement amongst the MIB Doctors on some esoteric point. This is where MIB Doctors go when they need help finding/interpreting the rules (such as the maximum value of a PEN). This is where MIB Doctors go if they don't like a design choice in a MIB module and want to know if other MIB Doctors agree, or to get alternate design suggestions. A person trying to learn to write a MIB will be totally lost and confused by these discussions. I think making the MIB reviews public could be a learning experience, but readers would need to sift through a lot of irrelevant stuff to find relevant nuggets. RFC4181 already gives them most of the nuggets we'll find in a MIB Doctor review. A MIB Doctor wiki might be a good way to capture additional nuggets from new reviews. Compare, for example, http://trac.tools.ietf.org/area/app/trac/wiki/TypicalAppsAreaIssues, and http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues. The mibs@ietf.org might be a better archive to check. This is where people writing a MIB are encouraged to seek help, so the focus is on advising MIB writers. But it does tend to be about solving problems MIB writers run into, rather than a from-scratch tutorial on how to write a MIB. Offering a Sunday tutorial on MIB writing, and/or producing a MIB-Doctor-written design guide would be far more helpful. Templates for writing MIB documents are already available on the tools page and from the RFC Editor. We've had quite a few discussions of a design guide (for things like table normalization, persistence, etc.) but haven't reached a point where somebody was willing to volunteer to hold the pen. A MIB design wiki might be a good way to start such a design guide, without demanding dedicated authorship from a MIB Doctor. There are multiple books available on MIBs; I find Dave Perkins' book "Understanding SNMP MIBs" most useful as a MIB Doctor (available on Amazon). -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/25/12 9:13 AM, "Bert Wijnen (IETF)" wrote: >Inline > >----- Original Message ----- >From: "Benoit Claise" >To: "David Harrington" >Cc: "MIB Doctors (E-mail)" >Sent: Friday, May 25, 2012 3:07 PM >Subject: Re: [MIB-DOCTORS] some advice to the new recruits > > >> Thanks Dave for that email. >> >> One more thing I would add is that the MIB-doctors email archives are >> available online. >> We should advertise this. That's a great source of information for >> anybody who wants to write a MIB module. >> > >I guess it is. BUT..... >would you ever try to go through such an archive if you are >writing a MIB module??? I doubt many (any?) people will >have the patience to do that. > >Nevertheless, sure we can advertise it. > >And, I'd like to be pleasantly surprised. > >Bert >> Regards, Benoit. >> >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From randy_presuhn@mindspring.com Fri May 25 10:45:21 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 7CAFD21F8724 for ; Fri, 25 May 2012 10:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukp8-OStygdF for ; Fri, 25 May 2012 10:45:21 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id E39B221F8723 for ; Fri, 25 May 2012 10:45:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=F8QBrLB+DMFia4CCOQWC/u6RA1JovhbPeOkQ7YRu0CxSvq3n33tRlZSMyDu5j+OX; 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.30.225.200] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXyZj-0008Rs-Uk for mib-doctors@ietf.org; Fri, 25 May 2012 13:45:20 -0400 Message-ID: <007d01cd3a9e$851fa5e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: Date: Fri, 25 May 2012 10:47:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f888f2ea48f879383c7b4f118f3c4d7b7e3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.225.200 Subject: Re: [MIB-DOCTORS] some advice to the new recruits 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, 25 May 2012 17:45:21 -0000 Hi - > From: "David Harrington" ... > I don't agree this would be a good archive for people wanting to learn to > write a MIB. > > This email list is for MIB Doctors. > The discussion tends to be about reaching agreement amongst the MIB > Doctors on some esoteric point. ... Very much agreed. I also think we need to be very careful about well-intended efforts to provide more general guidance. What might seem in the abstract to be sound advice can sometimes for specific use cases produce bad results. For example, a lofty-sounding recommendation to normalize can be counter- productive if the design goal is to minimize round-trips for multiple query types and the available mechanism is GetNext / GetBulk. The work of a conscientious MIB Doctor involves careful judgement and knowledge of the "bags of tricks" used in the Rube Goldberg world of MIB design, not just following checklists. Randy From dbharrington@comcast.net Fri May 25 11:16: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 0C72B21F8741 for ; Fri, 25 May 2012 11:16:49 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSJFnX9d6y2T for ; Fri, 25 May 2012 11:16:48 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE321F86A7 for ; Fri, 25 May 2012 11:16:48 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta15.westchester.pa.mail.comcast.net with comcast id EJ0U1j00U1uE5Es5FJGnEF; Fri, 25 May 2012 18:16:47 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id EJGl1j00Z3Ecudz3cJGm21; Fri, 25 May 2012 18:16:47 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 25 May 2012 14:16:44 -0400 From: David Harrington To: Randy Presuhn , "MIB Doctors (E-mail)" Message-ID: Thread-Topic: [MIB-DOCTORS] some advice to the new recruits In-Reply-To: <007d01cd3a9e$851fa5e0$6b01a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MIB-DOCTORS] some advice to the new recruits 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, 25 May 2012 18:16:49 -0000 Agreed. I am using "normalize" very loosely in this discussion. I really mean fate-sharing, et al. -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 5/25/12 1:47 PM, "Randy Presuhn" wrote: >Hi - > >> From: "David Harrington" >... >> I don't agree this would be a good archive for people wanting to learn >>to >> write a MIB. >> >> This email list is for MIB Doctors. >> The discussion tends to be about reaching agreement amongst the MIB >> Doctors on some esoteric point. >... > >Very much agreed. I also think we need to be very careful about >well-intended >efforts to provide more general guidance. What might seem in the >abstract to >be sound advice can sometimes for specific use cases produce bad results. >For example, a lofty-sounding recommendation to normalize can be counter- >productive if the design goal is to minimize round-trips for multiple >query types >and the available mechanism is GetNext / GetBulk. The work of a >conscientious >MIB Doctor involves careful judgement and knowledge of the "bags of >tricks" >used in the Rube Goldberg world of MIB design, not just following >checklists. > >Randy > >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors