From DanielC@orckit.com Thu Dec 1 00:41:57 2011 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 8940721F8C0F for ; Thu, 1 Dec 2011 00:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 oxuXHUB7zcld for ; Thu, 1 Dec 2011 00:41:56 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 308D221F8C0D for ; Thu, 1 Dec 2011 00:41:49 -0800 (PST) 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_01CCB005.80B8603C" Date: Thu, 1 Dec 2011 10:41:46 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General question on MIBs Thread-Index: AcywBQ9W/avRPfnoScqFPaajD0EXTg== From: "Daniel Cohn" To: X-Mailman-Approved-At: Thu, 01 Dec 2011 00:42:35 -0800 Subject: [MIB-DOCTORS] General question on MIBs 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 Dec 2011 08:41:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB005.80B8603C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Doctors, =20 This question has been bugging me for some time, hope you can shed some light on it.=20 =20 The SMIv2 standard allows for either including INDEX objects as columnar objects of the table, in which case they are called auxiliary objects, or not going so. MIB compilers I have worked with allow both options. I see that common practice in standard MIBs is to define INDEX objects as auxiliary objects (except when they are "reused" from a different table or MIB).=20 My question is: what is the advantage of doing this? In any event set/get operations will include the INDEX object as part of the OID, so what is the advantage of having the INDEX object as a columnar object?=20 =20 Thanks in advance for your help, =20 Daniel =20 ------_=_NextPart_001_01CCB005.80B8603C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Doctors,

This question has been bugging me for some time, hope = you can shed some light on it.

The SMIv2 = standard allows for either including INDEX objects as columnar objects = of the table, in which case they are called auxiliary objects, or not = going so. MIB compilers I have worked with allow both = options.

I see that common practice = in standard MIBs is to define INDEX objects as auxiliary objects (except = when they are “reused” from a different table or MIB). =

My question is: what is the = advantage of doing this? In any event set/get operations will include = the INDEX object as part of the OID, so what is the advantage of having = the INDEX object as a columnar object?

Thanks in = advance for your help,

Daniel

------_=_NextPart_001_01CCB005.80B8603C-- From j.schoenwaelder@jacobs-university.de Thu Dec 1 01:28:37 2011 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 7485D21F8BB6 for ; Thu, 1 Dec 2011 01:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.994 X-Spam-Level: X-Spam-Status: No, score=-102.994 tagged_above=-999 required=5 tests=[AWL=0.255, 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 nx34vdAXq9VA for ; Thu, 1 Dec 2011 01:28:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBB21F8BAD for ; Thu, 1 Dec 2011 01:28:36 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C89F520CC4; Thu, 1 Dec 2011 10:28:35 +0100 (CET) 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 3jreMfdbMNKx; Thu, 1 Dec 2011 10:28:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6598520CA9; Thu, 1 Dec 2011 10:28:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EB4171BEED76; Thu, 1 Dec 2011 10:28:15 +0100 (CET) Date: Thu, 1 Dec 2011 10:28:15 +0100 From: Juergen Schoenwaelder To: Daniel Cohn Message-ID: <20111201092815.GA4609@elstar.local> Mail-Followup-To: Daniel Cohn , mib-doctors@ietf.org References: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs 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 Dec 2011 09:28:37 -0000 On Thu, Dec 01, 2011 at 10:41:46AM +0200, Daniel Cohn wrote: > The SMIv2 standard allows for either including INDEX objects as columnar > objects of the table, in which case they are called auxiliary objects, > or not going so. MIB compilers I have worked with allow both options. > > I see that common practice in standard MIBs is to define INDEX objects > as auxiliary objects (except when they are "reused" from a different > table or MIB). > > My question is: what is the advantage of doing this? In any event > set/get operations will include the INDEX object as part of the OID, so > what is the advantage of having the INDEX object as a columnar object? I am not sure I understand your question and this is likely due to terminology confusion. Here is what RFC 2578 says: a) Objects listed in INDEX clauses are always columnar objects. They may be columnar objects of the same table or a different table. (Section 7.7 of RFC 2578). b) Section 7.7 of RFC 2578 also says that objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. So perhaps your question really is whether auxiliary objects should be not-accessible. RFC 2578 is pretty clear about this: The MAX-ACCESS clause for auxiliary objects is "not-accessible", except in a few special cases. (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; or (2) a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". What is the advantage of readable auxiliary objects? I guess the answer is a) simple-minded SNMP implementations that are not capable to extract values out of instance identifiers and b) the astonishing amount of confusion out there how SNMP actually works. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From DanielC@orckit.com Thu Dec 1 05:34:33 2011 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 9F2D211E8463 for ; Thu, 1 Dec 2011 05:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 E+Cq5DNi0U-2 for ; Thu, 1 Dec 2011 05:34:32 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6D06311E8456 for ; Thu, 1 Dec 2011 05:34:17 -0800 (PST) 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, 1 Dec 2011 15:34:19 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307362264@tlvmail1> In-Reply-To: <20111201092815.GA4609@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] General question on MIBs Thread-Index: AcywDAuIAcgzOYxySNip6uuIZ+t5rAAE67YQ References: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> <20111201092815.GA4609@elstar.local> From: "Daniel Cohn" To: "Juergen Schoenwaelder" X-Mailman-Approved-At: Thu, 01 Dec 2011 06:05:52 -0800 Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs 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 Dec 2011 13:34:33 -0000 Hi Juergen, thanks for your response. Let me clarify my question with an example. Let's say I want to define a conceptual table, fooTable that is indexed by interface. Then I can either: 1.- Reuse the ifIndex from the standard IF-MIB as follows: IMPORTS ifIndex FROM IF-MIB ... fooTable OBJECT-TYPE SYNTAX SEQUENCE OF FooEntry fooEntry OBJECT-TYPE SYNTAX FooEntry INDEX {ifIndex} FooEntry SEQUENCE { object1 ... object2 ... } 2.- Define a new ad-hoc fooIfIndex object, just for this table, with the same meaning as the standard ifIndex, i.e. the index of the interface to which the table information applies, as follows: fooTable OBJECT-TYPE SYNTAX SEQUENCE OF FooEntry fooEntry OBJECT-TYPE SYNTAX FooEntry INDEX {fooIfIndex} FooEntry SEQUENCE { fooIfIndex InterfaceIndex object1 ... object2 ... } fooIfIndex OBJECT-TYPE SYNTAX InterfaceIndex DESCRIPTION "The index of the interface to which objects in fooTable apply" .... Take for example RFC 4836. Instead of defining a new ifMauIfIndex, ifIndex could have been imported from IF-MIB. So my question is - is there any difference? Is any of the approaches preferred? Thanks again, Daniel =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, December 01, 2011 11:28 AM To: Daniel Cohn Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs On Thu, Dec 01, 2011 at 10:41:46AM +0200, Daniel Cohn wrote: =20 > The SMIv2 standard allows for either including INDEX objects as columnar > objects of the table, in which case they are called auxiliary objects, > or not going so. MIB compilers I have worked with allow both options. >=20 > I see that common practice in standard MIBs is to define INDEX objects > as auxiliary objects (except when they are "reused" from a different > table or MIB).=20 >=20 > My question is: what is the advantage of doing this? In any event > set/get operations will include the INDEX object as part of the OID, so > what is the advantage of having the INDEX object as a columnar object? I am not sure I understand your question and this is likely due to terminology confusion. Here is what RFC 2578 says: a) Objects listed in INDEX clauses are always columnar objects. They may be columnar objects of the same table or a different table. (Section 7.7 of RFC 2578). b) Section 7.7 of RFC 2578 also says that objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. So perhaps your question really is whether auxiliary objects should be not-accessible. RFC 2578 is pretty clear about this: The MAX-ACCESS clause for auxiliary objects is "not-accessible", except in a few special cases. (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; or (2) a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". What is the advantage of readable auxiliary objects? I guess the answer is a) simple-minded SNMP implementations that are not capable to extract values out of instance identifiers and b) the astonishing amount of confusion out there how SNMP actually works. /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 Thu Dec 1 07:08:52 2011 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 A356311E8116 for ; Thu, 1 Dec 2011 07:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.302 X-Spam-Level: X-Spam-Status: No, score=-103.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 Osxn-efxirCy for ; Thu, 1 Dec 2011 07:08:51 -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 B1C7411E80E0 for ; Thu, 1 Dec 2011 07:08:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAIKX106HCzI1/2dsb2JhbABEhQOVU48agQmBBYFyAQEBAQMSCwYNBDcODAYBCA0EBAEBAwIGBgwLAQICAwFEBwEBBQQBBBMIARmHbZwQiW6Rf4EwiFozYwSaOoww X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="279990828" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Dec 2011 10:08:49 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Dec 2011 09:57:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 1 Dec 2011 16:08:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT) Thread-Index: AcywOdKGjB0zXL6yQgKp67hp4O0GkwAAELCg From: "Romascanu, Dan (Dan)" To: Cc: adrian@olddog.co.uk, Ralph Droms Subject: [MIB-DOCTORS] FW: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT) X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 15:08:52 -0000 TUlCIERvY3RvcnMsDQoNClBsZWFzZSBzZWUgdGhlIERJU0NVU1MgZW50ZXJlZCBieSBBZHJpYW4u IEJvdGggQmVydCBhbmQgbWUgcHJvdmlkZWQgY29tbWVudHMgb24gdGhlIGVhcmxpZXIgdmVyc2lv bnMgb2YgdGhlIE1JQiBtb2R1bGUgYnV0IGRpZCBub3QgaGF2ZSB0aW1lIGZvciBhIGZ1bGwgTUlC IHJldmlldy4gSSBzZW50IGEgZm9ybWFsIGNhbGwgZm9yIHZvbHVudGVlcnMgdG8gdGhpcyBsaXN0 IHdoZW4gdGhlIGRvY3VtZW50IHdhcyBzZW50IHRvIElFVEYgTEMgKG9uIDEwLzMwKSwgYnV0IHRo aXMgb25lIHdhcyBub3QgYW5zd2VyZWQuIFN1cmUgdGhlIElFVEYgbWVldGluZyBpbnRlcmZlcmVk LCBidXQgcmlnaHQgbm93IHRoZSBsYWNrIG9mIGEgTUlCIGRvY3RvcnMgcmV2aWV3IGJsb2NrcyB0 aGUgZG9jdW1lbnQsIGFuZCB0aGUgdGhlcmUgc2VlbSB0byBiZSBzb21lIHByb2JsZW1zIChvciBh dCBsZWFzdCBxdWVzdGlvbnMpIHJhaXNlZCBieSBBZHJpYW4uIA0KDQpQbGVhc2UganVtcCBpbiB0 byBoZWxwLiANCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KDQpEYW4NCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmll c2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNClNlbnQ6IFRo dXJzZGF5LCBEZWNlbWJlciAwMSwgMjAxMSA0OjU5IFBNDQpUbzogVGhlIElFU0cNCkNjOiBkcmFm dC1pZXRmLXRyaWxsLXJicmlkZ2UtbWliQHRvb2xzLmlldGYub3JnOyB0cmlsbC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcNClN1YmplY3Q6IEFkcmlhbiBGYXJyZWwncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtdHJpbGwtcmJyaWRnZS1taWItMDQ6ICh3aXRoRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KQWRy aWFuIEZhcnJlbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN CmRyYWZ0LWlldGYtdHJpbGwtcmJyaWRnZS1taWItMDQ6IERpc2N1c3MNCg0KV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs DQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNClBs ZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCkhhcyBhIE1JQiBkb2N0b3IgcmV2aWV3IGJlZW4gZG9uZSB5ZXQ/IEl0IHNl ZW1zIGxpa2Ugb25lIGlzIHN0aWxsDQpuZWVkZWQuIEkgYW0gbm90IGEgTUlCIGV4cGVydCwgYnV0 IEkgdGhpbmsgSSBzZWUgYSBudW1iZXIgb2YgaXNzdWVzLg0KDQotLS0NCg0KSSdtIGFmcmFpZCBT ZWFuJ3MgQ29tbWVudCBuZWVkcyB0byBiZSBjYXB0dXJlZCBpbiBhIERpc2N1c3MuIA0KDQpQbGVh c2UgcmVzb2x2ZSB0aGUgZG93bnJlZiB0byBSRkMgNDY2MyBlaXRoZXIgYnkgbW92aW5nIGl0IHRv IA0KSW5mb3JtYXRpdmUgKHdoaWNoIHNlZW1zIHJlYXNvbmFibGUpIG9yIGJ5IHJlaXNzdWluZyB0 aGUgbGFzdCBjYWxsLg0KDQotLS0NCg0KSSB3b3VsZCBsaWtlIGhlbHAgZnJvbSB0aGUgT1BTIEFE cyAoYW5kIE1JQiBEb2N0b3JzKSBvbiB0aGlzIHBvaW50Og0KDQpJdCBzZWVtcyB0byBtZSB0aGF0 IHNlY3Rpb24gNi43IG5lZWRzIGEgbmV3IGNvbmZvcm1hbmNlIHN0YXRlbWVudCB0bw0KYmUgYXBw bGllZCB0byBJU0lTLU1JQi4gVGhlIHRleHQgaW4gdGhlIHNlY3Rpb25hcHBlYXJzIHRvIGJlIGlu IHR3byANCnBhcnRzOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCi0gSW1wbGVtZW50YXRpb24gZ3VpZGFuY2UgKHdo YXQgdmFsdWUgdG8gcmV0dXJuIG9uIGEgR0VUIGZyb20gYSBUcmlsbA0KICBpbXBsZW1lbnRhdGlv bikNCg0KLSBJbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudHMgKHdoaWNoIHRhYmxlcy9vYmplY3Rz IHRvIGltcGxlbWVudCBvciBub3QNCiAgKGNvbmZvcm1hbmNlIHN0YXRlbWVudCkuDQoNCi0tLQ0K DQogICBSYnJpZGdlTmlja25hbWUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTg0KICAgICAgIERJU1BM QVktSElOVCAiZCINCiAgICAgICBTVEFUVVMgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICJUaGUgMTYtYml0IGlkZW50aWZpZXIgdXNlZCBpbiBUUklMTCBhcyBhbg0KICAg ICAgICAgICBhYmJyZXZpYXRpb24gZm9yIHRoZSBSQnJpZGdlJ3MgNDgtYml0IElTLUlTIFN5c3Rl bSBJRC4NCiAgICAgICAgICAgVGhlIHZhbHVlIDAgbWVhbnMgYSBuaWNrbmFtZSBpcyBub3Qgc3Bl Y2lmaWVkLCB0aGUgdmFsdWVzDQogICAgICAgICAgIDB4ZmZjbyB0aHJvdWdoIDB4ZmZmZSBhcmUg cmVzZXJ2ZWQgZm9yIGZ1dHVyZSBhbGxvY2F0aW9uLA0KICAgICAgICAgICBhbmQgdGhlIHZhbHVl IDB4ZmZmZiBpcyBwZXJtYW5lbnRseSByZXNlcnZlZC4iDQogICBTWU5UQVggVW5zaWduZWQzMiAo MC4uNjU0NzEpDQoNCkFzIHNwZWNpZmllZCwgaWYgdGhlIHJlc2VydmVkIHZhbHVlcyBhcmUgZXZl ciBhbGxvY2F0ZWQgZm9yIGFueSByZWFzb24NCnlvdSB3aWxsIGhhdmUgdG8gcmVzcGluIHRoZSBN SUIgbW9kdWxlLiBZb3UgcHJvYmFibHkgZG9uJ3Qgd2FudCB0byBoYXZlDQp0byBkbyB0aGF0LCBz byB3aHkgbm90IGFsbG93IDAuLjY1NTM0PyAoQnkgdGhlIHdheSwgaWYgMHhmZmZmIGlzIG91dHNp ZGUNCnRoZSBhdmFpbGFibGUgcmFuZ2UsIGl0IGlzIGJ5IGRlZmluaXRpb24gcGVybWFuZXRseSBy ZXNlcnZlZCwgc28gbWF5YmUgDQp5b3UgZG9uJ3QgbmVlZCB0byBzYXkgYW55dG5nIGFib3V0IGl0 LikNCg0KLS0tDQoNClRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgY29uZnVzaW9uIGFib3V0IGRlZmF1 bHRzLg0KDQpUaGVyZSBhcmUgYSBudW1iZXIgb2YgY2FzZXMgd2hlcmUgdGhlIERFU0NSSVBUSU9O IGNsYXVzZSBzdGF0ZXMgYQ0Kc3BlY2lmaWMgdmFsdWUgZm9yIHRoZSBkZWZhdWx0IG9mIGEgcmVh ZC13cml0ZSBvciBhIHJlYWQtY3JlYXRlIG9iamVjdC4NCkZvciBleGFtcGxlOg0KDQogICByYnJp ZGdlQmFzZUZvcndhcmREZWxheSBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFVuc2ln bmVkMzINCiAgICAgICBVTklUUyAgICAgICAic2Vjb25kcyINCiAgICAgICBNQVgtQUNDRVNTICBy ZWFkLXdyaXRlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICJNb2RpZmllZCBhZ2luZyB0aW1lIGZvciBhZGRyZXNzIGVudHJpZXMgYWZ0 ZXIgYW4gYXBwb2ludGVkDQogICAgICAgICAgIGZvcndhcmRlciBjaGFuZ2UuIFRoZSBkZWZhdWx0 IHZhbHVlIGlzIDE1Lg0KDQogICAgICAgICAgIFRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdCBNVVNU IGJlIHJldGFpbmVkIGFjcm9zcw0KICAgICAgICAgICByZWluaXRpYWxpemF0aW9ucyBvZiB0aGUg bWFuYWdlbWVudCBzeXN0ZW0uIg0KICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgIlJCcmlk Z2Ugc2VjdGlvbiA0LjguMiINCiAgICAgIDo6PSB7IHJicmlkZ2VCYXNlIDMgfQ0KDQpUaGlzIGFw cGVhcnMgdG8gYmUgbWlzc2luZyBhIERFRlZBTCBjbGF1c2UgdW5sZXNzIHlvdSBtZWFuIHNvbWV0 aGluZw0KZGlmZmVyZW50IGJ5ICJkZWZhdWx0Ii4gSWYgeW91IGFjdHVhbGx5IG1lYW4gdGhhdCB0 aGUgZGVmYXVsdCBpbiBhbg0KaW1wbGVtZW50YXRpb24gb2YgdGhlIHByb3RvY29sIGlzIDE1LCB0 aGVuIGl0IGlzIG5vdCBhcHByb3ByaWF0ZSB0bw0KbWVudGlvbiBpdCBoZXJlLg0KDQpJbiBvdGhl ciBvYmplY3RzIChyYnJpZGdlQmFzZVVuaU11bHRpcGF0aEVuYWJsZSwgICAgICAgICAgICAgICAg ICAgICAgDQpyYnJpZGdlQmFzZU11bHRpTXVsdGlwYXRoRW5hYmxlKSB5b3UgaGF2ZSAiVGhlIGRl ZmF1bHQgaXMNCmltcGxlbWVudGF0aW9uLXNwZWNpZmljLiIgSWYgdGhpcyBhcHBsaWVzIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgIA0KbWFuYWdlbWVudCBhZ2VudCB0aGVuIHlvdSBtaWdo dCBndWlkZSB0aGUgaW1wbGVtZW50ZXIuIElmIGl0IGFwcGxpZXMgdG8NCnRoZSBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgcHJvdG9jb2wsIHRoZW4gaXQgZG9lc24ndCByZWFsbHkgYmVsb25nIGhlcmUu DQoNCkkgc3VnZ2VzdCB5b3UgbG9vayBhdCBlYWNoIERFU0NSSVBUSU9OIGNsYXVzZSB3aGVyZSB0 aGVyZSBpcyBhIGRlZmF1bHQNCmRlc2NyaWJlZCBhbmQgd29yayBvdXQgd2hldGhlciB5b3Ugc2hv dWxkOg0KLSBhZGQgYSBERUZWQUwgY2xhdXNlDQotIHJlb21vdmUgdGhlIHR4dA0KLSBleHRlbmQg dGhlIHRleHQgdG8gZ2l2ZSBhZGRpdGlvbmFsIGFkdmljZSB0byB0aGUgaW1wbGVtZW50ZXIgb2Yg dGhlDQogIG1hbmFnZW1lbnQgYWdlbnQuDQoNCihCeSB0aGUgd2F5LCBzb21ldGltZXMgeW91IGhh dmUgaW5jbHVkZWQgdGhlIERFRlZBTCBqdXN0IGZpbmUuKQ0KDQotLS0NCg0KICAgcmJyaWRnZUJh c2VQb3J0SWZJbmRleCBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIEludGVyZmFjZUlu ZGV4DQoNClNob3VsZCB0aGlzIGJlIEludGVyZmFjZUluZGV4T3JaZXJvPyBXaGF0IHdvdWxkIGhh cHBlbiBpZiB0aGUgZW50cnkgd2FzDQpkZWxldGVkIGZyb20gSUYtTUlCPw0KDQotLS0NCg0KSSBl eHBlY3RlZCB0byBzZWUgc29tZSBtZW50aW9uIG9mIHJicmlkZ2VTbm9vcGluZ0FkZHJUeXBlIGlu IHRoZQ0KY29uZm9ybWFuY2Ugc3RhdGVtZW50IHRvIGxpbWl0IGl0cyBhcHBsaWNhYmlsaXR5IHRv IG9ubHkgYSBmZXcgb2YgdGhlDQphZGRyZXNzIHR5cGVzLg0KDQotLS0NCg0KICAgcmJyaWRnZUR0 cmVlQWN0aXZlVHJlZXMgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBVbnNpZ25lZDMy DQoNClNob3VsZG4ndCB0aGlzIG1vcmUgcHJvcGVybHkgYmUgYSBHYXVnZTMyPw0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCllvdSBzaG91bGQgbWFpbmx5IGJl IHNheWluZyAiTUlCIG1vZHVsZSIgd2hlcmUgeW91IHNheSAiTUlCIg0KDQotLS0NCg0KU29tZSBv ZiB0aGUgSU1QT1JUUyBjbGF1c2UgZW50cmllcyB1c2VmdWxseSBwb2ludCB0byB0aGUgUkZDcyBo b3VzaW5nDQp0aGUgaW1wb3J0ZWQgVENzLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgY291bGQg aW5jbHVkZSB0aGUgcmVmZXJlbmNlcw0KZm9yIGFsbCB0aGUgb3RoZXJzLg0KDQotLS0NCg0KSSBh cHByZWNpYXRlIHRoZSBtYW55IFJFRkVSRU5DRSBjbGF1c2VzLiBDb3VsZCBhZGQgb25lIHRvIA0K UmJyaWRnZU5pY2tuYW1lLg0KDQotLS0NCg0KICAgLS0gSW1wbGVtZW50YXRpb24gb2YgdGhlIHJi cmlkZ2VCYXNlIHN1YnRyZWUgaXMgbWFuZGF0b3J5IGZvciBhbGwNCiAgIC0tIFJCcmlkZ2VzLg0K DQpEb2VzIHRoaXMgbWVhbg0KLi4uIHRoYXQgYXJlIGNvbmZvcm1hbnQgdG8gdGhpcyBNSUIgbW9k dWxlDQpPciBhcmUgeW91IG1ha2luZyBhIHdpZGVyIHN0YXRlbWVudCBhYm91dCBSYnJpZGdlcz8N Cg0KLS0tDQoNClRoZSBERVNDUklQVElPTiBjbGF1c2Ugb2YgcmJyaWRnZVNub29waW5nUG9ydEFk ZHIgc2hvdWxkIGluZGljYXRlIHRoZQ0KKG9idmlvdXMpIGZhY3QgdGhhdCB0aGUgb2JqZWN0IGlz IGludGVycHJldHRlZCBpbiB0aGUgY29udGV4dCBvZiANCnJicmlkZ2VTbm9vcGluZ1BvcnRBZGRy VHlwZS4NCg0KLS0tDQoNCiAgIHJicmlkZ2VEdHJlZUFjdGl2ZVRyZWVzIE9CSkVDVC1UWVBFDQog ICAgICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25s eQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAiVGhlIHRvdGFsIG51bWJlciBvZiB0cmVlcyBiZWluZyBjb21wdXRlZCBieSBhbGwgUmJy aWRnZXMNCiAgICAgICAgICAgY2FtcHVzLiINCg0KTWlzc2luZyBzb21lIHRleHQgaW4gdGhlIERF U0NSSVBUSU9OIGNsYXVzZT8NCg0KDQo= From j.schoenwaelder@jacobs-university.de Thu Dec 1 07:11:36 2011 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 3B96F11E8198 for ; Thu, 1 Dec 2011 07:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=0.218, 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 YYe8nLLyf5zv for ; Thu, 1 Dec 2011 07:11:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6735511E80E0 for ; Thu, 1 Dec 2011 07:11:35 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A7F220CF8; Thu, 1 Dec 2011 16:11:34 +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 pvYdkl4T4V2l; Thu, 1 Dec 2011 16:11:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D60A920D0C; Thu, 1 Dec 2011 16:11:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 32C861BF0CC7; Thu, 1 Dec 2011 16:11:14 +0100 (CET) Date: Thu, 1 Dec 2011 16:11:13 +0100 From: Juergen Schoenwaelder To: Daniel Cohn Message-ID: <20111201151111.GB5947@elstar.local> Mail-Followup-To: Daniel Cohn , mib-doctors@ietf.org References: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> <20111201092815.GA4609@elstar.local> <44F4E579A764584EA9BDFD07D0CA081307362264@tlvmail1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307362264@tlvmail1> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs 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 Dec 2011 15:11:36 -0000 On Thu, Dec 01, 2011 at 03:34:19PM +0200, Daniel Cohn wrote: > Hi Juergen, thanks for your response. Let me clarify my question with an > example. Let's say I want to define a conceptual table, fooTable that is > indexed by interface. > > Then I can either: > > 1.- Reuse the ifIndex from the standard IF-MIB as follows: > > IMPORTS > ifIndex FROM IF-MIB > ... > > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry > > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {ifIndex} > > FooEntry > SEQUENCE { > object1 ... > object2 ... > } > > 2.- Define a new ad-hoc fooIfIndex object, just for this table, with the > same meaning as the standard ifIndex, i.e. the index of the interface to > which the table information applies, as follows: > > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry > > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {fooIfIndex} > > FooEntry > SEQUENCE { > fooIfIndex InterfaceIndex > object1 ... > object2 ... > } > > fooIfIndex OBJECT-TYPE > SYNTAX InterfaceIndex > DESCRIPTION "The index of the interface to which objects in > fooTable apply" > .... > > Take for example RFC 4836. Instead of defining a new ifMauIfIndex, > ifIndex could have been imported from IF-MIB. So my question is - is > there any difference? Is any of the approaches preferred? Generally, there is no difference. In the case of ifMauIfIndex there is a difference since ifMauIfIndex is read-only - so it is a separate object with its own OID one can retrieve. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From john.flick@hp.com Thu Dec 1 15:18:46 2011 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 A5E4921F8D66 for ; Thu, 1 Dec 2011 15:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 86o1xNPOXIXY for ; Thu, 1 Dec 2011 15:18:46 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB321F8C99 for ; Thu, 1 Dec 2011 15:18:45 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id DF03624033; Thu, 1 Dec 2011 23:18:44 +0000 (UTC) Received: from G2W0893.americas.hpqcorp.net (16.238.89.28) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 1 Dec 2011 23:17:01 +0000 Received: from GVW1342EXA.americas.hpqcorp.net ([16.236.29.16]) by G2W0893.americas.hpqcorp.net ([16.238.89.28]) with mapi; Thu, 1 Dec 2011 23:17:01 +0000 From: "Flick, John W" To: Juergen Schoenwaelder , Daniel Cohn Date: Thu, 1 Dec 2011 23:16:59 +0000 Thread-Topic: [MIB-DOCTORS] General question on MIBs Thread-Index: AcywO9wCy/dlPve8QdWQ4mfJ7KUQbQAQjvDg Message-ID: <481FFE8F0FB4C345AA384965C3D84FBB8B927C7266@GVW1342EXA.americas.hpqcorp.net> References: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1> <20111201092815.GA4609@elstar.local> <44F4E579A764584EA9BDFD07D0CA081307362264@tlvmail1> <20111201151111.GB5947@elstar.local> In-Reply-To: <20111201151111.GB5947@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mib-doctors@ietf.org" Subject: Re: [MIB-DOCTORS] General question on MIBs 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 Dec 2011 23:18:46 -0000 The specific case of ifMauIfIndex, it falls under the special case 1 in the= text that Juergen quoted earlier: (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; ifMauIfIndex was originally defined in RFC 1515, which was written to confo= rm to SMIv1, and was converted to SMIv2 for RFC 2239 (later updated by 2668= , 3535 and then 4836). In SMIv1, auxiliary objects were normally defined a= s read-only. The convention of defining them as not-accessible was introdu= ced with SMIv2. So ifMauIfIndex is read-only for historical reasons. If we were defining t= his from scratch today, we would just import ifIndex. John -----Original Message----- From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On= Behalf Of Juergen Schoenwaelder Sent: Thursday, December 01, 2011 7:11 AM To: Daniel Cohn Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs On Thu, Dec 01, 2011 at 03:34:19PM +0200, Daniel Cohn wrote: > Hi Juergen, thanks for your response. Let me clarify my question with an > example. Let's say I want to define a conceptual table, fooTable that is > indexed by interface. >=20 > Then I can either: >=20 > 1.- Reuse the ifIndex from the standard IF-MIB as follows: >=20 > IMPORTS > ifIndex FROM IF-MIB > ... >=20 > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry >=20 > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {ifIndex} >=20 > FooEntry > SEQUENCE { > object1 ... > object2 ... > } >=20 > 2.- Define a new ad-hoc fooIfIndex object, just for this table, with the > same meaning as the standard ifIndex, i.e. the index of the interface to > which the table information applies, as follows: >=20 > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry >=20 > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {fooIfIndex} >=20 > FooEntry > SEQUENCE { > fooIfIndex InterfaceIndex > object1 ... > object2 ... > } >=20 > fooIfIndex OBJECT-TYPE > SYNTAX InterfaceIndex > DESCRIPTION "The index of the interface to which objects in > fooTable apply" > .... >=20 > Take for example RFC 4836. Instead of defining a new ifMauIfIndex, > ifIndex could have been imported from IF-MIB. So my question is - is > there any difference? Is any of the approaches preferred? Generally, there is no difference. In the case of ifMauIfIndex there is a difference since ifMauIfIndex is read-only - so it is a separate object with its own OID one can retrieve. /js --=20 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 bertietf@bwijnen.net Fri Dec 2 05:25:03 2011 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 3BE1821F971B for ; Fri, 2 Dec 2011 05:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foWAV6J33uxQ for ; Fri, 2 Dec 2011 05:25:02 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 183F421F96CA for ; Fri, 2 Dec 2011 05:25:01 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RWT6n-0001bT-UY for mib-doctors@ietf.org; Fri, 02 Dec 2011 14:25:00 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest148.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RWT6n-0004JR-OK for mib-doctors@ietf.org; Fri, 02 Dec 2011 14:24:57 +0100 Message-ID: <4ED8D1A9.5080300@bwijnen.net> Date: Fri, 02 Dec 2011 14:24:57 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mib-doctors@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; 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: 86ab03e524994f79ca2c75a176445dd4faaa70e18274822e1d6f654376337982 Subject: [MIB-DOCTORS] Fwd: [802.1 - 8588] Q-2011 MIB files 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, 02 Dec 2011 13:25:03 -0000 FYI -------- Original Message -------- Subject: [802.1 - 8588] Q-2011 MIB files Date: Fri, 2 Dec 2011 13:19:10 +0000 From: Tony Jeffree Reply-To: tony@jeffree.co.uk To: STDS-802-1-L@LISTSERV.IEEE.ORG Ballot due Dec. 1: P802.1Qbg/D1.9 For particulars see www.ieee802.org/1/email-pages/ballots.html 802.1 list help: www.ieee802.org/1/email-pages/zuwz1011.html List archives (access-controlled) by date: www.ieee802.org/1/private/email2/mail1.html ----- I have posted the text files of the MIB modules from IEEE Std 802.1Q-2011 on the website here: http://www.ieee802.org/1/files/public/MIBs/ Look for files with a "last modified" date of 2nd December 2011. Regards, Tony === Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG IEEE. Fostering technological innovation and excellence for the benefit of humanity. From DanielC@orckit.com Sun Dec 4 10:31:17 2011 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 1E58A21F86EE for ; Sun, 4 Dec 2011 10:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9NBb7a1+ftwA for ; Sun, 4 Dec 2011 10:31:16 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4021F86EC for ; Sun, 4 Dec 2011 10:31:15 -0800 (PST) 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: Sun, 4 Dec 2011 20:34:19 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130736245D@tlvmail1> In-Reply-To: <481FFE8F0FB4C345AA384965C3D84FBB8B927C7266@GVW1342EXA.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] General question on MIBs Thread-Index: AcywO9wCy/dlPve8QdWQ4mfJ7KUQbQAQjvDgAINoy5A= References: <44F4E579A764584EA9BDFD07D0CA0813073621D6@tlvmail1><20111201092815.GA4609@elstar.local><44F4E579A764584EA9BDFD07D0CA081307362264@tlvmail1> <20111201151111.GB5947@elstar.local> <481FFE8F0FB4C345AA384965C3D84FBB8B927C7266@GVW1342EXA.americas.hpqcorp.net> From: "Daniel Cohn" To: "Flick, John W" , "Juergen Schoenwaelder" X-Mailman-Approved-At: Mon, 05 Dec 2011 08:01:27 -0800 Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs 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: Sun, 04 Dec 2011 18:31:17 -0000 Thanks a lot Juergen and John, this completely clarifies the point. Regards, Daniel -----Original Message----- From: Flick, John W [mailto:john.flick@hp.com]=20 Sent: Friday, December 02, 2011 1:17 AM To: Juergen Schoenwaelder; Daniel Cohn Cc: mib-doctors@ietf.org Subject: RE: [MIB-DOCTORS] General question on MIBs The specific case of ifMauIfIndex, it falls under the special case 1 in the text that Juergen quoted earlier: (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; ifMauIfIndex was originally defined in RFC 1515, which was written to conform to SMIv1, and was converted to SMIv2 for RFC 2239 (later updated by 2668, 3535 and then 4836). In SMIv1, auxiliary objects were normally defined as read-only. The convention of defining them as not-accessible was introduced with SMIv2. So ifMauIfIndex is read-only for historical reasons. If we were defining this from scratch today, we would just import ifIndex. John -----Original Message----- From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, December 01, 2011 7:11 AM To: Daniel Cohn Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] General question on MIBs On Thu, Dec 01, 2011 at 03:34:19PM +0200, Daniel Cohn wrote: > Hi Juergen, thanks for your response. Let me clarify my question with an > example. Let's say I want to define a conceptual table, fooTable that is > indexed by interface. >=20 > Then I can either: >=20 > 1.- Reuse the ifIndex from the standard IF-MIB as follows: >=20 > IMPORTS > ifIndex FROM IF-MIB > ... >=20 > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry >=20 > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {ifIndex} >=20 > FooEntry > SEQUENCE { > object1 ... > object2 ... > } >=20 > 2.- Define a new ad-hoc fooIfIndex object, just for this table, with the > same meaning as the standard ifIndex, i.e. the index of the interface to > which the table information applies, as follows: >=20 > fooTable OBJECT-TYPE > SYNTAX SEQUENCE OF FooEntry >=20 > fooEntry OBJECT-TYPE > SYNTAX FooEntry > INDEX {fooIfIndex} >=20 > FooEntry > SEQUENCE { > fooIfIndex InterfaceIndex > object1 ... > object2 ... > } >=20 > fooIfIndex OBJECT-TYPE > SYNTAX InterfaceIndex > DESCRIPTION "The index of the interface to which objects in > fooTable apply" > .... >=20 > Take for example RFC 4836. Instead of defining a new ifMauIfIndex, > ifIndex could have been imported from IF-MIB. So my question is - is > there any difference? Is any of the approaches preferred? Generally, there is no difference. In the case of ifMauIfIndex there is a difference since ifMauIfIndex is read-only - so it is a separate object with its own OID one can retrieve. /js --=20 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 dromasca@avaya.com Fri Dec 9 09:28:22 2011 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 5613121F8488; Fri, 9 Dec 2011 09:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 u4A92uU-lcH3; Fri, 9 Dec 2011 09:28:21 -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 98CC221F843B; Fri, 9 Dec 2011 09:28:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAI1E4k7GmAcF/2dsb2JhbABDhQaZUYsJgRiBBYFyAQEBAQMSEQ0EUQYBCA0IBQIGBgwLAQICAwEfJQcBBgQBBAESCBqiJolukSyBNIkoM2MEmlyEfoc+ X-IronPort-AV: E=Sophos;i="4.71,327,1320642000"; d="scan'208";a="281240947" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Dec 2011 12:28:11 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Dec 2011 12:25:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 9 Dec 2011 18:28:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the December 15, 2011 IESG Teleconference Thread-Index: Acy1/oQ75xzN17rQRGC+iHR1+jsOMgAmRpbg From: "Romascanu, Dan (Dan)" To: , , , "IETF DNS Directorate" , "YANG Doctors" Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the December 15, 2011 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 Dec 2011 17:28:22 -0000 DQpQbGVhc2UgZmluZCBiZWxvdyB0aGUgYWdlbmRhIG9mIHRoZSBJRVNHIHRlbGVjaGF0IG9uIDEy LzE1LiBQbGVhc2Ugc2VuZCB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNvbmNlcm5zIGJl Zm9yZSAxMi8xNCBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2ctYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFU0cgU2VjcmV0YXJ5DQoN Cg0KMi4gUHJvdG9jb2wgQWN0aW9ucw0KMi4xIFdHIFN1Ym1pc3Npb25zDQoyLjEuMSBOZXcgSXRl bXMNCg0KICBvIGRyYWZ0LWlldGYtbDN2cG4tb3NwZnYzLXBlY2UtMTANCiAgICBPU1BGdjMgYXMg YSBQRS1DRSByb3V0aW5nIHByb3RvY29sIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBC ZW4gTml2ZW4tSmVua2lucyAoYmVuQG5pdmVuLWplbmtpbnMuY28udWspIGlzIHRoZSBEb2N1bWVu dA0KICAgIFNoZXBoZXJkDQogICAgVG9rZW46IFN0ZXdhcnQgQnJ5YW50DQoNCiAgbyBkcmFmdC1p ZXRmLWdlb3ByaXYtZGVyZWYtcHJvdG9jb2wtMDQNCiAgICBBIExvY2F0aW9uIERlcmVmZXJlbmNp bmcgUHJvdG9jb2wgVXNpbmcgSEVMRCAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogUmlj aGFyZCBCYXJuZXMgKHJiYXJuZXNAYmJuLmNvbSkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0K ICAgIFRva2VuOiBSb2JlcnQgU3BhcmtzDQoNCiAgbyBkcmFmdC1pZXRmLWdlb3ByaXYtcG9saWN5 LXVyaS0wNA0KICAgIExvY2F0aW9uIENvbmZpZ3VyYXRpb24gRXh0ZW5zaW9ucyBmb3IgUG9saWN5 IE1hbmFnZW1lbnQgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogQWxpc3NhIENv b3BlciAoYWNvb3BlckBjZHQub3JnKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9r ZW46IFJvYmVydCBTcGFya3MNCg0KICBvIGRyYWZ0LWlldGYtdjZvcHMtaGFwcHktZXllYmFsbHMt MDYNCiAgICBIYXBweSBFeWViYWxsczogU3VjY2VzcyB3aXRoIER1YWwtU3RhY2sgSG9zdHMgKFBy b3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6IEZyZWQgQmFrZXIgKGZyZWQuYmFrZXJAY2lzY28u Y29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJvbiBCb25pY2ENCg0K ICBvIGRyYWZ0LWlldGYtc2ltcGxlLW1zcnAtY2VtYS0wMw0KICAgIENvbm5lY3Rpb24gRXN0YWJs aXNobWVudCBmb3IgTWVkaWEgQW5jaG9yaW5nIChDRU1BKSBmb3IgdGhlIE1lc3NhZ2UNCiAgICBT ZXNzaW9uIFJlbGF5IFByb3RvY29sIChNU1JQKSAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90 ZTogSGlzaGFtIEtoYXJ0YWJpbCAoaGlzaGFtLmtoYXJ0YWJpbEBnbWFpbC5jb20pIGlzIHRoZSBk b2N1bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBHb256YWxvIENhbWFyaWxsbw0KDQog IG8gZHJhZnQtaWV0Zi10Y3BtLXJmYzM3ODItYmlzLTA0DQogICAgVGhlIE5ld1Jlbm8gTW9kaWZp Y2F0aW9uIHRvIFRDUCdzIEZhc3QgUmVjb3ZlcnkgQWxnb3JpdGhtIChQcm9wb3NlZA0KICAgIFN0 YW5kYXJkKQ0KICAgIE5vdGU6IERhdmlkIEJvcm1hbiAoZGF2aWQuYm9ybWFuQHdpbmRyaXZlci5j b20pIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBXZXNsZXkgRWRk eQ0KDQoyLjEuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoNCjIuMiBJbmRpdmlkdWFsIFN1 Ym1pc3Npb25zDQoyLjIuMSBOZXcgSXRlbXMNCg0KICBOT05FDQoNCjIuMi4yIFJldHVybmluZyBJ dGVtcw0KDQogIG8gZHJhZnQtd2VpbC1zaGFyZWQtdHJhbnNpdGlvbi1zcGFjZS1yZXF1ZXN0LTEw DQogICAgSUFOQSBSZXNlcnZlZCBJUHY0IFByZWZpeCBmb3IgU2hhcmVkIENHTiBTcGFjZSAoQkNQ KQ0KICAgIFRva2VuOiBSb24gQm9uaWNhDQogICAgV2FzIGRlZmVycmVkIGJ5IFBldGVyIFNhaW50 LUFuZHJlIG9uIDIwMTEtMTItMDENCg0KMy4gRG9jdW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1p c3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1pbXBh aXJtZW50cy0wOA0KICAgIEEgRnJhbWV3b3JrIGZvciB0aGUgQ29udHJvbCBvZiBXYXZlbGVuZ3Ro IFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MNCiAgICAoV1NPTikgd2l0aCBJbXBhaXJtZW50cyAo SW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBEZWJvcmFoIEJydW5nYXJkIChkYnJ1bmdhcmRAYXR0 LmNvbSkgaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkLg0KICAgIFRva2VuOiBBZHJpYW4gRmFycmVs DQoNCiAgbyBkcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDcNCiAgICBQcm9ibGVt IFN0YXRlbWVudCBvZiBQZWVyLXRvLVBlZXIgU3RyZWFtaW5nIFByb3RvY29sIChQUFNQKQ0KICAg IChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IE1hcnRpbiBTdGllbWVybGluZyAobWFydGluLnN0 aWVtZXJsaW5nQG5lY2xhYi5ldSkgaXMgdGhlDQogICAgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAg VG9rZW46IFdlc2xleSBFZGR5DQoNCjMuMS4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0K My4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWdlcmhhcmRzLXN5c2xvZy1wbGFpbi10Y3AtMTINCiAgICBUcmFuc21pc3Npb24gb2Yg U3lzbG9nIE1lc3NhZ2VzIG92ZXIgVENQIChJbmZvcm1hdGlvbmFsKQ0KICAgIFRva2VuOiBEYW4g Um9tYXNjYW51DQoNCiAgbyBkcmFmdC1vcmVpcmRhbi1tb2R5LWJvdC1yZW1lZGlhdGlvbi0xOA0K ICAgIFJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIFJlbWVkaWF0aW9uIG9mIEJvdHMgaW4gSVNQIE5l dHdvcmtzDQogICAgKEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46IFN0ZXBoZW4gRmFycmVsbA0K ICAgIFdhcyBkZWZlcnJlZCBieSBSb24gQm9uaWNhIG9uIDIwMTEtMTEtMzANCg0KMy4yLjIgUmV0 dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMgSVJURiBhbmQgSW5kZXBlbmRlbnQgU3VibWlz c2lvbiBTdHJlYW0gRG9jdW1lbnRzDQozLjMuMSBOZXcgSXRlbXMNCg0KICBOT05FDQoNCjMuMy4y IFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zLjMgRm9yIEFjdGlvbg0KDQogIG8gZHJh ZnQtbWNrZW56aWUtYXJwYW5ldC1ob3N0LWhvc3QtcHJvdG9jb2wtMDENCiAgICBIb3N0L0hvc3Qg UHJvdG9jb2wgZm9yIHRoZSBBUlBBIE5ldHdvcmsgKEhpc3RvcmljKQ0KICAgIE5vdGU6IElTRSBk b2N1bWVudA0KICAgIFRva2VuOiBSdXNzIEhvdXNsZXkNCg0KNC4gV29ya2luZyBHcm91cCBBY3Rp b25zDQo0LjEgV0cgQ3JlYXRpb24NCjQuMS4xIFByb3Bvc2VkIGZvciBJRVRGIFJldmlldw0KDQog IE5PTkUNCg0KNC4xLjIgUHJvcG9zZWQgZm9yIEFwcHJvdmFsDQoNCiAgTk9ORQ0KDQo0LjIgV0cg UmVjaGFydGVyaW5nDQo0LjIuMSBVbmRlciBFdmFsdWF0aW9uIGZvciBJRVRGIFJldmlldw0KDQog IE5PTkUNCg0KNC4yLjIgUHJvcG9zZWQgZm9yIEFwcHJvdmFsDQoNCiAgTk9ORQ0KDQoNCg==