From j.schoenwaelder@jacobs-university.de Thu Mar 1 09:54: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 B586121F8B04 for ; Thu, 1 Mar 2012 09:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 kbjKSluHaHpq for ; Thu, 1 Mar 2012 09:54:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E963721F89F3 for ; Thu, 1 Mar 2012 09:54:46 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 495A320E1F; Thu, 1 Mar 2012 18:54:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Fuzic_jcz-8; Thu, 1 Mar 2012 18:54:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3B3020E1E; Thu, 1 Mar 2012 18:54:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B10EE1D9B121; Thu, 1 Mar 2012 18:54:45 +0100 (CET) Date: Thu, 1 Mar 2012 18:54:45 +0100 From: Juergen Schoenwaelder To: Michelle Cotton Message-ID: <20120301175445.GA33371@elstar.local> Mail-Followup-To: Michelle Cotton , "mib-doctors@ietf.org" , Pearl Liang References: <20120219110502.GC76109@elstar.local> 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@ietf.org" , Pearl Liang Subject: Re: [MIB-DOCTORS] Question to the MIB doctors regarding MIB registries at IANA 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, 01 Mar 2012 17:54:47 -0000 On Thu, Mar 01, 2012 at 09:23:05AM -0800, Michelle Cotton wrote: > Hello Juergen, > > Thank you very much for your response. > > The XML pages do *not* require JavaScript to be meaningfully rendered. > We only make accessory use of JavaScript for sorting the tables when you > click on the sort button next to the column header. > > If you could further clarify your concern, we may be able to provide more > information. I stand corrected. A plain text browser like w3m will show me the XML content which is good. I was confused because my firefox shows all the text contained in the XML elements (and nothing else) while JavaScript was disabled. Once I enable www.viagenie.ca in my "NoScript" filter, things render nicely. So I guess I just have an odd browser setup. /js PS: If you want to followup, we should take this off the list since this does not seem at all a MIB doctor topic. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From michelle.cotton@icann.org Thu Mar 1 09:23: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 B95DA21E8089 for ; Thu, 1 Mar 2012 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.36 X-Spam-Level: X-Spam-Status: No, score=-106.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2I+A6K-bkEhH for ; Thu, 1 Mar 2012 09:23:10 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id DC42421E805F for ; Thu, 1 Mar 2012 09:23:09 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 1 Mar 2012 09:23:09 -0800 From: Michelle Cotton To: Juergen Schoenwaelder Date: Thu, 1 Mar 2012 09:23:05 -0800 Thread-Topic: [MIB-DOCTORS] Question to the MIB doctors regarding MIB registries at IANA Thread-Index: Acz3z/iu186WDexxTFyVdad/0rDtTA== Message-ID: In-Reply-To: <20120219110502.GC76109@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Mar 2012 07:12:37 -0800 Cc: "mib-doctors@ietf.org" , Pearl Liang Subject: Re: [MIB-DOCTORS] Question to the MIB doctors regarding MIB registries at IANA 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, 01 Mar 2012 17:23:10 -0000 Hello Juergen, Thank you very much for your response. The XML pages do *not* require JavaScript to be meaningfully rendered. We only make accessory use of JavaScript for sorting the tables when you click on the sort button next to the column header. If you could further clarify your concern, we may be able to provide more information. --Michelle On 2/19/12 3:05 AM, "Juergen Schoenwaelder" wrote: >On Fri, Feb 17, 2012 at 11:24:27AM -0800, Michelle Cotton wrote: >> Hello MIB Doctors, >>=20 >> As you may or may not be aware, we are almost finished with converting >>the IANA registries to using xml as the source. >> There are approximately 14 maintained MIBs on the IANA protocols page. >>We understand these files need to be kept in a text format to retain >>their functionality. >> What we are proposing is the following: >>=20 >> Using the IANA Finisher MIB as an example=8A. >>=20 >> At the Protocols page, http://www.iana.org/protocols, when you click on >>IANA Finisher MIB, you will go to a page that looks like this: >>=20 >> http://www.viagenie.ca/ianaxml/ianafinisher-mib/ianafinisher-mib.xml >> (Viagenie is assisting us with some of the conversions=8Athis is why thi= s >>mock-up is located on their website) >>=20 >> You will see at the bottom there is an attached file which contains the >>simple MIB, just as it appears currently on the IANA website. >> Will this new format work for everyone? Are there any questions or >>concerns? > >There is a general concern that the XML pages require Java script >support to be meaningfully rendered - but that is a meta issue and I >might be in the majority of people who is running tools that do not >run Java script. >=20 >> I hope that this will satisfy both our goal of converting the >>registries to XML as the source and keeping the functionality of the >>MIBs. > >What matters most is that the MIB files are available and that the >location where they can be fetched is stable. (Ideally does not even >change from where they are now - but if you change them, try to find a >location that can stay stable.) > >/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 Tue Mar 6 06:36: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 437AD21F8864 for ; Tue, 6 Mar 2012 06:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 KV50Gcjo1Nmw for ; Tue, 6 Mar 2012 06:36:57 -0800 (PST) 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 7DA4121F88AE for ; Tue, 6 Mar 2012 06:36:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJEfVk/GmAcF/2dsb2JhbABDtGuBB4F/AQEDEh4KUQEVFQYMDAdXAQQbARmHZQuYYYQXnBuNPII/YwSbRIoRgmQ X-IronPort-AV: E=Sophos;i="4.73,540,1325480400"; d="scan'208";a="334788857" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Mar 2012 09:36:52 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Mar 2012 09:29:25 -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: Tue, 6 Mar 2012 15:36:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: help with the ADSL-TDIM MIB Thread-Index: Acz7noBUsEZl9NwfTZu7CtmdAGQMVgABipZw From: "Romascanu, Dan (Dan)" To: Subject: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:36:58 -0000 Hi MIB Doctors, With Bert's help we checked the ADSL MIB modules in the 4 documents now in IETF LC.=20 We encountered a potential problem with http://www.ietf.org/id/draft-ietf-adslmib-gbond-tdim-mib-07.txt Quoting Bert:=20 With SMICNG STRICT checking I get these additional warning for gbond-tdim: W: f(gbond-tdim.mi2), (169,8) Variable "gBondTdimOperSvcPosition" in notification "gBondTdi mSvcUp" is an index for a table W: f(gbond-tdim.mi2), (196,8) Variable "gBondTdimOperSvcPosition" in notification "gBondTdi mSvcDown" is an index for a table And then looking into the gbond-atm MIB file, I am surprised to see: gBondTdimOperSvcEntry OBJECT-TYPE SYNTAX GBondTdimOperSvcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the G.Bond/TDIM Port Operational Service table, containing the index of an active Service entry in the gBondTdimSvcTable. The entry is indexed by ifIndex, indicating corresponding G.Bond/TDIM port, and by gBondTdimOperSvcPosition (1..60), indicating the corresponding service position in the G.Bond/TDIM frame." INDEX { ifIndex, gBondTdimOperSvcPosition } ::=3D { gBondTdimOperSvcTable 1 } GBondTdimOperSvcEntry ::=3D SEQUENCE { gBondTdimOperSvcPosition GBondTdimSvcOrderIndex, gBondTdimOperSvcIdx GBondTdimSvcIndex, gBondTdimOperSvcState INTEGER } gBondTdimOperSvcPosition OBJECT-TYPE SYNTAX GBondTdimSvcOrderIndex MAX-ACCESS read-only STATUS current This means that the object is indeed an index object and so does not need to be included in this object clause: gBondTdimSvcUp NOTIFICATION-TYPE OBJECTS { -- ifIndex is not needed here since we are under specific GBS gBondTdimOperSvcPosition, gBondTdimSvcIfIdx, gBondTdimOperSvcState } because it is already part of the OID for gbindTdimSvcIfIdx But I am also surprised that the object gBondTdimOperSvcPosition OBJECT-TYPE SYNTAX GBondTdimSvcOrderIndex MAX-ACCESS read-only STATUS current is read-only! Index objects should (normally) be not-accessible. I suspect they did that because otherwise the inclusion in the NOTIFICATION-TYPE OBJECTS clause causes and error and not just a warning. I had actually expected a warning/error from SMICng for the fact that the index object is read-only !!?? Now my reading is that they made the index object readable in order to ease the work of the management applications - some have a hard time separating an index with meaningful information. As no critical error is shouted I am inclined to let it pass.=20 Any opinions?=20 Thanks and Regards, Dan From j.schoenwaelder@jacobs-university.de Tue Mar 6 07:22:24 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C679A21F890C for ; Tue, 6 Mar 2012 07:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 jhUz7XsKdmUk for ; Tue, 6 Mar 2012 07:22:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9930321F88E8 for ; Tue, 6 Mar 2012 07:22:23 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC5D20CDB; Tue, 6 Mar 2012 16:22:22 +0100 (CET) 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 VcZ_4Np0QQzy; Tue, 6 Mar 2012 16:22:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EF5220CB7; Tue, 6 Mar 2012 16:22:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2B5D1DA5363; Tue, 6 Mar 2012 16:22:21 +0100 (CET) Date: Tue, 6 Mar 2012 16:22:21 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120306152221.GA2081@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , mib-doctors@ietf.org 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@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB 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, 06 Mar 2012 15:22:25 -0000 On Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) wrote: [...] > Now my reading is that they made the index object readable in order to > ease the work of the management applications - some have a hard time > separating an index with meaningful information. As no critical error is > shouted I am inclined to let it pass. We have insisted for more than a decade on the rule that index objects are not-accessible and I think changing the policy should not be done that easily or arbitrarily. If we want to change this policy, we should discuss it and then document it to ensure fair treatment of all MIB modules. (And a quick look suggests that the tables in the ADSL2-MIB for example have not-accessible index objects - so allowing read-only in the ADSL-TDIM MIB hardly helps the ADSL people in general.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From macfaden@gmail.com Tue Mar 6 23:43: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 B5D4421E806E for ; Tue, 6 Mar 2012 23:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 QTmMeKCJaJY4 for ; Tue, 6 Mar 2012 23:43:21 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BED1F21E804E for ; Tue, 6 Mar 2012 23:43:20 -0800 (PST) Received: by wicr5 with SMTP id r5so3266842wic.31 for ; Tue, 06 Mar 2012 23:43:20 -0800 (PST) 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:content-type; bh=mKK60j+Yj1dBARuObMT5YPN90wcIP2DJ0b0XPc23zbQ=; b=LHZGXsb+j3oqZcxvHI7RYrVwbYbCFGH7EwmrOFJUsy26cpA7oq6fKVHUzQUu5ItvaZ a2TW0QdO91ee+tTBpJQLHzWhM8K6av0KluLJPReA60Vi/CpCq6SxYyNw7w+UcUKnyRFm ccF8XUJ1s/98JLMG2iuSSFwFDC7c3cUHFk1pDjh6SRhIUgQkReG4Drc/Jnud7gfEwyoT o3KjcqA1PpPWD+LLi1Jbw1S/g6vn2/NelS+RH5tVRNEkNMpCkYnXnP6qGA0SkIXk7QVe dk7J3vWPHD1OjJUU0lE4JCTA9ezqqx7v3Ys5KcVuDfA1mjq2SpAPGezZuiPz+7E68YPx 5AWQ== MIME-Version: 1.0 Received: by 10.216.139.194 with SMTP id c44mr420518wej.112.1331106199812; Tue, 06 Mar 2012 23:43:19 -0800 (PST) Sender: macfaden@gmail.com Received: by 10.180.19.135 with HTTP; Tue, 6 Mar 2012 23:43:19 -0800 (PST) Received: by 10.180.19.135 with HTTP; Tue, 6 Mar 2012 23:43:19 -0800 (PST) In-Reply-To: <20120306152221.GA2081@elstar.local> References: <20120306152221.GA2081@elstar.local> Date: Tue, 6 Mar 2012 23:43:19 -0800 X-Google-Sender-Auth: xDJB3yGXvNFXczA8skd9YJeKXDA Message-ID: From: Michael MacFaden To: mib-doctors@ietf.org, "Romascanu, Dan (Dan)" , Juergen Schoenwaelder Content-Type: multipart/alternative; boundary=0016e6d58d7832b8ef04baa25082 Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:43:21 -0000 --0016e6d58d7832b8ef04baa25082 Content-Type: text/plain; charset=ISO-8859-1 I agree with Juergen. They could create another object in the notification with accessible for notify. Mike On Mar 6, 2012 7:22 AM, "Juergen Schoenwaelder" < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) wrote: > > [...] > > > Now my reading is that they made the index object readable in order to > > ease the work of the management applications - some have a hard time > > separating an index with meaningful information. As no critical error is > > shouted I am inclined to let it pass. > > We have insisted for more than a decade on the rule that index objects > are not-accessible and I think changing the policy should not be done > that easily or arbitrarily. If we want to change this policy, we > should discuss it and then document it to ensure fair treatment of all > MIB modules. (And a quick look suggests that the tables in the > ADSL2-MIB for example have not-accessible index objects - so allowing > read-only in the ADSL-TDIM MIB hardly helps the ADSL people in general.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > --0016e6d58d7832b8ef04baa25082 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I agree with Juergen. They could create another object in the notificati= on with accessible for notify.

Mike

On Mar 6, 2012 7:22 AM, "Juergen Schoenwael= der" <j.sch= oenwaelder@jacobs-university.de> wrote:
On Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) wrote:

[...]

> Now my reading is that they made the index object readable in order to=
> ease the work of the management applications - some have a hard time > separating an index with meaningful information. As no critical error = is
> shouted I am inclined to let it pass.

We have insisted for more than a decade on the rule that index objects
are not-accessible and I think changing the policy should not be done
that easily or arbitrarily. If we want to change this policy, we
should discuss it and then document it to ensure fair treatment of all
MIB modules. (And a quick look suggests that the tables in the
ADSL2-MIB for example have not-accessible index objects - so allowing
read-only in the ADSL-TDIM MIB hardly helps the ADSL people in general.)
/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
--0016e6d58d7832b8ef04baa25082-- From dromasca@avaya.com Wed Mar 7 03:10: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 4FA0221F8670 for ; Wed, 7 Mar 2012 03:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qeGPmAiSiEB3 for ; Wed, 7 Mar 2012 03:10:20 -0800 (PST) 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 D7A4521F84D7 for ; Wed, 7 Mar 2012 03:10:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssLAA1BV0+HCzI1/2dsb2JhbABAA4JFpSeGFYcNgQeBfQEBAQECAQEBAQ8KEQM+EAkCAgEIDQMBBAEBCwYMCwEGARoGBh8JCAEBBAESCBqHYAULngacMwSJN4QOgkRjBJtEhRuEdoJk X-IronPort-AV: E=Sophos;i="4.73,545,1325480400"; d="scan'208,217";a="295513705" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Mar 2012 06:10:17 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Mar 2012 05:55:01 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFC52.DA8FEC7C" Date: Wed, 7 Mar 2012 12:10:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] help with the ADSL-TDIM MIB Thread-Index: Acz8Nfi0yJqWBhNxRumrZtbHuVxaHAAHKKXA References: <20120306152221.GA2081@elstar.local> From: "Romascanu, Dan (Dan)" To: "Michael MacFaden" , , "Juergen Schoenwaelder" Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 11:10:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFC52.DA8FEC7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I accept the suggestions from Juergen and Mike, thanks! =20 I will ask the editor to re-spin the TDM-MIB, making the index object not-accessible and introducing a corresponding object accessible-for-notify for notifications.=20 =20 Regards, =20 Dan =20 =20 =20 From: macfaden@gmail.com [mailto:macfaden@gmail.com] On Behalf Of Michael MacFaden Sent: Wednesday, March 07, 2012 9:43 AM To: mib-doctors@ietf.org; Romascanu, Dan (Dan); Juergen Schoenwaelder Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB =20 I agree with Juergen. They could create another object in the notification with accessible for notify.=20 Mike=20 On Mar 6, 2012 7:22 AM, "Juergen Schoenwaelder" wrote: On Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) wrote: [...] > Now my reading is that they made the index object readable in order to > ease the work of the management applications - some have a hard time > separating an index with meaningful information. As no critical error is > shouted I am inclined to let it pass. We have insisted for more than a decade on the rule that index objects are not-accessible and I think changing the policy should not be done that easily or arbitrarily. If we want to change this policy, we should discuss it and then document it to ensure fair treatment of all MIB modules. (And a quick look suggests that the tables in the ADSL2-MIB for example have not-accessible index objects - so allowing read-only in the ADSL-TDIM MIB hardly helps the ADSL people in general.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ------_=_NextPart_001_01CCFC52.DA8FEC7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I accept the suggestions from Juergen and Mike, = thanks!

 

I will ask the editor to re-spin the TDM-MIB, making the index object = not-accessible and introducing a corresponding object = accessible-for-notify for notifications.

 

Regards,

 

Dan

 

 

 

From:= = macfaden@gmail.com [mailto:macfaden@gmail.com] On Behalf Of = Michael MacFaden
Sent: Wednesday, March 07, 2012 9:43 = AM
To: mib-doctors@ietf.org; Romascanu, Dan (Dan); Juergen = Schoenwaelder
Subject: Re: [MIB-DOCTORS] help with the = ADSL-TDIM MIB

 

I agree with Juergen. They = could create another object in the notification with accessible for = notify.

Mike

On Mar 6, 2012 7:22 AM, "Juergen = Schoenwaelder" <j.schoenwaelder@jaco= bs-university.de> wrote:

On = Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) = wrote:

[...]

> Now my reading is that they made the = index object readable in order to
> ease the work of the = management applications - some have a hard time
> separating an = index with meaningful information. As no critical error is
> = shouted I am inclined to let it pass.

We have insisted for more = than a decade on the rule that index objects
are not-accessible and I = think changing the policy should not be done
that easily or = arbitrarily. If we want to change this policy, we
should discuss it = and then document it to ensure fair treatment of all
MIB modules. = (And a quick look suggests that the tables in the
ADSL2-MIB for = example have not-accessible index objects - so allowing
read-only in = the ADSL-TDIM MIB hardly helps the ADSL people in = general.)

/js

--
Juergen Schoenwaelder     =       Jacobs University Bremen gGmbH
Phone: +49 421 200 3587     =     Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103     =     <http://www.jacobs-university.de/>
___________= ____________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

------_=_NextPart_001_01CCFC52.DA8FEC7C-- From j.schoenwaelder@jacobs-university.de Wed Mar 7 04:13: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 273D221F8716 for ; Wed, 7 Mar 2012 04:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 kpseiDFcKRK5 for ; Wed, 7 Mar 2012 04:13:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6166121F8713 for ; Wed, 7 Mar 2012 04:13:07 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6881A20CFC; Wed, 7 Mar 2012 13:13:06 +0100 (CET) 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 O4rM2KG5qsGM; Wed, 7 Mar 2012 13:13:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1112A20CF8; Wed, 7 Mar 2012 13:13:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2224C1DA725D; Wed, 7 Mar 2012 13:13:05 +0100 (CET) Date: Wed, 7 Mar 2012 13:13:05 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120307121305.GA4853@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Michael MacFaden , mib-doctors@ietf.org References: <20120306152221.GA2081@elstar.local> 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: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB 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, 07 Mar 2012 12:13:08 -0000 On Wed, Mar 07, 2012 at 12:10:05PM +0100, Romascanu, Dan (Dan) wrote: > I accept the suggestions from Juergen and Mike, thanks! > > I will ask the editor to re-spin the TDM-MIB, making the index object > not-accessible and introducing a corresponding object > accessible-for-notify for notifications. > The accessible-for-notify object is not strictly needed with the same logic that applies to index objects of ordinary tables. I think I recall a case where once someone wanted to make a table index accessible-for-notify for such a reason - I have to search what the outcome of that discussion was. In general, we do not have special accessible-for-notify objects for index objects just to carry them in notifications. (After all, this is all redundant information.) /js -- 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 Wed Mar 7 04:56: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 2164621F87A3 for ; Wed, 7 Mar 2012 04:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 SU0Yd9AIxLa6 for ; Wed, 7 Mar 2012 04:56:22 -0800 (PST) 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 84D2421F87A0 for ; Wed, 7 Mar 2012 04:56:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAJRZV0+HCzI1/2dsb2JhbABDrX6HGIEHggoBAQEBAxIeCj8MBAIBCA0BAgEEAQEBCgYMCwEGAUUJCAEBBBMIGodmnVCcN5AMYwSbR4oRgmQ X-IronPort-AV: E=Sophos;i="4.73,545,1325480400"; d="scan'208";a="335022886" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Mar 2012 07:56:21 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Mar 2012 07:41:15 -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: Wed, 7 Mar 2012 13:56:19 +0100 Message-ID: In-Reply-To: <20120307121305.GA4853@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] help with the ADSL-TDIM MIB Thread-Index: Acz8W7aV6PkC1h5vS9OdRl7mE3Lo6gABd5mA References: <20120306152221.GA2081@elstar.local> <20120307121305.GA4853@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 12:56:23 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, March 07, 2012 2:13 PM > To: Romascanu, Dan (Dan) > Cc: Michael MacFaden; mib-doctors@ietf.org > Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB >=20 > On Wed, Mar 07, 2012 at 12:10:05PM +0100, Romascanu, Dan (Dan) wrote: > > I accept the suggestions from Juergen and Mike, thanks! > > > > I will ask the editor to re-spin the TDM-MIB, making the index object > > not-accessible and introducing a corresponding object > > accessible-for-notify for notifications. > > >=20 > The accessible-for-notify object is not strictly needed with the same > logic that applies to index objects of ordinary tables. I think I > recall a case where once someone wanted to make a table index > accessible-for-notify for such a reason - I have to search what the > outcome of that discussion was. In general, we do not have special > accessible-for-notify objects for index objects just to carry them in > notifications. (After all, this is all redundant information.) >=20 > /js >=20 Yes, please - if you can find that discussion it would be useful.=20 Thanks,=20 Dan From j.schoenwaelder@jacobs-university.de Wed Mar 7 06:36: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 3815F21F87B6 for ; Wed, 7 Mar 2012 06:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, 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 6wYDwGzfa9Ay for ; Wed, 7 Mar 2012 06:36:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9FD21F8633 for ; Wed, 7 Mar 2012 06:36:31 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B67420CF5; Wed, 7 Mar 2012 15:36:30 +0100 (CET) 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 ubQjKkYRTHGS; Wed, 7 Mar 2012 15:36:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C75C620CF0; Wed, 7 Mar 2012 15:36:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E9F4A1DA768B; Wed, 7 Mar 2012 15:36:28 +0100 (CET) Date: Wed, 7 Mar 2012 15:36:28 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120307143628.GA5078@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Michael MacFaden , mib-doctors@ietf.org References: <20120306152221.GA2081@elstar.local> <20120307121305.GA4853@elstar.local> 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: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB 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, 07 Mar 2012 14:36:32 -0000 Well, it seems RFC 2578 is relatively clear that auxiliary objects (the INDEX objects that are columns of the same conceptual table) are not-accessible except in the situation where there are no other columns, in which case one of the columns becomes read-only. (The other exception is conversion from SMIv1 MIB modules to SMIv2, which does not seem to apply here.) Searching a bit, I found these: - There was a case where the prtAlertIndex of the Printer-MIB was discussed, which was originally defined as not-accessible but used also in a notification. This was not detected until the module was up for revision and then the solution was to make prtAlertIndex read-only with a MIN-ACCESS of accessible-for-notify. We are not facing the same situation here since our tools now spot such errors before modules get published. - The T11-FC-FABRIC-ADDR-MGR-MIB seems to have a construction that is interesting in the sense that they have an accessible-for-notify object t11FamNotifyFabricIndex that they carry in notifications in addition to t11FamLocalSwitchWwn, an object of a table indexed by {fcmInstanceIndex,fcmSwitchIndex,t11FamFabricIndex}. Its hard to understand the logic behind this (I am not a fibre channel guy) because the t11FamNotifyFabricIndex only provides part of the index and hence seems only marginally helpful. - The TRIP-MIB also has something interesting. They have a notification carrying tripOpenMessageError NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode, tripPeerState } and tripPeerState is a column of a table indexed by INDEX { applIndex, tripPeerRemoteAddrInetType, tripPeerRemoteAddr, tripPeerRemotePort } and again this leaves me puzzled as it again looks somewhat incomplete and arbitrary (I am also not a TRIP guy). So we end up with "does it make sense to add additional accessible-for-notify objects to notifications that carry values of auxiliary objects"? I continue to believe it is a bad idea to do this except we write a document updating RFC 2578 that "says experience with RFC 2578's rule to force auxiliary objects to be not-accessible tells us that implementations still today find it too hard to 'unpack' information encoded in the instance identifiers and hence this rule does not apply anymore". The idea to add additional object definitions to work around this rule seems just a bad hack to me. In principle, one can also add additional read-only columns to tables that duplicate auxiliary objects and this would be syntactically be fine wrt. RFC 2578 but still be a violation of the intention of RFC 2578. /js PS: Working on some constrained platforms lately, I guess I am a bit more sensitive to mandatory to implement redundant information (and this is what it boils down to). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From michelle.cotton@icann.org Wed Mar 7 11:37:07 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 C5A4611E8085 for ; Wed, 7 Mar 2012 11:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 q8Ap3Y9tTCTe for ; Wed, 7 Mar 2012 11:37:07 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id EB81911E8072 for ; Wed, 7 Mar 2012 11:37:06 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 7 Mar 2012 11:37:06 -0800 From: Michelle Cotton To: Juergen Schoenwaelder Date: Wed, 7 Mar 2012 11:37:02 -0800 Thread-Topic: [MIB-DOCTORS] Question to the MIB doctors regarding MIB registries at IANA Thread-Index: Acz8ma1+tWCgir8DRf6RzDvMLhYSGg== Message-ID: In-Reply-To: <20120301175445.GA33371@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Mar 2012 08:01:21 -0800 Cc: "mib-doctors@ietf.org" , Pearl Liang Subject: Re: [MIB-DOCTORS] Question to the MIB doctors regarding MIB registries at IANA 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, 07 Mar 2012 19:37:07 -0000 Thank you....I have not seen any other comments from the mib-doctor members... We'll move forward with this work and keep you posted. Thank you, Michelle On 3/1/12 9:54 AM, "Juergen Schoenwaelder" wrote: >On Thu, Mar 01, 2012 at 09:23:05AM -0800, Michelle Cotton wrote: >> Hello Juergen, >>=20 >> Thank you very much for your response. >>=20 >> The XML pages do *not* require JavaScript to be meaningfully rendered. >> We only make accessory use of JavaScript for sorting the tables when you >> click on the sort button next to the column header. >>=20 >> If you could further clarify your concern, we may be able to provide >>more >> information. > >I stand corrected. A plain text browser like w3m will show me the XML >content which is good. I was confused because my firefox shows all the >text contained in the XML elements (and nothing else) while JavaScript >was disabled. Once I enable www.viagenie.ca in my "NoScript" filter, >things render nicely. So I guess I just have an odd browser setup. > >/js > >PS: If you want to followup, we should take this off the list since > this does not seem at all a MIB doctor topic. > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From jcucchiara@mindspring.com Thu Mar 8 08:27: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 BCDB621F86C4 for ; Thu, 8 Mar 2012 08:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, 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 VciVsP2i4rqb for ; Thu, 8 Mar 2012 08:27:34 -0800 (PST) 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 CDDBA21F854E for ; Thu, 8 Mar 2012 08:27:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pMx2k8HHLRytIRPDWIQPltbuI1a5VwHEUE7Ec0PLl2YRkZBRG72q4pXysAUQ9bnk; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1S5gBd-0004Wu-Ga; Thu, 08 Mar 2012 11:27:29 -0500 Message-ID: <3d7401ccfd48$5b266fa0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Juergen Schoenwaelder" , "Romascanu, Dan \(Dan\)" References: <20120306152221.GA2081@elstar.local><20120307121305.GA4853@elstar.local> <20120307143628.GA5078@elstar.local> Date: Thu, 8 Mar 2012 11:27:29 -0500 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654185ea855c1ac9b1c8dc5e2f254ecfab18483c75118a9a15a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:27:34 -0000 Hi Folks, I've looked at some of my old MIB reviews where the accessible-for-notify has been discussed. Here are a few excerps: 1) VRRP-UNIFIED-MIB (now: RFC6527) " *) Concern on the use of accessible-for-notify: it might be a good idea to make these objects read-only, along with a timestamp type of object. Notifications are unreliable and so, could be lost. Also, some customers do not like to enable a lot of notifications and prefer polling. Would you consider making these objects read-only?" OUTCOME: The outcome looking at RFC6527 was to change one of the accessible-for-notify object to read-only and have a Discontinuity object. In another case the accessible-for-notify became a readonly object (which does duplicate information in an index). 2) Another MIB, RFC5643 (OSPFv3-MIB) There are accessible-for-notify objects and my recollection is that so much data would have been saved and timestamped that it was far easier to do the accessible-for-notify objects. Notifications were sent to show specific packet info for errors. Even though these errors were being counted, the MIB authors did not want to save all the information, so it was very temporary and accessible-for-notify was a decent solution. (Also, there was history here because this was in earlier versions of OSPFv2-MIB.) 3) TED-MIB (draft-ietf-ccamp-gmpls-ted-mib-10) The accessible-for-notify was in earlier versions of this MIB, but was changed to include an object from the table, rather than duplicate indices in accessible-for-notify objects. -- Wrt to ADSL-TDIM-MIB The claim that Management Stations have a difficult time parsing the OIDs to isolate indices doesn't seem completely plausible. If an agent can code it, then shouldn't these be able to be decoded by a manager? (maybe I'm just missing something.) At any rate, getting to the original question: I would prefer adding a read-only object which is duplicated information, rather than making an index read-only. (This was done in the VRRP-UNIFIED-MIB, RFC6527) (I agree with Bert, and would have expected to see a read-only index flagged as an error.) Also, I think Juergen raises some good points which my experience also suggestions, that accessible-for-notify objects can usually be rewritten to something maybe more meaningful. However, the use in the OSPFv3-MIB (RFC5643) of accessible-for-notify does seem to be an exception. Thanks, -Joan ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Romascanu, Dan (Dan)" Cc: "Michael MacFaden" ; Sent: Wednesday, March 07, 2012 9:36 AM Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB > Well, > > it seems RFC 2578 is relatively clear that auxiliary objects (the > INDEX objects that are columns of the same conceptual table) are > not-accessible except in the situation where there are no other > columns, in which case one of the columns becomes read-only. (The > other exception is conversion from SMIv1 MIB modules to SMIv2, which > does not seem to apply here.) > > Searching a bit, I found these: > > - There was a case where the prtAlertIndex of the Printer-MIB was > discussed, which was originally defined as not-accessible but used > also in a notification. This was not detected until the module was > up for revision and then the solution was to make prtAlertIndex > read-only with a MIN-ACCESS of accessible-for-notify. We are not > facing the same situation here since our tools now spot such errors > before modules get published. > > - The T11-FC-FABRIC-ADDR-MGR-MIB seems to have a construction that is > interesting in the sense that they have an accessible-for-notify > object t11FamNotifyFabricIndex that they carry in notifications in > addition to t11FamLocalSwitchWwn, an object of a table indexed by > {fcmInstanceIndex,fcmSwitchIndex,t11FamFabricIndex}. Its hard to > understand the logic behind this (I am not a fibre channel guy) > because the t11FamNotifyFabricIndex only provides part of the index > and hence seems only marginally helpful. > > - The TRIP-MIB also has something interesting. They have a > notification carrying > > tripOpenMessageError NOTIFICATION-TYPE > OBJECTS { tripNotifApplIndex, > tripNotifPeerAddrInetType, > tripNotifPeerAddr, > tripNotifPeerErrCode, > tripNotifPeerErrSubcode, > tripPeerState > } > and tripPeerState is a column of a table indexed by > > INDEX { applIndex, > tripPeerRemoteAddrInetType, > tripPeerRemoteAddr, > tripPeerRemotePort } > > and again this leaves me puzzled as it again looks somewhat > incomplete and arbitrary (I am also not a TRIP guy). > > So we end up with "does it make sense to add additional > accessible-for-notify objects to notifications that carry values of > auxiliary objects"? > > I continue to believe it is a bad idea to do this except we write a > document updating RFC 2578 that "says experience with RFC 2578's rule > to force auxiliary objects to be not-accessible tells us that > implementations still today find it too hard to 'unpack' information > encoded in the instance identifiers and hence this rule does not apply > anymore". > > The idea to add additional object definitions to work around this rule > seems just a bad hack to me. In principle, one can also add additional > read-only columns to tables that duplicate auxiliary objects and this > would be syntactically be fine wrt. RFC 2578 but still be a violation > of the intention of RFC 2578. > > /js > > PS: Working on some constrained platforms lately, I guess I am a bit > more sensitive to mandatory to implement redundant information > (and this is what it boils down to). > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From j.schoenwaelder@jacobs-university.de Thu Mar 8 08:56: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 6464521F863B for ; Thu, 8 Mar 2012 08:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 ZIce-Kpu-R3B for ; Thu, 8 Mar 2012 08:56:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B23CD21F8630 for ; Thu, 8 Mar 2012 08:56:31 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7229420D39; Thu, 8 Mar 2012 17:56:30 +0100 (CET) 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 jNkEhZu_iDUV; Thu, 8 Mar 2012 17:56:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B29A620D37; Thu, 8 Mar 2012 17:56:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 336861DA9B9B; Thu, 8 Mar 2012 17:56:28 +0100 (CET) Date: Thu, 8 Mar 2012 17:56:27 +0100 From: Juergen Schoenwaelder To: Joan Cucchiara Message-ID: <20120308165627.GA317@elstar.local> Mail-Followup-To: Joan Cucchiara , "Romascanu, Dan (Dan)" , Michael MacFaden , mib-doctors@ietf.org References: <20120306152221.GA2081@elstar.local> <20120307121305.GA4853@elstar.local> <20120307143628.GA5078@elstar.local> <3d7401ccfd48$5b266fa0$6601a8c0@JoanPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d7401ccfd48$5b266fa0$6601a8c0@JoanPC> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB 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, 08 Mar 2012 16:56:32 -0000 On Thu, Mar 08, 2012 at 11:27:29AM -0500, Joan Cucchiara wrote: > At any rate, getting to the original question: > > I would prefer adding a read-only object which is duplicated > information, rather than making an index read-only. (This was done > in the VRRP-UNIFIED-MIB, RFC6527) > (I agree with Bert, and would have expected to see a read-only > index flagged as an error.) Which object in RFC 6527 shall I look at in order understand what you have in mind? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jcucchiara@mindspring.com Thu Mar 8 09:43:22 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 714D621F86D0 for ; Thu, 8 Mar 2012 09:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, 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 Udcap80IUGc6 for ; Thu, 8 Mar 2012 09:43:21 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 529A821F86C6 for ; Thu, 8 Mar 2012 09:43:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=s9t8GnvLz2oWxqPjWMW2UOhEKxsHDUIqJdxVe4B/kUzUxXuB4khmyn51ZVTbfWip; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1S5hMt-00024G-AS; Thu, 08 Mar 2012 12:43:11 -0500 Message-ID: <3dac01ccfd52$ee1d1250$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Juergen Schoenwaelder" References: <20120306152221.GA2081@elstar.local> <20120307121305.GA4853@elstar.local> <20120307143628.GA5078@elstar.local> <3d7401ccfd48$5b266fa0$6601a8c0@JoanPC> <20120308165627.GA317@elstar.local> Date: Thu, 8 Mar 2012 12:43:10 -0500 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654185ea855c1ac9b1cec9ddc108ac727aa3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: Michael MacFaden , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:43:22 -0000 Juergen, I am incorrect. The DESCRIPTION of the following object: vrrpv3OperationsVirtualMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The virtual MAC address of the virtual router. Although this object can be derived from the 'vrrpv3OperationsVrId' object, it is defined so that it is easily obtainable by a management application and can be included in VRRP-related SNMP notifications." ::= { vrrpv3OperationsEntry 5 } let me to believe this object was in a notification, but I can't find it in a notification, thus, the DESCRIPTION is misleading/wrong. Thanks, -Joan ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Joan Cucchiara" Cc: "Romascanu, Dan (Dan)" ; "Michael MacFaden" ; Sent: Thursday, March 08, 2012 11:56 AM Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB > On Thu, Mar 08, 2012 at 11:27:29AM -0500, Joan Cucchiara wrote: > >> At any rate, getting to the original question: >> >> I would prefer adding a read-only object which is duplicated >> information, rather than making an index read-only. (This was done >> in the VRRP-UNIFIED-MIB, RFC6527) >> (I agree with Bert, and would have expected to see a read-only >> index flagged as an error.) > > Which object in RFC 6527 shall I look at in order understand what > you have in mind? > > /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 Fri Mar 9 01:11: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 6A39921F85F0; Fri, 9 Mar 2012 01:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 J4Lz1fRvtZIl; Fri, 9 Mar 2012 01:11:10 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6307021F85DD; Fri, 9 Mar 2012 01:11:09 -0800 (PST) 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 q2998bfB003723; Fri, 9 Mar 2012 10:08:37 +0100 (CET) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2998a0x013332; Fri, 9 Mar 2012 10:08:36 +0100 (CET) Message-ID: <4F59C894.4070305@cisco.com> Date: Fri, 09 Mar 2012 10:08:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: aaa-doctors@ietf.org, "MIB Doctors (E-mail)" , YANG Doctors , ops-dir@ietf.org, IETF DNS Directorate References: <20120308230610.7157.47891.idtracker@ietfa.amsl.com> In-Reply-To: <20120308230610.7157.47891.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120308230610.7157.47891.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: PRELIMINARY Agenda and Package for the March 15, 2012 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:11:13 -0000 Dear all, Please find below the preliminary agenda of the March 15th IESG telechat. Please send your questions, comments and concerns before March 14th COB. Thanks and Regards, Dan and Benoit. -------- Original Message -------- AGENDA PACKAGE FOR 2012-03-15 IESG TELECHAT 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-core-link-format-11 CoRE Link Format (Proposed Standard) Note: Carsten Bormann (cabo@tzi.org) is the document shepherd. Token: Peter Saint-Andre o draft-ietf-marf-dkim-reporting-12 Extensions to DKIM for Failure Reporting (Proposed Standard) Token: Pete Resnick o draft-ietf-marf-spf-reporting-08 SPF Authentication Failure Reporting using the Abuse Report Format (Proposed Standard) Token: Pete Resnick o draft-ietf-appsawg-xdash-03 Deprecating Use of the "X-" Prefix in Application Protocols (Best Current Practice) Token: Pete Resnick o draft-ietf-adslmib-gbond-mib-09 xDSL multi-pair bonding (G.Bond) MIB (Proposed Standard) Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-adslmib-gbond-atm-mib-05 ATM-Based xDSL Bonded Interfaces MIB (Proposed Standard) Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-adslmib-gbond-eth-mib-05 Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB (Proposed Standard) Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-adslmib-gbond-tdim-mib-07 xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB (Proposed Standard) Note: Menachem Dodge (Menachem.Dodge@ecitele.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-tsvwg-source-quench-06 Deprecation of ICMP Source Quench messages (Proposed Standard) Note: Gorry Fairgurst (gorry@erg.abdn.ac.uk) is the document shepherd. Token: Wesley Eddy o draft-ietf-pwe3-packet-pw-03 Packet Pseudowire Encapsulation over an MPLS PSN (Proposed Standard) Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-ipfix-rfc5815bis-01 Definitions of Managed Objects for IP Flow Information Export (Proposed Standard) Note: Juergen Quittek (Quittek@neclab.eu) is the document shepherd. Token: Dan Romascanu o draft-ietf-mediactrl-6231-iana-00 IANA Registry for MEDIACTRL Interactive Voice Response Control Package (Proposed Standard) Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-pcn-3-in-1-encoding-08 Encoding 3 PCN-States in the IP header using a single DSCP (Proposed Standard) Note: Scott Bradner (sob@harvard.edu) is the document shephed. Token: David Harrington 2.2 Individual Submissions 2.2.1 New Items o draft-mcgrew-tls-aes-ccm-03 AES-CCM Cipher Suites for TLS (Proposed Standard) Note: Joe Salowey<jsalowey@cisco.com> is the Document Shepherd. Token: Sean Turner 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-pcn-cl-edge-behaviour-12 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation (Informational) Note: Steven Blake (slblake@petri-meat.com> is the document shepherd) Token: David Harrington o draft-ietf-pcn-sm-edge-behaviour-09 PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation (Informational) Note: Steven Blake (slblake@petri-meat.com) is the document shepherd. Token: David Harrington o draft-ietf-decade-problem-statement-05 DECoupled Application Data Enroute (DECADE) Problem Statement (Informational) Note: Richard Woundy (richard_woundy@cable.comcast.com) is the document shepherd. Token: David Harrington o draft-ietf-opsawg-management-stds-05 An Overview of the IETF Network Management Standards (Informational) Note: Christopher Liljenstolpe is the Document Shepherd. Token: Dan Romascanu 3.1.2 Returning Items o draft-ietf-multimob-igmp-mld-tuning-05 Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks (Informational) Note: Behcet Sarikaya (sarikaya2012@gmail.com) is the document shepherd.Note: document is on the telechat 5 days before the LC ends. I'd like to complete this doc while I'm on the IESG, and handle additional last call comments (if any) in Paris IESG meeting. We'll hand it off to Brian if there's anything substantial. Token: Jari Arkko 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-harkins-ipsecme-spsk-auth-06 Secure PSK Authentication for IKE (Experimental) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner o draft-shin-augmented-pake-13 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 (Experimental) Note: Paul Hoffman is the document shepherd (paul.hoffman@vpnc.org). Token: Sean Turner o draft-kuegler-ipsecme-pace-ikev2-08 Password Authenticated Connection Establishment with IKEv2 (Experimental) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner o draft-reschke-http-status-308-05 The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect) (Experimental) Note: Cyrus Daboo (cyrus@daboo.name) is the document shepherd. Token: Peter Saint-Andre 3.2.2 Returning Items o draft-garcia-shim6-applicability-03 Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6) (Informational) Token: Jari Arkko 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-tsou-softwire-gwinit-6rd-06 "Gateway-Initiated" 6rd (Informational) Note: The IESG has concluded that this work is related to IETF work donein the softwire WG, but this relationship does not prevent publishing. Token: Ralph Droms 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o INtermediary-safe SIP session ID (insipid) Token: Gonzalo Camarillo 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Locator/ID Separation Protocol (lisp) Token: Jari Arkko o Hypertext Transfer Protocol Bis (httpbis) Token: Peter Saint-Andre From bclaise@cisco.com Wed Mar 21 03:41: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 1456E21F8606 for ; Wed, 21 Mar 2012 03:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_20=-0.74] 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 c2xiGqpW1HYP for ; Wed, 21 Mar 2012 03:41:17 -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 5006E21F85F8 for ; Wed, 21 Mar 2012 03:41:17 -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 q2LAdTH3026892 for ; Wed, 21 Mar 2012 11:39:29 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2LAdTB0015224 for ; Wed, 21 Mar 2012 11:39:29 +0100 (CET) Message-ID: <4F69AFE1.8020400@cisco.com> Date: Wed, 21 Mar 2012 11:39:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 10:41:18 -0000 Dear MIB doctors, Do you know if there is already a protocol number TC defined? Note: browsed through RFC4181 and SNMPv2-TC, without success. More generic question: how can we get a list of possible TC's? By searching in an NMS, loaded with all possible MIB modules? Regards, Benoit. From bertietf@bwijnen.net Wed Mar 21 03:55:11 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 C3FE821F8526 for ; Wed, 21 Mar 2012 03:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 enJFvhMjlplv for ; Wed, 21 Mar 2012 03:55:11 -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 2F7B221F84E4 for ; Wed, 21 Mar 2012 03:55:11 -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 1SAJC9-0001wd-0h; Wed, 21 Mar 2012 11:55:10 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SAJC8-0006ZG-T3; Wed, 21 Mar 2012 11:55:08 +0100 Message-ID: <4F69B38C.5050002@bwijnen.net> Date: Wed, 21 Mar 2012 11:55:08 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Benoit Claise References: <4F69AFE1.8020400@cisco.com> In-Reply-To: <4F69AFE1.8020400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 86ab03e524994f79ca2c75a176445dd4a61322545cf4a13f13d674e5be6f6092 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 10:55:11 -0000 Are you aware of http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs Bert On 3/21/12 11:39 AM, Benoit Claise wrote: > Dear MIB doctors, > > Do you know if there is already a protocol number TC defined? > Note: browsed through RFC4181 and SNMPv2-TC, without success. > > More generic question: how can we get a list of possible TC's? By searching in an NMS, loaded with all possible MIB modules? > > Regards, Benoit. > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bclaise@cisco.com Wed Mar 21 04:41:24 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F286B21F85D9 for ; Wed, 21 Mar 2012 04:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 QYjMkz7KmwVR for ; Wed, 21 Mar 2012 04:41:23 -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 B24E721F85EA for ; Wed, 21 Mar 2012 04:41:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2LBTrOh003046; Wed, 21 Mar 2012 12:29:53 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2LBTqXs028054; Wed, 21 Mar 2012 12:29:53 +0100 (CET) Message-ID: <4F69BBB0.40003@cisco.com> Date: Wed, 21 Mar 2012 12:29:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <4F69AFE1.8020400@cisco.com> <4F69B38C.5050002@bwijnen.net> In-Reply-To: <4F69B38C.5050002@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 11:41:24 -0000 Hi Bert, So I learned something today ;-) I don't see what I need in http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs. I even double checked RFC4001. So I'll conclude protocol number TC is not present. Thanks. Regards, Benoit. > Are you aware of > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs > Bert > > On 3/21/12 11:39 AM, Benoit Claise wrote: >> Dear MIB doctors, >> >> Do you know if there is already a protocol number TC defined? >> Note: browsed through RFC4181 and SNMPv2-TC, without success. >> >> More generic question: how can we get a list of possible TC's? By >> searching in an NMS, loaded with all possible MIB modules? >> >> Regards, Benoit. >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > From bertietf@bwijnen.net Wed Mar 21 04:46:42 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 CAEEB21F8616 for ; Wed, 21 Mar 2012 04:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.793 X-Spam-Level: X-Spam-Status: No, score=-99.793 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, 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 UXJDG76CJFwZ for ; Wed, 21 Mar 2012 04:46:42 -0700 (PDT) Received: from relay57.tele2.vuurwerk.nl (relay57.tele2.vuurwerk.nl [62.250.3.57]) by ietfa.amsl.com (Postfix) with ESMTP id 423E421F8617 for ; Wed, 21 Mar 2012 04:46:42 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1SAK00-000392-To; Wed, 21 Mar 2012 12:46:41 +0100 Message-ID: <7C20155D115E4D99B84913730B20E233@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Benoit Claise" References: <4F69AFE1.8020400@cisco.com> <4F69B38C.5050002@bwijnen.net> <4F69BBB0.40003@cisco.com> In-Reply-To: <4F69BBB0.40003@cisco.com> Date: Wed, 21 Mar 2012 12:46:19 +0100 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] protocol number TC? 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, 21 Mar 2012 11:46:42 -0000 I am not claiming it does not exist, but you are correct that we have not defined/listed it as one of our common TCs. We may need/want to check that every so often. I am not sure when we last did it (or even who checked it at that time). I used to spend some time on it as AD when I was AD. Dan did you check them once in a while? Anyone else (Juergen?)? Bert ----- Original Message ----- From: "Benoit Claise" To: "Bert Wijnen (IETF)" Cc: "MIB Doctors (E-mail)" Sent: Wednesday, March 21, 2012 12:29 PM Subject: Re: [MIB-DOCTORS] protocol number TC? > Hi Bert, > > So I learned something today ;-) > I don't see what I need in > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs. I even > double checked RFC4001. > So I'll conclude protocol number TC is not present. > > Thanks. > > Regards, Benoit. > >> Are you aware of >> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs >> Bert >> >> On 3/21/12 11:39 AM, Benoit Claise wrote: >>> Dear MIB doctors, >>> >>> Do you know if there is already a protocol number TC defined? >>> Note: browsed through RFC4181 and SNMPv2-TC, without success. >>> >>> More generic question: how can we get a list of possible TC's? By >>> searching in an NMS, loaded with all possible MIB modules? >>> >>> Regards, Benoit. >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> >> > From j.schoenwaelder@jacobs-university.de Wed Mar 21 05:55: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 E827821F859F for ; Wed, 21 Mar 2012 05:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 9qiGcywb6-YS for ; Wed, 21 Mar 2012 05:55:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E984D21F8597 for ; Wed, 21 Mar 2012 05:55:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA9B920D0A; Wed, 21 Mar 2012 13:55:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BXeKHM6rRGVc; Wed, 21 Mar 2012 13:55:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86E1220CFA; Wed, 21 Mar 2012 13:55:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D875A1E152DA; Wed, 21 Mar 2012 13:55:27 +0100 (CET) Date: Wed, 21 Mar 2012 13:55:26 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120321125526.GA1342@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" References: <4F69AFE1.8020400@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F69AFE1.8020400@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 12:55:31 -0000 On Wed, Mar 21, 2012 at 11:39:29AM +0100, Benoit Claise wrote: > Dear MIB doctors, > > Do you know if there is already a protocol number TC defined? > Note: browsed through RFC4181 and SNMPv2-TC, without success. If you mean a MIB version of http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml then I think this does not exist. Note that such a TC would need to be controlled by IANA. > More generic question: how can we get a list of possible TC's? By > searching in an NMS, loaded with all possible MIB modules? Sort of. I am trying to track all IETF/IANA MIB modules in the libsmi source code repository and this is what I use to find things. /js -- 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 Wed Mar 21 06:10: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 38F3121F8649 for ; Wed, 21 Mar 2012 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 NKMrO5W-goj4 for ; Wed, 21 Mar 2012 06:10:27 -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 330E121F85CF for ; Wed, 21 Mar 2012 06:10:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoQAK/SaU/GmAcF/2dsb2JhbABDsAaHAYEHggkBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQEKBgwLAQYBJh8JCAEBBAESCBqHaAuiMJQ/imGFPWMEm26KGIJogVs X-IronPort-AV: E=Sophos;i="4.73,624,1325480400"; d="scan'208";a="298184991" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Mar 2012 09:10:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Mar 2012 09:02:06 -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, 21 Mar 2012 14:10:22 +0100 Message-ID: In-Reply-To: <7C20155D115E4D99B84913730B20E233@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] protocol number TC? Thread-Index: Ac0HWEzyk0hsr0onT7SA4KFQz7B4zgAC1NRA References: <4F69AFE1.8020400@cisco.com> <4F69B38C.5050002@bwijnen.net><4F69BBB0.40003@cisco.com> <7C20155D115E4D99B84913730B20E233@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Benoit Claise" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 13:10:28 -0000 We updated the page two or three times during my tenure, last time around mid-2010.=20 Maybe this is a good time for the MIB Doctors to discuss if anything needs to be added to or taken off from the list of the most commonly used TCs. Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Wednesday, March 21, 2012 1:46 PM > To: Benoit Claise > Cc: MIB Doctors (E-mail) > Subject: Re: [MIB-DOCTORS] protocol number TC? >=20 > I am not claiming it does not exist, >=20 > but you are correct that we have not defined/listed it as > one of our common TCs. We may need/want to check that > every so often. I am not sure when we last did it (or even who > checked it at that time). I used to spend some time on it > as AD when I was AD. Dan did you check them once in > a while? Anyone else (Juergen?)? >=20 > Bert > ----- Original Message ----- > From: "Benoit Claise" > To: "Bert Wijnen (IETF)" > Cc: "MIB Doctors (E-mail)" > Sent: Wednesday, March 21, 2012 12:29 PM > Subject: Re: [MIB-DOCTORS] protocol number TC? >=20 >=20 > > Hi Bert, > > > > So I learned something today ;-) > > I don't see what I need in > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs. I even > > double checked RFC4001. > > So I'll conclude protocol number TC is not present. > > > > Thanks. > > > > Regards, Benoit. > > > >> Are you aware of > >> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs > >> Bert > >> > >> On 3/21/12 11:39 AM, Benoit Claise wrote: > >>> Dear MIB doctors, > >>> > >>> Do you know if there is already a protocol number TC defined? > >>> Note: browsed through RFC4181 and SNMPv2-TC, without success. > >>> > >>> More generic question: how can we get a list of possible TC's? By > >>> searching in an NMS, loaded with all possible MIB modules? > >>> > >>> 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 dbharrington@comcast.net Wed Mar 21 08:45: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 D7E9721F865B for ; Wed, 21 Mar 2012 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.772, 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 gsho4Qd8Vvnv for ; Wed, 21 Mar 2012 08:45:51 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id F13E521F85FC for ; Wed, 21 Mar 2012 08:45:50 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id oFbm1i0030QuhwU56FlrXp; Wed, 21 Mar 2012 15:45:51 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta02.westchester.pa.mail.comcast.net with comcast id oFlq1i0033Ecudz3NFlqik; Wed, 21 Mar 2012 15:45:51 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 21 Mar 2012 11:45:47 -0400 From: David Harrington To: Juergen Schoenwaelder , Benoit Claise Message-ID: Thread-Topic: [MIB-DOCTORS] protocol number TC? In-Reply-To: <20120321125526.GA1342@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 15:45:52 -0000 Maybe it is time to have a registry created at http://www.iana.org/assignments/smi-numbers for Tcs? (I'm not sure smi-numbers is the right place, since Tcs don't have numbers.) -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 3/21/12 8:55 AM, "Juergen Schoenwaelder" wrote: >On Wed, Mar 21, 2012 at 11:39:29AM +0100, Benoit Claise wrote: >> Dear MIB doctors, >> >> Do you know if there is already a protocol number TC defined? >> Note: browsed through RFC4181 and SNMPv2-TC, without success. > >If you mean a MIB version of > >http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml > >then I think this does not exist. Note that such a TC would need to be >controlled by IANA. > >> More generic question: how can we get a list of possible TC's? By >> searching in an NMS, loaded with all possible MIB modules? > >Sort of. I am trying to track all IETF/IANA MIB modules in the libsmi >source code repository and this is what I use to find things. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From andy@netconfcentral.org Wed Mar 21 08:59:22 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 723B521F85E5 for ; Wed, 21 Mar 2012 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 ywQ0b+0MF3fO for ; Wed, 21 Mar 2012 08:59:21 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64B21F85CF for ; Wed, 21 Mar 2012 08:59:21 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2LFxKAg028727 for ; Wed, 21 Mar 2012 11:59:20 -0400 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:34990] helo=[192.168.0.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0E/C6-22057-8DAF96F4; Wed, 21 Mar 2012 11:59:20 -0400 Message-ID: <4F69FADE.3000208@netconfcentral.org> Date: Wed, 21 Mar 2012 08:59:26 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 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 Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 15:59:22 -0000 On 03/21/2012 08:45 AM, David Harrington wrote: > Maybe it is time to have a registry created at > http://www.iana.org/assignments/smi-numbers for Tcs? > (I'm not sure smi-numbers is the right place, since Tcs don't have > numbers.) > Example: http://www.netconfcentral.org/typedeflist Too bad we can't just have tools to do this for us. I plan to work on that -- I just have 27 other plans as well ;-) We've been talking about running over Django on tools.ietf.org, but the ncorg code is Turbogears right now. Example: http://www.netconfcentral.org/typedeflist rsync --> rfcstrip --> smidump -f yang --> yangdump -format=sqldb --> ncorg-db WSGI --> Pylons --> Turbogears --> SqlAlchemy --> ncorg-db Andy From bclaise@cisco.com Wed Mar 21 09: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 974FF21F8629 for ; Wed, 21 Mar 2012 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 EhyxWDeyHsV3 for ; Wed, 21 Mar 2012 09:33: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 AC8B521F8623 for ; Wed, 21 Mar 2012 09:33: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 q2LGWxxd008749; Wed, 21 Mar 2012 17:32:59 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2LGWwAo020499; Wed, 21 Mar 2012 17:32:58 +0100 (CET) Message-ID: <4F6A02B9.8040201@cisco.com> Date: Wed, 21 Mar 2012 17:32:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 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 Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 16:33:05 -0000 Hi Dave, Is there any light way to do this, or do we need a RFC with a specific IANA Considerations section? Regards, Benoit. > Maybe it is time to have a registry created at > http://www.iana.org/assignments/smi-numbers for Tcs? > (I'm not sure smi-numbers is the right place, since Tcs don't have > numbers.) > From dbharrington@comcast.net Wed Mar 21 10:12: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 16F9C21E8049 for ; Wed, 21 Mar 2012 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.02 X-Spam-Level: X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 V0ejWgpMZFbt for ; Wed, 21 Mar 2012 10:12:04 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1A21E801A for ; Wed, 21 Mar 2012 10:12:04 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id oHBt1i00E0bG4ec5AHC4PA; Wed, 21 Mar 2012 17:12:04 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta03.westchester.pa.mail.comcast.net with comcast id oHBi1i00v3Ecudz3PHBunH; Wed, 21 Mar 2012 17:12:04 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 21 Mar 2012 13:11:40 -0400 From: David Harrington To: Benoit Claise Message-ID: Thread-Topic: [MIB-DOCTORS] protocol number TC? In-Reply-To: <4F6A02B9.8040201@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 17:12:05 -0000 I believe you will need an RFC with a specific IANA section. You also need to discuss how this registry will be maintained, per RFC5226. For example, What level of review is required for adding a new TC to the registry? You may want to require IESG Review, or just an expert's review. Can enterprise MIBs define Tcs and have them added to the registry? And so on. I don't think the process would need to be heavy weight, if you design it correctly. -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 3/21/12 12:32 PM, "Benoit Claise" wrote: >Hi Dave, > >Is there any light way to do this, or do we need a RFC with a specific >IANA Considerations section? > >Regards, Benoit. >> Maybe it is time to have a registry created at >> http://www.iana.org/assignments/smi-numbers for Tcs? >> (I'm not sure smi-numbers is the right place, since Tcs don't have >> numbers.) >> > From j.schoenwaelder@jacobs-university.de Wed Mar 21 11:19: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 8059921F8501 for ; Wed, 21 Mar 2012 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Dw3l-anQBWLH for ; Wed, 21 Mar 2012 11:19:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36921F8503 for ; Wed, 21 Mar 2012 11:19:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5484A20D0A; Wed, 21 Mar 2012 19:19:02 +0100 (CET) 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 CwPbD_kRZR9r; Wed, 21 Mar 2012 19:19:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91C2C20CCD; Wed, 21 Mar 2012 19:19:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A70261E162CF; Wed, 21 Mar 2012 19:19:00 +0100 (CET) Date: Wed, 21 Mar 2012 19:19:00 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20120321181900.GA1876@elstar.local> Mail-Followup-To: David Harrington , Benoit Claise , MIB Doctors References: <4F6A02B9.8040201@cisco.com> 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 Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 18:19:04 -0000 On Wed, Mar 21, 2012 at 01:11:40PM -0400, David Harrington wrote: > I believe you will need an RFC with a specific IANA section. > You also need to discuss how this registry will be maintained, per RFC5226. > For example, What level of review is required for adding a new TC to the > registry? > You may want to require IESG Review, or just an expert's review. > Can enterprise MIBs define Tcs and have them added to the registry? > And so on. Sounds like the pain is bigger than the benefit. It is fairly easy to have smidump produce whatever is wanted and to simply built a tool rather than a process. Note that there is no technical reason to register TCs with IANA since we do not have ensure unique names or such things. Hence, I assume a simple tool likely gets the job done faster and more flexible. /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 Wed Mar 21 14:57: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 60B8621E801E for ; Wed, 21 Mar 2012 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 sG+edNTaCJEL for ; Wed, 21 Mar 2012 14:57:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17F21F85CC for ; Wed, 21 Mar 2012 14:57:27 -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 q2LLvAdp009215; Wed, 21 Mar 2012 22:57:10 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2LLv9Zp020802; Wed, 21 Mar 2012 22:57:09 +0100 (CET) Message-ID: <4F6A4EB4.1050208@cisco.com> Date: Wed, 21 Mar 2012 22:57:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> In-Reply-To: <20120321181900.GA1876@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 21:57:28 -0000 On 21/03/2012 19:19, Juergen Schoenwaelder wrote: > On Wed, Mar 21, 2012 at 01:11:40PM -0400, David Harrington wrote: >> I believe you will need an RFC with a specific IANA section. >> You also need to discuss how this registry will be maintained, per RFC5226. >> For example, What level of review is required for adding a new TC to the >> registry? >> You may want to require IESG Review, or just an expert's review. >> Can enterprise MIBs define Tcs and have them added to the registry? >> And so on. > Sounds like the pain is bigger than the benefit. It is fairly easy to > have smidump produce whatever is wanted and to simply built a tool > rather than a process. Note that there is no technical reason to > register TCs with IANA since we do not have ensure unique names or > such things. Hence, I assume a simple tool likely gets the job done > faster and more flexible. I concur. Regards, Benoit. > > /js > From dbharrington@comcast.net Wed Mar 21 15:16: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 D4B8921E8142 for ; Wed, 21 Mar 2012 15:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.463, 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 DEam4gAQ4Yau for ; Wed, 21 Mar 2012 15:16:17 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4037021E8015 for ; Wed, 21 Mar 2012 15:16:17 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id oNFx1i00616LCl05ANGHaw; Wed, 21 Mar 2012 22:16:17 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta06.westchester.pa.mail.comcast.net with comcast id oNGE1i01W3Ecudz3SNGHmd; Wed, 21 Mar 2012 22:16:17 +0000 From: "David Harrington" To: "'Benoit Claise'" , "'MIB Doctors'" References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> In-Reply-To: <4F6A4EB4.1050208@cisco.com> Date: Wed, 21 Mar 2012 18:16:12 -0400 Message-ID: <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: Ac0HrZq2i0hrtanqRzCdzGmMM2L3KgAAkvPQ Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 22:16:18 -0000 I would say the main reason would be to have one central plae to lookup TCs. The registry would have the RFC# that defines the TC. Unless the tool is available and maintained by the tools team, or is available as a web service, not everybody is likely to have it available. Juergen, Are you offering to provide a web service? Would you consider putting this under tools team control and having it hosted at ietf? David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, March 21, 2012 5:57 PM To: David Harrington; MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? On 21/03/2012 19:19, Juergen Schoenwaelder wrote: > On Wed, Mar 21, 2012 at 01:11:40PM -0400, David Harrington wrote: >> I believe you will need an RFC with a specific IANA section. >> You also need to discuss how this registry will be maintained, per RFC5226. >> For example, What level of review is required for adding a new TC to the >> registry? >> You may want to require IESG Review, or just an expert's review. >> Can enterprise MIBs define Tcs and have them added to the registry? >> And so on. > Sounds like the pain is bigger than the benefit. It is fairly easy to > have smidump produce whatever is wanted and to simply built a tool > rather than a process. Note that there is no technical reason to > register TCs with IANA since we do not have ensure unique names or > such things. Hence, I assume a simple tool likely gets the job done > faster and more flexible. I concur. Regards, Benoit. > > /js > From andy@netconfcentral.org Wed Mar 21 15:35: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 B00A421E805A for ; Wed, 21 Mar 2012 15:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Wtb-RQ5BN6Mk for ; Wed, 21 Mar 2012 15:35:44 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0E89621E80DE for ; Wed, 21 Mar 2012 15:35:43 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2LMZhgF003068 for ; Wed, 21 Mar 2012 18:35:43 -0400 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36523] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 34/B8-14799-EB75A6F4; Wed, 21 Mar 2012 18:35:43 -0400 Message-ID: <4F6A57C5.7010809@netconfcentral.org> Date: Wed, 21 Mar 2012 15:35:49 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Harrington References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> In-Reply-To: <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'MIB Doctors' Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 21 Mar 2012 22:35:44 -0000 On 03/21/2012 03:16 PM, David Harrington wrote: > I would say the main reason would be to have one central plae to lookup TCs. > The registry would have the RFC# that defines the TC. > > Unless the tool is available and maintained by the tools team, or is > available as a web service, not everybody is likely to have it available. > > Juergen, Are you offering to provide a web service? > Would you consider putting this under tools team control and having it > hosted at ietf? > Has somebody volunteered to find and document all the standard TCs? Has somebody else volunteered to review it to see if it's right? Has somebody volunteered to update the registry every time a new TC is published? This seems like a lot of work, but if you have the resources, and want something administrative to do, a registry of TCs fits the bill. Andy > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Wednesday, March 21, 2012 5:57 PM > To: David Harrington; MIB Doctors > Subject: Re: [MIB-DOCTORS] protocol number TC? > > On 21/03/2012 19:19, Juergen Schoenwaelder wrote: >> On Wed, Mar 21, 2012 at 01:11:40PM -0400, David Harrington wrote: >>> I believe you will need an RFC with a specific IANA section. >>> You also need to discuss how this registry will be maintained, per > RFC5226. >>> For example, What level of review is required for adding a new TC to the >>> registry? >>> You may want to require IESG Review, or just an expert's review. >>> Can enterprise MIBs define Tcs and have them added to the registry? >>> And so on. >> Sounds like the pain is bigger than the benefit. It is fairly easy to >> have smidump produce whatever is wanted and to simply built a tool >> rather than a process. Note that there is no technical reason to >> register TCs with IANA since we do not have ensure unique names or >> such things. Hence, I assume a simple tool likely gets the job done >> faster and more flexible. > I concur. > > Regards, Benoit. >> >> /js >> > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > From dromasca@avaya.com Thu Mar 22 01:56:12 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 CF0FB21F85FB for ; Thu, 22 Mar 2012 01:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 vDVZstHrRPN3 for ; Thu, 22 Mar 2012 01:56:12 -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 EB9CF21F85F6 for ; Thu, 22 Mar 2012 01:56:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkNAKHoak/GmAcF/2dsb2JhbABBA7AkhnuBB4IJAQEBAQMBAQEPHgoxAwsMBAIBCA0EBAEBAQoGDAsBBgEmHwkIAQEEARIIGodoC5wLnB0EjT2CRGMEm26KGYJo X-IronPort-AV: E=Sophos;i="4.73,629,1325480400"; d="scan'208";a="298346882" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Mar 2012 04:56:10 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Mar 2012 04:47:47 -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: Thu, 22 Mar 2012 09:56:07 +0100 Message-ID: In-Reply-To: <4F6A57C5.7010809@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] protocol number TC? Thread-Index: Ac0Hsvb4M5qgy/3nRFeopLMUru9MMQAVijNg References: <4F6A02B9.8040201@cisco.com><20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com><835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "David Harrington" Cc: MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 08:56:12 -0000 I think that this is more or less what we intended to do with the creation of a Web page for TCs. A place where we would store the TCs, configuration control by allowing access only to the ADs, maybe to the MIB doctors, review by the MIB doctors, without the overhead of writing an RFC and administrating by IANA. A lose an informal process supported by the MIB doctors team. Is there any reason for this not to work? Or is it not enough?=20 Dan =20 > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, March 22, 2012 12:36 AM > To: David Harrington > Cc: 'MIB Doctors' > Subject: Re: [MIB-DOCTORS] protocol number TC? >=20 > On 03/21/2012 03:16 PM, David Harrington wrote: > > I would say the main reason would be to have one central plae to > lookup TCs. > > The registry would have the RFC# that defines the TC. > > > > Unless the tool is available and maintained by the tools team, or is > > available as a web service, not everybody is likely to have it > available. > > > > Juergen, Are you offering to provide a web service? > > Would you consider putting this under tools team control and having > it > > hosted at ietf? > > >=20 > Has somebody volunteered to find and document all the standard TCs? > Has somebody else volunteered to review it to see if it's right? > Has somebody volunteered to update the registry every time a new TC is > published? >=20 > This seems like a lot of work, but if you have the resources, and want > something administrative to do, a registry of TCs fits the bill. >=20 >=20 >=20 > Andy >=20 >=20 > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Wednesday, March 21, 2012 5:57 PM > > To: David Harrington; MIB Doctors > > Subject: Re: [MIB-DOCTORS] protocol number TC? > > > > On 21/03/2012 19:19, Juergen Schoenwaelder wrote: > >> On Wed, Mar 21, 2012 at 01:11:40PM -0400, David Harrington wrote: > >>> I believe you will need an RFC with a specific IANA section. > >>> You also need to discuss how this registry will be maintained, per > > RFC5226. > >>> For example, What level of review is required for adding a new TC > to the > >>> registry? > >>> You may want to require IESG Review, or just an expert's review. > >>> Can enterprise MIBs define Tcs and have them added to the registry? > >>> And so on. > >> Sounds like the pain is bigger than the benefit. It is fairly easy > to > >> have smidump produce whatever is wanted and to simply built a tool > >> rather than a process. Note that there is no technical reason to > >> register TCs with IANA since we do not have ensure unique names or > >> such things. Hence, I assume a simple tool likely gets the job done > >> faster and more flexible. > > I concur. > > > > Regards, Benoit. > >> > >> /js > >> > > > > > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From j.schoenwaelder@jacobs-university.de Thu Mar 22 02:24:09 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 9961621F8552 for ; Thu, 22 Mar 2012 02:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.036, 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 p+Oa3l4uPdha for ; Thu, 22 Mar 2012 02:24:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8521F8550 for ; Thu, 22 Mar 2012 02:24:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC27120CD2; Thu, 22 Mar 2012 10:24:07 +0100 (CET) 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 v5Uo0HvRR9QT; Thu, 22 Mar 2012 10:24:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10A3520CC7; Thu, 22 Mar 2012 10:24:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0FA5B1E173F2; Thu, 22 Mar 2012 10:24:04 +0100 (CET) Date: Thu, 22 Mar 2012 10:24:04 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120322092404.GB18297@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> 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 Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 09:24:09 -0000 On Thu, Mar 22, 2012 at 09:56:07AM +0100, Romascanu, Dan (Dan) wrote: > I think that this is more or less what we intended to do with the > creation of a Web page for TCs. A place where we would store the TCs, > configuration control by allowing access only to the ADs, maybe to the > MIB doctors, review by the MIB doctors, without the overhead of writing > an RFC and administrating by IANA. A lose an informal process supported > by the MIB doctors team. Is there any reason for this not to work? Or is > it not enough? Perhaps "Generic and Common Textual Conventions" makes it unclear what to add/remove. But anyway, here is the list of IETF and IANA TCs I just extracted using something like smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}' just in case someone wants to check whether something should be added to the web page. With a bit more effort, I can probably produce something more useful. That said, the web page tries to add value by listing "Generic and Common Textual Conventions". At the same time, this makes the web page useless for searching for TCs since it by definition is incomplete. /js PS: I note that even after years of discussions (that was still when Bert was AD), we still have no central place where one can pickup all extracted MIB modules. This would really be the first step for any automated solution but since this did not materialize for years, perhaps it is not important enough. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 22 02:43:07 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 38EBE21F8646 for ; Thu, 22 Mar 2012 02:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.513 X-Spam-Level: X-Spam-Status: No, score=-100.513 tagged_above=-999 required=5 tests=[AWL=-2.664, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_ASCII_ART_SPACINGc=0.833, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, UPPERCASE_50_75=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 OY5HTJLcS6rF for ; Thu, 22 Mar 2012 02:43:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A3C2221F865E for ; Thu, 22 Mar 2012 02:43:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F359720CE9; Thu, 22 Mar 2012 10:43:03 +0100 (CET) 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 E4t9SJJKqxkG; Thu, 22 Mar 2012 10:43:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62CB920CD9; Thu, 22 Mar 2012 10:43:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6BAF61E17797; Thu, 22 Mar 2012 10:43:03 +0100 (CET) Date: Thu, 22 Mar 2012 10:43:03 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors Message-ID: <20120322094303.GD18297@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline In-Reply-To: <20120322092404.GB18297@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 09:43:07 -0000 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 22, 2012 at 10:24:04AM +0100, Juergen Schoenwaelder wrote: > On Thu, Mar 22, 2012 at 09:56:07AM +0100, Romascanu, Dan (Dan) wrote: > > I think that this is more or less what we intended to do with the > > creation of a Web page for TCs. A place where we would store the TCs, > > configuration control by allowing access only to the ADs, maybe to the > > MIB doctors, review by the MIB doctors, without the overhead of writing > > an RFC and administrating by IANA. A lose an informal process supported > > by the MIB doctors team. Is there any reason for this not to work? Or is > > it not enough? > > Perhaps "Generic and Common Textual Conventions" makes it unclear what > to add/remove. But anyway, here is the list of IETF and IANA TCs I > just extracted using something like > > smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}' > > just in case someone wants to check whether something should be added > to the web page. With a bit more effort, I can probably produce > something more useful. > > That said, the web page tries to add value by listing "Generic and > Common Textual Conventions". At the same time, this makes the web page > useless for searching for TCs since it by definition is incomplete. > > /js > > PS: I note that even after years of discussions (that was still when > Bert was AD), we still have no central place where one can pickup > all extracted MIB modules. This would really be the first step for > any automated solution but since this did not materialize for > years, perhaps it is not important enough. Now with the attachements... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ietf-tcs.txt" DataCollectionSubtree ACCOUNTING-CONTROL-MIB DataCollectionList ACCOUNTING-CONTROL-MIB FileIndex ACCOUNTING-CONTROL-MIB AdslTransmissionModeType ADSL-LINE-EXT-MIB AdslLineCodingType ADSL-TC-MIB AdslPerfCurrDayCount ADSL-TC-MIB AdslPerfPrevDayCount ADSL-TC-MIB AdslPerfTimeElapsed ADSL-TC-MIB Adsl2Unit ADSL2-LINE-TC-MIB Adsl2Direction ADSL2-LINE-TC-MIB Adsl2TransmissionModeType ADSL2-LINE-TC-MIB Adsl2RaMode ADSL2-LINE-TC-MIB Adsl2InitResult ADSL2-LINE-TC-MIB Adsl2OperationModes ADSL2-LINE-TC-MIB Adsl2PowerMngState ADSL2-LINE-TC-MIB Adsl2ConfPmsForce ADSL2-LINE-TC-MIB Adsl2LConfProfPmMode ADSL2-LINE-TC-MIB Adsl2LineLdsf ADSL2-LINE-TC-MIB Adsl2LdsfResult ADSL2-LINE-TC-MIB Adsl2SymbolProtection ADSL2-LINE-TC-MIB Adsl2MaxBer ADSL2-LINE-TC-MIB Adsl2ScMaskDs ADSL2-LINE-TC-MIB Adsl2ScMaskUs ADSL2-LINE-TC-MIB Adsl2RfiDs ADSL2-LINE-TC-MIB Adsl2PsdMaskDs ADSL2-LINE-TC-MIB Adsl2PsdMaskUs ADSL2-LINE-TC-MIB Adsl2Tssi ADSL2-LINE-TC-MIB Adsl2LastTransmittedState ADSL2-LINE-TC-MIB Adsl2LineStatus ADSL2-LINE-TC-MIB Adsl2ChAtmStatus ADSL2-LINE-TC-MIB Adsl2ChPtmStatus ADSL2-LINE-TC-MIB AgentxTAddress AGENTX-MIB AggrMOErrorStatus AGGREGATE-MIB AggrMOValue AGGREGATE-MIB AggrMOCompressedValue AGGREGATE-MIB ResourceId ALARM-MIB LocalSnmpEngineOrZeroLenStr ALARM-MIB AppLocalIndex APM-MIB ProtocolDirNetworkAddress APM-MIB DataSourceOrZero APM-MIB RmonClientID APM-MIB TransactionAggregationType APM-MIB SnaSenseData APPC-MIB ATNetworkNumber APPLETALK-MIB DdpNodeAddress APPLETALK-MIB DdpSocketAddress APPLETALK-MIB ATName APPLETALK-MIB Unsigned64TC APPLICATION-MIB ApplTAddress APPLICATION-MIB SnaNodeIdentification APPN-MIB SnaControlPointName APPN-MIB SnaClassOfServiceName APPN-MIB SnaModeName APPN-MIB SnaSenseData APPN-MIB DisplayableDlcAddress APPN-MIB AppnNodeCounter APPN-MIB AppnPortCounter APPN-MIB AppnLinkStationCounter APPN-MIB AppnTopologyEntryTimeLeft APPN-MIB AppnTgDlcData APPN-MIB AppnTgEffectiveCapacity APPN-MIB AppnTgSecurity APPN-MIB AppnTgDelay APPN-MIB ApsK1K2 APS-MIB ApsSwitchCommand APS-MIB ApsControlCommand APS-MIB IANAItuProbableCauseOrZero ARC-MIB AtmAddr ATM-TC-MIB AtmConnCastType ATM-TC-MIB AtmConnKind ATM-TC-MIB AtmIlmiNetworkPrefix ATM-TC-MIB AtmInterfaceType ATM-TC-MIB AtmServiceCategory ATM-TC-MIB AtmSigDescrParamIndex ATM-TC-MIB AtmTrafficDescrParamIndex ATM-TC-MIB AtmVcIdentifier ATM-TC-MIB AtmVpIdentifier ATM-TC-MIB AtmVorXAdminStatus ATM-TC-MIB AtmVorXLastChange ATM-TC-MIB AtmVorXOperStatus ATM-TC-MIB BldgHvacOperation BLDG-HVAC-MIB BridgeId BRIDGE-MIB Timeout BRIDGE-MIB CapwapBaseWtpProfileIdTC CAPWAP-BASE-MIB CapwapBaseWtpIdTC CAPWAP-BASE-MIB CapwapBaseStationIdTC CAPWAP-BASE-MIB CapwapBaseRadioIdTC CAPWAP-BASE-MIB CapwapBaseTunnelModeTC CAPWAP-BASE-MIB CapwapBaseMacTypeTC CAPWAP-BASE-MIB CapwapBaseChannelTypeTC CAPWAP-BASE-MIB CapwapBaseAuthenMethodTC CAPWAP-BASE-MIB CapwapDot11WlanIdTC CAPWAP-DOT11-MIB CapwapDot11WlanIdProfileTC CAPWAP-DOT11-MIB PortIndex CHARACTER-MIB CiFlowDirection CIRCUIT-IF-MIB ClnpAddress CLNS-MIB CopsClientState COPS-CLIENT-MIB CopsServerEntryType COPS-CLIENT-MIB CopsErrorCode COPS-CLIENT-MIB CopsTcpPort COPS-CLIENT-MIB CopsAuthType COPS-CLIENT-MIB copsClientErrUnsupportClienttype COPS-CLIENT-MIB copsClientErrBadCtype COPS-CLIENT-MIB PhivAddr DECNET-PHIV-MIB PhivCounter DECNET-PHIV-MIB InterfaceIndex DECNET-PHIV-MIB AbsoluteCounter32 DIAL-CONTROL-MIB Dscp DIFFSERV-DSCP-TC DscpOrAny DIFFSERV-DSCP-TC IndexInteger DIFFSERV-MIB IndexIntegerNextFree DIFFSERV-MIB IfDirection DIFFSERV-MIB FailureReason DISMAN-EVENT-MIB OperationResponseStatus DISMAN-PING-MIB SnmpPduErrorStatus DISMAN-SCHEDULE-MIB NBName DLSW-MIB MacAddressNC DLSW-MIB TAddress DLSW-MIB EndStationLocation DLSW-MIB DlcType DLSW-MIB LFSize DLSW-MIB DlswTCPAddress DLSW-MIB DnsName DNS-SERVER-MIB DnsNameAsIndex DNS-SERVER-MIB DnsClass DNS-SERVER-MIB DnsType DNS-SERVER-MIB DnsQClass DNS-SERVER-MIB DnsQType DNS-SERVER-MIB DnsTime DNS-SERVER-MIB DnsOpCode DNS-SERVER-MIB DnsRespCode DNS-SERVER-MIB DocsX509ASN1DEREncodedCertificate DOCS-IETF-BPI2-MIB DocsSAId DOCS-IETF-BPI2-MIB DocsSAIdOrZero DOCS-IETF-BPI2-MIB DocsBpkmSAType DOCS-IETF-BPI2-MIB DocsBpkmDataEncryptAlg DOCS-IETF-BPI2-MIB DocsBpkmDataAuthentAlg DOCS-IETF-BPI2-MIB DocsIetfQosRfMacIfDirection DOCS-IETF-QOS-MIB DocsIetfQosBitRate DOCS-IETF-QOS-MIB DocsIetfQosSchedulingType DOCS-IETF-QOS-MIB TenthdBmV DOCS-IF-MIB TenthdB DOCS-IF-MIB DocsisVersion DOCS-IF-MIB DocsisQosVersion DOCS-IF-MIB DocsisUpstreamType DOCS-IF-MIB DocsEqualizerData DOCS-IF-MIB EightOTwoOui DOT3-OAM-MIB DsmonCounterAggGroupIndex DSMON-MIB DsmonCounterAggProfileIndex DSMON-MIB DvbRcsSatLabsProfileMap DVB-RCS-MIB DvbRcsSatLabsOptionMap DVB-RCS-MIB DvbRcsSatLabsFeatureMap DVB-RCS-MIB SnaNAUWildcardName EBN-MIB EfmProfileIndex EFM-CU-MIB EfmProfileIndexOrZero EFM-CU-MIB EfmProfileIndexList EFM-CU-MIB EfmTruthValueOrUnknown EFM-CU-MIB PhysicalIndex ENTITY-MIB PhysicalIndexOrZero ENTITY-MIB PhysicalClass ENTITY-MIB SnmpEngineIdOrNone ENTITY-MIB EntitySensorDataType ENTITY-SENSOR-MIB EntitySensorDataScale ENTITY-SENSOR-MIB EntitySensorPrecision ENTITY-SENSOR-MIB EntitySensorValue ENTITY-SENSOR-MIB EntitySensorStatus ENTITY-SENSOR-MIB EntityAdminState ENTITY-STATE-TC-MIB EntityOperState ENTITY-STATE-TC-MIB EntityUsageState ENTITY-STATE-TC-MIB EntityAlarmStatus ENTITY-STATE-TC-MIB EntityStandbyStatus ENTITY-STATE-TC-MIB FcNameIdOrZero FC-MGMT-MIB FcAddressIdOrZero FC-MGMT-MIB FcDomainIdOrZero FC-MGMT-MIB FcPortType FC-MGMT-MIB FcClasses FC-MGMT-MIB FcBbCredit FC-MGMT-MIB FcBbCreditModel FC-MGMT-MIB FcDataFieldSize FC-MGMT-MIB FcUnitFunctions FC-MGMT-MIB FcipDomainIdInOctetForm FCIP-MGMT-MIB FcipEntityMode FCIP-MGMT-MIB FcipEntityId FCIP-MGMT-MIB FddiTimeNano FDDI-SMT73-MIB FddiTimeMilli FDDI-SMT73-MIB FddiResourceId FDDI-SMT73-MIB FddiSMTStationIdType FDDI-SMT73-MIB FddiMACLongAddressType FDDI-SMT73-MIB MilliSeconds FIBRE-CHANNEL-FE-MIB MicroSeconds FIBRE-CHANNEL-FE-MIB FcNameId FIBRE-CHANNEL-FE-MIB FcAddressId FIBRE-CHANNEL-FE-MIB FcRxDataFieldSize FIBRE-CHANNEL-FE-MIB FcBbCredit FIBRE-CHANNEL-FE-MIB FcphVersion FIBRE-CHANNEL-FE-MIB FcStackedConnMode FIBRE-CHANNEL-FE-MIB FcCosCap FIBRE-CHANNEL-FE-MIB FcFeModuleCapacity FIBRE-CHANNEL-FE-MIB FcFeFxPortCapacity FIBRE-CHANNEL-FE-MIB FcFeModuleIndex FIBRE-CHANNEL-FE-MIB FcFeFxPortIndex FIBRE-CHANNEL-FE-MIB FcFeNxPortIndex FIBRE-CHANNEL-FE-MIB FcBbCreditModel FIBRE-CHANNEL-FE-MIB Float32TC FLOAT-TC-MIB Float64TC FLOAT-TC-MIB Float128TC FLOAT-TC-MIB UTF8OwnerString FLOW-METER-MIB PeerType FLOW-METER-MIB PeerAddress FLOW-METER-MIB AdjacentType FLOW-METER-MIB AdjacentAddress FLOW-METER-MIB TransportType FLOW-METER-MIB TransportAddress FLOW-METER-MIB RuleAddress FLOW-METER-MIB FlowAttributeNumber FLOW-METER-MIB RuleAttributeNumber FLOW-METER-MIB ActionNumber FLOW-METER-MIB ForcesID FORCES-MIB ForcesProtocolVersion FORCES-MIB MfrBundleLinkState FR-MFR-MIB DLCI FRAME-RELAY-DTE-MIB FrsldTxRP FRSLD-MIB FrsldRxRP FRSLD-MIB GmplsFreeformLabelTC GMPLS-TC-STD-MIB GmplsLabelTypeTC GMPLS-TC-STD-MIB GmplsSegmentDirectionTC GMPLS-TC-STD-MIB GsmpNameType GSMP-MIB GsmpPartitionType GSMP-MIB GsmpPartitionIdType GSMP-MIB GsmpVersion GSMP-MIB GsmpLabelType GSMP-MIB HcValueStatus HC-ALARM-MIB HCPerfValidIntervals HC-PerfHist-TC-MIB HCPerfInvalidIntervals HC-PerfHist-TC-MIB HCPerfTimeElapsed HC-PerfHist-TC-MIB HCPerfIntervalThreshold HC-PerfHist-TC-MIB HCPerfCurrentCount HC-PerfHist-TC-MIB HCPerfIntervalCount HC-PerfHist-TC-MIB HCPerfTotalCount HC-PerfHist-TC-MIB CounterBasedGauge64 HCNUM-TC ZeroBasedCounter64 HCNUM-TC Hdsl2ShdslPerfCurrDayCount HDSL2-SHDSL-LINE-MIB Hdsl2Shdsl1DayIntervalCount HDSL2-SHDSL-LINE-MIB Hdsl2ShdslPerfTimeElapsed HDSL2-SHDSL-LINE-MIB Hdsl2ShdslPerfIntervalThreshold HDSL2-SHDSL-LINE-MIB Hdsl2ShdslUnitId HDSL2-SHDSL-LINE-MIB Hdsl2ShdslUnitSide HDSL2-SHDSL-LINE-MIB Hdsl2ShdslWirePair HDSL2-SHDSL-LINE-MIB Hdsl2ShdslTransmissionModeType HDSL2-SHDSL-LINE-MIB Hdsl2ShdslClockReferenceType HDSL2-SHDSL-LINE-MIB KBytes HOST-RESOURCES-MIB ProductID HOST-RESOURCES-MIB InternationalDisplayString HOST-RESOURCES-MIB AppnTrafficType HPR-IP-MIB AppnTOSPrecedence HPR-IP-MIB HprNceTypes HPR-MIB HprRtpCounter HPR-MIB IANAItuProbableCause IANA-ITU-ALARM-TC-MIB IANAItuEventType IANA-ITU-ALARM-TC-MIB OwnerString IF-MIB InterfaceIndex IF-MIB InterfaceIndexOrZero IF-MIB IfcpIpTOVorZero IFCP-MGMT-MIB IfcpLTIorZero IFCP-MGMT-MIB IfcpSessionStates IFCP-MGMT-MIB IfcpAddressMode IFCP-MGMT-MIB InetAddressType INET-ADDRESS-MIB InetAddress INET-ADDRESS-MIB InetAddressIPv4 INET-ADDRESS-MIB InetAddressIPv6 INET-ADDRESS-MIB InetAddressIPv4z INET-ADDRESS-MIB InetAddressIPv6z INET-ADDRESS-MIB InetAddressDNS INET-ADDRESS-MIB InetAddressPrefixLength INET-ADDRESS-MIB InetPortNumber INET-ADDRESS-MIB InetAutonomousSystemNumber INET-ADDRESS-MIB InetScopeType INET-ADDRESS-MIB InetZoneIndex INET-ADDRESS-MIB InetVersion INET-ADDRESS-MIB SessionNumber INTEGRATED-SERVICES-MIB Protocol INTEGRATED-SERVICES-MIB SessionType INTEGRATED-SERVICES-MIB Port INTEGRATED-SERVICES-MIB MessageSize INTEGRATED-SERVICES-MIB BitRate INTEGRATED-SERVICES-MIB BurstSize INTEGRATED-SERVICES-MIB QosService INTEGRATED-SERVICES-MIB IpAddressOriginTC IP-MIB IpAddressStatusTC IP-MIB IpAddressPrefixOriginTC IP-MIB Ipv6AddressIfIdentifierTC IP-MIB LanguageTag IPMROUTE-STD-MIB IpoaEncapsType IPOA-MIB IpoaVpiInteger IPOA-MIB IpoaVciInteger IPOA-MIB IpoaAtmAddr IPOA-MIB IpoaAtmConnKind IPOA-MIB IpsAuthAddress IPS-AUTH-MIB SpdBooleanOperator IPSEC-SPD-MIB SpdAdminStatus IPSEC-SPD-MIB SpdIPPacketLogging IPSEC-SPD-MIB SpdTimePeriod IPSEC-SPD-MIB IPv6FlowLabel IPV6-FLOW-LABEL-MIB IPv6FlowLabelOrAny IPV6-FLOW-LABEL-MIB Ipv6Address IPV6-TC Ipv6AddressPrefix IPV6-TC Ipv6AddressIfIdentifier IPV6-TC Ipv6IfIndex IPV6-TC Ipv6IfIndexOrZero IPV6-TC IscsiTransportProtocol ISCSI-MIB IscsiDigestMethod ISCSI-MIB IscsiName ISCSI-MIB IsdnSignalingProtocol ISDN-MIB IsisOSINSAddress ISIS-MIB IsisSystemID ISIS-MIB IsisLinkStatePDUID ISIS-MIB IsisAdminState ISIS-MIB IsisLSPBuffSize ISIS-MIB IsisLevelState ISIS-MIB IsisSupportedProtocol ISIS-MIB IsisDefaultMetric ISIS-MIB IsisWideMetric ISIS-MIB IsisFullMetric ISIS-MIB IsisMetricType ISIS-MIB IsisMetricStyle ISIS-MIB IsisISLevel ISIS-MIB IsisLevel ISIS-MIB IsisPDUHeader ISIS-MIB IsisCircuitID ISIS-MIB IsisISPriority ISIS-MIB IsisUnsigned16TC ISIS-MIB IsisUnsigned8TC ISIS-MIB IsnsDiscoveryDomainSetId ISNS-MIB IsnsDdsStatusType ISNS-MIB IsnsDiscoveryDomainId ISNS-MIB IsnsDdFeatureType ISNS-MIB IsnsDdDdsModificationType ISNS-MIB IsnsEntityIndexIdOrZero ISNS-MIB IsnsPortalGroupIndexId ISNS-MIB IsnsPortalIndexId ISNS-MIB IsnsPortalPortTypeId ISNS-MIB IsnsPortalGroupTagIdOrNull ISNS-MIB IsnsPortalSecurityType ISNS-MIB IsnsNodeIndexId ISNS-MIB IsnsIscsiNodeType ISNS-MIB IsnsFcClassOfServiceType ISNS-MIB IsnsIscsiScnType ISNS-MIB IsnsIfcpScnType ISNS-MIB IsnsFcPortRoleType ISNS-MIB IsnsSrvrDiscoveryMethodsType ISNS-MIB ItuPerceivedSeverity ITU-ALARM-TC-MIB ItuTrendIndication ITU-ALARM-TC-MIB JmUTF8StringTC Job-Monitoring-MIB JmJobStringTC Job-Monitoring-MIB JmNaturalLanguageTagTC Job-Monitoring-MIB JmTimeStampTC Job-Monitoring-MIB JmJobSourcePlatformTypeTC Job-Monitoring-MIB JmFinishingTC Job-Monitoring-MIB JmPrintQualityTC Job-Monitoring-MIB JmPrinterResolutionTC Job-Monitoring-MIB JmTonerEconomyTC Job-Monitoring-MIB JmBooleanTC Job-Monitoring-MIB JmMediumTypeTC Job-Monitoring-MIB JmJobCollationTypeTC Job-Monitoring-MIB JmJobSubmissionIDTypeTC Job-Monitoring-MIB JmJobStateTC Job-Monitoring-MIB JmAttributeTypeTC Job-Monitoring-MIB JmJobServiceTypesTC Job-Monitoring-MIB JmJobStateReasons1TC Job-Monitoring-MIB JmJobStateReasons2TC Job-Monitoring-MIB JmJobStateReasons3TC Job-Monitoring-MIB JmJobStateReasons4TC Job-Monitoring-MIB L2tpMilliSeconds L2TP-MIB LangTag LANGTAG-TC-MIB LmpInterval LMP-MIB LmpRetransmitInterval LMP-MIB LmpNodeId LMP-MIB JackType MAU-MIB MidcomNatBindMode MIDCOM-MIB MidcomNatSessionIdOrZero MIDCOM-MIB RegistrationFlags MIP-MIB Mip6BURequestRejectionCode MOBILEIPV6-MIB MplsFTNEntryIndex MPLS-FTN-STD-MIB MplsFTNEntryIndexOrZero MPLS-FTN-STD-MIB MplsL3VpnName MPLS-L3VPN-STD-MIB MplsL3VpnRouteDistinguisher MPLS-L3VPN-STD-MIB MplsL3VpnRtType MPLS-L3VPN-STD-MIB MplsIndexType MPLS-LSR-STD-MIB MplsIndexNextType MPLS-LSR-STD-MIB MplsAtmVcIdentifier MPLS-TC-STD-MIB MplsBitRate MPLS-TC-STD-MIB MplsBurstSize MPLS-TC-STD-MIB MplsExtendedTunnelId MPLS-TC-STD-MIB MplsLabel MPLS-TC-STD-MIB MplsLabelDistributionMethod MPLS-TC-STD-MIB MplsLdpIdentifier MPLS-TC-STD-MIB MplsLsrIdentifier MPLS-TC-STD-MIB MplsLdpLabelType MPLS-TC-STD-MIB MplsLSPID MPLS-TC-STD-MIB MplsLspType MPLS-TC-STD-MIB MplsOwner MPLS-TC-STD-MIB MplsPathIndexOrZero MPLS-TC-STD-MIB MplsPathIndex MPLS-TC-STD-MIB MplsRetentionMode MPLS-TC-STD-MIB MplsTunnelAffinity MPLS-TC-STD-MIB MplsTunnelIndex MPLS-TC-STD-MIB MplsTunnelInstanceIndex MPLS-TC-STD-MIB TeHopAddressType MPLS-TC-STD-MIB TeHopAddress MPLS-TC-STD-MIB TeHopAddressAS MPLS-TC-STD-MIB TeHopAddressUnnum MPLS-TC-STD-MIB NatProtocolType NAT-MIB NatProtocolMap NAT-MIB NatAddrMapId NAT-MIB NatBindIdOrZero NAT-MIB NatBindId NAT-MIB NatSessionId NAT-MIB NatBindMode NAT-MIB NatAssociationType NAT-MIB NatTranslationEntity NAT-MIB DistinguishedName NETWORK-SERVICES-MIB URLString NETWORK-SERVICES-MIB NhrpGenAddr NHRP-MIB NtpStratum NTPv4-MIB NtpDateTime NTPv4-MIB OptIfAcTI OPT-IF-MIB OptIfBitRateK OPT-IF-MIB OptIfDEGM OPT-IF-MIB OptIfDEGThr OPT-IF-MIB OptIfDirectionality OPT-IF-MIB OptIfSinkOrSource OPT-IF-MIB OptIfExDAPI OPT-IF-MIB OptIfExSAPI OPT-IF-MIB OptIfIntervalNumber OPT-IF-MIB OptIfTIMDetMode OPT-IF-MIB OptIfTxTI OPT-IF-MIB AreaID OSPF-MIB RouterID OSPF-MIB Metric OSPF-MIB BigMetric OSPF-MIB Status OSPF-MIB PositiveInteger OSPF-MIB HelloRange OSPF-MIB UpToMaxAge OSPF-MIB DesignatedRouterPriority OSPF-MIB TOSType OSPF-MIB OspfAuthenticationType OSPF-MIB Ospfv3UpToRefreshIntervalTC OSPFV3-MIB Ospfv3DeadIntervalRangeTC OSPFV3-MIB Ospfv3RouterIdTC OSPFV3-MIB Ospfv3LsIdTC OSPFV3-MIB Ospfv3AreaIdTC OSPFV3-MIB Ospfv3IfInstIdTC OSPFV3-MIB Ospfv3LsaSequenceTC OSPFV3-MIB Ospfv3LsaAgeTC OSPFV3-MIB EnabledStatus P-BRIDGE-MIB PimMode PIM-STD-MIB PimGroupMappingOriginType PIM-STD-MIB PintServiceType PINT-MIB PintPerfStatPeriod PINT-MIB PktcMtaDevProvEncryptAlg PKTC-IETF-MTA-MIB TenthdBm PKTC-IETF-SIG-MIB PktcCodecType PKTC-IETF-SIG-MIB PktcRingCadence PKTC-IETF-SIG-MIB PktcSigType PKTC-IETF-SIG-MIB DtmfCode PKTC-IETF-SIG-MIB PktcSubscriberSideSigProtocol PKTC-IETF-SIG-MIB PmUTF8String POLICY-BASED-MANAGEMENT-MIB PtopoGenAddr PTOPO-MIB PtopoChassisIdType PTOPO-MIB PtopoChassisId PTOPO-MIB PtopoPortIdType PTOPO-MIB PtopoPortId PTOPO-MIB PtopoAddrSeenState PTOPO-MIB PwCepSonetEbm PW-CEP-STD-MIB PwCepSdhVc4Ebm PW-CEP-STD-MIB PwCepSonetVtgMap PW-CEP-STD-MIB PwCepFracAsyncMap PW-CEP-STD-MIB PwGroupID PW-TC-STD-MIB PwIDType PW-TC-STD-MIB PwIndexType PW-TC-STD-MIB PwIndexOrZeroType PW-TC-STD-MIB PwOperStatusTC PW-TC-STD-MIB PwAttachmentIdentifierType PW-TC-STD-MIB PwGenIdType PW-TC-STD-MIB PwCwStatusTC PW-TC-STD-MIB PwStatus PW-TC-STD-MIB PwFragSize PW-TC-STD-MIB PwFragStatus PW-TC-STD-MIB PwCfgIndexOrzero PW-TC-STD-MIB PwTDMCfgIndex PW-TDM-MIB PerfCurrentCount PerfHist-TC-MIB PerfIntervalCount PerfHist-TC-MIB PerfTotalCount PerfHist-TC-MIB PrtMediaUnitTC Printer-MIB MediaUnit Printer-MIB PrtCapacityUnitTC Printer-MIB CapacityUnit Printer-MIB PrtPrintOrientationTC Printer-MIB PrtSubUnitStatusTC Printer-MIB SubUnitStatus Printer-MIB PresentOnOff Printer-MIB PrtLocalizedDescriptionStringTC Printer-MIB PrtConsoleDescriptionStringTC Printer-MIB CodedCharSet Printer-MIB PrtChannelStateTC Printer-MIB PrtOutputStackingOrderTC Printer-MIB PrtOutputPageDeliveryOrientationTC Printer-MIB PrtMarkerCounterUnitTC Printer-MIB PrtMarkerSuppliesSupplyUnitTC Printer-MIB PrtMarkerSuppliesClassTC Printer-MIB PrtMarkerColorantRoleTC Printer-MIB PrtMarkerAddressabilityUnitTC Printer-MIB PrtMediaPathMaxSpeedPrintUnitTC Printer-MIB PrtInterpreterTwoWayTC Printer-MIB PrtAlertSeverityLevelTC Printer-MIB PortList Q-BRIDGE-MIB VlanIndex Q-BRIDGE-MIB VlanId Q-BRIDGE-MIB VlanIdOrAny Q-BRIDGE-MIB VlanIdOrNone Q-BRIDGE-MIB VlanIdOrAnyOrNone Q-BRIDGE-MIB ObjectName RFC1065-SMI NetworkAddress RFC1065-SMI IpAddress RFC1065-SMI Counter RFC1065-SMI Gauge RFC1065-SMI TimeTicks RFC1065-SMI Opaque RFC1065-SMI ObjectName RFC1155-SMI NetworkAddress RFC1155-SMI IpAddress RFC1155-SMI Counter RFC1155-SMI Gauge RFC1155-SMI TimeTicks RFC1155-SMI Opaque RFC1155-SMI DisplayString RFC1158-MIB DisplayString RFC1213-MIB PhysAddress RFC1213-MIB OwnerString RFC1271-MIB EntryStatus RFC1271-MIB FddiTime RFC1285-MIB FddiResourceId RFC1285-MIB FddiSMTStationIdType RFC1285-MIB FddiMACLongAddressType RFC1285-MIB AutonomousType RFC1316-MIB InstancePointer RFC1316-MIB PositiveInteger RFC1381-MIB IfIndexType RFC1381-MIB X121Address RFC1382-MIB RouteTag RIPv2-MIB OwnerString RMON-MIB EntryStatus RMON-MIB ZeroBasedCounter32 RMON2-MIB LastCreateTime RMON2-MIB TimeFilter RMON2-MIB DataSource RMON2-MIB ControlString RMON2-MIB RohcChannelIdentifier ROHC-MIB RohcChannelIdentifierOrZero ROHC-MIB RohcCompressionRatio ROHC-MIB RSerPoolENRPServerIdentifierTC RSERPOOL-MIB RSerPoolOperationScopeTC RSERPOOL-MIB RSerPoolPoolHandleTC RSERPOOL-MIB RserpoolPoolElementIdentifierTC RSERPOOL-MIB RSerPoolPolicyIdentifierTC RSERPOOL-MIB RSerPoolPolicyLoadTC RSERPOOL-MIB RSerPoolPolicyWeightTC RSERPOOL-MIB RSerPoolTransportUseTypeTC RSERPOOL-MIB RSerPoolOpaqueAddressTC RSERPOOL-MIB RsvpEncapsulation RSVP-MIB RefreshInterval RSVP-MIB ScsiLUN SCSI-MIB ScsiIndexValue SCSI-MIB ScsiPortIndexValueOrZero SCSI-MIB ScsiIndexValueOrZero SCSI-MIB ScsiIdentifier SCSI-MIB ScsiName SCSI-MIB ScsiLuNameOrZero SCSI-MIB ScsiDeviceOrPort SCSI-MIB ScsiIdCodeSet SCSI-MIB ScsiIdAssociation SCSI-MIB ScsiIdType SCSI-MIB ScsiIdValue SCSI-MIB ScsiHrSWInstalledIndexOrZero SCSI-MIB SMDSAddress SIP-MIB IfIndex SIP-MIB SipTCTransportProtocol SIP-TC-MIB SipTCEntityRole SIP-TC-MIB SipTCOptionTagHeaders SIP-TC-MIB SipTCMethodName SIP-TC-MIB SlapmNameType SLAPM-MIB SlapmStatus SLAPM-MIB SlapmPolicyRuleName SLAPM-MIB SmonDataSource SMON-MIB SnmpEngineID SNMP-FRAMEWORK-MIB SnmpSecurityModel SNMP-FRAMEWORK-MIB SnmpMessageProcessingModel SNMP-FRAMEWORK-MIB SnmpSecurityLevel SNMP-FRAMEWORK-MIB SnmpAdminString SNMP-FRAMEWORK-MIB OptMacAddr SNMP-REPEATER-MIB SnmpSSHAddress SNMP-SSH-TM-MIB SnmpTagValue SNMP-TARGET-MIB SnmpTagList SNMP-TARGET-MIB SnmpTLSAddress SNMP-TLS-TM-MIB SnmpTLSFingerprint SNMP-TLS-TM-MIB KeyChange SNMP-USER-BASED-SM-MIB DHKeyChange SNMP-USM-DH-OBJECTS-MIB ExtUTCTime SNMPv2-SMI ObjectName SNMPv2-SMI NotificationName SNMPv2-SMI Integer32 SNMPv2-SMI IpAddress SNMPv2-SMI Counter32 SNMPv2-SMI Gauge32 SNMPv2-SMI Unsigned32 SNMPv2-SMI TimeTicks SNMPv2-SMI Opaque SNMPv2-SMI Counter64 SNMPv2-SMI DisplayString SNMPv2-TC PhysAddress SNMPv2-TC MacAddress SNMPv2-TC TruthValue SNMPv2-TC TestAndIncr SNMPv2-TC AutonomousType SNMPv2-TC InstancePointer SNMPv2-TC VariablePointer SNMPv2-TC RowPointer SNMPv2-TC RowStatus SNMPv2-TC TimeStamp SNMPv2-TC TimeInterval SNMPv2-TC DateAndTime SNMPv2-TC StorageType SNMPv2-TC TDomain SNMPv2-TC TAddress SNMPv2-TC SnmpUDPAddress SNMPv2-TM SnmpOSIAddress SNMPv2-TM SnmpNBPAddress SNMPv2-TM SnmpIPXAddress SNMPv2-TM AgentID SNMPv2-USEC-MIB SspmMicroSeconds SSPM-MIB SspmClockSource SSPM-MIB SspmClockMaxSkew SSPM-MIB RunState SYSAPPL-MIB LongUtf8String SYSAPPL-MIB Utf8String SYSAPPL-MIB T11FamDomainPriority T11-FC-FABRIC-ADDR-MGR-MIB T11FamDomainInterfaceRole T11-FC-FABRIC-ADDR-MGR-MIB T11FamState T11-FC-FABRIC-ADDR-MGR-MIB T11FcListIndex T11-FC-FABRIC-CONFIG-SERVER-MIB T11FcListIndexPointerOrZero T11-FC-FABRIC-CONFIG-SERVER-MIB T11FcIeType T11-FC-FABRIC-CONFIG-SERVER-MIB T11FcPortState T11-FC-FABRIC-CONFIG-SERVER-MIB T11FcPortTxType T11-FC-FABRIC-CONFIG-SERVER-MIB T11FcsRejectReasonExplanation T11-FC-FABRIC-CONFIG-SERVER-MIB T11FspfLsrType T11-FC-FSPF-MIB T11FspfLinkType T11-FC-FSPF-MIB T11FspfInterfaceState T11-FC-FSPF-MIB T11FspfLastCreationTime T11-FC-FSPF-MIB T11NsGs4RejectReasonCode T11-FC-NAME-SERVER-MIB T11NsRejReasonCodeExpl T11-FC-NAME-SERVER-MIB T11ZsZoneMemberType T11-FC-ZONE-SERVER-MIB T11ZsRejectReasonExplanation T11-FC-ZONE-SERVER-MIB T11ZoningName T11-FC-ZONE-SERVER-MIB T11FabricIndex T11-TC-MIB TcpEStatsNegotiated TCP-ESTATS-MIB IpxAddress TCPIPX-MIB TeLinkBandwidth TE-LINK-STD-MIB TeLinkPriority TE-LINK-STD-MIB TeLinkProtection TE-LINK-STD-MIB TeLinkSwitchingCapability TE-LINK-STD-MIB TeLinkEncodingType TE-LINK-STD-MIB TeLinkSonetSdhIndication TE-LINK-STD-MIB TAggrMOErrorStatus TIME-AGGREGATE-MIB TimeAggrMOValue TIME-AGGREGATE-MIB CompressedTimeAggrMOValue TIME-AGGREGATE-MIB SnaResourceName TN3270E-MIB Tn3270eTraceData TN3270E-MIB MacAddress TOKEN-RING-RMON-MIB TimeInterval TOKEN-RING-RMON-MIB SourceRoute TOKENRING-STATION-SR-MIB TransportDomain TRANSPORT-ADDRESS-MIB TransportAddressType TRANSPORT-ADDRESS-MIB TransportAddress TRANSPORT-ADDRESS-MIB TransportAddressIPv4 TRANSPORT-ADDRESS-MIB TransportAddressIPv6 TRANSPORT-ADDRESS-MIB TransportAddressIPv4z TRANSPORT-ADDRESS-MIB TransportAddressIPv6z TRANSPORT-ADDRESS-MIB TransportAddressLocal TRANSPORT-ADDRESS-MIB TransportAddressDns TRANSPORT-ADDRESS-MIB TripItad TRIP-TC-MIB TripId TRIP-TC-MIB TripAddressFamily TRIP-TC-MIB TripAppProtocol TRIP-TC-MIB TripCommunityId TRIP-TC-MIB TripProtocolVersion TRIP-TC-MIB TripSendReceiveMode TRIP-TC-MIB PositiveInteger UPS-MIB NonNegativeInteger UPS-MIB Uri URI-TC-MIB Uri255 URI-TC-MIB Uri1024 URI-TC-MIB VdslSCMBandId VDSL-LINE-EXT-SCM-MIB VdslLineCodingType VDSL-LINE-MIB VdslLineEntity VDSL-LINE-MIB Xdsl2Unit VDSL2-LINE-TC-MIB Xdsl2Direction VDSL2-LINE-TC-MIB Xdsl2Band VDSL2-LINE-TC-MIB Xdsl2TransmissionModeType VDSL2-LINE-TC-MIB Xdsl2RaMode VDSL2-LINE-TC-MIB Xdsl2InitResult VDSL2-LINE-TC-MIB Xdsl2OperationModes VDSL2-LINE-TC-MIB Xdsl2PowerMngState VDSL2-LINE-TC-MIB Xdsl2ConfPmsForce VDSL2-LINE-TC-MIB Xdsl2LinePmMode VDSL2-LINE-TC-MIB Xdsl2LineLdsf VDSL2-LINE-TC-MIB Xdsl2LdsfResult VDSL2-LINE-TC-MIB Xdsl2LineBpsc VDSL2-LINE-TC-MIB Xdsl2BpscResult VDSL2-LINE-TC-MIB Xdsl2LineReset VDSL2-LINE-TC-MIB Xdsl2LineProfiles VDSL2-LINE-TC-MIB Xdsl2LineClassMask VDSL2-LINE-TC-MIB Xdsl2LineLimitMask VDSL2-LINE-TC-MIB Xdsl2LineUs0Disable VDSL2-LINE-TC-MIB Xdsl2LineUs0Mask VDSL2-LINE-TC-MIB Xdsl2SymbolProtection VDSL2-LINE-TC-MIB Xdsl2SymbolProtection8 VDSL2-LINE-TC-MIB Xdsl2MaxBer VDSL2-LINE-TC-MIB Xdsl2ChInitPolicy VDSL2-LINE-TC-MIB Xdsl2ScMaskDs VDSL2-LINE-TC-MIB Xdsl2ScMaskUs VDSL2-LINE-TC-MIB Xdsl2CarMask VDSL2-LINE-TC-MIB Xdsl2RfiBands VDSL2-LINE-TC-MIB Xdsl2PsdMaskDs VDSL2-LINE-TC-MIB Xdsl2PsdMaskUs VDSL2-LINE-TC-MIB Xdsl2Tssi VDSL2-LINE-TC-MIB Xdsl2LastTransmittedState VDSL2-LINE-TC-MIB Xdsl2LineStatus VDSL2-LINE-TC-MIB Xdsl2ChInpReport VDSL2-LINE-TC-MIB Xdsl2ChAtmStatus VDSL2-LINE-TC-MIB Xdsl2ChPtmStatus VDSL2-LINE-TC-MIB Xdsl2UpboKLF VDSL2-LINE-TC-MIB Xdsl2BandUs VDSL2-LINE-TC-MIB Xdsl2LinePsdMaskSelectUs VDSL2-LINE-TC-MIB Xdsl2LineCeFlag VDSL2-LINE-TC-MIB Xdsl2LineSnrMode VDSL2-LINE-TC-MIB Xdsl2LineTxRefVnDs VDSL2-LINE-TC-MIB Xdsl2LineTxRefVnUs VDSL2-LINE-TC-MIB Xdsl2BitsAlloc VDSL2-LINE-TC-MIB Xdsl2MrefPsdDs VDSL2-LINE-TC-MIB Xdsl2MrefPsdUs VDSL2-LINE-TC-MIB VPNId VPN-TC-STD-MIB VPNIdOrZero VPN-TC-STD-MIB VrId VRRP-MIB Vrrpv3VrIdTC VRRPV3-MIB WwwRequestType WWW-MIB WwwResponseType WWW-MIB WwwOperStatus WWW-MIB WwwDocName WWW-MIB --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iana-tcs.txt" AddressFamilyNumbers IANA-ADDRESS-FAMILY-NUMBERS-MIB IANACharset IANA-CHARSET-MIB FinDeviceTypeTC IANA-FINISHER-MIB FinAttributeTypeTC IANA-FINISHER-MIB FinEdgeTC IANA-FINISHER-MIB FinStitchingTypeTC IANA-FINISHER-MIB FinStitchingDirTypeTC IANA-FINISHER-MIB FinStitchingAngleTypeTC IANA-FINISHER-MIB FinFoldingTypeTC IANA-FINISHER-MIB FinBindingTypeTC IANA-FINISHER-MIB FinPunchHoleTypeTC IANA-FINISHER-MIB FinPunchPatternTC IANA-FINISHER-MIB FinSlittingTypeTC IANA-FINISHER-MIB FinWrappingTypeTC IANA-FINISHER-MIB FinStackOutputTypeTC IANA-FINISHER-MIB IANAGmplsLSPEncodingTypeTC IANA-GMPLS-TC-MIB IANAGmplsSwitchingTypeTC IANA-GMPLS-TC-MIB IANAGmplsGeneralizedPidTC IANA-GMPLS-TC-MIB IANAGmplsAdminStatusInformationTC IANA-GMPLS-TC-MIB IANAItuProbableCause IANA-ITU-ALARM-TC-MIB IANAItuEventType IANA-ITU-ALARM-TC-MIB IANAscopeSource IANA-MALLOC-MIB IANAmallocRangeSource IANA-MALLOC-MIB IANAifMauMediaAvailable IANA-MAU-MIB IANAifJackType IANA-MAU-MIB PrtCoverStatusTC IANA-PRINTER-MIB PrtGeneralResetTC IANA-PRINTER-MIB PrtChannelTypeTC IANA-PRINTER-MIB PrtInterpreterLangFamilyTC IANA-PRINTER-MIB PrtInputTypeTC IANA-PRINTER-MIB PrtOutputTypeTC IANA-PRINTER-MIB PrtMarkerMarkTechTC IANA-PRINTER-MIB PrtMarkerSuppliesTypeTC IANA-PRINTER-MIB PrtMediaPathTypeTC IANA-PRINTER-MIB PrtConsoleColorTC IANA-PRINTER-MIB PrtConsoleDisableTC IANA-PRINTER-MIB PrtAlertTrainingLevelTC IANA-PRINTER-MIB PrtAlertGroupTC IANA-PRINTER-MIB PrtAlertCodeTC IANA-PRINTER-MIB IANAPwTypeTC IANA-PWE3-MIB IANAPwPsnTypeTC IANA-PWE3-MIB IANAPwCapabilities IANA-PWE3-MIB IANAipRouteProtocol IANA-RTPROTO-MIB IANAipMRouteProtocol IANA-RTPROTO-MIB IANATn3270eAddrType IANATn3270eTC-MIB IANATn3270eAddress IANATn3270eTC-MIB IANATn3270eClientType IANATn3270eTC-MIB IANATn3270Functions IANATn3270eTC-MIB IANATn3270ResourceType IANATn3270eTC-MIB IANATn3270DeviceType IANATn3270eTC-MIB IANATn3270eLogData IANATn3270eTC-MIB IANAifType IANAifType-MIB IANAtunnelType IANAifType-MIB --5/uDoXvLw7AC5HRs-- From dromasca@avaya.com Thu Mar 22 02:47: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 1E90C21F8646 for ; Thu, 22 Mar 2012 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 rVhbC6eGkBsS for ; Thu, 22 Mar 2012 02:46:59 -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 776C021F8607 for ; Thu, 22 Mar 2012 02:46:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcNADf0ak/GmAcF/2dsb2JhbABCsDCGe4EHggkBAQEBAxIeCksEAgEIDQECAQQBAQEKBgwLAQYBRQkIAQEEARoTB4dookCUO5ABYwSbbooZgmg X-IronPort-AV: E=Sophos;i="4.73,629,1325480400"; d="scan'208";a="338338048" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Mar 2012 05:46:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Mar 2012 05:38:36 -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: Thu, 22 Mar 2012 10:46:56 +0100 Message-ID: In-Reply-To: <20120322094303.GD18297@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] protocol number TC? Thread-Index: Ac0IEDB/MAAt7U2fS/yfvylZovmCNwAACd0w References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> <20120322094303.GD18297@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Andy Bierman" , "David Harrington" , "MIB Doctors" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 09:47:00 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, March 22, 2012 11:43 AM > To: Romascanu, Dan (Dan); Andy Bierman; David Harrington; MIB Doctors > Subject: Re: [MIB-DOCTORS] protocol number TC? >=20 > On Thu, Mar 22, 2012 at 10:24:04AM +0100, Juergen Schoenwaelder wrote: > > On Thu, Mar 22, 2012 at 09:56:07AM +0100, Romascanu, Dan (Dan) wrote: > > > I think that this is more or less what we intended to do with the > > > creation of a Web page for TCs. A place where we would store the > > > TCs, configuration control by allowing access only to the ADs, > maybe > > > to the MIB doctors, review by the MIB doctors, without the overhead > > > of writing an RFC and administrating by IANA. A lose an informal > > > process supported by the MIB doctors team. Is there any reason for > > > this not to work? Or is it not enough? > > > > Perhaps "Generic and Common Textual Conventions" makes it unclear > what > > to add/remove. But anyway, here is the list of IETF and IANA TCs I > > just extracted using something like > > > > smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s > %s\n",$2,$1)}' > > > > just in case someone wants to check whether something should be added > > to the web page. With a bit more effort, I can probably produce > > something more useful. > > > > That said, the web page tries to add value by listing "Generic and > > Common Textual Conventions". At the same time, this makes the web > page > > useless for searching for TCs since it by definition is incomplete. > > > > /js > > > > PS: I note that even after years of discussions (that was still when > > Bert was AD), we still have no central place where one can pickup > > all extracted MIB modules. This would really be the first step > for > > any automated solution but since this did not materialize for > > years, perhaps it is not important enough. >=20 > Now with the attachements... >=20 Yes, we are talking about two different things:=20 - a place to find all extracted MIB modules and all TCs=20 - a place to find 'generic and common TCs' Both have value IMO.=20 Dan =20 From bclaise@cisco.com Thu Mar 22 03:06: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 A44C521F8657 for ; Thu, 22 Mar 2012 03:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=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 aUKUrz9pYRcd for ; Thu, 22 Mar 2012 03:06:17 -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 861A521F865E for ; Thu, 22 Mar 2012 03:06:17 -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 q2MA5npF021736; Thu, 22 Mar 2012 11:05:49 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2MA5mV3029645; Thu, 22 Mar 2012 11:05:49 +0100 (CET) Message-ID: <4F6AF97C.3080208@cisco.com> Date: Thu, 22 Mar 2012 11:05:48 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> <20120322094303.GD18297@elstar.local> In-Reply-To: <20120322094303.GD18297@elstar.local> Content-Type: multipart/alternative; boundary="------------040609040900090101040908" Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 10:06:18 -0000 This is a multi-part message in MIME format. --------------040609040900090101040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, Excellent. Proposal to update http://www.ops.ietf.org/mib-common-tcs.html, to divide the pages into two parts: 1. Generic and Common Textual Conventions (TCs) 2. List of all TCs in IETF MIB modules. Produced from "smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}' Last updated on March 22nd, by Juergen Schoenwaelder DataCollectionSubtree ACCOUNTING-CONTROL-MIB DataCollectionList ACCOUNTING-CONTROL-MIB FileIndex ACCOUNTING-CONTROL-MIB AdslTransmissionModeType ADSL-LINE-EXT-MIB AdslLineCodingType ADSL-TC-MIB ... Note1: hopefully the distinction between 1. and 2. makes sense? I mean we have the full list in 2., but 1. mentions "Generic and Common Textual Conventions (TCs)" So to come back to my initial question about a "protocol number TC", I now found Protocol INTEGRATED-SERVICES-MIB Should I use it since it's in the full list in 2. but not in 1.? Question:Do MIB doctors strongly suggest the TCs in section 1 while the ones in section 2 are nice to have? In other words, do we only need the section 2.? Note2: I believe the format is good enough for our purpose DataCollectionSubtree ACCOUNTING-CONTROL-MIB We could always improve this with the TC definition, a link to the RFC, etc... but not sure the benefit is worth the time, as the TC name are most of the time self explanatory. Regards, Benoit. > On Thu, Mar 22, 2012 at 10:24:04AM +0100, Juergen Schoenwaelder wrote: >> On Thu, Mar 22, 2012 at 09:56:07AM +0100, Romascanu, Dan (Dan) wrote: >>> I think that this is more or less what we intended to do with the >>> creation of a Web page for TCs. A place where we would store the TCs, >>> configuration control by allowing access only to the ADs, maybe to the >>> MIB doctors, review by the MIB doctors, without the overhead of writing >>> an RFC and administrating by IANA. A lose an informal process supported >>> by the MIB doctors team. Is there any reason for this not to work? Or is >>> it not enough? >> Perhaps "Generic and Common Textual Conventions" makes it unclear what >> to add/remove. But anyway, here is the list of IETF and IANA TCs I >> just extracted using something like >> >> smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}' >> >> just in case someone wants to check whether something should be added >> to the web page. With a bit more effort, I can probably produce >> something more useful. >> >> That said, the web page tries to add value by listing "Generic and >> Common Textual Conventions". At the same time, this makes the web page >> useless for searching for TCs since it by definition is incomplete. >> >> /js >> >> PS: I note that even after years of discussions (that was still when >> Bert was AD), we still have no central place where one can pickup >> all extracted MIB modules. This would really be the first step for >> any automated solution but since this did not materialize for >> years, perhaps it is not important enough. > Now with the attachements... > > /js > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors --------------040609040900090101040908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

Excellent.

Proposal to update http://www.ops.ietf.org/mib-common-tcs.html, to divide the pages into two parts:

1.  Generic and Common Textual Conventions (TCs)

2. List of all TCs in IETF MIB modules.
Produced from "smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}'
Last updated on March 22nd, by Juergen Schoenwaelder

DataCollectionSubtree                      ACCOUNTING-CONTROL-MIB
DataCollectionList                             ACCOUNTING-CONTROL-MIB
FileIndex                                             ACCOUNTING-CONTROL-MIB
AdslTransmissionModeType           ADSL-LINE-EXT-MIB
AdslLineCodingType                         ADSL-TC-MIB
...



Note1: hopefully the distinction between 1. and 2. makes sense?
I mean we have the full list in 2., but 1. mentions "Generic and Common Textual Conventions (TCs)"
So to come back to my initial question about a "protocol number TC", I now found
    Protocol                       INTEGRATED-SERVICES-MIB
Should I use it since it's in the full list in 2. but not in 1.?
Question:Do MIB doctors strongly suggest the TCs in section 1 while the ones in section 2 are nice to have?
In other words, do we only need the section 2.?

Note2: I believe the format is good enough for our purpose
    DataCollectionSubtree                      ACCOUNTING-CONTROL-MIB
We could always improve this with the TC definition, a link to the RFC, etc... but not sure the benefit is worth the time, as the TC name are most of the time self explanatory.


Regards, Benoit.


On Thu, Mar 22, 2012 at 10:24:04AM +0100, Juergen Schoenwaelder wrote:

On Thu, Mar 22, 2012 at 09:56:07AM +0100, Romascanu, Dan (Dan) wrote:

I think that this is more or less what we intended to do with the
creation of a Web page for TCs. A place where we would store the TCs,
configuration control by allowing access only to the ADs, maybe to the
MIB doctors, review by the MIB doctors, without the overhead of writing
an RFC and administrating by IANA. A lose an informal process supported
by the MIB doctors team. Is there any reason for this not to work? Or is
it not enough? 

Perhaps "Generic and Common Textual Conventions" makes it unclear what
to add/remove. But anyway, here is the list of IETF and IANA TCs I
just extracted using something like

smidump -k -f identifiers ietf/* | awk '/type/{printf("%-30s %s\n",$2,$1)}'

just in case someone wants to check whether something should be added
to the web page. With a bit more effort, I can probably produce
something more useful.

That said, the web page tries to add value by listing "Generic and
Common Textual Conventions". At the same time, this makes the web page
useless for searching for TCs since it by definition is incomplete.

/js

PS: I note that even after years of discussions (that was still when
    Bert was AD), we still have no central place where one can pickup
    all extracted MIB modules. This would really be the first step for
    any automated solution but since this did not materialize for
    years, perhaps it is not important enough.

Now with the attachements...

/js




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

--------------040609040900090101040908-- From j.schoenwaelder@jacobs-university.de Thu Mar 22 04:10: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 6C40C21F8548 for ; Thu, 22 Mar 2012 04:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_82=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 yClblYXAFKkO for ; Thu, 22 Mar 2012 04:10:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAB21F8550 for ; Thu, 22 Mar 2012 04:10:25 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D728520D1B; Thu, 22 Mar 2012 12:10:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LjFOnZ4LtyOM; Thu, 22 Mar 2012 12:10:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EB1320CFA; Thu, 22 Mar 2012 12:10:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 466431E17BD9; Thu, 22 Mar 2012 12:10:22 +0100 (CET) Date: Thu, 22 Mar 2012 12:10:21 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120322111021.GA22237@elstar.local> Mail-Followup-To: Benoit Claise , "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> <20120322094303.GD18297@elstar.local> <4F6AF97C.3080208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F6AF97C.3080208@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 22 Mar 2012 11:10:39 -0000 On Thu, Mar 22, 2012 at 11:05:48AM +0100, Benoit Claise wrote: > So to come back to my initial question about a "protocol number TC", > I now found > Protocol INTEGRATED-SERVICES-MIB > Should I use it since it's in the full list in 2. but not in 1.? Concerning the Protocol TC, that one seems to be doing what you want (and it is surprising to find it in the INTEGRATED-SERVICES-MIB). Note that using it creates a normative reference to (and hence dependency on) the RFC defining the INTEGRATED-SERVICES-MIB. > Question:Do MIB doctors strongly suggest the TCs in section 1 while > the ones in section 2 are nice to have? > In other words, do we only need the section 2.? Hard to tell. There might be TCs in section 2 that should not be used, e.g. definitions from the first attempt to support IPv6 where we moved from separate IPv6 MIB modules to more integrated MIB modules. See for example IPV6-TC defined in RFC 2465. While the RFC itself got obsoleted by RFC 4293, the MIB modules defined in RFC 2465 did of course not get updated and hence people can easily pick definitions that are not really up to date. We are not really managing this part of the life cycle well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 26 03:23: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 A5D3721F84B6 for ; Mon, 26 Mar 2012 03:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wzt2ZBw1eWCu for ; Mon, 26 Mar 2012 03:23:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 286D921F8522 for ; Mon, 26 Mar 2012 03:23:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 795AB20C71; Mon, 26 Mar 2012 12:23:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xxb1KN9NYkrL; Mon, 26 Mar 2012 12:23:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA19120C66; Mon, 26 Mar 2012 12:23:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 159EC1E1D9AB; Mon, 26 Mar 2012 12:23:12 +0200 (CEST) Date: Mon, 26 Mar 2012 12:23:12 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120326102312.GA33729@elstar.local> Mail-Followup-To: Benoit Claise , "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> <20120322094303.GD18297@elstar.local> <4F6AF97C.3080208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F6AF97C.3080208@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: MIB Doctors Subject: Re: [MIB-DOCTORS] protocol number TC? 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: Mon, 26 Mar 2012 10:23:20 -0000 On Thu, Mar 22, 2012 at 11:05:48AM +0100, Benoit Claise wrote: > 2. List of all TCs in IETF MIB modules. > Produced from "smidump -k -f identifiers ietf/* | awk > '/type/{printf("%-30s %s\n",$2,$1)}' During my train ride to Paris, I wrote a backend for smidump producing a TC list in xml2rfc format that can be rendered as .txt or .html: http://www.beadg.de/doctors/iana-tc-list.html http://www.beadg.de/doctors/iana-tc-list.txt http://www.beadg.de/doctors/ietf-tc-list.html http://www.beadg.de/doctors/ietf-tc-list.txt /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 Mon Mar 26 03:53: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 C89CA21F859A for ; Mon, 26 Mar 2012 03:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 R+3iCM0FdE7i for ; Mon, 26 Mar 2012 03:53:47 -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 94BB721F8549 for ; Mon, 26 Mar 2012 03:53:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2QArbKw019671; Mon, 26 Mar 2012 12:53:38 +0200 (CEST) Received: from [10.55.91.94] (dhcp-10-55-91-94.cisco.com [10.55.91.94]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2QArbZg029821; Mon, 26 Mar 2012 12:53:37 +0200 (CEST) Message-ID: <4F704AB1.3020302@cisco.com> Date: Mon, 26 Mar 2012 12:53:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Andy Bierman , David Harrington , MIB Doctors References: <4F6A02B9.8040201@cisco.com> <20120321181900.GA1876@elstar.local> <4F6A4EB4.1050208@cisco.com> <835ADEB3BFBF4CD98A8EA7FB695273FE@JV6RVH1> <4F6A57C5.7010809@netconfcentral.org> <20120322092404.GB18297@elstar.local> <20120322094303.GD18297@elstar.local> <4F6AF97C.3080208@cisco.com> <20120326102312.GA33729@elstar.local> In-Reply-To: <20120326102312.GA33729@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] protocol number TC? 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, 26 Mar 2012 10:53:49 -0000 Hi Juergen, You made my day! Thanks. I'l update the WIKI with these links. Regards, Benoit. > On Thu, Mar 22, 2012 at 11:05:48AM +0100, Benoit Claise wrote: > >> 2. List of all TCs in IETF MIB modules. >> Produced from "smidump -k -f identifiers ietf/* | awk >> '/type/{printf("%-30s %s\n",$2,$1)}' > During my train ride to Paris, I wrote a backend for smidump producing > a TC list in xml2rfc format that can be rendered as .txt or .html: > > http://www.beadg.de/doctors/iana-tc-list.html > http://www.beadg.de/doctors/iana-tc-list.txt > http://www.beadg.de/doctors/ietf-tc-list.html > http://www.beadg.de/doctors/ietf-tc-list.txt > > /js > From adrian@olddog.co.uk Thu Mar 29 04:33: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 8440921F899D for ; Thu, 29 Mar 2012 04:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 FvEMltyQJ2tN for ; Thu, 29 Mar 2012 04:33:43 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 484C121F8985 for ; Thu, 29 Mar 2012 04:33:42 -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 q2TBXfZ5010907; Thu, 29 Mar 2012 12:33:41 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2TBXe3n010890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 12:33:40 +0100 From: "Adrian Farrel" To: Date: Thu, 29 Mar 2012 12:33:41 +0100 Message-ID: <0d1401cd0d9f$cb2b0dd0$61812970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0Nn5hBzN0SmKiBR1GRo9uDAt6Y3Q== Content-Language: en-gb Cc: manet-chairs@tools.ietf.org, draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: [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: Thu, 29 Mar 2012 11:33:44 -0000 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