From dromasca@avaya.com Mon Aug 3 06:49:34 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E3828C1B6 for ; Mon, 3 Aug 2009 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sHozgM2UIuB for ; Mon, 3 Aug 2009 06:49:32 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 9200228C173 for ; Mon, 3 Aug 2009 06:49:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,314,1246852800"; d="txt'?scan'208";a="169006769" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Aug 2009 09:49:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Aug 2009 09:49:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA1441.2F2E1E8E" Date: Mon, 3 Aug 2009 15:49:10 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for the OPSAWG meeting at IETF-75 thread-index: AcoUQS3XtrKocr9SRRCMaTIHImuQgg== From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] Draft minutes for the OPSAWG meeting at IETF-75 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:49:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1441.2F2E1E8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find below the draft minutes for the OPSAWG meeting in Stockholm. Thanks to Juergen Quittek, Wes Hardaker and Benoit Claise for the notes. Please send comments or additions to the list.=20 Thanks and Regards, Dan ------_=_NextPart_001_01CA1441.2F2E1E8E Content-Type: text/plain; name="stockholm_opsawg_minutes_draft_00.txt" Content-Transfer-Encoding: base64 Content-Description: stockholm_opsawg_minutes_draft_00.txt Content-Disposition: attachment; filename="stockholm_opsawg_minutes_draft_00.txt" T1BTQVdHIG1lZXRpbmcgbm90ZXMNCklFVEYgNzUsIFN0b2NraG9sbSwgSnVseSAyOQ0KDQoNCjEu IFdlbGNvbWUgYW5kIGFnZW5kYSBiYXNoaW5nDQoNCkRhbiBSb21hc2NhbnU6IA0KU2NvdHQgY2Fu bm90IGpvaW4gcGh5c2ljYWxseSB0byBjaGFpciB0aGUgc2Vzc2lvbi4NCkRhbiBhbmQgUm9uIHNp dCBpbiBmb3IgU2NvdHQuDQpObyByZXF1ZXN0cyBmb3IgY2hhbmdpbmcgdGhlIGFnZW5kYQ0KDQoN CjIuIFdHIHN0YXR1cw0KDQpEYW46DQpEb2N1bWVudHMgaW4gb3IgYWZ0ZXIgSUVURiBsYXN0IGNh bGw6DQogIC0gbWFwcGluZyBTTk1QIHRvIFN5c2xvZw0KICAtIG1hcHBpbmcgU3lzbG9nIHRvIFNO TVANCiAgLSBTTUkgZGF0YXR5cGVzIGluIFhNTA0KTmV3IHJldmlzaW9ucyBhcmUgbmVlZGVkIGZv ciBhbGwgb2YgdGhlbS4NCg0KTWlsZXN0b25lIHJldmlldzoNCg0KVGhlcmUgaXMgYW4gb3BlbiBt aWxlc3RvbmUgb24gYSB0ZW1wbGF0ZSBmb3IgZ2VuZXJpYyBtYW5hZ2VtZW50IGRhdGEgbW9kZWxz LiBUaGVyZSBpcyBubyBwcm9ncmVzcyBvbiB0aGlzLiBJdCBtaWdodCBiZSB0aGUgcmlnaHQgIGlk ZWEgdG8gdGFrZSBpdCBvZmYgdGhlIGNoYXJ0ZXIuIA0KDQpEYXZpZCBIYXJyaW5ndG9uOiANClRo ZXJlIGlzIGEgbmVlZCBmb3IgdGhpcyBkb2N1bWVudC4gYmVjYXVzZSBwZW9wbGUgYXJlIGRlZmlu aW5nIA0KZGF0YSBtb2RlbHMgaW4gc2V2ZXJhbCBXR3MuIFdlIGhhdmUgaWRlYXMgd2hhdCB0byB3 cml0ZSBidXQgZGlkIA0Kbm90IHlldCBmaW5kIHRpbWUgZm9yIGRvaW5nIHNvLiBJdCBpcyBub3Qg bXVjaCB3b3JrIHRvIGJlIGRvbmUuDQoNCkRhbjogDQpEbyB3ZSBoYXZlIGVub3VnaCBiYWNrZ3Jv dW5kIGluIGV2ZXJ5dGhpbmcgbm93IHRoYXQgd2UgY2FuIHByb2R1Y2UgdGhlIGRvY3VtZW50IGlu IHRoZSBmaXJzdCBwbGFjZT8NCg0KRGF2aWQgSGFycmluZ3RvbjogDQpJIGJlbGlldmUgc28geWVz LiAgVGhlIGRvY3VtZW50IGhhcyBtb3N0IG9mIHRoZSBjb21wb25lbnRzIHRoYXQgaXQgbmVlZHMg bm93LiAgTWFueSBvZiB0aGUgYm9pbGVyIHBsYXRlcyBqdXN0IG5lZWQgdXBkYXRpbmcgdG8gYmUg Im1vcmUgZ2VuZXJpYyIuICBNdWNoIG9mIHRoZSBkb2N1bWVudCBpcyB2ZXJ5IE1JQi13b3JkZWQg YW5kIGNvdWxkIHVzZSBzb21lIGdlbmVyaWMgd29yZGluZyByZXBsYWNlbWVudHMuDQoNCkRhbiBS b21hc2NhbnU6IA0KV2UgaGF2ZSBhIGxvdCBvZiBjb21tb24gYW5kIGFncmVlZC1lZCB1cG9uIHRl eHQgYWJvdXQgTUlCIG1vZHVsZXMsIGV0Yy4gIEknbSBub3Qgc3VyZSB0aGF0IGFncmVlbWVudCBl eGlzdHMgYWJvdXQgY29tbW9uIGluZm9ybWF0aW9uIG1vZGVscy4NCg0KRGF2aWQgSGFycmluZ3Rv bjogDQpUaGF0J3MgcHJvYmFibHkgdHJ1ZS4gIEl0IHdhcyBkZWNpZGVkIHRvIHB1dCB0aGUgZG9j dW1lbnQgdGVtcGxhdGVzIG9uIHRoZSB0b29scyBwYWdlIGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxk IGp1c3QgcG9pbnQgdG8gdGhlIHRvb2xzIHBhZ2UuICBUaGF0J3MgcHJvYmFibHkgd2hhdCBuZWVk cyB0byBiZSBkb25lIGZvciBhIGdlbmVyaWMgbWFuYWdlbWVudCBtb2RlbCBhcyB3ZWxsIGluIG9y ZGVyIHRvIGtlZXAgaXQgY3VycmVudC4gT3RoZXIgV0dzIGFyZSBwb3NzaWJseSBnb2luZyB0byBj cmVhdGUgdmFyaW91cyBib2lsZXIgcGxhdGVzIChzeXNsb2csIHlhbmcgYXMgRUdzKSBhbmQgSSBk byBiZWxpZXZlIHRoZXJlIGlzIGEgbG90IG9mIGNvbW1vbiB0ZXh0IHRoZXJlLg0KDQoNCkp1ZXJn ZW4gU2Nob2Vud2FlbGRlcjoNCkkgcHJlZmVyIHRvIGhhdmUgc2VwYXJhdGUgZG9jdW1lbnRzIGZv ciBkaWZmZXJlbnQgY2FzZXMgaW4gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzLiBUaGUgbWFqb3Ig aXNzdWVzIGFyZSBzcGVjaWZpYyB0byB0aGUgcmVzcGVjdGl2ZSB0b3BpYy4gWWFuZywgc3lzbG9n IGFuZCBJUEZJWCwgZm9yIGV4YW1wbGUsIHJhdGhlciAgbmVlZCBpbmRpdmlkdWFsIHRlbXBsYXRl cyB0aGF0IG5lZWQgdG8gYmUgZGV2ZWxvcGVkIGluIHRoZSByZXNwZWN0aXZlIFdHcy4NCg0KRGF2 aWQ6DQpUaGUgZG9jdW1lbnQgSSBhbSB0aGlua2luZyBvZiB3b3VsZCBwb2ludCB0byBpbmRpdmlk dWFsIHRlbXBsYXRlcy4gSXQgd291bGQgbm90IGJlIGEgb25lIGZvciBhbGwgc29sdXRpb24gLGJ1 dCB3b3VsZCBoZWxwIHBlb3BsZSBmaW5kaW5nIHRoZSByaWdodCB0ZW1wbGF0ZSB6byB1c2UuDQoN CkRhbjoNCldlIGhhdmUgdGhlIHRvb2xzIHBhZ2UgZm9yIHRoYXQgcHVycG9zZS4NCg0KRGF2aWQ6 DQpQZW9wbGUgZG8gbm90IGZpbmQgaXQgb24gdGhlIHRvb2xzIHBhZ2UuDQoNCldlcyBIYXJkYWtl cjoNClRoaXMgd291bGQgYmUgYW4gUkZDIHdpdGggYWxtb3N0IG5vdGhpbmcgaW4uIEknbSBub3Qg c3VyZSB0aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gZ28uIFJGQ3MgYXJlIG5vdCB0aGUgaW5kZXgg d2hlcmUgYW55Ym9keSBzdGFydHMgbG9va2luZy4NCg0KUm9uIEJvbmljYToNCkkgYWdyZWUgdG8g V2VzLiBXZSBkb24ndCBuZWVkIHRoZSBhdXRob3JpdHkgZm9yIHRoZSBJRVRGIGZvciBwb2ludGlu Zw0KcGVvcGxlIHRvIHRvb2xzLiBUaGUgdG9vbHMgcGFnZSBpcyB0aGUgcmlnaHQgcGxhY2UgZm9y IGFuIGluZGV4Lg0KDQpEYXZpZDoNCldoZW4gd2Ugd3JvdGUgdGhlIGNoYXJ0ZXIsIHRoZSB0b29s cyBwYWdlIHdhcyBtdWNoIGxlc3MgdXNlZC4NCg0KRGFuOg0KV2UgZG9uJ3QgaGF2ZSBjb25zZW5z dXMgZm9yIHJlbW92aW5nIHRoZSBpdGVtIGZyb20gdGhlIGNoYXJ0ZXIuDQpJIHdpbGwgdHJ5IHRv IGRyYWZ0IGFuIGFsdGVybmF0aXZlIGFuZCBwb3N0IGl0IGluIHRoZSBtYWlsaW5nIGxpc3QuDQoN CkRhdmlkOg0KSWYgd2UgZG8gdGhpcywgdGhlIHJlc3VsdCB3b3VsZCBuZWVkIHRvIGdvIHRvIHRo ZSB0b29scyBwYWdlLg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6DQpZb3UgbWF5IGFzayBmb3Ig Y29uc2Vuc3VzIGlmIHRoaXMgc2hvdWxkIHJlbWFpbiBhcyBhIGNoYXJ0ZXJlZCBpdGVtDQp3aXRo IGFuIFJGQyBkZWxpdmVyYWJsZSBpbiB0aGlzIFdHLg0KLg0KRGFuOiBxdWVzdGlvbjogImRvIHdl IHdhbnQgdG8gY29udGludWUgdGhlIHRlbXBsYXRlIGZvciBnZW5lcmljIGRhdGEgbW9kZWwgbWFu YWdlbWVudCBhcyBhIGNoYXJ0ZXJlZCBpdGVtIGluIHRoaXMgd29ya2luZyBncm91cCI/DQoNCkRh bjoNClBsZWFzZSBzaG93IGhhbmRzLg0KMCBoYW5kcyBpbiBmYXZvcg0KNiBoYW5kcyBhZ2FpbnN0 DQoNCkRhdmlkOiB0aGUgb3RoZXIgcXVlc3Rpb24gdG8gYXNrIGlzIHdoZXRoZXIgYW55b25lIHdh bnRzIHRvIHdvcmsgb24gdGhlIGluZGl2aWR1YWwgdGVtcGxhdGVzLCBvciBtYXliZSBlYWNoIFdH IHNob3VsZCBkbyB0aGF0DQogICAgDQpEYW46IA0KbGV0cyBhc2sgZWFjaCBXRyBmaXJzdA0KDQpE YXZpZDogcGVvcGxlIGFyZW4ndCBhc2tpbmcgcXVlc3Rpb25zIGFib3V0IHRoZSBNSUIgdGVtcGxh dGUsIGFyZSB0aGV5IGV2ZW4gYmVpbmcgdXNlZCBvcj8NCg0KRGFuOiANCnRoZXkncmUgZGVmaW5p dGVseSBiZWluZyB1c2VkIGJ1dCB0aGUgcXVlc3Rpb25zIGFyZSBsaWtlbHkgZ29pbmcgdG8gdGhl IEFEcyBzaW5jZSB3ZSdyZSBnZXR0aW5nIHF1ZXN0aW9ucyBhYm91dCBpdC4NCg0KSnVlcmdlbjog DQpmb3IgbWUgaXQncyBhIHRvb2xzIGlzc3VlOyBsaWJzbWkgc3BpdHMgb3V0IGxvdHMgb2YgYm9p bGVycGxhdGUgdGV4dC4NCg0KDQoNCjMuIE9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZHJhZnRz DQogICAoZHJhZnQtaWV0Zi1vcHNhd2ctb3BlcmF0aW9ucy1hbmQtbWFuYWdlbWVudCkNCiAgIChk cmFmdC1pZXRmLW9wc2F3Zy1zdXJ2ZXktbWFuYWdlbWVudCkNCiAgIA0KRGF2aWQgSGFycmluZ3Rv biAoc2VlIHNsaWRlcyk6DQpUaGVyZSBpcyBhIHN1cnZleSBkb2N1bWVudCBvbiB3aGljaCB0aGUg V0cgbmVlZHMgdG8gZGVjaWRlIHdoYXQgdG8NCmRvIHdpdGggaXQuIA0KDQpKdWVyZ2VuOiANCnRo aXMgaXMgYW4gZXZlciBjaGFuZ2luZyBsaXN0IG9mIFRDcyBhbmQgdGhpcyBpcyBhIGR5bmFtaWMg bGlzdC4gIFdoeSB3b3VsZCB0aGlzIGRvY3VtZW50IG5lZWQgdG8gYmUgd3JpdHRlbi4gIEkgZG9u J3QgdGhpbmsgd2Ugc2hvdWxkIGNhc3QgY29uc3RhbnRseSBjaGFuZ2luZyB0aGluZ3MgYXMgUkZD cy4NCg0KRGF2aWQ6IA0KdGhpcyBkb2N1bWVudCB3YXMgYWxzbyBzdGFydGVkIGxvbmcgYmVmb3Jl IHRoZSBpbXByb3ZlZCBJRVRGIHRvb2xzIHBhZ2VzLiAgSSBhZ3JlZSB0aGF0IGl0IG1heSBiZSB0 aGlzIGlzIGJldHRlciBhcyBhIHdpa2kgZG9jdW1lbnQNCg0KRGFuOiBzaG91bGQgd2UgYXNrIGZv ciBhIGNvbnNlbnN1cyBjYWxsIG9uIHRoaXM/DQoNCkRhdmlkOiANCnRoZXJlIGFyZSBhIG51bWJl ciBvZiBNSUJzIHRoYXQgbm8gb25lIGV2ZXIgZG9lcyBhbnl0aGluZyB3aXRoLCBzaG91bGQgdGhl eSBiZSBsaXN0ZWQ/ICBJIGRvbid0IHRoaW5rIHNvLiAgUGVvcGxlIGRvbid0IHRlbGwgdXMgd2hl biBNSUJzIGFyZSBiZWluZyB1c2VkLiAgVGhlcmUgaXMgYSBxdWVzdGlvbiBhYm91dCB3aGF0IHRo ZSBwdXJwb3NlIG9mIHRoZSBkb2N1bWVudCBpcy4gIFRoZSBkb2N1bWVudCBhbHNvIHNheXMgQ09Q Uy1QUiBpcyBub3QgcmVjb21tZW5kZWQsIGJ1dCBJJ20gYXdhcmUgb2YgYXQgbGVhc3Qgb25lDQpp bXBsZW1lbnRhdGlvbiBleGlzdHMgc28gSSdtIG5vdCBzdXJlIGl0J3Mgd2lzZS4NCg0KUm9uIEJv bmljYTogDQpXaGF0IGlzIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2YgdGhlIG9wZXJhdGlvbnMgYW5k IG1hbmFnZW1lbnQNCmRvY3VtZW50Pw0KDQpEYXZpZDoNCkJDUC4NCg0KUm9uOg0KVGhpcyBtaWdo dCBiZSBhIHByb2JsZW0gYmVjYXVzZSBvZiB0aGUgY29tbWVudHMgd2UgcmVjZWl2ZWQgcmVjZW50 bHkuIFdlIHNob3VsZCByYXRoZXIgY29uc2lkZXIgbWFraW5nIGl0IGluZm9ybWF0aW9uYWwuDQoN CmRpc2N1c3Npb24gYWJvdXQgQkNQIHZzIGluZm9ybWF0aW9uYWwuICBTdW1tYXJ5OiBhIEJDUCBp cyBtb3JlIG9mIGEgY2x1YiBhbmQgYW4gaW5mb3JtYXRpb25hbCBpcyBtb3JlIG9mIGEgZ3VpZGVs aW5lDQogDQpKb2VsIFlhZ2VseTogDQp0aGVyZSBhcmUgcGxhY2VzIGluIEJDUCB3aGVyZSB3ZSBz YXkgdGhpbmdzIGxpa2UgIndlIGRvbid0IGxpa2UgdGhpbmdzIGJ1dCB3ZSdyZSBnb2luZyB0byBk byBpdCBhbnl3YXkiLiAgV2UgbGl2ZSBpbiB0aGUgcmVhbCB3b3JsZC4NCiANCkRhdmlkOg0KdGhp cyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBiZSBhIGxhcmdlIHBpZWNlIG9mIHdvb2QuICBZb3Ug Y291bGQgd2llbGQgaXQgYXMgYSBjbHViLCBidXQgaXQncyBub3QgZGVzaWduZWQgdG8gYmUgYSBj bHViLg0KIA0KUm9uOiANCmJ5IGxhYmVsaW5nIGl0IGFzIGEgQkNQIGl0J3Mgd29vZCBhbmQgY2Fu IGJlIHVzZWQgYXMgYSBjbHViLiAgQnkgbGFiZWxpbmcgaXQgYXMgaW5mb3JtYXRpb25hbCwgaXQg YmVjb21lcyBhIG5lcmYgd2VhcG9uLg0KDQpEYW46DQpUaGlzIGlzIGFuIGltcG9ydGFudCBxdWVz dGlvbiB0aGF0IG5lZWRzIHRvIGJlIGNsYXJpZmllZCBzb29uLiBQcm9wb3NhbCB0byBjaGFuZ2Ug b2YgdGhlIGludGVuZGVkIHN0YXR1cyB0byBpbmZvcm1hdGlvbmFsLiBSZXZpc2VkIEktRCBpbmNs dWRpbmcgc29tZSBjaGFuZ2VzIHdvdWxkIGZvbGxvdyBpZiBhZ3JlZWQuDQoNCg0KNC4gTG9jayBN SUINCiAgIChkcmFmdC1tZW5nLWZhbi1sb2NrLW1pYi0wMSkNCg0KV2FzaGFtIEZhbiAoc2VlIHNs aWRlcyk6DQpUaGUgcHVycG9zZSBpcyBtb25pdG9yaW5nIGxvY2tzLg0KDQpEYW46IA0KQXJlIHRo ZXJlIGNvbW1lbnRzIGZyb20gcGVvcGxlIGludm9sdmVkIGluIE5ldGNvbmYuDQoNCldlczoNCkxv Y2tzIGFyZSB1bmZvcnR1bmF0ZWx5IG5lY2Vzc2FyeS4gDQpJdCB0aGlzIHNlZW1zIHRvIGJlIGdv b2QgYW5kIHVzZWZ1bCB3b3JrLg0KSXQgd2lsbCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhl IGxvY2tzIGVhc2lseS4gDQoNCkRhdmlkIFBhcnRhaW46DQpJJ20gbm90IHN1cmUgd2Ugc2hvdWxk IG1lbnRpb24gY29wcy1wciBiZWNhdXNlIGl0IGlzbid0IHJlbGV2YW50IGFueSBsb25nZXIuDQoN Ckp1ZXJnZW4gU2Nob2Vud2FlbGRlcjoNClRoZXJlIGFyZSBub3QganVzdCBsb2NrcyBmcm9tIENP UFMtUFIgYW5kIG90aGVyIElFVEYgcHJvdG9jb2xzLiBUaGVyZSBhcmUgbWFueSBvdGhlciBsb2Nr cyBpbnZvbHZlZC4gVGhlcmVmb3JlLCBJIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhlIHVzZSBjYXNl LiBEZXZlbG9wZXJzIHdpbGwgZmluZCBpdCBoYXJkIHRvIGNoZWNrIHRoaXMgTUlCIHdoZW4gb2Jz ZXJ2aW5nIGEgcHJvYmxlbS4NCg0KQmFsYXpzOg0KSG93IGRvIHdlIGluZGljYXRlIHRoZSBzY29w ZSBvZiB0aGUgbG9ja3M/DQoNCldhc2hhbToNClRoZSBzY29wZSBpcyBkZXNjcmliZWQgaW4gdGhl IHJlc3BlY3RpdmUgc3RhbmRhcmQgZGVmaW5pbmcgdGhlIGxvY2suDQoNCkRhdmlkIEhhcnJpbmd0 b246DQpFYWNoIHByb3RvY29sIGhhcyBkaWZmZXJlbnQgd2F5cyBvZiBkZWZpbmluZyB0aGUgc2Nv cGUgb2YgYSBsb2NrLg0KVGhpcyBuZWVkcyB0byBiZSBzaG93biBpbiBhIGRpZmZlcmVudCB0YWJs ZSBvdXRzaWRlIG9mIHRoaXMgTUlCLg0KDQpEYW46IA0KbGV0IG1lIHNoYXJlIGEgY29uY2VybiBh cyBhbiBBRDogd2hlbiB5b3UgdGVsbCBtZSB0aGlzIGlzIGp1c3QgbW9uaXRvcmluZyB3aGF0IGxv Y2tzIGFyZSBvbiB0aGUgZGV2aWNlLCBJJ20gZmluZSBhbmQgdW5kZXJzdGFuZCB0aGUgc2NvcGUu ICBXaGVuIHdlIHN0YXJ0IGRlYWxpbmcgd2l0aCBleHRlbnNpYmlsaXR5IGFuZCBwcm90b2NvbCBp bmZvcm1hdGlvbiBJIHN0YXJ0IGJlaW5nIG1vcmUgY29uY2VybmVkLiAgSWYgdGhpcyBpcyBwb3Nz aWJsZSBuZXcgd29yayBJJ2xsIHByb2JhYmx5IGFzayBmb3IgYSBtaW5pbWFsIHNjb3BlLg0KDQpE YXZpZCBIYXJyaW5ndG9uOg0KVGhlIFNOTVAgc3RhY2sgd2lsbCBub3QgaGF2ZSBtdWNoIGluc2ln aHQgaW4gd2hhdCBpcyBnb2luZyBvbg0KaW4gdGhlIG5ldGNvbmYgc3RhY2suIFRoaXMgd291bGQg YmUgdmVyeSBkaWZmaWN1bHQgdG8gaW1wbGVsZW1lbnQsDQpiZWNhdXNlIGFsbCBzdGFja3MgbmVl ZCB0byBpbnRlcmFjdCBvciBhbGwgcHJvdG9jb2xzIG5lZWQgdG8gYmUNCmNvbnN1bHRlZC4gSSBs aWtlIHRvIHN1Z2dlc3QgYSBuZXcgd29yayBpdGVtIGZvciB0aGlzIFdHLiBJZiBwZW9wbGUgdGhp bmsgdGhhdA0KQ09QUy1QUiBpcyBhIGRlYWQgcHJvdG9jb2wsIHRoZW4gbGV0J3Mgb2Jzb2xldGUg aXQuDQoNCkRhbjogDQpXaWxsIHlvdSB3cml0ZSBhbiBJbnRlcm5ldCBkcmFmdCBvbiAiQ09QUy1Q UiBpcyBkZWFkIj8NCg0KRGF2aWQgUGFydGFpbjoNCklzIHRoYXQgdGhlIHdheSBpdCBpcyBkb25l Pw0KDQpSb246DQpZZXMuDQoNCkRhdmlkIFBhcnRhaW46DQpJIHdvdWxkIHN1cHBvcnQgaXQuDQoN CkRhdmlkIEhhcnJpbmd0b246DQpUaGVuIHdlIHNob3VsZCBpbmNsdWRlIFNOTVAtQ09ORi4NCg0K U2NvdHQgQnJhZG5lciBzdXBwb3J0aW5nIHRoaXMgdmlhIEphYmJlci4NCg0KQmVydCBXaWpuZW46 DQpUaGlzIG1heSBiZSBhIHdhc3RlIG9mIHJlc291cmNlcy4gSXQgY29zdHMgYSBsb3Qgb2YgdGlt ZSBpbg0KdGhlIHBhc3QgdG8gZ28gdGhpcyB3YXkgZm9yIG90aGVyIGRvY3VtZW50cy4NCg0KUm9u Og0KSSBsaWtlIHRvIGdpdmUgaXQgYSB0cnkgZm9yIGZpbmRpbmcgb3V0IGl0IGlzIHN0aWxsIGRp ZmZpY3VsdC4NCg0KRGFuOiANClJvbiB3aWxsIHNoZXBlcmQgdGhlIGRvY3VtZW50IDopDQoNCkRh dmlkIFBhcnRhaW46DQpIYXZpbmcgQ09QUy1QUiBoaXN0b3JpYyB3b3VsZCBhbHNvIHNhdmUgdGlt ZSBpbiB0aGUgZnV0dXJlLA0KYmVjYXVzZSBvdXIgZG9jdW1lbnRzIHdvdWxkIG5vdCBhbnltb3Jl IG5lZWQgdG8gcmVmZXJlbmNlIGl0Lg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6DQpDT1BTLVBS IGlzIGEgdGFyZ2V0IHdvcnRoIHRyeWluZyBpdC4gSXQgaGFzIG1vcmUgcmVsZXZhbmNlDQp0aGFu IGp1c3QgYSBzaW5nbGUgTUlCIG1vZHVsZS4NCg0KU2NvdHQ6DQpJdCB3aWxsIGJlIGEgbG90IG9m IHdvcmsuDQoNCkRhbjoNCkFzIHRlY2huaWNhbCBjb250cmlidXRvciwgSSB3b3VsZCBhbHNvIHN1 cHBvcnQgdGhpcyBlZmZvcnQuDQoNCldlczoNCkV2ZW4gaWYgd2UgcHV0IENPUFMtUFIgdG8gaGlz dG9yaWMsIHdlIHdvdWxkIHN0aWxsIG5lZWQgdG8NCnJlZmVyIHRvIGl0IGluIHNvbWUgZG9jdW1l bnRzLCBiZWNhdXNlIGl0IHdpbGwgc3RpbGwgZXhpc3QuDQoNCkJlcnQ6DQpXZSBhbHJlYWR5IHN0 b3BwZWQgV0dzIGRvaW5nIFBJQiBtb2R1bGVzIGJlY2F1c2UgdGhleSBoZWF2aWx5DQpvdmVybGFw IHdpdGggTUlCIG1vZHVsZXMuDQoNClNjb3R0Og0KSVRVLVQgYW5tZCAzR1BQIGFyZSBzdGlsbCB1 c2luZyBpdC4NCg0KQmVydDoNCldlIHdlbnQgdGhlcmUgYW5kIGV4cGxhaW5lZCB0aGUgc2l0dWF0 aW9uLiAzR1BQIGd1eXMgYXJlIHN0aWxsIHdyaXRpbmcgUElCIG1vZHVsZXMuDQoNCkRhdmlkIEhh cnJpbmd0b246DQpPbmUgYmlnIHByb2JsZW0gd2l0aCBDT1BTLVBSIGlzIHRoYXQgaXQgaGFzIGEg Z2xvYmFsIGxvY2suIFRoaXMgYmxvY2tzIGV2ZW4gQ0xJLiBJbiBzdWNoIGEgY2FzZSB0aGUgTE9D SyBNSUIgd291bGQgYmUgYSAgdXNlZnVsIG1lYW5zIGZvciBpZGVudGlmeWluZyB0aGUgbG9jayBi bG9ja2luZyBvdGhlciBtZWFucy4NCg0KRGFuOg0KV2hvIGluIHRoZSByb29tIGlzIGluIGZhdm9y IG9mIHdvcmtpbmcgb24gdGhlIExPQ0sgTUlCIGluIHRoZSBvcHNhd2cNCjQgaGFuZHMgaW4gZmF2 b3INCjAgaGFuZHMgYWdhaW5zdA0KV2Ugd2lsbCB0YWtlIHRoaXMgdG8gdGhlIGxpc3QuDQoNCkFi b3V0IGNvcHMtcHIgaGlzdG9yaWMsIHdob2V2ZXIgd2FudHMgdG8gZG8gdGhhdCBzaG91bGQgbWFr ZSBhIHByb3Bvc2FsIGRvY3VtZW50Lg0KDQoNCg0KNS4gU05NUCBMb2NrDQogICAoZHJhZnQtZmFu LW1lbmctc25tcC1sb2NrLTAwKQ0KDQpXYXNoYW0gRmFuIChzZWUgc2xpZGVzKToNCldlIHNob3Vs ZCBleHRlbmQgdGhlIExvY2sgTUlCIHRvIG1hbmlwdWxhdGUgU05NUCBsb2Nrcy4NCg0KSnVlcmdl biBTY2hvZW53YWVsZGVyOg0KV2hhdCBpcyBiZWluZyBsb2NrZWQ/IFdoYXQgaXMgdGhlIHNjb3Bl Pw0KDQogV2FzaGFtOiANClRoZSBpbnN0cnVtZW50YXRpb24gaXRzZWxmDQoNCkp1ZXJnZW46IA0K VGhlIHRpbWUgaXQgdGFrZXMgdG8gcHJvY2VzcyBhIHNldCBkb2Vzbid0IGRlcGVuZCBvbiB0aGUg bXNnIHNpemUuICB0aGUgbW90aXZhdGlvbiBzZWN0aW9uIG5lZWRzIHRvIGJlIGNoYW5nZWQuDQoN CiBSb246DQogSG93IG1hbnkgYmVsaWV2ZSB0aGlzIHNob3VsZCBiZSB0YWtlbiBhcyBhbiBpdGVt Pw0KIEZvcjogMywgYWdhaW5zdDogMA0KIE5vdCBtYW55IGFnYWluLCBsZXRzIHRha2UgaXQgdG8g dGhlIGxpc3QuDQoNCg0KNi4gT0FNIGRlZmluaXRpb24gZHJhZnQNCiAgIChkcmFmdC1hbmRlcnNz b24tbXBscy10cC1vYW0tZGVmKQ0KICAgDQpMb2EgQW5kZXJzb246DQpJbiBNUExTLVRQIHRoZSB0 ZXJtIE9BTSBpcyBoZWF2aWx5IHVzZWQsIGJ1dCB3aXRoIHByb2JhYmx5IGRpZmZlcmVudCBtZWFu aW5ncy4gVGhpcyBpcyBhIGRvY3VtZW50IGRlZmluaW5nIHRoaXMgdGVybS4gSXQ/cyBzY29wZSBp cyBiZXlvbmQgdGhlIE1QTFMtVFAsIHdpZGVyLUlFVEYNCg0KUm9uOg0KSG93IG1hbnkgdGhpbmsg aXQgc2hvdWxkIGJlIGEgV0cgaXRlbT8NCjMgaW4gZmF2b3INCjAgYWdhaW5zdA0KDQpEYW46DQpU aGlzIGhhcyBhbHJlYWR5IGJlZW4gb24gdGhlIGxpc3QgZm9yIGNvbnNlbnN1cy4gQW5vdGhlciAg d2VlayBvZiBtYWlsaW5nIGxpc3QgY29tbWVudCBjaGFuY2UsIG90aGVyd2lzZSBoZSBjYW4gZ28g YWhlYWQsIGFuZCBMb2EgY2FuIHJlLXN1Ym1pdCBhcyBkcmFmdC1pZXRmLW9wc2F3Zw0KDQpMb2E6 IA0KVGhlcmUgd2lsbCBiZSBzb21lIG90aGVyIGVkaXRzLiANCg0KDQo3LiBQb3dlciBNb25pdG9y aW5nDQoNCkp1ZXJnZW4gUXVpdHRlayAoc2VlIHNsaWRlcyk6DQoNClNjb3R0IEJyYWRuZXI6IA0K SXMgdGhlIE1JQiByZWFkLW9ubHk/DQoNCkp1ZXJnZW4gUXVpdHRlazogDQpObyBNSUIgYnkgbm93 LCBpbmZvcm1hdGlvbmFsIHByZXNlbnRhdGlvbiwgdCdzIG5vdCB0aGUgdGltZSB0byBkZWNpZGUg b24gdGhhdCBub3cNCg0KU2NvdHQ6IA0KSG93IGRvZXMgdGhpcyByZWxhdGUgdG8gdGhlIHNtYXJ0 IGdyaWQgd29yaz8NCg0KSnVlcmdlbiBRdWl0dGVrOiANCkl0IG1heSBiZSBhIGNvbXBvbmVudCwg YnV0IGkgdGhpbmsgc21hcnQgZ3JpZCByZXF1aXJlcyBtdWNoIG1vcmUgKGxpa2Ugc2NoZWR1bGlu ZyBwb3dlciBwcm9kdWN0aW9uIGFuZCBjb25zdW1wdGlvbikuIEkgdGhpbmsgaXQncyBzbGlnaHRs eSByZWxhdGVkIGJ1dCBub3Qgc3Ryb25nbHkuDQoNCkRhbiBSb21hc2NhbnU6IA0KU3BlYWtpbmcg YXMgYSBjb250cmlidXRvcjogdGhlcmUgYXJlIGEgYnVuY2ggb2Ygb3JnYW5pemF0aW9ucyB3b3Jr aW5nIG9uIHRoaXMgd2hpY2ggaXMgd2hhdCBtYWtlcyBpdCBoYXJkLiAgVGhleSBtYXkgaGF2ZSBN SUJzIGFzIHdlbGwgYW5kIHRoaXMgbWlnaHQgaW50ZXJmZXJlLiBBcyBhbiBBRDogSSB0aGluayB3 ZSBuZWVkIHRvIHNlZSBhbiBJRCB0byBzZWUgdGhlIHNjb3BlIG9mIHdoYXQgaXMgYmVpbmcgc3Vn Z2VzdGVkLg0KDQpKdWVyZ2VuIFF1aXR0ZWs6IA0KVGhpcyBpc24ndCBhIGNoYXJ0ZXJpbmcgcmVx dWVzdCBhdCB0aGlzIHRpbWU7IEkganVzdCB3YW50IHRvIGJyaW5nIGF3YXJlbmVzcyBhbmQgd2Fu dCB0byBzZWUgd2hvIGlzIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiB0aGlzPyAgSXMgdGhpcyB0 aGUgcmlnaHQgb3JnYW5pemF0aW9uPw0KDQpTY290dCBCcmFkbmVyOiANClNtYXJ0LWdyaWQgaW5j bHVkZXMgcmVtb3RlIG1vbml0b3JpbmcgQU5EIHJlbW90ZSBjb250cm9sDQoNCkp1ZXJnZW4gUXVp dHRlazogDQpJIGFncmVlIGJ1dCBJIGRvbid0IHNlZSB0aGF0IGFzIHRoZSBjb3JlIGlzc3VlLg0K DQoNCkRhdmlkIEhhcnJpbmd0b246IA0KSSdtIGhhdmluZyBhIHByb2JsZW0gc2VlaW5nIHdoYXQg d2UgY291bGQgZG8gaW4gdGhlIG9wc2F3ZyBhYm91dCB0aGlzLg0KDQpKdWVyZ2VuIFF1aXR0ZWs6 IA0KSSdtIG5vdCBuZWNlc3NhcmlseSBzdXJlIHRoaXMgaXMgdGhlIHJpZ2h0IGdyb3VwIHRvIGRv IGl0IGVpdGhlci4NCg0KSnVlcmdlbiBTY2hvZW53YWxlZGVyOiANCkkgcmVzZXJ2ZWQgYSAxMCBt aW51dGUgc2xvdCB0b21vcnJvdyBpbiBPUFNBUkVBIHRvIGRpc2N1c3MgbG93LXBvd2VyIHN0dWZm IGZyb20gNmxvd3Bhbi4gIFRoZXkncmUgY29uc2lkZXJpbmcgdXNpbmcgU05NUC4NCiAgIA0KUm9u IEJvbmljYTogDQpJIGNvdWxkIHNlZSBhIG51bWJlciBvZiBpbnRlcmVzdGluZyBNSUJzIHdyaXR0 ZW4gdG93YXJkIHRoaXMgZ29hbC4gIEFub3RoZXIgdGhpbmcgd29ydGggbW9uaXRvcmluZyBtaWdo dCBiZSB0aGUgaGVhdCB0aHJvd24gb2ZmLg0KDQoNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlcjogDQpU aGUgbmljZSB0aGluZyB3b3VsZCBiZSB0byBrbm93IHdobyB3b3VsZCBiZSBpbXBsZW1lbnRpbmcg aXQuDQoNCkRhdmlkIEhhcnJpbmd0b246IA0KVGhlcmUgYXJlIHNvbWUgdGhpbmdzIHdlIHNob3Vs ZCBhdm9pZCBkb2luZy4gIFNhbXBsaW5nIG92ZXIgdGltZSwgZXRjLCBhbGwgbmVlZCB0byBiZSBj b25zaWRlcmVkLiBBIHBvbGxpbmcgYXBwcm9hY2ggbWF5IGJlIGJldHRlci4NCg0KSnVlcmdlbiBT Y2hvZW53YWxlZGVyOiANClRoZSBNSUIgbmVlZHMgdG8gYmUgZWFzeSB0byBpbXBsZW1lbnQuICBT dGF0ZSBhbmQgZHVyYXRpb24gaXMgdGhlIGVhc2llc3QgdG8gaW1wbGVtZW50Lg0KDQpXZXM6IA0K QXMgdmVuZG9yIEkgY2FuIGNvbmZpcm0gdGhhdCB0aGUgbmVlZCBpcyBvdXQgdGhlcmUgPyB3ZWUg c2VlIGRlbWFuZC4NCiANCg0KICAgDQo4LiBWaXJ0dWFsIE5ldHdvcmsgTWFuYWdlbWVudCBJbmZv cm1hdGlvbiBNb2RlbA0KICAgKGRyYWZ0LW9raXRhLW9wcy12bmV0bW9kZWwtMDApDQoNCkhpZGVr aSBPa2l0YSAoc2VlIHNsaWRlcyk6DQpGb3IgdmlydHVhbCBuZXR3b3JrcyB3ZSBuZWVkIGEgZGF0 YSBtb2RlbCBmb3IgZGVzY3JpYmluZyAgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHZpcnR1YWwgYW5k IHBoeXNpY2FsIG5ldHdvcmtzIGFuZCAgZm9yIGRlc2NyaWJpbmcgY29ubmVjdGlvbnMgYmV0d2Vl biB2aXJ0dWFsIGVudGl0aWVzLg0KDQpKdWVyZ2VuIFF1aXR0ZWs6DQpJcyBpdCBmb3IgZGF0YSBj ZW50ZXJzIG9ubHkgb3IgYXBwbGljYWJsZSB0byBnZW5lcmFsIG5ldHdvcmtzPw0KDQpIaWRla2k6 DQpBbHNvIGFwcGxpY2F0aW9uIHRvIGdlbmVyYWwgbmV0d29ya3Mgc2hvdWxkIGJlIHBvc3NpYmxl Lg0KDQpEYW46DQpXaG8gaGFzIHJlYWQgdGhlIGRyYWZ0Pw0KKG5vIGhhbmRzIHNob3dlZCB1cC4p DQpJdCBpcyB0b28gZWFybHkgdG8gYXNrIGZvciBXRyBhZG9wdGlvbi4gTGV0J3MgY29udGludWUg dGhlIGRpc2N1c3Npb24uDQoNCg0KOS4gVGhlIE1hbmFnZW1lbnQgTW9kZWwgb2YgdGhlIENlbnRy YWxpemVkIE5ldHdvcmsgQXJjaGl0ZWN0dXJlDQogICAoZHJhZnQtcmljaGFyZC1vcHNhd2ctY25h LW1pYi0wMCkNCg0KUmljaGFyZCBZYW5nIChzZWUgc2xpZGVzKToNClN1Z2dlc3QgYSBnZW5lcmlj IG1hbmFnZW1lbnQgbW9kZWwuDQoNCkRhbjoNClBsZWFzZSBjaGVjayBldmVyeWJvZHksIGlmIHRo aXMgaXMgdXNlZnVsIHdvcmsgZm9yIG9wZXJhdG9ycy4gVG9vIGVhcmx5IHRvIHRhbGsgYWJvdXQg YWRvcHRpb24gYnkgV0csIG5lZWRzIHRvIGJlIGNvbnRpbnVlZCBvbiB0aGUgbGlzdC4gDQoNCg0K DQo= ------_=_NextPart_001_01CA1441.2F2E1E8E-- From j.schoenwaelder@jacobs-university.de Mon Aug 3 07:01:43 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7813A6DDE for ; Mon, 3 Aug 2009 07:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAxNbba-t2FG for ; Mon, 3 Aug 2009 07:01:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 18B053A6A8B for ; Mon, 3 Aug 2009 07:01:42 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B9D8C0038; Mon, 3 Aug 2009 16:01:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DVX3h6AUywov; Mon, 3 Aug 2009 16:01:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 700E5C001E; Mon, 3 Aug 2009 16:01:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1187B76798; Mon, 3 Aug 2009 16:01:43 +0200 (CEST) Date: Mon, 3 Aug 2009 16:01:43 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090803140143.GA20382@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Draft minutes for the OPSAWG meeting at IETF-75 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:01:43 -0000 On Mon, Aug 03, 2009 at 03:49:10PM +0200, Romascanu, Dan (Dan) wrote: > Juergen: > for me it's a tools issue; libsmi spits out lots of boilerplate text. A more precise transcription would be: smidump is able to generate security considerations boilerplate text from a MIB module and it is easy to extend this further to generate a whole document template from a MIB module; but all this is for me a tools issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed Aug 5 03:27:25 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62A228C39D for ; Wed, 5 Aug 2009 03:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRkcqav27DbV for ; Wed, 5 Aug 2009 03:27:25 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id D2EAB3A6B92 for ; Wed, 5 Aug 2009 03:27:24 -0700 (PDT) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA01.westchester.pa.mail.comcast.net with comcast id QaF61c0011ei1Bg51aTUTm; Wed, 05 Aug 2009 10:27:28 +0000 Received: from Harrington73653 ([212.17.134.226]) by OMTA24.westchester.pa.mail.comcast.net with comcast id QaW81c00B4tEd043kaWCZc; Wed, 05 Aug 2009 10:30:20 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: Date: Wed, 5 Aug 2009 12:27:18 +0200 Message-ID: <00d301ca15b7$55f63e00$db000a0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoUQS3XtrKocr9SRRCMaTIHImuQggBdZGLA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [OPSAWG] Draft minutes for the OPSAWG meeting at IETF-75 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 10:27:25 -0000 Hi, The notes say: David Harrington: There are some things we should avoid doing. Sampling over time, etc, all need to be considered. A polling approach may be better. What I actually said was more like: There are certain types of things that should not be included in a MIB module. People are mentioning things like (was it standard deviations ???). Values that can be derived from other values should not be included in a MIB module. The goal should be to keep the agent simple, and move any derivable calculations to the manager application. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Monday, August 03, 2009 3:49 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Draft minutes for the OPSAWG meeting at IETF-75 > > Please find below the draft minutes for the OPSAWG meeting in > Stockholm. > Thanks to Juergen Quittek, Wes Hardaker and Benoit Claise for > the notes. > > > Please send comments or additions to the list. > > Thanks and Regards, > > Dan > From root@core3.amsl.com Thu Aug 6 07:45:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7DD5B28C14A; Thu, 6 Aug 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090806144501.7DD5B28C14A@core3.amsl.com> Date: Thu, 6 Aug 2009 07:45:01 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, et al. Filename : draft-ietf-opsawg-syslog-msg-mib-05.txt Pages : 22 Date : 2009-08-06 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-msg-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-06073900.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Aug 6 07:45:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9DE0628C14F; Thu, 6 Aug 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090806144501.9DE0628C14F@core3.amsl.com> Date: Thu, 6 Aug 2009 07:45:01 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-snmp-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages Author(s) : V. Marinov, J. Schoenwaelder Filename : draft-ietf-opsawg-syslog-snmp-04.txt Pages : 15 Date : 2009-08-06 This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-snmp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-06073913.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Thu Aug 6 07:50:54 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687AA28C164; Thu, 6 Aug 2009 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PizNHqFBh4kr; Thu, 6 Aug 2009 07:50:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 25D7028C115; Thu, 6 Aug 2009 07:50:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6084C007A; Thu, 6 Aug 2009 16:50:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0xZ7APYgK2vW; Thu, 6 Aug 2009 16:50:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A80D0C0079; Thu, 6 Aug 2009 16:50:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5ACA1B7D01B; Thu, 6 Aug 2009 16:50:03 +0200 (CEST) Date: Thu, 6 Aug 2009 16:50:02 +0200 From: Juergen Schoenwaelder To: Dan Romascanu , Avshalom Houri , Magnus Nystroem , Ben Campbell , Niclas Comstedt , opsawg-chairs@ietf.org Message-ID: <20090806145002.GA849@elstar.local> Mail-Followup-To: Dan Romascanu , Avshalom Houri , Magnus Nystroem , Ben Campbell , Niclas Comstedt , opsawg-chairs@ietf.org, iesg@ietf.org, opsawg@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org, iesg@ietf.org Subject: [OPSAWG] SYSLOG / SNMP translation IETF last call followup X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:50:54 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We received several minor IETF last call comments on the two IDs: draft-ietf-opsawg-syslog-msg-mib-04.txt draft-ietf-opsawg-syslog-snmp-03.txt Attached to this document is a response to the non-editorial comments that were made. I have also posted new IDs reflecting the changes that came out of the IETF last call reviews: draft-ietf-opsawg-syslog-msg-mib-05.txt draft-ietf-opsawg-syslog-snmp-04.txt Dan, please review the response / changes and if you are fine, please forward the document to the IESG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="syslog-review-summary.org" * draft-ietf-opsawg-syslog-msg-mib-04 ** AD review by Dan Romascanu *** DONE Missing reference RFC 3412 Added the missing reference. *** DONE converter vs translator and writing style There was no particular reason why I used converter in one document and translator in the other document. I will change this document to use translator. For the writing style, I prefer "SYSLOG-to-SNMP translator" and "SNMP-to-SYSLOG translator" since I generally write protocol names in all-caps. *** DONE message truncation Message truncation is a general "feature" of SYSLOG, see section 6.1 of RFC 5424. The SYSLOG specifications do not discuss whether all messages will be truncated to the same length nor is there a control object that tells an implementation when to truncate and when to discard. If we assume that truncation happens in the SYSLOG side of the translator, then I think no additional text is really needed. In response to your comments, I change the reference clause to point to section 6.1 and 6.4 of RFC5424. *** DONE counter of received SYSLOG messages I agree that counters for received messages etc. are useful but I consider them out of scope for this MIB module, which specifically addresses the translation of SYSLOG messages to SNMP. The counters you have in mind should be in a general SYSLOG-MIB and it seems the SYSLOG WG is still debating if and how they continue with a SYSLOG-MIB. No change made. *** DONE notification suppression threat There was already text concerning unauthorized disabling of notifications but I have added some additional text (mostly copied from your review) to make this threat clearer. ** Gen-Art review by Avshalom Houri No comments were received; no change made. ** Sec-Dir review by Magnus Nystroem *** DONE Restricting SEQUENCE OF SyslogMsgSDEntry This is an SMIv2 module and not a full blown ASN.1 module and SMIv2 does not allow such restrictions on the length of the sequence. In SNMP land, we also consider it bad style to invent arbitrary limits - so even if SMIv2 would allow this, we likely would not do this. No change made. *** DONE Security Considerations Improvements The text in the document conforms with the boilerplate text posted on the OPS web pages and thus I believe the text is fine. If people think it is not, they should talk to the OPS ADs and the SEC ADs so that they can work out better boilerplate text. No change made. * draft-ietf-opsawg-syslog-snmp-03 ** AD review by Dan Romascanu *** DONE MUST in "must be translated"? Changed to "MUST be translated". *** DONE RFC 2119 capitalization in sections 3.1 and 3.2? I capitalized several RFC 2119 keywords and rewrote 1-2 sentences for clarity. See the diff for the details. *** DONE Why BER encoding in the usage example? The BER encoding was included to (a) show the SNMP message format (the ASN.1 part at the right) since many people are still not familiar with the notion of contexts and to (b) illustrate the relative sizes of the two representations of the same notification and (c) to introduce all the parameters needed such as the context values. One could remove the BER and instead add textual descriptions of the example trap but I doubt this will necessarily improve readability. So I prefer to keep things as they are. No change made. *** DONE RFC 4234 has been obsoleted by RFC 5234 Replaced the outdated reference with the new reference since there were no reasons to stick to RFC 4234. ** Gen-Art review by Ben Campbell *** DONE MUST in "format must be translated"? Changed to "MUST be translated". *** DONE MUST in "must be compliant"? Changed to "MUST comply with". *** DONE Mapping of SNMP access control policies to SYSLOG There is no standardized access control model for SYSLOG. The security considerations already spell out that network operators using SNMP-to-SYSLOG translators should ensure that SYSLOG messages should not reveal sensitive information that is protected by SNMP. How this is done is implementation / deployment specific since SYSLOG does not have a defined and standardized access control mechanism. No change made. *** DONE Diagram asymmetry and access control The purpose of the arrows in the diagram was to indicate message flows and not individual messages. The SNMP-to-SYSLOG translator can act as a notification receiver for N SNMP notification originators and it can send SYSLOG messages to some independent number M of SYSLOG collectors. Added a clarification. SNMP enforces access control on the notification originator side, not at the notification receiver side. So from the SNMP perspective, there is no additional access control requirement here. *** DONE Is draft-ietf-opsawg-syslog-msg-mib a normative reference? I think so since there is text including a MUST that refers to the SYSLOG-MSG-MIB in section 4. No change made. *** DONE RFC 4234 has been obsoleted by RFC 5234 Replaced the outdated reference with the new reference since there were no reasons to stick to RFC 4234. ** Ops-Dir review by Niclas Comstedt *** DONE RFC 4234 has been obsoleted by RFC 5234 Replaced the outdated reference with the new reference since there were no reasons to stick to RFC 4234. --gBBFr7Ir9EOA20Yy-- From sob@harvard.edu Fri Aug 7 03:42:56 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C5B28C1AB for ; Fri, 7 Aug 2009 03:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecdVhnBZ8I8J for ; Fri, 7 Aug 2009 03:42:53 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 94A5E3A6ACC for ; Fri, 7 Aug 2009 03:42:53 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 247BC1B8D37D; Fri, 7 Aug 2009 06:42:56 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090807104256.247BC1B8D37D@newdev.eecs.harvard.edu> Date: Fri, 7 Aug 2009 06:42:56 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg mailing list consensus calls X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 10:42:57 -0000 There were a number of consensus checks made during the opsawg session in Stockholm that need to be verified on the opsawg list I'll send the calls over the next few days - one per message - please send your opinion on the calls to the list thanks Scott From sob@harvard.edu Fri Aug 7 03:51:48 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8797E3A6ED6 for ; Fri, 7 Aug 2009 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV5mBqFsYUnd for ; Fri, 7 Aug 2009 03:51:47 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id D6B683A6EBD for ; Fri, 7 Aug 2009 03:51:47 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id CF57D1B8D3BC; Fri, 7 Aug 2009 06:51:50 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090807105150.CF57D1B8D3BC@newdev.eecs.harvard.edu> Date: Fri, 7 Aug 2009 06:51:50 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg CC @1 - Generic Management Data Model X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 10:51:48 -0000 THe opsawg charter includes milestones for a 'Template for Generic Management Data Models' There has been no work to date on such a document (as far as I know) Dan asked the room in Stockholm if this item should stay in the opsawg charter. The view in the room was none in favor of keeping the document as a chartered item, 6 against. please let the list know if you feel that the milestones should be removed from the charter or if you feel that the working group should still develop such a document. (if you feel that the task should be maintaind please suggest someone to be the editor of the document if you have any suggestions) thanks Scott From ietfdbh@comcast.net Fri Aug 7 12:50:26 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BF53A6FF0 for ; Fri, 7 Aug 2009 12:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NNZkPqtCtvp for ; Fri, 7 Aug 2009 12:50:26 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id B6B1B3A6FD2 for ; Fri, 7 Aug 2009 12:49:53 -0700 (PDT) Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA08.westchester.pa.mail.comcast.net with comcast id RRzW1c0061ZXKqc58Xpx4X; Fri, 07 Aug 2009 19:49:57 +0000 Received: from Harrington73653 ([212.17.132.74]) by OMTA21.westchester.pa.mail.comcast.net with comcast id RXsc1c0071cTpF03hXsfln; Fri, 07 Aug 2009 19:52:45 +0000 From: "David Harrington" To: "'Scott O. Bradner'" , References: <20090807105150.CF57D1B8D3BC@newdev.eecs.harvard.edu> Date: Fri, 7 Aug 2009 21:49:44 +0200 Message-ID: <00ea01ca1798$3bf796b0$f6000a0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090807105150.CF57D1B8D3BC@newdev.eecs.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcoXTRQQ73LNpQ5eSBiqRfDyahAFNAASvL/A Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 19:50:27 -0000 Hi, This is not about developing a generic data model; it is only about developing a template. The subject line is rather misleading. I believe the template belongs on the tools page, and could be different templates for different management protocols. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Friday, August 07, 2009 12:52 PM > To: opsawg@ietf.org > Subject: [OPSAWG] opsawg CC @1 - Generic Management Data Model > > > THe opsawg charter includes milestones for a 'Template for Generic > Management Data Models' > > There has been no work to date on such a document (as far as I know) > > Dan asked the room in Stockholm if this item should stay in the opsawg > charter. > > The view in the room was none in favor of keeping the document > as a chartered item, 6 against. > > please let the list know if you feel that the milestones > should be removed > from the charter or if you feel that the working group should still > develop such a document. (if you feel that the task should be > maintaind please suggest someone to be the editor of the document if > you have any suggestions) > > thanks > > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From m_ersue@yahoo.de Fri Aug 7 14:13:30 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54C03A6A1A for ; Fri, 7 Aug 2009 14:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUaK3S3cKSOG for ; Fri, 7 Aug 2009 14:13:29 -0700 (PDT) Received: from web24506.mail.ird.yahoo.com (web24506.mail.ird.yahoo.com [87.248.114.233]) by core3.amsl.com (Postfix) with SMTP id 78BA93A6B1A for ; Fri, 7 Aug 2009 14:13:29 -0700 (PDT) Received: (qmail 63158 invoked by uid 60001); 7 Aug 2009 21:13:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1249679607; bh=xNyEp6JcZLzKwKiwkCsUIlX4A8hTEOnLG21KYC+1adc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ItSGD+xjCEcbJjltcuzyIyfWSkpBgBo7DZ44tP5ORcO7ijRaVBjeXJ1yPr8XAQI2GzfUmKGIZjyuP8DN8od5uKFnzf9TDz4mlcrJur/vJXwEvftehNSNTSRIa/SZrY8Ltb6Sg/qx+UErZIMPxDkfYh/tdyR5wbLVM7mmqsvBjjs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=tFZ9/v9TfMY8eS7bomOfFpTiumGodGPedlUbnKphUXoiyfNqJ4DM0uJlTYal9iZpBN+irZUs7mzdj8aBUuB6CvHY5wb+66SZvXJHZaKF3mGv7sBooAcrQc3UIVxCDiGEgpdNiIeOPMYBIgbuncqL3SUHzUeDnduOdUnR6z+K0IY=; Message-ID: <177335.62005.qm@web24506.mail.ird.yahoo.com> X-YMail-OSG: ERR:encrypt:no_context Received: from [192.100.130.228] by web24506.mail.ird.yahoo.com via HTTP; Fri, 07 Aug 2009 21:13:26 GMT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.289.15 Date: Fri, 7 Aug 2009 21:13:26 +0000 (GMT) From: Mehmet Ersue To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-994603140-1249679606=:62005" Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 21:13:30 -0000 --0-994603140-1249679606=:62005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi Dave,=0A=0Acan you please elaborate a bit how the template will look = like?=0AIs it rather a "Generic Template for Management Data Models"?=0AIs = it for both, MIBs and YAMs?=0A=0AThank you.=0A=0ACheers,=0AMehmet=0A =0A=0A= > -----Original Message-----=0A> From: opsawg-bounces@ietf.org =0A> [mailto= :opsawg-bounces@ietf.org] On Behalf Of ext David Harrington=0A> Sent: Frida= y, August 07, 2009 9:50 PM=0A> To: 'Scott O. Bradner'; opsawg@ietf.org=0A> = Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model=0A> =0A>= Hi,=0A> =0A> This is not about developing a generic data model; it is only= about=0A> developing a template. =0A> The subject line is rather misleadin= g.=0A> =0A> I believe the template belongs on the tools page, and could be= =0A> different templates for different management protocols.=0A> =0A> dbh= =0A> =0A> > -----Original Message-----=0A> > From: opsawg-bounces@ietf.org = =0A> > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner=0A> >= Sent: Friday, August 07, 2009 12:52 PM=0A> > To: opsawg@ietf.org=0A> > Sub= ject: [OPSAWG] opsawg CC @1 - Generic Management Data Model=0A> > =0A> > = =0A> > THe opsawg charter includes milestones for a 'Template for Generic = =0A> > Management Data Models'=0A> > =0A> > There has been no work to date = on such a document (as far as I know)=0A> > =0A> > Dan asked the room in St= ockholm if this item should stay in the=0A> opsawg=0A> > charter.=0A> > =0A= > > The view in the room was none in favor of keeping the document =0A> > a= s a chartered item, 6 against.=0A> > =0A> > please let the list know if you= feel that the milestones =0A> > should be removed=0A> > from the charter o= r if you feel that the working group should still=0A> > develop such a docu= ment. (if you feel that the task should be=0A> > maintaind please suggest s= omeone to be the editor of the document if=0A> > you have any suggestions)= =0A> > =0A> > thanks=0A> > =0A> > Scott=0A> > _____________________________= __________________=0A> > OPSAWG mailing list=0A> > OPSAWG@ietf.org=0A> > ht= tps://www.ietf.org/mailman/listinfo/opsawg=0A> > =0A> =0A> ________________= _______________________________=0A> OPSAWG mailing list=0A> OPSAWG@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/opsawg=0A> =0A=0A=0A=0A --0-994603140-1249679606=:62005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Dave,

can you please elaborate a bit how the template= will look like?
Is it rather a "Generic Template for Management Data Mo= dels"?
Is it for both, MIBs and YAMs?

Thank you.

Cheers,Mehmet
 

> -----Original Message-----
> From: ops= awg-bounces@ietf.org
> [mailto:opsawg-bounces@ietf.org] On Behalf Of= ext David Harrington
> Sent: Friday, August 07, 2009 9:50 PM
>= To: 'Scott O. Bradner'; opsawg@ietf.org
> Subject: Re: [OPSAWG] opsa= wg CC @1 - Generic Management Data Model
>
> Hi,
>
&= gt; This is not about developing a generic data model; it is only about
= > developing a template.
> The subject line is rather misleading.=
>
> I believe the template belongs on the tools page, and could be
> different templates for different management protocols.>
> dbh
>
> > -----Original Message-----
>= ; > From: opsawg-bounces@ietf.org
> > [mailto:opsawg-bounces@i= etf.org] On Behalf Of Scott O. Bradner
> > Sent: Friday, August 07= , 2009 12:52 PM
> > To: opsawg@ietf.org
> > Subject: [OPS= AWG] opsawg CC @1 - Generic Management Data Model
> >
> >= ;
> > THe opsawg charter includes milestones for a 'Template for = Generic
> > Management Data Models'
> >
> > Th= ere has been no work to date on such a document (as far as I know)
> = >
> > Dan asked the room in Stockholm if this item should stay= in the
> opsawg
> > charter.
> >
> > The= view in the room was none in favor of keeping the document
> > a= s a chartered item, 6 against.
> >
> > please let the list know if you feel that the milestones
> > should be remo= ved
> > from the charter or if you feel that the working group sho= uld still
> > develop such a document. (if you feel that the task = should be
> > maintaind please suggest someone to be the editor of= the document if
> > you have any suggestions)
> >
&g= t; > thanks
> >
> > Scott
> > ______________= _________________________________
> > OPSAWG mailing list
> = > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listin= fo/opsawg
> >
>
> _______________________= ________________________
> OPSAWG mailing list
> OPSAWG@ietf.or= g
> https://www.ietf.org= /mailman/listinfo/opsawg
>

=0A=0A=0A = --0-994603140-1249679606=:62005-- From ietfdbh@comcast.net Fri Aug 7 14:56:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BBF3A6978 for ; Fri, 7 Aug 2009 14:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI25o9AhJTi0 for ; Fri, 7 Aug 2009 14:56:08 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id BCD713A6403 for ; Fri, 7 Aug 2009 14:56:07 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id RYvD1c0070SCNGk5AZwBdK; Fri, 07 Aug 2009 21:56:11 +0000 Received: from Harrington73653 ([212.17.132.74]) by OMTA09.westchester.pa.mail.comcast.net with comcast id RZvv1c0041cTpF03VZvzb4; Fri, 07 Aug 2009 21:56:09 +0000 From: "David Harrington" To: "'Mehmet Ersue'" , References: <177335.62005.qm@web24506.mail.ird.yahoo.com> Date: Fri, 7 Aug 2009 23:55:58 +0200 Message-ID: <010301ca17a9$e0e6e2a0$f6000a0a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0104_01CA17BA.A46FB2A0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <177335.62005.qm@web24506.mail.ird.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcoXo+5iPu4gsj76QfmbB4rKNbSR1wAAXdoQ Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 21:56:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0104_01CA17BA.A46FB2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There are templates for developing documents that contain MIB modules. The purpose is to make the layout and content surrounding a MIB fairly consistent, so it makes it easier to review the documents. The template follows the guidelines in RFC4181. If the WG did a generic template, it would look something like http://tools.ietf.org/tools/templates/mib-doc-template-xml.txt, modified to make it less SNMP, SMI, and MIB-specific. A generic template would presumably have the advantage of similarity across interfaces, which could make it easier to review proposed data models, regardless of interface, but we would need to focus on the least common denominator. It could have limited utility because it could only address the least common denominator (or end up having a bunch of conditional clauses that would make it more complex). An alternative would be to define a template for each NM interface. If these are substantially different then it becomes harder to review proposed data models. six of one, half dozen of the other. Juergen has argued this is just a tools issue. In some ways I agree. In some ways I disagree. That is why I developed a template for use with xml2rfc. But xml2rfc does not generate such information in MIB documents by itself; the MIB template helps editors know what sections are recommended and what should go into them following RFC4181 guidelines. Most of the useful content cannot be generated algorithmically by a tool; it must be generated by humans explaining the purpose, layout, dependencies, and security vulnerabilities of the particular MIB module. The template helps provide (inline) advice to editors of MIB documents. dbh _____ From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Mehmet Ersue Sent: Friday, August 07, 2009 11:13 PM To: opsawg@ietf.org Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model Hi Dave, can you please elaborate a bit how the template will look like? Is it rather a "Generic Template for Management Data Models"? Is it for both, MIBs and YAMs? Thank you. Cheers, Mehmet > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of ext David Harrington > Sent: Friday, August 07, 2009 9:50 PM > To: 'Scott O. Bradner'; opsawg@ietf.org > Subject: Re: [OPSAWG] opsawg CC @1 - Generic Management Data Model > > Hi, > > This is not about developing a generic data model; it is only about > developing a template. > The subject line is rather misleading. > > I believe the template belongs on the tools page, and could be > different templates for different management protocols. > > dbh > > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > > Sent: Friday, August 07, 2009 12:52 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] opsawg CC @1 - Generic Management Data Model > > > > > > THe opsawg charter includes milestones for a 'Template for Generic > > Management Data Models' > > > > There has been no work to date on such a document (as far as I know) > > > > Dan asked the room in Stockholm if this item should stay in the > opsawg > > charter. > > > > The view in the room was none in favor of keeping the document > > as a chartered item, 6 against. > > > > please let the list know if you feel that the milestones > > should be removed > > from the charter or if you feel that the working group should still > > develop such a document. (if you feel that the task should be > > maintaind please suggest someone to be the editor of the document if > > you have any suggestions) > > > > thanks > > > > Scott > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > ------=_NextPart_000_0104_01CA17BA.A46FB2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There are templates for developing documents = that contain=20 MIB modules. The purpose is to make the layout and content surrounding a = MIB=20 fairly consistent, so it makes it easier to review the documents. The = template=20 follows the guidelines in RFC4181.
 
If the WG did a generic template, it would look = something=20 like h= ttp://tools.ietf.org/tools/templates/mib-doc-template-xml.txt,=
modified to make it less SNMP, SMI, and=20 MIB-specific.
 
A generic template would presumably have the = advantage of=20 similarity across interfaces, which could make it easier to review = proposed data=20 models, regardless of interface, but we would need to focus on the least = common=20 denominator. It could have limited utility because it could only address = the=20 least common denominator (or end up having a bunch of conditional = clauses that=20 would make it more complex).
 
An alternative would be to define a template = for each NM=20 interface. If these are substantially different then it becomes harder = to review=20 proposed data models.
 
six of one, half dozen of the = other.
 
Juergen has argued this is just a tools issue. = In some ways=20 I agree. In some ways I disagree. That is why I developed a template for = use=20 with xml2rfc. But xml2rfc does not generate such information in MIB = documents by=20 itself; the MIB template helps editors know what sections = are=20 recommended and what should go into them following RFC4181 = guidelines.=20 Most of the useful content cannot be generated algorithmically by a = tool;=20 it must be generated by humans explaining the purpose, layout, = dependencies, and=20 security vulnerabilities of the particular MIB module. The template = helps=20 provide (inline) advice to editors of MIB documents.
 
dbh

From: opsawg-bounces@ietf.org=20 [mailto:opsawg-bounces@ietf.org] On Behalf Of Mehmet=20 Ersue
Sent: Friday, August 07, 2009 11:13 PM
To:=20 opsawg@ietf.org
Subject: Re: [OPSAWG] opsawg CC @1 - Generic = Management Data Model


Hi Dave,

can you please elaborate a bit how the = template will=20 look like?
Is it rather a "Generic Template for Management Data=20 Models"?
Is it for both, MIBs and YAMs?

Thank=20 you.

Cheers,
Mehmet
 

> -----Original=20 Message-----
> From: opsawg-bounces@ietf.org
>=20 [mailto:opsawg-bounces@ietf.org] On Behalf Of ext David = Harrington
>=20 Sent: Friday, August 07, 2009 9:50 PM
> To: 'Scott O. Bradner';=20 opsawg@ietf.org
> Subject: Re: [OPSAWG] opsawg CC @1 - Generic=20 Management Data Model
>
> Hi,
>
> This is = not about=20 developing a generic data model; it is only about
> developing a = template.
> The subject line is rather misleading.
> =
> I=20 believe the template belongs on the tools page, and could be
> = different=20 templates for different management protocols.
>
> = dbh
>=20
> > -----Original Message-----
> > From:=20 opsawg-bounces@ietf.org
> > [mailto:opsawg-bounces@ietf.org] = On=20 Behalf Of Scott O. Bradner
> > Sent: Friday, August 07, 2009 = 12:52=20 PM
> > To: opsawg@ietf.org
> > Subject: [OPSAWG] = opsawg CC=20 @1 - Generic Management Data Model
> >
> >
> = >=20 THe opsawg charter includes milestones for a 'Template for Generic =
>=20 > Management Data Models'
> >
> > There has been = no work=20 to date on such a document (as far as I know)
> >
> = > Dan=20 asked the room in Stockholm if this item should stay in the
>=20 opsawg
> > charter.
> >
> > The view in = the room=20 was none in favor of keeping the document
> > as a chartered = item, 6=20 against.
> >
> > please let the list know if you = feel that=20 the milestones
> > should be removed
> > from the = charter=20 or if you feel that the working group should still
> > = develop such a=20 document. (if you feel that the task should be
> > maintaind = please=20 suggest someone to be the editor of the document if
> > you = have any=20 suggestions)
> >
> > thanks
> >
> = >=20 Scott
> > = _______________________________________________
>=20 > OPSAWG mailing list
> > OPSAWG@ietf.org
> = > https://www.ietf.org/mailman/listinfo/opsawg>=20 >
>
> = _______________________________________________
>=20 OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg>=20

------=_NextPart_000_0104_01CA17BA.A46FB2A0-- From sob@harvard.edu Sat Aug 8 17:06:23 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D6C3A68AB for ; Sat, 8 Aug 2009 17:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWuQKrAzPZzB for ; Sat, 8 Aug 2009 17:06:22 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 9FA5C3A69F1 for ; Sat, 8 Aug 2009 17:06:22 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 3C46E1B93083; Sat, 8 Aug 2009 20:06:24 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090809000624.3C46E1B93083@newdev.eecs.harvard.edu> Date: Sat, 8 Aug 2009 20:06:24 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg - consensus check draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 00:06:23 -0000 draft-ietf-opsawg-operations-and-management was discussed during the opsawg session in Stockholm - it was proposed to retarget this ID to informational from BCP. Also reissue the ID with a few changes and redo the IETF last call targeting informational there were no objections to this proposal in Stockholm please let teh list know if you agree or disagree with this path for this document Scott From ietfdbh@comcast.net Sun Aug 9 01:27:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC953A6966 for ; Sun, 9 Aug 2009 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz+RYpk-SrTr for ; Sun, 9 Aug 2009 01:27:49 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 0D71D3A697B for ; Sun, 9 Aug 2009 01:27:48 -0700 (PDT) Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA02.westchester.pa.mail.comcast.net with comcast id S8Ts1c0031YDfWL528Tswh; Sun, 09 Aug 2009 08:27:52 +0000 Received: from Harrington73653 ([212.17.132.74]) by OMTA20.westchester.pa.mail.comcast.net with comcast id S8Vy1c0021cTpF03g8W11V; Sun, 09 Aug 2009 08:30:08 +0000 From: "David Harrington" To: "'Scott O. Bradner'" , References: <20090809000624.3C46E1B93083@newdev.eecs.harvard.edu> Date: Sun, 9 Aug 2009 10:27:41 +0200 Message-ID: <016001ca18cb$4883b7e0$f6000a0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090809000624.3C46E1B93083@newdev.eecs.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcoYhT79I4KyzaCqQrC/Mww32tIl4AARf8Ow Subject: Re: [OPSAWG] opsawg - consensus checkdraft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 08:27:49 -0000 agree. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Sunday, August 09, 2009 2:06 AM > To: opsawg@ietf.org > Subject: [OPSAWG] opsawg - consensus > checkdraft-ietf-opsawg-operations-and-management > > > draft-ietf-opsawg-operations-and-management was discussed during the > opsawg session in Stockholm - it was proposed to retarget > this ID to informational > from BCP. Also reissue the ID with a few changes and redo the > IETF last call targeting informational > > there were no objections to this proposal in Stockholm > > please let teh list know if you agree or disagree with this path for > this document > > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From SCHISHOL@nortel.com Sun Aug 9 14:07:24 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C663A6B73 for ; Sun, 9 Aug 2009 14:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEiomMXAzigx for ; Sun, 9 Aug 2009 14:07:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CD0463A6B2E for ; Sun, 9 Aug 2009 14:07:23 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n79L7OW10128 for ; Sun, 9 Aug 2009 21:07:24 GMT 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, 9 Aug 2009 17:07:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41A3C7EEC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposals for Edtior's Note for Syslog Alarm Thread-Index: AcoZNWI2GYp9KmhCTwWn23mGhrslYg== From: "Sharon Chisholm" To: Subject: [OPSAWG] Proposals for Edtior's Note for Syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:07:24 -0000 Hi Here are the proposals for editor's notes to resolve issues raised during IESG last call against the Syslog Alarm Id In section 1,=20 Old:Alarm related terminology is defined in [RFC3877]. New:Alarm related terminology is defined in [RFC3877]. SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424]=20 In section 3 Old: the SD-PARARMS are mandatory. New: the SD-PARAMS are mandatory. =20 In section 3.6 Old: [RFC1738] and its updates. In the case of an SNMP resource, the New: [RFC3986] and its updates. In the case of an SNMP resource, the =20 In section 4 Old: In this example, extended from [Syslog], the VERSION is 1 and the New: In this example, extended from [RFC5424], the VERSION is 1 and the In section 6 Old: IANA is requested to register the SD-IDs New: IANA is requested to register the syslog Structured Data ID Values =20 In section 8.1 Old: [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. New: [RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", RFC RFC3986, January 2005. Sharon Chisholm Nortel Ottawa, Ontario Canada From dromasca@avaya.com Mon Aug 10 02:38:29 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971273A6DFE for ; Mon, 10 Aug 2009 02:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdbMdHOG2BZ7 for ; Mon, 10 Aug 2009 02:38:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5CF043A6DF8 for ; Mon, 10 Aug 2009 02:38:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,352,1246852800"; d="scan'208";a="153524670" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Aug 2009 05:38:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Aug 2009 05:38:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 11:38:11 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41A3C7EEC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Proposals for Edtior's Note for Syslog Alarm Thread-Index: AcoZNWI2GYp9KmhCTwWn23mGhrslYgAaLYzQ References: <713043CE8B8E1348AF3C546DBE02C1B41A3C7EEC@zcarhxm2.corp.nortel.com> From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Subject: Re: [OPSAWG] Proposals for Edtior's Note for Syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 09:38:29 -0000 Thanks, Sharon.=20 The agenda for this week IESG telechat was already very crowded, so I placed the document on the agenda of the 8/27 IESG telechat.=20 Regards, Dan =20 > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Monday, August 10, 2009 12:07 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Proposals for Edtior's Note for Syslog Alarm >=20 > Hi >=20 > Here are the proposals for editor's notes to resolve issues=20 > raised during IESG last call against the Syslog Alarm Id >=20 >=20 >=20 > In section 1,=20 >=20 > Old:Alarm related terminology is defined in [RFC3877]. >=20 >=20 > New:Alarm related terminology is defined in [RFC3877]. >=20 > SD-ID, SD-PARM and other syslog related terms are defined in=20 > [RFC5424]=20 >=20 >=20 >=20 >=20 > In section 3 >=20 > Old: the SD-PARARMS are mandatory. >=20 > New: the SD-PARAMS are mandatory. >=20 > =20 >=20 > In section 3.6 >=20 > Old: [RFC1738] and its updates. In the case of an SNMP resource, the >=20 > New: [RFC3986] and its updates. In the case of an SNMP resource, the >=20 > =20 >=20 > In section 4 >=20 > Old: In this example, extended from [Syslog], the VERSION is 1 and the >=20 > New: In this example, extended from [RFC5424], the VERSION is=20 > 1 and the >=20 >=20 >=20 > In section 6 >=20 > Old: IANA is requested to register the SD-IDs >=20 > New: IANA is requested to register the syslog Structured Data=20 > ID Values >=20 >=20 > =20 >=20 > In section 8.1 >=20 > Old: [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, > "Uniform > Resource Locators (URL)", RFC 1738, December 1994. >=20 > New: [RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., > "Uniform Resource Identifier (URI): Generic Syntax", RFC=20 > RFC3986, January 2005. >=20 >=20 >=20 > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From ben@estacado.net Mon Aug 10 13:33:13 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDBD28C222; Mon, 10 Aug 2009 13:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYbzdIqgwZ0D; Mon, 10 Aug 2009 13:33:12 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 4CEDE3A6EE2; Mon, 10 Aug 2009 13:33:12 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n7AKX2S3066244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 15:33:02 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <104E6E90-836A-427B-A034-FEFB95B6E693@estacado.net> From: Ben Campbell To: Juergen Schoenwaelder In-Reply-To: <20090806145002.GA849@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 15:33:02 -0500 References: <20090806145002.GA849@elstar.local> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 11 Aug 2009 01:42:28 -0700 Cc: Niclas Comstedt , Avshalom Houri , Magnus Nystroem , opsawg-chairs@ietf.org, iesg@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG / SNMP translation IETF last call followup X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:33:13 -0000 Hi, I believe that your responses adequately address my comments. Thanks! Ben. On Aug 6, 2009, at 9:50 AM, Juergen Schoenwaelder wrote: > We received several minor IETF last call comments on the two IDs: > > draft-ietf-opsawg-syslog-msg-mib-04.txt > draft-ietf-opsawg-syslog-snmp-03.txt > > Attached to this document is a response to the non-editorial comments > that were made. I have also posted new IDs reflecting the changes that > came out of the IETF last call reviews: > > draft-ietf-opsawg-syslog-msg-mib-05.txt > draft-ietf-opsawg-syslog-snmp-04.txt > > Dan, please review the response / changes and if you are fine, please > forward the document to the IESG. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From dromasca@avaya.com Thu Aug 13 09:23:15 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2EF3A6ACD for ; Thu, 13 Aug 2009 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOEDlISkjqct for ; Thu, 13 Aug 2009 09:23:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 573453A6804 for ; Thu, 13 Aug 2009 09:23:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,375,1246852800"; d="scan'208";a="153918985" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Aug 2009 12:21:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 Aug 2009 12:21:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 18:21:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Today's telechat Thread-Index: AcocMh8z07tz7wSAQ06/9kt80YaP+g== From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: opsawg@ietf.org Subject: [OPSAWG] Today's telechat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:23:15 -0000 The IESG discussed the two OPSAWG documents in the telechat today:=20 - draft-ietf-opsawg-syslog-snmp-04 has one open DISCUSS from Alexey and an number of agreed edits resulting from a DISCUSS from Lars. Juergen agreed to issue a revised ID and I expect this new version to get the pending DISCUSS cleared easily =20 - draft-ietf-opsawg-syslog-msg-mib-05 has four pending DISCUSSes. Although most of the edits are clear there is some more work to finalize them completely. This also goes into Revised ID.=20 I expect Juergen to work in the next few days on revisions for the two documents/ Thanks for the good work Dan=20 From root@core3.amsl.com Thu Aug 13 13:15:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C4F2328C1D3; Thu, 13 Aug 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090813201501.C4F2328C1D3@core3.amsl.com> Date: Thu, 13 Aug 2009 13:15:01 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author(s) : J. Schoenwaelder, et al. Filename : draft-ietf-opsawg-syslog-msg-mib-06.txt Pages : 23 Date : 2009-08-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-msg-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-13131312.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Aug 13 13:15:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CFBFB28C204; Thu, 13 Aug 2009 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090813201501.CFBFB28C204@core3.amsl.com> Date: Thu, 13 Aug 2009 13:15:01 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-snmp-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages Author(s) : V. Marinov, J. Schoenwaelder Filename : draft-ietf-opsawg-syslog-snmp-05.txt Pages : 15 Date : 2009-08-13 This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsawg-syslog-snmp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-13131323.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Thu Aug 13 13:32:27 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A92328C24D for ; Thu, 13 Aug 2009 13:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTTiloW5GiSX for ; Thu, 13 Aug 2009 13:32:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DDB9E28C1AF for ; Thu, 13 Aug 2009 13:32:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEDBBC00BB; Thu, 13 Aug 2009 22:19:24 +0200 (CEST) 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 cZga0jvrl3Kd; Thu, 13 Aug 2009 22:19:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0DD6C00BA; Thu, 13 Aug 2009 22:19:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0698DC673DC; Thu, 13 Aug 2009 22:19:22 +0200 (CEST) Date: Thu, 13 Aug 2009 22:19:22 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090813201922.GA15949@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Today's telechat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:32:27 -0000 On Thu, Aug 13, 2009 at 06:21:33PM +0200, Romascanu, Dan (Dan) wrote: > The IESG discussed the two OPSAWG documents in the telechat today: > > - draft-ietf-opsawg-syslog-snmp-04 > > has one open DISCUSS from Alexey and an number of agreed edits resulting > from a DISCUSS from Lars. Juergen agreed to issue a revised ID and I > expect this new version to get the pending DISCUSS cleared easily > > - draft-ietf-opsawg-syslog-msg-mib-05 > > has four pending DISCUSSes. Although most of the edits are clear there > is some more work to finalize them completely. This also goes into > Revised ID. > > I expect Juergen to work in the next few days on revisions for the two > documents/ Thanks for the good work I just submitted revised IDs - they should show up on the tools page shortly where you can easily spot the changes. The biggest change is the replacement of SnmpAdminString with a new special purpose TC to get rid of the 255 octet restriction of SnmpAdminString. All the other changes are basically clarifications or ABNF bug fixes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sob@harvard.edu Thu Aug 13 17:05:50 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501513A6D4A for ; Thu, 13 Aug 2009 17:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY1vFUZ+H0tm for ; Thu, 13 Aug 2009 17:05:49 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id B6A153A6D40 for ; Thu, 13 Aug 2009 17:05:49 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 7A7F01BC4D28; Thu, 13 Aug 2009 20:05:53 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090814000553.7A7F01BC4D28@newdev.eecs.harvard.edu> Date: Thu, 13 Aug 2009 20:05:53 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg - draft-opsawg-survey-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:05:50 -0000 At the opsawg session in Stockholm Dave said that he would not be able to continue as editor of draft-opsawg-survey-management. This is a call for volunteers to take on that job. thanks Scott From sob@harvard.edu Thu Aug 20 17:59:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F053A6D71 for ; Thu, 20 Aug 2009 17:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtxFKe6J-kOy for ; Thu, 20 Aug 2009 17:59:27 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 7FC243A6B13 for ; Thu, 20 Aug 2009 17:59:27 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id D35601BF4863; Thu, 20 Aug 2009 20:59:32 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> Date: Thu, 20 Aug 2009 20:59:32 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:59:28 -0000 the SNMP Lock & lock MIB documents were dicussed during the Stockholm meeting - the room was asked if they should become opsawg documents no one raised their hand to indicate that they were against the idea but only a few people raised their hands in favor the IDs are draft-fan-meng-snmp-lock draft meng-fan-lock-mib please express your opinion to the list tnx Scott From ietfdbh@comcast.net Thu Aug 20 18:28:21 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363123A6BE6 for ; Thu, 20 Aug 2009 18:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcoCq25SrVo3 for ; Thu, 20 Aug 2009 18:28:20 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 330083A6B72 for ; Thu, 20 Aug 2009 18:28:19 -0700 (PDT) Received: from OMTA23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Wo7M1c0021c6gX859pURlB; Fri, 21 Aug 2009 01:28:25 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA23.westchester.pa.mail.comcast.net with comcast id WpXw1c00M0UQ6dC3jpXwHm; Fri, 21 Aug 2009 01:31:56 +0000 From: "David Harrington" To: "'Scott O. Bradner'" , References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> Date: Thu, 20 Aug 2009 21:28:23 -0400 Message-ID: <011901ca21fe$acaf4d60$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acoh+qeMv2UZ4ZxMRxeN/Zkei7OihAAAKEgA Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 01:28:21 -0000 Hi, I think the lock-mib would be a useful monitoring tool. the IETF is moving toward a multi-protocol management approach, to support the real-world multi-protocol approach to NM. The IETF is designing NM protocols with locks that impact SNMP. It is important to allow operators to see what locks are impacting SNMP. The SNMP lock is less urgent. SNMP has no decent lock capability. With the emerging changes to SNMP, such as session-based transports, and new NM protocol standards, I think support for locking in SNMP could be needed. This is an optional feature that implementers can choose to implement or not; it is not being proposed as a mandatory-to-implement feature in SNMP. Since OPSAWG is handling many of the multi-NM-protocol coordination issues already, I believe this is the appropriate WG to take on this task, and as with many of the other proposals in this WG, this does not look like a resource-intensive work item. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Thursday, August 20, 2009 9:00 PM > To: opsawg@ietf.org > Subject: [OPSAWG] opsawg consensus check > > > the SNMP Lock & lock MIB documents were dicussed during the Stockholm > meeting - the room was asked if they should become opsawg documents > > no one raised their hand to indicate that they were against the > idea but only a few people raised their hands in favor > > > the IDs are > draft-fan-meng-snmp-lock > draft meng-fan-lock-mib > > please express your opinion to the list > > tnx > > Scott > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From j.schoenwaelder@jacobs-university.de Thu Aug 20 23:30:45 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997873A6A5F for ; Thu, 20 Aug 2009 23:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyhvckOecgNx for ; Thu, 20 Aug 2009 23:30:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3FADC3A6B60 for ; Thu, 20 Aug 2009 23:30:43 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 844E0C0004; Fri, 21 Aug 2009 08:30:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gGyjoMlxrUw9; Fri, 21 Aug 2009 08:30:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0C92C0007; Fri, 21 Aug 2009 08:30:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 63067C764F3; Fri, 21 Aug 2009 08:30:45 +0200 (CEST) Date: Fri, 21 Aug 2009 08:30:45 +0200 From: Juergen Schoenwaelder To: "Scott O. Bradner" Message-ID: <20090821063045.GA11436@elstar.local> Mail-Followup-To: "Scott O. Bradner" , "opsawg@ietf.org" References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 06:30:45 -0000 On Fri, Aug 21, 2009 at 02:59:32AM +0200, Scott O. Bradner wrote: > > the SNMP Lock & lock MIB documents were dicussed during the Stockholm > meeting - the room was asked if they should become opsawg documents > > no one raised their hand to indicate that they were against the > idea but only a few people raised their hands in favor > > > the IDs are > draft-fan-meng-snmp-lock > draft meng-fan-lock-mib > > please express your opinion to the list I suggest the authors of these documents take the feedback from the WG meeting in Stockholm and the mailing discussion as input to produce revised IDs where the motivation and scope for this work becomes clearer. This will give us a much better basis to take a decision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Fri Aug 21 00:07:41 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3777C3A6A74 for ; Fri, 21 Aug 2009 00:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.126 X-Spam-Level: ** X-Spam-Status: No, score=2.126 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_40=-0.185, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvIepWAiUILs for ; Fri, 21 Aug 2009 00:07:40 -0700 (PDT) Received: from relay.versatel.net (relay54.tele2.vuurwerk.nl [62.250.3.54]) by core3.amsl.com (Postfix) with ESMTP id DEE5C3A6DD0 for ; Fri, 21 Aug 2009 00:07:39 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1MeODw-0004jx-GO; Fri, 21 Aug 2009 09:07:44 +0200 Message-ID: <809E0A9BAFAE4E9294C32BCF11292549@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Juergen Schoenwaelder" , "Scott O. Bradner" References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> <20090821063045.GA11436@elstar.local> In-Reply-To: <20090821063045.GA11436@elstar.local> Date: Fri, 21 Aug 2009 09:07:27 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1CCF_01CA223E.CE1E9D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 07:07:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1CCF_01CA223E.CE1E9D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Scott O. Bradner=20 Cc: opsawg@ietf.org=20 Sent: Friday, August 21, 2009 8:30 AM Subject: Re: [OPSAWG] opsawg consensus check On Fri, Aug 21, 2009 at 02:59:32AM +0200, Scott O. Bradner wrote: >=20 > the SNMP Lock & lock MIB documents were dicussed during the = Stockholm > meeting - the room was asked if they should become opsawg documents >=20 > no one raised their hand to indicate that they were against the > idea but only a few people raised their hands in favor=20 >=20 >=20 > the IDs are > draft-fan-meng-snmp-lock > draft meng-fan-lock-mib >=20 > please express your opinion to the list I suggest the authors of these documents take the feedback from the WG meeting in Stockholm and the mailing discussion as input to produce revised IDs where the motivation and scope for this work becomes clearer. This will give us a much better basis to take a decision. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -------------------------------------------------------------------------= ----- No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date: = 08/20/09 06:05:00 ------=_NextPart_000_1CCF_01CA223E.CE1E9D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Friday, August 21, 2009 = 8:30=20 AM
Subject: Re: [OPSAWG] opsawg = consensus=20 check

On Fri, Aug 21, 2009 at 02:59:32AM +0200, Scott O. = Bradner=20 wrote:
>
> the SNMP Lock & lock MIB documents were = dicussed=20 during the Stockholm
> meeting - the room was asked if they = should=20 become opsawg documents
>
> no one raised their hand to = indicate=20 that they were against the
> idea but only a few people raised = their=20 hands in favor
>
>
> the IDs are
>=20 draft-fan-meng-snmp-lock
> draft meng-fan-lock-mib
> =
>=20 please express your opinion to the list

I suggest the authors = of these=20 documents take the feedback from the WG
meeting in Stockholm and = the=20 mailing discussion as input to produce
revised IDs where the = motivation and=20 scope for this work becomes
clearer. This will give us a much = better basis=20 to take a decision.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg


No virus found in this incoming message.
Checked by AVG = - www.avg.com
Version: 8.5.409 / = Virus=20 Database: 270.13.62/2315 - Release Date: 08/20/09=20 06:05:00
------=_NextPart_000_1CCF_01CA223E.CE1E9D30-- From tena@huawei.com Fri Aug 21 01:46:16 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB343A67D8 for ; Fri, 21 Aug 2009 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.584 X-Spam-Level: *** X-Spam-Status: No, score=3.584 tagged_above=-999 required=5 tests=[AWL=4.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80eWydltTKQJ for ; Fri, 21 Aug 2009 01:46:15 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3C9503A68BC for ; Fri, 21 Aug 2009 01:46:15 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP004I0XOXUI@szxga01-in.huawei.com> for opsawg@ietf.org; Fri, 21 Aug 2009 16:46:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP00G1FXOXV4@szxga01-in.huawei.com> for opsawg@ietf.org; Fri, 21 Aug 2009 16:46:09 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOP000VEXOX70@szxml06-in.huawei.com> for opsawg@ietf.org; Fri, 21 Aug 2009 16:46:09 +0800 (CST) Date: Fri, 21 Aug 2009 16:46:08 +0800 From: Tina TSOU To: "Scott O. Bradner" , Juergen Schoenwaelder , "Bert Wijnen (IETF)" Message-id: <00f701ca223b$d398ecf0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_FRcudIpEdZRmnLopM8ewwA)" X-Priority: 3 X-MSMail-priority: Normal References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> <20090821063045.GA11436@elstar.local> <809E0A9BAFAE4E9294C32BCF11292549@BertLaptop> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 08:46:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FRcudIpEdZRmnLopM8ewwA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT +1 B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Bert Wijnen (IETF) To: Juergen Schoenwaelder ; Scott O. Bradner Cc: opsawg@ietf.org Sent: Friday, August 21, 2009 3:07 PM Subject: Re: [OPSAWG] opsawg consensus check +1 ----- Original Message ----- From: Juergen Schoenwaelder To: Scott O. Bradner Cc: opsawg@ietf.org Sent: Friday, August 21, 2009 8:30 AM Subject: Re: [OPSAWG] opsawg consensus check On Fri, Aug 21, 2009 at 02:59:32AM +0200, Scott O. Bradner wrote: > > the SNMP Lock & lock MIB documents were dicussed during the Stockholm > meeting - the room was asked if they should become opsawg documents > > no one raised their hand to indicate that they were against the > idea but only a few people raised their hands in favor > > > the IDs are > draft-fan-meng-snmp-lock > draft meng-fan-lock-mib > > please express your opinion to the list I suggest the authors of these documents take the feedback from the WG meeting in Stockholm and the mailing discussion as input to produce revised IDs where the motivation and scope for this work becomes clearer. This will give us a much better basis to take a decision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ---------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date: 08/20/09 06:05:00 ------------------------------------------------------------------------------ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_FRcudIpEdZRmnLopM8ewwA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
+1
 
 
----- Original Message -----
Sent: Friday, August 21, 2009 3:07 PM
Subject: Re: [OPSAWG] opsawg consensus check

+1
----- Original Message -----
Sent: Friday, August 21, 2009 8:30 AM
Subject: Re: [OPSAWG] opsawg consensus check

On Fri, Aug 21, 2009 at 02:59:32AM +0200, Scott O. Bradner wrote:
>
> the SNMP Lock & lock MIB documents were dicussed during the Stockholm
> meeting - the room was asked if they should become opsawg documents
>
> no one raised their hand to indicate that they were against the
> idea but only a few people raised their hands in favor
>
>
> the IDs are
> draft-fan-meng-snmp-lock
> draft meng-fan-lock-mib
>
> please express your opinion to the list

I suggest the authors of these documents take the feedback from the WG
meeting in Stockholm and the mailing discussion as input to produce
revised IDs where the motivation and scope for this work becomes
clearer. This will give us a much better basis to take a decision.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date: 08/20/09 06:05:00

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--Boundary_(ID_FRcudIpEdZRmnLopM8ewwA)-- From wjhns1@hardakers.net Fri Aug 21 08:05:45 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1363A6DC3 for ; Fri, 21 Aug 2009 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mj1mGU+515n for ; Fri, 21 Aug 2009 08:05:44 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 07C9F3A6831 for ; Fri, 21 Aug 2009 08:05:43 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 860769805E; Fri, 21 Aug 2009 08:05:46 -0700 (PDT) From: Wes Hardaker To: sob@harvard.edu (Scott O. Bradner) Organization: Sparta References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> Date: Fri, 21 Aug 2009 08:05:46 -0700 In-Reply-To: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> (Scott O. Bradner's message of "Thu, 20 Aug 2009 20:59:32 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:05:45 -0000 >>>>> On Thu, 20 Aug 2009 20:59:32 -0400 (EDT), sob@harvard.edu (Scott O. Bradner) said: SOB> the SNMP Lock & lock MIB documents were dicussed during the Stockholm SOB> meeting - the room was asked if they should become opsawg documents I agree that reading something more concrete based on the suggestions would be good. But the fundamental problem is: is the problem real enough we should be working on it, and I think it is so I'm in favor of a solution. Which solution is a different question. Cross-protocol locks, unfortunately, are difficult. Especially when trying to write generic support code. I've had conversations with people that aren't sure how'd they'd implement the netconf locking requirements. It's a system-wide feature requirement so it's actually impossible to stamp a "RFC4741 Locking Compliant" stamp on a agent development package. Because it's impossible. The system has to make sure the lock is enforced everywhere, which a software provider can't do. Because the complexity of simple locks can be difficult depending on the system, I think management of them from *every* protocol affect is an absolute MUST. -- Wes Hardaker Cobham Analytic Solutions From tena@huawei.com Sun Aug 23 19:38:34 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCAB3A6D46 for ; Sun, 23 Aug 2009 19:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.634 X-Spam-Level: **** X-Spam-Status: No, score=4.634 tagged_above=-999 required=5 tests=[AWL=2.714, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s6yC37bBAMB for ; Sun, 23 Aug 2009 19:38:34 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 428B13A68D0 for ; Sun, 23 Aug 2009 19:38:29 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOV00G7Y0O0G4@szxga02-in.huawei.com> for opsawg@ietf.org; Mon, 24 Aug 2009 10:38:24 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOV00LGY0O0Q4@szxga02-in.huawei.com> for opsawg@ietf.org; Mon, 24 Aug 2009 10:38:24 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOV00HQ80O0P2@szxml06-in.huawei.com> for opsawg@ietf.org; Mon, 24 Aug 2009 10:38:24 +0800 (CST) Date: Mon, 24 Aug 2009 10:38:23 +0800 From: Tina TSOU To: "Scott O. Bradner" , opsawg@ietf.org Message-id: <009e01ca2463$f3d3d9b0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_alsIs0OkkLP0+7lMGkmiJg)" X-Priority: 3 X-MSMail-priority: Normal References: <20090814000553.7A7F01BC4D28@newdev.eecs.harvard.edu> Subject: Re: [OPSAWG] opsawg - draft-opsawg-survey-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 02:38:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_alsIs0OkkLP0+7lMGkmiJg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I volunteer to do the work. It has been a nice draft. What does it need to be updated immediately? B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Friday, August 14, 2009 8:05 AM Subject: [OPSAWG] opsawg - draft-opsawg-survey-management At the opsawg session in Stockholm Dave said that he would not be able to continue as editor of draft-opsawg-survey-management. This is a call for volunteers to take on that job. thanks Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_alsIs0OkkLP0+7lMGkmiJg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
I volunteer to do the work.
It has been a nice draft. What does it need to be updated immediately?
 
 
B. R.
Tina
----- Original Message -----
Sent: Friday, August 14, 2009 8:05 AM
Subject: [OPSAWG] opsawg - draft-opsawg-survey-management


At the opsawg session in Stockholm Dave said that he would not
be able to continue as editor of draft-opsawg-survey-management.

This is a call for volunteers to take on that job.

thanks

Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--Boundary_(ID_alsIs0OkkLP0+7lMGkmiJg)-- From randy_presuhn@mindspring.com Tue Aug 25 12:15:20 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B8228C51B for ; Tue, 25 Aug 2009 12:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mayioh6x1kI0 for ; Tue, 25 Aug 2009 12:15:20 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id CD75B28C4FF for ; Tue, 25 Aug 2009 12:15:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VjEyEXdTytJCz+x2SeQNjDYODYZQiCByTDt5kPNPXRsz8HQ7GWtu/RPmiNicd8T9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.54.141] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mg1U1-0000cw-SH for opsawg@ietf.org; Tue, 25 Aug 2009 15:15:06 -0400 Message-ID: <00e301ca25b8$c624ef80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> Date: Tue, 25 Aug 2009 12:18:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f94e193274073c42f7624463c56841b63f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.141 Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 19:15:20 -0000 Hi - > From: "Wes Hardaker" > To: "Scott O. Bradner" > Cc: > Sent: Friday, August 21, 2009 8:05 AM > Subject: Re: [OPSAWG] opsawg consensus check ... > Cross-protocol locks, unfortunately, are difficult. Especially when > trying to write generic support code. I've had conversations with > people that aren't sure how'd they'd implement the netconf locking > requirements. It's a system-wide feature requirement so it's actually > impossible to stamp a "RFC4741 Locking Compliant" stamp on a agent > development package. Because it's impossible. The system has to make > sure the lock is enforced everywhere, which a software provider can't > do. To me the problem looks more and more like Byzantine agreement, particularly if we have no way of ensuring that the access control models of the various protocols will have been configured to provide a coherent policy, and if we admit the reality that there will be inconsistencies in how the information is modelled and thereby constrained in the different protocol environments. Assuming the implementations are error-free, of course. :-) > Because the complexity of simple locks can be difficult depending on the > system, I think management of them from *every* protocol affect is an > absolute MUST. And there's the rub. Retro-fitting SNMP, for example, would require digging into AgentX, SNMP proxy, and the various proprietary subagent mechanisms. This would keep someone busy for a long time. There may be lessons to be learned here from the world of configuration management. (As in Webdav, CVS, SCCS, RCS, .... ) Randy From dromasca@avaya.com Wed Aug 26 08:20:52 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9F33A6902; Wed, 26 Aug 2009 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynjn9oUwBP72; Wed, 26 Aug 2009 08:20:51 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id B86823A6CA8; Wed, 26 Aug 2009 08:20:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,279,1249272000"; d="txt'?scan'208";a="171429354" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 26 Aug 2009 11:17:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Aug 2009 11:17:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA2660.4F99FB60" Date: Wed, 26 Aug 2009 17:17:21 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Final Minutes of the OPSAWG meeting at IETF-75 Thread-Index: AcomYE7tmgUVb7svQGmXi8VR/1dUKQ== From: "Romascanu, Dan (Dan)" To: Cc: opsawg@ietf.org Subject: [OPSAWG] Final Minutes of the OPSAWG meeting at IETF-75 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 15:20:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2660.4F99FB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find attached the final minutes of the OPSAWG meeting at IETF-75. I have included all comments that I have received after the preliminary minutes were submitted a few weeks ago. Please upload these for the proceedings, as I have no access to the Meeting Materials tools for the WG (or maybe Scott can do this).=20 Thanks and Regards, Dan ------_=_NextPart_001_01CA2660.4F99FB60 Content-Type: text/plain; name="stockholm_opsawg_minutes.txt" Content-Transfer-Encoding: base64 Content-Description: stockholm_opsawg_minutes.txt Content-Disposition: attachment; filename="stockholm_opsawg_minutes.txt" T1BTQVdHIG1lZXRpbmcgbm90ZXMNCklFVEYgNzUsIFN0b2NraG9sbSwgSnVseSAyOQ0KDQoNCjEu IFdlbGNvbWUgYW5kIGFnZW5kYSBiYXNoaW5nDQoNCkRhbiBSb21hc2NhbnU6IA0KU2NvdHQgY2Fu bm90IGpvaW4gcGh5c2ljYWxseSB0byBjaGFpciB0aGUgc2Vzc2lvbi4NCkRhbiBhbmQgUm9uIHNp dCBpbiBmb3IgU2NvdHQuDQpObyByZXF1ZXN0cyBmb3IgY2hhbmdpbmcgdGhlIGFnZW5kYQ0KDQoN CjIuIFdHIHN0YXR1cw0KDQpEYW46DQpEb2N1bWVudHMgaW4gb3IgYWZ0ZXIgSUVURiBsYXN0IGNh bGw6DQogIC0gbWFwcGluZyBTTk1QIHRvIFN5c2xvZw0KICAtIG1hcHBpbmcgU3lzbG9nIHRvIFNO TVANCiAgLSBTTUkgZGF0YXR5cGVzIGluIFhNTA0KTmV3IHJldmlzaW9ucyBhcmUgbmVlZGVkIGZv ciBhbGwgb2YgdGhlbS4NCg0KTWlsZXN0b25lIHJldmlldzoNCg0KVGhlcmUgaXMgYW4gb3BlbiBt aWxlc3RvbmUgb24gYSB0ZW1wbGF0ZSBmb3IgZ2VuZXJpYyBtYW5hZ2VtZW50IGRhdGEgbW9kZWxz LiBUaGVyZSBpcyBubyBwcm9ncmVzcyBvbiB0aGlzLiBJdCBtaWdodCBiZSB0aGUgcmlnaHQgIGlk ZWEgdG8gdGFrZSBpdCBvZmYgdGhlIGNoYXJ0ZXIuIA0KDQpEYXZpZCBIYXJyaW5ndG9uOiANClRo ZXJlIGlzIGEgbmVlZCBmb3IgdGhpcyBkb2N1bWVudC4gYmVjYXVzZSBwZW9wbGUgYXJlIGRlZmlu aW5nIA0KZGF0YSBtb2RlbHMgaW4gc2V2ZXJhbCBXR3MuIFdlIGhhdmUgaWRlYXMgd2hhdCB0byB3 cml0ZSBidXQgZGlkIA0Kbm90IHlldCBmaW5kIHRpbWUgZm9yIGRvaW5nIHNvLiBJdCBpcyBub3Qg bXVjaCB3b3JrIHRvIGJlIGRvbmUuDQoNCkRhbjogDQpEbyB3ZSBoYXZlIGVub3VnaCBiYWNrZ3Jv dW5kIGluIGV2ZXJ5dGhpbmcgbm93IHRoYXQgd2UgY2FuIHByb2R1Y2UgdGhlIGRvY3VtZW50IGlu IHRoZSBmaXJzdCBwbGFjZT8NCg0KRGF2aWQgSGFycmluZ3RvbjogDQpJIGJlbGlldmUgc28geWVz LiAgVGhlIGRvY3VtZW50IGhhcyBtb3N0IG9mIHRoZSBjb21wb25lbnRzIHRoYXQgaXQgbmVlZHMg bm93LiAgTWFueSBvZiB0aGUgYm9pbGVyIHBsYXRlcyBqdXN0IG5lZWQgdXBkYXRpbmcgdG8gYmUg Im1vcmUgZ2VuZXJpYyIuICBNdWNoIG9mIHRoZSBkb2N1bWVudCBpcyB2ZXJ5IE1JQi13b3JkZWQg YW5kIGNvdWxkIHVzZSBzb21lIGdlbmVyaWMgd29yZGluZyByZXBsYWNlbWVudHMuDQoNCkRhbiBS b21hc2NhbnU6IA0KV2UgaGF2ZSBhIGxvdCBvZiBjb21tb24gYW5kIGFncmVlZC1lZCB1cG9uIHRl eHQgYWJvdXQgTUlCIG1vZHVsZXMsIGV0Yy4gIEknbSBub3Qgc3VyZSB0aGF0IGFncmVlbWVudCBl eGlzdHMgYWJvdXQgY29tbW9uIGluZm9ybWF0aW9uIG1vZGVscy4NCg0KRGF2aWQgSGFycmluZ3Rv bjogDQpUaGF0J3MgcHJvYmFibHkgdHJ1ZS4gIEl0IHdhcyBkZWNpZGVkIHRvIHB1dCB0aGUgZG9j dW1lbnQgdGVtcGxhdGVzIG9uIHRoZSB0b29scyBwYWdlIGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxk IGp1c3QgcG9pbnQgdG8gdGhlIHRvb2xzIHBhZ2UuICBUaGF0J3MgcHJvYmFibHkgd2hhdCBuZWVk cyB0byBiZSBkb25lIGZvciBhIGdlbmVyaWMgbWFuYWdlbWVudCBtb2RlbCBhcyB3ZWxsIGluIG9y ZGVyIHRvIGtlZXAgaXQgY3VycmVudC4gT3RoZXIgV0dzIGFyZSBwb3NzaWJseSBnb2luZyB0byBj cmVhdGUgdmFyaW91cyBib2lsZXIgcGxhdGVzIChzeXNsb2csIHlhbmcgYXMgRUdzKSBhbmQgSSBk byBiZWxpZXZlIHRoZXJlIGlzIGEgbG90IG9mIGNvbW1vbiB0ZXh0IHRoZXJlLg0KDQoNCkp1ZXJn ZW4gU2Nob2Vud2FlbGRlcjoNCkkgcHJlZmVyIHRvIGhhdmUgc2VwYXJhdGUgZG9jdW1lbnRzIGZv ciBkaWZmZXJlbnQgY2FzZXMgaW4gZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzLiBUaGUgbWFqb3Ig aXNzdWVzIGFyZSBzcGVjaWZpYyB0byB0aGUgcmVzcGVjdGl2ZSB0b3BpYy4gWWFuZywgc3lzbG9n IGFuZCBJUEZJWCwgZm9yIGV4YW1wbGUsIHJhdGhlciAgbmVlZCBpbmRpdmlkdWFsIHRlbXBsYXRl cyB0aGF0IG5lZWQgdG8gYmUgZGV2ZWxvcGVkIGluIHRoZSByZXNwZWN0aXZlIFdHcy4NCg0KRGF2 aWQ6DQpUaGUgZG9jdW1lbnQgSSBhbSB0aGlua2luZyBvZiB3b3VsZCBwb2ludCB0byBpbmRpdmlk dWFsIHRlbXBsYXRlcy4gSXQgd291bGQgbm90IGJlIGEgb25lIGZvciBhbGwgc29sdXRpb24gLGJ1 dCB3b3VsZCBoZWxwIHBlb3BsZSBmaW5kaW5nIHRoZSByaWdodCB0ZW1wbGF0ZSB6byB1c2UuDQoN CkRhbjoNCldlIGhhdmUgdGhlIHRvb2xzIHBhZ2UgZm9yIHRoYXQgcHVycG9zZS4NCg0KRGF2aWQ6 DQpQZW9wbGUgZG8gbm90IGZpbmQgaXQgb24gdGhlIHRvb2xzIHBhZ2UuDQoNCldlcyBIYXJkYWtl cjoNClRoaXMgd291bGQgYmUgYW4gUkZDIHdpdGggYWxtb3N0IG5vdGhpbmcgaW4uIEknbSBub3Qg c3VyZSB0aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gZ28uIFJGQ3MgYXJlIG5vdCB0aGUgaW5kZXgg d2hlcmUgYW55Ym9keSBzdGFydHMgbG9va2luZy4NCg0KUm9uIEJvbmljYToNCkkgYWdyZWUgdG8g V2VzLiBXZSBkb24ndCBuZWVkIHRoZSBhdXRob3JpdHkgZm9yIHRoZSBJRVRGIGZvciBwb2ludGlu Zw0KcGVvcGxlIHRvIHRvb2xzLiBUaGUgdG9vbHMgcGFnZSBpcyB0aGUgcmlnaHQgcGxhY2UgZm9y IGFuIGluZGV4Lg0KDQpEYXZpZDoNCldoZW4gd2Ugd3JvdGUgdGhlIGNoYXJ0ZXIsIHRoZSB0b29s cyBwYWdlIHdhcyBtdWNoIGxlc3MgdXNlZC4NCg0KRGFuOg0KV2UgZG9uJ3QgaGF2ZSBjb25zZW5z dXMgZm9yIHJlbW92aW5nIHRoZSBpdGVtIGZyb20gdGhlIGNoYXJ0ZXIuDQpJIHdpbGwgdHJ5IHRv IGRyYWZ0IGFuIGFsdGVybmF0aXZlIGFuZCBwb3N0IGl0IGluIHRoZSBtYWlsaW5nIGxpc3QuDQoN CkRhdmlkOg0KSWYgd2UgZG8gdGhpcywgdGhlIHJlc3VsdCB3b3VsZCBuZWVkIHRvIGdvIHRvIHRo ZSB0b29scyBwYWdlLg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6DQpZb3UgbWF5IGFzayBmb3Ig Y29uc2Vuc3VzIGlmIHRoaXMgc2hvdWxkIHJlbWFpbiBhcyBhIGNoYXJ0ZXJlZCBpdGVtDQp3aXRo IGFuIFJGQyBkZWxpdmVyYWJsZSBpbiB0aGlzIFdHLg0KLg0KRGFuOiBxdWVzdGlvbjogImRvIHdl IHdhbnQgdG8gY29udGludWUgdGhlIHRlbXBsYXRlIGZvciBnZW5lcmljIGRhdGEgbW9kZWwgbWFu YWdlbWVudCBhcyBhIGNoYXJ0ZXJlZCBpdGVtIGluIHRoaXMgd29ya2luZyBncm91cCI/DQoNCkRh bjoNClBsZWFzZSBzaG93IGhhbmRzLg0KMCBoYW5kcyBpbiBmYXZvcg0KNiBoYW5kcyBhZ2FpbnN0 DQoNCkRhdmlkOiB0aGUgb3RoZXIgcXVlc3Rpb24gdG8gYXNrIGlzIHdoZXRoZXIgYW55b25lIHdh bnRzIHRvIHdvcmsgb24gdGhlIGluZGl2aWR1YWwgdGVtcGxhdGVzLCBvciBtYXliZSBlYWNoIFdH IHNob3VsZCBkbyB0aGF0DQogICAgDQpEYW46IA0KbGV0cyBhc2sgZWFjaCBXRyBmaXJzdA0KDQpE YXZpZDogcGVvcGxlIGFyZW4ndCBhc2tpbmcgcXVlc3Rpb25zIGFib3V0IHRoZSBNSUIgdGVtcGxh dGUsIGFyZSB0aGV5IGV2ZW4gYmVpbmcgdXNlZCBvcj8NCg0KRGFuOiANCnRoZXkncmUgZGVmaW5p dGVseSBiZWluZyB1c2VkIGJ1dCB0aGUgcXVlc3Rpb25zIGFyZSBsaWtlbHkgZ29pbmcgdG8gdGhl IEFEcyBzaW5jZSB3ZSdyZSBnZXR0aW5nIHF1ZXN0aW9ucyBhYm91dCBpdC4NCg0KSnVlcmdlbjog DQpzbWlkdW1wIGlzIGFibGUgdG8gZ2VuZXJhdGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYm9p bGVycGxhdGUgdGV4IGZyb20gYSBNSUIgbW9kdWxlIGFuZCBpdCBpcyBlYXN5IHRvIGV4dGVuZCB0 aGlzIGZ1cnRoZXIgdG8gZ2VuZXJhdGUgYSB3aG9sZSBkb2N1bWVudCB0ZW1wbGF0ZSBmcm9tIGEg TUlCIG1vZHVsZTsgYnV0IGFsbCB0aGlzIGlzIGZvciBtZSBhIHRvb2xzIGlzc3VlLg0KDQozLiBP cGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50IGRyYWZ0cw0KICAgKGRyYWZ0LWlldGYtb3BzYXdnLW9w ZXJhdGlvbnMtYW5kLW1hbmFnZW1lbnQpDQogICAoZHJhZnQtaWV0Zi1vcHNhd2ctc3VydmV5LW1h bmFnZW1lbnQpDQogICANCkRhdmlkIEhhcnJpbmd0b24gKHNlZSBzbGlkZXMpOg0KVGhlcmUgaXMg YSBzdXJ2ZXkgZG9jdW1lbnQgb24gd2hpY2ggdGhlIFdHIG5lZWRzIHRvIGRlY2lkZSB3aGF0IHRv DQpkbyB3aXRoIGl0LiANCg0KSnVlcmdlbjogDQp0aGlzIGlzIGFuIGV2ZXIgY2hhbmdpbmcgbGlz dCBvZiBUQ3MgYW5kIHRoaXMgaXMgYSBkeW5hbWljIGxpc3QuICBXaHkgd291bGQgdGhpcyBkb2N1 bWVudCBuZWVkIHRvIGJlIHdyaXR0ZW4uICBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBjYXN0IGNv bnN0YW50bHkgY2hhbmdpbmcgdGhpbmdzIGFzIFJGQ3MuDQoNCkRhdmlkOiANCnRoaXMgZG9jdW1l bnQgd2FzIGFsc28gc3RhcnRlZCBsb25nIGJlZm9yZSB0aGUgaW1wcm92ZWQgSUVURiB0b29scyBw YWdlcy4gIEkgYWdyZWUgdGhhdCBpdCBtYXkgYmUgdGhpcyBpcyBiZXR0ZXIgYXMgYSB3aWtpIGRv Y3VtZW50DQoNCkRhbjogc2hvdWxkIHdlIGFzayBmb3IgYSBjb25zZW5zdXMgY2FsbCBvbiB0aGlz Pw0KDQpEYXZpZDogDQp0aGVyZSBhcmUgYSBudW1iZXIgb2YgTUlCcyB0aGF0IG5vIG9uZSBldmVy IGRvZXMgYW55dGhpbmcgd2l0aCwgc2hvdWxkIHRoZXkgYmUgbGlzdGVkPyAgSSBkb24ndCB0aGlu ayBzby4gIFBlb3BsZSBkb24ndCB0ZWxsIHVzIHdoZW4gTUlCcyBhcmUgYmVpbmcgdXNlZC4gIFRo ZXJlIGlzIGEgcXVlc3Rpb24gYWJvdXQgd2hhdCB0aGUgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQg aXMuICBUaGUgZG9jdW1lbnQgYWxzbyBzYXlzIENPUFMtUFIgaXMgbm90IHJlY29tbWVuZGVkLCBi dXQgSSdtIGF3YXJlIG9mIGF0IGxlYXN0IG9uZQ0KaW1wbGVtZW50YXRpb24gZXhpc3RzIHNvIEkn bSBub3Qgc3VyZSBpdCdzIHdpc2UuDQoNClJvbiBCb25pY2E6IA0KV2hhdCBpcyB0aGUgaW50ZW5k ZWQgc3RhdHVzIG9mIHRoZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50DQpkb2N1bWVudD8NCg0K RGF2aWQ6DQpCQ1AuDQoNClJvbjoNClRoaXMgbWlnaHQgYmUgYSBwcm9ibGVtIGJlY2F1c2Ugb2Yg dGhlIGNvbW1lbnRzIHdlIHJlY2VpdmVkIHJlY2VudGx5LiBXZSBzaG91bGQgcmF0aGVyIGNvbnNp ZGVyIG1ha2luZyBpdCBpbmZvcm1hdGlvbmFsLg0KDQpkaXNjdXNzaW9uIGFib3V0IEJDUCB2cyBp bmZvcm1hdGlvbmFsLiAgU3VtbWFyeTogYSBCQ1AgaXMgbW9yZSBvZiBhIGNsdWIgYW5kIGFuIGlu Zm9ybWF0aW9uYWwgaXMgbW9yZSBvZiBhIGd1aWRlbGluZQ0KIA0KSm9lbCBZYWdlbHk6IA0KdGhl cmUgYXJlIHBsYWNlcyBpbiBCQ1Agd2hlcmUgd2Ugc2F5IHRoaW5ncyBsaWtlICJ3ZSBkb24ndCBs aWtlIHRoaW5ncyBidXQgd2UncmUgZ29pbmcgdG8gZG8gaXQgYW55d2F5Ii4gIFdlIGxpdmUgaW4g dGhlIHJlYWwgd29ybGQuDQogDQpEYXZpZDoNCnRoaXMgZG9jdW1lbnQgaXMgZGVzaWduZWQgdG8g YmUgYSBsYXJnZSBwaWVjZSBvZiB3b29kLiAgWW91IGNvdWxkIHdpZWxkIGl0IGFzIGEgY2x1Yiwg YnV0IGl0J3Mgbm90IGRlc2lnbmVkIHRvIGJlIGEgY2x1Yi4NCiANClJvbjogDQpieSBsYWJlbGlu ZyBpdCBhcyBhIEJDUCBpdCdzIHdvb2QgYW5kIGNhbiBiZSB1c2VkIGFzIGEgY2x1Yi4gIEJ5IGxh YmVsaW5nIGl0IGFzIGluZm9ybWF0aW9uYWwsIGl0IGJlY29tZXMgYSBuZXJmIHdlYXBvbi4NCg0K RGFuOg0KVGhpcyBpcyBhbiBpbXBvcnRhbnQgcXVlc3Rpb24gdGhhdCBuZWVkcyB0byBiZSBjbGFy aWZpZWQgc29vbi4gUHJvcG9zYWwgdG8gY2hhbmdlIG9mIHRoZSBpbnRlbmRlZCBzdGF0dXMgdG8g aW5mb3JtYXRpb25hbC4gUmV2aXNlZCBJLUQgaW5jbHVkaW5nIHNvbWUgY2hhbmdlcyB3b3VsZCBm b2xsb3cgaWYgYWdyZWVkLg0KDQoNCjQuIExvY2sgTUlCDQogICAoZHJhZnQtbWVuZy1mYW4tbG9j ay1taWItMDEpDQoNCldhc2hhbSBGYW4gKHNlZSBzbGlkZXMpOg0KVGhlIHB1cnBvc2UgaXMgbW9u aXRvcmluZyBsb2Nrcy4NCg0KRGFuOiANCkFyZSB0aGVyZSBjb21tZW50cyBmcm9tIHBlb3BsZSBp bnZvbHZlZCBpbiBOZXRjb25mLg0KDQpXZXM6DQpMb2NrcyBhcmUgdW5mb3J0dW5hdGVseSBuZWNl c3NhcnkuIA0KSXQgdGhpcyBzZWVtcyB0byBiZSBnb29kIGFuZCB1c2VmdWwgd29yay4NCkl0IHdp bGwgbm90IGJlIGFibGUgdG8gaW1wbGVtZW50IHRoZSBsb2NrcyBlYXNpbHkuIA0KDQpEYXZpZCBQ YXJ0YWluOg0KSSdtIG5vdCBzdXJlIHdlIHNob3VsZCBtZW50aW9uIGNvcHMtcHIgYmVjYXVzZSBp dCBpc24ndCByZWxldmFudCBhbnkgbG9uZ2VyLg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6DQpU aGVyZSBhcmUgbm90IGp1c3QgbG9ja3MgZnJvbSBDT1BTLVBSIGFuZCBvdGhlciBJRVRGIHByb3Rv Y29scy4gVGhlcmUgYXJlIG1hbnkgb3RoZXIgbG9ja3MgaW52b2x2ZWQuIFRoZXJlZm9yZSwgSSBo YXZlIGEgcHJvYmxlbSB3aXRoIHRoZSB1c2UgY2FzZS4gRGV2ZWxvcGVycyB3aWxsIGZpbmQgaXQg aGFyZCB0byBjaGVjayB0aGlzIE1JQiB3aGVuIG9ic2VydmluZyBhIHByb2JsZW0uDQoNCkJhbGF6 czoNCkhvdyBkbyB3ZSBpbmRpY2F0ZSB0aGUgc2NvcGUgb2YgdGhlIGxvY2tzPw0KDQpXYXNoYW06 DQpUaGUgc2NvcGUgaXMgZGVzY3JpYmVkIGluIHRoZSByZXNwZWN0aXZlIHN0YW5kYXJkIGRlZmlu aW5nIHRoZSBsb2NrLg0KDQpEYXZpZCBIYXJyaW5ndG9uOg0KRWFjaCBwcm90b2NvbCBoYXMgZGlm ZmVyZW50IHdheXMgb2YgZGVmaW5pbmcgdGhlIHNjb3BlIG9mIGEgbG9jay4NClRoaXMgbmVlZHMg dG8gYmUgc2hvd24gaW4gYSBkaWZmZXJlbnQgdGFibGUgb3V0c2lkZSBvZiB0aGlzIE1JQi4NCg0K RGFuOiANCmxldCBtZSBzaGFyZSBhIGNvbmNlcm4gYXMgYW4gQUQ6IHdoZW4geW91IHRlbGwgbWUg dGhpcyBpcyBqdXN0IG1vbml0b3Jpbmcgd2hhdCBsb2NrcyBhcmUgb24gdGhlIGRldmljZSwgSSdt IGZpbmUgYW5kIHVuZGVyc3RhbmQgdGhlIHNjb3BlLiAgV2hlbiB3ZSBzdGFydCBkZWFsaW5nIHdp dGggZXh0ZW5zaWJpbGl0eSBhbmQgcHJvdG9jb2wgaW5mb3JtYXRpb24gSSBzdGFydCBiZWluZyBt b3JlIGNvbmNlcm5lZC4gIElmIHRoaXMgaXMgcG9zc2libGUgbmV3IHdvcmsgSSdsbCBwcm9iYWJs eSBhc2sgZm9yIGEgbWluaW1hbCBzY29wZS4NCg0KRGF2aWQgSGFycmluZ3RvbjoNClRoZSBTTk1Q IHN0YWNrIHdpbGwgbm90IGhhdmUgbXVjaCBpbnNpZ2h0IGluIHdoYXQgaXMgZ29pbmcgb24NCmlu IHRoZSBuZXRjb25mIHN0YWNrLiBUaGlzIHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0IHRvIGltcGxl bGVtZW50LA0KYmVjYXVzZSBhbGwgc3RhY2tzIG5lZWQgdG8gaW50ZXJhY3Qgb3IgYWxsIHByb3Rv Y29scyBuZWVkIHRvIGJlDQpjb25zdWx0ZWQuIEkgbGlrZSB0byBzdWdnZXN0IGEgbmV3IHdvcmsg aXRlbSBmb3IgdGhpcyBXRy4gSWYgcGVvcGxlIHRoaW5rIHRoYXQNCkNPUFMtUFIgaXMgYSBkZWFk IHByb3RvY29sLCB0aGVuIGxldCdzIG9ic29sZXRlIGl0Lg0KDQpEYW46IA0KV2lsbCB5b3Ugd3Jp dGUgYW4gSW50ZXJuZXQgZHJhZnQgb24gIkNPUFMtUFIgaXMgZGVhZCI/DQoNCkRhdmlkIFBhcnRh aW46DQpJcyB0aGF0IHRoZSB3YXkgaXQgaXMgZG9uZT8NCg0KUm9uOg0KWWVzLg0KDQpEYXZpZCBQ YXJ0YWluOg0KSSB3b3VsZCBzdXBwb3J0IGl0Lg0KDQpEYXZpZCBIYXJyaW5ndG9uOg0KVGhlbiB3 ZSBzaG91bGQgaW5jbHVkZSBTTk1QLUNPTkYuDQoNClNjb3R0IEJyYWRuZXIgc3VwcG9ydGluZyB0 aGlzIHZpYSBKYWJiZXIuDQoNCkJlcnQgV2lqbmVuOg0KVGhpcyBtYXkgYmUgYSB3YXN0ZSBvZiBy ZXNvdXJjZXMuIEl0IGNvc3RzIGEgbG90IG9mIHRpbWUgaW4NCnRoZSBwYXN0IHRvIGdvIHRoaXMg d2F5IGZvciBvdGhlciBkb2N1bWVudHMuDQoNClJvbjoNCkkgbGlrZSB0byBnaXZlIGl0IGEgdHJ5 IGZvciBmaW5kaW5nIG91dCBpdCBpcyBzdGlsbCBkaWZmaWN1bHQuDQoNCkRhbjogDQpSb24gd2ls bCBzaGVwZXJkIHRoZSBkb2N1bWVudCA6KQ0KDQpEYXZpZCBQYXJ0YWluOg0KSGF2aW5nIENPUFMt UFIgaGlzdG9yaWMgd291bGQgYWxzbyBzYXZlIHRpbWUgaW4gdGhlIGZ1dHVyZSwNCmJlY2F1c2Ug b3VyIGRvY3VtZW50cyB3b3VsZCBub3QgYW55bW9yZSBuZWVkIHRvIHJlZmVyZW5jZSBpdC4NCg0K SnVlcmdlbiBTY2hvZW53YWVsZGVyOg0KQ09QUy1QUiBpcyBhIHRhcmdldCB3b3J0aCB0cnlpbmcg aXQuIEl0IGhhcyBtb3JlIHJlbGV2YW5jZQ0KdGhhbiBqdXN0IGEgc2luZ2xlIE1JQiBtb2R1bGUu DQoNClNjb3R0Og0KSXQgd2lsbCBiZSBhIGxvdCBvZiB3b3JrLg0KDQpEYW46DQpBcyB0ZWNobmlj YWwgY29udHJpYnV0b3IsIEkgd291bGQgYWxzbyBzdXBwb3J0IHRoaXMgZWZmb3J0Lg0KDQpXZXM6 DQpFdmVuIGlmIHdlIHB1dCBDT1BTLVBSIHRvIGhpc3RvcmljLCB3ZSB3b3VsZCBzdGlsbCBuZWVk IHRvDQpyZWZlciB0byBpdCBpbiBzb21lIGRvY3VtZW50cywgYmVjYXVzZSBpdCB3aWxsIHN0aWxs IGV4aXN0Lg0KDQpCZXJ0Og0KV2UgYWxyZWFkeSBzdG9wcGVkIFdHcyBkb2luZyBQSUIgbW9kdWxl cyBiZWNhdXNlIHRoZXkgaGVhdmlseQ0Kb3ZlcmxhcCB3aXRoIE1JQiBtb2R1bGVzLg0KDQpTY290 dDoNCklUVS1UIGFubWQgM0dQUCBhcmUgc3RpbGwgdXNpbmcgaXQuDQoNCkJlcnQ6DQpXZSB3ZW50 IHRoZXJlIGFuZCBleHBsYWluZWQgdGhlIHNpdHVhdGlvbi4gM0dQUCBndXlzIGFyZSBzdGlsbCB3 cml0aW5nIFBJQiBtb2R1bGVzLg0KDQpEYXZpZCBIYXJyaW5ndG9uOg0KT25lIGJpZyBwcm9ibGVt IHdpdGggQ09QUy1QUiBpcyB0aGF0IGl0IGhhcyBhIGdsb2JhbCBsb2NrLiBUaGlzIGJsb2NrcyBl dmVuIENMSS4gSW4gc3VjaCBhIGNhc2UgdGhlIExPQ0sgTUlCIHdvdWxkIGJlIGEgIHVzZWZ1bCBt ZWFucyBmb3IgaWRlbnRpZnlpbmcgdGhlIGxvY2sgYmxvY2tpbmcgb3RoZXIgbWVhbnMuDQoNCkRh bjoNCldobyBpbiB0aGUgcm9vbSBpcyBpbiBmYXZvciBvZiB3b3JraW5nIG9uIHRoZSBMT0NLIE1J QiBpbiB0aGUgb3BzYXdnDQo0IGhhbmRzIGluIGZhdm9yDQowIGhhbmRzIGFnYWluc3QNCldlIHdp bGwgdGFrZSB0aGlzIHRvIHRoZSBsaXN0Lg0KDQpBYm91dCBjb3BzLXByIGhpc3RvcmljLCB3aG9l dmVyIHdhbnRzIHRvIGRvIHRoYXQgc2hvdWxkIG1ha2UgYSBwcm9wb3NhbCBkb2N1bWVudC4NCg0K DQoNCjUuIFNOTVAgTG9jaw0KICAgKGRyYWZ0LWZhbi1tZW5nLXNubXAtbG9jay0wMCkNCg0KV2Fz aGFtIEZhbiAoc2VlIHNsaWRlcyk6DQpXZSBzaG91bGQgZXh0ZW5kIHRoZSBMb2NrIE1JQiB0byBt YW5pcHVsYXRlIFNOTVAgbG9ja3MuDQoNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlcjoNCldoYXQgaXMg YmVpbmcgbG9ja2VkPyBXaGF0IGlzIHRoZSBzY29wZT8NCg0KIFdhc2hhbTogDQpUaGUgaW5zdHJ1 bWVudGF0aW9uIGl0c2VsZg0KDQpKdWVyZ2VuOiANClRoZSB0aW1lIGl0IHRha2VzIHRvIHByb2Nl c3MgYSBzZXQgZG9lc24ndCBkZXBlbmQgb24gdGhlIG1zZyBzaXplLiAgdGhlIG1vdGl2YXRpb24g c2VjdGlvbiBuZWVkcyB0byBiZSBjaGFuZ2VkLg0KDQogUm9uOg0KIEhvdyBtYW55IGJlbGlldmUg dGhpcyBzaG91bGQgYmUgdGFrZW4gYXMgYW4gaXRlbT8NCiBGb3I6IDMsIGFnYWluc3Q6IDANCiBO b3QgbWFueSBhZ2FpbiwgbGV0cyB0YWtlIGl0IHRvIHRoZSBsaXN0Lg0KDQoNCjYuIE9BTSBkZWZp bml0aW9uIGRyYWZ0DQogICAoZHJhZnQtYW5kZXJzc29uLW1wbHMtdHAtb2FtLWRlZikNCiAgIA0K TG9hIEFuZGVyc29uOg0KSW4gTVBMUy1UUCB0aGUgdGVybSBPQU0gaXMgaGVhdmlseSB1c2VkLCBi dXQgd2l0aCBwcm9iYWJseSBkaWZmZXJlbnQgbWVhbmluZ3MuIFRoaXMgaXMgYSBkb2N1bWVudCBk ZWZpbmluZyB0aGlzIHRlcm0uIEl0P3Mgc2NvcGUgaXMgYmV5b25kIHRoZSBNUExTLVRQLCB3aWRl ci1JRVRGDQoNClJvbjoNCkhvdyBtYW55IHRoaW5rIGl0IHNob3VsZCBiZSBhIFdHIGl0ZW0/DQoz IGluIGZhdm9yDQowIGFnYWluc3QNCg0KRGFuOg0KVGhpcyBoYXMgYWxyZWFkeSBiZWVuIG9uIHRo ZSBsaXN0IGZvciBjb25zZW5zdXMuIEFub3RoZXIgIHdlZWsgb2YgbWFpbGluZyBsaXN0IGNvbW1l bnQgY2hhbmNlLCBvdGhlcndpc2UgaGUgY2FuIGdvIGFoZWFkLCBhbmQgTG9hIGNhbiByZS1zdWJt aXQgYXMgZHJhZnQtaWV0Zi1vcHNhd2cNCg0KTG9hOiANClRoZXJlIHdpbGwgYmUgc29tZSBvdGhl ciBlZGl0cy4gDQoNCg0KNy4gUG93ZXIgTW9uaXRvcmluZw0KDQpKdWVyZ2VuIFF1aXR0ZWsgKHNl ZSBzbGlkZXMpOg0KDQpTY290dCBCcmFkbmVyOiANCklzIHRoZSBNSUIgcmVhZC1vbmx5Pw0KDQpK dWVyZ2VuIFF1aXR0ZWs6IA0KTm8gTUlCIGJ5IG5vdywgaW5mb3JtYXRpb25hbCBwcmVzZW50YXRp b24sIHQncyBub3QgdGhlIHRpbWUgdG8gZGVjaWRlIG9uIHRoYXQgbm93DQoNClNjb3R0OiANCkhv dyBkb2VzIHRoaXMgcmVsYXRlIHRvIHRoZSBzbWFydCBncmlkIHdvcms/DQoNCkp1ZXJnZW4gUXVp dHRlazogDQpJdCBtYXkgYmUgYSBjb21wb25lbnQsIGJ1dCBpIHRoaW5rIHNtYXJ0IGdyaWQgcmVx dWlyZXMgbXVjaCBtb3JlIChsaWtlIHNjaGVkdWxpbmcgcG93ZXIgcHJvZHVjdGlvbiBhbmQgY29u c3VtcHRpb24pLiBJIHRoaW5rIGl0J3Mgc2xpZ2h0bHkgcmVsYXRlZCBidXQgbm90IHN0cm9uZ2x5 Lg0KDQpEYW4gUm9tYXNjYW51OiANClNwZWFraW5nIGFzIGEgY29udHJpYnV0b3I6IHRoZXJlIGFy ZSBhIGJ1bmNoIG9mIG9yZ2FuaXphdGlvbnMgd29ya2luZyBvbiB0aGlzIHdoaWNoIGlzIHdoYXQg bWFrZXMgaXQgaGFyZC4gIFRoZXkgbWF5IGhhdmUgTUlCcyBhcyB3ZWxsIGFuZCB0aGlzIG1pZ2h0 IGludGVyZmVyZS4gQXMgYW4gQUQ6IEkgdGhpbmsgd2UgbmVlZCB0byBzZWUgYW4gSUQgdG8gc2Vl IHRoZSBzY29wZSBvZiB3aGF0IGlzIGJlaW5nIHN1Z2dlc3RlZC4NCg0KSnVlcmdlbiBRdWl0dGVr OiANClRoaXMgaXNuJ3QgYSBjaGFydGVyaW5nIHJlcXVlc3QgYXQgdGhpcyB0aW1lOyBJIGp1c3Qg d2FudCB0byBicmluZyBhd2FyZW5lc3MgYW5kIHdhbnQgdG8gc2VlIHdobyBpcyBpbnRlcmVzdGVk IGluIHdvcmtpbmcgb24gdGhpcz8gIElzIHRoaXMgdGhlIHJpZ2h0IG9yZ2FuaXphdGlvbj8NCg0K U2NvdHQgQnJhZG5lcjogDQpTbWFydC1ncmlkIGluY2x1ZGVzIHJlbW90ZSBtb25pdG9yaW5nIEFO RCByZW1vdGUgY29udHJvbA0KDQpKdWVyZ2VuIFF1aXR0ZWs6IA0KSSBhZ3JlZSBidXQgSSBkb24n dCBzZWUgdGhhdCBhcyB0aGUgY29yZSBpc3N1ZS4NCg0KDQpEYXZpZCBIYXJyaW5ndG9uOiANCkkn bSBoYXZpbmcgYSBwcm9ibGVtIHNlZWluZyB3aGF0IHdlIGNvdWxkIGRvIGluIHRoZSBvcHNhd2cg YWJvdXQgdGhpcy4NCg0KSnVlcmdlbiBRdWl0dGVrOiANCkknbSBub3QgbmVjZXNzYXJpbHkgc3Vy ZSB0aGlzIGlzIHRoZSByaWdodCBncm91cCB0byBkbyBpdCBlaXRoZXIuDQoNCkp1ZXJnZW4gU2No b2Vud2FsZWRlcjogDQpJIHJlc2VydmVkIGEgMTAgbWludXRlIHNsb3QgdG9tb3Jyb3cgaW4gT1BT QVJFQSB0byBkaXNjdXNzIGxvdy1wb3dlciBzdHVmZiBmcm9tIDZsb3dwYW4uICBUaGV5J3JlIGNv bnNpZGVyaW5nIHVzaW5nIFNOTVAuDQogICANClJvbiBCb25pY2E6IA0KSSBjb3VsZCBzZWUgYSBu dW1iZXIgb2YgaW50ZXJlc3RpbmcgTUlCcyB3cml0dGVuIHRvd2FyZCB0aGlzIGdvYWwuICBBbm90 aGVyIHRoaW5nIHdvcnRoIG1vbml0b3JpbmcgbWlnaHQgYmUgdGhlIGhlYXQgdGhyb3duIG9mZi4N Cg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6IA0KVGhlIG5pY2UgdGhpbmcgd291bGQgYmUgdG8g a25vdyB3aG8gd291bGQgYmUgaW1wbGVtZW50aW5nIGl0Lg0KDQpEYXZpZCBIYXJyaW5ndG9uOiAN ClRoZXJlIGFyZSBjZXJ0YWluIHR5cGVzIG9mIHRoaW5ncyB0aGF0IHNob3VsZCBub3QgYmUgaW5j bHVkZWQgaW4gYSBNSUIgbW9kdWxlLiBQZW9wbGUgYXJlIG1lbnRpb25pbmcgdGhpbmdzIGxpa2Ug KHdhcyBpdCBzdGFuZGFyZCBkZXZpYXRpb25zID8pLiAgVmFsdWVzIHRoYXQgY2FuIGJlIGRlcml2 ZWQgZnJvbSBvdGhlciB2YWx1ZXMgc2hvdWxkIG5vdCBiZSBpbmNsdWRlZCBpbiBhIE1JQiBtb2R1 bGUuIFRoZSBnb2FsIHNob3VsZCBiZSB0byBrZWVwIHRoZSBhZ2VudCBzaW1wbGUsIGFuZCBtb3Zl IGFueSBkZXJpdmFibGUgY2FsY3VsYXRpb25zIHRvIHRoZSBtYW5hZ2VyIGFwcGxpY2F0aW9uLg0K DQpKdWVyZ2VuIFNjaG9lbndhbGVkZXI6IA0KVGhlIE1JQiBuZWVkcyB0byBiZSBlYXN5IHRvIGlt cGxlbWVudC4gIFN0YXRlIGFuZCBkdXJhdGlvbiBpcyB0aGUgZWFzaWVzdCB0byBpbXBsZW1lbnQu DQoNCldlczogDQpBcyB2ZW5kb3IgSSBjYW4gY29uZmlybSB0aGF0IHRoZSBuZWVkIGlzIG91dCB0 aGVyZSA/IHdlZSBzZWUgZGVtYW5kLg0KIA0KDQogICANCjguIFZpcnR1YWwgTmV0d29yayBNYW5h Z2VtZW50IEluZm9ybWF0aW9uIE1vZGVsDQogICAoZHJhZnQtb2tpdGEtb3BzLXZuZXRtb2RlbC0w MCkNCg0KSGlkZWtpIE9raXRhIChzZWUgc2xpZGVzKToNCkZvciB2aXJ0dWFsIG5ldHdvcmtzIHdl IG5lZWQgYSBkYXRhIG1vZGVsIGZvciBkZXNjcmliaW5nICByZWxhdGlvbnNoaXBzIGJldHdlZW4g dmlydHVhbCBhbmQgcGh5c2ljYWwgbmV0d29ya3MgYW5kICBmb3IgZGVzY3JpYmluZyBjb25uZWN0 aW9ucyBiZXR3ZWVuIHZpcnR1YWwgZW50aXRpZXMuDQoNCkp1ZXJnZW4gUXVpdHRlazoNCklzIGl0 IGZvciBkYXRhIGNlbnRlcnMgb25seSBvciBhcHBsaWNhYmxlIHRvIGdlbmVyYWwgbmV0d29ya3M/ DQoNCkhpZGVraToNCkFsc28gYXBwbGljYXRpb24gdG8gZ2VuZXJhbCBuZXR3b3JrcyBzaG91bGQg YmUgcG9zc2libGUuDQoNCkRhbjoNCldobyBoYXMgcmVhZCB0aGUgZHJhZnQ/DQoobm8gaGFuZHMg c2hvd2VkIHVwLikNCkl0IGlzIHRvbyBlYXJseSB0byBhc2sgZm9yIFdHIGFkb3B0aW9uLiBMZXQn cyBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbi4NCg0KDQo5LiBUaGUgTWFuYWdlbWVudCBNb2RlbCBv ZiB0aGUgQ2VudHJhbGl6ZWQgTmV0d29yayBBcmNoaXRlY3R1cmUNCiAgIChkcmFmdC1yaWNoYXJk LW9wc2F3Zy1jbmEtbWliLTAwKQ0KDQpSaWNoYXJkIFlhbmcgKHNlZSBzbGlkZXMpOg0KU3VnZ2Vz dCBhIGdlbmVyaWMgbWFuYWdlbWVudCBtb2RlbC4NCg0KRGFuOg0KUGxlYXNlIGNoZWNrIGV2ZXJ5 Ym9keSwgaWYgdGhpcyBpcyB1c2VmdWwgd29yayBmb3Igb3BlcmF0b3JzLiBUb28gZWFybHkgdG8g dGFsayBhYm91dCBhZG9wdGlvbiBieSBXRywgbmVlZHMgdG8gYmUgY29udGludWVkIG9uIHRoZSBs aXN0LiANCg0KDQoNCg== ------_=_NextPart_001_01CA2660.4F99FB60-- From ietfdbh@comcast.net Wed Aug 26 09:27:04 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0ADF3A69F3 for ; Wed, 26 Aug 2009 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQfmGzRfGA6c for ; Wed, 26 Aug 2009 09:27:03 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id A57503A6C6D for ; Wed, 26 Aug 2009 09:27:03 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Z3Mx1c0050SCNGk544T9jN; Wed, 26 Aug 2009 16:27:09 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Z4T01c0050UQ6dC3V4T8bb; Wed, 26 Aug 2009 16:27:09 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20090821005932.D35601BF4863@newdev.eecs.harvard.edu> <00e301ca25b8$c624ef80$6801a8c0@oemcomputer> Date: Wed, 26 Aug 2009 12:26:58 -0400 Message-ID: <03d901ca266a$0d7068e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00e301ca25b8$c624ef80$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcoluGkKuYgzt/BnRVynErL1/3I1WwAsZB/g Subject: Re: [OPSAWG] opsawg consensus check X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:27:04 -0000 Hi, I am not sure this answered Scott's question. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, August 25, 2009 3:18 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] opsawg consensus check > > Hi - > > > From: "Wes Hardaker" > > To: "Scott O. Bradner" > > Cc: > > Sent: Friday, August 21, 2009 8:05 AM > > Subject: Re: [OPSAWG] opsawg consensus check > ... > > Cross-protocol locks, unfortunately, are difficult. Especially when > > trying to write generic support code. I've had conversations with > > people that aren't sure how'd they'd implement the netconf locking > > requirements. It's a system-wide feature requirement so > it's actually > > impossible to stamp a "RFC4741 Locking Compliant" stamp on a agent > > development package. Because it's impossible. The system > has to make > > sure the lock is enforced everywhere, which a software > provider can't > > do. > > To me the problem looks more and more like Byzantine agreement, > particularly if we have no way of ensuring that the access > control models > of the various protocols will have been configured to provide > a coherent > policy, and if we admit the reality that there will be > inconsistencies in how > the information is modelled and thereby constrained in the > different protocol > environments. Assuming the implementations are error-free, > of course. :-) > > > Because the complexity of simple locks can be difficult > depending on the > > system, I think management of them from *every* protocol > affect is an > > absolute MUST. > > And there's the rub. Retro-fitting SNMP, for example, would > require digging > into AgentX, SNMP proxy, and the various proprietary subagent > mechanisms. > This would keep someone busy for a long time. > > There may be lessons to be learned here from the world of > configuration > management. (As in Webdav, CVS, SCCS, RCS, .... ) > > Randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From sob@harvard.edu Thu Aug 27 07:47:14 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DE93A692A for ; Thu, 27 Aug 2009 07:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOKbd0YCiVej for ; Thu, 27 Aug 2009 07:47:14 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 0D35628C213 for ; Thu, 27 Aug 2009 07:47:14 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 72D1E1C46E58; Thu, 27 Aug 2009 10:47:19 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090827144719.72D1E1C46E58@newdev.eecs.harvard.edu> Date: Thu, 27 Aug 2009 10:47:19 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg consensus on draft-andersson-mpls-tp-oam-def X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:47:14 -0000 draft-andersson-mpls-tp-oam-def was disucssed during teh opsawg session in Stockholm. A few people in the room felt that it should beadopted as a opsawg item. The AD felt that this document would fit under the current opsawg charter. this is a check to see if anyone objects to adopting this ID as an opsawg WG document. please let the list know within the next week tnx Scott From j.schoenwaelder@jacobs-university.de Fri Aug 28 06:06:13 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16EA3A6F69 for ; Fri, 28 Aug 2009 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFc0o++F8HpB for ; Fri, 28 Aug 2009 06:06:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9DC2C3A6EF9 for ; Fri, 28 Aug 2009 06:06:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C99BAC00D9; Fri, 28 Aug 2009 15:06:18 +0200 (CEST) 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 mEe-qWk8yauK; Fri, 28 Aug 2009 15:06:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8917BC00DA; Fri, 28 Aug 2009 15:06:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0DA33C817AC; Fri, 28 Aug 2009 15:06:15 +0200 (CEST) Date: Fri, 28 Aug 2009 15:06:15 +0200 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20090828130615.GA22962@elstar.local> Mail-Followup-To: opsawg@ietf.org, Adrian Farrel , Scott Bradner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Farrel Subject: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:06:13 -0000 Hi, during the IESG review of draft-ietf-opsawg-syslog-msg-mib-06.txt, Adrian Farrel raised a DISCUSS concerning the syslogMsgTable that we have not managed to clear yet and where we seek input from the WG. The syslogMsgTable is index by syslogMsgIndex, an unsigned index number that is increases when entries are added and which rolls over if the index number space has been exceeded. This means that the entries in the table are (ignoring roll overs here) in the order they were inserted (which is not necessarily the timestamp order of the syslog events). This supports the following "tail -f" use case where a management application initially reads the table, remembers the end of the table and during the next poll starts at the last remembered index position. This is useful to quickly check for additions to the table. This approach also works with index roll overs unless the table rolls over multiple times during a polling cycle. Adrian Farrel asks in his DISCUSS whether there is not also a use case to read the table in index order, that is oldest table entry to most recent table entry, according to table insertion order. Right now, this only works until the first index rollover occurs since after the first index rollover, top table entries might be more recent than bottom table entries. This can be fixed for example by adding an additional scalar object reporting the index of the oldest entry in the table. As the editor of the document, I did not feel entitled to make a decision on this issue. After talking with Scott Bradner, we believe the WG needs to decide whether the ability to quickly find the oldest entry in the table (according to the insertion time) is a feature the MIB module needs to support. An important detail to consider here is that the table insertion order is not necessarily syslog timestamp order. /js PS: Adrian, please correct me if my summary of your DISCUSS is incorrect or unclear. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Washam.Fan@huaweisymantec.com Fri Aug 28 07:05:27 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A744928C333 for ; Fri, 28 Aug 2009 07:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnufVKUF8AFi for ; Fri, 28 Aug 2009 07:05:26 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 9B21D3A712A for ; Fri, 28 Aug 2009 07:05:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP300FEFB4E5VB0@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Fri, 28 Aug 2009 22:05:02 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP300G4FB4EVL20@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Fri, 28 Aug 2009 22:05:02 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 28 Aug 2009 22:05:02 +0800 From: WashamFan To: Juergen Schoenwaelder Message-id: Date: Fri, 28 Aug 2009 22:05:02 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <20090828130615.GA22962@elstar.local> References: <20090828130615.GA22962@elstar.local> Cc: opsawg@ietf.org, Adrian Farrel Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:05:27 -0000 Hi, ----- Original Message ----- From: Juergen Schoenwaelder Date: Friday, August 28, 2009 9:07 pm Subject: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt To: opsawg@ietf.org Cc: Adrian Farrel > Hi, > > during the IESG review of draft-ietf-opsawg-syslog-msg-mib-06.txt, > Adrian Farrel raised a DISCUSS concerning the syslogMsgTable that we > have not managed to clear yet and where we seek input from the WG. > > The syslogMsgTable is index by syslogMsgIndex, an unsigned index > number that is increases when entries are added and which rolls over > if the index number space has been exceeded. This means that the > entries in the table are (ignoring roll overs here) in the order they > were inserted (which is not necessarily the timestamp order of the > syslog events). This supports the following "tail -f" use case where > a > management application initially reads the table, remembers the end of > the table and during the next poll starts at the last remembered index > position. This is useful to quickly check for additions to the > table. This approach also works with index roll overs unless the table > rolls over multiple times during a polling cycle. > > Adrian Farrel asks in his DISCUSS whether there is not also a use case > to read the table in index order, that is oldest table entry to most > recent table entry, according to table insertion order. Right now, > this only works until the first index rollover occurs since after the > first index rollover, top table entries might be more recent than > bottom table entries. This can be fixed for example by adding an > additional scalar object reporting the index of the oldest entry in > the table. How about introduce a column as a rollover counter to the table? washam > As the editor of the document, I did not feel entitled to make a > decision on this issue. After talking with Scott Bradner, we believe > the WG needs to decide whether the ability to quickly find the oldest > entry in the table (according to the insertion time) is a feature the > MIB module needs to support. An important detail to consider here is > that the table insertion order is not necessarily syslog timestamp > order. > > /js > > PS: Adrian, please correct me if my summary of your DISCUSS is > incorrect or unclear. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From ietfdbh@comcast.net Fri Aug 28 07:59:33 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB7D3A6B4A for ; Fri, 28 Aug 2009 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5cWWU1fNuNh for ; Fri, 28 Aug 2009 07:59:32 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 1CBB43A6926 for ; Fri, 28 Aug 2009 07:59:31 -0700 (PDT) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA09.westchester.pa.mail.comcast.net with comcast id ZozT1c0021ei1Bg59qzfkz; Fri, 28 Aug 2009 14:59:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA24.westchester.pa.mail.comcast.net with comcast id Zr3k1c00H0UQ6dC3kr3lEN; Fri, 28 Aug 2009 15:03:45 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20090828130615.GA22962@elstar.local> Date: Fri, 28 Aug 2009 10:59:37 -0400 Message-ID: <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090828130615.GA22962@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acon4FjVnfDWhQxnTlGr5ZJuA73/lAADTUAw Cc: 'Adrian Farrel' Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:59:33 -0000 Hi, The SNMP approach has a major guideline: keep the agent simple; move complexity to the manager. I think that different applications will want different orderings, and that the applications should sort based on their preference rather than forcing this onto the agent. I do not believe there is significant operational benefit from knowing insertion order. Do entries ever get removed from this table? Does rollover just overwrite starting at the beginning of the table? Is there ever a case where the newer entries get interlaced with older entries? I am not sure I see the benefits of knowing where the oldest entry is. I think most uses will want the whole table so they can sort it by whatever criteria it needs. I can see a few edge cases (like having oldest=0 might imply no rollover has occurred), but nothing compelling. In the case of wanting to only get updated rows, I would think knowing where the most recent entry is might be more useful than knowing where the oldest entry is, so you know where to stop reading, even if there has been no rollover. This seems to add complexity to the agent that might not be needed. The manager can simply look at each getNext retrieval to see if it already has that entry. But a scalar is fairly simple to add, so I wouldn't object if it got added. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, August 28, 2009 9:06 AM > To: opsawg@ietf.org > Cc: Adrian Farrel > Subject: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt > > Hi, > > during the IESG review of draft-ietf-opsawg-syslog-msg-mib-06.txt, > Adrian Farrel raised a DISCUSS concerning the syslogMsgTable that we > have not managed to clear yet and where we seek input from the WG. > > The syslogMsgTable is index by syslogMsgIndex, an unsigned index > number that is increases when entries are added and which rolls over > if the index number space has been exceeded. This means that the > entries in the table are (ignoring roll overs here) in the order they > were inserted (which is not necessarily the timestamp order of the > syslog events). This supports the following "tail -f" use case where a > management application initially reads the table, remembers the end of > the table and during the next poll starts at the last remembered index > position. This is useful to quickly check for additions to the > table. This approach also works with index roll overs unless the table > rolls over multiple times during a polling cycle. > > Adrian Farrel asks in his DISCUSS whether there is not also a use case > to read the table in index order, that is oldest table entry to most > recent table entry, according to table insertion order. Right now, > this only works until the first index rollover occurs since after the > first index rollover, top table entries might be more recent than > bottom table entries. This can be fixed for example by adding an > additional scalar object reporting the index of the oldest entry in > the table. > > As the editor of the document, I did not feel entitled to make a > decision on this issue. After talking with Scott Bradner, we believe > the WG needs to decide whether the ability to quickly find the oldest > entry in the table (according to the insertion time) is a feature the > MIB module needs to support. An important detail to consider here is > that the table insertion order is not necessarily syslog timestamp > order. > > /js > > PS: Adrian, please correct me if my summary of your DISCUSS is > incorrect or unclear. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From j.schoenwaelder@jacobs-university.de Fri Aug 28 09:35:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE903A6EF3 for ; Fri, 28 Aug 2009 09:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWnHYonMaejO for ; Fri, 28 Aug 2009 09:35:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 208A43A6906 for ; Fri, 28 Aug 2009 09:35:08 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEC89C00DC; Fri, 28 Aug 2009 18:35:14 +0200 (CEST) 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 pGoUxxkhnk1t; Fri, 28 Aug 2009 18:35:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF18FC00DA; Fri, 28 Aug 2009 18:35:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1214BC81D55; Fri, 28 Aug 2009 18:35:11 +0200 (CEST) Date: Fri, 28 Aug 2009 18:35:11 +0200 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090828163510.GC23097@elstar.local> Mail-Followup-To: WashamFan , "opsawg@ietf.org" , Adrian Farrel References: <20090828130615.GA22962@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "opsawg@ietf.org" , Adrian Farrel Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:35:09 -0000 On Fri, Aug 28, 2009 at 04:05:02PM +0200, WashamFan wrote: > How about introduce a column as a rollover counter to the table? To solve which problem? It does not give me the oldest entry without reading the table - so no improvement related to Adrian Farrel's discuss. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Fri Aug 28 17:02:16 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F403A6AA2 for ; Fri, 28 Aug 2009 17:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gds6+vKQsoYq for ; Fri, 28 Aug 2009 17:02:15 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 0B1723A6863 for ; Fri, 28 Aug 2009 17:02:13 -0700 (PDT) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA02.westchester.pa.mail.comcast.net with comcast id Zzk21c0091wpRvQ5202MpZ; Sat, 29 Aug 2009 00:02:21 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA18.westchester.pa.mail.comcast.net with comcast id a05c1c0090UQ6dC3e05cz7; Sat, 29 Aug 2009 00:05:37 +0000 From: "David Harrington" To: "'Adrian Farrel'" , "'Juergen Schoenwaelder'" , References: <20090828130615.GA22962@elstar.local> <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> Date: Fri, 28 Aug 2009 20:02:19 -0400 Message-ID: <057501ca283b$faac2e50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcooKYAENkjdkHkhSAaX6aAxJT62MQADW00A Cc: draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 00:02:16 -0000 Hi, > 2. > > The SNMP approach has a major guideline: > > keep the agent simple; move complexity to the manager. > Yes. And this is what swings it for me. > I am just left wondering whether an Agent is more loaded by a > bulk read of > 10,000 entries or maintaining a pointer into the table. > > Clear up this last point, and I'm done. > > Cheers, > Adrian Well, I think you have two cases - the initial read and update reads. I might be surprised to see 10,000 in an initial read, but I presumably want to get them all on the initial read, so if there are 10,000, then that's what I'll get, whether there is a scalar or not. Knowing the oldest entry doesn't really help me on the initial read. Now we'll deal with update reads. I would be surprised to see 10,000 entries in an update. But presuming they're there and I want them all, I can bulk read them at 100 each time and check for whether I have duplicates of entries I retrieved earlier (or whether the timestamp changes significantly or whatever optimization I meet choose to use). I can stop requesting more once I detect a duplicate. If the table is actually that large that there are 10,000 update entries in the table, a bulk read of 100 does not seem like much of a problem, and it would be nicer to the CPU of the agent device. Worst case, I read 100 duplicate entries, but compared to an update of 10,000 entries I think this is insignificant. How complex you want to make the algorithm can be decided by the manager. I am not certain how a scalar to the oldest helps that much. A pointer to the latest entry would seem more useful to recognize where to stop. Of course, the pointer to the oldest is probably 1 greater than the pointer to the newest. I just don't think it makes that much difference if you are talking 10,000 entries in an update. As I said I don't object to having a scalar. But I don't think it's going to matter much in your scenario. If you're really concerned about the load on the agent, remember that if there are 10000 update entries, the scalar needs to be updated 10,000 times. And for the manager to know the value of the scalar, it will have to do reads of the scalar as well as of the table entries. If you really want to reduce the load from bulk reads, then you might want to provide filtering INDEXES on common fields, such as facility (only get the ones for the email server), and severity (only retrieve the critical errors). I think this might be more useful at reducing retrieval load than the proposed scalar because these are commonly used filters. dbh From tena@huawei.com Sat Aug 29 00:48:27 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6086C3A68FE for ; Sat, 29 Aug 2009 00:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.963 X-Spam-Level: X-Spam-Status: No, score=-97.963 tagged_above=-999 required=5 tests=[AWL=4.531, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2LEGCHs8GPs for ; Sat, 29 Aug 2009 00:48:26 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0F0BA3A690D for ; Sat, 29 Aug 2009 00:48:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP400I7UOCJGY@szxga04-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 15:48:19 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP400AK9OCJ9V@szxga04-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 15:48:19 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP400DKIOCJMZ@szxml06-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 15:48:19 +0800 (CST) Date: Sat, 29 Aug 2009 15:48:19 +0800 From: Tina TSOU To: opsawg@ietf.org, "Scott O. Bradner" Message-id: <00dc01ca287d$137c59a0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_fugpEs7N5Wj2QG7pRpAl8Q)" X-Priority: 3 X-MSMail-priority: Normal References: <20090827144719.72D1E1C46E58@newdev.eecs.harvard.edu> Subject: Re: [OPSAWG] opsawg consensus on draft-andersson-mpls-tp-oam-def X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 07:48:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_fugpEs7N5Wj2QG7pRpAl8Q) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Scott et al, It's OK for me. This draft is to clarify the meaning of each letter in the abbreviation of "OAM" since there are different explanations. In MPLS-TP it is agreed that OAM stands for Operation, Administration and Maintenance. Two concerns are following. 1) I'm wondering whether the definition of OAM in OPS area equals the above. If so, which definition takes priority? If not, hope this can be used as a reference to unify the usage of this term. 2) If this draft is to be adopted as an OPS WG draft, should we extend the scope, i.e. not limited to MPLS-TP only? B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Thursday, August 27, 2009 10:47 PM Subject: [OPSAWG] opsawg consensus on draft-andersson-mpls-tp-oam-def draft-andersson-mpls-tp-oam-def was disucssed during teh opsawg session in Stockholm. A few people in the room felt that it should beadopted as a opsawg item. The AD felt that this document would fit under the current opsawg charter. this is a check to see if anyone objects to adopting this ID as an opsawg WG document. please let the list know within the next week tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_fugpEs7N5Wj2QG7pRpAl8Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable

Hi Scott et al,

It's OK for me.

This draft is to clarify the meaning of each letter in the=20 abbreviation of "OAM" since there are different explanations. In MPLS-TP = it is=20 agreed that OAM stands for Operation, Administration and=20 Maintenance.

 

Two concerns are following.

1) I=92m wondering whether the definition of OAM in OPS = area equals the=20 above. If so, which definition takes priority? If not, hope this can be = used as=20 a reference to unify the usage of this = term.

2) If this draft is to be adopted as an OPS WG draft, = should we=20 extend the scope, i.e. not limited to MPLS-TP=20 only?

 
 
B. R.
Tina
http://tinatsou.weebly.com/contact.html
----- Original Message -----
From:=20 Scott O. = Bradner=20
Sent: Thursday, August 27, 2009 = 10:47=20 PM
Subject: [OPSAWG] opsawg = consensus on=20 draft-andersson-mpls-tp-oam-def


draft-andersson-mpls-tp-oam-def was disucssed = during teh=20 opsawg session
in Stockholm.  A few people in the room felt = that it=20 should beadopted
as a opsawg item.  The AD felt that this = document=20 would fit under the
current opsawg charter.

this is a check = to see=20 if anyone objects to adopting this ID as
an opsawg WG=20 document.

please let the list know within the next=20 = week

tnx

Scott
_________________________________________= ______
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg --Boundary_(ID_fugpEs7N5Wj2QG7pRpAl8Q)-- From j.schoenwaelder@jacobs-university.de Sat Aug 29 11:41:48 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06513A69D9 for ; Sat, 29 Aug 2009 11:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqdRZmWuQi4K for ; Sat, 29 Aug 2009 11:41:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 247BD3A68E0 for ; Sat, 29 Aug 2009 11:41:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D1E9C001F; Sat, 29 Aug 2009 20:41:53 +0200 (CEST) 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 DCs4Qng8ouQS; Sat, 29 Aug 2009 20:41:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E113C000D; Sat, 29 Aug 2009 20:41:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A2378C82C4E; Sat, 29 Aug 2009 20:41:49 +0200 (CEST) Date: Sat, 29 Aug 2009 20:41:49 +0200 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20090829184149.GD24348@elstar.local> Mail-Followup-To: Adrian Farrel , David Harrington , "opsawg@ietf.org" , "draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org" References: <20090828130615.GA22962@elstar.local> <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 18:41:48 -0000 On Fri, Aug 28, 2009 at 11:49:50PM +0200, Adrian Farrel wrote: > Two minor points: > > 1. > > Do entries ever get removed from this table? > Not as I understand it. The index is monotonic increasing and wraps at the > maximum value (defined as the lesser of syslogMsgTableMaxSize and > 4294967295). No, it wraps at 4294967295 always. What makes you believe it maps at min(syslogMsgTableMaxSize, 4294967295)? > > Does rollover just overwrite starting at the beginning of the table? > Yes. Only in the case where the agent has storage for 4294967295 table entries, something I consider unlikely implementations will support. > Yes. And this is what swings it for me. > I am just left wondering whether an Agent is more loaded by a bulk read of > 10,000 entries or maintaining a pointer into the table. > > Clear up this last point, and I'm done. If you only need the oldest entry in table insertion time, such an index is of course handy. The question is what practical value it has to be able to retrieve this oldest entry quickly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Adrian.Farrel@huawei.com Fri Aug 28 14:49:54 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9F23A69AC for ; Fri, 28 Aug 2009 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWE5LbP6T253 for ; Fri, 28 Aug 2009 14:49:53 -0700 (PDT) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id CA9D23A68CE for ; Fri, 28 Aug 2009 14:49:52 -0700 (PDT) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP3006OZWNBD7@lhrga01-in.huawei.com> for opsawg@ietf.org; Fri, 28 Aug 2009 22:49:59 +0100 (BST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP3006K9WN8HO@lhrga01-in.huawei.com> for opsawg@ietf.org; Fri, 28 Aug 2009 22:49:59 +0100 (BST) Date: Fri, 28 Aug 2009 22:49:50 +0100 From: Adrian Farrel To: David Harrington , 'Juergen Schoenwaelder' , opsawg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090828130615.GA22962@elstar.local> <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> X-Mailman-Approved-At: Mon, 31 Aug 2009 01:31:38 -0700 Cc: draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 21:49:54 -0000 David, Thanks for that input. It almost closes the issue for me. Two minor points: 1. > Do entries ever get removed from this table? Not as I understand it. The index is monotonic increasing and wraps at the maximum value (defined as the lesser of syslogMsgTableMaxSize and 4294967295). > Does rollover just overwrite starting at the beginning of the table? Yes. > Is there ever a case where the newer entries get interlaced with older > entries? Not unless someone screws up. 2. > The SNMP approach has a major guideline: > keep the agent simple; move complexity to the manager. Yes. And this is what swings it for me. I am just left wondering whether an Agent is more loaded by a bulk read of 10,000 entries or maintaining a pointer into the table. Clear up this last point, and I'm done. Cheers, Adrian ----- Original Message ----- From: "David Harrington" To: "'Juergen Schoenwaelder'" ; opsawg@ietf.org Cc: "'Adrian Farrel'" Sent: Friday, August 28, 2009 3:59 PM Subject: RE: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt > Hi, > > The SNMP approach has a major guideline: > keep the agent simple; move complexity to the manager. > > I think that different applications will want different orderings, and > that the applications should sort based on their preference rather > than forcing this onto the agent. I do not believe there is > significant operational benefit from knowing insertion order. > > Do entries ever get removed from this table? Does rollover just > overwrite starting at the beginning of the table? Is there ever a case > where the newer entries get interlaced with older entries? > > I am not sure I see the benefits of knowing where the oldest entry is. > I think most uses will want the whole table so they can sort it by > whatever criteria it needs. I can see a few edge cases (like having > oldest=0 might imply no rollover has occurred), but nothing > compelling. In the case of wanting to only get updated rows, I would > think knowing where the most recent entry is might be more useful than > knowing where the oldest entry is, so you know where to stop reading, > even if there has been no rollover. This seems to add complexity to > the agent that might not be needed. The manager can simply look at > each getNext retrieval to see if it already has that entry. But a > scalar is fairly simple to add, so I wouldn't object if it got added. > > dbh > >> -----Original Message----- >> From: opsawg-bounces@ietf.org >> [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder >> Sent: Friday, August 28, 2009 9:06 AM >> To: opsawg@ietf.org >> Cc: Adrian Farrel >> Subject: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt >> >> Hi, >> >> during the IESG review of draft-ietf-opsawg-syslog-msg-mib-06.txt, >> Adrian Farrel raised a DISCUSS concerning the syslogMsgTable that we >> have not managed to clear yet and where we seek input from the WG. >> >> The syslogMsgTable is index by syslogMsgIndex, an unsigned index >> number that is increases when entries are added and which rolls over >> if the index number space has been exceeded. This means that the >> entries in the table are (ignoring roll overs here) in the order > they >> were inserted (which is not necessarily the timestamp order of the >> syslog events). This supports the following "tail -f" use case where > a >> management application initially reads the table, remembers the end > of >> the table and during the next poll starts at the last remembered > index >> position. This is useful to quickly check for additions to the >> table. This approach also works with index roll overs unless the > table >> rolls over multiple times during a polling cycle. >> >> Adrian Farrel asks in his DISCUSS whether there is not also a use > case >> to read the table in index order, that is oldest table entry to most >> recent table entry, according to table insertion order. Right now, >> this only works until the first index rollover occurs since after > the >> first index rollover, top table entries might be more recent than >> bottom table entries. This can be fixed for example by adding an >> additional scalar object reporting the index of the oldest entry in >> the table. >> >> As the editor of the document, I did not feel entitled to make a >> decision on this issue. After talking with Scott Bradner, we believe >> the WG needs to decide whether the ability to quickly find the > oldest >> entry in the table (according to the insertion time) is a feature > the >> MIB module needs to support. An important detail to consider here is >> that the table insertion order is not necessarily syslog timestamp >> order. >> >> /js >> >> PS: Adrian, please correct me if my summary of your DISCUSS is >> incorrect or unclear. >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > From Adrian.Farrel@huawei.com Sat Aug 29 11:55:35 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9B93A67F4 for ; Sat, 29 Aug 2009 11:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+QvjkahJKA9 for ; Sat, 29 Aug 2009 11:55:35 -0700 (PDT) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id 06FCF3A684C for ; Sat, 29 Aug 2009 11:55:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP500KARJ8MC0@lhrga03-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 19:55:35 +0100 (BST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP5002XGJ8KWU@lhrga03-in.huawei.com> for opsawg@ietf.org; Sat, 29 Aug 2009 19:55:34 +0100 (BST) Date: Sat, 29 Aug 2009 19:55:26 +0100 From: Adrian Farrel To: Juergen Schoenwaelder Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090828130615.GA22962@elstar.local> <052e01ca27f0$2a0e6060$0600a8c0@china.huawei.com> <20090829184149.GD24348@elstar.local> X-Mailman-Approved-At: Mon, 31 Aug 2009 01:31:38 -0700 Cc: draft-ietf-opsawg-syslog-msg-mib@tools.ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 18:55:36 -0000 >> 1. >> > Do entries ever get removed from this table? >> Not as I understand it. The index is monotonic increasing and wraps at >> the >> maximum value (defined as the lesser of syslogMsgTableMaxSize and >> 4294967295). > > No, it wraps at 4294967295 always. What makes you believe it maps at > min(syslogMsgTableMaxSize, 4294967295)? I'm very sorry. When I wrote this I went back to check on the email thread, and copied from my original question and not from your answer. (That's a poor excuse, I know.) So, this impacts Dave's question; Entries *do* get deleted from the table as the valid index window slides upwards. >> > Does rollover just overwrite starting at the beginning of the table? >> Yes. > > Only in the case where the agent has storage for 4294967295 table > entries, something I consider unlikely implementations will support. > >> Yes. And this is what swings it for me. >> I am just left wondering whether an Agent is more loaded by a bulk read >> of >> 10,000 entries or maintaining a pointer into the table. >> >> Clear up this last point, and I'm done. > > If you only need the oldest entry in table insertion time, such an > index is of course handy. The question is what practical value it has > to be able to retrieve this oldest entry quickly. If we agree that the management station should read and store the table, parse it, and then do whatever it wants to. I agree: none. Adrian