From dromasca@avaya.com Sun Jan 1 03:22: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 1483F21F847C; Sun, 1 Jan 2012 03:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=0.342, 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 adz46mvchast; Sun, 1 Jan 2012 03:22:47 -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 534DA21F8482; Sun, 1 Jan 2012 03:22:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAEBBAE/GmAcF/2dsb2JhbABCggWDCpsrixeBBIEFgXIBAQEBAxIRDQQ+EwYBCA0IBQIGBgwLAQICAwEfJQcBBgQBBAESCBqhCIlvkHaBL4lKM2MEmnGFAIdG X-IronPort-AV: E=Sophos;i="4.71,440,1320642000"; d="scan'208";a="284270913" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jan 2012 06:22:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jan 2012 06:18:50 -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: Sun, 1 Jan 2012 12:22:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 5, 2012 IESG Teleconference Thread-Index: AczGgq+j0FT9W6rdTy+pz+9lo3ISEQB9JbcQ From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the January 5, 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: Sun, 01 Jan 2012 11:22:49 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS81IElFU0cg dGVsZWNoYXQuIFBsZWFzZSBzZW5kIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBhbmQgY29uY2Vy bnMgYWJvdXQgdGhlIGRvY3VtZW50IGFuZCBXRyBjaGFydGVycyBicm91Z2h0IHVwIGZvciB0aGUg YXBwcm92YWwgb2YgdGhlICBJRVNHIGJlZm9yZSAxLzQgQ09CLiANCg0KVGhhbmtzIGFuZCBSZWdh cmRzLA0KDQpEYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNn LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBJRVNHIFNlY3JldGFyeQ0KDQoNCjIuIFByb3RvY29sIEFjdGlvbnMNCjIuMSBXRyBTdWJt aXNzaW9ucw0KMi4xLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXNpZXZlLWluY2x1ZGUt MTMNCiAgICBTaWV2ZSBFbWFpbCBGaWx0ZXJpbmc6IEluY2x1ZGUgRXh0ZW5zaW9uIChQcm9wb3Nl ZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXJyeSBMZWliYSAoYmFycnlsZWliYUBjb21wdXRlci5v cmcpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBQZXRlIFJlc25p Y2sNCg0KICBvIGRyYWZ0LWlldGYtc29mdHdpcmUtZ2F0ZXdheS1pbml0LWRzLWxpdGUtMDYNCiAg ICBHYXRld2F5IEluaXRpYXRlZCBEdWFsLVN0YWNrIExpdGUgRGVwbG95bWVudCAoUHJvcG9zZWQg U3RhbmRhcmQpDQogICAgTm90ZTogWW9uZyBDdWkgKGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuKSBp cyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBk cmFmdC1pZXRmLTZsb3dwYW4tbmQtMTgNCiAgICBOZWlnaGJvciBEaXNjb3ZlcnkgT3B0aW1pemF0 aW9uIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzDQogICAgKDZMb1dQQU4pIChQcm9w b3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBDYXJzdGVuIEJvcm1hbm4gKGNhYm9AdHppLm9yZykg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8g ZHJhZnQtaWV0Zi02bWFuLWV4dGhkci0wNQ0KICAgIEFuIHVuaWZvcm0gZm9ybWF0IGZvciBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlhbiBI YWJlcm1hbiAoYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0KSBpcyB0aGUgZG9jdW1lbnQNCiAgICBz aGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJhZnQtaWV0Zi1zdG9ybS1y ZGRwLXJlZ2lzdHJpZXMtMDENCiAgICBJQU5BIFJlZ2lzdHJpZXMgZm9yIHRoZSBSRERQIChSZW1v dGUgRGlyZWN0IERhdGEgUGxhY2VtZW50KQ0KICAgIFByb3RvY29scyAoUHJvcG9zZWQgU3RhbmRh cmQpDQogICAgTm90ZTogRGF2aWQgQmxhY2sgKGRhdmlkLmJsYWNrQGVtYy5jb20pIGlzIHRoZSBk b2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogRGF2aWQgSGFycmluZ3Rvbg0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtZGhjLXZwbi1vcHRpb24tMTQNCiAgICBW aXJ0dWFsIFN1Ym5ldCBTZWxlY3Rpb24gT3B0aW9ucyBmb3IgREhDUHY0IGFuZCBESENQdjYgKFBy b3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogSm9obiBKYXNvbiBCcnpvem93c2tpIChq b2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20pIGlzDQogICAgdGhlIGRvY3VtZW50IHNo ZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8gZHJhZnQtaWV0Zi1pcHBtLW1l dHJpY3Rlc3QtMDUNCiAgICBJUFBNIHN0YW5kYXJkIGFkdmFuY2VtZW50IHRlc3RpbmcgKEJDUCkN CiAgICBOb3RlOiBIZW5rIFVpanRlcndhYWwgKGhlbmtAdWlqdGVyd2FhbC5ubCkgaXMgdGhlIGRv Y3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBXZXNsZXkgRWRkeQ0KDQoyLjIgSW5kaXZpZHVh bCBTdWJtaXNzaW9ucw0KMi4yLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1kYWJvby13ZWJkYXYt c3luYy0wNg0KICAgIENvbGxlY3Rpb24gU3luY2hyb25pemF0aW9uIGZvciBXZWJEQVYgKFByb3Bv c2VkIFN0YW5kYXJkKQ0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQogIG8gZHJhZnQt Z3JlZ29yaW8tdXJpdGVtcGxhdGUtMDcNCiAgICBVUkkgVGVtcGxhdGUgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IE11cnJheSBLdWNoZXJhd3kgPG1za0BjbG91ZG1hcmsuY29tPiBpcyB0 aGUgRG9jdW1lbnQNCiAgICBTaGVwaGVyZC4NCiAgICBUb2tlbjogUGV0ZXIgU2FpbnQtQW5kcmUN Cg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLiBEb2N1bWVudCBBY3Rpb25z DQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1z aXBjbGYtcHJvYmxlbS1zdGF0ZW1lbnQtMDkNCiAgICBUaGUgQ29tbW9uIExvZyBGb3JtYXQgKENM RikgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCiAgICAoU0lQKTogRnJhbWV3 b3JrIGFuZCBEYXRhIE1vZGVsIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IFBldGVyIE11c2dy YXZlIChtdXNncmF2ZXBqQGdtYWlsLmNvbSkgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQu DQogICAgVG9rZW46IFJvYmVydCBTcGFya3MNCg0KMy4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAg Tk9ORQ0KDQozLjEuMyBGb3IgQWN0aW9uDQoNCiAgbyBkcmFmdC1pZXRmLXJ0Z3dnLWxmYS1hcHBs aWNhYmlsaXR5LTA0DQogICAgTEZBIGFwcGxpY2FiaWxpdHkgaW4gU1AgbmV0d29ya3MgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogQWx2YXJvIFJldGFuYSAoYWx2YXJvLnJldGFuYUBocC5jb20p IGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0K My4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWFya2tvLWlwdjYtb25seS1leHBlcmllbmNlLTA0DQogICAgRXhwZXJpZW5jZXMgZnJv bSBhbiBJUHY2LU9ubHkgTmV0d29yayAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUm9uIEJv bmljYQ0KDQogIG8gZHJhZnQtb2h5ZS1jYW5vbmljYWwtbGluay1yZWxhdGlvbi0wNA0KICAgIFRo ZSBDYW5vbmljYWwgTGluayBSZWxhdGlvbiAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUGV0 ZXIgU2FpbnQtQW5kcmUNCg0KICBvIGRyYWZ0LWt1Y2hlcmF3eS1ka2ltLWF0cHMtMTMNCiAgICBE S0lNIEF1dGhvcml6ZWQgVGhpcmQtUGFydHkgU2lnbmVycyAoRXhwZXJpbWVudGFsKQ0KICAgIE5v dGU6IEJhcnJ5IExlaWJhIChiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZykgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAgbyBkcmFmdC1hbXVu ZHNlbi1pdGVtLWFuZC1jb2xsZWN0aW9uLWxpbmstcmVsYXRpb25zLTA0DQogICAgVGhlIEl0ZW0g YW5kIENvbGxlY3Rpb24gTGluayBSZWxhdGlvbnMgKEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46 IFBldGVyIFNhaW50LUFuZHJlDQoNCiAgbyBkcmFmdC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJl bGF0aW9uLTAwDQogICAgVGhlICdkaXNjbG9zdXJlJyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYgTGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2 Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQozLjIuMiBSZXR1cm5pbmcgSXRlbXMN Cg0KICBOT05FDQoNCjMuMyBJUlRGIGFuZCBJbmRlcGVuZGVudCBTdWJtaXNzaW9uIFN0cmVhbSBE b2N1bWVudHMNCjMuMy4xIE5ldyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zLjIgUmV0dXJuaW5nIEl0 ZW1zDQoNCiAgTk9ORQ0KDQo0LiBXb3JraW5nIEdyb3VwIEFjdGlvbnMNCjQuMSBXRyBDcmVhdGlv bg0KNC4xLjEgUHJvcG9zZWQgZm9yIElFVEYgUmV2aWV3DQoNCiAgTk9ORQ0KDQo0LjEuMiBQcm9w b3NlZCBmb3IgQXBwcm92YWwNCg0KICBvIFNQRiBVcGRhdGUgKHNwZmJpcykNCiAgICBUb2tlbjog UGV0ZQ0KDQo0LjIgV0cgUmVjaGFydGVyaW5nDQo0LjIuMSBVbmRlciBFdmFsdWF0aW9uIGZvciBJ RVRGIFJldmlldw0KDQogIG8gRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCAoZG1tKQ0K ICAgIFRva2VuOiBKYXJpDQoNCiAgbyBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKGxp c3ApDQogICAgVG9rZW46IEphcmkNCg0KICBvIFJvdXRpbmcgQXJlYSBXb3JraW5nIEdyb3VwIChy dGd3ZykNCiAgICBUb2tlbjogU3Rld2FydA0KDQogIG8gRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5k IEV4dGVuc2lvbnMgKGRpbWUpDQogICAgVG9rZW46IERhbg0KDQoNCg== From dromasca@avaya.com Fri Jan 13 02:57:43 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691FD21F8608; Fri, 13 Jan 2012 02:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 J5dvGifsDtjt; Fri, 13 Jan 2012 02:57:42 -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 5F19A21F85F1; Fri, 13 Jan 2012 02:57:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOwNEE+HCzI1/2dsb2JhbABChRCnDXuBBYFyAQEBAQMSEQ0EPhMGAQgNCAUCBgYMCwECAgMBRAcBBgQBBAESCBqjZYlykTgEgS+JWDNjBJsFjE0 X-IronPort-AV: E=Sophos;i="4.71,503,1320642000"; d="scan'208";a="286058423" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2012 05:57:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2012 05:44:17 -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, 13 Jan 2012 11:57:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference Thread-Index: AczRfyPKxMIpSIkRRyG8ppVDEejZswAYbF3A From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the January 19, 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, 13 Jan 2012 10:57:43 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS8xOSBJRVNH IHRlbGVjaGF0LiBQbGVhc2Ugc2VuZCB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNvbmNl cm5zIGFib3V0IHRoZSBkb2N1bWVudHMgYW5kIGNoYXJ0ZXIgYnJvdWdodCB1cCBmb3IgV0cgYXBw cm92YWwgYmVmb3JlIFdlZG5lc2RheSAxLzE4IENPQi4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SUVTRyBTZWNyZXRhcnkNCg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoyLjEgV0cgU3VibWlzc2lv bnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1tYXJmLXJlZGFjdGlvbi0wNA0K ICAgIFJlZGFjdGlvbiBvZiBQb3RlbnRpYWxseSBTZW5zaXRpdmUgRGF0YSBmcm9tIE1haWwgQWJ1 c2UgUmVwb3J0cw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBUb2tlbjogUGV0ZSBSZXNu aWNrDQoNCiAgbyBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0LTA5DQogICAgQXV0 aGVudGljYXRpb24gRmFpbHVyZSBSZXBvcnRpbmcgdXNpbmcgdGhlIEFidXNlIFJlcG9ydCBGb3Jt YXQNCiAgICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGUgUmVzbmljaw0KDQog IG8gZHJhZnQtaWV0Zi1uZXRleHQtcmFkaXVzLXBtaXA2LTA2DQogICAgUkFESVVTIFN1cHBvcnQg Zm9yIFByb3h5IE1vYmlsZSBJUHY2IChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXNh dmFyYWogUGF0aWwgKEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20pIGlzIHRoZSBkb2N1bWVudA0K ICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLW5l dGV4dC1idWxrLXJlLXJlZ2lzdHJhdGlvbi0xMA0KICAgIEJ1bGsgQmluZGluZyBVcGRhdGUgU3Vw cG9ydCBmb3IgUHJveHkgTW9iaWxlIElQdjYgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAg Tm90ZTogQmFzYXZhcmFqIFBhdGlsIChCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tKSBpcyB0aGUg ZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJh ZnQtaWV0Zi1vc3BmLW11bHRpLWluc3RhbmNlLTA3DQogICAgT1NQRiBNdWx0aS1JbnN0YW5jZSBF eHRlbnNpb25zIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBNYW5hdiBCaGF0aWEgKG1h bmF2LmJoYXRpYUBhbGNhdGVsLWx1Y2VudC5jb20pIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtaWV0Zi1raXR0ZW4t c2FzbC1zYW1sLTA4DQogICAgQSBTQVNMIGFuZCBHU1MtQVBJIE1lY2hhbmlzbSBmb3IgU0FNTCAo UHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogVGhlIGRvY3VtZW50IHNoZXBoZXJkIGZvciB0 aGlzIGRvY3VtZW50IGlzIFNoYXduIEVtZXJ5DQogICAgKHNoYXduLmVtZXJ5QG9yYWNsZS5jb20p Lg0KICAgIFRva2VuOiBTdGVwaGVuIEZhcnJlbGwNCg0KICBvIGRyYWZ0LWlldGYtaWRyLWZzbS1z dWJjb2RlLTAyDQogICAgU3ViY29kZXMgZm9yIEJHUCBGaW5pdGUgU3RhdGUgTWFjaGluZSBFcnJv ciAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogU3VzYW4gSGFyZXMgaXMgdGhlIGRvY3Vt ZW50IHNoZXBoZXJkDQogICAgKFN1c2FuLkhhcmVzQGh1YXdlaS5jb20gb3Igc2hhcmVzQG5kemgu Y29tKS4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1y ZmM2MDQ2LWJpcy0wNQ0KICAgIFRyYW5zcG9ydCBvZiBSZWFsLXRpbWUgSW50ZXItbmV0d29yayBE ZWZlbnNlIChSSUQpIE1lc3NhZ2VzIG92ZXINCiAgICBIVFRQLyBUTFMgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IEthdGhsZWVuIE1vcmlhcnR5IChrYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tKSBpcyB0aGUgZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogU2VhbiBUdXJu ZXINCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1yZmM2MDQ1LWJpcy0wNQ0KICAgIFJlYWwtdGltZSBJ bnRlci1uZXR3b3JrIERlZmVuc2UgKFJJRCkgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6 IEJyaWFuIFRyYW1tZWxsICh0cmFtbWVsbEB0aWsuZWUuZXRoei5jaCkgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCjIuMS4yIFJldHVybmlu ZyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMNCjIuMi4xIE5l dyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQoz LiBEb2N1bWVudCBBY3Rpb25zDQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0K DQogIG8gZHJhZnQtaWV0Zi1saXNwLW1hcC12ZXJzaW9uaW5nLTA2DQogICAgTElTUCBNYXAtVmVy c2lvbmluZyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFRlcnJ5IE1hbmRlcnNvbiAodGVycnku bWFuZGVyc29uQGljYW5uLm9yZykgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQuDQogICAg VG9rZW46IEphcmkgQXJra28NCiAgICBXYXMgZGVmZXJyZWQgYnkgQWRyaWFuIEZhcnJlbCBvbiAy MDExLTA5LTIxDQoNCjMuMS4yIFJldHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1saXNw LTE5DQogICAgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKSAoRXhwZXJpbWVu dGFsKQ0KICAgIE5vdGU6IEpvZWwgSGFscGVybiAoam1oQGpvZWxoYWxwZXJuLmNvbSkgaXMgdGhl IGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1p ZXRmLWxpc3AtbXVsdGljYXN0LTEyDQogICAgTElTUCBmb3IgTXVsdGljYXN0IEVudmlyb25tZW50 cyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFdhc3NpbSBIYWRkYWQgPHdhc3NpbS5oYWRkYWRA ZXJpY3Nzb24uY29tPiBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjog SmFyaSBBcmtrbw0KDQozLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucyBWaWEgQUQNCjMuMi4xIE5l dyBJdGVtcw0KDQogIG8gZHJhZnQta29tcGVsbGEtbDJ2cG4tbDJ2cG4tMDgNCiAgICBMYXllciAy IFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrcyBVc2luZyBCR1AgZm9yIEF1dG8tZGlzY292ZXJ5IGFu ZA0KICAgIFNpZ25hbGluZyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBSb3NzIENhbGxvbiAo cmNhbGxvbkBqdW5pcGVyLm5ldCkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2Vu OiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtYXNoLWdjYWMtYWxnb3JpdGhtLXNwZWMtMDMN CiAgICBHZW5lcmljIENvbm5lY3Rpb24gQWRtaXNzaW9uIENvbnRyb2wgKEdDQUMpIEFsZ29yaXRo bSBTcGVjaWZpY2F0aW9uDQogICAgZm9yIElQL01QTFMgTmV0d29ya3MgKEV4cGVyaW1lbnRhbCkN CiAgICBOb3RlOiBZb3VuZyBMZWUgKGxlZXlvdW5nQGh1YXdlaS5jb20pIGlzIHRoZSBkb2N1bWVu dCBzaGVwaGVyZC4NCiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtamlhbmct YTYtdG8taGlzdG9yaWMtMDANCiAgICBNb3ZpbmcgQTYgdG8gSGlzdG9yaWMgU3RhdHVzIChJbmZv cm1hdGlvbmFsKQ0KICAgIE5vdGU6IFJhbHBoIERyb21zIChyZHJvbXNAY2lzY28uY29tKSBpcyB0 aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBkcmFm dC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJlbGF0aW9uLTAyDQogICAgVGhlICdkaXNjbG9zdXJl JyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYg TGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRy ZQ0KICAgIFdhcyBkZWZlcnJlZCBieSBQZXRlciBTYWludC1BbmRyZSBvbiAyMDEyLTAxLTAzDQoN CjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zIElSVEYgYW5kIEluZGVwZW5k ZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEgTmV3IEl0ZW1zDQoNCiAgTk9O RQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoNCjQuIFdvcmtpbmcgR3JvdXAg QWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3NlZCBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIE5PTkUNCg0KNC4y IFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlvbiBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9J RCBTZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCiAgbyBEaWFt ZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoZGltZSkNCiAgICBUb2tlbjogRGFuDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKiBQ bGVhc2Ugc2VlIHRoZSBJRCBUcmFja2VyIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy8pIGZvcg0KZGV0YWlscyBvbiBkb2N1bWVudHMgdGhhdCBhcmUgdW5kZXIgZGlzY3Vzc2lvbiBi eSB0aGUgSUVTRy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K From rdroms.ietf@gmail.com Tue Jan 24 05:03:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85721F84F7 for ; Tue, 24 Jan 2012 05:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.618 X-Spam-Level: X-Spam-Status: No, score=-103.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 klsksTlOrdDT for ; Tue, 24 Jan 2012 05:03:05 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC921F84F6 for ; Tue, 24 Jan 2012 05:03:05 -0800 (PST) Received: by qabj34 with SMTP id j34so2325409qab.10 for ; Tue, 24 Jan 2012 05:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JT7hyy3jDokimHYxvbh65HnyKB3oeCBk4icXq+RnE5o=; b=nMdxg52Ur3jNNX6V7IPCOaGGTNeRdkao4vh6yZ3UzO7D37wldFfJdPjA+1Y2mqKGjU eIk37YciHcq2qH6JygTpeZywE9xnYA2snyHqsP7G5wnDCokl6ZzIc5dnMfhdlAz85jGT 1E5dMZhRFpIUpzQ2haR/z0RdoDEdLh+0Bqdig= Received: by 10.224.195.2 with SMTP id ea2mr1090098qab.84.1327410183625; Tue, 24 Jan 2012 05:03:03 -0800 (PST) Received: from rtp-rdroms-8913.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id eb4sm15941285qab.4.2012.01.24.05.03.00 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 05:03:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Tue, 24 Jan 2012 08:02:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <02A2B32A-7518-49DD-939B-CF7B5D22A52C@gmail.com> References: To: mib-doctors@ietf.org X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 24 Jan 2012 05:03:52 -0800 Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] 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: Tue, 24 Jan 2012 13:03:06 -0000 MIB Doctors - I don't think I've seen a reply to Dan's request for a = formal MIB Doctor review of draft-ietf-trill-rbridge-mib-04. The lack = of a MIB Doctor review is blocking progress on this document, so I would = greatly appreciate one of you volunteering to review the document. - Ralph On Dec 1, 2011, at 10:08 AM 12/1/11, Romascanu, Dan (Dan) wrote: > MIB Doctors, >=20 > Please see the DISCUSS entered by Adrian. Both Bert and me provided = comments on the earlier versions of the MIB module but did not have time = for a full MIB review. I sent a formal call for volunteers to this list = when the document was sent to IETF LC (on 10/30), but this one was not = answered. Sure the IETF meeting interfered, but right now the lack of a = MIB doctors review blocks the document, and the there seem to be some = problems (or at least questions) raised by Adrian.=20 >=20 > Please jump in to help.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of Adrian Farrel > Sent: Thursday, December 01, 2011 4:59 PM > To: The IESG > Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org; = trill-chairs@tools.ietf.org > Subject: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: = (withDISCUSS and COMMENT) >=20 > Adrian Farrel has entered the following ballot position for > draft-ietf-trill-rbridge-mib-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Has a MIB doctor review been done yet? It seems like one is still > needed. I am not a MIB expert, but I think I see a number of issues. >=20 > --- >=20 > I'm afraid Sean's Comment needs to be captured in a Discuss.=20 >=20 > Please resolve the downref to RFC 4663 either by moving it to=20 > Informative (which seems reasonable) or by reissuing the last call. >=20 > --- >=20 > I would like help from the OPS ADs (and MIB Doctors) on this point: >=20 > It seems to me that section 6.7 needs a new conformance statement to > be applied to ISIS-MIB. The text in the sectionappears to be in two=20 > parts: >=20 > - Implementation guidance (what value to return on a GET from a Trill > implementation) >=20 > - Implementation requirements (which tables/objects to implement or = not > (conformance statement). >=20 > --- >=20 > RbridgeNickname ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The 16-bit identifier used in TRILL as an > abbreviation for the RBridge's 48-bit IS-IS System ID. > The value 0 means a nickname is not specified, the values > 0xffco through 0xfffe are reserved for future allocation, > and the value 0xffff is permanently reserved." > SYNTAX Unsigned32 (0..65471) >=20 > As specified, if the reserved values are ever allocated for any reason > you will have to respin the MIB module. You probably don't want to = have > to do that, so why not allow 0..65534? (By the way, if 0xffff is = outside > the available range, it is by definition permanetly reserved, so maybe=20= > you don't need to say anytng about it.) >=20 > --- >=20 > There seems to be some confusion about defaults. >=20 > There are a number of cases where the DESCRIPTION clause states a > specific value for the default of a read-write or a read-create = object. > For example: >=20 > rbridgeBaseForwardDelay OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Modified aging time for address entries after an appointed > forwarder change. The default value is 15. >=20 > The value of this object MUST be retained across > reinitializations of the management system." > REFERENCE > "RBridge section 4.8.2" > ::=3D { rbridgeBase 3 } >=20 > This appears to be missing a DEFVAL clause unless you mean something > different by "default". If you actually mean that the default in an > implementation of the protocol is 15, then it is not appropriate to > mention it here. >=20 > In other objects (rbridgeBaseUniMultipathEnable, =20= > rbridgeBaseMultiMultipathEnable) you have "The default is > implementation-specific." If this applies to the implementation of the = =20 > management agent then you might guide the implementer. If it applies = to > the implementation of the protocol, then it doesn't really belong = here. >=20 > I suggest you look at each DESCRIPTION clause where there is a default > described and work out whether you should: > - add a DEFVAL clause > - reomove the txt > - extend the text to give additional advice to the implementer of the > management agent. >=20 > (By the way, sometimes you have included the DEFVAL just fine.) >=20 > --- >=20 > rbridgeBasePortIfIndex OBJECT-TYPE > SYNTAX InterfaceIndex >=20 > Should this be InterfaceIndexOrZero? What would happen if the entry = was > deleted from IF-MIB? >=20 > --- >=20 > I expected to see some mention of rbridgeSnoopingAddrType in the > conformance statement to limit its applicability to only a few of the > address types. >=20 > --- >=20 > rbridgeDtreeActiveTrees OBJECT-TYPE > SYNTAX Unsigned32 >=20 > Shouldn't this more properly be a Gauge32? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > You should mainly be saying "MIB module" where you say "MIB" >=20 > --- >=20 > Some of the IMPORTS clause entries usefully point to the RFCs housing > the imported TCs. It would be great if you could include the = references > for all the others. >=20 > --- >=20 > I appreciate the many REFERENCE clauses. Could add one to=20 > RbridgeNickname. >=20 > --- >=20 > -- Implementation of the rbridgeBase subtree is mandatory for all > -- RBridges. >=20 > Does this mean > ... that are conformant to this MIB module > Or are you making a wider statement about Rbridges? >=20 > --- >=20 > The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate the > (obvious) fact that the object is interpretted in the context of=20 > rbridgeSnoopingPortAddrType. >=20 > --- >=20 > rbridgeDtreeActiveTrees OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of trees being computed by all Rbridges > campus." >=20 > Missing some text in the DESCRIPTION clause? >=20 >=20 From dromasca@avaya.com Tue Jan 24 05:17:57 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3821F8542 for ; Tue, 24 Jan 2012 05:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 zpOaQHEM6LcC for ; Tue, 24 Jan 2012 05:17:57 -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 85F8721F84D6 for ; Tue, 24 Jan 2012 05:17:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAADGuHk+HCzI1/2dsb2JhbABCnVOEMYwrgQWBcgEBAQEDEgsTCjEODAQCAQgNAQMEAQEBCgYMCwEGASAlCQgBAQQBEggBGYdinQ+bP4kEAgEiAyMIgmOBBhyCUGMEmxWFC4dM X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="287772823" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jan 2012 08:17:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 08:04: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: Tue, 24 Jan 2012 14:17:51 +0100 Message-ID: In-Reply-To: <02A2B32A-7518-49DD-939B-CF7B5D22A52C@gmail.com> 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: AczamIW07dt7h476SXmRWqvjWCM63QAAbsTg References: <02A2B32A-7518-49DD-939B-CF7B5D22A52C@gmail.com> From: "Romascanu, Dan (Dan)" To: "Ralph Droms" , Cc: Adrian Farrel Subject: Re: [MIB-DOCTORS] 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: Tue, 24 Jan 2012 13:17:58 -0000 MIB Doctors, Please step ahead to help with reviewing this document. If I understand well its progress depends now on its MIB review! Note that Bert and me have already reviewed previous versions, and that O have already entered a DISCUSS on this version related to rbridgeBaseNicknameTable and rbridgeEsadiTable including read-create objects but now RowStatus objects. However, a complete MIB Doctor review is necessary.=20 Thanks and Regards, Dan > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Tuesday, January 24, 2012 3:03 PM > To: mib-doctors@ietf.org > Cc: Adrian Farrel; Romascanu, Dan (Dan) > Subject: Re: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib- > 04: (withDISCUSS and COMMENT) >=20 > MIB Doctors - I don't think I've seen a reply to Dan's request for a > formal MIB Doctor review of draft-ietf-trill-rbridge-mib-04. The lack > of a MIB Doctor review is blocking progress on this document, so I > would greatly appreciate one of you volunteering to review the > document. >=20 > - Ralph >=20 > On Dec 1, 2011, at 10:08 AM 12/1/11, Romascanu, Dan (Dan) wrote: >=20 > > MIB Doctors, > > > > Please see the DISCUSS entered by Adrian. Both Bert and me provided > comments on the earlier versions of the MIB module but did not have > time for a full MIB review. I sent a formal call for volunteers to this > list when the document was sent to IETF LC (on 10/30), but this one was > not answered. Sure the IETF meeting interfered, but right now the lack > of a MIB doctors review blocks the document, and the there seem to be > some problems (or at least questions) raised by Adrian. > > > > Please jump in to help. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of Adrian Farrel > > Sent: Thursday, December 01, 2011 4:59 PM > > To: The IESG > > Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org; trill- > chairs@tools.ietf.org > > Subject: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: > (withDISCUSS and COMMENT) > > > > Adrian Farrel has entered the following ballot position for > > draft-ietf-trill-rbridge-mib-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > --------------------------------------------------------------------- > - > > DISCUSS: > > --------------------------------------------------------------------- > - > > > > Has a MIB doctor review been done yet? It seems like one is still > > needed. I am not a MIB expert, but I think I see a number of issues. > > > > --- > > > > I'm afraid Sean's Comment needs to be captured in a Discuss. > > > > Please resolve the downref to RFC 4663 either by moving it to > > Informative (which seems reasonable) or by reissuing the last call. > > > > --- > > > > I would like help from the OPS ADs (and MIB Doctors) on this point: > > > > It seems to me that section 6.7 needs a new conformance statement to > > be applied to ISIS-MIB. The text in the sectionappears to be in two > > parts: > > > > - Implementation guidance (what value to return on a GET from a Trill > > implementation) > > > > - Implementation requirements (which tables/objects to implement or > not > > (conformance statement). > > > > --- > > > > RbridgeNickname ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "d" > > STATUS current > > DESCRIPTION > > "The 16-bit identifier used in TRILL as an > > abbreviation for the RBridge's 48-bit IS-IS System ID. > > The value 0 means a nickname is not specified, the values > > 0xffco through 0xfffe are reserved for future allocation, > > and the value 0xffff is permanently reserved." > > SYNTAX Unsigned32 (0..65471) > > > > As specified, if the reserved values are ever allocated for any > reason > > you will have to respin the MIB module. You probably don't want to > have > > to do that, so why not allow 0..65534? (By the way, if 0xffff is > outside > > the available range, it is by definition permanetly reserved, so > maybe > > you don't need to say anytng about it.) > > > > --- > > > > There seems to be some confusion about defaults. > > > > There are a number of cases where the DESCRIPTION clause states a > > specific value for the default of a read-write or a read-create > object. > > For example: > > > > rbridgeBaseForwardDelay OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "seconds" > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "Modified aging time for address entries after an appointed > > forwarder change. The default value is 15. > > > > The value of this object MUST be retained across > > reinitializations of the management system." > > REFERENCE > > "RBridge section 4.8.2" > > ::=3D { rbridgeBase 3 } > > > > This appears to be missing a DEFVAL clause unless you mean something > > different by "default". If you actually mean that the default in an > > implementation of the protocol is 15, then it is not appropriate to > > mention it here. > > > > In other objects (rbridgeBaseUniMultipathEnable, > > rbridgeBaseMultiMultipathEnable) you have "The default is > > implementation-specific." If this applies to the implementation of > the > > management agent then you might guide the implementer. If it applies > to > > the implementation of the protocol, then it doesn't really belong > here. > > > > I suggest you look at each DESCRIPTION clause where there is a > default > > described and work out whether you should: > > - add a DEFVAL clause > > - reomove the txt > > - extend the text to give additional advice to the implementer of the > > management agent. > > > > (By the way, sometimes you have included the DEFVAL just fine.) > > > > --- > > > > rbridgeBasePortIfIndex OBJECT-TYPE > > SYNTAX InterfaceIndex > > > > Should this be InterfaceIndexOrZero? What would happen if the entry > was > > deleted from IF-MIB? > > > > --- > > > > I expected to see some mention of rbridgeSnoopingAddrType in the > > conformance statement to limit its applicability to only a few of the > > address types. > > > > --- > > > > rbridgeDtreeActiveTrees OBJECT-TYPE > > SYNTAX Unsigned32 > > > > Shouldn't this more properly be a Gauge32? > > > > > > --------------------------------------------------------------------- > - > > COMMENT: > > --------------------------------------------------------------------- > - > > > > You should mainly be saying "MIB module" where you say "MIB" > > > > --- > > > > Some of the IMPORTS clause entries usefully point to the RFCs housing > > the imported TCs. It would be great if you could include the > references > > for all the others. > > > > --- > > > > I appreciate the many REFERENCE clauses. Could add one to > > RbridgeNickname. > > > > --- > > > > -- Implementation of the rbridgeBase subtree is mandatory for all > > -- RBridges. > > > > Does this mean > > ... that are conformant to this MIB module > > Or are you making a wider statement about Rbridges? > > > > --- > > > > The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate the > > (obvious) fact that the object is interpretted in the context of > > rbridgeSnoopingPortAddrType. > > > > --- > > > > rbridgeDtreeActiveTrees OBJECT-TYPE > > SYNTAX Unsigned32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The total number of trees being computed by all Rbridges > > campus." > > > > Missing some text in the DESCRIPTION clause? > > > > From noamb@orckit.com Wed Jan 25 00:29:38 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 1E73921F869A for ; Wed, 25 Jan 2012 00:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 5R3PYPZ8vymp for ; Wed, 25 Jan 2012 00:29:37 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9C21F8635 for ; Wed, 25 Jan 2012 00:29:36 -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_01CCDB3B.D6754116" Date: Wed, 25 Jan 2012 10:32:12 +0200 Message-ID: <45A67426326F814AAC27DBEC3FC7EEC2042AA067@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compilation of RFC 5060 PIM MIB Thread-Index: AczbO9XtXjIX7k2/Tk6h6yACAZdI2g== From: "Noam Brousard" To: X-Mailman-Approved-At: Wed, 25 Jan 2012 07:16:06 -0800 Subject: [MIB-DOCTORS] Compilation of RFC 5060 PIM 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, 25 Jan 2012 08:29:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCDB3B.D6754116 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Doctors, =20 I tried compiling the latest PIM MIB (RFC 5060) and got the following error: =20 A named number list may be applied only to the INTEGER type itself, and not to a type derived from the INTEGER type for SYNTAX declarations such as the following: pimStarGPimMode OBJECT-TYPE SYNTAX PimMode { asm(3), bidir(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this entry represents an ASM (Any Source Multicast, used with PIM-SM) or BIDIR-PIM group." ::=3D { pimStarGEntry 4 }=20 =20 =20 Where PimMode was previously defined as:=20 =20 PimMode ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The PIM mode in which a group is operating. =20 none(1) The group is not using PIM, which may be the case if, for example, it is a link-local or unroutable group address. =20 ssm(2) Source-Specific Multicast (SSM) with PIM Sparse Mode. =20 asm(3) Any Source Multicast (ASM) with PIM Sparse Mode. =20 bidir(4) Bidirectional PIM. =20 dm(5) PIM Dense Mode. =20 other(6) Any other PIM mode." =20 SYNTAX INTEGER { none(1), ssm(2), asm(3), bidir(4), dm(5), other(6) } =20 Can you shed any light on this issue? Is it just a matter of tweaking my compiler? =20 Thanks, =20 Noam =20 ------_=_NextPart_001_01CCDB3B.D6754116 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Doctors,

 

I tried compiling the latest PIM MIB (RFC 5060) and = got the following error:

 

A named = number list may be applied only to the INTEGER type itself, and not to a = type derived from the INTEGER type for SYNTAX declarations such as the = following:

pimStarGPimMode OBJECT-TYPE

    SYNTAX     = PimMode { asm(3), bidir(4) }

    MAX-ACCESS = read-only

    = STATUS     current

    DESCRIPTION

          =   "Whether this entry represents an ASM (Any Source = Multicast,

         &= nbsp;  used with PIM-SM) or BIDIR-PIM group."

    ::=3D { pimStarGEntry 4 } =

 

 

Where = PimMode was previously defined as:

 

PimMode = ::=3D TEXTUAL-CONVENTION

    STATUS     = current

    = DESCRIPTION

         &= nbsp;  "The PIM mode in which a group is = operating.

 

         &= nbsp;  none(1)      The group is not using = PIM, which may be the

         &= nbsp;           &n= bsp;   case if, for example, it is a link-local = or

         &= nbsp;           &n= bsp;   unroutable group address.

 

         &= nbsp;  ssm(2)       Source-Specific = Multicast (SSM) with PIM Sparse

         &= nbsp;           &n= bsp;   Mode.

 

         &= nbsp;  asm(3)       Any Source = Multicast (ASM) with PIM Sparse

         &= nbsp;           &n= bsp;   Mode.

 

         &= nbsp;  bidir(4)     Bidirectional = PIM.

 

         &= nbsp;  dm(5)        PIM Dense = Mode.

 

         &= nbsp;  other(6)     Any other PIM = mode."

 

    SYNTAX     = INTEGER {

         &= nbsp;        = none(1),

         &= nbsp;        ssm(2),

         &= nbsp;        asm(3),

         &= nbsp;        = bidir(4),

         &= nbsp;        dm(5),

         &= nbsp;        = other(6)

         &= nbsp;     }

 

Can you shed = any light on this issue? Is it just a matter of tweaking my = compiler?

 

Thanks,

 

Noam

 

------_=_NextPart_001_01CCDB3B.D6754116-- From j.schoenwaelder@jacobs-university.de Wed Jan 25 08:47:56 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 A6FEF21F859F for ; Wed, 25 Jan 2012 08:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 9l34BrkqTw5Z for ; Wed, 25 Jan 2012 08:47:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69621F853B for ; Wed, 25 Jan 2012 08:47:55 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87AA920C2F; Wed, 25 Jan 2012 17:47:54 +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 6OBsOgtj-BtH; Wed, 25 Jan 2012 17:47:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CE6120C28; Wed, 25 Jan 2012 17:47:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 77EB61CBA74A; Wed, 25 Jan 2012 17:47:36 +0100 (CET) Date: Wed, 25 Jan 2012 17:47:35 +0100 From: Juergen Schoenwaelder To: Noam Brousard Message-ID: <20120125164734.GB61984@elstar.local> Mail-Followup-To: Noam Brousard , mib-doctors@ietf.org References: <45A67426326F814AAC27DBEC3FC7EEC2042AA067@tlvmail1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A67426326F814AAC27DBEC3FC7EEC2042AA067@tlvmail1> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Compilation of RFC 5060 PIM 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, 25 Jan 2012 16:47:56 -0000 On Wed, Jan 25, 2012 at 10:32:12AM +0200, Noam Brousard wrote: > Hi Doctors, > > > > I tried compiling the latest PIM MIB (RFC 5060) and got the following > error: > > A named number list may be applied only to the INTEGER type itself, and > not to a type derived from the INTEGER type for SYNTAX declarations such > as the following: > > pimStarGPimMode OBJECT-TYPE > SYNTAX PimMode { asm(3), bidir(4) } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Whether this entry represents an ASM (Any Source Multicast, > used with PIM-SM) or BIDIR-PIM group." > ::= { pimStarGEntry 4 } The subtyping of enumerated INTEGER TCs enjoys quite some usage in conformance statements (in particular InetAddressType and RowStatus and StorageType come to my mind). Such subtyping is less frequently used in object type definitions. > Can you shed any light on this issue? Is it just a matter of tweaking my > compiler? Does your compiler allow TC subtyping in OBJECT definition in compliance statements? For example, the TUNNEL-MIB [RFC4087] has: OBJECT tunnelIfAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } Section 11 of RFC 2578 really only talks about range and size subtyping. RFC 2579 just says this: The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the same way as the SYNTAX clause of an OBJECT-TYPE macro (see section 11 of [2]). But then, it seems common practice that we do allow named number INTEGER subtyping. /js PS: For the SMIv2 geeks: The hidden issue here is that it is allowed to change the label associated with a number when a module is revised. This can break named number subtyping in modules that import a named number TC. Hence, changing a label or removing a named number is really really a bad idea. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Wed Jan 25 12:02:50 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9E21F8574 for ; Wed, 25 Jan 2012 12:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, 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 1oAEGPU3Q65z for ; Wed, 25 Jan 2012 12:02:49 -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 8200621F856F for ; Wed, 25 Jan 2012 12:02:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ctYPuwqFFnFrN6zcZlELd5GJx406Jr7+wVnNnFGNvGFoi1XD3w/R++8rBqxxQMOZ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.28] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rq7lx-0001Wu-98 for mib-doctors@ietf.org; Wed, 25 Jan 2012 13:40:41 -0500 Message-ID: <003b01ccdb91$62db93c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <45A67426326F814AAC27DBEC3FC7EEC2042AA067@tlvmail1> <20120125164734.GB61984@elstar.local> Date: Wed, 25 Jan 2012 10:44:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f544206e7e16fd93f48ebd399773d4a58350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.28 Subject: Re: [MIB-DOCTORS] Compilation of RFC 5060 PIM 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, 25 Jan 2012 20:02:50 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Noam Brousard" > Cc: > Sent: Wednesday, January 25, 2012 8:47 AM > Subject: Re: [MIB-DOCTORS] Compilation of RFC 5060 PIM MIB ... > But then, it seems common practice that we do allow named number > INTEGER subtyping. The practice seems reasonable to me. After all, RFC 2578 does say: An extended subset of the full capabilities of ASN.1 (1988) sub- typing is allowed, as appropriate to the underlying ASN.1 type. Randy From dromasca@avaya.com Thu Jan 26 07: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 BF63121F86C5 for ; Thu, 26 Jan 2012 07:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 azJrgJyfsJZX for ; Thu, 26 Jan 2012 07:43: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 2C46821F86C3 for ; Thu, 26 Jan 2012 07:43:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAHBzIU+HCzI1/2dsb2JhbABCnWmEMoYNhiKBBYFyAQEBAQMBAQEPCxMKMQMLDAQCAQgNAQMEAQEBCgYMBwQBBgEgBh8JCAEBBBMIARmHYpwrm1GJCAECCgEBAScGNYMFEw6BSYJLYwSbGIULh04 X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="288206512" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jan 2012 10:43:17 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jan 2012 10:29:33 -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: Thu, 26 Jan 2012 16:43:11 +0100 Message-ID: In-Reply-To: <023c01ccdc3d$b5c7fcc0$6601a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Adrian Farrel's Discuss ondraft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT) Thread-Index: AczcPeERfnnOkNPRTv2SUK1tBeNdwQAAvyfw References: <02A2B32A-7518-49DD-939B-CF7B5D22A52C@gmail.com> <023c01ccdc3d$b5c7fcc0$6601a8c0@JoanPC> From: "Romascanu, Dan (Dan)" To: "Joan Cucchiara" Cc: mib-doctors@ietf.org, Anil Rijhsinghani , Ralph Droms , Adrian Farrel Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss ondraft-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, 26 Jan 2012 15:43:21 -0000 This is great, please go ahead, thanks Joan! Regards, Dan > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Thursday, January 26, 2012 5:18 PM > To: Romascanu, Dan (Dan) > Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss ondraft-ietf-trill- > rbridge-mib-04: (withDISCUSS and COMMENT) >=20 > Dan, >=20 > If you haven't had any volunteers yet, then I'm happy to do a review, > although this > isn't my area, but I can do it from a MIB perspective. >=20 > Let me know. (Oh timeframe would be about Feb 7th or so, possibly > earlier). >=20 > Thanks, > -Joan >=20 > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "Ralph Droms" ; > Cc: "Adrian Farrel" > Sent: Tuesday, January 24, 2012 8:17 AM > Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss > ondraft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT) >=20 >=20 > > MIB Doctors, > > > > Please step ahead to help with reviewing this document. If I > understand > > well its progress depends now on its MIB review! Note that Bert and > me > > have already reviewed previous versions, and that O have already > entered > > a DISCUSS on this version related to rbridgeBaseNicknameTable and > > rbridgeEsadiTable including read-create objects but now RowStatus > > objects. However, a complete MIB Doctor review is necessary. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > >> Sent: Tuesday, January 24, 2012 3:03 PM > >> To: mib-doctors@ietf.org > >> Cc: Adrian Farrel; Romascanu, Dan (Dan) > >> Subject: Re: Adrian Farrel's Discuss on draft-ietf-trill-rbridge- > mib- > >> 04: (withDISCUSS and COMMENT) > >> > >> MIB Doctors - I don't think I've seen a reply to Dan's request for a > >> formal MIB Doctor review of draft-ietf-trill-rbridge-mib-04. The > lack > >> of a MIB Doctor review is blocking progress on this document, so I > >> would greatly appreciate one of you volunteering to review the > >> document. > >> > >> - Ralph > >> > >> On Dec 1, 2011, at 10:08 AM 12/1/11, Romascanu, Dan (Dan) wrote: > >> > >> > MIB Doctors, > >> > > >> > Please see the DISCUSS entered by Adrian. Both Bert and me > provided > >> comments on the earlier versions of the MIB module but did not have > >> time for a full MIB review. I sent a formal call for volunteers to > > this > >> list when the document was sent to IETF LC (on 10/30), but this one > > was > >> not answered. Sure the IETF meeting interfered, but right now the > lack > >> of a MIB doctors review blocks the document, and the there seem to > be > >> some problems (or at least questions) raised by Adrian. > >> > > >> > Please jump in to help. > >> > > >> > Thanks and Regards, > >> > > >> > Dan > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf > >> Of Adrian Farrel > >> > Sent: Thursday, December 01, 2011 4:59 PM > >> > To: The IESG > >> > Cc: draft-ietf-trill-rbridge-mib@tools.ietf.org; trill- > >> chairs@tools.ietf.org > >> > Subject: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib- > 04: > >> (withDISCUSS and COMMENT) > >> > > >> > Adrian Farrel has entered the following ballot position for > >> > draft-ietf-trill-rbridge-mib-04: Discuss > >> > > >> > When responding, please keep the subject line intact and reply to > > all > >> > email addresses included in the To and CC lines. (Feel free to cut > >> this > >> > introductory paragraph, however.) > >> > > >> > Please refer to http://www.ietf.org/iesg/statement/discuss- > >> criteria.html > >> > for more information about IESG DISCUSS and COMMENT positions. > >> > > >> > > >> > > >> > > > --------------------------------------------------------------------- > >> - > >> > DISCUSS: > >> > > > --------------------------------------------------------------------- > >> - > >> > > >> > Has a MIB doctor review been done yet? It seems like one is still > >> > needed. I am not a MIB expert, but I think I see a number of > issues. > >> > > >> > --- > >> > > >> > I'm afraid Sean's Comment needs to be captured in a Discuss. > >> > > >> > Please resolve the downref to RFC 4663 either by moving it to > >> > Informative (which seems reasonable) or by reissuing the last > call. > >> > > >> > --- > >> > > >> > I would like help from the OPS ADs (and MIB Doctors) on this > point: > >> > > >> > It seems to me that section 6.7 needs a new conformance statement > to > >> > be applied to ISIS-MIB. The text in the sectionappears to be in > two > >> > parts: > >> > > >> > - Implementation guidance (what value to return on a GET from a > > Trill > >> > implementation) > >> > > >> > - Implementation requirements (which tables/objects to implement > or > >> not > >> > (conformance statement). > >> > > >> > --- > >> > > >> > RbridgeNickname ::=3D TEXTUAL-CONVENTION > >> > DISPLAY-HINT "d" > >> > STATUS current > >> > DESCRIPTION > >> > "The 16-bit identifier used in TRILL as an > >> > abbreviation for the RBridge's 48-bit IS-IS System ID. > >> > The value 0 means a nickname is not specified, the > values > >> > 0xffco through 0xfffe are reserved for future > allocation, > >> > and the value 0xffff is permanently reserved." > >> > SYNTAX Unsigned32 (0..65471) > >> > > >> > As specified, if the reserved values are ever allocated for any > >> reason > >> > you will have to respin the MIB module. You probably don't want to > >> have > >> > to do that, so why not allow 0..65534? (By the way, if 0xffff is > >> outside > >> > the available range, it is by definition permanetly reserved, so > >> maybe > >> > you don't need to say anytng about it.) > >> > > >> > --- > >> > > >> > There seems to be some confusion about defaults. > >> > > >> > There are a number of cases where the DESCRIPTION clause states a > >> > specific value for the default of a read-write or a read-create > >> object. > >> > For example: > >> > > >> > rbridgeBaseForwardDelay OBJECT-TYPE > >> > SYNTAX Unsigned32 > >> > UNITS "seconds" > >> > MAX-ACCESS read-write > >> > STATUS current > >> > DESCRIPTION > >> > "Modified aging time for address entries after an > > appointed > >> > forwarder change. The default value is 15. > >> > > >> > The value of this object MUST be retained across > >> > reinitializations of the management system." > >> > REFERENCE > >> > "RBridge section 4.8.2" > >> > ::=3D { rbridgeBase 3 } > >> > > >> > This appears to be missing a DEFVAL clause unless you mean > something > >> > different by "default". If you actually mean that the default in > an > >> > implementation of the protocol is 15, then it is not appropriate > to > >> > mention it here. > >> > > >> > In other objects (rbridgeBaseUniMultipathEnable, > >> > rbridgeBaseMultiMultipathEnable) you have "The default is > >> > implementation-specific." If this applies to the implementation of > >> the > >> > management agent then you might guide the implementer. If it > applies > >> to > >> > the implementation of the protocol, then it doesn't really belong > >> here. > >> > > >> > I suggest you look at each DESCRIPTION clause where there is a > >> default > >> > described and work out whether you should: > >> > - add a DEFVAL clause > >> > - reomove the txt > >> > - extend the text to give additional advice to the implementer of > > the > >> > management agent. > >> > > >> > (By the way, sometimes you have included the DEFVAL just fine.) > >> > > >> > --- > >> > > >> > rbridgeBasePortIfIndex OBJECT-TYPE > >> > SYNTAX InterfaceIndex > >> > > >> > Should this be InterfaceIndexOrZero? What would happen if the > entry > >> was > >> > deleted from IF-MIB? > >> > > >> > --- > >> > > >> > I expected to see some mention of rbridgeSnoopingAddrType in the > >> > conformance statement to limit its applicability to only a few of > > the > >> > address types. > >> > > >> > --- > >> > > >> > rbridgeDtreeActiveTrees OBJECT-TYPE > >> > SYNTAX Unsigned32 > >> > > >> > Shouldn't this more properly be a Gauge32? > >> > > >> > > >> > > > --------------------------------------------------------------------- > >> - > >> > COMMENT: > >> > > > --------------------------------------------------------------------- > >> - > >> > > >> > You should mainly be saying "MIB module" where you say "MIB" > >> > > >> > --- > >> > > >> > Some of the IMPORTS clause entries usefully point to the RFCs > > housing > >> > the imported TCs. It would be great if you could include the > >> references > >> > for all the others. > >> > > >> > --- > >> > > >> > I appreciate the many REFERENCE clauses. Could add one to > >> > RbridgeNickname. > >> > > >> > --- > >> > > >> > -- Implementation of the rbridgeBase subtree is mandatory for > all > >> > -- RBridges. > >> > > >> > Does this mean > >> > ... that are conformant to this MIB module > >> > Or are you making a wider statement about Rbridges? > >> > > >> > --- > >> > > >> > The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate > > the > >> > (obvious) fact that the object is interpretted in the context of > >> > rbridgeSnoopingPortAddrType. > >> > > >> > --- > >> > > >> > rbridgeDtreeActiveTrees OBJECT-TYPE > >> > SYNTAX Unsigned32 > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "The total number of trees being computed by all > Rbridges > >> > campus." > >> > > >> > Missing some text in the DESCRIPTION clause? > >> > > >> > > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors From dromasca@avaya.com Fri Jan 27 10:31:56 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 511B521F8670; Fri, 27 Jan 2012 10:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+1mWPFXjXFK; Fri, 27 Jan 2012 10:31:55 -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 770FC21F863F; Fri, 27 Jan 2012 10:31:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAInsIk/GmAcF/2dsb2JhbABEhQuoTXqBBYFyAQEBAQMSEQ0EUQYBCA0IAQQCBgYMCwECAgMBRAcBBgQBBAESCBqkIolykV+BL4diASQGNReCbhMOgSgMFYIYM2MEmxOMVQ X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="326899254" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jan 2012 13:31:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2012 13:26:38 -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, 27 Jan 2012 19:31:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the February 2, 2012 IESG Teleconference Thread-Index: AczcgOtnocb/4tTnShaVT1QxqpbivQAoLXfg From: "Romascanu, Dan (Dan)" To: , , "IETF DNS Directorate" , "YANG Doctors" , Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the February 2, 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, 27 Jan 2012 18:31:56 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgSUVTRyB0ZWxl Y2hhdCBvbiAyLzIuIFBsZWFzZSBzZW5kIG1lIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBvciBj b25jZXJucyBhYm91dCB0aGUgaXRlbXMgb24gdGhlIGFnZW5kYSBiZWZvcmUgV2VkbmVzZGF5IDIv MSBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVNHIFNlY3JldGFyeQ0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDI3LCAyMDEyIDE6MTkgQU0NCi4uLg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoy LjEgV0cgU3VibWlzc2lvbnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1zaWRy LXJwa2ktcnRyLTI0DQogICAgVGhlIFJQS0kvUm91dGVyIFByb3RvY29sIChQcm9wb3NlZCBTdGFu ZGFyZCkNCiAgICBOb3RlOiBEb2N1bWVudCBzaGVwaGVyZCBpcyBDaHJpcyBNb3Jyb3cgKG1vcnJv d2NAb3BzLW5ldG1hbi5uZXQpLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtcm10LXNpbXBsZS1hdXRoLWZvci1hbGMt bm9ybS0wNg0KICAgIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBTY2hlbWVzIGZvciB0aGUgQUxDIGFu ZCBOT1JNIFByb3RvY29scw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlh biBBZGFtc29uIChhZGFtc29uQGl0ZC5ucmwubmF2eS5taWwpIGlzIHRoZSBkb2N1bWVudA0KICAg IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5ndG9uDQoNCjIuMiBJbmRpdmlkdWFs IFN1Ym1pc3Npb25zDQoyLjIuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LW5vdHRpbmdoYW0taHR0 cC1uZXctc3RhdHVzLTAzDQogICAgQWRkaXRpb25hbCBIVFRQIFN0YXR1cyBDb2RlcyAoUHJvcG9z ZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGVyIFNhaW50LUFuZHJlDQoNCjIuMi4yIFJldHVy bmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4gRG9jdW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1p c3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1kaXNj YXJkLXByZWZpeC0wMg0KICAgIEEgRGlzY2FyZCBQcmVmaXggZm9yIElQdjYgKEluZm9ybWF0aW9u YWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpLCAoam9lbGphQGJvZ3VzLmNvbSkgdjZvcHMgY28t Y2hhaXIsIGlzIHRoZQ0KICAgIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSb24gQm9u aWNhDQoNCiAgbyBkcmFmdC1pZXRmLTZtYW4tMzYyNy1oaXN0b3JpYy0wMQ0KICAgIFJGQzM2Mjcg dG8gSGlzdG9yaWMgc3RhdHVzIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IEJyaWFuIEhhYmVy bWFuIChicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLXJhZGV4dC1yYWRz ZWMtMTANCiAgICBUTFMgZW5jcnlwdGlvbiBmb3IgUkFESVVTIChFeHBlcmltZW50YWwpDQogICAg Tm90ZTogSm91bmkgS29yaG9uZW4gKGpvdW5pLmtvcmhvbmVuQG5zbi5jb20pIGlzIHRoZSBEb2N1 bWVudA0KICAgIFNoZXBoZXJkLg0KICAgIFRva2VuOiBEYW4gUm9tYXNjYW51DQoNCjMuMS4yIFJl dHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi12Nm9wcy12Ni1hYWFhLXdoaXRlbGlzdGlu Zy1pbXBsaWNhdGlvbnMtMDgNCiAgICBDb25zaWRlcmF0aW9ucyBmb3IgVHJhbnNpdGlvbmluZyBD b250ZW50IHRvIElQdjYgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpIChq b2VsamFAYm9ndXMuY29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJv biBCb25pY2ENCg0KMy4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcg SXRlbXMNCg0KICBOT05FDQoNCjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4z IElSVEYgYW5kIEluZGVwZW5kZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEg TmV3IEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoN CjQuIFdvcmtpbmcgR3JvdXAgQWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3Nl ZCBmb3IgSUVURiBSZXZpZXcNCg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3Zh bA0KDQogIE5PTkUNCg0KNC4yIFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlv biBmb3IgSUVURiBSZXZpZXcNCg0KICBvIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSAo bmV0bW9kKQ0KICAgIFRva2VuOiBEYW4NCg0KICBvIEJhc2ljIExldmVsIG9mIEludGVyb3BlcmFi aWxpdHkgZm9yIFNJUCBTZXJ2aWNlcyAoYmxpc3MpDQogICAgVG9rZW46IFJvYmVydA0KDQogIG8g QmlEaXJlY3Rpb25hbCBvciBTZXJ2ZXItSW5pdGlhdGVkIEhUVFAgKGh5YmkpDQogICAgVG9rZW46 IFBldGVyDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9JRCBT ZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg==