From dromasca@avaya.com Thu Aug 2 09:59:09 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3527221E80D2; Thu, 2 Aug 2012 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdczt0Xyr5V8; Thu, 2 Aug 2012 09:59:08 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1646121E80D1; Thu, 2 Aug 2012 09:59:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFKvGlDGmAcF/2dsb2JhbABFuRiBB4IgAQEBAQMSHgo/DAQCAQgNBAEDAQELBgwLAQYBRQMGCAEBBBMIGodrn2edWItKg2iCPGADm0SKEIJh X-IronPort-AV: E=Sophos;i="4.77,702,1336363200"; d="scan'208";a="318305461" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Aug 2012 12:54:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Aug 2012 12:54:33 -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, 2 Aug 2012 18:59:03 +0200 Message-ID: In-Reply-To: <501AA9DF.6010208@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Basic ietf process question ... Thread-Index: Ac1wy2hzPoZv2TgCQzeKkLeHbDP4+QAAOQGw References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> From: "Romascanu, Dan (Dan)" To: Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:59:09 -0000 Hi, The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda concerning the revision of RFC1052 and discussing a new architecture for management protocols.=20 My personal take is that no one protocol, or one data modeling language can match the operational requirements to configure and manage the wide and wider range of hosts, routers and other network devices that are used to implement IP networks and protocols. We should be talking nowadays about a toolset rather than one tool that fits all. However, this is a discussion that just starts.=20 Regards, Dan > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Robert Raszuk > Sent: Thursday, August 02, 2012 7:25 PM > Cc: ietf@ietf.org > Subject: Basic ietf process question ... >=20 > All, >=20 > IETF documents have number of mandatory sections .. IANA Actions, > Security Considerations, Refs, etc ... >=20 > Does anyone have a good reason why any new protocol definition or > enhancement does not have a build in mandatory "XML schema" section > which would allow to actually use such standards based enhancement in > vendor agnostic way ? >=20 > There is a lot of talk about reinventing APIs, building network wide OS > platform, delivering SDNs (whatever it means at any point of time for > one) ... but how about we start with something very basic yet IMHO > necessary to slowly begin thinking of network as one plane. >=20 > I understand that historically we had/still have SNMP however I have > never seen this being mandatory section of any standards track document. > Usually SNMP comes 5 years behind (if at all) making it obsolete by > design. >=20 > NETCONF is great and very flexible communication channel for > provisioning. However it is sufficient to just look at number of ops > lists to see that those who tried to use it quickly abandoned their > efforts due to complete lack of XML schema from each vendor they happen > to use or complete mismatch of vendor to vendor XML interpretation. >=20 > And while perhaps this is obvious I do not think that any new single > effort will address this. This has to be an atomic and integral part of > each WG's document. >=20 > Looking forward for insightful comments ... >=20 > Best, > R. >=20 From andy@yumaworks.com Thu Aug 2 10:13:46 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2294B11E8133 for ; Thu, 2 Aug 2012 10:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyrdmyOobeMD for ; Thu, 2 Aug 2012 10:13:45 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5441911E813A for ; Thu, 2 Aug 2012 10:13:45 -0700 (PDT) Received: by qaea16 with SMTP id a16so1404603qae.10 for ; Thu, 02 Aug 2012 10:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=se17rDsSnqDvp5SP2U+hl1dRTCXSbLwJKVpTRp9m1vc=; b=BDZJu84DG9ubb/4sO0uOyUcVK0UDkWsxFQgUQjJEWyX46MGKZD1zZHBCPHafbF9HeL ZoXDyrEkxmE7E011ZRjZG0XDUNXdkNkaJNZXEoKsRNaMqn6VJhAP6NtHxr+8K6L6LK2I 1PENNytCBPyo6Uz+zDmSROL0mZSCwQyDWuQ9W0icfYYjPamiZed3jH7Rop6rpB/bs1Bt ShCdVuuUlAJ1q+lpocGYhRs5FVYUfmfC/8T81N0eWu5xunP1kNo+DOg4P2IHri9fA0Gu +bUwOlc2+e6BofPYagQZhLC7jVMPKz/AGMoW2yJ118fgpNRkPVFrp23/gyZUZbveDTyG L7Kw== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr42909924qad.21.1343927624851; Thu, 02 Aug 2012 10:13:44 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 10:13:44 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:e55b:8747:ab19:155b] In-Reply-To: References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> Date: Thu, 2 Aug 2012 10:13:44 -0700 Message-ID: From: Andy Bierman To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQliU1RUybi39LRh+T5ZHX3Qt5buueAhISJoHPwLe8oVhCRIK14yxDEIUt1tRWQEODjvOGbJ Cc: opsawg@ietf.org, ietf@ietf.org, robert@raszuk.net Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:13:46 -0000 On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan) wrote: > Hi, > > The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda > concerning the revision of RFC1052 and discussing a new architecture for > management protocols. > > > My personal take is that no one protocol, or one data modeling language > can match the operational requirements to configure and manage the wide > and wider range of hosts, routers and other network devices that are > used to implement IP networks and protocols. We should be talking > nowadays about a toolset rather than one tool that fits all. However, > this is a discussion that just starts. NMS developers need to spend too many resources on translating naming and other data-modeling specific details so they can be usable within the application. So if 1 data modeling language is not used, then deterministic, loss-less, round-trip translation between data modeling languages is needed. Multiple protocols are not the problem -- incompatible data from multiple protocols is the problem. > > Regards, > > Dan > Andy > > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > Of >> Robert Raszuk >> Sent: Thursday, August 02, 2012 7:25 PM >> Cc: ietf@ietf.org >> Subject: Basic ietf process question ... >> >> All, >> >> IETF documents have number of mandatory sections .. IANA Actions, >> Security Considerations, Refs, etc ... >> >> Does anyone have a good reason why any new protocol definition or >> enhancement does not have a build in mandatory "XML schema" section >> which would allow to actually use such standards based enhancement in >> vendor agnostic way ? >> >> There is a lot of talk about reinventing APIs, building network wide > OS >> platform, delivering SDNs (whatever it means at any point of time for >> one) ... but how about we start with something very basic yet IMHO >> necessary to slowly begin thinking of network as one plane. >> >> I understand that historically we had/still have SNMP however I have >> never seen this being mandatory section of any standards track > document. >> Usually SNMP comes 5 years behind (if at all) making it obsolete by >> design. >> >> NETCONF is great and very flexible communication channel for >> provisioning. However it is sufficient to just look at number of ops >> lists to see that those who tried to use it quickly abandoned their >> efforts due to complete lack of XML schema from each vendor they > happen >> to use or complete mismatch of vendor to vendor XML interpretation. >> >> And while perhaps this is obvious I do not think that any new single >> effort will address this. This has to be an atomic and integral part > of >> each WG's document. >> >> Looking forward for insightful comments ... >> >> Best, >> R. >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Thu Aug 2 10:16:25 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0408821F8652; Thu, 2 Aug 2012 10:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni9ZI9zSsKi9; Thu, 2 Aug 2012 10:16:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1721F8622; Thu, 2 Aug 2012 10:16:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJG0GlDGmAcF/2dsb2JhbABFhXuyK3OBB4IgAQEBAQMBAQEPEQ0EOgsMBAIBCA0EAQMBAQECAgYGDAsBAgICAQElHwMGCAEBBBMIGodrC59eih6TOQSBIYophXIyYAObRIoQgmE X-IronPort-AV: E=Sophos;i="4.77,702,1336363200"; d="scan'208";a="360156194" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Aug 2012 13:12:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Aug 2012 13:11:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 2 Aug 2012 19:16:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Basic ietf process question ... Thread-Index: Ac1w0jSaA+9gSCWUS0eENw3bix/ixQAABTow References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com><501AA9DF.6010208@raszuk.net> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: opsawg@ietf.org, ietf@ietf.org, robert@raszuk.net Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:16:25 -0000 WWVzLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciBhIGJhc2ljIGluZm9ybWF0aW9uIG1vZGVsIHdy aXR0ZW4gaW4gWE1MIGNhbiBiZSBhIHVzZWZ1bCBzdGFydGluZyBwb2ludCAodHJ5aW5nIHRvIGlu dGVycHJldCB0aGUgcHJvcG9zYWwgbWFkZSBieSBSb2JlcnQpLiANCg0KRGFuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5 dW1hd29ya3MuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDAyLCAyMDEyIDg6MTQgUE0N Cj4gVG86IFJvbWFzY2FudSwgRGFuIChEYW4pDQo+IENjOiByb2JlcnRAcmFzenVrLm5ldDsgb3Bz YXdnQGlldGYub3JnOyBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBCYXNp YyBpZXRmIHByb2Nlc3MgcXVlc3Rpb24gLi4uDQo+IA0KPiBPbiBUaHUsIEF1ZyAyLCAyMDEyIGF0 IDk6NTkgQU0sIFJvbWFzY2FudSwgRGFuIChEYW4pDQo+IDxkcm9tYXNjYUBhdmF5YS5jb20+IHdy b3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gVGhlIE9QU0FXRy9PUFNBUkVBIG9wZW4gbWVldGluZyB0 aGlzIGFmdGVybm9vbiBoYXMgYW4gaXRlbSBvbiB0aGUNCj4gPiBhZ2VuZGEgY29uY2VybmluZyB0 aGUgcmV2aXNpb24gb2YgUkZDMTA1MiBhbmQgZGlzY3Vzc2luZyBhIG5ldw0KPiA+IGFyY2hpdGVj dHVyZSBmb3IgbWFuYWdlbWVudCBwcm90b2NvbHMuDQo+ID4NCj4gPg0KPiA+IE15IHBlcnNvbmFs IHRha2UgaXMgdGhhdCBubyBvbmUgcHJvdG9jb2wsIG9yIG9uZSBkYXRhIG1vZGVsaW5nDQo+ID4g bGFuZ3VhZ2UgY2FuIG1hdGNoIHRoZSBvcGVyYXRpb25hbCByZXF1aXJlbWVudHMgdG8gY29uZmln dXJlIGFuZA0KPiA+IG1hbmFnZSB0aGUgd2lkZSBhbmQgd2lkZXIgcmFuZ2Ugb2YgaG9zdHMsIHJv dXRlcnMgYW5kIG90aGVyIG5ldHdvcmsNCj4gPiBkZXZpY2VzIHRoYXQgYXJlIHVzZWQgdG8gaW1w bGVtZW50IElQIG5ldHdvcmtzIGFuZCBwcm90b2NvbHMuIFdlDQo+ID4gc2hvdWxkIGJlIHRhbGtp bmcgbm93YWRheXMgYWJvdXQgYSB0b29sc2V0IHJhdGhlciB0aGFuIG9uZSB0b29sIHRoYXQNCj4g PiBmaXRzIGFsbC4gSG93ZXZlciwgdGhpcyBpcyBhIGRpc2N1c3Npb24gdGhhdCBqdXN0IHN0YXJ0 cy4NCj4gDQo+IE5NUyBkZXZlbG9wZXJzIG5lZWQgdG8gc3BlbmQgdG9vIG1hbnkgcmVzb3VyY2Vz IG9uIHRyYW5zbGF0aW5nIG5hbWluZw0KPiBhbmQgb3RoZXIgZGF0YS1tb2RlbGluZyBzcGVjaWZp YyBkZXRhaWxzIHNvIHRoZXkgY2FuIGJlIHVzYWJsZSB3aXRoaW4NCj4gdGhlIGFwcGxpY2F0aW9u LiAgU28gaWYgMSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIGlzIG5vdCB1c2VkLCB0aGVuDQo+IGRl dGVybWluaXN0aWMsIGxvc3MtbGVzcywgcm91bmQtdHJpcCB0cmFuc2xhdGlvbiBiZXR3ZWVuIGRh dGEgbW9kZWxpbmcNCj4gbGFuZ3VhZ2VzIGlzIG5lZWRlZC4gIE11bHRpcGxlIHByb3RvY29scyBh cmUgbm90IHRoZSBwcm9ibGVtIC0tDQo+IGluY29tcGF0aWJsZSBkYXRhIGZyb20gbXVsdGlwbGUg cHJvdG9jb2xzIGlzIHRoZSBwcm9ibGVtLg0KPiANCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4g PiBEYW4NCj4gPg0KPiANCj4gQW5keQ0KPiANCj4gPg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaWV0Zi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86aWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZg0KPiA+PiBSb2JlcnQg UmFzenVrDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDIsIDIwMTIgNzoyNSBQTQ0KPiA+ PiBDYzogaWV0ZkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBCYXNpYyBpZXRmIHByb2Nlc3MgcXVl c3Rpb24gLi4uDQo+ID4+DQo+ID4+IEFsbCwNCj4gPj4NCj4gPj4gSUVURiBkb2N1bWVudHMgaGF2 ZSBudW1iZXIgb2YgbWFuZGF0b3J5IHNlY3Rpb25zIC4uIElBTkEgQWN0aW9ucywNCj4gPj4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMsIFJlZnMsIGV0YyAuLi4NCj4gPj4NCj4gPj4gRG9lcyBhbnlv bmUgaGF2ZSBhIGdvb2QgcmVhc29uIHdoeSBhbnkgbmV3IHByb3RvY29sIGRlZmluaXRpb24gb3IN Cj4gPj4gZW5oYW5jZW1lbnQgZG9lcyBub3QgaGF2ZSBhIGJ1aWxkIGluIG1hbmRhdG9yeSAiWE1M IHNjaGVtYSIgc2VjdGlvbg0KPiA+PiB3aGljaCB3b3VsZCBhbGxvdyB0byBhY3R1YWxseSB1c2Ug c3VjaCBzdGFuZGFyZHMgYmFzZWQgZW5oYW5jZW1lbnQgaW4NCj4gPj4gdmVuZG9yIGFnbm9zdGlj IHdheSA/DQo+ID4+DQo+ID4+IFRoZXJlIGlzIGEgbG90IG9mIHRhbGsgYWJvdXQgcmVpbnZlbnRp bmcgQVBJcywgYnVpbGRpbmcgbmV0d29yayB3aWRlDQo+ID4gT1MNCj4gPj4gcGxhdGZvcm0sIGRl bGl2ZXJpbmcgU0ROcyAod2hhdGV2ZXIgaXQgbWVhbnMgYXQgYW55IHBvaW50IG9mIHRpbWUgZm9y DQo+ID4+IG9uZSkgLi4uIGJ1dCBob3cgYWJvdXQgd2Ugc3RhcnQgd2l0aCBzb21ldGhpbmcgdmVy eSBiYXNpYyB5ZXQgSU1ITw0KPiA+PiBuZWNlc3NhcnkgdG8gc2xvd2x5IGJlZ2luIHRoaW5raW5n IG9mIG5ldHdvcmsgYXMgb25lIHBsYW5lLg0KPiA+Pg0KPiA+PiBJIHVuZGVyc3RhbmQgdGhhdCBo aXN0b3JpY2FsbHkgd2UgaGFkL3N0aWxsIGhhdmUgU05NUCBob3dldmVyIEkgaGF2ZQ0KPiA+PiBu ZXZlciBzZWVuIHRoaXMgYmVpbmcgbWFuZGF0b3J5IHNlY3Rpb24gb2YgYW55IHN0YW5kYXJkcyB0 cmFjaw0KPiA+IGRvY3VtZW50Lg0KPiA+PiBVc3VhbGx5IFNOTVAgY29tZXMgNSB5ZWFycyBiZWhp bmQgKGlmIGF0IGFsbCkgbWFraW5nIGl0IG9ic29sZXRlIGJ5DQo+ID4+IGRlc2lnbi4NCj4gPj4N Cj4gPj4gTkVUQ09ORiBpcyBncmVhdCBhbmQgdmVyeSBmbGV4aWJsZSBjb21tdW5pY2F0aW9uIGNo YW5uZWwgZm9yDQo+ID4+IHByb3Zpc2lvbmluZy4gSG93ZXZlciBpdCBpcyBzdWZmaWNpZW50IHRv IGp1c3QgbG9vayBhdCBudW1iZXIgb2Ygb3BzDQo+ID4+IGxpc3RzIHRvIHNlZSB0aGF0IHRob3Nl IHdobyB0cmllZCB0byB1c2UgaXQgcXVpY2tseSBhYmFuZG9uZWQgdGhlaXINCj4gPj4gZWZmb3J0 cyBkdWUgdG8gY29tcGxldGUgbGFjayBvZiBYTUwgc2NoZW1hIGZyb20gZWFjaCB2ZW5kb3IgdGhl eQ0KPiA+IGhhcHBlbg0KPiA+PiB0byB1c2Ugb3IgY29tcGxldGUgbWlzbWF0Y2ggb2YgdmVuZG9y IHRvIHZlbmRvciBYTUwgaW50ZXJwcmV0YXRpb24uDQo+ID4+DQo+ID4+IEFuZCB3aGlsZSBwZXJo YXBzIHRoaXMgaXMgb2J2aW91cyBJIGRvIG5vdCB0aGluayB0aGF0IGFueSBuZXcgc2luZ2xlDQo+ ID4+IGVmZm9ydCB3aWxsIGFkZHJlc3MgdGhpcy4gVGhpcyBoYXMgdG8gYmUgYW4gYXRvbWljIGFu ZCBpbnRlZ3JhbCBwYXJ0DQo+ID4gb2YNCj4gPj4gZWFjaCBXRydzIGRvY3VtZW50Lg0KPiA+Pg0K PiA+PiBMb29raW5nIGZvcndhcmQgZm9yIGluc2lnaHRmdWwgY29tbWVudHMgLi4uDQo+ID4+DQo+ ID4+IEJlc3QsDQo+ID4+IFIuDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4gPiBP UFNBV0dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29wc2F3Zw0K From ietfdbh@comcast.net Thu Aug 2 10:20:02 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8011E8153 for ; Thu, 2 Aug 2012 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWMsD8uOuD4A for ; Thu, 2 Aug 2012 10:20:01 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id DB81B11E8129 for ; Thu, 2 Aug 2012 10:20:00 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id hqy51j00A1wpRvQ59tL3Vi; Thu, 02 Aug 2012 17:20:03 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta18.westchester.pa.mail.comcast.net with comcast id htRS1j00S3Ecudz3etRTAe; Thu, 02 Aug 2012 17:25:30 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 02 Aug 2012 13:19:55 -0400 From: David Harrington To: "Romascanu, Dan (Dan)" , Message-ID: Thread-Topic: [OPSAWG] Basic ietf process question ... In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:20:03 -0000 +1 -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/2/12 12:59 PM, "Romascanu, Dan (Dan)" wrote: >Hi, > >The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda >concerning the revision of RFC1052 and discussing a new architecture for >management protocols. > > >My personal take is that no one protocol, or one data modeling language >can match the operational requirements to configure and manage the wide >and wider range of hosts, routers and other network devices that are >used to implement IP networks and protocols. We should be talking >nowadays about a toolset rather than one tool that fits all. However, >this is a discussion that just starts. > >Regards, > >Dan > > > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >Of >> Robert Raszuk >> Sent: Thursday, August 02, 2012 7:25 PM >> Cc: ietf@ietf.org >> Subject: Basic ietf process question ... >> >> All, >> >> IETF documents have number of mandatory sections .. IANA Actions, >> Security Considerations, Refs, etc ... >> >> Does anyone have a good reason why any new protocol definition or >> enhancement does not have a build in mandatory "XML schema" section >> which would allow to actually use such standards based enhancement in >> vendor agnostic way ? >> >> There is a lot of talk about reinventing APIs, building network wide >OS >> platform, delivering SDNs (whatever it means at any point of time for >> one) ... but how about we start with something very basic yet IMHO >> necessary to slowly begin thinking of network as one plane. >> >> I understand that historically we had/still have SNMP however I have >> never seen this being mandatory section of any standards track >document. >> Usually SNMP comes 5 years behind (if at all) making it obsolete by >> design. >> >> NETCONF is great and very flexible communication channel for >> provisioning. However it is sufficient to just look at number of ops >> lists to see that those who tried to use it quickly abandoned their >> efforts due to complete lack of XML schema from each vendor they >happen >> to use or complete mismatch of vendor to vendor XML interpretation. >> >> And while perhaps this is obvious I do not think that any new single >> effort will address this. This has to be an atomic and integral part >of >> each WG's document. >> >> Looking forward for insightful comments ... >> >> Best, >> R. >> > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From brian.e.carpenter@gmail.com Thu Aug 2 11:11:19 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63C21F8592; Thu, 2 Aug 2012 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.46 X-Spam-Level: X-Spam-Status: No, score=-101.46 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C21BF+CaE2UM; Thu, 2 Aug 2012 11:11:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9B11E8200; Thu, 2 Aug 2012 11:11:12 -0700 (PDT) Received: by weyu54 with SMTP id u54so6888972wey.31 for ; Thu, 02 Aug 2012 11:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=15LcXXzM72CCqEbZLP5PBiUzAiuj14e5H9nyrnaPvAE=; b=Emg8+eOMknZ8acozJpcMknPOk7a24Q/Uv+7g0kWHH+zkEuBh+WmoaIjm55POWov5WL S+6c6eUxGHxT/RfT3voFU7ZOXbn6teUVZfioUACy7v4xFIVlCQOxRBo+fYYIK0VqmJ81 U+s4bFa5u3R+uK1N/b82fux1cLKelpwFy0oVPtG+f1bCcKgkI3k0FPfqMmd4Mi8pAdgB ohILsuIRWS99NrZeg1w3MMQ9UdvZPXPZinY9WLqqx0DGZM1FJSbNTuECXH26lZFqKFAf fot0XL/JXXPsE8sg/gY9ZzYjPWRoDamdUnXOf9yPcfXPmd3tc94gojGFemLKXpEpEWh8 lpdg== Received: by 10.180.104.197 with SMTP id gg5mr6700774wib.9.1343931071890; Thu, 02 Aug 2012 11:11:11 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id fb20sm18993230wid.1.2012.08.02.11.11.10 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 11:11:11 -0700 (PDT) Message-ID: <501AC2C7.6040707@gmail.com> Date: Thu, 02 Aug 2012 19:11:19 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: robert@raszuk.net References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> In-Reply-To: <501AB4F5.7030205@raszuk.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:11:19 -0000 I think anyone with intimate experience of the Web Services standards experiment (trying to use XML as if it was a Turing machine) would have extreme doubts about any proposal to impose such a requirement. It was not for no reason that many people came to refer to the Web Services family of standards as "WS-splat". The words "small" and "xml schema" don't really belong together, Regards Brian Carpenter On 02/08/2012 18:12, Robert Raszuk wrote: > Hi Dan, > >> We should be talking >> nowadays about a toolset rather than one tool that fits all. > > Just to clarify what I asked about .. I am not looking for a single tool > or single protocol to be used to configure everything. > > I am asking for small building block like xml schema (or something > similar) to be part of each new IETF proposal or protocol change. IMHO > only that can allow any further more fancy abstractions and tools to be > build and used in practice. > > Best regards, > R. > > > >> Hi, >> >> The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda >> concerning the revision of RFC1052 and discussing a new architecture for >> management protocols. >> >> >> My personal take is that no one protocol, or one data modeling language >> can match the operational requirements to configure and manage the wide >> and wider range of hosts, routers and other network devices that are >> used to implement IP networks and protocols. We should be talking >> nowadays about a toolset rather than one tool that fits all. However, >> this is a discussion that just starts. >> >> Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >> Of >>> Robert Raszuk >>> Sent: Thursday, August 02, 2012 7:25 PM >>> Cc: ietf@ietf.org >>> Subject: Basic ietf process question ... >>> >>> All, >>> >>> IETF documents have number of mandatory sections .. IANA Actions, >>> Security Considerations, Refs, etc ... >>> >>> Does anyone have a good reason why any new protocol definition or >>> enhancement does not have a build in mandatory "XML schema" section >>> which would allow to actually use such standards based enhancement in >>> vendor agnostic way ? >>> >>> There is a lot of talk about reinventing APIs, building network wide >> OS >>> platform, delivering SDNs (whatever it means at any point of time for >>> one) ... but how about we start with something very basic yet IMHO >>> necessary to slowly begin thinking of network as one plane. >>> >>> I understand that historically we had/still have SNMP however I have >>> never seen this being mandatory section of any standards track >> document. >>> Usually SNMP comes 5 years behind (if at all) making it obsolete by >>> design. >>> >>> NETCONF is great and very flexible communication channel for >>> provisioning. However it is sufficient to just look at number of ops >>> lists to see that those who tried to use it quickly abandoned their >>> efforts due to complete lack of XML schema from each vendor they >> happen >>> to use or complete mismatch of vendor to vendor XML interpretation. >>> >>> And while perhaps this is obvious I do not think that any new single >>> effort will address this. This has to be an atomic and integral part >> of >>> each WG's document. >>> >>> Looking forward for insightful comments ... >>> >>> Best, >>> R. >>> >> >> >> > > From robert@raszuk.net Thu Aug 2 11:17:33 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A16611E8220 for ; Thu, 2 Aug 2012 11:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtIeyj26+0ZJ for ; Thu, 2 Aug 2012 11:17:32 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2024911E821D for ; Thu, 2 Aug 2012 11:17:32 -0700 (PDT) Received: (qmail 8399 invoked by uid 399); 2 Aug 2012 18:17:31 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 18:17:31 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501AC43A.3020307@raszuk.net> Date: Thu, 02 Aug 2012 20:17:30 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> In-Reply-To: <501AC2C7.6040707@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:17:33 -0000 Hi Brian, Perhaps we understand a different thing by "xml schema" As example what I had in mind when asking this question was the example from "Appendix A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where while perhaps not yet complete it does provide decent representation of one of the popular service today. That's what I had mind asking why such appendix isn't a mandatory part of each new protocol extension. It has very little to do with Web Services you may be referring to. Many thx, R. > I think anyone with intimate experience of the Web Services standards > experiment (trying to use XML as if it was a Turing machine) would have > extreme doubts about any proposal to impose such a requirement. > > It was not for no reason that many people came to refer to the Web > Services family of standards as "WS-splat". The words "small" and > "xml schema" don't really belong together, > > Regards > Brian Carpenter > > On 02/08/2012 18:12, Robert Raszuk wrote: >> Hi Dan, >> >>> We should be talking >>> nowadays about a toolset rather than one tool that fits all. >> >> Just to clarify what I asked about .. I am not looking for a single tool >> or single protocol to be used to configure everything. >> >> I am asking for small building block like xml schema (or something >> similar) to be part of each new IETF proposal or protocol change. IMHO >> only that can allow any further more fancy abstractions and tools to be >> build and used in practice. >> >> Best regards, >> R. >> >> >> >>> Hi, >>> >>> The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda >>> concerning the revision of RFC1052 and discussing a new architecture for >>> management protocols. >>> >>> >>> My personal take is that no one protocol, or one data modeling language >>> can match the operational requirements to configure and manage the wide >>> and wider range of hosts, routers and other network devices that are >>> used to implement IP networks and protocols. We should be talking >>> nowadays about a toolset rather than one tool that fits all. However, >>> this is a discussion that just starts. >>> >>> Regards, >>> >>> Dan >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >>> Of >>>> Robert Raszuk >>>> Sent: Thursday, August 02, 2012 7:25 PM >>>> Cc: ietf@ietf.org >>>> Subject: Basic ietf process question ... >>>> >>>> All, >>>> >>>> IETF documents have number of mandatory sections .. IANA Actions, >>>> Security Considerations, Refs, etc ... >>>> >>>> Does anyone have a good reason why any new protocol definition or >>>> enhancement does not have a build in mandatory "XML schema" section >>>> which would allow to actually use such standards based enhancement in >>>> vendor agnostic way ? >>>> >>>> There is a lot of talk about reinventing APIs, building network wide >>> OS >>>> platform, delivering SDNs (whatever it means at any point of time for >>>> one) ... but how about we start with something very basic yet IMHO >>>> necessary to slowly begin thinking of network as one plane. >>>> >>>> I understand that historically we had/still have SNMP however I have >>>> never seen this being mandatory section of any standards track >>> document. >>>> Usually SNMP comes 5 years behind (if at all) making it obsolete by >>>> design. >>>> >>>> NETCONF is great and very flexible communication channel for >>>> provisioning. However it is sufficient to just look at number of ops >>>> lists to see that those who tried to use it quickly abandoned their >>>> efforts due to complete lack of XML schema from each vendor they >>> happen >>>> to use or complete mismatch of vendor to vendor XML interpretation. >>>> >>>> And while perhaps this is obvious I do not think that any new single >>>> effort will address this. This has to be an atomic and integral part >>> of >>>> each WG's document. >>>> >>>> Looking forward for insightful comments ... >>>> >>>> Best, >>>> R. >>>> >>> >>> >>> >> >> > > From victor.kuarsingh@gmail.com Thu Aug 2 15:40:29 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397D511E80A5; Thu, 2 Aug 2012 15:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beccnGcz-2zl; Thu, 2 Aug 2012 15:40:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4A11E80A2; Thu, 2 Aug 2012 15:40:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so80405obb.31 for ; Thu, 02 Aug 2012 15:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=cfkuWQZh+dIlunpesIJneKuPLbg5bjPat9YYu45jf9E=; b=Qdby3yyLz14IhkLaj6axCyUVy2dX4UbjSZ/a16P2wZuR62btF4YyGYTy/btsNaUi2g P9FR3vG6xUlge+7v4Mn3TPZRLf06aW6y0d08CtEDBUYettvSmFCOWGEupl/Y35PKq9WW z24RvnnKRtzBamb0eGHutvNuEixr6j39FQfLA9NokJKZf1iBGBwcWT8KGAmYElssOdn5 bS6lSzq+02/PApZj4AYAfKYfAcuysvFrHUPyAavwyI7jgFq7H/1EZ0SRVKIX3U87Cc3J DW1XL+iLSW+yBCJiNKIZrn4+P3/YP6R2j2ZXkKpj5icmD30BN4Trg2VelkQqrDZFCScx Ya/A== Received: by 10.60.30.170 with SMTP id t10mr40608345oeh.10.1343947227840; Thu, 02 Aug 2012 15:40:27 -0700 (PDT) Received: from [130.129.19.190] (dhcp-13be.meeting.ietf.org. [130.129.19.190]) by mx.google.com with ESMTPS id hz6sm7413083obb.1.2012.08.02.15.40.24 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 15:40:26 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 02 Aug 2012 15:40:21 -0700 From: Victor Kuarsingh To: , , Message-ID: Thread-Topic: Feedback LSN Deployment Draft Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3426766825_19161737" Subject: [OPSAWG] Feedback LSN Deployment Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:40:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3426766825_19161737 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit OPSAWG/Behave/Sunset4 WGs, Following further consideration in OPSAWG, the Chairs have requested addition opportunity for feedback from the Behave and Sunset4 WGs regarding draft-ietf-opsawg-lsn-deployment-00. (link - http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-00) What we are looking for is technical feedback on the architecture/concepts defined in the draft. What we are NOT looking for is opinions on why CGN is bad. I expect there may be textual updates needed along with other minor items. There was also a plan to remove the "Performance" section which was originally added before other drafts were available discussing CGN/NAT444 impacts (like draft-donley-nat444-impacts) The document presupposes an operator has decided to do CGN/NAT444 (business/technical reasons particular to them) and therefore may require architectural options on how to deploy this in an existing network. The document offers once such option using BGP/MPLS IP VPNs. I appreciate feedback. Regards, Victor K --B_3426766825_19161737 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
OPSAWG/Behave/Sunset4 WGs,

Following further consideration in OPSAWG, the Chair= s have requested addition opportunity for feedback from the Behave and Sunse= t4 WGs regarding draft-ietf-opsawg-lsn-deployment-00. (link - http://tools= .ietf.org/html/draft-ietf-opsawg-lsn-deployment-00)

=
What we are looking for is technical feedback on the architecture/conce= pts defined in the draft.  What we are NOT looking for is opinions on w= hy CGN is bad.  I expect there may be textual updates needed along with= other minor items. 

There was also a plan to = remove the "Performance" section which was originally added before other dra= fts were available discussing CGN/NAT444 impacts (like draft-donley-nat= 444-impacts)

The document presupposes an operator h= as decided to do CGN/NAT444 (business/technical reasons particular to them) = and therefore may require architectural options on how to deploy this in an = existing network.  The document offers once such option using BGP/MPLS = IP VPNs.

I appreciate feedback.

Regards,

Victor K
--B_3426766825_19161737-- From aakhter@cisco.com Thu Aug 2 16:05:59 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95F11E814E; Thu, 2 Aug 2012 16:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRfDab+lefgt; Thu, 2 Aug 2012 16:05:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BDB1211E8120; Thu, 2 Aug 2012 16:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=2296; q=dns/txt; s=iport; t=1343948757; x=1345158357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G+1h5te9E/xl072EJ1XShgVEFWzyNP4fS8kPk2vRIwE=; b=UCI4AzxAATbj/ZzX0l95ds9ncUpo9wSKynerP0l+AhzE07B8jQsoggWq Uf8mE8kpVXF5e/Y3AZw5rAVvIi8Ry1h1OcRhOpRqj8g/DclA4+aYH0/du QD0zmhEvMR5+ixYb9FJfUZxswbR2pFjPFv2buJRsHlif+SNDNkWj/yBrF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHUHG1CtJXHA/2dsb2JhbAArGhaFZbItc4EHgiABAQEDAQEBAQ8BEBE6CwwEAgEGAhEEAQEDAgYCGwMCAgIlCxQBCAgBAQQBDQEECAERCIdlBgspnE+NGZMtgSGKKRqFWDJgA5FjhHiJcQiDGoFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="108051806" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2012 23:05:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72N5aJY011811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 23:05:36 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.85]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 18:05:36 -0500 From: "Aamer Akhter (aakhter)" To: Christopher LILJENSTOLPE , "opsawg@ietf.org" Thread-Topic: [Tools-discuss] hosting of opsawg at news.gmane.org Thread-Index: Ac0VygSjeXWBA+n0RVmJD+wdjXWn9BbOTXbA Date: Thu, 2 Aug 2012 23:05:35 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC0960F53CC57@xmb-rcd-x15.cisco.com> References: <7F298ACC76CC154F832B6D02852D169F079F3DC8@XMB-RCD-101.cisco.com> <9AD0D6B7-6587-4864-B427-571DC97C44FD@cdl.asgaard.org> In-Reply-To: <9AD0D6B7-6587-4864-B427-571DC97C44FD@cdl.asgaard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.113.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--36.873500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Tools-discuss@ietf.org" , opsawg-chairs Subject: Re: [OPSAWG] [Tools-discuss] hosting of opsawg at news.gmane.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:05:59 -0000 SGkgR3V5cywNCg0KRGlkIHRoZSByZXBsaWNhdGlvbiBvZiB0aGUgYXJjaGl2ZSB0byBuZXdzLmdt YW5lLm9yZyBvY2NvdXI/IEkgd2Fzbid0IGFibGUgdG8gZmluZCBpdCB0aGVyZS4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRvb2xzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnRvb2xzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENo cmlzdG9waGVyIExJTEpFTlNUT0xQRQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxMiA1 OjAxIEFNDQpUbzogQWFtZXIgQWtodGVyIChhYWtodGVyKTsgb3BzYXdnQGlldGYub3JnDQpDYzog VG9vbHMtZGlzY3Vzc0BpZXRmLm9yZzsgb3BzYXdnLWNoYWlycw0KU3ViamVjdDogUmU6IFtUb29s cy1kaXNjdXNzXSBob3N0aW5nIG9mIG9wc2F3ZyBhdCBuZXdzLmdtYW5lLm9yZw0KDQpDb25zaWRl ciBpdCBkb25lLiAgUGxlYXNlIHJlbWVtYmVyIHRoYXQgdGhlIGlldGYgbWFpbGluZyBsaXN0IGFy Y2hpdmUgaXMgdGhlIGRlZmluaXRpdmUgb25lLg0KDQoJQ2hyaXMNCg0KT24gMjhNYXIyMDEyLCBh dCAwMC40OCwgQWFtZXIgQWtodGVyIChhYWtodGVyKSB3cm90ZToNCg0KPiANCj4gDQo+IFRoZXJl IGFyZSBhIGxhcmdlIG51bWJlciBvZiBJRVRGIG1haWxpbmcgbGlzdHMgaG9zdGVkIGF0IGdtYW5l LiBJIGhhdmUgDQo+IGZvdW5kIGl0IGEgbXVjaCBlYXNpZXIgaW50ZXJmYWNlIHRvIGludGVyYWN0 IHdpdGggcmF0aGVyIHRoYW4gdGhlIA0KPiBvZmZpY2lhbCBhcmNoaXZlIGF0IA0KPiAoaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29wc2F3Zy9jdXJyZW50L21haWxsaXN0Lmh0 bWwpLg0KPiANCj4gDQo+IA0KPiAxKSAgICAgIFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGltcG9y dCB0aGUgZXhpc3RpbmcgYXJjaGl2ZSBpbnRvDQo+IGdtYW5lLm9yZz8NCj4gVGhpcyByZXF1aXJl cyB0aGUgJ293bmVyJyBvZiBtYWlsaW5nIGxpc3QgdG8gbWFrZSB0aGUgcmVxdWVzdC4gDQo+IGh0 dHA6Ly9nbWFuZS5vcmcvaW1wb3J0LnBocA0KPiANCj4gDQo+IA0KPiAyKSAgICAgIFdvdWxkIGl0 IGJlIHBvc3NpYmxlIGZvciBnbWFuZS5vcmcgdG8gc3Vic2NyaWJlIHRvIHRoZSBtYWlsaW5nDQo+ IGxpc3Qgc3VjaCBhcyB0byBhcmNoaXZlIHRoZSBmb3J3YXJkIGRpc2N1c3Npb25zIGluIGEgbmlj ZXIgaW50ZXJmYWNlPw0KPiBodHRwOi8vZ21hbmUub3JnL3N1YnNjcmliZS5waHANCj4gDQo+IA0K PiANCj4gVGhhbmtzIGZvciBhbnkgY29uc2lkZXJhdGlvbiwNCj4gDQo+IGFhDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KDQotLQ0K5p2O5p+v552/DQpDaGVjayBteSBQR1Aga2V5IGhlcmU6 IGh0dHBzOi8vd3d3LmFzZ2FhcmQub3JnL35jZGwvY2RsLmFzYw0KQ3VycmVudCB2Q2FyZCBoZXJl OiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2NkbC52Y2YNCkNoZWNrIG15IGNhbGVuZGFy IGF2YWlsYWJpbGl0eTogaHR0cHM6Ly90dW5nbGUubWUvY2RsDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUb29scy1kaXNjdXNzIG1haWxpbmcgbGlz dA0KVG9vbHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90b29scy1kaXNjdXNzDQo= From aakhter@cisco.com Thu Aug 2 16:30:54 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738F211E8129 for ; Thu, 2 Aug 2012 16:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulF3EaDPwFTS for ; Thu, 2 Aug 2012 16:30:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 384F511E80F0 for ; Thu, 2 Aug 2012 16:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3298; q=dns/txt; s=iport; t=1343950253; x=1345159853; h=from:to:cc:subject:date:message-id:mime-version; bh=IePLTKGMdFshLmA6G2uuw9CG/fUCTqgU39h0UtpQAlY=; b=iwGlh8hYP26YHl7rDgSgb/MaDyFJWt8Q3n3Ahnr7yqvd0QX732O60eQZ mp6e7KEYFTXbb4/dH9R/gLUWzSB9EaszGWaes1mOeKEJhXV+bSVkUJ9HM +mvp3g/xBr5KECF5qWU+d4Rhkl8GMETUqWaoJ7HDU2nTXwAJYBIoM3fMj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOQMG1CtJXG8/2dsb2JhbABFgkq2UYEHgiIBBBIBGkwSAQweViYBBA4NGodrnQigS5FuYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208,217";a="105041004" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 02 Aug 2012 23:30:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72NUqrL031281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 23:30:52 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.85]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 18:30:52 -0500 From: "Aamer Akhter (aakhter)" To: "draft-schoenw-opsawg-vm-mib@tools.ietf.org" Thread-Topic: draft-schoenw-opsawg-vm-mib scaling question Thread-Index: Ac1xA6F5IspGVUWZRdikvdd9R84mTg== Date: Thu, 2 Aug 2012 23:30:51 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC0960F53D096@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.113.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--26.947600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75C0E47A1889264493A2DCB2869AC0960F53D096xmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: [OPSAWG] draft-schoenw-opsawg-vm-mib scaling question X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:30:54 -0000 --_000_75C0E47A1889264493A2DCB2869AC0960F53D096xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, There was a question regarding scaling in the case of hundreds of VMs etc. In cases if a full dump is not needed, does it make sense to have the abili= ty to create flag setting thresholds that represent an aggregation and port= ion of a MIB tree? This might provide a more lightweight polling mechanism = than a scan of large spans of the MIB. However, Chris made a really good question regarding if MIBs are really rel= evant given the Regards,aa --_000_75C0E47A1889264493A2DCB2869AC0960F53D096xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there,

 

There was a question regarding scaling in the case o= f hundreds of VMs etc.

 

In cases if a full dump is not needed, does it make = sense to have the ability to create flag setting thresholds that represent = an aggregation and portion of a MIB tree? This might provide a more lightwe= ight polling mechanism than a scan of large spans of the MIB.

 

However, Chris made a really good question regarding= if MIBs are really relevant given the

 

Regards,aa

--_000_75C0E47A1889264493A2DCB2869AC0960F53D096xmbrcdx15ciscoc_-- From j.schoenwaelder@jacobs-university.de Thu Aug 2 16:42:12 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5766221E8039 for ; Thu, 2 Aug 2012 16:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2PEvpvWgNYI for ; Thu, 2 Aug 2012 16:42:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6E38A21E804D for ; Thu, 2 Aug 2012 16:42:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E23FB20C06; Fri, 3 Aug 2012 01:42:06 +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 2VtYiBZqK20x; Fri, 3 Aug 2012 01:42:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5364120C03; Fri, 3 Aug 2012 01:42:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E58B2102EAD; Fri, 3 Aug 2012 01:42:04 +0200 (CEST) Date: Fri, 3 Aug 2012 01:42:04 +0200 From: Juergen Schoenwaelder To: "Aamer Akhter (aakhter)" Message-ID: <20120802234204.GC87351@elstar.local> Mail-Followup-To: "Aamer Akhter (aakhter)" , "draft-schoenw-opsawg-vm-mib@tools.ietf.org" , "opsawg@ietf.org" References: <75C0E47A1889264493A2DCB2869AC0960F53D096@xmb-rcd-x15.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75C0E47A1889264493A2DCB2869AC0960F53D096@xmb-rcd-x15.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-schoenw-opsawg-vm-mib@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-schoenw-opsawg-vm-mib scaling question X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2012 23:42:12 -0000 On Thu, Aug 02, 2012 at 11:30:51PM +0000, Aamer Akhter (aakhter) wrote: > Hi there, > > There was a question regarding scaling in the case of hundreds of VMs etc. > > In cases if a full dump is not needed, does it make sense to have the ability to create flag setting thresholds that represent an aggregation and portion of a MIB tree? This might provide a more lightweight polling mechanism than a scan of large spans of the MIB. > Can you perhaps elaborate using an example what "create flag setting thresholds that represent an aggregation and portion of a MIB tree" means? BTW, there are generic thresholding and even expression MIBs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From aakhter@cisco.com Thu Aug 2 21:04:54 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10B11E80E5 for ; Thu, 2 Aug 2012 21:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFox7jjSOIvJ for ; Thu, 2 Aug 2012 21:04:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BA97A11E80B8 for ; Thu, 2 Aug 2012 21:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=2306; q=dns/txt; s=iport; t=1343966693; x=1345176293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dTg8NgWjeebS9JmAi/JWXydBPGU6Tf1qOK8eRAL1uKU=; b=NMjp/X6qs2oJ2Vm9zAA8eesC/Tq4hmpPUcDzxZtUmNh0kepAf+cCl2uM o1EmLebBsRQTVkFRZ4TSoT+MQCPglvpM+6ojfv8oOjjTc5lDM3+IIaXmC kpTg41XGMW8K3LsvdAUkRNw6Bf4qyGtDx7/gA6gGS54dvpLLpz98qmZKl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAxNG1CtJV2a/2dsb2JhbABCA7kngQeCIAEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAEBBA4FCBMHh2udDKA7BItDg2OCQWADo2+BZoJf X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="108071459" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2012 04:04:47 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7344ltn004881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 04:04:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.85]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 23:04:47 -0500 From: "Aamer Akhter (aakhter)" To: Juergen Schoenwaelder Thread-Topic: [OPSAWG] draft-schoenw-opsawg-vm-mib scaling question Thread-Index: Ac1xA6F5IspGVUWZRdikvdd9R84mTgALrLQAAAHgMxA= Date: Fri, 3 Aug 2012 04:04:46 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC0960F540ABB@xmb-rcd-x15.cisco.com> References: <75C0E47A1889264493A2DCB2869AC0960F53D096@xmb-rcd-x15.cisco.com> <20120802234204.GC87351@elstar.local> In-Reply-To: <20120802234204.GC87351@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.113.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--36.511600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-schoenw-opsawg-vm-mib@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-schoenw-opsawg-vm-mib scaling question X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 04:04:54 -0000 Again, these are for cases where a full dump is not needed across the VMs. = It is similar to Solution #02-01 but where #02-01 just indicates a change i= n value, the idea here is to quantify & threshold the change to see if it i= s meaningful of further data capture. Examples: (I'm simplifying quite a bit) 1. create a histogram representing all CPU loads of the VMs on the machine= . The buckets of the histogram could represent a CPU load of 0-25, 26-50, 5= 1-75.. etc). Rather than the poller grabbing each of the individual CPUs it= could just look at the histogram to see if there is any high level change = worth investigating more.=20 2. select 5-6 KPI within a MIB tree (lets' say in if-mib it's items like i= fOperStatus, %change in InOctets, %OutErrors, etc) if any of these exceed c= onfigured thresholds indicate a change via a new object for that specific V= M. You could also group the 100's of VMs into buckets where each bucket has an= indicator object representing significant change. This would ease the need= to scan through each of the VMs. hth -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, August 02, 2012 7:42 PM To: Aamer Akhter (aakhter) Cc: draft-schoenw-opsawg-vm-mib@tools.ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] draft-schoenw-opsawg-vm-mib scaling question On Thu, Aug 02, 2012 at 11:30:51PM +0000, Aamer Akhter (aakhter) wrote: > Hi there, >=20 > There was a question regarding scaling in the case of hundreds of VMs etc= . >=20 > In cases if a full dump is not needed, does it make sense to have the abi= lity to create flag setting thresholds that represent an aggregation and po= rtion of a MIB tree? This might provide a more lightweight polling mechanis= m than a scan of large spans of the MIB. >=20 Can you perhaps elaborate using an example what "create flag setting thresh= olds that represent an aggregation and portion of a MIB tree" means? BTW, there are generic thresholding and even expression MIBs. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Thu Aug 2 23:58:05 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959C021E8034; Thu, 2 Aug 2012 23:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.462 X-Spam-Level: X-Spam-Status: No, score=-101.462 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDg7TH6zMSrw; Thu, 2 Aug 2012 23:58:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D33821E8039; Thu, 2 Aug 2012 23:58:04 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so4597115wib.13 for ; Thu, 02 Aug 2012 23:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dbONaZKbFwOe0wVPYbEInwlodLIqmdwLE3wCA43X8vc=; b=C50MhQYZAsxht85VVXdVtTaKmvvcxdBL8Xh/NPu5/sB35iB7J/RTNLgt6AS3CGPy1j t3J8HRwEXur62kvW7HhG8Uehk+pLAfUjzHZGG+T4SKDUDRAGLMZUGci8Xnwyi1VEe/sX SwAfvEgPsGau1VgghlrAreoiruIQ0h/id6CvfTE07R2qTh4RWATjtWx8v4IBb316ZCKp low46WnwLpZ5BgFQtWRVV6dO9XJKXHpCmSaW1WuOc6fiY0sEAnYa4Ezn+YuJDR/mDikW K42xGLXqNwGlLOItbxwJxMx+VvfcAxUCrjzomQwqmG7Az8+c6laWp+qt2aZozon/1tno 76wA== Received: by 10.216.101.68 with SMTP id a46mr335171weg.120.1343977082767; Thu, 02 Aug 2012 23:58:02 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-217-126.as13285.net. [2.102.217.126]) by mx.google.com with ESMTPS id cu1sm37903317wib.6.2012.08.02.23.58.00 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 23:58:01 -0700 (PDT) Message-ID: <501B767B.6030501@gmail.com> Date: Fri, 03 Aug 2012 07:58:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: robert@raszuk.net References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> <501AC43A.3020307@raszuk.net> In-Reply-To: <501AC43A.3020307@raszuk.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 06:58:06 -0000 On 02/08/2012 19:17, Robert Raszuk wrote: > Hi Brian, > > Perhaps we understand a different thing by "xml schema" As example what > I had in mind when asking this question was the example from "Appendix > A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where > while perhaps not yet complete it does provide decent representation of > one of the popular service today. There are certainly cases where systematic metadata are useful; I can't judge whether VPN configuration is one of them, but I can easily believe it. In such a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else you might choose. > That's what I had mind asking why such appendix isn't a mandatory part > of each new protocol extension. That's an enormous leap that I just don't understand. Most protocols don't need that sort of configuration complexity. > It has very little to do with Web Services you may be referring to. Yes it does. It's exactly because of a doctrinaire approach that whatever it is, it should be represented by an XML schema, that WS-splat became such a horribly complex matter. Again: no problem with creating XML schemata where they are useful. But making them mandatory would be just as bad as making MIB modules mandatory, IMHO. Brian > > Many thx, > R. > >> I think anyone with intimate experience of the Web Services standards >> experiment (trying to use XML as if it was a Turing machine) would have >> extreme doubts about any proposal to impose such a requirement. >> >> It was not for no reason that many people came to refer to the Web >> Services family of standards as "WS-splat". The words "small" and >> "xml schema" don't really belong together, >> >> Regards >> Brian Carpenter >> >> On 02/08/2012 18:12, Robert Raszuk wrote: >>> Hi Dan, >>> >>>> We should be talking >>>> nowadays about a toolset rather than one tool that fits all. >>> >>> Just to clarify what I asked about .. I am not looking for a single tool >>> or single protocol to be used to configure everything. >>> >>> I am asking for small building block like xml schema (or something >>> similar) to be part of each new IETF proposal or protocol change. IMHO >>> only that can allow any further more fancy abstractions and tools to be >>> build and used in practice. >>> >>> Best regards, >>> R. >>> >>> >>> >>>> Hi, >>>> >>>> The OPSAWG/OPSAREA open meeting this afternoon has an item on the >>>> agenda >>>> concerning the revision of RFC1052 and discussing a new architecture >>>> for >>>> management protocols. >>>> >>>> >>>> My personal take is that no one protocol, or one data modeling language >>>> can match the operational requirements to configure and manage the wide >>>> and wider range of hosts, routers and other network devices that are >>>> used to implement IP networks and protocols. We should be talking >>>> nowadays about a toolset rather than one tool that fits all. However, >>>> this is a discussion that just starts. >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >>>> Of >>>>> Robert Raszuk >>>>> Sent: Thursday, August 02, 2012 7:25 PM >>>>> Cc: ietf@ietf.org >>>>> Subject: Basic ietf process question ... >>>>> >>>>> All, >>>>> >>>>> IETF documents have number of mandatory sections .. IANA Actions, >>>>> Security Considerations, Refs, etc ... >>>>> >>>>> Does anyone have a good reason why any new protocol definition or >>>>> enhancement does not have a build in mandatory "XML schema" section >>>>> which would allow to actually use such standards based enhancement in >>>>> vendor agnostic way ? >>>>> >>>>> There is a lot of talk about reinventing APIs, building network wide >>>> OS >>>>> platform, delivering SDNs (whatever it means at any point of time for >>>>> one) ... but how about we start with something very basic yet IMHO >>>>> necessary to slowly begin thinking of network as one plane. >>>>> >>>>> I understand that historically we had/still have SNMP however I have >>>>> never seen this being mandatory section of any standards track >>>> document. >>>>> Usually SNMP comes 5 years behind (if at all) making it obsolete by >>>>> design. >>>>> >>>>> NETCONF is great and very flexible communication channel for >>>>> provisioning. However it is sufficient to just look at number of ops >>>>> lists to see that those who tried to use it quickly abandoned their >>>>> efforts due to complete lack of XML schema from each vendor they >>>> happen >>>>> to use or complete mismatch of vendor to vendor XML interpretation. >>>>> >>>>> And while perhaps this is obvious I do not think that any new single >>>>> effort will address this. This has to be an atomic and integral part >>>> of >>>>> each WG's document. >>>>> >>>>> Looking forward for insightful comments ... >>>>> >>>>> Best, >>>>> R. >>>>> >>>> >>>> >>>> >>> >>> >> >> > > From robert@raszuk.net Fri Aug 3 00:22:15 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4D321E8050 for ; Fri, 3 Aug 2012 00:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jwTFi-8+2RV for ; Fri, 3 Aug 2012 00:22:15 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD221E8034 for ; Fri, 3 Aug 2012 00:22:14 -0700 (PDT) Received: (qmail 31317 invoked by uid 399); 3 Aug 2012 07:22:13 -0000 Received: from unknown (HELO ?10.0.1.2?) (pbs:robert@raszuk.net@64.114.198.24) by mail1310.opentransfer.com with ESMTPM; 3 Aug 2012 07:22:13 -0000 X-Originating-IP: 64.114.198.24 Message-ID: <501B7C22.3030706@raszuk.net> Date: Fri, 03 Aug 2012 09:22:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> <501AC43A.3020307@raszuk.net> <501B767B.6030501@gmail.com> In-Reply-To: <501B767B.6030501@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 07:22:16 -0000 Hello Brian, > That's an enormous leap that I just don't understand. Most protocols don't > need that sort of configuration complexity. Hmmmm I am of the opinion that most protocols requires configuration. I am also of the opinion that each vendor chooses an original way to configure their network elements. Therefor if you do not define up front a standard based of configuring given routing protocol you will end up with exactly what we have today .. zoo of various different CLI commands to enable the exact same protocol across more then one vendor box. Are you saying that this is ok ? Or are you saying that there is simpler way to enable netconf based unified way to configure protocols and services on your network other then providing per component "xml schema" with subsequent schema extensions as part of IETF standardization process ? To make it a bit more explicit ... do you really need to study 5 user manuals or google 5 times to enable IGP or BGP or even configure NTP across 5 different router OS running in your network ??? > Again: no problem with creating XML schemata where they are useful. > But making them mandatory would be just as bad as making MIB modules > mandatory, IMHO. Aha .. so you are saying that MIBs are not mandatory .... Very interesting. So I guess SSH to the routers and box by box cli provisioning is here to stay for a while I think :( Best regards, R. From ietfc@btconnect.com Fri Aug 3 01:27:53 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEB421F8D72 for ; Fri, 3 Aug 2012 01:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3YdSQBf-uA0 for ; Fri, 3 Aug 2012 01:27:52 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id BB14E21F8D35 for ; Fri, 3 Aug 2012 01:27:52 -0700 (PDT) Received: from mail182-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 08:27:52 +0000 Received: from mail182-co1 (localhost [127.0.0.1]) by mail182-co1-R.bigfish.com (Postfix) with ESMTP id 91CC5540374; Fri, 3 Aug 2012 08:27:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT011.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542M1432I1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail182-co1 (localhost.localdomain [127.0.0.1]) by mail182-co1 (MessageSwitch) id 1343982470694925_13972; Fri, 3 Aug 2012 08:27:50 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.254]) by mail182-co1.bigfish.com (Postfix) with ESMTP id A778ED80044; Fri, 3 Aug 2012 08:27:50 +0000 (UTC) Received: from DB3PRD0702HT011.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 08:27:50 +0000 Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by pod51017.outlook.com (10.3.48.170) with Microsoft SMTP Server (TLS) id 14.15.86.1; Fri, 3 Aug 2012 08:27:38 +0000 Message-ID: <016401cd7151$3cb50b80$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter , References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com><501AC43A.3020307@raszuk.net> <501B767B.6030501@gmail.com> Date: Fri, 3 Aug 2012 09:22:53 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.117] X-OriginatorOrg: btconnect.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 08:27:53 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Friday, August 03, 2012 7:58 AM > On 02/08/2012 19:17, Robert Raszuk wrote: > > Hi Brian, > > > > Perhaps we understand a different thing by "xml schema" As example what > > I had in mind when asking this question was the example from "Appendix > > A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where > > while perhaps not yet complete it does provide decent representation of > > one of the popular service today. > > There are certainly cases where systematic metadata are useful; I can't judge > whether VPN configuration is one of them, but I can easily believe it. In such > a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else > you might choose. > I don't:-) I think that XML is a disaster, lacking any fundamental principles or coherence, something that I see with its use for protocols such as Netconf. By contrast, I never saw such problems with SNMP and ASN.1, except where the IETF had limited its use thereof (which was probably the right call). Tom Petch > > Brian > > > > > Many thx, > > R. > > From j.schoenwaelder@jacobs-university.de Fri Aug 3 06:29:49 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A02821F8D9D; Fri, 3 Aug 2012 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5zvJrKsF3Ct; Fri, 3 Aug 2012 06:29:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BABA721F8D8E; Fri, 3 Aug 2012 06:29:47 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1D2A20C0A; Fri, 3 Aug 2012 15:29:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GKCI3dLssajV; Fri, 3 Aug 2012 15:29:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0584820BFB; Fri, 3 Aug 2012 15:29:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A306A2103BA8; Fri, 3 Aug 2012 15:29:45 +0200 (CEST) Date: Fri, 3 Aug 2012 15:29:45 +0200 From: Juergen Schoenwaelder To: Robert Raszuk Message-ID: <20120803132945.GD88437@elstar.local> Mail-Followup-To: Robert Raszuk , Brian E Carpenter , opsawg@ietf.org, ietf@ietf.org References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> <501AC43A.3020307@raszuk.net> <501B767B.6030501@gmail.com> <501B7C22.3030706@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501B7C22.3030706@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2012 13:29:49 -0000 On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote: > > Aha .. so you are saying that MIBs are not mandatory .... Very > interesting. So I guess SSH to the routers and box by box cli > provisioning is here to stay for a while I think :( > Robert, you may want to take a closer look at the data models currently being defined in the NETMOD working group. Please review them and send any comments. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From robert@raszuk.net Fri Aug 3 07:31:45 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC721F8D72 for ; Fri, 3 Aug 2012 07:31: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaFnXUNc5ULH for ; Fri, 3 Aug 2012 07:31:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 562D621F8D6A for ; Fri, 3 Aug 2012 07:31:44 -0700 (PDT) Received: (qmail 30588 invoked by uid 399); 3 Aug 2012 14:31:43 -0000 Received: from unknown (HELO ?10.0.1.2?) (pbs:robert@raszuk.net@64.114.198.24) by mail1310.opentransfer.com with ESMTPM; 3 Aug 2012 14:31:43 -0000 X-Originating-IP: 64.114.198.24 Message-ID: <501BE0CE.90605@raszuk.net> Date: Fri, 03 Aug 2012 16:31:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> <501AC43A.3020307@raszuk.net> <501B767B.6030501@gmail.com> <501B7C22.3030706@raszuk.net> <20120803132945.GD88437@elstar.local> In-Reply-To: <20120803132945.GD88437@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:31:45 -0000 Hi Juergen, Many thx for the great suggestion ! However perhaps you are much more knowledgeable in that area and could recommend which model fit the best the requirement to standardize configuration of any new protocol or protocol extension at least in the space of routing and routing protocols or services being based on them ? As you know the current IRS framework driven by junisco is trying to come with common API to the routing system agreed across vendors. This is great as attempts never happened in the past. But if we are at this phase I think creating a network elements abstraction layer and be able to configure/monitor any protocol and service at the unified way is one of the building blocks we should start with. And of course I think this is very clear to everyone if it is not made mandatory in each draft as new section or appendix it is just not going to happen in practice. Best regards, R. > On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote: >> >> Aha .. so you are saying that MIBs are not mandatory .... Very >> interesting. So I guess SSH to the routers and box by box cli >> provisioning is here to stay for a while I think :( >> > > Robert, > > you may want to take a closer look at the data models currently being > defined in the NETMOD working group. Please review them and send any > comments. > > /js > From j.schoenwaelder@jacobs-university.de Fri Aug 3 08:31:05 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3038221F8DCF; Fri, 3 Aug 2012 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJUGjspP3hmX; Fri, 3 Aug 2012 08:31:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7540921F8DC3; Fri, 3 Aug 2012 08:31:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5278420C0A; Fri, 3 Aug 2012 17:31:03 +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 tOL92Xs9F__U; Fri, 3 Aug 2012 17:31:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E23E120BED; Fri, 3 Aug 2012 17:31:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C46142103DAB; Fri, 3 Aug 2012 17:31:00 +0200 (CEST) Date: Fri, 3 Aug 2012 17:31:00 +0200 From: Juergen Schoenwaelder To: Robert Raszuk Message-ID: <20120803153100.GA88678@elstar.local> Mail-Followup-To: Robert Raszuk , opsawg@ietf.org, ietf@ietf.org References: <501AA9DF.6010208@raszuk.net> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com> <501AC43A.3020307@raszuk.net> <501B767B.6030501@gmail.com> <501B7C22.3030706@raszuk.net> <20120803132945.GD88437@elstar.local> <501BE0CE.90605@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501BE0CE.90605@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2012 15:31:05 -0000 On Fri, Aug 03, 2012 at 04:31:42PM +0200, Robert Raszuk wrote: > > But if we are at this phase I think creating a network elements > abstraction layer and be able to configure/monitor any protocol and > service at the unified way is one of the building blocks we should > start with. And of course I think this is very clear to everyone if > it is not made mandatory in each draft as new section or appendix it > is just not going to happen in practice. > Writing data models that are implementable on multiple platforms is non trivial. We started working on your "building block" but it will take time. And after all, a data model is only worth something if it gets implemented. A mandatory section does not help much with all of this. What helps is people who commit time to work on it, who review stuff, producing good and hopefully widely implementable models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Aug 3 09:18:41 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AF21F8E57; Fri, 3 Aug 2012 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLNBRRvOissx; Fri, 3 Aug 2012 09:18:41 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9D21F8E54; Fri, 3 Aug 2012 09:18:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ehI2/7sAO48DEMr7AsdlCx+SWeFXZfdBkcDtBh0HerkfURte7xXbZzV5Q/el5WyJ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.55.169] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SxKaG-0002vX-FK; Fri, 03 Aug 2012 12:18:40 -0400 Message-ID: <006601cd7194$6681e620$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com><501AA9DF.6010208@raszuk.net> Date: Fri, 3 Aug 2012 09:24:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f11d75e9d171ba3468f40dcd775cc11f38350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.169 Cc: ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:18:41 -0000 Hi - > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: ; > Sent: Thursday, August 02, 2012 10:13 AM > Subject: Re: [OPSAWG] Basic ietf process question ... ... > NMS developers need to spend too many resources on translating > naming and other data-modeling specific details so they can be > usable within the application. So if 1 data modeling language > is not used, then deterministic, loss-less, round-trip translation > between data modeling languages is needed. Multiple > protocols are not the problem -- incompatible data from multiple > protocols is the problem. ... Picking a single language or set of round-trip translatable languages also isn't enough. Its a fact of life that vendors will produce models and implementations that are slightly, or even radically different. The differences aren't necessarily even intentional, but nonetheless introduce the need to talk about "similar" models and "operationally equivalent" configurations, where the transformations needed to go from what will do the job on one piece of equipment to what will work on another may be substantial. (From an implementation perspective it might be better to think in terms of transformations necessary to go from a common model of desired operational characteristics to the dial tweaks and button pokes necessary to get a device to do the right thing.) Since great minds often think alike, even in the absence of standards, there is not necessarily a formal "derived from" or "subclass" or "common aspect" relationship between the definitions. This may be an obvious use case for XSLT, but as far as I know nothing has been done about *standardizing* such usage, other than discussions at the IAB workshop oh-so-many years ago, and some ISO/ITU discussions in the 1990s about eventual applications of the General Relationship Model and the management domain/policy stuff in GDMO land. Randy From liljenstolpe@gmail.com Fri Aug 3 09:51:18 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127B121F8E1D for ; Fri, 3 Aug 2012 09:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgrDun8XPd0i for ; Fri, 3 Aug 2012 09:51:17 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7996021F8DD4 for ; Fri, 3 Aug 2012 09:51:17 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1180558ggn.31 for ; Fri, 03 Aug 2012 09:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=mZG6s04BhBTPSwnW7zUsSKBQnbJpmGumeNx9FKXnjT4=; b=FC32GjcvDcK5ROpojncLFstRv9GhphtSMgjPSZTebaD+cwUCO0tNWzLvIL06d1Vuyi XHYP8vrzyUUUBhoK8mwfkm/aw2iGHCb4ZApsr5/HBeRhZvn/Q7uakEBj8UoElLtRqoSb 0qgG/EWyvCT8rvcIQaxNAK/bkRh+JCS2Giy15Y0vTGWpfGVBI445BFNdUtdmtnTsPvDw iqEUin+LWttAtrs4GjsY/IoZLuLBvApDgiLvKQYx+dnTOIRoxLGoS5v46gPA1THEAKW4 2FV+BAuNEzxgXbeBzZqzBmp3RVgK1YFvj7pFTQeD6nERUvn3dL7cDpu1dFOumlV+UQ4a tv0Q== Received: by 10.50.170.3 with SMTP id ai3mr12072580igc.9.1344012676555; Fri, 03 Aug 2012 09:51:16 -0700 (PDT) Received: from ?IPv6:2001:df8::96:3c39:9807:2f6d:1d80? ([2001:df8:0:96:3c39:9807:2f6d:1d80]) by mx.google.com with ESMTPS id d4sm4685484iga.14.2012.08.03.09.51.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 09:51:16 -0700 (PDT) From: Christopher LILJENSTOLPE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Aug 2012 09:51:14 -0700 Message-Id: <6EFD7DC9-419F-40C8-84C0-71421DA65233@gmail.com> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: "ops-ads@tools.ietf.org Management Area" , opsawg-chairs Subject: [OPSAWG] Gmane reflector of list X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:51:53 -0000 Greetings, The gmane reflector for the opsawg mailing list has been setup = as gmane.ietf.opsawg. They will also pull the existing archives over = and make them available as well. Chris From robert@raszuk.net Thu Aug 2 10:12:34 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA0B11E8133 for ; Thu, 2 Aug 2012 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytMGMMCa97DI for ; Thu, 2 Aug 2012 10:12:32 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF811E80F7 for ; Thu, 2 Aug 2012 10:12:25 -0700 (PDT) Received: (qmail 24306 invoked by uid 399); 2 Aug 2012 17:12:22 -0000 Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 17:12:22 -0000 X-Originating-IP: 130.129.17.10 Message-ID: <501AB4F5.7030205@raszuk.net> Date: Thu, 02 Aug 2012 19:12:21 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <501AA9DF.6010208@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 03 Aug 2012 10:09:57 -0700 Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:12:35 -0000 Hi Dan, > We should be talking > nowadays about a toolset rather than one tool that fits all. Just to clarify what I asked about .. I am not looking for a single tool or single protocol to be used to configure everything. I am asking for small building block like xml schema (or something similar) to be part of each new IETF proposal or protocol change. IMHO only that can allow any further more fancy abstractions and tools to be build and used in practice. Best regards, R. > Hi, > > The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda > concerning the revision of RFC1052 and discussing a new architecture for > management protocols. > > > My personal take is that no one protocol, or one data modeling language > can match the operational requirements to configure and manage the wide > and wider range of hosts, routers and other network devices that are > used to implement IP networks and protocols. We should be talking > nowadays about a toolset rather than one tool that fits all. However, > this is a discussion that just starts. > > Regards, > > Dan > > > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > Of >> Robert Raszuk >> Sent: Thursday, August 02, 2012 7:25 PM >> Cc: ietf@ietf.org >> Subject: Basic ietf process question ... >> >> All, >> >> IETF documents have number of mandatory sections .. IANA Actions, >> Security Considerations, Refs, etc ... >> >> Does anyone have a good reason why any new protocol definition or >> enhancement does not have a build in mandatory "XML schema" section >> which would allow to actually use such standards based enhancement in >> vendor agnostic way ? >> >> There is a lot of talk about reinventing APIs, building network wide > OS >> platform, delivering SDNs (whatever it means at any point of time for >> one) ... but how about we start with something very basic yet IMHO >> necessary to slowly begin thinking of network as one plane. >> >> I understand that historically we had/still have SNMP however I have >> never seen this being mandatory section of any standards track > document. >> Usually SNMP comes 5 years behind (if at all) making it obsolete by >> design. >> >> NETCONF is great and very flexible communication channel for >> provisioning. However it is sufficient to just look at number of ops >> lists to see that those who tried to use it quickly abandoned their >> efforts due to complete lack of XML schema from each vendor they > happen >> to use or complete mismatch of vendor to vendor XML interpretation. >> >> And while perhaps this is obvious I do not think that any new single >> effort will address this. This has to be an atomic and integral part > of >> each WG's document. >> >> Looking forward for insightful comments ... >> >> Best, >> R. >> > > > From christopher.liljenstolpe@bigswitch.com Thu Aug 2 16:38:10 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9DD11E80F0 for ; Thu, 2 Aug 2012 16:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m04lfDxJtm1l for ; Thu, 2 Aug 2012 16:38:10 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A611E8072 for ; Thu, 2 Aug 2012 16:38:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so122535ghb.31 for ; Thu, 02 Aug 2012 16:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kRi/aGpFY27tX8TFwrXSdcukRpcwKl5vjQqx1tTdT68=; b=Ge91O6D5vktEZp8ofElj2nRufmAS/HQ3s6hwfxFhLvzyVHmOr5iPBZLTRNi8Id4dI8 mHdKEhRsc3Ci+ojT3bktwK06dG4DmCI8A6AUBkJJT2F75fU3Uy2JDY7rEhDW4adRvwFJ PegjUhIo+RDf8er8MAucD+TWcQHR63V8qY6sWSpNd0zWVthGYVzMFv7TdvvSsDIpq3Cx p5sB3b/LYwiUfaUN2KW0N+bAmTfifxgm5FWXAwB4u/3SIWzn6iYn7cVqFXLL762Cwojn DxW1EZsuGWLAU6fK9CjqVkzVilLCL7ppJ+cLNseOUFzKOBU49FT7kTj1a0vfP5tJYdg3 AwuA== Received: by 10.50.170.65 with SMTP id ak1mr6683659igc.43.1343950688861; Thu, 02 Aug 2012 16:38:08 -0700 (PDT) Received: from ?IPv6:2001:df8::96:6c1e:1a66:b618:6639? ([2001:df8:0:96:6c1e:1a66:b618:6639]) by mx.google.com with ESMTPS id ud8sm16708483igb.4.2012.08.02.16.38.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 16:38:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <75C0E47A1889264493A2DCB2869AC0960F53CC57@xmb-rcd-x15.cisco.com> Date: Thu, 2 Aug 2012 16:38:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F298ACC76CC154F832B6D02852D169F079F3DC8@XMB-RCD-101.cisco.com> <9AD0D6B7-6587-4864-B427-571DC97C44FD@cdl.asgaard.org> <75C0E47A1889264493A2DCB2869AC0960F53CC57@xmb-rcd-x15.cisco.com> To: "Aamer Akhter (aakhter)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkN0miww1AqDcs2hcp/g034hs5TdS1xXjisWIe6YqZ5fTI41c71w/je4Wv72NM2aGUwzDZm X-Mailman-Approved-At: Fri, 03 Aug 2012 10:09:57 -0700 Cc: "opsawg@ietf.org" , "Tools-discuss@ietf.org" , opsawg-chairs Subject: Re: [OPSAWG] [Tools-discuss] hosting of opsawg at news.gmane.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:38:10 -0000 Didn't hear from them for a long time, then did, and then quiet again. = I will re-pickup =09 Chris On 02Aug2012, at 16.05, Aamer Akhter (aakhter) wrote: > Hi Guys, >=20 > Did the replication of the archive to news.gmane.org occour? I wasn't = able to find it there. >=20 > -----Original Message----- > From: tools-discuss-bounces@ietf.org = [mailto:tools-discuss-bounces@ietf.org] On Behalf Of Christopher = LILJENSTOLPE > Sent: Wednesday, March 28, 2012 5:01 AM > To: Aamer Akhter (aakhter); opsawg@ietf.org > Cc: Tools-discuss@ietf.org; opsawg-chairs > Subject: Re: [Tools-discuss] hosting of opsawg at news.gmane.org >=20 > Consider it done. Please remember that the ietf mailing list archive = is the definitive one. >=20 > Chris >=20 > On 28Mar2012, at 00.48, Aamer Akhter (aakhter) wrote: >=20 >>=20 >>=20 >> There are a large number of IETF mailing lists hosted at gmane. I = have=20 >> found it a much easier interface to interact with rather than the=20 >> official archive at=20 >> (http://www.ietf.org/mail-archive/web/opsawg/current/maillist.html). >>=20 >>=20 >>=20 >> 1) Would it be possible to import the existing archive into >> gmane.org? >> This requires the 'owner' of mailing list to make the request.=20 >> http://gmane.org/import.php >>=20 >>=20 >>=20 >> 2) Would it be possible for gmane.org to subscribe to the = mailing >> list such as to archive the forward discussions in a nicer interface? >> http://gmane.org/subscribe.php >>=20 >>=20 >>=20 >> Thanks for any consideration, >>=20 >> aa >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc > Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf > Check my calendar availability: https://tungle.me/cdl >=20 > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl From christopher.liljenstolpe@bigswitch.com Thu Aug 2 17:08:55 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6937611E8087 for ; Thu, 2 Aug 2012 17:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH2TB4gqJIg8 for ; Thu, 2 Aug 2012 17:08:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28B21F8BE7 for ; Thu, 2 Aug 2012 17:08:54 -0700 (PDT) Received: by yenq13 with SMTP id q13so149829yen.31 for ; Thu, 02 Aug 2012 17:08:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rwxGTzJ/xjiPUrRXbn6xvMgdpKbUdcs0rqcRdrNsZqA=; b=i5OMyUKRI6zfYERGmWvq620e7EtzDLH/KT/Kpvu8JRp7AvmqdUoGXR/myH+I4WeEGy MVreyAf3vwN3MCU6u/6PayAnNDNQBIFKd8TixetMJRcxYlZ2BvT711iRIXM9BixZov/4 1PCT4fF/GIPj4sQZWS947gdgE0UvutPEE8YYHe6oG6MiJlrUZo28J8G/Fadfco2EZRVd pD45Qt25Egf1jQC3iBjIH+vwGgyko2bj2rM63BX3KBTCUt3kkHOXFVC9ZU7YtBQrVlMZ wfTrrqpHnglvqnIPQiXt377vDNbF/MD3bnOsk2zsmDfBZJD3ozju3b/X3UwRCJMZSf3y 9UdQ== Received: by 10.50.169.4 with SMTP id aa4mr6722847igc.53.1343952533515; Thu, 02 Aug 2012 17:08:53 -0700 (PDT) Received: from ?IPv6:2001:df8::96:6c1e:1a66:b618:6639? ([2001:df8:0:96:6c1e:1a66:b618:6639]) by mx.google.com with ESMTPS id z7sm19252651igb.3.2012.08.02.17.08.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 17:08:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: Date: Thu, 2 Aug 2012 17:08:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F298ACC76CC154F832B6D02852D169F079F3DC8@XMB-RCD-101.cisco.com> <9AD0D6B7-6587-4864-B427-571DC97C44FD@cdl.asgaard.org> <75C0E47A1889264493A2DCB2869AC0960F53CC57@xmb-rcd-x15.cisco.com> To: "Aamer Akhter (aakhter)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn3RavkOqsjYAsfr+GB3s9b+Vy7fN6IJRkfG3a1JIhk6F48JLSkCguBq60DTXfaQRQfVTSk X-Mailman-Approved-At: Fri, 03 Aug 2012 10:09:57 -0700 Cc: "opsawg@ietf.org" , "Tools-discuss@ietf.org" , opsawg-chairs Subject: Re: [OPSAWG] [Tools-discuss] hosting of opsawg at news.gmane.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:08:55 -0000 Greetings, The request is in. Chris On 02Aug2012, at 16.38, Christopher LILJENSTOLPE wrote: > Didn't hear from them for a long time, then did, and then quiet again. = I will re-pickup > =09 > Chris >=20 > On 02Aug2012, at 16.05, Aamer Akhter (aakhter) wrote: >=20 >> Hi Guys, >>=20 >> Did the replication of the archive to news.gmane.org occour? I wasn't = able to find it there. >>=20 >> -----Original Message----- >> From: tools-discuss-bounces@ietf.org = [mailto:tools-discuss-bounces@ietf.org] On Behalf Of Christopher = LILJENSTOLPE >> Sent: Wednesday, March 28, 2012 5:01 AM >> To: Aamer Akhter (aakhter); opsawg@ietf.org >> Cc: Tools-discuss@ietf.org; opsawg-chairs >> Subject: Re: [Tools-discuss] hosting of opsawg at news.gmane.org >>=20 >> Consider it done. Please remember that the ietf mailing list archive = is the definitive one. >>=20 >> Chris >>=20 >> On 28Mar2012, at 00.48, Aamer Akhter (aakhter) wrote: >>=20 >>>=20 >>>=20 >>> There are a large number of IETF mailing lists hosted at gmane. I = have=20 >>> found it a much easier interface to interact with rather than the=20 >>> official archive at=20 >>> (http://www.ietf.org/mail-archive/web/opsawg/current/maillist.html). >>>=20 >>>=20 >>>=20 >>> 1) Would it be possible to import the existing archive into >>> gmane.org? >>> This requires the 'owner' of mailing list to make the request.=20 >>> http://gmane.org/import.php >>>=20 >>>=20 >>>=20 >>> 2) Would it be possible for gmane.org to subscribe to the = mailing >>> list such as to archive the forward discussions in a nicer = interface? >>> http://gmane.org/subscribe.php >>>=20 >>>=20 >>>=20 >>> Thanks for any consideration, >>>=20 >>> aa >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> -- >> =E6=9D=8E=E6=9F=AF=E7=9D=BF >> Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc >> Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf >> Check my calendar availability: https://tungle.me/cdl >>=20 >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > -- =20 > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc > Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf > Check my calendar availability: https://tungle.me/cdl >=20 -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl From janovak@cisco.com Fri Aug 3 07:40:03 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CD21F8463; Fri, 3 Aug 2012 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmnRDfU6EUlo; Fri, 3 Aug 2012 07:40:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9321F8DC0; Fri, 3 Aug 2012 07:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2875; q=dns/txt; s=iport; t=1344004802; x=1345214402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2rmf9ehrhIvQCY5pWkaFFgCw2ZQio0fkGCwU+3yA/G8=; b=PYJVWlupLrS3IJfDa9JBoxh6nbosJ/OV64piO4RdJO1cRqxpxTvX084M +2sQSXTCw63PoXGyJ2nu4wJ5BH8W++YJhNSU5StbBnhzfq/e8QWItIL1I Uk9VzMrYnwkd+4sDIpFeyc0c2KanIQmXT8gZGM0LreD69dSvZv3Cx8dSX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB7iG1CtJXG8/2dsb2JhbABFuRyBB4IgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgBAQQBDQUIGodrnESgKotIhiRgA6NxgWaCXw X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208";a="108211278" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2012 14:40:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q73Ee15L003563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 14:40:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 09:40:01 -0500 From: "Jan Novak (janovak)" To: "Aamer Akhter (aakhter)" , "'ipfix@ietf.org'" , "'opsawg@ietf.org'" Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQDYLiRuAA4E6qQA== Date: Fri, 3 Aug 2012 14:40:00 +0000 Message-ID: References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> In-Reply-To: <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.89.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--42.180200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 03 Aug 2012 10:09:57 -0700 Cc: Hendrik Scholz , 'Al Morton' , "'pmol@ietf.org'" Subject: Re: [OPSAWG] Comments on draft-akhter-opsawg-perfmon-ipfix-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:40:03 -0000 Hi again, Thanks for applying the comments. AA> Jan, can you look again ? Is there still a problem? No, sorry missed the TBD or its significance. AA> We're open to adding scope (as defined as which set of packets would th= is be applicable to). AA> Would you agree that this is more of a methodology item than a IE item? Yes, indeed, whichever of Observation domain/Scope it is, it is not the pro= perty of the IE. Jan The climate of Edinburgh is such that the weak succumb young, and the strong envy them .... Dr. Johnson -----Original Message----- From: Aamer Akhter (aakhter)=20 Sent: 30 July 2012 16:50 To: Jan Novak (janovak); 'ipfix@ietf.org'; 'opsawg@ietf.org' Cc: 'Al Morton'; 'pmol@ietf.org'; Hendrik Scholz Subject: RE: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Jan, Thank-you for the review. Please find my comments below. We Hendrik and I w= ill be publishing -03 shortly.=20 -----Original Message----- From: Jan Novak (janovak)=20 Sent: Tuesday, May 22, 2012 4:58 AM To: Aamer Akhter (aakhter); ipfix@ietf.org; opsawg@ietf.org Cc: Al Morton; pmol@ietf.org Subject: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - se= ction 1,3, 4 could probably be abbreviated or omitted leaving the document = just with raw IPFIX IE specifications or just add the IE specification as s= ub-sections or a new section into the first document ??=20 AA> I agree that there is overlap, but it was retained for readability. But= I see your point regarding keeping the focus on the IEs in the IPFIX versi= on of the draft. Will strip some of the detail in the IPFIX version. Section 2 uses definitions from RFC5610 - I think those you use there are d= efined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are de= fining the IE itself so you should use the definitions from RFC5102 AA> I think I had used RFC5610 as it seemed to be a bit more specific about= it (eg rangeBegin and rangeEnd rather than just range). But we are fine e= ither way depending on feedback. Also the methodology documents already speaks in terms of IPFIX IEs while y= ou are trying to specify some performance metrics - the methodology could h= ave names and an exact definitions of the metric and then a reference which= IE represents the particular metric AA> will update the methodology doc with exact definitions and reference th= e IEs.=20 RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST en= tries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. From mrm@vmware.com Mon Aug 6 19:56:09 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8A821F86B1 for ; Mon, 6 Aug 2012 19:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55rLOad8sL3x for ; Mon, 6 Aug 2012 19:56:08 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6B21F86B3 for ; Mon, 6 Aug 2012 19:56:08 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id C93EB28839; Mon, 6 Aug 2012 19:56:07 -0700 (PDT) Received: from zimbra-prod-mta-3.vmware.com (zimbra-prod-mta-3.vmware.com [10.113.160.227]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id C5646B01CD; Mon, 6 Aug 2012 19:56:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-3.vmware.com (Postfix) with ESMTP id C0916E2B66; Mon, 6 Aug 2012 19:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-3.vmware.com Received: from zimbra-prod-mta-3.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-3.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK7aX91Dmxvl; Mon, 6 Aug 2012 19:56:07 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zimbra-prod-mta-3.vmware.com (Postfix) with ESMTP id A54A0E2A9F; Mon, 6 Aug 2012 19:56:07 -0700 (PDT) Date: Mon, 6 Aug 2012 19:56:07 -0700 (PDT) From: Michael MacFaden To: robert@raszuk.net Message-ID: <434694256.7409699.1344308167588.JavaMail.root@vmware.com> In-Reply-To: <501B7C22.3030706@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Basic ietf process question ... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 02:56:09 -0000 > Aha .. so you are saying that MIBs are not mandatory .... Very > interesting. So I guess SSH to the routers and box by box cli > provisioning is here to stay for a while I think :( Well there is one example I can think of where this didn't become the norm -- DOCSIS -- where a small customer community forced vendors through a process of standardization (trekking to Broomfield CO USA oh joy) in order for them to sell gear. And that included a set of tests for the SNMPv3 agent with mandated read-write mib modules among other mgmt protocols employed. Maybe this was a simpler problem than that's being discussed here. But given the VC activity/startups on virtualized networking can imagine that other chunks of networking infrastructure amenable to standardized configuration will follow suit. Once that occurs then standards bodies codify industry practice. Mike MacFaden |Tue, 2 Oct 2001 15:34:22 -0700 |My amendment to Postel's Law: |Be liberal in what you accept, conservative in what you send, and add a |knob so that you can interoperate even if the other guy blows it. | |Tony